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

Хмммм.... В таком случае нас ждет монополизм Интел без перспектив возниконовения альтернатив.... Разве что принудительно разделят Intel как когда-то AT&T.

Хотя есть надежда на IBM. Может купят AMD и помогут технологиями.

факты факты а не голословные заявления

>В пятницу нам на ней сделали наши тесты...

А где это до снятия NDA вы ухитрились раздобыть образец(-ы)? И какой был степпинг? (В ранних вообще половина фич отключена.)

И, кстати, что за "ваши" тесты? Если это реальные приложения (иначе почему вы называете их "вашими"?), то где гарантия, что их производительность вообще упирается в процессор?

> А где это до снятия NDA вы ухитрились раздобыть образец(-ы)?

Не МЫ -- фирмачи. Мы им только наши файлы и сырцы для бенчмарков предоставили (под то же NDA).

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

> ...где гарантия, что их производительность вообще упирается в процессор?

А вот тот-то и оно, что нет такой гаранти! Более того, зависимость производительности от процессора напрямую и не прослеживается обычно.

Поэтому мы и тестируем платформу целиком, прежде, чем покупать.

Пока что ситуация с АМД такова -- еще полгода назад готовые решения ИМЕЛИ проблемы. Эксллюзивные решения стоят на порядок дороже -- извини, я уж тогда Итаники предпочту. Последние месяца два-три базирущиеся на 8200 серии решения ведут себя совершенно достойно, но Ксеонам сливают (в кластерном варианте, разумеется -- Ксеоны больше 8 корок на СМП не масштабируются). Но Ксеонов за те же бабки можно прикупить (корок) в 1.5 раза больше! И каждая корка -- процентов на 10 шустрее по целым и почти в 1.5 раза -- по ФП.

Мы честно ждали Барселону месяца 3 -- нам клятвенно обещали "на следующей неделе"... Дождались! :-(

> а чем оно лучше спектрума?

чем лучше - трудно сказать, времени убивается все равно примерно одинаковое количество, хоть там Z80 хоть Opteron о четырех ядрах. А вот чем хуже - сразу понятно - энергопотреблением. Этим мы приближаем срок не только Вендекапца, а и глобального Цивили- Капца !

>На серверах я понимаю зачем 4 ядра. А домой мне и двух будет много.

Тебе на винде нужен один но на 20ГГц. А многоядерность... Что в венде с нею делать-то?

> Но Ксеонов за те же бабки можно прикупить (корок) в 1.5 раза больше! И каждая корка -- процентов на 10 шустрее по целым и почти в 1.5 раза -- по ФП.

Это тех ксеонов, для которых FB-DIMM'ы стОят немерянных денег? Это те FB-DIMM'ы, которые чуть подгрузишь и они нагреются до 35 гр.С - начинают глючить неимоверно? Нет уж - нафиг-нафиг:)

Нечем у AMD в ближайшее время ответить сколь-нибудь достойно на Core 2, все специалисты в один голос это утверждают. И в "Барселоне" не так уж и много архитектурных нововведений, которые должны были это отставание уменьшить. Может с Оптеронами что-то и придумают, но на десктопах - в ближайшее время там будет править Интел...

> факты факты а не голословные заявления

:-) Только на веру пока!

Факты:

Оптероны имеют самую "сильную" модель обращения к памяти. Если вы посмотрите на какую-нибудь "atomic library", вы с удивлением увидите, что в разделах АМД везде сидят заглушки. Т.е., Оптерон (и Атлон, есснно) ВООБЩЕ не умеет перераспределять обращения к памяти.

Ксеоны ЧУТЬ получше на опережение читают.

Про Барселону я не в курсе.

Из современных архитектур самая "навороченная" по этой части -- Итаник. Мало того, что она очень "слабая", она еще три пареллельных конвейера держит. Поэтому при равной тактовой частоте он была бы процентов на 20-30 шустрее АМД (по целым; по ФП -- значительно больше; на синтетических тестах -- в 2-3 раза шустрее).

Непревзойденной была Альфа -- самая "слабая" память, самая сложная из СМП архитектур! Увы, сдохла...

К чему это я?

В свое время АМД сделала очень удачный ход: "усилила" свою модель обращения к памяти, что позволило им выйти в лидеры в гигагерцовой гонке.

Теперь они ввели Л3 кыш... Явно маркетинговый ход! Икс86 НЕ СУЖДЕНО иметь трехуровневый кыш! Она для этого слишком примитивна, латенси все сожрет!

