Приветствуйте новую архитектуру процессоров от AMD: K10

>Кстати, а почему Ксеоны _ТРЕБУЮТ_ FB? Они ее _поддерживают_!

Есть другой приемлимый вариант для Xeon'ов?

>стали кричать про то, что рулит не голая производительность, а нормированная на энергопотребление (на серверах с водяным охлаждением это особенно актуально ;) )

А причём тут потребление к охлаждению? Вы потребление с тепловыделением не путаете?

>Приятель рулит кластером па пару сотен нодов, на Ксеонах - никаких жалоб. Уверяю, все нагружено по самые помидоры.

Какая ФС? x86 или x86_64? Если не учитывать потребление и нагрев, то на 32bit Xeon'ы нормально работают... вот только неэффективно это: оверхед начиная с 768М RAM, серъёзный оверхед начиная с 4Г RAM, использование в два раза меньше регистров, оверхед на PIC коде (при каждом входе в функцию) и т.д. :(

>Каждая третья задача, распаралеленная больше, чем на 10 корок, падает; файлуха глючит;

какая "файлуха" - так и не сказали :(

А итаники вы зря сюда приплели. С таким же успехом можно было сравнивать с SPARC'ами, Alpha'ми и т.д.:)

> Топология задачи соответсвует топологии супркомпьютера?

Звезда

> Вы потребление с тепловыделением не путаете?

Понял. Вопросов больше нет! :-)

>Понял. Вопросов больше нет! :-)

Ну, если для тебя количество сожранных киловат для решения единичной задачи роли не играет и электроэнергия бесплатная (лишь бы воды побольше нагреть), тогда и и у меня "вопросов больше нет":)

>> ...когда время выполнения начнёт расти ...

>Ну, и я про что! К Амдалю это отношения не имеет -- там асимптота.

>А в реальности все обычно ОЧЕНЬ сильно флюктуирует.

Прямое отношение. Последовательная задача делится на часть A поддерживающую идеальное рапараллеливание, и часть B - не поддерживающую. Тогда увеличение количества узлов в системе приводит к тому, что часть B ограничивает ускорение. На практике часть A составляют большую часть целого (скажем 98%) и эта часть уменьшается с ростом числа узлов (скажем до 30%). Ускорение будет иметь вид горба, асимптота недостижима на количестве узлов в 16-32-64, т.е. для таких маленьких систем, что мы обсуждаем.

>> Топология задачи соответсвует топологии супркомпьютера?

> Звезда

Т.е. топология задачи не соответствует топологии суперкомпьютера (я не знаю суперов с топологией звезда, хотя может и есть). В любом случае - звезда не масштабируема => возможны проблемы с bootleneck. А Xeon кластер собран по звезде? Если да, то опять Ininiband не при чём ;-).

> Ускорение будет иметь вид горба, асимптота недостижима

Первая часть этого предложения противоречит второй.

Вот тебе закон Амдаля:

S=1/(a+(1-a)/p), где a -- нераспараллеливаеемая доля алгоритма, p -- число процессоров.

Предел при p стремящемся к бесконечности равен 1/a, это и есть Амдалевская асимптота. При a стремящемся к 0 асимтота убегает на бесконечность, и мы получаем линейный рост.

Никакого горба в законе Амдаля нет.

А в реальной жизни есть. И связян он с насышением коммуникационной среды.

> Т.е. топология задачи не соответствует топологии суперкомпьютера ... возможны проблемы с bootleneck. ...

Н-да...

Во времена токенрингов кластеры вязали кольцами или торами, но сейчас практически все свичи являются звездами. Простые кластеры обычно топологически являются "кликой" или звездой (если траффик идет через сервер -- нас этот случай не интересует).

Специализированные суперкомпы обычно имеют вид многомерного тора.

А суперкомпьютеры общего назначнения (о которых я и говорю) вяжутся "Фат Три", иногда -- в несколько плоскостей. Для такой топологии необходимо наличие динамической балансировки, которая у ИнфиниБэнда отсутствует.

> Никакого горба в законе Амдаля нет. А в реальной жизни есть. И связян он с насышением коммуникационной среды.

Класс! Несмотря на различие в терминологии (будем считать, что это я напутал, всё-таки теорию я учил очень давно), горб в ускорении мы всё-таки нашли и в причинах его появления у нас полное согласие.

Теперь вопрос. Есть две системы и одинаковая задача. На одной системе (скажем А) максимум горба для 16 узлов, на другой (скажем Б) - для 64. Топология систем одинакова. Узлы разные. Выводы?

Мои такие:

Либо узел системы А - быстрее. либо линк системы А медленнее.

Уточним задачу. Где-то вверху сказано - системы А и Б построены на принципиально одинаковой сети (здесь имеется ввиду одинаковые задержка и пропускная способность). Выводы?

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

> Н-да...

