Оба-на! Наши машинки опустили на 56 и 153 места. Все кластеры линуксовые прут, гады ;))

Читаю и смешно. Даже Ирси подфлеймил и свалил.

1. По поводу того, что опенМП - суксь. Да кто же заставляет использовать. Бесплатных еще вагон. MPICH, или LAM хотя бы лучше. А коммерческих реализаций - просто вагон и все как один - лучшие.

2. Здесь еще креев самих вагон и телега. В том числе и X1. Так на этом замечательном недоделаном железе можно считать лишь крипто. Что и делают. А вот других задач, которые требуют много ресурсов и плохо распараллеливаются больше вы и не назовете!!! А распараллеливаются все частные производные и обыкновенные туда же. Интегралы (ха! какой Монте-Карло, все методы могут быть распараллелены прекрасно!) туда же. Из приложений: погода, магнитосфера, ионосфера и все другие "сферы" плюсь космос, гидромеханика вся, включая задачи горения и взрыва, химия.

Смешно сказать, но построение трехмерных сцен, которые составляют оставшуюся половину ресурсоемких задач давно запараллелили.

Что еще??? Графы??? Сортировка??? Что еще я забыл? Все параллельно и все рулится MPI без проблем. Нафик. Есть еще другие методы параллелить. Но не будем о грустном. :)

И кластеры рулят прекрасно. У меня в комнате стоит самопал четырехпроцессорный - рубит почти с четырехкратным ускорением - то есть без потерь.

3. Про общую оперативку - можно плакать. :))

В общем отличный тупик. Мне в нем прекрасно считается, Ирси, прекрасно. Или вы в этом тоже профи, уважаемый? :))

smp - бред?

В суперкомпьютерах память делится на банки и подключается через коммутатор. Естественно, коммутатор растет геометрически при увеличении количества процессоров и банков памяти.

Разницы в логике блокировок нет по сравнению с обычным smp. Просто при обращении разных процессоров к разным банкам задержки нет вообще, а в случае обращении к одному банку организуется очередь.

При последовательной выборке процессором из банков при стандартном времени доступа в 4 такта и 4 банках памяти получается выборка на каждый такт.

>То, что "задачки", которые нужно решать "вам", решаемы на кластерах, не значит, что кластеры подходят для задач, которые нужно решать не вам.

Речь идет о том что если Вам что-то не нужно то это плохо. Я же не говорю что Java это плохо, просто никто в здравом уме и терзвой памяти не будет на ней писать HPC-задачу для HPC-кластера (а именно они фигурируют в Top500)

а вот для всяких HA это пожалуйста, только они к Top500 уже не имеют никакого отношения

>Бред. Оперативка точно не общая. По крайней мере не в той степени что на обычных однопроцессорниках. Прикинь как на такой тачиле отслеживать тогда какой из них имеет доступ к какой ячейке на запись а какой нет? Очень большие траты производительности получаются

Учите матчасть. Ключевае слова NUMA, DSM, SSI(хотя это к HPC прямого отношения не имеет)

>Далее: кластер медленный суперкампутер = 3 ха-ха. Посмотри-ка на проекты распределённых вычислений. F@h, Seti@home,UD (кстати почему-то не выпустят линуксовых версий клиента). Вряд-ли какой компашка из Топ500 мог-бы угнаться за этими кластерами.

И еще раз учите матчасть: то, о чем вы говорите это метакомпьютинг и к HPC кластерам имеет опосредованное отношение (там основные проблемы и задачи чуток другие)

ЗЫ: начинайте прямо с http://www.parallel.ru - там на родном языке элементарные вещи излагаются вполне доступно

2atoku: блин, пойми - тупик и экономически оправданое решение это вовсе не взаимоисключающие вещи. :) Я не спорю с тем что еще некоторое время кластеры будут рулить... а что далше? При наростании числа узлов в кластере все болшим узким местом между ними будут становится каналы связи... Вообщем мне кажется что от Eth & tcp/ip в конце-концов таки придется отказаться...

>1. По поводу того, что опенМП - суксь. Да кто же заставляет использовать. Бесплатных еще вагон. MPICH, или LAM хотя бы лучше. А коммерческих реализаций - просто вагон и все как один - лучшие.

:)) Это как говорится на вкус и цвет ... см. мнение Dselect-a ;)