Впрочем, кто знает... Мне всегда АМД импонировали.

> Это тех ксеонов, для которых FB-DIMM'ы стОят немерянных денег?

Про деньги -- я говорил про стоимость РЕШЕНИЯ: сюда включаются и процессоры, и Диммы, и чипсеты, и Ethernet, и ИнфиниБэнд карточки со свичами, и диски, и железяки для управления терминалами/в том числе по сети, и техподдержка...

> Это те FB-DIMM'ы, которые чуть подгрузишь и они нагреются до 35 гр.С - начинают глючить неимоверно? Нет уж - нафиг-нафиг:)

Наверное, тебе просто не повезло:-)

> Теперь они ввели Л3 кыш... Явно маркетинговый ход! Икс86 НЕ СУЖДЕНО иметь трехуровневый кыш! Она для этого слишком примитивна, латенси все сожрет!

Сбили меня предыдущие ораторы...

s/латенси/инвалидация/

>Наверное, тебе просто не повезло:-)

Наверное, ты просто их не загружаешь. Или не обслуживаешь кластер на пару сотен нодов:)

А ещё у FB-DIMM латентность немерянная. Из-за этого и выше сказанного Intel и отказывается от FB-DIMM вобще (только об этом они в рекламных роликах не кричат громко:))

>Наверное, ты просто их не загружаешь. Или не обслуживаешь кластер на пару сотен нодов:)

А позвольте вопрос, для самообразования:) Как связан нагрев памяти с количеством узлов в кластере, ведь кластер в отличие от SMP и NUMA общей памяти не имеет? Т.е. Вы говорите о кластере на пару сотен нодов, а если например кластер на 20 нодов, то на нем не будет такой загрузки памяти? Почему Вы подчеркиваете именно большое количество узлов в кластере?

> Впрочем, кто знает... Мне всегда АМД импонировали.

У меня такое ощущение, что для "ваших тестов" вам же подсунули образец барселоны самого первого отладочного степпинга, что с конвейера сошёл. У народа что по сцылкам и на ixbt запостился (включая spec.org) - барселона болтается на уровне "равночастотного + сколько то" ксеона, в чём-то опережая, в чём-то сливая там где и раньше сливалось. И в работе с памятью рвёт коркодубные ксеоны как тузег грелку.

Но уж хуже то чем раньше было они процессор точно сделать не могли, а? Может чего в биос^W консерватории или поставщиках подкрутить?

>А позвольте вопрос, для самообразования:) Как связан нагрев памяти с количеством узлов в кластере

Температура. Охлаждение. 20 и 200 нодов в этом случае - существенная разница - они ж не в чистом поле стоят. И 35 гр. - это не очень большая тепрература для чипа, он не должен "спотыкаться" при ней. А про отношение к перспективам FB-DIMM самого Intel с недавних пор поищите - узнаете много интересного:)

>ведь кластер в отличие от SMP и NUMA общей памяти не имеет?

Но память всё равно используется, не так ли?:) И если разорились на недешёвое удовольствие в виде приличного кластера, то уж грузят его "на полную катушку" (даже электроподстанцию специально построили для него).

Можно ещё много "лестных слов" (зачастую - нецензурных) послушать про реализация в Интелах x86_64 - поищи на сайте разработчиков Lustre (а в кластерах без неё в большинстве случаев - никак) - они большее сотни багрепортов в Интел отправили.

> К9 - был проект по выпуску ответа на пень 4. Но так как ожидания не оправдались, проект был закрыт

Ой, таки знаток "эмэрикн ынглиш"! Бугага!!! :)) K9 означает на сленге... ну вообщем ... вариант близкий к термину "слакофилищще" (с). http://en.wikipedia.org/wiki/AMD_K9 :)))))

AMD давно уже "живой труп".

> чего это я буду учитывать то, чего нет?

Давненько спите, батенька. Чувствуется не заходили на overclockers ru. Не давеча как в прошлом году амдшные процессоры остались в пролете. Как по соотношению производительности на мегагерц так и по возможности разгона. Ничего, спите, такие как вы нам нужны. Кто же будет покупать лажовые амдшные процы, чтобы удержать амд на плаву, чтобы интел особо не борзел с ценами.

