EntityFX Jan 27 2022 at 19:31

Первые тесты инженерной версии процессора Эльбрус-16С

10 min

58K

ICL Services corporate blog Computer hardware CPU

✏️ Technotext 2022

+85

291

Comments 291

AKonia Jan 27 2022 at 19:55

Простейший вопрос: тесты оптимизировали ? Просто под интел они ясен пень оптимизированы и в цифрах соменения нет, но с Эльбрусом же важна связь с компилятором, т.е. это примитивные тесты или пиковые с учётом оптимизации ? В противном случае было бы не правильно, если данное сравнение окажется из той же оперы, что и "сравниваю пузырьковую сортировку с быстрой, без оглядки на теорию сложности"

+16

EntityFX Jan 27 2022 at 19:56

Да, само собой. Сам код не менял, игрался флагами сборки, профилирование компилятором LCC. Но вообще компилятор МЦСТ порой странно ведёт себя, да.

+10

Ul3ainee Jan 28 2022 at 11:23

Может это в начале статьи где-то указать? А то меня ровно тот же вопрос сопровождал в течение всей статьи: «чем и как компилировали тесты?». Уж очень сильно это меняет дело в случае VLIW.

EntityFX Jan 29 2022 at 01:26

Да, добавил, а то СМИ там уже ахинею начали писать.

Banzay48 Jan 29 2022 at 12:16

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

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

"Энтузиаст вогнал гвоздь в крышку гроба МЦСТ и Эльбруса"...

На том же ДНС-ШОП в новостях усираются, что именно ты доказал, что Эльбрус-16 чуть ли не в 250 раз слабее Intel Core7, а в комментах там такой срач развели что дай дороги. Чуть ли не "энтузиаст-оппозиционер протестировал Эльбрус-16С, и всему миру доказал что это полный кал, крайне не рекомендованный к приобретению".

Смотри как бы теперь у тебя проблем не возникло. Те же ДНС полностью переиначили твою статью, и выставили тебя чуть ли не "борцом с системой и изобличителем лжи о импортозамещении".

Я бы на твоем месте подал на ДНС в суд, или потребовал опровержения

EntityFX Jan 29 2022 at 12:27

Я со СМИ не сотрудничаю, мне интересны бенчмарки Эльбрусов, да и сами Эльбрусы (энтузиаст: работа с ними, программирование. Честно, мне Эльбрусы очень нравятся, хотел бы себе такой). Что там они пишут - я не отвечаю, я отвечаю за цифры и косяки тестов, постараюсь исправлять, если найдут ошибки в тестах/методике.

Факторы:

Инженерник (отключены часть кеш-линий)
2 планки ОЗУ на не полной частоте (2400 вместо 3200), надо 8 планок
Компилятор не последней версии

nepoman Jan 31 2022 at 11:24

Вообще-то результаты иногда следует и перепроверять, корректно анализируя вывод не мешает... И что так ангажированно приведено для HPL LINPACK?? ...где те же данные для Core i7-2600??? :-D
- а то складывается впечатление, что нативный тест HPL (Alma Mater Elbrus) также полностью провален?!) хотя в действительности все оказывается как-то подозрительно иначе: Core i7-2600, который в cpubenchmark.net явно слабее Core i5-8250U, едва ли может выдать GFLOPS-ы в этом тесте, так как нативно скомпилированный LINPACK HPL-2.3, для последнего указанного Core i5-8250U на Debian 11 (ещё раз: который имеет больше "попугаев", чем Core i7-2600, согласно cpubecnhmark.net!!!), отдает всего каких-то жалких: 0.3802 GLOPS, внезапно, как так?! ...в стандартной сборке "из-коробки", без всяких дополнительных опций оптимизации, но с установкой штатно-оптимизированных доп.библиотек дистрибутива (BLAS). ...кстати, проводя эти тесты желательно ещё и указывать, какая таки библиотека: BLAS или VSIPL были использованы (http://www.netlib.org/benchmark/hpl/).
- в итоге, впечатления от объективности текущих результатов тестов получаются довольно смешанные...

EntityFX Jan 31 2022 at 11:32

Так, посмотрел Эльбрусовский HPL (версия 2.2).

MPI: /opt/mpich-3.1.4/, с флагом -lmpi
La: какая-то своя либа, с флагом -leml, -DHPL_CALL_CBLAS

Для Core i7 пока нет возможности протестировать HPL, там нужно грузится в ОС, а работаю теперь удалённо. Можно в WSL, но как там с производительностью будет.

Но вот результаты на Kunpeng 920 2.6 ГГц на 48 ядрах:

T/V                N    NB     P     Q               Time                 Gflops
--------------------------------------------------------------------------------
WR10L4L4       40800   240     1    48             233.34             1.9406e+02
HPL_pdgesv() start time Wed Jan 26 22:07:05 2022

HPL_pdgesv() end time   Wed Jan 26 22:10:58 2022

--------------------------------------------------------------------------------
||Ax-b||_oo/(eps*(||A||_oo*||x||_oo+||b||_oo)*N)=   9.95497593e-04 ...... PASSED
================================================================================

khis Jan 28 2022 at 09:04

"А вы тесты оптимизировали?" - от создателей "А вы систему оптимизировали? " И "А вы ПО оптимизировали? ".

Не слишком ли много накладных расходов ради того, чтобы заставить эту поделку работать хотябы на уровне 10-ти летнего? Я бы ещё может согласился с тем, что да, надо своё развивать, но ядра то, насколько я понимаю, это не отечественная разработка, то есть всё отечественное процессоростроение это не о классных спецах в проектировании ядер и архитектур, а о спецах, объединяющих IP ядра в соответствии с госзаказом?

-18

trunya Jan 28 2022 at 10:10

Вы эльбрус с байкалом путаете

+17

bbvoronin Jan 28 2022 at 10:11

Ядра, свои, родные, посконные, вероятно вы путаете Эльбрус с Байкалом (там АРМ)

+10

Neo28 Jan 29 2022 at 07:36

Там mips, но не суть)

-6

amartology Jan 29 2022 at 12:13

В Байкал-Т — MIPS. В Байкал-M и Байкал-S — ARM.

UFO just landed and posted this here

AllexIn Jan 28 2022 at 17:55

ТАк VLIW это как раз о "оптимизировано компилятором".

Если мы забиваем на качество компиляции - бенч можно даже не запускать.

EntityFX Jan 29 2022 at 01:45

Верно, это сразу бросается в глаза. Ещё нужно лезть в код и оптимизировать участки.

Neo28 Jan 28 2022 at 10:11

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

oYASo Jan 28 2022 at 13:23

Что значит "тесты оптимизированы"? Для разработчика должно быть все по дефолту: взял код, собрал, проверил, отправил в прод. То, что там есть какая-то связь с компилятором - прекрасно, но я же не буду оптимизировать десятки миллионов строк плюсового кода, чтобы они как-то по-особенному стали работать на Эльбрусе. Разработчики процессора это подразумевают, но не уверен, что с ними согласны разработчики софта.

-12

anka007 Jan 28 2022 at 14:43

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

+12

oYASo Jan 30 2022 at 13:58

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

В моем понимании "оптимизация" - это затачивание тестов под конкретную платформу. e2k архитектура подразумевает, что вы знаете о широкой команде, и стараетесь писать код так, чтобы эту широкую команду максимально заполнить для параллельной обработки. Если вы делаете так, вы действительно получаете сильный буст, но проблема в том, что 99.999% кода написано без оглядки на такие архитектуры, а, следовательно, никаких преимуществ вы тут не получите.

Поэтому интересны такие тестовые кейсы:

1) Мы берем любой стандартный бенчмарк и компилим код as is под x86 и e2k и смотрим, какая разница в попугаях. В подавляюшем большинстве это то, на что нужно смотреть, потому что вряд ли люди будут переписывать openssl или какой-нибудь jsoncpp.

2) Пишем максимально эффективный код для x86 и e2k и смотрим, насколько архитектура реально эффективно тащит задачу. Этот кейс ок, когда вы самые ресурсоемкие части своего продукта сразу пишите с оглядкой на платформу e2k. Не представляю, кому это, кроме МО РФ и некоторой госухе, надо.

И я на всякий случай напомню, что VLIW в Intel умер. Да и не только в Intel, были разные идеи сделать что-то похожее, потому как сама идея выглядит вполне себе ок, но на практике оказалось, что писать эффективный компилятор под этой дело крайне сложно, а заставить всех разработчиков быть умными и сразу писать эффектиный код под архитектуру не получилось.

anka007 Jan 31 2022 at 10:19

1) В этом и заключается тест производительности. Берется некий стандартный код, который по утверждению автора более-менее соотвествует типичным задачам. В зависимости от того, что планируется запускать выбирается подходящий тест.

2) Вообще не поняла. Перед тем, как начать разработку ПО обычно выбирают архитектуру. Тут коротенькую процедурку оптимизировали под эльбрус, можно оценить трудозатраты. При этом оценку типа стоит/не стоит начинать разрабатывать и оптимизировать можно получить анализом алгоритма и результатов стандартных тестов.

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

oYASo Feb 1 2022 at 23:44

Перед тем, как начать разработку ПО обычно выбирают архитектуру.

Ой ли! Современный мир таков, что мы пишем продукт, а потом нам приходит осознание, что какая-то крупная компания выпустила, скажем, M1, и теперь наш продукт нужно собирать на ARM. И хочется, чтобы все проблемы ограничились настройкой тулчейна под целевую платформу. И это, кстати, отличный пример, как новый проц довольно быстро оброс софтом и большей произвоидельностью без таких уж сильных приседаний.

Ну и будем честны, вряд ли в общим случае какой-то разрабочик/компания скажут: "штош, начну-ка я пилить свой новый проект чисто под Эльбрус". Как я уже писал выше, кроме оборонки и некоторой госухи я больше никого не вижу.

А вот труд разработчиков ПО сильно подорожал.

Поэтому Эльбрус сделал платформу, в которой мы должны тратить время разработчика на оптимизации из приведенной Вами статьи? :)

UFO just landed and posted this here

Mike_Mihalych Feb 3 2022 at 13:37

Компас, если я не ошибаюсь, пытаются портировать на Линуксы уже года 3 как.

UFO just landed and posted this here

santey_tm Feb 1 2022 at 22:35

Кстати, на днях было произвежено именно такое тестирование уважаемым shcher :
https://habr.com/ru/post/647165/
Общий вывод: на коде без оптимизации Эльбрус 1.55ГГц проигрывает Intel Core i7-9700K 4.8 ГГц в 16 раз.
Но! После лптимизации кода (причем не конкретно под Эльбрус, а снандартным для всех процессоров образом) Эльбрус уступал Интелу 34%. Что с учетом разницы в частотах, считаю, является выдающимя показателем.
Получается, после оптимизация кода Интел ускорился в 4 раз, а Эльбрус в 44 раза.
Одна замена типа счетчиков на знаковый 64бит дала прирост в 12 раз!
Т.е. в очередной раз подтверждается критичность оптимизации кода под VLIW.
Поэтому, конечно, Эльбрус плохо подходит для персональных ПК с их обилием неоптимизированного софта и браузерами со скриптовыми языками.
А вот для серваков, где типичный набор софта не так велик и где он как правило компилируемый - подходит вполне! Более того, после оптимизации производительность будет сопоставима с Интелами, работающими на втрое больших частотах (при том, что Зеонов, способных держать 4.5ГГц на всех ядрах, в природе не существует, насколько знаю). Т.е. в плане тепловыделения Эльбрус будет рулить однозначно.

oYASo Feb 2 2022 at 00:06

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

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

Насчет серверов. Если уж совсем быть честным, то на сервере мы можем поставить не десктопный корэ-ай-семь, а парочку AMD EPYC по 64 ядра каждый, и тут я даже не знаю, какие силы надо с Эльбрусом выставлять? Сразу ЦОД строить, чтобы сопостовимо было? Про цены этого сопоставления я вообще молчу.

Но даже если предположить, что мы тут хотя бы десктопных проц трехлетней давности пытаемся догнать, то чтобы результаты из статьи как-то заработали, надо еще nginx переписать под это дело, или TensorFlow, или v8, или какой-то еще софт. Будет Сысоев, интересно, nginx переписывать, чтобы на Эльбрусах все быстро было? Вопрос, конечно, риторический.

То есть да, какую-то работу они показывают. Оно даже работает, если завтра в ЦБ РФ запретят поставлять intel/amd/etc, мы сможем закупить контейнер Эльбрусов, установить их и даже получить какие-то положительные результаты (вопросы о производстве пока отбросим). Но это ваще не конкуренция. Это вещь в себе, которая нужна на каком-то локальном рынке решать какие-то локальные проблемы без претензии на технологичность. Это как Москвич в автомобилестроении, жил, пока ничего другого не было, и сразу умер, как появилось. Мы опять идем по этому пути и опять придем к таким же результатам.

amartology Feb 2 2022 at 10:57

Оно даже работает, если завтра в ЦБ РФ запретят поставлять intel/amd/etc, мы сможем закупить контейнер Эльбрусов

Вообще не факт. Если EAR ограничения коснутся Intel, то они коснутся и TSMC.

edo1h Feb 2 2022 at 05:33

Получается, после оптимизация кода Интел ускорился в 4 раз, а Эльбрус в 44 раза.

да, любопытный случай.

Более того, после оптимизации производительность будет сопоставима с Интелами, работающими на втрое больших частотах

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

на самом деле, никто не спорит с тем, что эльбрус — неплохая числодробилка. есть класс задач, на которых он может тягаться с интелом. но (a) этот класс задач достаточно узкий, (b) на многих счётных задачах gpu показывают недостижимую для cpu производительность.

А вот для серваков, где типичный набор софта не так велик и где он как правило компилируемый — подходит вполне!

вы уверены? есть куча серверного софта на java, python, да те же миллионы сайтов на php где крутятся, если не на серверах?

и ещё один вопрос, автор статьи потратил несколько часов на оптимизацию менее 20 LoC.
иду в гугл, вбиваю название первого пришедшего в голову продукта, получаю:
PostgreSQL is over 1.3M lines of code and some of the code paths can be tricky to reach.
сколько времени уйдёт на его оптимизацию?

UFO just landed and posted this here

JerleShannara Feb 2 2022 at 16:48

А как вы собрались заменять всякий Oracle, который там крутится, на Postgres без оптимизации и разгона этого самого Постгреса?

UFO just landed and posted this here

JerleShannara Feb 2 2022 at 18:21

Ну чтобы чисто поржать, 1С там всякие что используют в роли базы данных, когда их под линуксами всякими запускают? Всякие гитлабы там что в роли базы данных используют? Впрочем согласен, MySQL/MariaDB наверное проще будет оптимизировать, там кода меньше скорее всего.
Задачи оптимизации и разгона надо будет переделывать под каждое поколение Эльбрусов — расплата за подход этого самого e2k. Конечно да, всякие базы данных там под каждую архитектуру надо оптимизировать, но давайте сравним кол-во разработчиков под x86, arm, risc и кол-во разработчиков под e2k, хотя это довольно бессмысленная идея, e2k нужен сугубо узкой прослойке в РФ, а прочие архитектуры нужны во всём мире.

-2

UFO just landed and posted this here

JerleShannara Feb 5 2022 at 15:25

А вы принципиально не можете мыслить хотя бы слегка за рамками «только одна программа»? Вот к примеру, как расшифровывается LAMP и почему оно так популярно было, да и остаётся, правда A заменилось на N и прочее в этом духе?

-1

UFO just landed and posted this here

JerleShannara Feb 7 2022 at 18:09

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

-2

edo1h Feb 2 2022 at 17:08

основная проблема с заменой oracle/ms sql/etc не в оптимизации, а в том, что совместимость между разными субд весьма условная

UFO just landed and posted this here

Crazy_Pit Jan 28 2022 at 14:46

это свойство vliw.. вот если в эльбрусе бы не было транслятора для Х86 . то без компилятора бы тест не запустили и вопросов бы таких не возникало..то есть на нем можно запустить тест в двух режимах.

oYASo Jan 30 2022 at 14:06

Не очень понял, о чем Вы. Да, Эльбрус имеет бинарный транслятор, но это все-таки дополнительный бонус для историй, когда код под платформы по каким-то причинам пересобрать нельзя. Наверное, разработчиков в первую очередь интересует история, когда код собрать можно.

Или о чем был комментарий?

-1

Crazy_Pit Jan 30 2022 at 15:14

Что значит "тесты оптимизированы"? Для разработчика должно быть все по дефолту: взял код, собрал, проверил, отправил в прод

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

oYASo Jan 30 2022 at 16:49

У автора статьи тесты собраны как нативно под платформу, так и с бинарной трансляцией. Тут можно поискать со словом RTC: https://github.com/EntityFX/anybench/tree/master/results

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

Но основное сравнение: это все-таки нативный код для e2k и нативный код для x86.

EntityFX Jan 31 2022 at 11:40

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

saboteur_kiev Jan 28 2022 at 16:16

> Для разработчика должно быть все по дефолту: взял код, собрал, проверил, отправил в прод

Да ладно. Возьмем какой-нить софт для расчетов, например magma
http://magma.maths.usyd.edu.au/magma/download/x86_64-linux/
Почему там есть отдельные дистрибутивы под amd и под intel?
Просто Эльбрус недоступен широким массам и не популярен, поэтому под него нужно специально компилировать, и это еще компилятор должен знать особенности эльбруса.