PS: я всю дорогу _исторически_ предпочитаю PVM если интересно ;)

>И кластеры рулят прекрасно. У меня в комнате стоит самопал четырехпроцессорный - рубит почти с четырехкратным ускорением - то есть без потерь.

Это видимо зависит от задачи. У меня смасштабировать лучше чем с 0.7 не получается (CFD-задачи на 4x 2xOpteron-ах с гигабиткой в качестве среды передачи)

>3. Про общую оперативку - можно плакать. :))

В смысле ? ;)

>При наростании числа узлов в кластере все болшим узким местом между ними будут становится каналы связи... Вообщем мне кажется что от Eth & tcp/ip в конце-концов таки придется отказаться...

;)))

Какой такой Eth ? Какой такой TCP ? ;)))

Вы таки посмотрите на чем строятся кластеры с >50 узлами

Кстати сейчас узкое место это шина на которой сидит сетевой интерфейс ....

>При наростании числа узлов в кластере все болшим узким местом между ними будут становится каналы связи...

Ознакомьтесь с тем ЧТО, например, используется в серьезном HPC

http://www.dolphinics.com/

PS: MPI там кстати может бегать как поверх TCP так и непостредственно поверх SCI

2sS: ну так просвятите, если считаете что я не прав...:) Только не надо упоминать SGI, ок?

Шина узкое место, да? 10GbE хочется, да? :) Для простого GbE PCI-X ни разу не узкая, особенно если использовать Jumbo Frames...

2 Irsi, посмотри на SunFireLink, и InfiniBand. Bandwidth у последнего 800 Мегабайт в секунду, латентность на небольших сообщениях 5-7 мкс. Что в 30 раз меньше чем у GE, ну а BW в 8 раз выше соотвественно чем у GE. И это не предел уже сейчас системы с Infiniband BW которых порядка 2.1 Гигабайта в секунду.

В догонку реализации MPI от ncsa и osu работают как раз поверх InfiniBand и используют RDMA подсистему. Кстати забавно наблюдать когда запускаешь Linpack память отьедается не самим процессом xhpl а ядром системы :)

2anonymous (*) (24.06.2004 11:38:27): Ага, согласен... Надо мне было сразу пояснить что я назвал "классическим" кластером. Это кучка писюков с линухом и Eth, воткнутых в коммутатор... Вообщем не обязательно писюков - XServe Cluster Node тоже подходит под это определение, несмотря на то что не писюк и не с линуксом...:)
А если отказываемся от Eth во всех его проявлениях, то сразу возникает вопрос стоимости...

> А если серьезно то о чем мы говорим: Об архитектурных решениях или о парадигмах параллельного программирования ?

О решениях, вестимо. С парадигмой все более-менее понятно (хотя есть куча задач, где она не к месту).

> Например весьма комфортно программить на OpenMP поверх DSM

Вот это -- более вменяемый способ...

> вот только оверхед будет "мама не горюй"

Это не свойство DSM, это свойство ее реализации...

> вот других задач, которые требуют много ресурсов и плохо распараллеливаются больше вы и не назовете!!! А распараллеливаются все частные производные и обыкновенные туда же. Интегралы (ха! какой Монте-Карло, все методы могут быть распараллелены прекрасно!) туда же.

А ну-ка, распаралелльте адаптивное интегрирование... Или обращение разреженных матриц...

> А вот других задач, которые требуют много ресурсов и плохо распараллеливаются больше вы и не назовете!!!

А про аналитические вычисления я уж совсем молчу...

>10GbE хочется, да? :)

>Для простого GbE PCI-X ни разу не узкая, особенно если использовать Jumbo Frames...

Именно. Какое там у десетигигабитки latency ?

Ethernet годится как среда передачи только для low cost решений

2sS: Похоже мы пытаемся доказать друг-другу одно и тоже, тебе не кажется? :)

Irsi (*) (24.06.2004 12:11:19):

> Ага, согласен... Надо мне было сразу пояснить что я назвал "классическим" кластером. Это кучка писюков с линухом и Eth, воткнутых в коммутатор... Вообщем не обязательно писюков - XServe Cluster Node тоже подходит под это определение, несмотря на то что не писюк и не с линуксом...:) А если отказываемся от Eth во всех его проявлениях, то сразу возникает вопрос стоимости...