Кстати, а почему Ксеоны _ТРЕБУЮТ_ FB? Они ее _поддерживают_! АМД, кстати, тоже. В Барселоне они эту поддержку оставили, но "наружу" ее не вывели, и поначалу пообещали мигрировать на FB "со временем". Но теперь, когда побить корку 2 они не смогли, стали кричать про то, что рулит не голая производительность, а нормированная на энергопотребление (на серверах с водяным охлаждением это особенно актуально ;) ), отсюда и всякие маркетинговые опускания Интеловских технологий.

> Наверное, ты просто их не загружаешь. Или не обслуживаешь кластер на пару сотен нодов:)

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

Я сам Ксеоновские кластеры не видел. Рулить пока приходилось только АМДшными кластерами на пару-тройку десятков нод, и то -- на подхвате: моя зона ответственности --- СМП машины.

Много работал на кластере на 300 Итаниках под вторым Квадриксом -- только положительные впечатления!

Теперь приходится иметь дело с АМД кластером на 3000 вычислительных корок (750 нодов) под ИнфиниБэндом, впечатления совершенно отвратительные! Каждая третья задача, распаралеленная больше, чем на 10 корок, падает; файлуха глючит; больше 16 корок мои задачи не масштабируются (на Итаниковском кластере оно прилично пахало до 64, а на Ксеоновом кластере бенчмарки масштабировались тоже до 64).

Охлаждение, кстати, водяное.

>Теперь приходится иметь дело с АМД кластером на 3000 вычислительных корок (750 нодов) под ИнфиниБэндом, впечатления совершенно отвратительные! Каждая третья задача, распаралеленная больше, чем на 10 корок, падает; файлуха глючит; больше 16 корок мои задачи не масштабируются (на Итаниковском кластере оно прилично пахало до 64, а на Ксеоновом кластере бенчмарки масштабировались тоже до 64).

В переводе на нормальный язык это означает 2 двухпроцессорных ядра ? И что значит "больше 16 корок мои задачи не масштабируются ?" Может тогда станет ясно, почему эти задачи на ксеонах лучше масштабируются

Это значит, что больше 16 задач одновременно не тянет ?

> В переводе на нормальный язык это означает 2 двухпроцессорных ядра ?

Да, 750x(2x2)=3000 :)

Кстати, это только вычислительные ноды, Еще там 2 8-корковых логин нода, 8 четырехкорковых серверов и 10 четырехкорковых файлопомоек.

> Это значит, что больше 16 задач одновременно не тянет ? Нет. Задач оно потянет одновременно более трех тысяч :-).

> что значит "больше 16 корок мои задачи не масштабируются

Это значит, что параллельная распределенная задача с увеличением кол-ва ее тредов (процессов, поскольку речь идет о кластере) работает быстрее и быстрее, но только пока процессов не больше 16. Потом ускорения нет, а есть только замедление.

> Может тогда станет ясно, почему эти задачи на ксеонах лучше масштабируются

Я не говорил, что они на Ксеонах масштабируются лучше! Я говорил, что на Барселоне они масштабируются хуже!

> Я не говорил, что они на Ксеонах масштабируются лучше! Я говорил, что на Барселоне они масштабируются хуже!

Вообще -- да, говорил.

Я имел в виду данный конкретный кластер, и причину я знаю -- ИнфиниБэнд не справляется, поскольку у нее нет динамической балансировки. Мы это много обсуждали, тут от процессора ничего не зависит.

Проблема в надежности -- постоянно чего-то падает! И вот тут-то, возможно, виновата связка "процессор-память".

>> Я не говорил, что они на Ксеонах масштабируются лучше! Я говорил, что на Барселоне они масштабируются хуже!

>Я имел в виду данный конкретный кластер, и причину я знаю -- ИнфиниБэнд не справляется, поскольку у нее нет динамической балансировки. Мы это много обсуждали, тут от процессора ничего не зависит.

А я уже собирался цитировать :-)

>Проблема в надежности -- постоянно чего-то падает! И вот тут-то, возможно, виновата связка "процессор-память".

Если у вас есть проблемы с надежностью, с ФС то вряд ли это процессор виноват. Скорее виновата задача, шины, память, винты ... Радиация рядом с кластером...(Это не моя догадка)

Процессор последний в ряду возможных претендентов.

Возможно компилятор без руля что такое "барселона" и компилит код кривой для оных процов, но рабочий для предыдущего поколения?