А так, если вас не интересует производительность, то совместимость позволяет работать и так. Но как разработчика, это вас не красит.

UFO just landed and posted this here

oYASo Jan 30 2022 at 14:18

Потому что можно использовать свежие SSE и прочие AVX-512, которые дают сильный буст на математике.

А использование всего оптимизационного добра на e2k хоть и дают сильный буст, но только в рамках их архитектуры - остальным они все равно сильно проигрывают. Поэтому ребята из magma и всех других расчетных софтов вряд ли будут пилить какую-то серьезную поддержку нашей архитектуры, потому что зачем? И отдел стратегического планирования МЦСТ должен это понимать: никакой массовости не будет, никто специально поддержку пилить не будет, значит, большинство кода на платформе будет использоваться as is.

Karbofos42 Jan 28 2022 at 17:13

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

sgjurano Jan 28 2022 at 17:42

Бинарный поиск вместо линейного процессоры делать всё же не должны :)

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

Neo28 Jan 28 2022 at 22:22

Хороший компилятор код довольно сильно переколбашивает, в том числе на уровне симантики языка и кусков кода, иногда заметного объема, в сотни с/c++ функций. У подобного поделия фронт энд который парсит язык это процентов 10% кода от силы, еще 10% это кодогенерация, а оставшиеся 80 это почти все оптимизация. Только по оптимизации циклов книжка с теорией страниц 500, с математикой) и еще 500-600 страниц по общим оптимизациям построением всяких SSA форм)) и еще наверно 400 про векторизацию, и наверно 300 про кодогенерацию...ну это если "класику брать")) они больше на учебник по матану похоже, чем на книжку по программированию))

arantar Jan 29 2022 at 00:05

Можете пожалуйста названия этих книжек скинуть?

Neo28 Jan 29 2022 at 06:38

https://www.amazon.com/Software-Vectorization-Handbook-Multimedia-Performance/dp/0974364924#aw-udpv3-customer-reviews_feature_div

https://www.amazon.com/Compilers-Principles-Techniques-Alfred-Aho/dp/0201100886/ref=mp_s_a_1_2?crid=2AG0N3HEAF5YZ&keywords=compilers+principles%2C+techniques%2C+and+tools&qid=1643426879&sprefix=compilers%2Caps%2C252&sr=8-2

https://www.amazon.com/Optimizing-Compilers-Modern-Architectures-Dependence-based/dp/1558602860

https://www.amazon.com/Advanced-Compiler-Design-Implementation-Muchnick/dp/1558603204/ref=pd_aw_sbs_2/147-7943669-8618115?pd_rd_w=Dy5zN&pf_rd_p=bc45384a-cf15-479c-b874-e31c5245d34e&pf_rd_r=C0M20AERN9B8JMHTT1Z9&pd_rd_r=6569f36c-24e0-4e75-a233-bf6385b525dc&pd_rd_wg=uihha&pd_rd_i=1558603204&psc=1

https://www.amazon.com/Engineering-Compiler-Keith-Cooper/dp/012088478X/ref=pd_aw_vtp_1/147-7943669-8618115?pd_rd_w=Kg6m4&pf_rd_p=5de75ffb-8b60-480a-8e6e-73ac6e3b849a&pf_rd_r=C0M20AERN9B8JMHTT1Z9&pd_rd_r=6569f36c-24e0-4e75-a233-bf6385b525dc&pd_rd_wg=uihha&pd_rd_i=012088478X&psc=1

oYASo Jan 30 2022 at 14:35

Свидетели Отечественных Процессоров на Хабр ботов завезли, что ли?

Какой софт каким конкурентам будет проигрывать? Речь у нас про то, что софт под Эльбрус проигрывает по скорости конкурентам Intel, AMD и далее по списку. Рынок не у Эльбруса, чтобы он задавал тренды, если что :)

Под привычную нам архитектуру x86 большинство оптимизации делает компилятор, не разработчик. Эльбрусовский же компилятор за вас не делает ту работу, которая нужна дла VLIW процов. Есть даже инструкция, как с этим жить.

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

DungeonLords Jan 30 2022 at 05:39

Для общего развития вам может быть полезна

https://habr.com/ru/post/442682/

DistortNeo Jan 28 2022 at 19:56

Собственно, да. После вот этой статьи:
https://habr.com/ru/post/647165/
где оптимизацией кода можно достичь ускорения в 44 раза на Эльбрусе, становится очевидным, что тестировать надо тоже правильно.

EntityFX Jan 29 2022 at 02:51

Полностью согласен!

Neo28 Jan 29 2022 at 06:57

Кейс классический вообщем-то. Есть софт, есть железка. Софт собирается компилятором, получается скорость х. Затем если необходимо идёт тонкая настройка руками. Стоимость доведения софта до максимальной скорости работы руками обычно дорогая и применяется в крайних случаях. Если всё вылизать то в данном случае и конкуренты мягко говоря сильно прибавят). Если надо ещё быстрее то берём и считаем на gpu, как вообщем то и делают для подобных разностных схем обычно)

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

UFO just landed and posted this here

Neo28 Jan 29 2022 at 12:04

Ни один компилятор пока не умеет делать идеальный код. В любом компиляторе всегда ищется баланс.

Компилятор у интел специально не замедляет код для АМД, он не пользует просто фичи, где АМД лучше интел) . Да, смысл то же для юзера, но юридический смысл другой, интел из за этого ходил неоднократно в суд). И делает он так очевидно почему. Интел же не компилятор продаёт, а процессор. АМД так же делал, когда у них был свой компилятор лет 20 назад или около того. Просто бизнес)

А и да, код вылизывают, прибивают не просто гвоздями к вендору, А бывает и к конкретной железке иногда) вылизывают не всё, а только боттл неки, которые основное время жрут. Поэтому если такие кастомеры садятся на платформу, подвинуть их на конкурента очень сложно. Я ещё до времён gpu использования для расчётов с плавающей арифметики, для пиксара делал оптимизацию рендера, для рендеринга мультиков. Они сидели на интел и к красным уходить не хотели совсем) потаму что интел помогал код вылизывать, а они каждые 3-4 года обновляли процы для 20к серверов)

UFO just landed and posted this here

X3_Shim Jan 30 2022 at 12:09

>> А если вспомнить, что бывают ещё библиотеки интела?

Кстати, совсем давно я ускорял матлаб, путем подсовывания в него MKL, вместо использующейся ACML, получил огромное ускорение и параллельность. Всего то небольшую интерфейсную либу приделал к MKL.

А MKL_DEBUG_CPU_TYPE вообще была изначально задумана для тестирования разных веток кода на топовых процах. Расползлось однако, хотя прикрыто имя переменной в коде было просто XORом :)

DistortNeo Jan 29 2022 at 13:23

Если всё вылизать то в данном случае и конкуренты мягко говоря сильно прибавят

Если посмотрите статью, на которую я сослался, то окажется, что прибавка у конкурентов уже не такая существенная.

Neo28 Feb 5 2022 at 06:45

У каждой архитектуры есть сильные и слабые стороны. Архитектура Эльбруса в теории не плоха для флотинг поинт арифметики и циклов. Но cpu это баланс. И у Эльбруса его нет. Там где он силён он проигрывает немного, где не очень, проигрывает на порядки. А разностные схемы кому надо считать, давно это на gpu делают. Тот же интел это понял в контексте итаниум 14 лет назад, и начал сворачивать проект.

Alusar Jan 27 2022 at 19:56

Интересно.

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

EntityFX Jan 27 2022 at 19:57

В считалках, в хранилках, БД сервера, защищённые компы, ну как Intel Itanium.

+10

Neo28 Jan 28 2022 at 10:21

Итаниум, сдох де-факто ещё в 2010 году, когда я оттуда уходил) интел его тянул ещё долго ибо были уже клиенты жирные, в основном япошки, которым по контракту интел был обязан поставлять чипы ещё несколько лет. Звучит странно но кто с Япошками работал поймёт, им что то продать сложно, но если продал они это годы будут пользовать.

+10

vanxant Jan 28 2022 at 00:06

Во всех, где не любят Intel ME и прочие зонды, например.

UFO just landed and posted this here

vanxant Jan 28 2022 at 03:01

Доступнее? Назовите любой один сервер на RISC-V, чтобы можно было прям купить.

+11

UFO just landed and posted this here

JerleShannara Jan 29 2022 at 15:00

Хинт: если я не могу купить байкал, я иду и покупаю бродком/медиатек/рокчипс/аллвинер. Если я не смогу в будущем купить ядропуперриск я пойду и куплю хайфайв и прочих. Если я не могу купить эльбрус, ну да, ну да, пошёл я.

-3

UFO just landed and posted this here

JerleShannara Jan 29 2022 at 15:09

Достану из сундука попугая и повязку, если не найду решений, которые можно будет заюзать.
П.С. Дам подсказку — в компуктерном магазине можно спокойно купить коробочку с надписью Microsoft Windows 10 Professional и даже с Microsoft Windows Server 2019. И никто вам там не скажет: руки вверх, подлая морда, покажи докУмент, что ты не МГУ.

UFO just landed and posted this here

JerleShannara Jan 29 2022 at 15:20

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

-3

UFO just landed and posted this here

JerleShannara Jan 29 2022 at 17:00

Подсказка: после покупки в зубы берётся чек с накладной, коробка с виндус. Далее идём бухгалтерию и опа, теперь это не у частника, а у организации на балансе. Если же нам надо 20000 виндусов, то есть фирмы, управляемые зицпредседателями фунтами, которые с радостью за +х% купят и перепродадут вам много чего интересного. Это если вернуться в реальность из розовых мечт, в которых ограничения действительно работают.

-3

saboteur_kiev Jan 30 2022 at 17:49

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

Простите, вьюноша.

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

Вы вообще думайте шире, а не о своем личном компьютере где-то дома или о маленькой ООО "рога и копыта". Там где нет запретов - там их нет. Там где есть - они есть.

И если уж надо работать на винде там, где нельзя, это решается другими способами, а не те варианты, которые вы предлагаете и которые выглядят как детский лепет.

JerleShannara Jan 30 2022 at 18:09

Я этим кстати реальность описывал. И если в инструкции на АРМ указана «Виндус Восемь», то ставить туда надо именно её, а за другую вам и прилетит всё, что вы наобещали. Плюс если прочитать внимательнее, с чего пошёл посыл про «купить за нал в магазе, а бухи поставят на учёт» или «заказать через фирму-прокладку», то он был про то, что делать, если используемый в производственной цепочке софт «Виндуз онли» и не хочет идеально работать при помощи всяких wine. Можете недавний скандал про турбины сименс вспомнить к примеру такого решения проблемы.

-3

saboteur_kiev Jan 31 2022 at 01:27

Я этим кстати реальность описывал. И если в инструкции на АРМ указана «Виндус Восемь», то ставить туда надо именно её, а за другую вам и прилетит всё, что вы наобещали.

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

JerleShannara Jan 31 2022 at 02:05

Кхем, вы софт, к которому ещё пачка документации по ГОСТ прилагается, использовали, ну или видели хоть раз? Там это классика жанра, доходящая порой до маразма, включающего какие патчи на ось ни в коем случае ставить нельзя.
Использование нелицензионной это тогда, когда прослоек не осталось, а магазин закрыли.
И турбины сименс это тот случай, когда прослойка испортилась.

-3

XtouRusX Feb 2 2022 at 05:23

Я не специалист, но со стороны пока этот процессор выглядит как Хрущев и кукуруза. Продукт хороший, но только для своей ниши.

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

Это я о том, что вроде как архитектура позицианируется как что-то для "математики", БД и т д., но на выставках можно видеть обычные рабочие станции на нем. Потому и возникает у многих вопрос, а что же там все таки делают люди и для чего за государственные деньги.

UFO just landed and posted this here

Neo28 Feb 5 2022 at 06:58

Для простого опера в мвд кто оформляет дела на компе или майора планирующего поставки картофана, нужна простейшая рабочая станция за 3 копейки, стоящая вся как один только проц Эльбруса. Желательно что бы софт не делал мозги. А когда в масштабах страны тратят деньги и внедряют более дорогие решения, то вся экономика становится "суперджетом". И потом народ удивляется, А почему у нас квартиры такие дорогие и такие паганые, а слетать в крым дороже чем в Барселону. Я всему руками за развитие Отечественной электроники и промышленности, но do right things right. А пока просто повышается энтропия.

-2

DungeonLords Jan 30 2022 at 05:51

Поддерживаю топик стартера ссылкой на компьютер на risc v. Купить можно хоть на али

Allwinner D1

UFO just landed and posted this here

JerleShannara Jan 28 2022 at 14:17

ARM не?

Wan-Derer Jan 28 2022 at 15:58

каких именно решениях может быть использован подобный камень

В любых. Это ЦП общего назначения. А то что производительность ниже..... Ну сколько реальных задач, на которых ЦП загружен круглосуточно на 100% на все ядра? Сколько задач где жизненно важная скорость обработки? Я не спорю, такие есть, но каков их процент в реальной жизни?

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

Alusar Jan 28 2022 at 16:02

Ну сколько реальных задач, на которых ЦП загружен круглосуточно на 100% на все ядра?

Я не говорил об этом)
Просто рассуждаю не только со стороны тех.параметров, но еще с немаловажной финансовой стороны.

Neo28 Jan 29 2022 at 07:50

Не могу сказать сколько в %% по рынку. Но где сервер работает с загрузкой 80% я видел очень много. Это я бы сказал это типичный кейс для сколь-нибудь серьёзной инфраструктуры, где хотя бы пол-сотни серверов есть. 20% оставляется на нежданчики обычно. И народ да, прям вот планирует нагрузку и бюджет. Круг задач весьма высок, от стриминга киношек до ERP систем крупных контор. Да могут быть просадки в нагрузке в течении суток, но в целом сервер колбасит под нагрузкой

Wan-Derer Jan 29 2022 at 08:21

Хорошо. Но что мешает на такую задачу поставить два сервера вместо одного?

Занимаемое место? Ну мы же не Сингапур! Мы 8 тыс км только в ширину :) Уж под ЦОД местечко найдётся! :)

Потребляемое электричество? Ну так мы - ресурсодобывающая страна. И турбины крутить тоже умеем.

Избыточное тепло? Ну так у нас обычно холодно! Почему бы не совместить приятное с полезным? :)

В плюсах - резервирование.

Конечно, не стоит ждать что так будут мыслить обычные эксплуатанты. Им чем проще/быстрее/стандартней - тем лучше. МЦСТ и Байкал - тоже не МикроИнтел, они эту тему субсидировать не могут. Здесь должно играть государство. А государство играет пока очень вяло. Я согласен с тем одним госзаказом отрасль не вытянуть. Так же одними запретами задачу не решить. А вот если добавить сюда пряник - может получиться. Если обычному коммерческому заказчику предложить хорошие условия приобретения и дальнейшего владения - он подумает-подумает, да и решится на эксперимент. А дальше уже дело производителей - сделать так чтобы эксперимент прошёл успешно.

И во избежание бессмысленной дискуссии: я тут ни за что не "топлю", я пытаюсь ответить на вопрос "где этот камень можно применить".

-1

Neo28 Feb 1 2022 at 18:15

2 сервера будут жрать примерно в 2 раза больше электричества, если они жрут в 2 раза больше электричества, то надо в 2 раза более мощную систему кондиционирования сама система стоит дороже и электричества в 2 раза больше. Нужно в 2 раза больше упсов, в 2 раза больше сетевых портов - само железо стоит денег, плюс опять же питание-охлаждение свичей. под сервера которых больше, надо больше места. Часто в дата центрах бывает проблема с мощностью. Т.е. просто так вот нельзя привезти 10 серверов в розетку воткнуть....там придется менять проводку, и очень часто в здании мощность вся расписана. Если сервера часть критической инфраструктуры, то кроме упсов, ставят еще дизель генераторы....опять же потребляемая мощность это критично для цены. В зависимости от типа задач, может стоять софт, и часто очень не дешовый, который привязан к серверу - больше серверов, больше цена. Я не говорю о том что скорее всего 2 менее производительные сервера будут стоить дороже чем 1 более производительный, могут быть +- вариации но в целом это так.

Wan-Derer Feb 1 2022 at 21:17

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

Neo28 Feb 1 2022 at 21:50

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

Wan-Derer Feb 2 2022 at 04:42

Да. Но без этого ничего и не будет. Если государство заинтересовано в развитии отрасли, его участие должно быть деятельным, а не просто сидеть где-то сверху и "регулировать".

У государства здесь больше возможностей чем у частника. Частник видит только цену Суперждета и более ничего. Для государства на одного производителя Суперждета приходится несколько производителей металла, агрегатов и прочих полимеров. Везде работают люди, получают зарплату, тратят её внутри страны, что даёт развитие ещё каким-то отраслям. И т.д. Надо уметь считать чуть дальше бухгалтера ларька "Союзпечать", тогда, возможно, субсидия окажется и не субсидией вовсе, а наоборот.

Самое простое: мы нефтедобывающая страна и нефтянка - высокодохоная отрасль. Так почему бы не предложить покупателю Суперждета субсидию на горючку? В общем балансе нефтяной отрасли это крохи, а машинка вдруг оказывается выгодной, как минимум для отечественного покупателя.