> Во времена токенрингов кластеры вязали кольцами или торами, но сейчас практически все свичи являются звездами. Простые кластеры обычно топологически являются "кликой" или звездой (если траффик идет через сервер -- нас этот случай не интересует).

> Специализированные суперкомпы обычно имеют вид многомерного тора.

> А суперкомпьютеры общего назначнения (о которых я и говорю) вяжутся "Фат Три", иногда -- в несколько плоскостей. Для такой топологии необходимо наличие динамической балансировки, которая у ИнфиниБэнда отсутствует.

Ты сегодня какой-то другой, лексион с попсового сменил на научный, выспался что-ли?

Здесь согласен абсолютно со всем. За исключением того, что меня учили иерархические топологии на базе коммутаторов называть "деревьями" - а не "звездой" (Дерево - масштабируется, а звезда - нет). В случае с "Fat Tree", суть лишь в том, что некоторые связи дублируются, что увеличивает пропускную способность.

Правильно ли я понял, что под динамической балансировкой понимается Forwarding?

Возвращаясь в русло беседы. Так в чем же разница коммуникационной системы между кластером с Xeon и кластером с Barcelona?

> Теперь вопрос. Есть две системы и одинаковая задача. На одной системе (скажем А) максимум горба для 16 узлов, на другой (скажем Б) - для 64. Топология систем одинакова. Узлы разные. Выводы?

Сейчас проясню ( в следующем посте).

> Либо узел системы А - быстрее.

И кто-то мне тут про Амдаля впаривал? :-) НИКАК скорость узла на все это повлиять не может!

> либо линк системы А медленнее.

Н-да...

Формула Амдаля давно уточнена на такие случаи (лень искать), но, уверяю, там тоже горба нет!

ИнфиниБэнд изначально задумывался как альтернатива перифирийным шинам. В результате, производительность ИнфиниБэнд им не уступает. Более того, в некоторых аспектах (например, пропускная способность) ИнфиниБэнд вполне сравним с фрондсайд шинами и гипертранспортными туннелями.

Это значит, что процессор является неотъемлемой частью коммуникационной среды; более того, в некоторых аспектах -- определяющей.

> Правильно ли я понял, что под динамической балансировкой понимается Forwarding?

Тут я тебя не понял...

Разумеется, форвардинг, вот только куда?

ИнфиниБэндовский свитч не предусматривает динамической маршрутизации -- просто протокол не позволяет! Если "толстодеревянный" кусок в момент загрузки системы вдруг выбрал слишком перегруженную (в дельнейшем) ветку -- все!

Поэтому и проблемы с масштабированием: если бы я масштабировался на ПУСТОМ кластере, то все было бы в порядке, несмотря на звезду: в кластере 3000 корок, а мне надо только 64!

Но в реале некоторые каналы моей звезды оказываются зашумленными конкурентами, которых не было бы в случае СМП или сеток с хорошей балансировкой (типа КвариксНет2).

Насчет СМП: Гипертранспорт -- отнюдь не СМП! Это к НУМА ближе!

>> Либо узел системы А - быстрее.

> НИКАК скорость узла на все это повлиять не может!

Видимо я начал впадать в маразм. Проверяй:

Пусть последовательная задача выполняется за время T1 = x1 + b1 (части хорошо и плохо распараллеливающиеся);

Примем для простоты линейную сложность коммуникационных задержек от размера системы (это узкое место, но сейчас нам это не важно);

Тогда время выполнения задачи на n узлах Tn = x1/n + b1 + a1 n;

Ускорение есть S = T1 / Tn = T1 / ( x1/n + b1 + a1 n ) = T1 / ( T1/n + (n-1)/n b1 + a1 n^2/n ) = n / ( 1 + [ b1(n-1)/T1 + a1 n^2 /T1 ] )

Проверяем. Если программа идеально параллелится и задержек нет, то b1 = 0, a1 = 0, S = n. Если задержки есть S = n / ( 1 + a1n^2/T1 ). Всё OK.

Когда ускорение на одинаковом количестве узлов больше? Тогда, когда выражение в [] меньше, т.е. b1(n-1)/T1 + a1 n^2 / T1 меньше.

Отношение b1/T1 на разных процессорах не меняется => первое слагаемое констатнта на разных системах.

a1 n^2 / T1 меньше, если a1 меньше или T1 больше.

Вывод: Ускорение больше, если сеть лучше или узел хуже.

Ну, может и напортачил где. Но интуитивно чуствую где-то так.

> ИнфиниБэнд изначально задумывался как альтернатива перифирийным шинам. В результате, производительность ИнфиниБэнд им не уступает. Более того, в некоторых аспектах (например, пропускная способность) ИнфиниБэнд вполне сравним с фрондсайд шинами и гипертранспортными туннелями. Это значит, что процессор является неотъемлемой частью коммуникационной среды; более того, в некоторых аспектах -- определяющей.