> Это значит, что параллельная распределенная задача с увеличением кол-ва ее тредов (процессов, поскольку речь идет о кластере) работает быстрее и быстрее, но только пока процессов не больше 16. Потом ускорения нет, а есть только замедление.

Закон Амдала? Увеличить задачу?

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

Конечно!

Но меня-то интересует готовое решение. Я пока вижу, что решения на базе Итаников в десятки раз надежнее решений на базе АМД.

К сожалению, и в десятки раз дороже... :(

Про ненадежность решений на Ксеонах я слышал только один раз -- тут, вчера. Своего опыта пока нет, но скоро, наверное, появится...

> Возможно компилятор без руля что такое "барселона" и компилит код кривой для оных процов, но рабочий для предыдущего поколения?

Barcelona is NOT x86 compatible? В топку!

> Закон Амдала?

При чем тут закон Амдаля? Я же сравниваю с ТОЧНО ТАКОЙ ЖЕ задачей, "выполаживающейся" на другой архитектуре только после 64!

К тому же я наблюдаю на кластере явно выраженное ПАДЕНИЕ скорости, чего Амдаль вообще не предусматримает!

Ту проблему мы подробно обнюхивали Вампиром -- виновата ИнфиниБэнд, она на таких масштабах плохо тянет.

Зато дешево!

> При чем тут закон Амдаля? Я же сравниваю с ТОЧНО ТАКОЙ ЖЕ задачей, "выполаживающейся" на другой архитектуре только после 64!

Вы сравниваете одну и ту же задачу (программу), запускаемую на

1) AMD кластере с Infiniband,

2) Xeon кластере с ???.

Получаете ускорение скажем 12 на 1) и скажем 48 на 2).

Вы утверждаете, что Xeon кластер выполнен на какой-то революционной сетке с очень низкой задержкой и существенно большей пропускной способностью?

:-(

http://www.theinquirer.net/?article=42257

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

>Конечно! Но меня-то интересует готовое решение.

По моему говорить о готовых кластерных решениях несколько преждевременно и странно... По крайней мере для меня

>Про ненадежность решений на Ксеонах я слышал только один раз -- тут, вчера. Своего опыта пока нет, но скоро, наверное, появится...

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

> ...Вы сравниваете одну и ту же задачу (программу), запускаемую на

Давай на "Ты": так легче, уверяю...

Ежели ты понимаешь, что такое закон Амдаля, то твои слова лишены смысла. :-) Или объясни.

> Вы утверждаете, что Xeon кластер выполнен на какой-то революционной сетке с очень низкой задержкой и существенно большей пропускной способностью?

Я знаю, на чем был выполнен тот Ксеонный кластер! Извиняюсь, я просто не подумал, что это кому-то интересно -- он был "интерконнектед" ИнфиниБэндом, ДДР, 4-x. Стандартный 24-х портовый свитч -- что, есть варианты? :-)

Наш АМДшный кластер соединен той же технологией, но, разумеется, масштабы не те... И "fat tree" топология была заявлена -- вместо нее оказался тупой двухуровнеый комплекс свитчей с удвоением вперед... Настоящее Фат Трии на ИнфиниБэнде сделать нельзя! Увы:(

Ксеонный кластер был без нагрузки, но продемонстрировал масштабируемость до 64. Я понимаю, что в реальной суперкомпьютерной жизни такого не бывает -- но у нас-то БУДЕТ! Мы ж покупаем кластер для конкретной задачи!

:-(

http://www.theinquirer.net/?article=42257

:-)

>>Конечно! Но меня-то интересует готовое решение.

>По моему говорить о готовых кластерных решениях несколько преждевременно и странно... По крайней мере для меня

:-)

Фор хум хау!

> А про ненадежность решений от амд только от вас...

Гы... А Вы много слышали про кластеры на 3000 корках? Я просто сказал, что оно -- не стабильно! Личный опыт.

У нас тут в подвале -- толстый (в 30 нодов) АМДшный кластер, под Гигабитным Ethernet'ом, и все нормально... Пока не потребуется его для реальныых параллельных рассчетов юзать! -- не получается никак...:(

> Я с некоторых пор отвечаю за один грид...

Грид -- ни разу не HPC!

Я плохо понимаю слово "Грид" в данном контексте... Если речь идет о новомодном Церновском направлении -- да, согласен, много тут кластеров в этих рамках твориться -- но, извините, это немного не то. Это -- просто компы в стойках, соединенные гигабитным Ethernet'ом, на которые Внешние Дяди могут приткнуть свои Неспешные Задачи в свободное время...