С серверами сложнее, но тоже можно что-то придумать. Скажем, из ресурсов, которые ты перечислил, государство может непосредственно регулировать недвижку и электричество. Хочешь ЦОД на Эльбрусах? Вот тебе льгота на землю/стройку/аренду и "бытовой" тариф на электроэнергию. И преференции на оказание услуг государству. То что для владельца ЦОД тупик в одно действие, для структуры, имеющей возможность планирования ресурсов и горизонт в десятки лет - обычная задача оптимизации при нескольких константах.

XtouRusX Feb 2 2022 at 08:06

Проблема в том, что государством рулят плюс/минус люди которые думают как обычные бухгалтера.

Если дали кому-то денег, значит они что-то сделают, а если давать льготы - это же денег недополучим.

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

Wan-Derer Feb 2 2022 at 08:54

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

Пример: со всех трибун несётся: "Давайте развивать Дальний восток!!!!!1". Давайте, чё. Но только другие руководители молвят: "Строить каскад ГЭС на притоках Амура нецелессобразно - нет потребителей". Тваюмать! А откуда там предприятия возьмутся если там ни дорог, ни электричества, одни чёрные лесорубы шастают? А если кто-то и построил себе заводик, то он должен подумать и об электростанции. А наш хилый частник есдинственное что может себе позволить - это традиционная тепловая ТЭЦ (это если газ ему подведут).

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

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

Neo28 Feb 2 2022 at 09:35

Экономика работает в интереса узкого круга лиц, в интересах этого узкого круга перераспределяется сырьевая рента. Малый кусочек отщипывается электорату на прокорм и обильно сдабривается лозунгами из всех доступных СМИ.

Существует негласный контракт - узкий круг лиц не лезет во власть и политику, царь не лезет в экономику. Иногда ему в ходе очередного годового "ответы на вопросы" подсовывают плачущего мальчика, которого Царь публично успокаивает и дарит "щенка". Тезисно как работает экономика РФ

-1

XtouRusX Feb 2 2022 at 09:50

Ну зачем так реалистично... Теперь и работать не хочется даже...

P.S. При этом государство боится потерять весь контроль, потому все что может завязать, завязывает на себя и столицу. И вот в 2022 году снова исполнитель из региона получает данные по бумажной почте из госфонда в Москве, который раньше был в регионе.

Собственно МЦСТ тут тоже показатель. Лучше пусть сидят у нас на бюджете и напуганные всякими гостайнами и наказаниями за разглашение, чем какие-то неподконтрольные будут зарабатывать деньги "мимо кассы".

UFO just landed and posted this here

Paul_Arakelyan Jan 29 2022 at 12:29

В настольном сегменте - производительность 1 ядра, пока что, важнее всего. Тут ситуация "ужас ужасный". И в БД - она тоже, часто, не редкая. Грубо говоря, то, что ты можешь отработать 100 параллельных запросов на 100 ядрах за 5 секунд, затратив Х Вт, не всегда компенсирует тот факт, что 1 запрос ты будешь отрабатывать те же 5 секунд, пусть даже конкурент сжирает 2*Х Вт на отработке 100 запросов, но если он это делает быстрее - юзер убежит к конкуренту и энергоэффективность не поможет.

UFO just landed and posted this here

Rezzet Jan 27 2022 at 20:01

Возможно ошибаюсь, но мне кажется что там где идет простое числодробление без сложных переходов, там Эльбрус показывает себя достаточно уверено, но там где появляются условные переходы и наверно кеш-мисы, становится все плохо. Возможно дело в плохом предсказание переходов и загрузке кеша?

Если бы мне дали принимать решение о политике полупроводниковой отрасли, то наверно смотрел в сторону RISC-V.

+10

lamerok Jan 27 2022 at 20:08

Насколько я понял из пресс-релиза, где то к этому и идёт, микс RISC-V и родное ядро. Первое для всего, второе для спец задач.

hhba Feb 1 2022 at 19:47

Насколько я понял из пресс-релиза, где то к этому и идёт, микс RISC-V и родное ядро

Ммм, из какого пресс-релиза? 0_о

Первое для всего, второе для спец задач

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

К слову, я не до конца понимаю причину популярности RISC-V. Открытость - это хорошо, но ведь микроархитектура (которая, в общем-то, и определяет конкурентоспособность конкретных реализаций) остается за кастомером. Если есть такие кастомеры (а мы видим. что они есть), которые готовы хреначить ядра, то чего они до того не хреначили что-то еще? Тот же MIPS хотя и стал тоже открытым лишь недавно, как раз под давлением RISC-V, но ведь до того кажется был не слишком дорог. Утверждалось, что сильно дешевле АРМа, предположительно даже сговорчивее (но у ARM Holdings оказалась лучшая инфраструктура пресейла, что, я полагаю, и определило их успех помимо технического совершенства). В общем выглядит как-то так для меня: серьезные инвесторы реально купились на это вот "все бисплатно! держите компилятор впридачу!" и начали выдавать бабло на то, что можно было делать давно.

amartology Feb 1 2022 at 19:58

К слову, я не до конца понимаю причину популярности RISC-V.

Индустрия хочет иметь альтернативу ARM. Особенно в свете возможности покупки ARM одним из их крупнейших клиентов. RISC-V отвечает на этот запрос индустрии. То есть это чисто маркетинговая история, а не техническая.

hhba Feb 1 2022 at 22:15

То есть это чисто маркетинговая история, а не техническая

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

Индустрия хочет иметь альтернативу ARM

А вот тут немного размыто. Во-первых, повторюсь, есть и был MIPS. Во-вторых - ну ни разу не гранды индустрии первыми побежали мутить с RISC-V, опасаясь за свои портки.

amartology Feb 2 2022 at 10:59

— ну ни разу не гранды индустрии первыми побежали мутить с RISC-V

Вообще первыми внедрениями RISC-V в серийные чипы были продукты NVIDIA и Western Digital.

UFO just landed and posted this here

amartology Feb 2 2022 at 12:02

Intel ME — это 32-битный x86

UFO just landed and posted this here

hhba Feb 2 2022 at 14:54

Действительно, про Нвидию я пропустил... Странно все это. У них при чем была та же самая история, о которой я выше писал - люди, которые к тому моменту уже имели тесные объятия с ARM, и имели лицензию на ISA, и даже пилили свои микроархитектуры, почему-то тем не менее взялись за это...

amartology Feb 2 2022 at 17:49

люди, которые к тому моменту уже имели тесные объятия с ARM, и имели лицензию на ISA, и даже пилили свои микроархитектуры, почему-то тем не менее взялись за это...

Например, для того, чтобы наглядно показать ARM, что не стоит зарываться и задирать цены.

hhba Feb 2 2022 at 17:54

Между прочим, как вы думаете, они платили какие-то роялти за ISA в случае ядра Denver? Почему-то кажется, что нет, и тогда кому и чего там показывать? Пилили бы дальше эти ядра, ну или опять же есть МИПС. @Am0ralist верно припоминает. что китайцы занялись именно этим....

Загадки, сплошные загадки. Еще очень интересно будет спустя время посмотреть, как полетит (и полетит ли) RISC-V в России. Будет ли кто-то из наших покупать готовые отечественные ядра Syntacore? Кажется Миландр или Элвис (отказавшийся от развития своей ветки GPCPU в пользу покупных ядер) открыты к такому, а вот пресс-релиз, в котором МЦСТ про подобное говорит, я что-то так и не нашел.

UFO just landed and posted this here

hhba Feb 2 2022 at 18:27

Хм, да, есть! И, да, слив 2600-му Интелу менее чем вдвое, без всяких там ARM и RISC-V. Хвала Стэнфорду, убить всех человеков!

UFO just landed and posted this here

amartology Feb 2 2022 at 19:03

Еще очень интересно будет спустя время посмотреть, как полетит (и полетит ли) RISC-V в России.

Уже полетел, начинайте смотреть по сторонам внимательнее.

Еще очень интересно будет спустя время посмотреть, как полетит (и полетит ли) RISC-V в России.

У Миландра, НИИМА «Прогресс», НИИЭТ и «Байкал» оно уже в работе. У первых двух — уже в кремнии есть.

-1

hhba Feb 3 2022 at 12:57

Уже полетел, начинайте смотреть по сторонам внимательнее.

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

У Миландра, НИИМА «Прогресс», НИИЭТ и «Байкал» оно уже в работе. У первых двух — уже в кремнии есть.

Мммм, погодите, не путайте. Про Байкал и Миландр я конечно знаю (у Миландра даже статья тут была), но они используют импортные ядра от CloudBEAR, я же имел в виду отечественные, Синтакоровские. НИИМА зачем-то мутит что-то свое, вместо покупки готовых ядер, это скорее не целевая модель. Про НИИЭТ я впервые сейчас от вас слышу - не было от них новостей про RISC-V в широкой печати, поделитесь пожалуйста.

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

UPD: БЛДЖАД!!111 Я наконец заглянул в раздел "Contacts" на сайте CloudBEAR.... Это не иностранная компания... 0_о

amartology Feb 3 2022 at 15:12

импортные ядра от CloudBEAR

С каких пор Питер стал заграницей?

Про НИИЭТ я впервые сейчас от вас слышу — не было от них новостей про RISC-V в широкой печати, поделитесь пожалуйста.

Так вот же они

В рамках проекта должен быть разработан и освоен в серийном производстве ультранизкопотребляющий микроконтроллер на архитектуре RISC-V со встроенной энергонезависимой памятью объемом 1 Мбайт и широким набором периферийных устройств.

Проект направлен на импортозамещение в гражданской аппаратуре, в которой сейчас применяются микроконтроллеры серий STM32L0, STM32L1, STM32L4, STM32L5, STM32U0 ф. ST Microelectronics и микроконтроллеры серии MSP430 ф. Texas Instruments.

hhba Feb 3 2022 at 15:47

С каких пор Питер стал заграницей?

Ну я там выше написал, что перепроверил и удивился. Несколько лет назад меня ввели в заблуждение. Приятное заблуждение)))

Так вот же они

Угу, действительно. Пресс-релизов не видел, а инфа довольно новая кстати.

Не вполне понятно, планируют ли они купить ядра у CloudBEAR/Syntacore, или как НИИМА пилить сами. Второе было бы грустно.

amartology Feb 3 2022 at 17:55

или как НИИМА пилить сами.

НИИМА ядро Синтакора используют

hhba Feb 3 2022 at 18:01

Хм, не в силу недоверия, а ради интереса - где об этом есть инфа?

UFO just landed and posted this here

EntityFX Jan 27 2022 at 20:08

У Эльбруса нет предсказателя переходов, переупорядочивания инструкций. Прямое исполнение, микрокода нет, это и требуется для защищённого исполнения кода, 3 аппаратных стека и т.д.

JerleShannara Jan 28 2022 at 14:17

И до сих пор нет операционной системы, которая это бы всё смогла полноценно использовать.

EntityFX Jan 27 2022 at 20:48

RISC-V интересна, на неё плохой код вертеть самое то, если сделают процессор 256 простых risc-v ядер, но серверного исполнения (даже без SIMD). PHP, NodeJS, Python будет нормально работать.

Rezzet Jan 27 2022 at 21:20

Как по мне, так RISC-V интересна тем что есть огромная куча фирм которые делают блоки процессора разного назначения и фактически можно собрать современный процессор как конструкто лего. Алибаба вообще открыла свои ядра которые по их заявлениям быстре ARM A73. https://www.opennet.ru/opennews/art.shtml?num=56010

Есть разные блоки под разными лицензиями, открытые/закрытые.

Плюс софт который уже портирован на данную архитектуру.

EntityFX Jan 27 2022 at 23:24

Кстати, МЦСТ могли бы вместо своей линейки SPARC перейти на RISC-V. И деньги бы пошли, наверное.

akaAzazello Jan 28 2022 at 11:07

RISC-V только-только закончил формирование спецификаций - векторное расширение(RVV), без которого он был неполным для ниши HPC, в 2021 довели до версии 1.0 - так что сейчас очень подходящее время для перехода.

UFO just landed and posted this here

akaAzazello Jan 28 2022 at 16:45

Как заметил автор, в МЦСТ (как минимум раньше было) 2 команды разработчиков - Е2К и (Sun) Spark - и было бы логично, чтобы знакомые с RISC архитектурой спарковцы занялись бы близкой (разработанной в том же Berkeley) и свободной RISC-V архитектурой, а не, скажем, ARM или слились с E2K командой

UFO just landed and posted this here

amartology Jan 28 2022 at 17:52

если для военки чипы делаются вроде как «тут»

С чего вы взяли?

UFO just landed and posted this here

amartology Jan 29 2022 at 11:59

Не стоит верить всему, что пишут в интернетах. Особенно если это не официальный пресс-релиз МЦСТ или Микрона об освоении серийного производства процессора на отечественной фабрике. Ну или, на худой конец, ТЗ на ОКР по адаптации дизайна с TSMC на Микрон.

UFO just landed and posted this here

imotorin Jan 29 2022 at 21:22

SPARC

nixtonixto Jan 28 2022 at 09:27

Смотреть лучше в сторону ARM, Apple не даст соврать. Даже здесь в тестах их процессор для мобильных телефонов оказался в разы производительней этого десктопного Эльбруса. Хотелось бы ещё увидеть не только абсолютные цифры результатов тестов, а в пересчёте на ватт потребляемой мощности. Для серверов это очень важно.

Neo28 Jan 28 2022 at 11:05

В серверах важна не только производительность на ватт, но и скалируемость. У арма с этим печалька. Поэтому истории арм для серверов уже лет 10, но пока это узкоспециализированные решения

Layan Jan 28 2022 at 12:41

Почему узкоспециализированные то? Тот же AWS с Graviton очень даже неплох. Мы довольно быстро на него перешли — дешевле и производительнее получилось. Софт, в основном, уже собран под ARM. Да и собрать тоже не проблема.

Neo28 Jan 28 2022 at 13:03

Амазон переработал заметную часть стека софтового под арм, они себе это могут позволить при их объемах.

Layan Jan 28 2022 at 13:53

Но ведь тот софт, что они переработали вполне можно использовать и на других ARM. Так, даже наш софт собирается под ARM и используется и на серверах, и на ноутбуках разработчиков с Apple M1.

Neo28 Jan 28 2022 at 21:58

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

UFO just landed and posted this here

nixtonixto Jan 28 2022 at 13:41

Я на 99% уверен, что в российских реалиях «опенсорс» или велосипед окажутся такими же провальными затеями, как Йотафон, Марусся, лунная база… И в лучшем случае его будут так же, как в этой статье, сравнивать с 10...15-летними не-флагманскими моделями Интел. ИМХО более-менее конкурентоспособный процессор в России можно собрать, если брать Актуальные ядра ARM и обвешивать их своими IP, PHY и логикой. Процессор нужен не только оборонке, поэтому для гражданки вполне реально лицензировать ядра и собрать камень в разумные сроки.

-2

anka007 Jan 28 2022 at 14:23

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

amartology Jan 29 2022 at 18:30

Вояки всю дорогу прекрасно потребляли не только отечественные ARM, но и скажем, процессоры Intel.

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

Неправильно знаете)

hi-tower Feb 1 2022 at 22:41

Вы думаете, Интел разрешает использовать свои процы в военке? Они просто не контролируют их распространение. В отличие, например, от IBM с их PowerPC

-1

Paskin Jan 30 2022 at 08:44

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

toxano Jan 27 2022 at 20:07

Можете уточнить про Geekbench. Там сравнение одного i7 2600 против двух 16С?

EntityFX Jan 27 2022 at 20:16

Нет, это глюк распознавания проца, там 1 проц в бинарной трансляции, Geekbench падал, пришлось прокинуть ему кастомный /proc/cpuinfo.

Extravert34 Jan 27 2022 at 20:08

Выложите пожалуйста тесты на openbenchmarking.org. Там регулярно выкладываются бенчмарки разных экзотических (и не очень) процессоров, будет интересно сравнить.

EntityFX Jan 27 2022 at 20:09

Кому интересно как посчитать теоретические FLOPS:

How calculate FLOPS (v1 .. v3):

Single Precision: 4 FP ALUs * 4 Single operation * Cores * Frequency
Double Precision: 4 FP ALUs * 2 Double operation * Cores * Frequency

How calculate FLOPS (v4):

Single Precision: 6 FP ALUs * 4 Single operation * Cores * Frequency
Double Precision: 6 FP ALUs * 2 Double operation * Cores * Frequency

How calculate FLOPS (v5+ [128 bit SIMD]):

Single Precision: 6 FP ALUs * 4 Single operation * 2 SIMD * Cores * Frequency
Double Precision: 6 FP ALUs * 2 Double operation * 2 SIMD * Cores * Frequency

Example for Elbrus-16C: 6 ALUs * 2 DP * 2 * 16 Cores * 2e9 = 7.68e11 --> 768 GFlops FP64

V1tol Jan 27 2022 at 20:13

Интернет говорит, что в 16С аж целых 8 каналов памяти. Думаю, что 2 планки очень сильно ограничивают некоторые результаты.

EntityFX Jan 27 2022 at 20:21

Да, верно, но столько установлено, а поменять конфигурацию памяти я не могу =, работал удалённо.

toxano Jan 27 2022 at 20:29

Может один удаленный образец, дадут сообществу на растерзание. Все сами соберём и проверим

EntityFX Jan 27 2022 at 20:46

Тут спросите: https://t.me/e2k_chat

EntityFX Jan 27 2022 at 20:22