(Ты будешь удивлен!;)

У меня под боком находится кластер для студентов, из писюков, под Линухом -- именно стандартные писюки, связанные eth, с расшаренными по nfs домашними директориями. 32 штуки, стоят себе в одной большой комнате, выполняя роль дисплейного класса.

Не совсем стандартные, правда, -- помимо eth они соединены InfiniBand'ом, и мамка специфическая, поскольку тама PCI-X стоят. Все это удвоило их цену -- но ТОЛЬКО удвоило.

По ночам, или во время каникул, вся эта штука изпользуется для HPC.

И тормозит именно шина!

Dselect (*) (24.06.2004 12:28:04):

> А про аналитические вычисления я уж совсем молчу...

В QFT аналитические вычисления вполне себе параллелятся (я имею в виду параллельную версию FORMa).

Как раз с помощью MPI ;)

>2sS: Похоже мы пытаемся доказать друг-другу одно и тоже, тебе не кажется? :)

Дык мы говорим про Top500 или про low cost HPC ? ;)

Кластеры они по любому рулят что там что сям, просто не нужно все в одну кучу мешать ... понятно что когда речь идет о тысячах узлов (и даже сотнях) использование low cost решений, которые возможно хороши при десятке узлов, мягко говоря сомнительно ....

Вы, я надеюсь, не ставите в серверы SCSI контроллеры на шине ISA ? ;)))

linux_newbe (*) (24.06.2004 1:28:18):

Полный бред.

Единственная осмысленная фраза:

> Оперативка точно не общая. По крайней мере не в той степени что на обычных однопроцессорниках.

Все остальное - просто бессмыслица.

>Единственная осмысленная фраза:

>> Оперативка точно не общая. По крайней мере не в той степени что на обычных однопроцессорниках.

А это разве не бред ? ;)

С ЧЕМ должна быть общая память на ОДНОПРОЦЕССОРНИКАХ ? ;)

Тем более что про DSM товарисч видимо не слышал ....

Не надо о грустном...

> В QFT аналитические вычисления вполне себе параллелятся (я имею в виду параллельную версию FORMa)

Да хрен там что параллелится, AFAIK, они просто считают разные диаграммки на разных узлах...

P.S.

FORM -- и без того глюкало немерянное, а уж parallel version...

> Насколько я понимаю, разница между многопроцессорным компьютером и кластером заключается в том, что в первом у всех процессоров общая память,

Вы неправильно понимаете... У SMP машины тоже может быть NUMA.

sS (Score: 156 MaxScore: 157) (*) (24.06.2004 15:29:09):

> А это разве не бред ? ;)

> С ЧЕМ должна быть общая память на ОДНОПРОЦЕССОРНИКАХ ? ;)

Верно!

Тоже бред :-)

Dselect (Score: 164 MaxScore: 172) (*) (24.06.2004 15:36:49):

>> В QFT аналитические вычисления вполне себе параллелятся (я имею в виду параллельную версию FORMa)

> Да хрен там что параллелится, AFAIK, они просто считают разные диаграммки на разных узлах...

1. Дык, шашечки, или ехать? Что посчитать-то нужно? Амплитуду, или абстрактный интеграл? Аналитическое вычисление амплитуды в теории возмущений прекрасно параллелится.

2. К тому же, там именно все параллелится. Каждая диаграммка считается на всех узлах.

2sS: ээээ... стоп, BigMac который не так уж давно занял имхо 3ю позицию в Топ500 использовал именно GbE...

>2sS: ээээ... стоп, BigMac который не так уж давно занял имхо 3ю позицию в Топ500 использовал именно GbE...

Gig-E Это вроде бы что то около 30-х мест

Я же не говорю что это СОВСЕМ нельзя использовать (сам его использую)

Просто все зависит от задачи. Для сильносвязанных задач (когда идет интенсивный обмен мелкими пакетами) имеются вполне ощутимые проблемы с latency (кстати я не сказал бы что Linpack уж очень сильно чувствителен к этому показателю). В любом случае бюджет то не резиновый вот народ и выбирает между быстрой средой передачи и производительностью единичного узла

2Irsi

Держи ссылку

http://www.top500.org/sublist/index.php?vendor=%25&country=%25&app=%2...

Вот более точный список (примерно 1/3 из 500 начиная с 31 места)