Мы таких не пускаем из принципа, хотя и коллаборанты, и склоняют... У нас своих проблем хватает! :-)

>> Возможно компилятор без руля что такое "барселона" и компилит код кривой для оных процов, но рабочий для предыдущего поколения?

>Barcelona is NOT x86 compatible? В топку!

Ты всегда так кипятишься ? Он хотел сказать, что компиллятор не знает сейчас, что такое "барселона", и не может давать оптимальный для данного процессора код. А определенные улучшения в структуре комманд в этом процессоре все же есть.

>>>Конечно! Но меня-то интересует готовое решение.

>>По моему говорить о готовых кластерных решениях несколько преждевременно и странно... По крайней мере для меня

> :-)

А что ты понимаешь под готовым решением ?

>> ...Вы сравниваете одну и ту же задачу (программу), запускаемую на

> Давай на "Ты": так легче, уверяю...

>Ежели ты понимаешь, что такое закон Амдаля, то твои слова лишены

>смысла. :-) Или объясни.

Объясняю :). Я комментировал следующее замечание:

"Параллельная задача с увеличением кол-ва выч. узлов работает быстрее и быстрее, но только до определённого момента. Дальнейшее увеличение числа узлов приводит к замедлениию".

Смысл я оставил, но немного переформулировал. Я заметил, что это поведение характерно для любой задачи на любой аппаратуре, поскольку является следствием закона Амдала. Конечно, точка перегиба определяется соотношением скорости элементарного вычислителя к скорости элементарной передачи => Чем быстрее узел и хуже сетка, тем быстрее появится точка максимума на графе ускорения, но речь быле не о том.

> Наш АМДшный кластер соединен той же технологией

А вот это самое интересное! Если оба кластера - Infiniband со сравнимыми задержкой и пропускной способностью, то появление точки максимума на графе ускорения можно объяснить не худшей характеритикой сети, а лучшей характеристикой выч. узла (собственно, что и обсуждается в статье - молодцы AMD). Поскольку ты не объяснил характер задачи, что-либо более определенное сказать нельзя ;-).

>> А про ненадежность решений от амд только от вас...

>Гы... А Вы много слышали про кластеры на 3000 корках? Я просто сказал, что оно -- не стабильно! Личный опыт.

>У нас тут в подвале -- толстый (в 30 нодов) АМДшный кластер, под Гигабитным Ethernet'ом, и все нормально... Пока не потребуется его для реальныых параллельных рассчетов юзать! -- не получается никак...:(

Аргументация какая то разрозненная и логически не связанная. Не может размер кластера влиять на степень стабильности работы процессора... Наблюдение не объяснение. Это проблема софта или "коммутации" машин

Даже не хочется напоминать о куче разных кластеров из топ-500 сделланых на оптеронах, или в которых они использовались.

> А что ты понимаешь под готовым решением ?

:-)

Деньги есть -- купил!

Заранее заказал бенчмарки. Если по прибытии аппаратуры эти бенчмарки не прошли -- рекламация...

Разумеется, 24х7 обслуга -- практика показывает, иначе фирмачей не допинаешься, ежели что сдохнет... Все равно увильнут! Просто пришлют запчасти...

> Аргументация какая то разрозненная и логически не связанная. Не может размер кластера влиять на степень стабильности работы процессора... Наблюдение не объяснение. Это проблема софта или "коммутации" машин

Коли уж у нас тут такой разговор, я попробую встрять. Размер кластера не влияет на стабильность процессора. Размер кластера изменяет вероятность сбоя любого узла кластера. Очевидно, что если PC даёт один аппаратный сбой в год, то кластер из 360 таких PC будет давать сбой в день. Если первое - терпимо, то второе - нет. Другая проблема - увеличенный объём I/O и как следствие, повышенная вероятность сбоя системы ввода-вывода, и эта вероятность выше с ростом числа узлов. Ну дальше сами можете придумать, почему большой кластер сбоит чаще.

>> Я с некоторых пор отвечаю за один грид...

>Грид -- ни разу не HPC!

Есть разные реализации гридов. Сановская например больше заточена на реализацию той или иной детальной политики использования вычислительных ресурсов. Ты ставишь задания в очередь и они в какой том момент получают доступ к вычислительным ресурсам. Возможна реализация и паралельных вычислений. Например сборка проекта. Но главное здесь политика использования ресурсов.