Добавлю позже в описание про тип и каналы памяти.

EntityFX Jan 27 2022 at 20:26

Уточнил: там 2 плашки KSM24RD4/32MEI по 32 Гига.

VLev Jan 27 2022 at 20:45

Не нашёл log-ов SPEC2006.

Как именно в нём тестировалось?

EntityFX Jan 27 2022 at 20:46

Это уже МЦСТшные цифры, купить тест не могу, хотя на нём они тестируют перфу компилятора.

VLev Jan 27 2022 at 20:49

я так и думал :(

Armmaster Jan 27 2022 at 20:48

Java
1 поток:
...
Эльбрус 16С в 1,7 раз медленнее на 1 поток чем Core i7 2600

А можно уточнить, как цифра 1.7 получилась? Просто я смотрю в результаты замеров на Джаве и вижу там другие результаты. Да и чисто из понимания теории, такой результат на Э16С выглядит крайне сомнительным.

EntityFX Feb 1 2022 at 22:42

Обсудили в чатиках.

VLev Jan 27 2022 at 20:54

Whetstone...
Эльбрус-16С показывает результаты кратные частоте (2000 / 1500).

вообще-то 1831/1723=1.06 -- какая-то ошибка, вероятно

по крайней мере

42467/16495/2=1.29
это уже ближе к 2000/1500=1.3(3)

EntityFX Jan 27 2022 at 21:01

Повторно перепроверю, поиграюсь флагами.

wigneddoom Jan 27 2022 at 21:10

Астрологи объявили неделю эльбрусов...

Baikal-S конечно интереснее выглядит.

perfect_genius Jan 28 2022 at 15:15

Чем он интереснее других ARM-процессоров?

JerleShannara Jan 28 2022 at 15:19

Тем, что его ещё как-то можно провести под лозунгом «Сделано в РФ».

perfect_genius Jan 31 2022 at 13:12

Но ведь у Эльбруса даже архитектура «Сделано в РФ».

JerleShannara Jan 31 2022 at 15:43

Но по факту и он и Байкал пройдут по одному и томуже классу в импортозамещении, поскольку выпечены на TSMC.

amartology Jan 28 2022 at 16:59

Чем он интереснее других ARM-процессоров?

И много вы знаете других 48-ядерных ARM-процессоров?
Не говоря уже о том, что Байкал-S не должен быть интереснее других ARM-процессоров, он должен быть интереснее конкретно вот этого Эльбруса.

lumag Jan 28 2022 at 18:34

Cavium/Marvell ThunderX/ ThunderX2 и т.д.

UFO just landed and posted this here

wigneddoom Jan 29 2022 at 20:01

В точку. Что у Байкал, что у Эльбрус только одно "конкурентное" преимущество - проходят под лозунгом "Сделано в РФ". Только у первого готовая экосистема софта и выше производительность.

Что касается других 48-х ARM. У нас на тестах был сервер Хуавей с их KunPeng 920 (48C, 2.6 GHz), вполне приличная машинка. Поэтому если Байкаловцы не врут, и Байкал S сможет работать на 2,5 GHz и производительность будет на уровне 0,7 KunPeng 920 или примерно Intel Xeon Gold 6148, то с этим уже можно работать.

Тут главное как у них пойдёт с поставками и что их партнёры смогут предложить в виде готового продукта.

perfect_genius Jan 31 2022 at 13:10

Только у первого готовая экосистема софта и выше производительность.

А у второго на одну точку отказа (санкции) меньше.

evil_kabab Jan 27 2022 at 22:16

Заходил на сайт мцст пару дней назад. У них нет SSL сертификата. Не то чтобы он просрочен или ещё чего, его там просто нет! Печатаешь https: и вываливается ошибка сервера...

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

+11

EntityFX Jan 27 2022 at 22:28

Да, надо им сказать. Let's Encrypt пусть поставят.

ogregor Jan 28 2022 at 00:11

Давно в кубер пора заворачивать. Сейчас даже школьник это делать умеет.

-8

computerix Jan 28 2022 at 07:30

Сарказм?

KGeist Jan 27 2022 at 22:58

Зашел на сайт разработчика сайта - у самих нет сертификата. Прошелся по кейсам клиентов - у половины тоже нет, при том что где-то есть вход/регистрация. Заинтересовало, откуда такая странная студия появилась. Выяснил, что их руководитель - юрист, который делал детский сайт о президенте на на kremlin.ru, сайт о патриархе Кирилле, в основном православные проекты. Сама студия названа в честь арабского правителя 6 века Арефы Эфиопского, которого в одной из войн сжёг омиритский царь-иудей Дунаан. В какой-то момент, читая википедию о христианских великомучениках, я задумался, "а при чем тут, собственно, процессоры Эльбрус", и прекратил исследование :)

+77

EntityFX Jan 28 2022 at 09:10

Лучший комментарий!

-1

IGR2014 Jan 28 2022 at 13:00

М'сье знает толк в исследованиях!)

Akr0n Jan 28 2022 at 02:28

Сейчас как воткнут ГОСТовый, вообще мало, кто зайдет на сайт.

CodeHolder Jan 28 2022 at 13:58

Будем продвигать хромиум-гост в массы.

liano Jan 27 2022 at 23:06

Сколько времени занимает компиляция Linux ядра?

1tuz Feb 2 2022 at 11:55

А генту можно поставить?)

forthuser Jan 27 2022 at 23:41

Жду ваши предложения, какие ещё бенчмарки можно прогнать на этих компьютерах

А, проверьте, если не сложно такой «тест»
vectorforth (SIMD vectorized Forth compiler with CPU based shader application)

EntityFX Jan 28 2022 at 09:42

Словил ошибки компиляции

 line 7861: error #350:
          more than one operator "*" matches these operands:
            function template
                      "jtk::Expr<jtk::BinExprOp<jtk::Constant<T>, jtk::matrix<T, Container>::const_iterator, jtk::OpMul                                                                                                                      <jtk::gettype<T, T2>::ty>>> jtk::operator*(T2, const jtk::matrix<T, Container> &)"
            function template
                      "jtk::matrix<double, Container> jtk::symmetric_sparse_matrix_wrapper<T>::operator*(const jtk::mat                                                                                                                      rix<double, Container> &) const [with T=double]"
            operand types are: const
                      jtk::symmetric_sparse_matrix_wrapper<double> *
                      jtk::matrix<double, std::vector<double,
                      std::allocator<double>>>
      matrix<T, Container> r = b - A * out;
                                     ^
          detected during:
            instantiation of
                      "void jtk::preconditioned_conjugate_gradient(jtk::matrix<T, Container> &, T &, uint32_t &, const                                                                                                                       jtk::symmetric_sparse_matrix_wrapper<T> &, const TPreconditioner &, const jtk::matrix<T, Container> &, const jtk::matri                                                                                                                      x<T, Container> &, T) [with T=double, Container=std::vector<double, std::allocator<double>>, TPreconditioner=jtk::diago                                                                                                                      nal_preconditioner<double>]"
                      at line 7917
            instantiation of
                      "void jtk::conjugate_gradient(jtk::matrix<T, Container> &, T &, uint32_t &, const jtk::symmetric_                                                                                                                      sparse_matrix_wrapper<T> &, const jtk::matrix<T, Container> &, const jtk::matrix<T, Container> &, T) [with T=double, Co                                                                                                                      ntainer=std::vector<double, std::allocator<double>>]"
                      at line 4739 of
                      "/root/vectorforth/jtk/jtk.tests/mat_tests.cpp"

lcc: "/root/vectorforth/jtk/jtk.tests/../jtk/mat.h", line 7861: error #350:
          more than one operator "*" matches these operands:
            function template
                      "jtk::Expr<jtk::BinExprOp<jtk::Constant<T>, jtk::matrix<T, Container>::const_iterator, jtk::OpMul                                                                                                                      <jtk::gettype<T, T2>::ty>>> jtk::operator*(T2, const jtk::matrix<T, Container> &)"
            function template
                      "jtk::matrix<float, Container> jtk::symmetric_sparse_matrix_wrapper<T>::operator*(const jtk::matr                                                                                                                      ix<float, Container> &) const [with T=float]"
            operand types are: const
                      jtk::symmetric_sparse_matrix_wrapper<float> *
                      jtk::matrix<float, std::vector<float,
                      std::allocator<float>>>
      matrix<T, Container> r = b - A * out;
                                     ^
          detected during instantiation of
                    "void jtk::preconditioned_conjugate_gradient(jtk::matrix<T, Container> &, T &, uint32_t &, const jt                                                                                                                      k::symmetric_sparse_matrix_wrapper<T> &, const TPreconditioner &, const jtk::matrix<T, Container> &, const jtk::matrix<                                                                                                                      T, Container> &, T) [with T=float, Container=std::vector<float, std::allocator<float>>, TPreconditioner=jtk::diagonal_p                                                                                                                      reconditioner<float>]"
                    at line 4773 of
                    "/root/vectorforth/jtk/jtk.tests/mat_tests.cpp"