http://www.top500.org/sublist/index.php?vendor=%25&country=%25&app=%2...

> Дык, шашечки, или ехать? Что посчитать-то нужно?

Функцию Грина. Получить для нее _вменяемый_ ответ, без громадных кусков, которые оказываются хитро записанными нулями или единичками. ( a la \frac{a^2}{(a-b)^2} - 2 \frac{a b}{(a-b)^2} + \frac{b^2}{(a-b)^2} )

> Аналитическое вычисление амплитуды в теории возмущений прекрасно параллелится.

Многие алгоритмы -- рекурсивные, и распараллеливаются тяжко. По ходу дела оказывается, что разные узлы считают один и тот же интеграл, который в ответ вообще не входит -- сокращается при суммировании разных кусков...

2Dselect (*) (24.06.2004 18:35:47):

Н-да...

А еще неплохо бы, чтобы оно само статью написАло, и само ее заслало в нужный журнал, и само от нападок рефери отбрыкалось. И все это -- параллельно...

:-)

нет определённо. встретить разбирающегося в железе математика умеющего распаралеивать алгоритмы - это просто несбыточная мечта какаято

да при чем тут "само"?

> А еще неплохо бы, чтобы оно само статью написАло,

Какое там -- этому %^&@скому FORM'-у сначала б научиться приводить подобные, потом -- приобрести более-менее человеческий pattern matching, а уж потом только -- параллелиться...

Dselect(24.06.2004 20:31:22):

> Какое там -- этому %^&@скому FORM'-у сначала б научиться приводить подобные, потом -- приобрести более-менее человеческий pattern matching, а уж потом только -- параллелиться...

Подобные он со швистом приводит, pattern matching у него гораздо более развитый чем, скажем, у Мапла.

Глюкав, зараза -- это есть.

Но альтернативы ему пока нет...

> Подобные он со швистом приводит

a/(a+b) + b/(a+b) -- выше его сил...

> pattern matching у него гораздо более развитый чем, скажем, у Мапла.

Давайте еще с xcalc'-ом сравним...

> Глюкав, зараза -- это есть.

Среднестатистический ответ (для любой задачи) -- segmentation fault :)

> Но альтернативы ему пока нет...

http://www.ginac.de/

2sS:
http://www.top500.org/list/2003/11/
Третья строчка в списке.

>http://www.top500.org/list/2003/11/

во первых это информация годовалой давности... а во вторых там Infiniband, а GigE там используется скорее всего как управляющая сеть (см например описание нашего МВС 1000М http://parallel.ru/computers/reviews/MVS1000M.html )

2 Dselect:

Между прочим, меня тут просветили: Phys. Rev. Lett. 88 (2002) 012001; Phys. Lett. B559 (2003) 245; Nucl. Phys. B604 (2001) 281; Phys. Rev. D67 (2003) 074026

ссылки на физические приложения, которые обсчитывались именно на ПАРАЛЛЕЛЬНОЙ версии Форма.

>> Но альтернативы ему пока нет...

> http://www.ginac.de/

Понятно...

Если для Ваших задач подходит Гинак, то, конечно, Вам Форм совершенно ни к чему. Ни параллельный, ни последовательный.

IMHO теперь, после 5 лет развития Гинака (и почти 10 Икслупса) с этой командой все ясно. Не было посчитано НИЧЕГО.

Кстати, Гинак задумывался как альтернатива Мапла для Икслупса. В те времена вышел Мапл 6, впоследствие вошедший в историю своей тормознутостью. И все бенчмарки Гинака, которые приводятся авторами, ссылаются именно на версию 6.

Пока Гинаковцы доводили свое творение до ума, появился Мапл 9, который работает не хуже Гинака.

>> Подобные он со швистом приводит

>a/(a+b) + b/(a+b) -- выше его сил...

Ну да, FORM -- мощный инструмент, специально заточенный под приведение миллионов слагаемых. Деноминаторы СПЕЦИАЛЬНО не разворачиваются, поскольку считаются одним членом, см. мануал и hep-ph/0007221.

Чтобы работать с деноминаторами, есть 2 пути.

Певый -- "в лоб":

s a,b,[a+b];

l s=a/(a+b)+b/(a+b);

id 1/(a+b)=1/[a+b];

id a=[a+b]-b;

print;

.end

Работает, но не всегда :)