Я хотел обратить внимание, что процессоры месяцами загружены, и все работает безотказно.

>> "Параллельная задача с увеличением кол-ва выч. узлов работает быстрее и быстрее, но только до определённого момента. Дальнейшее увеличение числа узлов приводит к замедлениию".

> Смысл я оставил, но немного переформулировал. Я заметил, что это поведение характерно для любой задачи на любой аппаратуре, поскольку является следствием закона Амдала. Конечно, точка перегиба определяется соотношением скорости элементарного вычислителя к скорости элементарной передачи => Чем быстрее узел и хуже сетка, тем быстрее появится точка максимума на графе ускорения, но речь быле не о том.

Ничего не понял! Про какую точку перегиба ты говоришь? У Амдаля -- асимптота!

> Если оба кластера - Infiniband со сравнимыми задержкой и пропускной способностью, то появление точки максимума на графе ускорения можно объяснить не худшей характеритикой сети, а лучшей характеристикой выч. узла ...

Один кластер -- нагруженный по самые баклацепторы суперкомпьютер. Второй кластер -- специально соединенные для наших бенчмарков несколько Ксеонов...

Спор ни о чем: я просто как-то всем сразу отвечаю...

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

Совершенно не связанное с первым утверждение: СМП в лице Барселоны сливает кластеру Ксеонов с тем же количеством корок, соединенных через ИнфиниБэнд.

>> А что ты понимаешь под готовым решением ?

>:-)

>Деньги есть -- купил!

>Заранее заказал бенчмарки. Если по прибытии аппаратуры эти бенчмарки не прошли -- рекламация...

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

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

>Размер кластера не влияет на стабильность процессора. Размер кластера изменяет вероятность сбоя любого узла кластера.

Мысль в общем понятна, но есть определенная статистика использования этих процессоров, и она никак не позволяет говорить о реальности такого объяснения. Ну и есть другие аргументы о качестве оптеронов, например топ-500 кластеров.

> Ничего не понял! Про какую точку перегиба ты говоришь? У Амдаля -- асимптота!

Берём параллельную задачу. Запускаем на одном узле. Засекаем время выполнения. Эту же задачу запускаем на двух узлах. Время выполнения уменьшилось. Запускаем на четырёх узлах. Время уменьшилось по сравнению с временем на двух. Продолжаем увеличивать количество узлов. Наступит момент (количество узлов N), когда время выполнения начнёт расти. Это и есть точка максимума ускорения. На разной аппаратуре N разное и тем больше, чем лучше выч. узел и/или хуже сеть.

> Один кластер -- нагруженный по самые баклацепторы суперкомпьютер. Второй кластер -- специально соединенные для наших бенчмарков несколько Ксеонов...

Этой информации не достаточно, чтобы делать выводы. Топология задачи соответсвует топологии супркомпьютера?

Если сеть одинакова (сравнимая задержка и сравнимая пропускная способность с одинаковым типом соединения), то в твоём случае однозначный вывод - узлы AMD кластера более производительны, чем узлы Xeon кластера.

> ИнфиниБэнд не тянет на больших масштабах (много сотен корок).

Ты несколько раз повторил эту фразу, но, хоть убей, я её не понимаю. Что мне мешает использовать Infiniband для конструирования решетки и решать сеточное уравнение с обменами только между соседями (накаких forwarding). Получу идеальное масштабирование хоть для 32K узлов. Про тянет-нетянет можно говорить только в котексте решаемой задачи (а значит определённом соотношении вычислений/обменов и определённой топологии обменов в алгоритме задачи). А про задачу ты вообще ещё ничего не сказал, вот я и гадаю ...

> Мысль в общем понятна, но есть определенная статистика использования этих процессоров, и она никак не позволяет говорить о реальности такого объяснения. Ну и есть другие аргументы о качестве оптеронов, например топ-500 кластеров.

Есть информация о количестве hardware failure для "типичного кластера из TOP-500"? Я регулярно работаю на двух суперкомпьютерах из верхних строчек TOP-500, и потому верю в реальность такого объяснения ;-).

Ясно, что речь не про Opteron - рассуждения можно обобщать. Но! BGL работает на 700 MHz, BGP - на 850 MHz. Меньше частота - легче охлаждать...

>Barcelona is NOT x86 compatible? В топку!

Xeon is NOT x86_64 compatible! В топку!

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

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

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