lcc: "/opt/mcst/lcc-home/1.25.17/e2k-v5-linux/include/smmintrin.h", line 155: warning #1444:
          function "__builtin_ia32_dpps" (declared at line 3929 of
          "/opt/mcst/lcc-home/1.25.17/e2k-v5-linux/include/e2kbuiltin.h") was
          declared deprecated
          ("The function may be slow due to inefficient implementation, please try to avoid it")
          [-Wdeprecated-declarations]
    ((__m128) __builtin_ia32_dpps ((__v4sf)(__m128)(X),                   \
              ^
 in expansion of macro "_mm_dp_ps" at line 5318 of
           "/root/vectorforth/jtk/jtk.tests/../jtk/mat.h"
        __m128 d = _mm_dp_ps(v1, v2, 0xf1);
                   ^
          detected during instantiation of
                    "void jtk::preconditioned_conjugate_gradient(jtk::matrix<T, Container> &, T &, uint32_t &, const jt                                                                                                                      k::symmetric_sparse_matrix_wrapper<T> &, const TPreconditioner &, const jtk::matrix<T, Container> &, const jtk::matrix<                                                                                                                      T, Container> &, T) [with T=float, Container=std::vector<float, std::allocator<float>>, TPreconditioner=jtk::diagonal_p                                                                                                                      reconditioner<float>]"
                    at line 4773 of
                    "/root/vectorforth/jtk/jtk.tests/mat_tests.cpp"

2 errors detected in the compilation of "/root/vectorforth/jtk/jtk.tests/mat_tests.cpp".
make[2]: *** [jtk/jtk.tests/CMakeFiles/jtk.tests.dir/build.make:132: jtk/jtk.tests/CMakeFiles/jtk.tests.dir/mat_tests.c

Krey Jan 28 2022 at 00:32

Спасибо за ваш труд по портированию и тестам. Слежу с момента как узнал о вас в ролике Д. Бачило.

EntityFX Jan 28 2022 at 09:06

Да, Дмитрия обожаю, смотрю все его выпуски с 2014го.

aborouhin Jan 28 2022 at 00:55

Вот интересно, почему для сравнения выбран Core i7-2600 10-летней давности, у которого ядер меньше в 4 раза, потоков - в 2, память работает на в 2 с лишним раза меньшей частоте... Если уж мы оцениваем процессор 2021 года, давайте и возьмём в качестве конкурента какой-нибудь 11700K, хотя бы. А лучше, если потом ещё результаты тестов соотнести со стоимостью процессора - сколько производительности мы получаем на доллар/рубль.

+11

red_andr Jan 28 2022 at 01:25

Ну так будет совсем не честно! Кстати, техпроцесс тоже в два раза отличается. И да, разница более чем в десять лет. Core i7-2600 был запущен в продажу в январе 2011, а Эльбрус 16С, как видим, до сих пор доступен только в инженерных образцах. В серию хорошо если пойдёт к началу 2023 года, то есть будет уже 12 лет.

gshep Jan 28 2022 at 07:51

наверное просто потому, что у автора тестирования под рукой есть только Core i7-2600. Я предполагаю, что если вы - или кто-либо другой - погоняют эти же самые тесты на упомянутом 11700K или Райзене, то автор добавит эти результаты в статью.

PsihXMak Jan 28 2022 at 08:57

Вот мне тоже интересно. Уже столько статей вышло и ни в одной нет сравнения с акутальными моделями.

EntityFX Jan 28 2022 at 09:08

У меня есть только Core i7 2600 из самых мощных компов, работаю с ним уже 10 лет и все до сих пор летает (веб, разработка, игры не играю).

yamabusi Jan 28 2022 at 14:31

Очевидно конкретно в тесте Blender важнее многопоточность если E5-2620 v2 сделал Core i7 2600,нежели ГГц,с другой стороны у Elbrus 16C 16 ядер.

BkmzSpb Jan 29 2022 at 13:13

Недавно отправил на пенсию 2700K и заменил на 11700KF. Сразу предупреждаю, запускал на Windows как есть (чистое окружение не готовил). Имею проблемы с охлаждение, по моим прикидкам теряю примерно 1% частоты (0.05 ГГц) при продолжительной пиковой нагрузке.

Дотнетовский бенчмарк у меня один раз выпал с ArgumentOutOfRangeException при досутпе к какой-то коллекции. В остальные два раза 24 тест у меня просто не отрабатывал -- 0 загрузки CPU и 0 прогресса. Что-то странное с бенчмарком на сравнение строк параллельно -- потребляет не более 20% CPU cycles, возможно там какой-то data race происходит (либо может это IO-bound/GC-heavy, но я не заметил ни давления на память ни доступа к диску). На джаве параллельные строки работали действительно праллельно с загрузкой в 100%.

Т.к. в джаве не шарю, запустил бинарник "как есть".

Возможно я что-то еще делаю не так, но тест блендера занял у меня 22 секунды.

& 'C:\Program Files\Blender Foundation\Blender 3.0\blender.exe' -b RyzenGraphic_27.blend  -f 1 -- --cycles-device CPU.log

Бенчмарк Blender

Blender 3.0.1 (hash dc2d18018171 built 2022-01-26 01:46:57)
Read blend: C:\Users\[redacted]\Downloads\RyzenGraphic_27.blend
Fra:1 Mem:63.36M (Peak 65.44M) | Time:00:00.04 | Mem:0.00M, Peak:0.00M | Scene, RenderLayer | Synchronizing object | Plane.006
Fra:1 Mem:63.37M (Peak 65.44M) | Time:00:00.04 | Mem:0.00M, Peak:0.00M | Scene, RenderLayer | Synchronizing object | Plane.005
Fra:1 Mem:63.37M (Peak 65.44M) | Time:00:00.04 | Mem:0.00M, Peak:0.00M | Scene, RenderLayer | Synchronizing object | Plane.003
Fra:1 Mem:63.37M (Peak 65.44M) | Time:00:00.04 | Mem:0.00M, Peak:0.00M | Scene, RenderLayer | Synchronizing object | Plane.001
Fra:1 Mem:63.37M (Peak 65.44M) | Time:00:00.04 | Mem:0.00M, Peak:0.00M | Scene, RenderLayer | Synchronizing object | Curve.002
Fra:1 Mem:63.38M (Peak 65.44M) | Time:00:00.04 | Mem:0.00M, Peak:0.00M | Scene, RenderLayer | Synchronizing object | chip_master pin_001 pin_grp372.001
Fra:1 Mem:63.40M (Peak 65.44M) | Time:00:00.04 | Mem:0.00M, Peak:0.00M | Scene, RenderLayer | Synchronizing object | chip_master gold_plane.001
Fra:1 Mem:63.40M (Peak 65.44M) | Time:00:00.04 | Mem:0.00M, Peak:0.00M | Scene, RenderLayer | Synchronizing object | chip_master numbers.001
Fra:1 Mem:65.56M (Peak 65.95M) | Time:00:00.05 | Mem:0.00M, Peak:0.00M | Scene, RenderLayer | Synchronizing object | chip_master D_letter.001
Fra:1 Mem:64.84M (Peak 65.95M) | Time:00:00.05 | Mem:0.00M, Peak:0.00M | Scene, RenderLayer | Synchronizing object | chip_master middle_layer.001
Fra:1 Mem:65.05M (Peak 65.95M) | Time:00:00.05 | Mem:0.00M, Peak:0.00M | Scene, RenderLayer | Synchronizing object | black_glue chip_master.001
Fra:1 Mem:65.47M (Peak 65.95M) | Time:00:00.05 | Mem:0.00M, Peak:0.00M | Scene, RenderLayer | Synchronizing object | chip_master top_layer.001
Fra:1 Mem:65.78M (Peak 65.95M) | Time:00:00.05 | Mem:0.00M, Peak:0.00M | Scene, RenderLayer | Synchronizing object | chip_master gold_plane_back.001
Fra:1 Mem:65.79M (Peak 65.95M) | Time:00:00.05 | Mem:0.00M, Peak:0.00M | Scene, RenderLayer | Synchronizing object | chip_master heat_spreader.001
Fra:1 Mem:66.48M (Peak 66.48M) | Time:00:00.05 | Mem:0.00M, Peak:0.00M | Scene, RenderLayer | Synchronizing object | chip_master bottom_layer.001
Fra:1 Mem:66.09M (Peak 67.06M) | Time:00:00.05 | Mem:0.00M, Peak:0.00M | Scene, RenderLayer | Synchronizing object | Plane.004
Fra:1 Mem:64.23M (Peak 67.06M) | Time:00:00.05 | Mem:0.00M, Peak:0.00M | Scene, RenderLayer | Initializing
Fra:1 Mem:58.38M (Peak 67.06M) | Time:00:00.05 | Mem:0.00M, Peak:0.00M | Scene, RenderLayer | Updating Images | Loading Enso.png
Fra:1 Mem:58.38M (Peak 67.06M) | Time:00:00.05 | Mem:0.00M, Peak:0.00M | Scene, RenderLayer | Updating Images | Loading summitRidge_color.jpg
Fra:1 Mem:295.96M (Peak 826.42M) | Time:00:00.47 | Mem:256.00M, Peak:256.00M | Scene, RenderLayer | Waiting for render to start
Fra:1 Mem:295.96M (Peak 826.42M) | Time:00:00.47 | Mem:256.00M, Peak:256.00M | Scene, RenderLayer | Loading render kernels (may take a few minutes the first time)
Fra:1 Mem:295.96M (Peak 826.42M) | Time:00:00.47 | Mem:256.00M, Peak:256.00M | Scene, RenderLayer | Updating Scene
Fra:1 Mem:295.96M (Peak 826.42M) | Time:00:00.47 | Mem:256.00M, Peak:256.00M | Scene, RenderLayer | Updating Shaders
Fra:1 Mem:296.47M (Peak 826.42M) | Time:00:00.48 | Mem:256.01M, Peak:256.01M | Scene, RenderLayer | Updating Procedurals
Fra:1 Mem:296.47M (Peak 826.42M) | Time:00:00.48 | Mem:256.01M, Peak:256.01M | Scene, RenderLayer | Updating Background
Fra:1 Mem:296.47M (Peak 826.42M) | Time:00:00.48 | Mem:256.01M, Peak:256.01M | Scene, RenderLayer | Updating Camera
Fra:1 Mem:296.47M (Peak 826.42M) | Time:00:00.48 | Mem:256.01M, Peak:256.01M | Scene, RenderLayer | Updating Meshes Flags
Fra:1 Mem:296.47M (Peak 826.42M) | Time:00:00.48 | Mem:256.01M, Peak:256.01M | Scene, RenderLayer | Updating Objects
Fra:1 Mem:296.47M (Peak 826.42M) | Time:00:00.48 | Mem:256.01M, Peak:256.01M | Scene, RenderLayer | Updating Objects | Copying Transformations to device
Fra:1 Mem:296.75M (Peak 826.42M) | Time:00:00.48 | Mem:256.27M, Peak:256.27M | Scene, RenderLayer | Updating Objects | Applying Static Transformations
Fra:1 Mem:296.75M (Peak 826.42M) | Time:00:00.48 | Mem:256.27M, Peak:256.27M | Scene, RenderLayer | Updating Particle Systems
Fra:1 Mem:296.75M (Peak 826.42M) | Time:00:00.48 | Mem:256.27M, Peak:256.27M | Scene, RenderLayer | Updating Particle Systems | Copying Particles to device
Fra:1 Mem:296.75M (Peak 826.42M) | Time:00:00.48 | Mem:256.27M, Peak:256.27M | Scene, RenderLayer | Updating Meshes
Fra:1 Mem:297.11M (Peak 826.42M) | Time:00:00.48 | Mem:256.27M, Peak:256.27M | Scene, RenderLayer | Updating Mesh | Computing attributes
Fra:1 Mem:297.24M (Peak 826.42M) | Time:00:00.48 | Mem:256.27M, Peak:256.27M | Scene, RenderLayer | Updating Mesh | Copying Attributes to device
Fra:1 Mem:297.16M (Peak 826.42M) | Time:00:00.48 | Mem:256.33M, Peak:256.33M | Scene, RenderLayer | Updating Geometry BVH chip_master pin_001 pin_grp1848.001 1/1 | Building BVH
Fra:1 Mem:297.16M (Peak 826.42M) | Time:00:00.48 | Mem:256.35M, Peak:256.35M | Scene, RenderLayer | Updating Geometry BVH chip_master pin_001 pin_grp1848.001 1/1 | Building BVH 0%
Fra:1 Mem:297.16M (Peak 826.42M) | Time:00:00.48 | Mem:256.34M, Peak:256.36M | Scene, RenderLayer | Updating Scene BVH | Building
Fra:1 Mem:297.17M (Peak 826.42M) | Time:00:00.48 | Mem:256.34M, Peak:256.36M | Scene, RenderLayer | Updating Scene BVH | Building BVH
Fra:1 Mem:297.17M (Peak 826.42M) | Time:00:00.49 | Mem:257.67M, Peak:258.67M | Scene, RenderLayer | Updating Scene BVH | Copying BVH to device
Fra:1 Mem:297.17M (Peak 826.42M) | Time:00:00.49 | Mem:257.67M, Peak:258.67M | Scene, RenderLayer | Updating Mesh | Computing normals
Fra:1 Mem:299.10M (Peak 826.42M) | Time:00:00.49 | Mem:257.67M, Peak:258.67M | Scene, RenderLayer | Updating Mesh | Copying Mesh to device
Fra:1 Mem:299.10M (Peak 826.42M) | Time:00:00.49 | Mem:259.59M, Peak:259.59M | Scene, RenderLayer | Updating Objects Flags
Fra:1 Mem:299.10M (Peak 826.42M) | Time:00:00.49 | Mem:259.60M, Peak:259.60M | Scene, RenderLayer | Updating Images
Fra:1 Mem:299.10M (Peak 826.42M) | Time:00:00.49 | Mem:259.60M, Peak:259.60M | Scene, RenderLayer | Updating Camera Volume
Fra:1 Mem:299.10M (Peak 826.42M) | Time:00:00.49 | Mem:259.60M, Peak:259.60M | Scene, RenderLayer | Updating Lookup Tables
Fra:1 Mem:299.10M (Peak 826.42M) | Time:00:00.49 | Mem:259.85M, Peak:259.85M | Scene, RenderLayer | Updating Lights
Fra:1 Mem:299.10M (Peak 826.42M) | Time:00:00.49 | Mem:259.85M, Peak:259.85M | Scene, RenderLayer | Updating Lights | Computing distribution
Fra:1 Mem:299.10M (Peak 826.42M) | Time:00:00.49 | Mem:259.85M, Peak:259.85M | Scene, RenderLayer | Updating Integrator
Fra:1 Mem:299.10M (Peak 826.42M) | Time:00:00.49 | Mem:259.86M, Peak:259.86M | Scene, RenderLayer | Updating Film
Fra:1 Mem:299.11M (Peak 826.42M) | Time:00:00.49 | Mem:259.61M, Peak:259.86M | Scene, RenderLayer | Updating Lookup Tables
Fra:1 Mem:299.11M (Peak 826.42M) | Time:00:00.49 | Mem:259.87M, Peak:259.87M | Scene, RenderLayer | Updating Baking
Fra:1 Mem:299.11M (Peak 826.42M) | Time:00:00.49 | Mem:259.87M, Peak:259.87M | Scene, RenderLayer | Updating Device | Writing constant memory
Fra:1 Mem:299.13M (Peak 826.42M) | Time:00:00.49 | Mem:259.87M, Peak:259.87M | Scene, RenderLayer | Sample 0/150
Fra:1 Mem:311.38M (Peak 826.42M) | Time:00:00.64 | Remaining:00:22.91 | Mem:272.09M, Peak:272.09M | Scene, RenderLayer | Sample 1/150
Fra:1 Mem:323.59M (Peak 826.42M) | Time:00:21.32 | Mem:272.09M, Peak:272.09M | Scene, RenderLayer | Sample 150/150
Fra:1 Mem:323.59M (Peak 826.42M) | Time:00:21.32 | Mem:272.09M, Peak:272.09M | Scene, RenderLayer | Finished
Saved: 'C:\tmp\0001.png'
 Time: 00:21.93 (Saving: 00:00.57)


Blender quit

dotnet 6.0

Warmup
........................
Bench
[1] ArithemticsBenchmark
ArithemticsBenchmark                   939.62 ms        9578.35 pts   319279093.35 Iter/s
Iterrations:       300000000, Ratio:            0.03
[2] ParallelArithemticsBenchmark
ParallelArithemticsBenchmark          2048.15 ms       71348.99 pts   146473632.65 Iter/s
Iterrations:       300000000, Ratio:            0.03
[3] MathBenchmark
MathBenchmark                         8839.98 ms       11312.24 pts    22624489.41 Iter/s
Iterrations:       200000000, Ratio:             0.5
[4] ParallelMathBenchmark
ParallelMathBenchmark                16034.94 ms      101111.87 pts    12472762.22 Iter/s
Iterrations:       200000000, Ratio:             0.5
[5] CallBenchmark
CallBenchmark                         5052.00 ms        1980.57 pts   198056609.13 Iter/s
Iterrations:      2000000000, Ratio:            0.01
[6] ParallelCallBenchmark
ParallelCallBenchmark                10741.28 ms       30260.08 pts   186197518.68 Iter/s
Iterrations:      2000000000, Ratio:            0.01
[7] IfElseBenchmark
IfElseBenchmark                       2439.66 ms        8197.86 pts   819786229.26 Iter/s
Iterrations:      2000000000, Ratio:            0.01
[8] ParallelIfElseBenchmark
ParallelIfElseBenchmark               2700.96 ms      125556.16 pts   740478063.00 Iter/s
Iterrations:      2000000000, Ratio:            0.01
[9] StringManipulation
StringManipulation                    3450.07 ms       14492.44 pts     1449246.34 Iter/s
Iterrations:         5000000, Ratio:              10
[10] ParallelStringManipulation
ParallelStringManipulation           78165.57 ms       10256.57 pts       63966.79 Iter/s
Iterrations:         5000000, Ratio:              10
[11] MemoryBenchmark
MemoryBenchmark                       1277.64 ms       22872.52 pts       22872.52 MB/s
Iterrations:          500000, Ratio:               1
[12] ParallelMemoryBenchmark
ParallelMemoryBenchmark              12719.73 ms      181774.73 pts      181774.73 MB/s
Iterrations:          500000, Ratio:               1
[13] RandomMemoryBenchmark
RandomMemoryBenchmark                 2350.07 ms       18237.67 pts        9118.84 MB/s
Iterrations:          500000, Ratio:               2
[14] ParallelRandomMemoryBenchmark
ParallelRandomMemoryBenchmark         5549.28 ms      251701.26 pts      125850.63 MB/s
Iterrations:          500000, Ratio:               2
[15] Scimark2Benchmark
Scimark2Benchmark                    16709.78 ms       11746.67 pts        1174.67 CompositeScore
Iterrations:               0, Ratio:              10
[16] ParallelScimark2Benchmark
ParallelScimark2Benchmark            15436.11 ms      119686.33 pts       11968.63 CompositeScore
Iterrations:               0, Ratio:              10
[17] DhrystoneBenchmark
DhrystoneBenchmark                    1348.17 ms       34053.50 pts        8513.38 DMIPS
Iterrations:               0, Ratio:               4
[18] ParallelDhrystoneBenchmark
ParallelDhrystoneBenchmark            3000.43 ms      245741.61 pts       61435.40 DMIPS
Iterrations:               0, Ratio:               4
[19] WhetstoneBenchmark
WhetstoneBenchmark                  109342.94 ms        7165.07 pts        7165.07 MWIPS
Iterrations:               0, Ratio:               1
[20] ParallelWhetstoneBenchmark
ParallelWhetstoneBenchmark          110528.07 ms      103971.71 pts      103971.71 MWIPS
Iterrations:               0, Ratio:               1
[21] LinpackBenchmark
LinpackBenchmark                      2483.89 ms       22565.84 pts        2256.58 MFLOPS
Iterrations:               0, Ratio:              10
[22] ParallelLinpackBenchmark
ParallelLinpackBenchmark             17634.09 ms        5080.34 pts        5080.34 MFLOPS
Iterrations:               0, Ratio:              10
[23] HashBenchmark
HashBenchmark                         2158.10 ms        9267.41 pts      926743.69 Iter/s
Iterrations:         2000000, Ratio:              10

Java openjdk version "1.8.0_292"

Warmup
........................
Bench
[1] ArithemticsBenchmark
ArithemticsBenchmark                      872 ms     10321.08 pts   344036697.25 Iter/s
Iterrations:       300000000, Ratio:        0.030000
[2] ParallelArithemticsBenchmark
ParallelArithemticsBenchmark             2447 ms     58876.02 pts  1962538061.39 Iter/s
Iterrations:       300000000, Ratio:        0.030000
[3] MathBenchmark
MathBenchmark                           90900 ms      1100.00 pts     2200220.02 Iter/s
Iterrations:       200000000, Ratio:        0.500000
[4] ParallelMathBenchmark
ParallelMathBenchmark                  135701 ms     11940.00 pts    23888908.06 Iter/s
Iterrations:       200000000, Ratio:        0.500000
[5] CallBenchmark
Elapsed No Call: 0
Elapsed Call: 4968
CallBenchmark                            4968 ms      4024.14 pts   402414486.92 Iter/s
Iterrations:      2000000000, Ratio:        0.010000
[6] ParallelCallBenchmark
ParallelCallBenchmark                    5285 ms     61852.27 pts  6185233887.08 Iter/s
Iterrations:      2000000000, Ratio:        0.010000
[7] IfElseBenchmark
IfElseBenchmark                          1243 ms     16090.10 pts  1609010458.57 Iter/s
Iterrations:      2000000000, Ratio:        0.010000
[8] ParallelIfElseBenchmark
ParallelIfElseBenchmark                  2579 ms    127079.06 pts 12707911543.49 Iter/s
Iterrations:      2000000000, Ratio:        0.010000
[9] StringManipulation
StringManipulation                       6487 ms      7700.00 pts      770772.31 Iter/s
Iterrations:         5000000, Ratio:       10.000000
[10] ParallelStringManipulation
ParallelStringManipulation              18905 ms     42680.00 pts     4275397.06 Iter/s
Iterrations:         5000000, Ratio:       10.000000
[11] MemoryBenchmark
int 4k: 24112.65 MB/s
int 512k: 21943.82 MB/s
int 8M: 20989.25 MB/s
int 32M: 16827.59 MB/s
long 4k: 47063.25 MB/s
long 512k: 34566.37 MB/s
long 8M: 23100.59 MB/s
long 32M: 21810.06 MB/s
Average: 26301.70 MB/s
MemoryBenchmark                           955 ms     26301.70 pts       26301.70 MB/s
Iterrations:          500000, Ratio:        1.000000
[12] ParallelMemoryBenchmark
ParallelMemoryBenchmark                  5413 ms    147934.36 pts      147934.36 MB/s
Iterrations:          500000, Ratio:        1.000000
[13] RandomMemoryBenchmark
Random int 4k: 17918.58 MB/s
Random int 512k: 17594.59 MB/s
Random int 8M: 16973.91 MB/s
Random long 4k: 36168.98 MB/s
Random long 512k: 34875.00 MB/s
Random long 8M: 33367.52 MB/s
Average: 26149.76 MB/s
RandomMemoryBenchmark                     687 ms     52299.53 pts       26149.76 MB/s
Iterrations:          500000, Ratio:        2.000000
[14] ParallelRandomMemoryBenchmark
ParallelRandomMemoryBenchmark            2411 ms    331520.67 pts      165760.33 MB/s
Iterrations:          500000, Ratio:        2.000000
[15] Scimark2Benchmark
Scimark2Benchmark                       34367 ms     31676.80 pts        3167.68 CompositeScore
Iterrations:               0, Ratio:       10.000000
[16] ParallelScimark2Benchmark
ParallelScimark2Benchmark               27409 ms    314022.20 pts       31402.22 CompositeScore
Iterrations:               0, Ratio:       10.000000
[17] DhrystoneBenchmark
DhrystoneBenchmark                        295 ms    157004.00 pts       39251.00 DMIPS
Iterrations:               0, Ratio:        4.000000
[18] ParallelDhrystoneBenchmark
ParallelDhrystoneBenchmark               1127 ms    741844.00 pts      185461.00 DMIPS
Iterrations:               0, Ratio:        4.000000
[19] WhetstoneBenchmark
WhetstoneBenchmark                      31267 ms      1591.34 pts        1591.34 MWIPS
Iterrations:               0, Ratio:        1.000000
[20] ParallelWhetstoneBenchmark
ParallelWhetstoneBenchmark              32012 ms     22219.28 pts       22219.28 MWIPS
Iterrations:               0, Ratio:        1.000000
[21] LinpackBenchmark
LinpackBenchmark                         1345 ms     42190.63 pts        4219.06 MFLOPS
Iterrations:               0, Ratio:       10.000000
[22] ParallelLinpackBenchmark
ParallelLinpackBenchmark                16789 ms     51935.02 pts        5193.50 MFLOPS
Iterrations:               0, Ratio:       10.000000
[23] HashBenchmark
HashBenchmark                            1290 ms     15500.00 pts     1550387.60 Iter/s
Iterrations:         2000000, Ratio:       10.000000
[24] ParallelHashBenchmark
ParallelHashBenchmark                   13803 ms     23830.00 pts     2392870.31 Iter/s
Iterrations:         2000000, Ratio:       10.000000

Total:                                 438557 ms   2301532.18 pts

Single-thread results
Operating System,Runtime,Threads Count,Memory Used,ArithemticsBenchmark,MathBenchmark,CallBenchmark,IfElseBenchmark,StringManipulation,MemoryBenchmark,RandomMemoryBenchmark,ParallelRandomMemoryBenchmark,Scimark2Benchmark,DhrystoneBenchmark,WhetstoneBenchmark,LinpackBenchmark,HashBenchmark,Total Points,Total Time (ms)
Windows 10 10.0 amd64,Java Version 1.8.0_292,16,151860336,10321.08,1100.00,4024.14,16090.10,7700.00,26301.70,52299.53,331520.67,31676.80,157004.00,1591.34,42190.63,15500.00,2301532.18,438557
All results
Operating System,Runtime,Threads Count,Memory Used,ArithemticsBenchmark,ParallelArithemticsBenchmark,MathBenchmark,ParallelMathBenchmark,CallBenchmark,ParallelCallBenchmark,IfElseBenchmark,ParallelIfElseBenchmark,StringManipulation,ParallelStringManipulation,MemoryBenchmark,ParallelMemoryBenchmark,RandomMemoryBenchmark,ParallelRandomMemoryBenchmark,Scimark2Benchmark,ParallelScimark2Benchmark,DhrystoneBenchmark,ParallelDhrystoneBenchmark,WhetstoneBenchmark,ParallelWhetstoneBenchmark,LinpackBenchmark,ParallelLinpackBenchmark,HashBenchmark,ParallelHashBenchmark,Total Points,Total Time (ms)
Windows 10 10.0 amd64,Java Version 1.8.0_292,16,151860336;10321.08;58876.02;1100.00;11940.00;4024.14;61852.27;16090.10;127079.06;7700.00;42680.00;26301.70;147934.36;52299.53;331520.67;31676.80;314022.20;157004.00;741844.00;1591.34;22219.28;42190.63;51935.02;15500.00;23830.00;2301532.18;438557
Single-thread  Units results
Operating System,Runtime,Threads Count,Memory Used,ArithemticsBenchmark (Iter/s),MathBenchmark (Iter/s),CallBenchmark (Iter/s),IfElseBenchmark (Iter/s),StringManipulation (Iter/s),MemoryBenchmark (MB/s),RandomMemoryBenchmark (MB/s),ParallelRandomMemoryBenchmark (MB/s),Scimark2Benchmark (CompositeScore),DhrystoneBenchmark (DMIPS),WhetstoneBenchmark (MWIPS),LinpackBenchmark (MFLOPS),HashBenchmark (Iter/s),Total Points,Total Time (ms)
Windows 10 10.0 amd64,Java Version 1.8.0_292,16,151860336,344036697.25,2200220.02,402414486.92,1609010458.57,770772.31,26301.70,26149.76,165760.33,3167.68,39251.00,1591.34,4219.06,1550387.60;2301532.18;438557
All  Units results
Operating System,Runtime,Threads Count,Memory Used,ArithemticsBenchmark (Iter/s),ParallelArithemticsBenchmark (Iter/s),MathBenchmark (Iter/s),ParallelMathBenchmark (Iter/s),CallBenchmark (Iter/s),ParallelCallBenchmark (Iter/s),IfElseBenchmark (Iter/s),ParallelIfElseBenchmark (Iter/s),StringManipulation (Iter/s),ParallelStringManipulation (Iter/s),MemoryBenchmark (MB/s),ParallelMemoryBenchmark (MB/s),RandomMemoryBenchmark (MB/s),ParallelRandomMemoryBenchmark (MB/s),Scimark2Benchmark (CompositeScore),ParallelScimark2Benchmark (CompositeScore),DhrystoneBenchmark (DMIPS),ParallelDhrystoneBenchmark (DMIPS),WhetstoneBenchmark (MWIPS),ParallelWhetstoneBenchmark (MWIPS),LinpackBenchmark (MFLOPS),ParallelLinpackBenchmark (MFLOPS),HashBenchmark (Iter/s),ParallelHashBenchmark (Iter/s),Total Points,Total Time (ms)
Windows 10 10.0 amd64,Java Version 1.8.0_292,16,151860336,344036697.25,1962538061.39,2200220.02,23888908.06,402414486.92,6185233887.08,1609010458.57,12707911543.49,770772.31,4275397.06,26301.70,147934.36,26149.76,165760.33,3167.68,31402.22,39251.00,185461.00,1591.34,22219.28,4219.06,5193.50,1550387.60,2392870.31,2301532.18,438557

CPU-Z

Processors Information
-------------------------------------------------------------------------

Socket 1			ID = 0
	Number of cores		8 (max 8)
	Number of threads	16 (max 16)
	Manufacturer		GenuineIntel
	Name			Intel Core i7 11700KF
	Codename		Rocket Lake
	Specification		11th Gen Intel(R) Core(TM) i7-11700KF @ 3.60GHz
	Package (platform ID)	Socket 1200 LGA (0x1)
	CPUID			6.7.1
	Extended CPUID		6.A7
	Core Stepping		B0
	Technology		14 nm
	TDP Limit		125.0 Watts
	Tjmax			100.0 �C
	Core Speed		4889.2 MHz
	Multiplier x Bus Speed	49.0 x 99.8 MHz
	Base frequency (cores)	99.8 MHz
	Base frequency (ext.)	99.8 MHz
	Stock frequency		3600 MHz
	Max frequency		0 MHz
	Instructions sets	MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, EM64T, AES, AVX, AVX2, AVX512F, FMA3, SHA
	Microcode Revision	0x3C
	L1 Data cache		8 x 48 KB (12-way, 64-byte line)
	L1 Instruction cache	8 x 32 KB (8-way, 64-byte line)
	L2 cache		8 x 512 KB (8-way, 64-byte line)
	L3 cache		16 MB (16-way, 64-byte line)
	Preferred cores		2 (#2, #3)
	Max CPUID level		0000001Bh
	Max CPUID ext. level	80000008h
	FID/VID Control		yes


	Turbo Mode		supported, enabled
	Max non-turbo ratio	36x
	Max turbo ratio		50x
	Max efficiency ratio	8x
	Min operating ratio	8x
	Speedshift		Autonomous
	FLL_OC_MODE		0
	FLL_OC_MODE_REG		0x00000000
	O/C bins		unlimited
	Ratio 1 core		50x
	Ratio 2 cores		50x
	Ratio 3 cores		49x
	Ratio 4 cores		49x
	Ratio 5 cores		49x
	Ratio 6 cores		49x
	Ratio 7 cores		49x
	Ratio 8 cores		49x
	IA Voltage Mode		PCU adaptive
	IA Voltage Offset	0 mV
	GT Voltage Mode		PCU adaptive
	GT Voltage Offset	0 mV
	LLC/Ring Voltage Mode	PCU adaptive
	LLC/Ring Voltage Offset	0 mV
	Agent Voltage Mode	Override
	Agent Voltage Target	1075 mV
	Agent Voltage Offset	0 mV
	TDP Level		125.0 W @ 36x
	TDP Level		95.0 W @ 31x

	Temperature 0		50 degC (122 degF) (Package)
	Temperature 1		42 degC (107 degF) (Core #0)
	Temperature 2		39 degC (102 degF) (Core #1)
	Temperature 3		39 degC (102 degF) (Core #2)
	Temperature 4		36 degC (96 degF) (Core #3)
	Temperature 5		37 degC (98 degF) (Core #4)
	Temperature 6		43 degC (109 degF) (Core #5)
	Temperature 7		39 degC (102 degF) (Core #6)
	Temperature 8		37 degC (98 degF) (Core #7)
	Voltage 0		1.46 Volts (VID)
	Voltage 1		+0.00 Volts (IA Offset)
	Voltage 2		+0.00 Volts (GT Offset)
	Voltage 3		+0.00 Volts (LLC/Ring Offset)
	Voltage 4		1.08 Volts (System Agent)
	Power 00		38.60 W (Package)
	Power 01		27.07 W (IA Cores)
	Power 02		n.a. (GT)
	Power 03		11.53 W (Uncore)
	Power 04		n.a. (DRAM)
	Clock Speed 0		4889.22 MHz (Core #0)
	Clock Speed 1		4889.22 MHz (Core #1)
	Clock Speed 2		4889.22 MHz (Core #2)
	Clock Speed 3		4889.22 MHz (Core #3)
	Clock Speed 4		4889.22 MHz (Core #4)
	Clock Speed 5		4889.22 MHz (Core #5)
	Clock Speed 6		4889.22 MHz (Core #6)
	Clock Speed 7		4889.22 MHz (Core #7)
	Core 0 max ratio	49.00 (effective 49.00)
	Core 1 max ratio	49.00 (effective 49.00)
	Core 2 max ratio	50.00 (effective 50.00)
	Core 3 max ratio	50.00 (effective 50.00)
	Core 4 max ratio	49.00 (effective 49.00)
	Core 5 max ratio	49.00 (effective 49.00)
	Core 6 max ratio	49.00 (effective 49.00)
	Core 7 max ratio	49.00 (effective 49.00)

BkmzSpb Jan 29 2022 at 13:57

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

Paskin Jan 30 2022 at 08:46

А чем вы под него тесты компилировали?

yamabusi Jan 28 2022 at 14:14

Просто ради интереса отрендерил сцену в Blender на копееченом Зеон с Алика(Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz),6 ядер/12 потоков.

На 1 секунду медленнее вышло.
https://radikal.ru/lfp/d.radikal.ru/d05/2201/0a/227d8f126617t.jpg/htm

Я понимаю что там далеко не оптимизированно,но в этом плане разница производительность/доллар космическая мягко сказать.)

checkpoint Jan 28 2022 at 03:24

Что там с тестами кэш памяти ? Это самый важный показатель для СУБД.

EntityFX Jan 28 2022 at 09:15

Да, есть: www.altlinux.org/Эльбрус/тесты/результаты#Тест_латентности_кеша

checkpoint Jan 28 2022 at 11:36

Хорошая табличка, спасибо.

Видно, что у Э-16С кэш почти в полтора раза медленее чем у Э-8СВ, при том, что частота DDR выше (DDR4-2400 у Э-8СВ и DDR4-3200 у Э-16С если верить спецификации). Не ожиданно.

EntityFX Jan 28 2022 at 12:12

Инженерник, там частично отключены некоторые кеш-линии, это всё влияет на результаты. Память работает на DDR4-2400, в серийном должна на DDR4-3200.

checkpoint Jan 28 2022 at 14:50

Понятно. Значит ждем релиза.

EntityFX Jan 28 2022 at 16:01

EntityFX Jan 28 2022 at 20:34

STREAM

-------------------------------------------------------------
STREAM version $Revision: 5.10 $
-------------------------------------------------------------
This system uses 8 bytes per array element.
-------------------------------------------------------------
Array size = 10000000 (elements), Offset = 0 (elements)
Memory per array = 76.3 MiB (= 0.1 GiB).
Total memory required = 228.9 MiB (= 0.2 GiB).
Each kernel will be executed 10 times.
 The *best* time for each kernel (excluding the first iteration)
 will be used to compute the reported bandwidth.
-------------------------------------------------------------
Your clock granularity/precision appears to be 1 microseconds.
Each test below will take on the order of 5202 microseconds.
   (= 5202 clock ticks)
Increase the size of the arrays if this shows that
you are not getting at least 20 clock ticks per test.
-------------------------------------------------------------
WARNING -- The above is only a rough guideline.
For best results, please be sure you know the
precision of your system timer.
-------------------------------------------------------------
Function    Best Rate MB/s  Avg time     Min time     Max time
Copy:           20090.1     0.007969     0.007964     0.007975
Scale:          19408.0     0.008253     0.008244     0.008262
Add:            21848.2     0.010992     0.010985     0.011005
Triad:          22284.0     0.010776     0.010770     0.010796
-------------------------------------------------------------
Solution Validates: avg error less than 1.000000e-13 on all three arrays
-------------------------------------------------------------

checkpoint Jan 28 2022 at 22:26

Это тест для Э-16С ? А можно такой же тест для Э-8СВ, ну и для интелла ? Заранее большое спасибо.

EntityFX Feb 1 2022 at 22:54

8CВ, 4 планки DDR4-2400 по 8 ГБ

-------------------------------------------------------------
STREAM version $Revision: 5.10 $
-------------------------------------------------------------
This system uses 8 bytes per array element.
-------------------------------------------------------------
Array size = 200000000 (elements), Offset = 0 (elements)
Memory per array = 1525.9 MiB (= 1.5 GiB).
Total memory required = 4577.6 MiB (= 4.5 GiB).
Each kernel will be executed 10 times.
 The *best* time for each kernel (excluding the first iteration)
 will be used to compute the reported bandwidth.
-------------------------------------------------------------
Number of Threads requested = 8
Number of Threads counted = 8
-------------------------------------------------------------
Your clock granularity/precision appears to be 1 microseconds.
Each test below will take on the order of 89796 microseconds.
   (= 89796 clock ticks)
Increase the size of the arrays if this shows that
you are not getting at least 20 clock ticks per test.
-------------------------------------------------------------
WARNING -- The above is only a rough guideline.
For best results, please be sure you know the
precision of your system timer.
-------------------------------------------------------------
Function    Best Rate MB/s  Avg time     Min time     Max time
Copy:           22845.9     0.140402     0.140069     0.140706
Scale:          22963.4     0.139740     0.139352     0.140096
Add:            25437.5     0.189290     0.188698     0.191004
Triad:          25591.7     0.188562     0.187561     0.188898
-------------------------------------------------------------
Solution Validates: avg error less than 1.000000e-13 on all three arrays
-------------------------------------------------------------

Core i7 2600, 2 планки DDR3-1333 по 8 ГБ

-------------------------------------------------------------
STREAM version $Revision: 5.10 $
-------------------------------------------------------------
This system uses 8 bytes per array element.
-------------------------------------------------------------
Array size = 100000000 (elements), Offset = 0 (elements)
Memory per array = 762.9 MiB (= 0.7 GiB).
Total memory required = 2288.8 MiB (= 2.2 GiB).
Each kernel will be executed 10 times.
 The *best* time for each kernel (excluding the first iteration)
 will be used to compute the reported bandwidth.
-------------------------------------------------------------
Number of Threads requested = 8
Number of Threads counted = 8
-------------------------------------------------------------
Your clock granularity/precision appears to be 2 microseconds.
Each test below will take on the order of 119145 microseconds.
   (= 59572 clock ticks)
Increase the size of the arrays if this shows that
you are not getting at least 20 clock ticks per test.
-------------------------------------------------------------
WARNING -- The above is only a rough guideline.
For best results, please be sure you know the
precision of your system timer.
-------------------------------------------------------------
Function    Best Rate MB/s  Avg time     Min time     Max time
Copy:           11514.5     0.147185     0.138955     0.160230
Scale:          11379.7     0.148755     0.140601     0.160839
Add:            12667.7     0.197619     0.189458     0.207608
Triad:          12650.8     0.198835     0.189712     0.213622
-------------------------------------------------------------
Solution Validates: avg error less than 1.000000e-13 on all three arrays
-------------------------------------------------------------

checkpoint Feb 1 2022 at 23:27

Благодарю!

EntityFX Feb 2 2022 at 01:48

ПСП на Эльбрус-16С 8 планок по 8 ГБ (DDR4-2400):

STREAM version $Revision: 5.10 $
-------------------------------------------------------------
This system uses 8 bytes per array element.
-------------------------------------------------------------
Array size = 10000000 (elements), Offset = 0 (elements)
Memory per array = 76.3 MiB (= 0.1 GiB).
Total memory required = 228.9 MiB (= 0.2 GiB).
Each kernel will be executed 10 times.
 The *best* time for each kernel (excluding the first iteration)
 will be used to compute the reported bandwidth.
-------------------------------------------------------------
Number of Threads requested = 16
Number of Threads counted = 16
-------------------------------------------------------------
Your clock granularity/precision appears to be 1 microseconds.
Each test below will take on the order of 1688 microseconds.
   (= 1688 clock ticks)
Increase the size of the arrays if this shows that
you are not getting at least 20 clock ticks per test.
-------------------------------------------------------------
WARNING -- The above is only a rough guideline.
For best results, please be sure you know the
precision of your system timer.
-------------------------------------------------------------
Function    Best Rate MB/s  Avg time     Min time     Max time
Copy:           70389.0     0.002306     0.002273     0.002349
Scale:          67256.8     0.002406     0.002379     0.002446
Add:            74444.1     0.003237     0.003224     0.003256
Triad:          77148.4     0.003144     0.003111     0.003185
-------------------------------------------------------------
Solution Validates: avg error less than 1.000000e-13 on all three arrays
-------------------------------------------------------------

checkpoint Feb 2 2022 at 02:35

А можно еще раз тест TLB на этой (8 по 8ГБ) конфигурации ?

InChaos Jan 28 2022 at 09:34

Кэш память ЦП важный показатель для СУБД? Извините, не мое дело, но не курите это больше.

checkpoint Jan 28 2022 at 11:25

Кэш память ЦП важный показатель для СУБД?

Именно так. В СУБД очень мало вычислений, подавляющее большинство операций - это копирование массивов данных из одной области памяти в другую. Чем больше и оперативней кэш, тем быстрее отработает ваш запрос.

amartology Jan 28 2022 at 12:15

Intel i7-2600
Status: Discontinued
Launch Date: Q1'11
Lithography: 32 nm

Реально? На в два раза меньших проектных нормах получили камень медленнее и жарче, чем уже снятый с производства десятилетний Intel, и после этого кто-то все еще считает, что у Эльбурса как архитектуры есть какие-то перспективы?

+14

Fjfvh Jan 28 2022 at 12:43

Тогда почему этот явно негодный процессор с удовольствием выпускают вполне современные китайские производители? Им на свою репутацию совсем наплевать?

-3

amartology Jan 28 2022 at 13:16

Какие китайские производители что выпускают? Интел? Вряд ли. Эльбрус? Точно нет.

mithdradates Jan 28 2022 at 14:02

Тогда почему этот явно негодный процессор с удовольствием выпускают вполне современные китайские производители? Им на свою репутацию совсем наплевать?

Какие китайские производители выпускают Эльбрус? Вы про TSMC что ли? Это фаб, они "выпекают" что закажет клиент.

forthuser Jan 28 2022 at 12:46

А, почему нет?

У IA-x86 есть «тяжёлое» наследие, которое Intel должна ускорять с помощью аппаратной магии, у Эльбрус магия ускорения кода в возможностях компилятора.
При этом, полагаю, что железное наполнение у Эльбрус более специфично по его управлению, чем в модели IA-x86 в связи со спецификацией программного кода.
Отсюда следует, предположительно, что инженеры Intel вынуждены использовать определённый базис решений к которым они пришли в результате многих десятилетий, а у Эльбрус архитектуры более свободы в выборе пути реализации проекта программно-аппаратно процессора Эльбрус.
Отсюда и такие, вполне достойные результаты на «коротком» старте этого проекта.

P.S. Мне это так видится в общих рассуждениях. 😋

Чем то Эльбрус похож на идеи процессора Transmeta.
Жаль, что они не смогли удержаться на рынке.

amartology Jan 28 2022 at 13:18

Отсюда и такие, вполне достойные результаты на «коротком» старте этого проекта.

Коротком? Архитектура Эльбрус — ровесница ARM.

Чем то Эльбрус похож на идеи процессора Transmeta.
Жаль, что они не смогли удержаться на рынке.

Так раз Трансмета и Итаниум не смогли, может в этом есть какая-то закономерность? Например, то, что VLIW как подход к процессорам общего назначения не работает?

forthuser Jan 28 2022 at 13:44

Так и, к примеру, M68K тоже общего назначения и где то ровесница, и долго была на рынке, но конкурентную борьбу с инженерами Intel не выиграла.
И, вроде, только с Pentium-1 произошёл «отрыв» IA-x86 от конкурентов.

P.S. Даже Apple в своих ПК, 15-ть лет назад перешла на IA-x86 процессоры от Intel закопав свою архитектуру, а сейчас и от Intel процессоров ушла на свои процессоры, но разрабатывала она их в течении где то 10-ти лет.

А, сколько ещё процессоров общего назначения, к примеру, начиная с Z-80 не смогли составить конкуренцию…

JerleShannara Jan 28 2022 at 14:29

Небольшая подсказка: что IBM Power, что M68K, что x86, что ARM вполне себе RISC/CISC/MIPS (х86 только снаружи имеет обёртку CISC, внутри это RISC начиная с Pentium Pro/2). VLIWы это: трансмета (не выстрелила), итаник(почётно утонул), ещё VLIW мелькал в GPU AMD (RDNA 2 уже не VLIW ЕМНИП) и куче сигнальных процессоров(а вот тут он выстрелил, правда нынче, если надо скорости, вместо DSP ставят FPGA).

forthuser Jan 28 2022 at 14:44

Небольшая подсказка

Имеет смысл, тогда указать, что в Вашем понимании RISC, и что с того, что где то по слухам внутри x86 есть RISC процессор, а вероятно и не один если к ним нет прямого доступа у программ.

P.S. Вы ещё не указали MISC абревиатуру.

JerleShannara Jan 28 2022 at 21:33

Не по слухам, читайте документацию на интеловские процессоры и особенно про то, что такое микрокод. Если бы современные интеля были бы внутри чистым CISCом, то вместе с процессором вам бы в комплекте шёл фреоновый кондиционер-охладитель для процессора. RISC — короткие инструкции, подразумевающие простые действия вида «записать из памяти в регистр», «прибавить к аккумулятору регистр» и так далее, а не «взять из памяти число по смещению из регистра и прибавив к нему второй регистр положить в аккумулятор».

kedoki Jan 28 2022 at 15:54

ещё VLIW мелькал в GPU AMD (RDNA 2 уже не VLIW ЕМНИП)

Ну как мелькал, применялся не одно поколение начиная с HD 2000 и заканчивая HD 6000, плюс ранние APU и некоторые видеокарты формально из более поздних линеек (AMD не раз помещала карты с разными архитектурами в одну линейку). За долгие годы AMD не смогли хорошо загружать VLIW, потоковые процессоры хронически недогружались. В HD 6000 VLIW5 порезали до VLIW4, а в следующем поколении перешли на GCN с RISC. RDNA с самого начала RISC, как и GCN.

Итого: слили область GPGPU Хуангу с его RISC, не смогли обеспечить хорошую загрузку VLIW и сменили архитектуру более десяти лет назад. Не сказать, что Itanic в мире видеокарт, но от полного успеха очень далеко.

0xd34df00d Jan 28 2022 at 21:06

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

northzen Jan 28 2022 at 13:54

А какие перспективы у неЭльбруса? У его отсутствия?
Радоваться надо, что осиляют технологии хотя бы десятилетней давности.

JerleShannara Jan 28 2022 at 14:30

Перспективы посидеть на ARMах, пока не будут готовы RISC-V.

UFO just landed and posted this here

JerleShannara Jan 28 2022 at 15:18

Силовикам на спарках перекантоваться проще, пока риск5 не появится, а вот куда совать e2k я вообще не знаю, ну не пригоден этот процессор на роль GP CPU. В радар его засунуть — может что и выйдет. Не силовкам — на АРМах с перспективой слезть на риск5, если всё станет только хуже.

UFO just landed and posted this here

JerleShannara Jan 28 2022 at 16:31

Госзакупки, на которые прилетает птица, которая может кушать падаль и не дохнуть, вряд ли видят все. Ну а работать в условном офисе старого разлива под линуксом можно и на Rках от МЦСТ ещё какое-то время.

UFO just landed and posted this here

JerleShannara Jan 28 2022 at 21:03

Ну вот опять вы Тшку приплетаете. Запишите себе: Тшка хороший микроконтроллер для управляемого L2 коммутатора, Тшка с приделанной видеокартой — условно частично терпимый тонкий клиент, если разрешение не выше 720p и нет 3D. По мне проще наконец закопать стюардессу, переждать время на спарках и стартовать на risc-v, у которого хотя бы есть более-менее нормальное комьюнити.

UFO just landed and posted this here

JerleShannara Jan 29 2022 at 13:34

С таволгой была поличитески-маскишоу ситуация, которую ниже уже описали.
Из имеющегося на рынке с флагом «РФ» — Baikal-M1000, всё прочее либо не GPСPU, либо устаревшее порядком. Для Siloviks я предлагаю переждать на MCST R-Series (гугл кстати про это таки что-то знает). e2k — это не GPCPU как бы его не пытались за него выдать, все попытки вытащить на рынок VLIW процессоры в роли GPCPU завершились гранд-обломами, а уж ресурсов там было потрачено гораздо больше. Если уж тащить эту архитектуру — то делать из неё ускорители (матрицы 10000х10000 там перемножить, всякие фильтры наложить и т.д.) которые будут разгружать GPCPU на рабочих задачах.

yalex1442 Jan 29 2022 at 13:51

>e2k — это не GPCPU
Какой-нибуль другой из отечественных GPCPU способен на такое?

Причем это крутится на предыдущем камне в эмуляции с сопутствующими потерями.

JerleShannara Jan 29 2022 at 13:56

На 1 FPM? Думаю что вполне, если под QEMU на aarch64 запустить через wine и в PCIe вставить хорошую видеокарту.

UFO just landed and posted this here

JerleShannara Jan 29 2022 at 14:15

Дам ещё одну подсказку — поищите древность по имени «Эльбрус 90 микро», чтобы понять для кого МЦСТ клепает SPARC. Вот они совершенно спокойно на них и пересидят, пока не появится что-то более вкусное на безпроблеммной с точки зрения лицензирования корке. Итаник завершился обломом потому, что там была та же самая канитель «будет совместимо, компилятор разрулит» и интел держал их сугубо для тех, кто поверил в то, что VLIW это круто(ибо контракты и прочее). Трансмета тоже удачно утонула со своим робинзоном на VLIW. И только МЦСТ продолжает тянуть лямку, что VLIW это GPCPU. А так — назовите на момент отказа фирмой Intel от ARM тех, кто ещё делал тогда процессоры на ARM ядрах. И назовите тех, кто на момент отказа фирмы Intel от Итаника делал тогда процессоры на VLIW.

UFO just landed and posted this here

JerleShannara Jan 29 2022 at 14:57

То есть госзакупки всегда будем делать по принципу «я дебил», хорошо, записал.
Я ругаюсь с того, что стоящий у меня камень, которому уже 11 лет, по прежнему рвёт все эти эльбрусы, при учёте того, что в момент выхода он стоил менее 500уе., а бюджетные деньги тратятся на то, что ему сливает, стоит гораздо дороже и не имеет перспектив на рынке GPCPU. Вам кстати самому не смешно, что «GPCPU», представляемый как серверный, мягко говоря пригоден в основном только как десктопный? Плюс ещё один толстый и большой гвоздь в крышку VLIWа: у нас сейчас основная масса кода — это говнокод. Фреймворки на фреймворках поверх либы абстракции. При этом каждую тему с e2k преследует «ну вот компилятор допилим и всё будет телемаркет» и «ну код надо оптимизировать». Вы себе как представляете тонну говнокодеров, которые будут под e2k оптимизацию делать?
П.С. Серьёзные задачи я на домашней машине не кручу, для этого есть такие удобные штуки как мощные сервера, которые увы на e2k не удастся построить.
П.П.С. Винда у меня уже давно скончалась, живу как-то под линуксом спокойно.

UFO just landed and posted this here

JerleShannara Jan 29 2022 at 15:18

Я предлагаю говнософт пока переписать под ARM/SPARC, параллельно смотря, как это будет теоретически выглядеть на RISC-V, благо его сейчас на «посмотреть» можно даже на cyclone iv собрать. В сервер, где стоит сельдерон можно спокойно запихнуть ARM, или заменить его на несколько серверов на SPARC. В сервер, где стоит парочка Xeon, ну да, ну да, пошёл я на ближайшие пару-тройку лет.

UFO just landed and posted this here

JerleShannara Jan 29 2022 at 17:02

Эмм, если вы в сервера с сельдеронами пихаете 4Тб оперативки, то надо проверить психическое здоровье.

amartology Jan 29 2022 at 12:05

А от старых байкалов даже полиция отбрыкивалась

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

UFO just landed and posted this here

northzen Jan 28 2022 at 18:43

Это вариант "еще немножко потерпеть". Но когда терпится, опыт разработки не накапливается, а лишь теряется.

JerleShannara Jan 28 2022 at 21:04

Ну так никто не говорит, что надо оставаться на АРМах, можно уже начинать пилить софт по risc.

Mox Jan 28 2022 at 16:17

16 нанометровый процессор с 16 ядрами тягается, и временами проигрывает, 4-х ядерному, 8 поточному 32 нанометровому, да еще и на более медленной памяти.

Что-то печально это все (((

Надежда на то что компилятор все таки может раскрыть потенциал, но без серьезных вливаний надежды особо нет, да и политика закрытости тоже не позволяет надеяться что сообщество что-то там подпатчит.

JerleShannara Jan 28 2022 at 16:31

Песня про раскрытие компилятора исполняется ещё со времён монокуба.

Armmaster Jan 28 2022 at 16:37

Надежда на то что компилятор все таки может раскрыть потенциал

не сможет

amartology Jan 28 2022 at 17:02

Надежда на то что компилятор все таки может

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

Mox Jan 28 2022 at 17:44

Я так понимаю что lcc еще толком не умеет profile-guided optimization, а без этого для vliw компилятора слишком мало данных. На это надежда )

amartology Jan 28 2022 at 20:59

Видите ли, идея VLIW была в том, чтобы можно было сделать более простое железо и дальше разогнать машину за счет компилятора. Прямо сейчас мы уже видим, что железо намного более сложное и дорогое (не конкретно сейчас более дорогое, а в большой серии 16 нм сильно дороже, чем 32 нм), чем сильно превосходящие его х86. Так зачем оно тогда?

Mox Jan 28 2022 at 23:12

Я кстати не знаю насколько оно сложное, думаю что все таки попроще чем конкуренты.

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

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

amartology Jan 29 2022 at 12:08

кстати не знаю насколько оно сложное, думаю что все таки попроще чем конкуренты.

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

вещи типа Tensorflow, где процессор бы раскрылся

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

Mox Jan 30 2022 at 20:02

По поводу простоты:

Она скорее определяется транзисторным бюджетом, скорость/тормоза тут не при чем. Я предполагаю что большая чем у аналогов простота достигается отсутствием блока анализа и переупорядочивания команд, то есть это процессор без фронтенда. В эльбрусе это отведено компилятору, а команда явно указывает конкретные блоки процессора для своего выполнения.

По поводу Tensorflow:

Насколько я знаю - проблема Эльбруса в том что он на уровне архитектуры допускает гораздо большую параллелизацию операций, чем это возможно определить при анализе кода на нынешнем уровне развивтия компилятора. То есть VLIW команды идут "полупустыми" - исполняющими меньше операций за команду чем позволяет аппаратура процессора.

Тем не менее, при cпецифических задачах типа "перемножение матриц" можно все отлично распараллелить и загрузить VLIW команды по полной. То есть все что выводят сейчас на OpenCL/CUDA на Эльбрусе будет очень неплохо.

Косвенно подтверждает это результат теста minerd, где нужно считать параллелящиеся вещи - почти 7 кратное превосходство Эльбрус над Intel.

JerleShannara Jan 29 2022 at 04:35

Выкидываем из e2k всю ненужную периферию. Оставляем в нём только PCIe Device и кучу каналов памяти, сажаем всё это дело на full sized PCIe карту. Получаем ускоритель, который поможет разгрузить CPU на всяких хитрых задачах.

ncwca Feb 12 2022 at 10:36

Ну судя по задержкам кэша/операция - эльбрус это просто какие-то второсорные ип-блоки с той же арифметикой. Потому как почему у неё такие дерьмовы задержки неведомо. влив никак не влияет на кэши, операции и прочее.

А по поводу самого влив. Влив - это будущие. Миф о том, что х86 и суперскаляр может что-то там без компилятора - это полнейшая чушь. Ничего он не может.

Ситуация +/- такая же как и ситуация с многопоточностью. Ничего с этим не сделаешь. И проблема влива и "преимущества" суперскаляра в основном обусловлены именно школой и теми подходами, которые используются сейчас.

Тот же итаник никаким вливом не являлся. Это был огрызок. Это такой микс. Сдох он не потому, что влив, а потому что а) интелу ненужна конкуренция с самим собою, б) развитие той школы, которая нужна вливу - ненужна интелу.

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

Допустим, хороший пример это нвидия. Вот выгодно ли нвидии заниматься пониманием темы тех, кто пишет на той же куде? Нет. Зачем. Бизнес-модель нвидии - это продажа блобов/поддержки. Там до сих пор каждый первый уверен, что есть какие-то куда-ядра. Хотя эту херню нвидия просто придумала, чтобы вчерашние скалярные говноделы смогли хоть как-то понять разницу между х86 и видяхой.

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

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

Со всеми этими ветками и прочими куллстори про "рантайм" - практически всегда это чушь. Там есть и то обстоятельство, что никто не понимает что вообще такое "предсказатель переходов" и суперскалярность вообще. В связи с этим всё это наделяется какими-то чуда-свойствами. Так же люди не понимают, что 90% того, что есть в их коде - это обусловлено их плохим пониманием и таким же уровнем качества кода. Просто людей учиили так писатаь.

Поэтому те, кто действительно что-то понимают - пытаются всю эту динамическую херню выпилить нахрен. Будь то компиляторы под тот же интел, либо сам интел. Да и сама эта динамическая херня не является проблемой для влива.

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

amartology Feb 12 2022 at 10:54

VLIW для задач общего назначения — это, к сожалению, ретрофутуризм, а не будущее. Кроме Intel, им занималось ещё некоторое количество компаний, у которых не было за душой x86, и все эти компании не стали успешными. Зато развивавшийся тогда же ARM имеет огромные тиражи и полностью захватил рынок всего, кроме ПК. И сейчас для амбициозного проекта RISC-V можно было сделать вообще любую архитектуру, можно было выбрать все самое лучшее, но выбран был вовсе не VLIW.

никто не понимает что вообще такое «предсказатель переходов» и суперскалярность вообще. В связи с этим всё это наделяется какими-то чуда-свойствами

Выгода от предсказателя хорошо измеряется. Именно поэтому они есть в процессорах и активно развиваются.

ncwca Feb 12 2022 at 12:41

VLIW для задач общего назначения — это, к сожалению, ретрофутуризм, а не будущее.

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

Это такая же методичка как 20 лет все кричали "многопоточность не работает - одно ядро наше всё".

Кроме Intel, им занималось ещё некоторое количество компаний, у которых
не было за душой x86, и все эти компании не стали успешными.

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

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

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

Зато развивавшийся тогда же ARM имеет огромные тиражи и полностью
захватил рынок всего, кроме ПК.

Арм ничего никуда не захватил. Просто фортануло. У него не было никаких конкурентов. Это как рассказывать, что что-то захватил интел. Интел всегда был мусором, продвигался дядями из межделмаша. Там каким-то чудом во что-то сформировался в середине нулевых. Из-за бесконечного бабла и отсутствия конкуренции. Ну и х86 во многом проприетарный мусор.

А дяди с теми же нормальными суперскалярами думали, что мейнфремы будут везде вечно. Но не фортануло. Потом вакханалия с эплом, пс3/коробкой.

К тому же, повторяю, суперскаляр - это такое же во много легаси, как и х86. Нужен ли кому-то х86? Нет. Это дерьмо. Он в принципе не имеет смысла. Но чего же он захватил и держит рынок?

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

Поэтому переход с х86 без смены парадигмы невозможен. Тоже самое касается суперскаляра.

И сейчас для амбициозного проекта RISC-V
можно было сделать вообще любую архитектуру, можно было выбрать все
самое лучшее, но выбран был вовсе не VLIW.

Нет, никто никакое лучше не выбирал. Выбиралось привычное и то, что куда проще внедрить. О каком-то "лучшее" там никто не думал.

Выгода от предсказателя хорошо измеряется.

Зачем мне спорить с неимеющими к теме отношения ретрансляторами пропаганды, которые не способны даже читать то, что им пишут? Я понимаю, сложно и проще тулить методичку.

То, что на дерьме что-то там "хорошо" измеряется - это ничего не значит. Проблема в том, что это - дерьмо.

Именно поэтому они есть в процессорах и активно развиваются.

Не поэтому. Я спорю даже с теми, кто даже не знает что такое предсказетль.

Я открою тайну экспертам, но предсказатель вообще никак не завязан на суперскаляр. Вообще процессора без предсказателя существовать не может.

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

Поэтому ядро, которое исполняет код - оно не может выполнять всякие переходы, вызовы и прочую чушь. Оно может выполнять только плоский код. В том числе и влив.

Именно для этого и существует предсказатель. Его задача - сделать из мусора плоский код.

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

Именно потому, что преобразовывает он будущие - он называется предсказателем. И повторяю, никак он не связан суперскаляром. О том, что он есть и был в итанике я уже сказал.

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

Без всех эти оптимизация - никакой суперскаляр не работает. Потому что он дерьмо. Он ничего сам не может.

И единственное его преимущество это то, что у него исполнения выявленных независимым цепочек инструкций шедулится отдельно. Влив, в базовом случае - не может исполнять инструкции частично. {add, read}, {mul, mul} - вот влив не может выполнить add + после этого начать выполнять mul из второй "широкой команды", пока read не выполнился.

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

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

Здесь единственная проблема в том, что у влива частоты меньше, ну в текущих реализациях. Поэтому он будет сливать. Но это не такая большая проблема. Это проблема сейчас, когда много дерьма и оно упирается в частоту одного/нескольких ядер.

При этом высокая частота - это горячо. Её нет ни на мобилках, ни на тех же консолях, если мы говорим про игры. Ни на тех же серверах. У интела на жирных хеонах частота 3ггц и нормально.

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

Почему на эльбрусе при такой частоте такие гигантские задержки я не зняю. Судя по всему второсорные ип-блоки.

Если попроще. Влив не особо хуже суперскаляра даже, если исполняет дерьмо. написанно под суперскаляр теми, кто хлебал это дерьмо 30-40 лет. Но потенциал у него куда выше. Он бесконечен. Там ещё нормальный рисковый суперскаляр с нормальным компилятором может ещё эволюционировать, но не долго.

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

edo1h Feb 12 2022 at 13:07

Для лапши хватит

а где вы другой код возьмёте? даже не другой код, а задачи под него.

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

не мешает. но это, сюрприз, будет уже не vliw, а суперскаляр.
вся идея vliw в том, что параллелизм явно задаётся компилятором, формирующим широкие команды.

ncwca Feb 12 2022 at 14:23

а где вы другой код возьмёте?

Повышается уровень инстрии, старые говноделы возвращаются к мытью полов. Как вдруг появился многопоточный код?

даже не другой код, а задачи под него.

Это оправдание тех самым говноделов и неудачников разных мастей уровня "не мы такие". Ничего общего эта чушь с реальностью не имеет.

не мешает. но это, сюрприз, будет уже не vliw, а суперскаляр.

Нет, не будет.

вся идея vliw в том, что параллелизм явно задаётся компилятором, формирующим широкие команды.

Во-первых нет, широких команд во вливе может даже не быть. Это просто базовая модель.

Во-вторых, это называется явный параллелизм. Через что он задётся - неважно. А сам влив и широкая команда - это имя нарицательное. Здесь главное иметь isa с явным параллелизмом. Т.е. она не занимается поском этой параллельности в скалярной isa, как это происходит в случае с суперскаляром.

И самое важное, никаким образом я нигде не говорил о том, что парллелизм будет невным. Откуда взято это откровение?

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

На самом деле можно взять 10 поток инструкций, писать их параллельно, а делее исполнять. Это так же будет янвым параллелизмом.

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

Отвечу на другие клулстори.

да, именно так и было, конкуренция не нужна, интел планировал поделить
рынок на сегменты, высокопроизводительный отдать itanium'у, а бюджетный
оставить за x86.

Не фортануло. У интело получилось начиная с кор2 сделать не-кукурузу. Итаниум был практически х86 с smt, о чём я выше говорил.

Так же, стоит обновить методичку на тему гпу. А так же того, что я писал на тему вливов. Вливы требуют отдельной школы, как это происходит в тех же гпу. Интел же не хотел этим заниматься и учить кого-то.

Там же на итанике были симды, они хорошо продвинулись. Тоже самое и для х86. Потом интел уже начал делать х86-гпу на новых супер-симдах.

вот только что-то пошло не так, x86 пришлось развивать и на его фоне итаник за много денег оказался никому не нужен.

Уже противоречия в методичке. Итаник за много денег, который ничего не предлагал. Историю я описал выше.

Говноделы, нежелание интела учить адептов + дешевость и успешность новых х86, развитие симдов, которые везде продвигались.

Такая же история с паверами/спарками. х86 на их фоне дерьмо, а был ещё большим дерьмом. Там фанатики орали про "проигрышь риска" и прочей чуши.

Такова реальность. х86-дерьмо породило много адептов с покоробленным мозгом. В 90. Там сдохло всё. Ну и вопрос цены. А цена потому, что х86 штампавался миллионами, потому что маздайка и рабы.

Какая-то культура программирования была в юниксах, где-то там глубого в лабораториях. И только с спо, гпу - культура стала массовой. До этого там были такие овощи.

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

А что-то вообще выпускается? Вот х86 выпускается. А х86 дерьмище отборное. Сливает всему. Но почему же оно выпускается? Ой, наверное потому что какое-то будущие и хки вторичны на рынке рабов?

Удачи там маздайку запустить на вливе. Даже мусорный арм-огрызок нахрен никому не упал, хотя билли хотел хоть какой-то мобильный сегмент занять. Хотя бы среди лёгких ноутбуков/гибридов.

В 90/00 - это слишком рано. Сейчас, да и раньше это никому ненужно. Все рынки поделены. Все бизнес-стратегии основаны на то, что чем более бездарны твои рабы - тем лучше.

Зачем кому-то из вендоров учить адептов? Если вендор хочет продавать и лочить ан блобах? Каким-то чудом х86 как что-то отрытое состоялся. Дай вендору возможность - он тебя обожит блобами и нулём информации.

Как это произошло с гпу, как это происходит в хдл-разработке. Это всё никак не связано с технической стороной вопроса.

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

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

-2

edo1h Feb 12 2022 at 14:44

Во-первых нет, широких команд во вливе может даже не быть

читаем расшифровку vliw: very long instruction word

JerleShannara Feb 12 2022 at 14:51

Что с интерпретируемыми языками программирования делать будем? Нет, я конечно не против, если в счастливом будущем за слово жаваскрипт и похапэ будут вешать на дереве и вклеивать в руки табличку 2 + 2 = 22, а весь мир будет писать на С-подобных языках и устраивать срачи на тему «Rust или C# — все стороны лохи», но что-то это совсем утопично-нереалистрично звучит.

ncwca Feb 12 2022 at 20:01

Сразу отвечу балаболу выше, который решил срывать покровы с

читаем расшифровку vliw: very long instruction word

А ведь выше я писал, что в том же итаники нет very long, а данный балабол называл это вливом. Как же так?

А, я понял - это жертва русскоязычной википедии. Хотя скорее всего просто бот с откроваения уровня "чёрная дыра - не дыра".

Что с интерпретируемыми языками программирования делать будем?

А что с ними делать? Это мосор. Если бы кому-то там нужна была производительность - этих языков не существовало бы. Поэтому слабый заход.

Да и проблема не в языках, а в подходах.

Нет, я конечно не против, если в счастливом будущем за слово жаваскрипт и похапэ будут вешать на дереве и вклеивать в руки табличку 2 + 2 = 22

Жаваскрипт не интерпретируемый, а там где есть интерпретатор - всем насрать на то с какой скоростью он работает. Там котируются минимальные задержки на исполнение. Ну и то как минимальные.

Да и жабаскрипт - это просто скриптуха, т.к. где она есть? В броузере? Там нахрен производительность ненужна.

На каких-то маня-веб-серверах? Там она тоже ненужна. Да и любая подобная лапша имеет ровно ноль смысла, потому как не выполняет полезной работы. Её выполняют всякие демоны, внешние сервисы(типа баз данных), сишный рантайм и сишные же либы.

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

а весь мир будет писать на С-подобных языках

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

и устраивать срачи на тему
«Rust или C# — все стороны лохи», но что-то это совсем
утопично-нереалистрично звучит.

Какое отношение это днище имеет к языкам? Ладно там C# ещё пытается быть похожим на язык для бедных, но раст? Это просто мусор.

В любом случае люди очень странно себе представляют ситуацию. Им кажется, что существует какой-то отдельный жаваскрипт и там всё работает как-то иначе - нет.

Проблема с жаваскриптом и скриптухой не в том, что она скриптуха, а в что jit для этого мусора генерирует многожество ловушек и часто что-то пересобирает. Но люди уже давно поняли, что это так же хреново работает на суперскаляре. Именно поэтому подобная логика просто не доходит до жита.

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

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

-3

JerleShannara Feb 13 2022 at 03:41

Смотрите, я лет десять назад тоже был готов написать на хабр «Эльбрус рулет, пишу с него», правда тогда это было с FF 3.X, который вылетал каждые 5 минут на этом самом эльбрусе. Но вот сейчас мы с вами перекидываемся продуктами пищеварения через те самые пыхпыхи с жабаскриптами, которые очень качественно выполняют роль гвоздя в крышке гроба VLIWа, и хрен кому там оптимизация этого ада упёрлась, даже в рамках x86_64, я уже молчу про менее популярные архитектуры. В итоге я пришёл к прагматичной точке зрения, которая гласит — в ракету хоть el'bruse, в жизнь только принятые миром практики. Увы, VLIW в текущих реализациях под GPCPU полностью непригоден, что показали прошедшие 30+ лет.

edo1h Feb 12 2022 at 11:42

Сдох он не потому, что влив, а потому что а) интелу ненужна конкуренция с самим собою

да, именно так и было, конкуренция не нужна, интел планировал поделить рынок на сегменты, высокопроизводительный отдать itanium'у, а бюджетный оставить за x86.

вот только что-то пошло не так, x86 пришлось развивать и на его фоне итаник за много денег оказался никому не нужен.

Я, возможно, напишу об этом статью когда-нибудь. Но в целом влив — это будущие

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

-1

saboteur_kiev Jan 28 2022 at 20:42

Я вам так скажу, что мы тут в Украине завидуем что у вас есть свои разработки процессоров, которые в принципе можно сравнивать по производительности в десятки раз, а то и в разы (а не в тысячи и десятки тысяч).
Это означает что отрасль в принципе вообще есть. Да маленькая. Да, не конкурент на мировом рынке, но уже существует в виде, когда ее можно использовать даже в продакшене, и на внутреннем рынке у нее уже могут/должны быть заказчики, а это значит продолжение разработки, наработка экспертизы. И кто его знает что будет лет через 10-20.

amartology Jan 28 2022 at 21:00

Я вам так скажу, что мы тут в Украине завидуем

У вас в Украине тоже есть толковые микроэлектронщики. Они только, как и ваши айтишники, работают на мировой рынок, а не на внутренний. И это, кстати, в плане квалификации большой плюс.

saboteur_kiev Jan 28 2022 at 23:05

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

amartology Jan 29 2022 at 12:12

А в разработку основных узлов и не пустят.

Насколько мне известно, пускают ещё как. Патенты себе — это и риски себе, видимо, желающих создавать свои собственные компании особенно нет. Но специалисты есть, и отрасль в каком-то виде есть.
В России все крутится вокруг госзаказа, а у Украины собственных денег на микроэлектронный госзаказ нет. Но у Украины есть, например, перспективы войти в ЕС и устроиться в европейскую систему микроэлектронного госзаказа. — тогда, глядишь, и собственные компании станут выгоднее работы на дядю.

saboteur_kiev Feb 1 2022 at 05:38

Я работал в проекте, где было R&D с техникой. Уверен, что у многих продукция есть в доме.

Как только началась война в 2013, этот проект свернулся и свалил и из Украины и из России. Людей перекидывали потом в другие проекты. И конкуренты тоже.

UFO just landed and posted this here

RiddleRider Jan 28 2022 at 20:36

Благодарю за тестирование!

theoretician Jan 29 2022 at 07:34

По-моему, главная проблема МЦСТ в том, что она не понимает, как правильно презентовать свои процессоры рынку. Почему-то всё время сравнивает с Intel и AMD, говоря при этом, что у монструозных западных компаний намного больше денег на разработку, производство и т.д. В этом главная ошибка, мне кажется, не надо пытаться бросать вызов существующим решениям сразу во всём, особенно в том, в чём они заведомо выиграют - в общих задачах со сложной логикой и тем более в попытках запустить программы с трансляцией в x86, показать выполнение Windows и прочее - не нужно этого делать. Автор данного повествования тоже зря ограничился "для бенчмарков это запрещено делать" - ничего не запрещено, такая честность никого не интересует, и вообще честность - это бред, в рынке надо полностью раскручивать все преимущества, даже полностью спекулятивные и фиктивные. Наоборот, надо брать особенности данной архитектуры и читить так, как недоступно для других архитектур, перекомпилировать с флагами и оптимизировать, по ситуации представляя данные процессоры не как общего серверного назначения, а специалированного. Даже статья получилась бы намного интереснее, если бы удалось полностью раскрыть именно особенности этой архитектуры, и если бы при этом эльбрусы ушли в отрыв.

Сейчас МЦСТ ещё не вклинилась в рынок, живёт за счёт господдержки, но, лично я бы не стал рассчитывать в российских реалиях на это в долгосрочной перспективе. Пусть сейчас есть господдержка, но её надо использовать, чтобы постепенно найти себя в рынке.

edo1h Jan 30 2022 at 22:54

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

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

edo1h Jan 29 2022 at 23:59

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

EntityFX Feb 4 2022 at 11:32

Перетестил с 8ми, столько поставили сперва. Каналов 8, в теории 16 планок можно.

edo1h Feb 4 2022 at 12:02

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

EntityFX Feb 4 2022 at 12:31

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

HumanJan Feb 4 2022 at 11:31

Автор сравнивет процессор 2022 года с процом 10 летней давности. Вы серьезно. Более того он ему проиграл почти все тесты. Вывод про кал ладу калину напрашивается сам. Я уверен что этот проц будет где то на уровне core2duo. За который мне на радиорынке 100 гривен не дали.

-3

UFO just landed and posted this here

jura12 Feb 4 2022 at 11:38

Жду ваши предложения, какие ещё бенчмарки можно прогнать на этих компьютерах

юзаю phoronix-test-suite в wsl вин 11. мой новый проц i6-12400f быстрее вашего. смотри результаты Benchmarks / Results Uploaded By jura12 - OpenBenchmarking.org

Bwana Jan 31 at 15:45

Жду ваши предложения, какие ещё бенчмарки можно прогнать на этих компьютерах

Все перечисленные тесты, за исключением дристоса, зипа и шамира, -- тесты арифметики с плавающей запятой в стандарте IEEE-754. Фактически, это тестирование, насколько удачно этот стандарт реализован в том или ином кремнии. Ни в коем случае не умаляя важности этой арифметики, хотелось бы больше тестов целочисленной, поскольку в системном софте именно она преобладает, и преобладает существенно. Операционки и прочий системный софт (файлы, коммуникационные дела) под капотом используют именно целочисленную арифметику и побитовую догику. Базы данных тоже. Собственно, данные с плав. запятой в БД в виде типов присутствуют, однако для работы, например, с бабками почти не используются. Да и во многих приложениях, интенсивно использующих плав. арифметику, используется не процессор, а видеокарта. Причем, как раз, для работы с линейной алгеброй (блас и прочий лапак).

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

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

EntityFX Jan 31 at 19:47

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

Желательно на сишке.

Only those users with full accounts are able to leave comments. Log in, please.