Intel x48-cores. Ховайся, кто может. Они наступают

мда. если процессорыы будующего будут расти только за счет ядер - ничего хорошего не будет

Всё к этому и идёт. Не зря же зашевелились с ОпенЦЛем тем же.

Будет много небыстрых ядер, а алгоритмы параллельные или конвееризуемые...

Будем надеяться, что Java на них тормозить не будет

вот это как раз не правильный путь развития

не должны мы тупо увеличивать кол-во ядер

система дожна становится гетерогенной, включать разные виды вычеслительных блоков. Оптимизирвоаться под них и тд

да и сами проце бы ускорить. а то говорять эльбрус на 300 Мгц рвет пень в 2 ГГц

А у кого в алгоритме плохо с паралеллизмом - тому не повезло. =))

>говорять эльбрус на 300 Мгц рвет пень в 2 ГГц

кто говорит?

говорять что кур доять... у эльбруса есть только один шанс нанести сокрушительное поражение текущим монстрам процессоростроения - если этот эльбрус увидит директор интела то лопнет со смеху.

> А у кого в алгоритме плохо с паралеллизмом - тому не повезло. =))
как я вовремя начал изучать erlang :)

>а то говорять эльбрус на 300 Мгц рвет пень в 2 ГГц

а я слышал, что один Рэмбо может всю армию перебить

Мал клоп, да вонюч.

Белка - тоже существо малогабаритное, а вот шуму от нее много.

а я слышал, что один Рэмбо может всю армию перебить

Чо слышал - я это собственными глазами видел! Помню, ещё по телевизору его спецоперации транслировали. Так китайсы с медведями в ушанках только так отлетали налево и направо. Жаль только в годах он уже, Рембо. Не потянет уже наверное целую свалить - и на половину не хватит. Эх! Не рожат земля заморская больше таких обгатырей, не рожат. На то и надежда наша.

С Чаком Норрисом не путаешь?

они говорят. но это так я сказал. просто я считаю что не только в ширь надо, но и в глубь

Рэмбо кладет армию из обычных солдат, а Чак Норрис армию из Рэмбо.

> Мал клоп, да вонюч.

интересно, а кто вонючей: перегретый intel или перегретый эльбрус?

>просто я считаю что не только в ширь надо, но и в глубь

просто считать и выпускать коммерчески успешный продукт - две разные вещи
над вопросом дальнейшего развития архитектуры старательно думает (за немалую зарплату) не один десяток умных людей

Скоро выйдет nvidia fermi, который порвет этот intel как тузик грелку.

оно сможет испольнять код любой сложности или как всегда?

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

>48 ядер суммарно расходуют не более 25 Вт в режиме ожидания и 125 Вт при максимальной производительности

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

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

Эмм.. Простите, а вот скажем в моём кваде. Да. Вот в нём тоже есть одно Правильное Ядро и три неправильных?

И сколько программ могут заюзать все 4 твои ядра на 100% и чтоб прирост был производительности был 400% ?

Судя по анонсам у них с этим большой прогресс. Заявлена поддержка виртуальных функций в GPU-коде(видимо настоящие jump-ы) и вообще чуть ли не настоящий C++(включая эксэпшены) в компиляторе.

И сколько программ могут заюзать все 4 твои ядра на 100% и чтоб прирост был производительности был 400% ?

Мммм... а причем тут программы? Я так понял, что есть кошерные ядра а есть некошерные, правда?

Можно подумать сабж может исполнять код любой сложности на всех ядрах.

Причем я так понял что это собственно ограничения процессора? Вот я и интересуюсь, как мне отличить правильное ядро от неправильного. А то вдруг я чего не там запущу.

Это ограничение программ, а не процессора.

Это ограничение программ, а не процессора.

Ага. Ну то-есть к Интелу & K это отношения не имеет. Тут уж как девелуперы почешутся так и будет. Независимо от того, два у меня ядра или сорок два. Это уже лучше.

> Заявлена поддержка виртуальных функций в GPU-коде(видимо настоящие jump-ы) и вообще чуть ли не настоящий C++(включая эксэпшены) в компиляторе.

А вот это ВКУСНО

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

Теперь бы узнать размер кода, сложность jump'ов и условий, а так же размер стэка

и сколько ядер это могут делать сразу

ЗЫ: если jump'ы даже не настоящие, то явно уже не хроменькие как раньше

> Можно подумать сабж может исполнять код любой сложности на всех ядрах.

