Ну. Если сказать по правде, мы их до сих пор тестим, но есть уже одна, ставшая очевидной, особенность: память не тянет два ядра. Ну не тянет и всё. У нас есть новый кластер, в котором стоит сколько-то блэйдов, в которые засунуты двухпроцессорные платы, на которых установлены двухядерные opteron'ы 285, к каждому из которых воткнуто по 4 гигабайта памяти и соединено это всё с внешним миром через Hyper Transport вот так вот:
внешний мир (в том числе и 1Gb медный ethernet) --HT-- cpu0 --2xHT-- cpu1
Делаем простейший тест (ну, на самом деле программа не такая уж и простая — это MG из NASA Parallel Benchmark) в следующей конфигурации: либо прибиваем 4 процесса этой задачи к одному узлу — на каждое ядро по процессу, либо 4 процесса на разные процессоры в двух разных блэйдах. В итоге первая конфигурация выдаёт 2700 попугаев, а вторая 4500. Вдумайтесь, взаимодействие через ethernet, которое гораздо менее эффективно, чем zerocopy на NUMA, да ещё в такой конфигурации, когда весь траффик протягивается через один линк, да ещё когда вместо оптимизированного протокола всё качается вычислтельно ёмким TCP, оказывается намного более эффективным.
Конечно, причина очевидна: два ядра конкурируют за один контроллер памяти. Когда же мы используем 4 контроллера и асинхронную доставку данных между ними, всё получается намного шустрее. Но возникает тогда вопрос: а какого фига нас заставляют покупать многоядерные процессоры, убеждая в том, что они обладают какой-то непревзойдённой производительностью? Право же, лучше бы вместо второго ядра добавили какой-нибудь логики, вроде DMA. Или энергопотребление бы снизили, просто ядра выкидывая.
Эх. Но что более всего удручает, так это то, куда навострили свою деятельность разработчики: засунуть в процессор ещё больше ядер, при этом никак не снизив конкуренцию за доступ к памяти. Ну да, ну да, у Intel есть общий кэш второго уровня, у AMD появиться кэш третьего, но это общий ресурс, да, наверное с несколькими банками. Да, AMD выведет это всё на два контроллера памяти, но зачем так сложно и энергонеэффективно? Если это не снимет проблему. Потому что по прежнему за 1 контроллер (даже если каким-то чудесным чудом удасться убедить Linux раскладывать адресные пространства так, чтобы они попадали под разные контроллеры памяти и в разные банки Lтретьего кэша) будут конкурировать два ядра.
А теперь, внимание, барабанная дробь и всё такое прочее, на сцену выкатываются процессоры с интегрироваными графическими ядрами. У меня возникает вопрос: а как же они в своих любимых SMP-конфигурациях с одной подсистемой обращения к памяти будут свои любимые ядра кормить данными? Зачем нам простаивающие (сколько там, если считать по попугаям?) 30% времени процессоры? Почему не сделать побольше простых процессоров, но с DMA и со своей памятью. Кстати, вы знаете, что BlueGene/L работает на процессорах для встраиваемой электроники?: )
Да даже если хочется Intel и AMD продавать решения на одном кристалле, почему бы просто не развести каждое ядро к своей памяти? Ну эффективнее же гораздо. Эх. Не понимаю я логику производителей. Тем более не понимаю логику тех, кто на всё это 'великолепие' тратит деньги, ибо недостатки очевидны.
Короче, все плохие, кроме IBM, которая в Cell'ах примерно так и сделала. Но опять же не понятно, это манакальное желание засунуть всё в один чип. Не, ну да, внешние шины они были долгое время медленными. Но сейчас же есть последовательные — безумно быстрые и энергии жрут мало, да ещё их можно спокойно через оптоволокно пускать.
Вот. Нет, конечно, второму ядру можно найти применение: виртуализация какая-нибудь, или, вот как в нашем случае, запускать все системные процессы на, например, чётных ядрах, а расчётные на нечётных, может будет выигрышь, процентов в 10, что не мало, в принципе, если время расчёта составляет 10 дней. Но всё равно, интуиция протестует против усложнения такой и без того непростой вещи, как процессор. Усложнение это, конечно, всего лишь количественное. Но… Хых. Всё-равно, транзисторы то переключаются, воздух греется, леднки тают, Америку топит, нации эммигрируют, нам на Урале жить становиться тесно: )
P.S. Тут сейчас, наверняка, придут и скажут, что мы сами дураки, что в x86-64 на то и придумано 16 регистров, чтобы разгружать во время вычислений подсистему памяти, и что компилятор надо оптимизирующий и правильный использовать. На что отвечу: использовали рекомендованный компилятор AMD — PGI. Intel'овский тоже пробовали, тщательно наблюдая за тем, чтобы он оптимизировал таки доступы в памяти. Результат одинаковый.
внешний мир (в том числе и 1Gb медный ethernet) --HT-- cpu0 --2xHT-- cpu1
Делаем простейший тест (ну, на самом деле программа не такая уж и простая — это MG из NASA Parallel Benchmark) в следующей конфигурации: либо прибиваем 4 процесса этой задачи к одному узлу — на каждое ядро по процессу, либо 4 процесса на разные процессоры в двух разных блэйдах. В итоге первая конфигурация выдаёт 2700 попугаев, а вторая 4500. Вдумайтесь, взаимодействие через ethernet, которое гораздо менее эффективно, чем zerocopy на NUMA, да ещё в такой конфигурации, когда весь траффик протягивается через один линк, да ещё когда вместо оптимизированного протокола всё качается вычислтельно ёмким TCP, оказывается намного более эффективным.
Конечно, причина очевидна: два ядра конкурируют за один контроллер памяти. Когда же мы используем 4 контроллера и асинхронную доставку данных между ними, всё получается намного шустрее. Но возникает тогда вопрос: а какого фига нас заставляют покупать многоядерные процессоры, убеждая в том, что они обладают какой-то непревзойдённой производительностью? Право же, лучше бы вместо второго ядра добавили какой-нибудь логики, вроде DMA. Или энергопотребление бы снизили, просто ядра выкидывая.
Эх. Но что более всего удручает, так это то, куда навострили свою деятельность разработчики: засунуть в процессор ещё больше ядер, при этом никак не снизив конкуренцию за доступ к памяти. Ну да, ну да, у Intel есть общий кэш второго уровня, у AMD появиться кэш третьего, но это общий ресурс, да, наверное с несколькими банками. Да, AMD выведет это всё на два контроллера памяти, но зачем так сложно и энергонеэффективно? Если это не снимет проблему. Потому что по прежнему за 1 контроллер (даже если каким-то чудесным чудом удасться убедить Linux раскладывать адресные пространства так, чтобы они попадали под разные контроллеры памяти и в разные банки Lтретьего кэша) будут конкурировать два ядра.
А теперь, внимание, барабанная дробь и всё такое прочее, на сцену выкатываются процессоры с интегрироваными графическими ядрами. У меня возникает вопрос: а как же они в своих любимых SMP-конфигурациях с одной подсистемой обращения к памяти будут свои любимые ядра кормить данными? Зачем нам простаивающие (сколько там, если считать по попугаям?) 30% времени процессоры? Почему не сделать побольше простых процессоров, но с DMA и со своей памятью. Кстати, вы знаете, что BlueGene/L работает на процессорах для встраиваемой электроники?: )
Да даже если хочется Intel и AMD продавать решения на одном кристалле, почему бы просто не развести каждое ядро к своей памяти? Ну эффективнее же гораздо. Эх. Не понимаю я логику производителей. Тем более не понимаю логику тех, кто на всё это 'великолепие' тратит деньги, ибо недостатки очевидны.
Короче, все плохие, кроме IBM, которая в Cell'ах примерно так и сделала. Но опять же не понятно, это манакальное желание засунуть всё в один чип. Не, ну да, внешние шины они были долгое время медленными. Но сейчас же есть последовательные — безумно быстрые и энергии жрут мало, да ещё их можно спокойно через оптоволокно пускать.
Вот. Нет, конечно, второму ядру можно найти применение: виртуализация какая-нибудь, или, вот как в нашем случае, запускать все системные процессы на, например, чётных ядрах, а расчётные на нечётных, может будет выигрышь, процентов в 10, что не мало, в принципе, если время расчёта составляет 10 дней. Но всё равно, интуиция протестует против усложнения такой и без того непростой вещи, как процессор. Усложнение это, конечно, всего лишь количественное. Но… Хых. Всё-равно, транзисторы то переключаются, воздух греется, леднки тают, Америку топит, нации эммигрируют, нам на Урале жить становиться тесно: )
P.S. Тут сейчас, наверняка, придут и скажут, что мы сами дураки, что в x86-64 на то и придумано 16 регистров, чтобы разгружать во время вычислений подсистему памяти, и что компилятор надо оптимизирующий и правильный использовать. На что отвечу: использовали рекомендованный компилятор AMD — PGI. Intel'овский тоже пробовали, тщательно наблюдая за тем, чтобы он оптимизировал таки доступы в памяти. Результат одинаковый.