Второй способ, "штатный", состоит в явном обозначении деноминаторов и использовании ratio:

s a,b,[a+b];

l s=a/[a+b]+b/[a+b];

ratio a,[a+b],b;

print;

.end

2sS: ну все-таки полугодовалой, и там используется именно GbE... Ибо это было собрано на обычных десктопных маках. :) Могу ролик кинуть, где рассказывается как все это делалось. :)

Irsi (Score: 59 MaxScore: 182) (*) (25.06.2004 13:51:15):

> ...и там используется именно GbE...

Ну сходи по своей же ссылке!

http://computing.vt.edu/research_computing/terascale/pressrelease.html

"They are ambitiously designing a large 64-bit InfiniBand cluster using existing,..."

"Cisco's Gigabit Ethernet switches were the choice for the secondary communications fabric to interconnect the cluster."

> Деноминаторы СПЕЦИАЛЬНО не разворачиваются

Та я знаю, что по мнению автора that's not a bug, that's a feature. Именно поэтому FORM идет лесом...

> Пока Гинаковцы доводили свое творение до ума, появился Мапл 9, который работает не хуже Гинака.

Хуже. Ибо основная претензия к мапля -- отнюдь не скорость, а @#$утый на всю голову язык.

> Чтобы работать с деноминаторами, есть 2 пути.

> Певый -- "в лоб":

Не катит. Ни первый, ни второй. Я заранее их не знаю, они по ходу вычисления появляются ( как появляются -- это уже другая история, см., напр. Nucl. Phys. B397(1993) 123-142 )

> IMHO теперь, после 5 лет развития Гинака (и почти 10 Икслупса) с этой командой все ясно. Не было посчитано НИЧЕГО.

Библиотеку они написали, работать со спецфункциями ( multiple polylogs ) хотя бы как GiNaC мало какая зараза умеет. Что еще от них надо?

А то, что господа физики на любом языке пытаются писать на FORTRAN'-е... дык кто ж им доктор...

Dselect (*) (25.06.2004 17:45:41):

> Не катит. Ни первый, ни второй. Я заранее их не знаю, они по ходу вычисления появляются ( как появляются -- это уже другая история, см., напр. Nucl. Phys. B397(1993) 123-142 )

Да уж...

Вами приведен классический пример, когда это как раз КАТИТ.

> Библиотеку они написали, работать со спецфункциями ( multiple polylogs ) хотя бы как GiNaC мало какая зараза умеет. Что еще от них надо?

IMHO Гинак -- довольно-таки неуклюжая умирающая (по техническим причинам) поделка, единственное преимущество которой -- GPL лицензия.

Ну, да ладно -- каждый выбирает, как он хочет. ;)

> Вами приведен классический пример, когда это как раз КАТИТ.

Таки не катит. Бо получается что-нибудь вроде

m1^4/(m1^2 - m2^2 +m3^2)^2 + m2^4/(m1^2 - m2^2 + m3^2)^2 + etc.,

что в конце концов -- либо ноль, либо просто число порядка единички...

GiNaC'-у надо всего лишь сказать

blah = blah.normal();

а с FORM'-ом -- долго и нудно иметь секс, глядя на промежуточные выражения и пытаясь подобрать pattern, который это чудо сможет понять... > IMHO Гинак -- довольно-таки неуклюжая

Всяко лучше, чем FORM.

> единственное преимущество которой -- GPL лицензия

А вот это -- недостаток, а не преимущество.

Dselect (*) (25.06.2004 20:36:14):

>> Вами приведен классический пример, когда это как раз КАТИТ.

>Таки не катит. Бо получается что-нибудь вроде

>m1^4/(m1^2 - m2^2 +m3^2)^2 + m2^4/(m1^2 - m2^2 + m3^2)^2 + etc.,

>что в конце концов -- либо ноль, либо просто число порядка единички...

Ну, в местных кругах на такое принято отвечать -- RTFM! Но, вообще-то, тут это -- оффтопик.

Подытоживая нашу дискуссию, замечу, что я уже оговаривался: ЕСЛИ Вам хватает Гинака, то Форм Вам просто не нужен. Безотносительно достоинств/недостатков.

Это примерно как сравнивать писюк и телевизор (а что? И там, и там можно кино смотреть!).