на любом ядре может быть исполнен сколь угодно сложный код

а на современном расчетном блоке GPU - нет

А бесполезно, большинство алгоритмов не поддаются распараллеливанию. А для тех, что поддаются, надо сильно тюнить работу с кешем, на 4х ядрах с этим проблемы возникают, а на 48 чую вообще песец будет.

А на хорошо распараллеливаемых алгоритмах nvidia будет рвать intel.

А бесполезно, большинство алгоритмов не поддаются распараллеливанию. А для тех, что поддаются, надо сильно тюнить работу с кешем, на 4х ядрах с этим проблемы возникают, а на 48 чую вообще песец будет.

Странно. Тогда я катастрофически не понимаю, как мои mysql/pgsql практически линейно скалируются на 4-8-16 ядер. По крайней мере с точки зрения конечной производительности. Наверное, внутри них есть какие-то совсем уже хитрые алгоритмы.

большинство задач очень хорошо паралеляться

с другой стороны мы почти обеспечены необходимой производительностью для 99% задач, которые не можем паралелить

Грубо говоря тут у тебя работает 16 копий одного и того же алгоритма никак не связанных между собой.

Очень хороший пример — умножение разреженной матрицы на вектор. Если взять самый распространенный формат CSR (как в матлабе) и в лоб делать уможение просто банально разнеся итерации в цикле по ядрам, то даже на двуядернике мы получим %уй, а не ускорение, а уж про большее число ядер я молчу. Вот так вот тривиальная задача, которая в теории распараллеливается просто отлично на деле превращается в страшный геморрой.

Грубо говоря тут у тебя работает 16 копий одного и того же алгоритма никак не связанных между собой.

Конечно, кто спорит. Работают в параллель. И я бы не отказался, если бы их было не 16ть (что уже дюже дорого) а 32 а то и 48. При этом за разумную цену и с приемлемым TCO. А то, что кто-то там матрицы не может посчитать - ну это печально конечно, но какое до них дело простым колхозникам.

хм. а не кажеться ли что оптимизация для однозадачности может привести к невозможности распралеливанияЯ?

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

как много в повседневной жизни таких алгоритмов?

В этом примере как раз многозадачность и все ядра будут грузиться на 100% и каждое ядро будет работать со своим куском данных, а на выходе все равно %уй, а не ускорение. Вот чудеса то!

В этой задаче проблема не в оптимизации под однозадачность, а в том, что ядра дольше тянут данные из памяти чем производят с ними действия. 4 ядра ломятся в одну шину памяти - получаем ускорение ~2, хотя ни кто не простаивает.

с другой стороны мы почти обеспечены необходимой производительностью для 99% задач,

Тогда зачем нам задачи вируальной реальности? Если уже 99% обеспечено?

Будущие ноутбуки, располагающие вычислительной мощностью такого процессора, смогут «воспринимать» окружающий мир так, как это делает человек, и адекватно реагировать на происходящее.

Представьте, что однажды Вы сможете брать у компьютера уроки танца или при помощи 3D-камеры пройтись по магазину одежды и примерить наряды. http://habrahabr.ru/company/intel/blog/77065

Ну у меня таких алгоритмов полно. Меня интересуют именно параллельные вычисления. Поэтому смотрю на fermi :)

И я бы не отказался, если бы их было не 16ть (что уже дюже дорого) а 32 а то и 48. При этом за разумную цену и с приемлемым TCO.

У вас такие быстрые диски что могут обеспечить данными 32 процесса? OMG!

RAID-0 из 32х дисков :)

> Задача с матрицам давно, естественно, решена, но её решение очень нетривиальное.

Скинь ссылку(CSR MvM), если не сложно. Задача очень интересует.

У вас такие быстрые диски что могут обеспечить данными 32 процесса? OMG!

Нет, просто у нас очень много памяти :) Впрочем, диски тоже ничего.

Мда, один диск может выдать 100Мб/сек, один проц может схавать 18Гб/сек. Налицо недогруз в 180 раз

2 раза будет если сильно повезет, а в общем случае ускорение будет в 1 раз :)

А чем fermi отличен? те же яйца, только сбоку

ЗЫ: наверно мы чуть о разном говорили. Я говорил вообще об распаралеливании при достаточно идеальной архитектуре.... В общем рассуждения, отдаленый от реальности

А данные у нас прямо из дисков в процессоры поступают? Оперативная память отсутствует? Современные объемы порой превосходят старые винчестеры...