Рейтинг суперкомпьютеров top-500 возглавил кластер на ARM-процессорах

Стагнирующую монополию костыльного x86_64 нужно свергать.

Стагнирующую монополию костыльного x86_64 нужно свергать.

Может они количеством превзошли и понтуются?

Так они только на 5-м месте

Очередной недопроц-замена видеокарты для embarrassingly parallel задач? Вменяемая конкуренция этого в обычном софте с x86 сомнительна.

Смена кодировки команд практически ничего не даст, кроме сломанной совместимости с софтом. А больше значительной разницы там по сути нет.

https://www.r-ccs.riken.jp/en/fugaku/project/outline

https://www.fujitsu.com/global/about/innovation/fugaku/specifications/

Мамкины кулькакеры - смотрите сюда -

Programming Language and Library
Java

Сублимируйте -

http://jblas.org/

Может они количеством превзошли и понтуются?

не только, судя по результатам их ARM-ядра на равных с x86-ядрами.

Вменяемая конкуренция этого в обычном софте с x86 сомнительна.

С обычным софтом это к Яблочникам. Они десктопы на ARM анонсировали.

А под HPC-кластера давно уже софт собирают из исходников. Иначе теряется выгода от новых процессоров, будь то Intel, AMD, IBM Power и т.д. и т.п.

Дело не в сборке, а в том, что только определённые задачи в полной мере могут использовать заявленные флопсы таких железок. В другом софте производительность будет унылая, если у них там не практически полный аналог современных x86 процев кроме набора команд, разумеется.

Больше велосипедов, хороших и разных!

А что тебя там не устраивает? SIMD 512бит, скорость ядра 2,2ГГц. 48 ядер (плюс, возможно, 2-4 ядра). Это вполне себе заточенный под многопоточную математику проц, а не сборка под мобильник.

При этом он в 2.8 раз мощнее второго места (IBM POWER9+NVIDIA). И на столько же прожорливее

И у него в 3 раза больше ядер. И в чем прикол?

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

И на столько же у него больше ядер. И в чем прикол?

Со вторым местом сравнивать сложно, там Power9 + NVidia Volta GV100 с оптимизированной шиной. А тут на одном узле только один проц. Можешь сравнить с 8-м местом

Ну так известно же, что рейтинг перформанса на 1 ядро выглядит как POWER > x86 > ARM. Вот и приходится ARM-у догонять числом ядер.

Нужна конкуренция, ибо x86{_64} превратился в стагнирующий совок, готовый сколлапсировать под тяжестью напиханных в него костылей.

По-моему, x86 в этом впереди, по крайней мере в части задач.

NVidia Volta GV100

Так в ней одной 6000 ядер :)))

Можешь сравнить с 8-м местом

Там (kW) нет :(

• Fugaku - 158976 процев по 48 ядер.
• Summit - 9216 процев по 22 ядра.

Легким движением руки

в 2.8 раз мощнее

превращается из преимущества в анекдот.

Ну-ну а про NVidia кто говорить будет с их тысячами ядрами на борту?

Окей, пусть будет 158976 против 36864. Что-то принципиально изменилось?

4608 узлов * ( 2 проца * 22 ядра + 6 видеокарт * ( 5376 CUDA ядер + 672 тензорных ядер)) = 167 417 856 абстрактных ядер

В добавок у IBM один узел занимает 2U в стойке. У Fujitsu 384 узла в стойке

Вот теперь java не тормозит!

Да на него только перешли и закопали x86.

Вменяемая конкуренция этого в обычном софте с x86 сомнительна.

ARM64 уже превзошел Зионы на абсолютном большинстве задач и дышит в спину последним Райзенам.

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

Тормозит Джава только у мамкиных кулькакеров, которым мамка нормальный комп не купила.

У меня и на Rasp'е Джава быстро работает.

У меня тормоза были с унылой САПРиной на жабе, которая была запущена на серваке (xeon + 1Tb RAM). Мощнее мамка не купит ;)

с унылой САПРиной на жабе

Конкретно какая «САПРина»?

Кривыми ручонками индусских разработчиков можно прекрасно затормозить gc в Джаве.

Могу даже научить как.

https://www.manning.com/books/bitter-java

Конкретно какая «САПРина»?

Cadence vManager

Могу только посочувствовать.

Не Вы же разработчик - Вас обязали пользовать это поделие.

-----

Не стОит путать «теплое и мягкое».

Джава - отдельно.

Индусский код - отдельно.

В моей практике постоянно встречается «унаследованный» индусский код типа конкатенации строк вместо заведения StringBuilder.

И это еще «цветочки».

и низким параллелизмом

наверно просто такие задачи не стоит обсчитывать на кластере?

Альтернатив нет) только если массово переходить на тулы от кого-то другого из «большой тройки», но хрен редьки не слаще