Гинак никак не может быть альтернативой Форму: Форм заточен на вычисления процессов, состоящих из тысяч (иногда десятков тысяч) интегралов, а Гинак писался для Икслупса, который предназначался для ковыряния с мастерами.

(2All: прошу прощения за оффтопик, всего пара абзацев -- Dselect меня поймет.)

Например, Лапорта позволяет вам провести редукцию к мастерам совершенно алгоритмически. Хотя оригинальный алгоритм написан на Мапле, реальные вычисления выполняются на Форме (с привлечением внешних программ) -- сейчас реально "круто" считают Лапортой Шредер, Джакон (и поляки), Четыркин (и немцы), Веретин -- все на Форме! -- из прочих "классиков" мне известен лишь Мастролли, который не знает Форма -- дык, он и не посчитал ничего!

Вычисление мастеров -- совершенно другая история. Тут, конечно, можно юзать Гинак -- однако НИКТО его не юзает.Ваш любимый Давыдычев считает руками (как и Котиков). Бродхарст считает на Редьюсе. Четыркин и Смирнов считают на математике (и Пенин -- тоже). Кого еще из "классиков" забыл? (Все "бывшие" считали руками, поскольку компьютеров тогда не было)

завязываем с offtopic'-ом...

> Гинак никак не может быть альтернативой Форму: Форм заточен на вычисления процессов, состоящих из тысяч (иногда десятков тысяч)

Очень даже может: можно для этих интегралов написать весьма эффективный (всмысле использования памяти) тип данных ( ~ 4 short int'-ов, GiNaC::symbol, refcount -- и усе), все интегралы помещаются в RAM, и FORM... употребляет чупа-чупс... Особенно если потом из аналитического ответа хочется узнать числа...

> Тут, конечно, можно юзать Гинак -- однако НИКТО его не юзает

http://arxiv.org/abs/hep-ph/0110083

http://arxiv.org/abs/math-ph/0201011

> Кого еще из "классиков" забыл?

Грозина, который пользует Maxima, Reduce, или просто голый LISP :)

P.S.

2 All: sorry за offtopic, завязываю...

2 All: sorry за offtopic :)

Ну, не уходить же в talks из-за пары фраз!

2Dselect (*) (26.06.2004 17:17:58)

>> Тут, конечно, можно юзать Гинак -- однако НИКТО его не юзает

> http://arxiv.org/abs/hep-ph/0110083

Да уж...

Тама написано, что оно МОЖЕТ быть сделано (и БУДЕТ сделано) не только на Форме, но и на Гинаке.

Я немного в курсе этой деятельности.

Мох -- фанат Форма. Он все и считал (заметтье, они Вермасерена благодарят!) Но в силу природной глюкавости Форма проверки делались, действительно, на Гинаке (Вайнцирлем). А Увер писАл программки на Це и Фортране и всех проверял.

> http://arxiv.org/abs/math-ph/0201011

Чисто математическая работа, посвещенная вычислению разложений функций, встречающихся в мастерах. Выполнена фанатом ООП.

>> Кого еще из "классиков" забыл?

>Грозина, который пользует Maxima, Reduce, или просто голый LISP :)

Во-первых, Грозин IMHO не относится к классикам, замеченным в (систематических) вычислениях (важных) мастеров.

Во-вторых, хотя Грозин -- один из девелоперов Максимы, считает он В ОСНОВНОМ на Форме :-)

Да, самое интересное забыл откомментировать:

>> Гинак никак не может быть альтернативой Форму: Форм заточен на вычисления процессов, состоящих из тысяч (иногда десятков тысяч)

>Очень даже может: можно для этих интегралов написать весьма эффективный (всмысле использования памяти) тип данных ( ~ 4 short int'-ов, GiNaC::symbol, refcount -- и усе), все интегралы помещаются в RAM ...

Понятно...

Честное слово, внутреннее представление Форма -- ЗНАЧИТЕЛЬНО более экономное, чем Гинака.

Вам же не только ссылаться на данные, но и работать еще с ними надо?

А, между тем, на 64-битной платформе ВСЯ информация о символе, необходимая для внутреннего представления данных в Форме, поместится в размере, эквивалентном (скрытому) полю, требуемому для указателя на VMT.

И, все равно, главная проблема -- диск.

2 Гб RAM'а на процессор НЕ ХВАТАЕТ.