Ты как шпион, дозируешь информацию, типа дагадывайся сам что у нас и как. У вас видимо происходит участие вычислительного процессора в коммуникационных операциях. Бывает, что на bi-процессорных узлах один из процессоров выполняет только функции коммуникатора.

> ИнфиниБэндовский свитч не предусматривает динамической маршрутизации

Теперь и это понял. Речь идёт о том, что при передаче по продублированному линку, выбор происходит случано. Я привык динамическую балансировку связывать с нагрузкой, а не маршрутизацией. Но мне казалось что оба кластера обладают этой проблемой.

У меня сложилось впечатление, что сравнивался сильно загруженный AMD-based кластер с полупустым Xeon-based кластером. Или вообще результаты мастабирования случайны.

> У меня сложилось впечатление, что сравнивался сильно загруженный AMD-based кластер с полупустым Xeon-based кластером.

"Ты знал, ты знал!" :-)

Я и не скрывал этого, BTW!

Только, вообще-то, то было сравнение нашего суперкомпьютера на АМД в пику "толстым" кластерам на Ксеонах в пару сотен узлов... На том кластере, что мы купим, будет крутиться ТОЛЬКО наша задача!

А реально я могу сравнивать с двумя "базовыми" архитектурами:

1. Альтикс о 32 головах (вообще-то, оно -- СМП, но базируется на той же Full Fat Tree топологии (правда, двухплоскостной) и ccNUMA.

2. Прeдшественник -- кластер о 300 Итаниках под Квадриксом (у QcNETII с балансировкой проблем нету).

И вот, я вижу, что две последние при ТОЙ ЖЕ САМОЙ ТОПОЛОГИИ ЗАДАЧИ масштабируются по самое нехочу.

Гы, запутал... Респект!

Завтра разберусь. В Амдале НЕТ скорости узла, факт! Просто в формулу не входит...

В твоей формуле, даже если положить a1=0 (будет соответствовать Амдалю), будет зависимость... Мне сейчас неохота разбираться: с пары пива и не то сообразишь. Завтра на свежую голову отвечу, -- или сам пойми, в чем проблема! :-)

> В твоей формуле, даже если положить a1=0 (будет соответствовать Амдалю), будет зависимость...

??? От узла зависеть не будет. Этот как раз самое важное. Смотри:

S = n / ( 1 + b1(n-1)/T1 );

В этой формуле нужно положить, что вся задача есть 1 (или 100%), т.е. 1 = T1 = x1 + b1. Если при этом количество узов n обозначить p, а непараллельную часть b1 обозначить a, то

S = p / ( 1 + a( p-1 ) / 1 ) = 1 / ( a + (1-a)/p ) - цитированный тобой закон Амдала.

Ну а поскольку b1/T1 зависит только от задачи (это просто процент плохо параллельной части), то при a1 = 0 получим частный случай закона без коммкникаций.

Непонимание появилось потому, что ты законом Амдала называешь только эту формулу, а я - методику расчёта поведения задачи фиксированного размера на компьютерной системе с увеличивающимся числом узлов. Сам Амдал к формуле имеет отношение косвенное, и скорее закон должен быть "имени Амдала". Кстати, ещё интереснее, если вместо линейной положить более "кластерную" модель передачи сообщений, где латентность передачи зависит от вычислительного узла. Но это как-нибудь в другой раз ...

Понятно -- ты про "формальную модель ускорения".Ее обычно так записывают:

S=T1/[ (a+(1-a)/p)T1 +tc]

где tc -- общее время, требуемое для подготовки данных.

Эта формула получается из твоей при tc=a1*p, что, как ты сам заметил, совершенно не соответствует действительности, хотя горб эта штука, действительно, выдает для любой возрастающей tc(p).

Но я никогда не слыхал, чтобы ее называли "законом Амдаля". Обычно под Амдалем как раз и понимают "идеальный" случай, когда tc=0.

> У вас видимо происходит участие вычислительного процессора в коммуникационных операциях.

Не _у_нас_!

Если под "вычислительным процессором" понимать железяку CPU, а не арифметическое устройство, то участие вычислительного процессора в коммуникационных операциях происходит _у всех_! Всегда!

Когда ты что-то навычислял, то оно лежит в процессорном кыше, и ты должен это дело передать куда-то. Для начала в память, хотя бы. Если это Оптерон, то процессор погоняет циферки по своим кышам, щелкнет кроссбар свитчем и отдаст данные гипертранспорту. Если это Ксеон, то данные начнут толкаться в северный мост.

Потом ты попросишь процессор передать эти данные на другой узел. Результат опять будет сильно зависеть от конкретного процессора, но в конце концов данные окажутся на перефирийной шине, на которой сидит сетевая карта. Карты и сами сети сейчас довольно шустрые, поэтому время, которое данные будут перекачиваться на другую карту будет вполне сопоставимо с тем временем, которое данные будут путешествовать по памяти и кышам процессоров.