Поэтому Neoverse V1 нужно дать частоту в 1.5 раза больше - 3.0 GHz, чтобы сравняться с ядром Эльбруса по флопсам.
И я думаю, что довольно неплохое OoO ядро с умным префетчем, такое как V1, сможет эффективнее использовать ресурсы, чем тупой VLIW со статическим планированием.
Обычно так и будет.
Но если задача допускает полное планирование всего цикла, тогда Эльбрус выдаст полную скорость. Хотя часть ресурсов в слотах FMA уйдет на другие цели. Поэтому что-то потеряют от пиковых значений.
А спланировать префетч данных - это ключевой момент для Эльбруса, которого нет в других процессорах, где все делает аппаратный префетч.
Что? Количество ядер не изменилось.
А могло вырасти, если бы использовали Neoverse N2.
Altra Max - 128 ядер Neoverse N1 на 7 нм
Graviton3 - только 64 ядра Neoverse на 5 нм.
new Graviton3 processors also consumes up to 60% less power than the Graviton2
Это ошибочная трактовка. В оригинале так:
AWS Graviton3 processors are also more energy efficient, using up to 60% less energy for same performance than comparable EC2 instances.
А comparable EC2 instances - это что-типа AMD или Intel.
Тот подход на сайте SPEC принят не всей индустрией, а только некоторыми участниками типа AMD/Intel для серверных процессоров.
А процессоры Apple, Qualcomm, Mediatek и все ноутбучные процессоры x86 вообще не тестируют по полному "подходу" на сайте SPEC.
Поэтому большинство существующих процессоров вообще не попадают на сайт SPEC.
Но сами нагрузки из SPEC 2017 многих устраивают, и каждый может выбрать такие условия запуска этих нагрузок, которые лучше будут соотвествовать целям тестов.
Например, Armmaster размахивал результатом Epyc 72F3, когда надо было унизить Эльбрус.
Сравниваем Epyc 72F3 с Байкалом-S.
8-ядерный 72F3 - 98/125
48-ядерный Байкал-S 71/80
Выходит, что средняя производительность ядра Байкал-S хуже примерно в 9 раз, чем у ядра того Epyc.
Вот, чтобы таких "абсурдных" выводов не было, нужно скептически относиться к результатам на сайте SPEC, и стараться больше использовать другие источники информации насчет производительности ядер разных процессоров.
Вот, например, AWS тестирует нагрузку Spec самостоятельно с простыми ключами:
И им не нужно лезть на сайт SPEC за дутыми результатами Intel/AMD. Они сами протестируют свои серверы Intel/AMD с теми же ключами, что и свои серверы Graviton2 и Graviton3.
Многие делают так, чтобы было удобнее сравнивать разные процессоры. А чем проще будут опции компиляции для разных платформ, тем легче сравнивать разные процессоры. Поэтому подход на anandtech достатчно разумный, когда всех уравнивают по опциям.
Вы постоянно пытаетесь что-то и зачем-то мне доказать, но непонятно что и зачем. Цифры тут настолько красноречивы, что я не знаю, о чём тут можно спорить.
Я уже написал. В качестве доказательства бесперспективности эльбруса вы предложили использовать показатель "Микроархитектурная производительность" именно из результатов Spec 2017.
Но для байкалов вы почему-то отказываетесь рассматривать этот же показатель. Портить позитивное заключение насчет ядер Байкала не хотите низкими цифрами, которые я показал выше:
0.66 / 0.67 Baikal-M
0.75 / 0.84 Baikal-S
0.89 / 1.38 Эльбрус 8СВ
Там же специально указаны цифры для одного потока. 405/(217*1.33)= ~1.4.
Про это уже ответил в другом посте. Большой кэш 2+32 MB помогает в Single-Core. А в Multi-Core большого кэша у каждого ядра уже нет. Поэтому и нет большого прироста у A75.
а на деле они никак не верифицируемы и получены с помощью кучи опций и припрыжек, заточенных под SpecCPU 2017.
А на Байкалах "припрыжки и опции" почему не делают?
Кто им мешает выдать высокий результат?
А реальный перф и микроархитектурная скорость будут существенно ниже, иногда в разы.
А иногда будет в разы выше у Эльбруса на нагрузках типа Linpack.
Строго говоря есть свидетельства что в МЦСТ есть команда людей, которая занимается получением красивых результатов в SPEC
И зачем они это делают годами, если так ни одного оформленного результата Spec эта команда так и не выдала за все эти годы?
Где результаты всех этих "красивых" оптимизаций?
В любом случае это будет очень небольшая команда менее 10 разработчиков, которые плотно занимаются компиляторами С++ / Fortran в МЦСТ, против всего остального мира разработчиков компиляторов, где ARM играет важнейшую роль с учетом миллиардов ядер и процессоров ARM. Так во всем мире разработчики компиляторов проверяют все изменения и патчи компиляторов именно на нагрузках Spec. Так почему же все они не выдали на-гора оптимизации для нагрузок Spec, которые могли бы подтянуть в тесты Байкалы?
Кто кому мешает?
Почему у Байкалов результат на ядро в Spec ниже, чем у Эльбрусов?
Эльбрус находится в проигрышном состоянии, когда мелкая команда соревнуется против всего остального мира. И поэтому некоторая дополнительная оптимизация компиляторов и параметров запуска только частично уравновешивает ту фору, которую априори имеет Байкал за счет мощной экосистемы ARM в компиляторах.
Также игнорируете то что я уже вам несколько раз объяснил, почему нельзя цифры с Anandtech сравнивать с тем что публикует производитель (точнее можно, при условии что производитель не тратил время и силы на оптимизацию параметров запуска теста, но во всех случаях когда это не публикуется - сравнение некорректно).
Я так и не понял.
Вот есть тесты i9-12900K и M1 Maх в нагрузках Spec 2017 на сайте anandtech.
Других "авторитетных" тестов Spec 2017 для этих процессоров больше никто не делал. Производители процессоров тоже не публиковали свои результаты.
Так можно ли сравнивать те результаты Spec 2017 на сайте Anandtech?
Я считаю, что можно сравнивать те тесты между собой, и можно сравнивать их с байкалами. Все без проблем согласуется по условиям запуска тестов.
В ситуации когда хотя бы один из источников не публикует детали
Байкалу доступна сила всей экосистемы ARM. Существуют серверные процессоры на ARM: Graviton2, Kunpeng, Altra, а также смартфоны на арм. Эти крупные производители и сама компания ARM сильно заинтересованы занести в компиляторы оптимизации, которые выдадут высокую производительность на разных нагрузках, включая Spec 2017.
А байкалу остается только подтянуть все эти существующие оптимизации и компиляторы ARM, чтобы выдать максимальный результат для своих процессоров. И ничего самим придумывать не надо. Но они в итоге выдали только 7.9 / 8.0 в Spec2017 в Байкал-М.
У Эльбрусов людских ресурсов значительно меньше. Там для Эльбрусов только несколько человек занимаются компиляторами C++ / Fortran. Так неужели эти единичные разработчики под Эльбрус сейчас круче всего мирового сообщества разработчиков компиляторов под ARM?
Поэтому и сравниваю лучшие результаты в такой схеме:
пара оптимизаторов на Эльбрусах против всего остального мира оптимизаторов под ARM на массовых ядрах A57/A75.
По-моему это вполне честное сравнение.
Пусть все показывают свои лучшие результаты на нагрузках Spec 2017. И в пересчете на ядро у Эльбруса там результат пока выше, чем у A57/A75.
Поэтому сравнивать нормируя по частоте - некорректно.
Корректно. Это показывает производительность на такт. Именно за этот показатель борются в последнее время все. Если посмотреть презентации новых ядер или процессоров у AMD и Intel, то они там сами выставляют новым процессорам одинаковую низкую частоту наравне со старым процессором (ядром), и сравнивают именно производлительность на такт у старого и нового процессора.
Так они показывают именно микроархитектурные изменения и приросты. А обывателю оставляют право самостятльно сделать простую операцию умножения той удельной производительности на частоту.
Но микроархитектрную скорость можно сообщить заранее для всех продуктов сразу, а конкретную частоту выдать в последний момент. И частоты будут разные. В ноутбуке и сервере частота будет ниже, а в десктопе - выше.
Так и в случае Байкала мы уже знаем достаточно хорошо производительность на такт этого ядра A75, но не знаем финальных частот конечного продукта. Но когда те частоты сообщат, останется только подставить частоту в формулы.
Также не забывайте, что обычно у производителя есть возможность подбирать параметры сборки и играться с компилятором
Вот пусть тогда байкал "играется" с компилятором, и выдаст более высокий результат Spec 2017 у Байкал-М. Но они не выдали. У Эльбруса Spec 2017 FP в два раза больше. Кто мешает байкалу поднять свой результат Spec 2017 FP?
А в Geekbench им не дают играться, и исполняют то, что дают всем.
Излишне. Средний результат по всему набору нагрузок хорошо отражает изменения.
Повторюсь еще раз - вы взяли Spec Rate или Spec Base? Если не в курсе, то почему вы думаете что сравниваете одну и ту же величину?
Очевидно, что rate.
В этой статье у Armmaster есть только результаты rate Spec2017.
Для Элбрус 8СВ и Байкал-S публиковали только rate.
Бывает еще разбивка Peak / Base, но для обсуждаемых процессоров (Байкал, Эльбрусы и M1) публиковали только одну цифру из двух возможных: Base или Peak. Поэтому эти единственные доступные цифры и рассматриваем. Свободы выбора из двух вариантов по цифрам никто пока не давал. Поэтому и ошибиться нельзя.
К сожалению geekbench такие мелочи как частоты ядер не показывает.
Да, там есть результат байкала на частоте 2.5 GHz, где только 24 ядра. Но это баловство "на попробовать".
Как я уже сказал, так как частота определяется в том числе микроархитектруными особенностями, то не надо на нее нормировать, вы получаете величину которая в каких-то сравнениях может сказать что-нибудь, но в целом бесполезна.
Частота зависит от техпроцесса. А нормированная по частоте производительность зависит от микроархитектуры. И такую производительность можно замерить даже на эмуляторе до появления реального продукта. А потом просто подставить частоту в формулу, и получить итоговую производительность.
Для примера: SiFive объявила свое новое ядро Performance P650, которое дает >11 SpecINT2k6 / GHz.
1.79 / 2.0 GHz * 1.5 GHz = 1.344 - это прирост микроархитектурной скорости ядра всего процессора Байкал-S относительно Байкал-M для нагрузки single core. Но эта цифра не совсем надежная из-за того, что одно ядро байкал-S получило 512 KB кэша L2, 2 MB кэша L3 и 32 MB кэша L4, а одно ядро Байкал-M - только 1 MB и 8 MB. Поэтому часть большого прироста single core получается из-за большого кэша. А вот в Multi-Core на каждое ядро будет равенство кэша:
Байкал-M: 12 MB / 8 = 1.5 MB кэша на ядро.
Байкал-S: 80 MB / 48 = 1.67 MB кэша на ядро.
Поэтому нагрузки Multi-Core хорошо отражают среднию производительность ядра с учетом разного размера кэша и разного числа ядер.
Лучше брать результаты Spec 2017 rate, но Armmaster их "забраковал" для Байкал-S. Поэтому скатываемся до Geekbench. Но и в Spec 2017 rate, и в Geekbench разница примерно в 9-10 раз относительно Байкал-М.
Говоря о Spec2017 говорите пожалуйста что конкретно вы опубликовали
Для эльбрусов и байкалов взял цифры из этой статьи. Для M1 Max - из тестирования на сайте anandtech.com:
int = 48.57 / float = 75.67 для 8 ядер M1 Max на частоте 3 GHz.
48.57 / 24 = 2.02 - int
75.67 / 24 = 3.15 - float
Я вполне возьмусь утверждать что нормирование по частоте тут недопустимо в принципе, когда речь идет о микроархитектурной скорости (либо прошу ссылку на сайт spec'а с определением, где дается точная методика).
Так предложил считать "микроархитектурную скорость" Armmaster в предыдущей статье про Эльбрус, чтобы принизить Эльбрус относительно высокого показателя у Epyc.
Если Байкал и Эльбрус имели одинаковую частоту 1.5 GHz на 28 нм, то никакую поправку вносить не надо.
Если на 16 нм будет разная частота в финальном продукте, можно учесть поправку. Пока же исходим из того, что официально будет по 2.0 GHz у них.
Я же написал, что сейчас вы сравниваете быстрые замеры на gcc на Baikal-S с оптимизированными результатами на Baikal-M
Там уже запускали одинаковый исполняемый файл Geekbench, который содержит оптимизации одинакового уровня для любых процессоров ARM. И все микроархитектурные приросты туда попадают.
И в этом Geekbench прирост получился в 9 раз у Байкал-S относительно Байкал-М. А число ядер увеличилось в 6 раз. Значит ядро в среднем дает больше в 1.5 раза по производительности. Но в эти 1.5 раза уже входит увеличение частоты в 1.33 раза c 1.5 GHz до 2 GHz. Поэтому "микроархитектурная скорость" в A75 выросла не так сильно, как вы намекаете.
Когда вы топили Эльбрус в предудущих статьях, вы использовали показатель "микроархитектурная скорость":
По итогу мы видим, что микроархитектурная скорость процессоров Эльбрус в 3-4 раза уступает современным серверным CISC-процессорам топового класса.
Но когда та же "микроархитектурная скорость" у перспективного Байкала оказывается еще ниже уровня Эльбруса, вы почему-то сразу забыли про этот показатель. Напишите, например, во сколько раз "микроархитектурная скорость" Байкала слабее "микроархитектурной скорости" современных процессоров x86. И почему нужно игнорировать эту разницу в случае Байкала, но нельзя в случае Эльбруса.
Добавлю еще Apple M1 Max в табличку микроархитектурной скорости Spec2017:
0.66 / 0.67 Baikal-M
0.75 / 0.84 Baikal-S
0.89 / 1.38 Эльбрус 8СВ
2.02 / 3.15 Apple M1 Max
При этом микроархитектуру M1 Max считают лучшей в мире. Но M1 Max выигрывает только в 2.3 раза у Эльбруса по микроархитектурной скорости Spec2017.
А могут ещё и выше поднять, о чём тех. дир. Байкала непрозрачно намекнул на конференции
А еще он сказал, что на пиковой нагрузке даже на 2.0 GHz они уже могут потреблять на уровне TDP. А значит без уменьшения числа ядер нельзя будет поднять частоту. Высокую частоту на легкой нагрузке можно сделать для баловства. Но в реальных серверах, где нужно будет всегда гарантировать предельные токи и потребление TDP для любой нагрузки, такие эксперименты ставить слишком рискованно. Проще выдать всем стабильные 2.0 GHz или 2.2 GHz.
Новейший Graviton3 использует ядро Neoverse V1, которое отличается от Neoverse N2 этими самыми гигафлопсами, которых там в 2 раза больше. Так они пожертвовали низким потреблением и числом ядер ради гигафлопсов. При этом у них гигафлопсов в ядре Graviton3 все равно меньше, чем в ядре Эльбрус-16С.
"Архитектурная скорость" на 1 GHz одного ядра для Int/Float Spec2017 RATE по "вашей" методике: 0.66 / 0.67 Baikal-M 0.75 / 0.84 Baikal-S 0.89 / 1.38 Эльбрус 8СВ
Тут нет никаких 1.5 раза прироста у A75 относительно A57. Пока получили только 13% и 26% прироста для int/float.
А рост частоты Байкала до 2.5 ГГц не является официальным. И они не сообщили какое напряжение нужно будет выставить для той частоты. Поэтому этот рост частоты до 2.5 ГГц могут еще и отменить.
А что насчет "архитектурной скорости" у ядер A75 в Байкал-S в сравнении с Эльбрусами на тестах SpecCPU 2017?
Как сильно увеличили ту "архитектурную скорость" в A75 относительно A57?
Вот тут ваш предыдущие комментарии по "архитектурной скорости":
Arm утверждает, что только переход с A57 на A72 даёт +26% на fp, правда не конкретизируя, это SpecFP CPU2017 или что-то другое. Если переход на A73 и A75 даёт по 20% каждый, например, то это уже 2.2 раза только по архитектурной скорости.
Ну здрасте. A73 это +2 поколения от A57. Арм заявляет там +90% перформанса при переходе на A72 и ещё +30% при переходе на A73. Пусть эти цифры явно маркетинговые, но то, что там будет приличный привар на десятки процентов на спеках это очевидно.
Но получается, что архитектурная скорость ядра A75 все еще значительно ниже архитектурной скорости ядра Эльбруса для FP. И весь Эльбрус слабее только из-за низкого числа ядер.
А по частотам пока нет окончательной ясности для новых Эльбрусов и Байкалов. Например, даже новейший Graviton3 имеет частоту только 2.6 GHz, что не сильно отличается от новых Байкалов и Эльбрусов.
Вышеприведённые оценки было бы интересно сравнить с мировым опытом. К сожалению, получить точную информацию от компаний уровня Intel или AMD крайне сложно.
Вот компания Nvidia, которая на уровне Intel или AMD, прямо заявила, что ее процессор Xavier делали 2 тысячи человек 4 года, и все это стоило 2 миллиарда долларов, что очень сильно противоречит всем вашим цифрам по стоимости разработки и числу разработчиков.
Поэтому такой важный факт по заданной теме тоже стоило упомянуть в статье. Можно, конечно, написать еще и предположение, что Nvidia соврала в этой оценке, а разработка Xavier стоила значительно дешевле, если вы так считаете. Но только Nvidia публично сообщила хоть какие-то цифры по стоимости разработки процессоров из всех мировых процессорных компаний.
Поэтому суммарная стоимость разработки чипа уровня Intel Core i9-9900K на самом передовом техпроцессе в момент выхода чипа будет составлять порядка $100 млн.
Nvidia рассказывала про затраты на разработку своего последнего процессора Xavier:
With more than 9 billion transistors, Xavier is the most complex system on a chip ever created, representing the work of more than 2,000 NVIDIA engineers over a four-year period, and an investment of $2 billion in research and development.
При этом Xavier по CPU части в 2-3 раза слабее, чем 9900K, хотя там тоже 8 ядер.
А казалоcь бы, что такая крутая компания как Nvidia могла легко вместо 2 миллиардов потратить ваши "$100 млн", и сделать процессор уровня 9900K. Но они потратили в 20 раз больше, и сделали процессор слабее по производительности CPU ядер.
Поэтому в реальности все может отличаться и на порядок от приведенных циферок.
С другими примерами тоже не все так очевидно.
Nuvia не закончила разработку.
От SiFive физически доступна только дорогая плата unmatched, где процессор SiFive в разы слабее любых эльбрусов.
Esperanto ничего пока не довела до массового производства.
А по срокам разработки нужно учитывать дату tapeout и дату получения первого рабочего инженерного образца. Так tapeout для Элбрус-16С был где-то весной 2020. Тогда вероятно и закончилась основная часть разработки этого процессора. А после этого идет тестирование, устранение проблем, второй tapeout с исправлениями, и подготовка к серийному производству.
Я вам показал уже слайды ARM, где утверждается что быстрее в int и memory workloads. Поэтому обращайтесь к ним за разъяснениями что они имели в виду. В анонсах компании обычно не врут (им это черевато исками).
Нам вообще не нужен промежуточный A73, чтобы сравнивать XT-910 c российскими процессорами.
Есть известные данные
6.11 SPECInt/GHz - XT-910 - в статье
6.13 SPECInt/GHz - Cortex-A57 - это реальные тесты Байкала.
7.8-8.0 SPECInt/GHz - Cortex-A75 - это наиболее вероятная оценка, и которая есть на некоторых слайдах.
Этих соотношений достаточно, чтобы утверждать, что XT-910 проигрывает ядру A75. Поэтому они и выбрали A73 для сравнения, а не A75.
Аналогично для SCR7 выбрали совсем слабое ядро A53 на своих слайдах, чтобы не позориться на фоне высокой производительности ядер A57 и A72.
Я предполагаю что вы забыли включить ссылку на анализ всех когда либо выпущенных 2-issue (если я правильно понимаю что вы подразумеваете под двумя декодерами) процессорами.
Посмотрите слайды XT-910.
Там перечисляют его характеристики:
• 3-decode，8-issue
Вот и подумайте для начала, чем issue отличается от decode. И не путайтесь в этих терминах.
В данном месте я предлагаю вам доказать это на практике и привести какой-нибудь бенчмарк, где A75 показал бы результат выше чем 600 GFLOPS (напомню, столько заявлена производительность 4-х кластерного XT-910 в плавучке).
У Эльбрус-16С есть 1500 GFLOPS на FP32. Это в 2.5 раза больше, чем у XT-910. А число ядер одинаковое - 16 штук.
Я уже написал свою основную позицию.
Ядро Эльбруса примерно на уровне A75 для INT, и сильнее ядра A75 на FLOAT.
Никаких RISC-V уровня A75 не существует физически. Только есть SiFive P550 в проекте. Но российским разработчикам до уровня ядра P550 очень далеко.
Если кто-то и придумает свои расширения RISC-V для FLOAT, то у Эльбруса тоже уже есть много этих GFLOPS.
Так фактически российские разработчики своих ядер выйдут на уровень производительности ядра Эльбруса только через несколько итераций и через несколько лет.
Cortex A73 тоже dual-issue, но при этом быстрее чем A72.
Не быстрее.
6.75 SPECInt/GHz - Cortex-A73 - в статье
6.13 SPECInt/GHz - Cortex-A57 - это реальные тесты
Попробуйте вписать A72 между ними.
A72 использовали в серверных Graviton и Kunpeng. А ядро A73 сделали специально для смартфонов. A73 не быстрее, но оно потребляет меньше.
Микроархитектуру нельзя упрощать до количества декодируемых команд за такт
Этим и отличается хорошая разработка от слабой.
A73 - это лучшее ядро, которое имеет только два декодера. Но никто больше не смог повторить на 2 декодерах такую высокую производительность.
SCR7 - тоже не смогли.
Так A75 - это очень хорошее ядро на 3 декодерах.
XT-910 - тоже 3 декодера. Но производительность ниже, чем у A75.
Так даже крупные разработчики на RISC-V проигрывают ядрам Cortex по производительности. А российские RISC-V проиграют еще больше. До уровня Cortex там очень далеко. А ядра Эльбрус уже на том уровне для INT, и даже выше для FP нагрузок.
Поэтому корректное сравнение производительности железа - это крайне сложный процесс и там недостаточно взять один какой-то бенчмарк и в нем все смотреть
Один бенчмарк - плохо.
Средний результат из 10 нагрузок - уже хорошо. Этого достаточно для точных оценок.
Coremark я не доверяю. Известно, что там даже простейшие мипсы без OoO накручивали до высокого уровня. Это слишком специфичный и мелкий бенчмарк, где научились хорошо прокачивать слабые ядра.
Там на слайде NBench A73 выиграл в среднем. Например, там есть нагрузка, где A73 выиграл у xt-910 в 1.6 раза.
EEMBC и Coremark - это мелкие нагрузки.
Нагрузки Spec 2006 показательнее, а там xt-910 проиграл. И так мы знаем, что xt-910 получился на уровне A57 в итоге - 6.11 SPECInt/GHz.
Выводы.
Крупная компания Alibaba спроектировала RISC-V ядро класса A57. Российские разработчики тоже смогут сделать такое ядро когда-нибудь в будущем. Но ядро Эльбруса уже производительнее этого уровня.
Перенос результатов другого бенчмарка в принципе недопустим. Поэтому если приводите geekbench 5 - покажите его результаты для SCR7
Перенос допустим. Найти реальные цифры Spec CPU2017 для A53 трудно. Никто не публиковал их. Но определить выигрыш A57 от A53 легко. Есть миллионы устройств на этих ядрах, и можно использовать то среднее преимущество на 70%, которое показывает geekbench 5.
И единственная надежная оценка производительности для SCR7 - это тот слайд про 20%.
В обоих случаях это не какой-то случайный результат на одной нагрузке, а среднее среди множества нагрузок - 9 штук для SCR7. И так же много нагрузок для geekbench.
Поэтому этим отдельным оценкам про 70% и 20% вполне можно доверять. И можно совмещать эти оценки в итоговый результат про 40% преимущества A57 над SCR7.
Когда не хватает конкретных конечных выводов, надо уметь пользоваться инструментами и данными, которые доступны.
Если сомневаетесь в моих выводах, попробуйте самостоятельно определить или найти информацию про то, как отличаются A57 и A53 по производительности.
A57 - это 3 декодера и OoO.
A53 - это 2 декодера без OoO.
Если бы между ними не было большой разницы по производительности, тогда такой OoO можно было бы признать бесполезным.
Нет.
Эльбрус - 6 команд FMA128 за такт.
Neoverse V1 - 4 команды FMA128 за такт.
Neoverse N2 - 2 команды FMA128 за такт.
Cortex A75 - 1 команда FMA128 за такт.
Поэтому Neoverse V1 нужно дать частоту в 1.5 раза больше - 3.0 GHz, чтобы сравняться с ядром Эльбруса по флопсам.
Обычно так и будет.
Но если задача допускает полное планирование всего цикла, тогда Эльбрус выдаст полную скорость. Хотя часть ресурсов в слотах FMA уйдет на другие цели. Поэтому что-то потеряют от пиковых значений.
А спланировать префетч данных - это ключевой момент для Эльбруса, которого нет в других процессорах, где все делает аппаратный префетч.
А могло вырасти, если бы использовали Neoverse N2.
Altra Max - 128 ядер Neoverse N1 на 7 нм
Graviton3 - только 64 ядра Neoverse на 5 нм.
Это ошибочная трактовка. В оригинале так:
AWS Graviton3 processors are also more energy efficient, using up to 60% less energy for same performance than comparable EC2 instances.
А comparable EC2 instances - это что-типа AMD или Intel.
Тот подход на сайте SPEC принят не всей индустрией, а только некоторыми участниками типа AMD/Intel для серверных процессоров.
А процессоры Apple, Qualcomm, Mediatek и все ноутбучные процессоры x86 вообще не тестируют по полному "подходу" на сайте SPEC.
Поэтому большинство существующих процессоров вообще не попадают на сайт SPEC.
Но сами нагрузки из SPEC 2017 многих устраивают, и каждый может выбрать такие условия запуска этих нагрузок, которые лучше будут соотвествовать целям тестов.
Например, Armmaster размахивал результатом Epyc 72F3, когда надо было унизить Эльбрус.
Сравниваем Epyc 72F3 с Байкалом-S.
8-ядерный 72F3 - 98/125
48-ядерный Байкал-S 71/80
Выходит, что средняя производительность ядра Байкал-S хуже примерно в 9 раз, чем у ядра того Epyc.
Вот, чтобы таких "абсурдных" выводов не было, нужно скептически относиться к результатам на сайте SPEC, и стараться больше использовать другие источники информации насчет производительности ядер разных процессоров.
Вот, например, AWS тестирует нагрузку Spec самостоятельно с простыми ключами:
https://3dnews.ru/assets/external/galleries/2021/12/07/61ae9abeb4182ef0229b11c9/57692e79fea8d0e70b54d1bb9a863c17.png
И им не нужно лезть на сайт SPEC за дутыми результатами Intel/AMD. Они сами протестируют свои серверы Intel/AMD с теми же ключами, что и свои серверы Graviton2 и Graviton3.
Многие делают так, чтобы было удобнее сравнивать разные процессоры. А чем проще будут опции компиляции для разных платформ, тем легче сравнивать разные процессоры. Поэтому подход на anandtech достатчно разумный, когда всех уравнивают по опциям.
Эти мелкие ключи у Байкала для peak на общий результат не должны сильно влиять.
Например, вот у Altra разница между Peak и Base менее 2%:
https://www.spec.org/cpu2017/results/res2021q3/cpu2017-20210811-28660.txt
Там один из способов поднять производительность у ARM - это подменить библиотеки, например, на jemalloc.
Но Байкал и anandtech этого не делали. В этом они схожи.
Я уже написал. В качестве доказательства бесперспективности эльбруса вы предложили использовать показатель "Микроархитектурная производительность" именно из результатов Spec 2017.
Но для байкалов вы почему-то отказываетесь рассматривать этот же показатель. Портить позитивное заключение насчет ядер Байкала не хотите низкими цифрами, которые я показал выше:
0.66 / 0.67 Baikal-M
0.75 / 0.84 Baikal-S
0.89 / 1.38 Эльбрус 8СВ
Про это уже ответил в другом посте. Большой кэш 2+32 MB помогает в Single-Core. А в Multi-Core большого кэша у каждого ядра уже нет. Поэтому и нет большого прироста у A75.
А на Байкалах "припрыжки и опции" почему не делают?
Кто им мешает выдать высокий результат?
А иногда будет в разы выше у Эльбруса на нагрузках типа Linpack.
И зачем они это делают годами, если так ни одного оформленного результата Spec эта команда так и не выдала за все эти годы?
Где результаты всех этих "красивых" оптимизаций?
В любом случае это будет очень небольшая команда менее 10 разработчиков, которые плотно занимаются компиляторами С++ / Fortran в МЦСТ, против всего остального мира разработчиков компиляторов, где ARM играет важнейшую роль с учетом миллиардов ядер и процессоров ARM. Так во всем мире разработчики компиляторов проверяют все изменения и патчи компиляторов именно на нагрузках Spec. Так почему же все они не выдали на-гора оптимизации для нагрузок Spec, которые могли бы подтянуть в тесты Байкалы?
Кто кому мешает?
Почему у Байкалов результат на ядро в Spec ниже, чем у Эльбрусов?
Эльбрус находится в проигрышном состоянии, когда мелкая команда соревнуется против всего остального мира. И поэтому некоторая дополнительная оптимизация компиляторов и параметров запуска только частично уравновешивает ту фору, которую априори имеет Байкал за счет мощной экосистемы ARM в компиляторах.
Я так и не понял.
Вот есть тесты i9-12900K и M1 Maх в нагрузках Spec 2017 на сайте anandtech.
Других "авторитетных" тестов Spec 2017 для этих процессоров больше никто не делал. Производители процессоров тоже не публиковали свои результаты.
Так можно ли сравнивать те результаты Spec 2017 на сайте Anandtech?
Я считаю, что можно сравнивать те тесты между собой, и можно сравнивать их с байкалами. Все без проблем согласуется по условиям запуска тестов.
Байкалу доступна сила всей экосистемы ARM. Существуют серверные процессоры на ARM: Graviton2, Kunpeng, Altra, а также смартфоны на арм. Эти крупные производители и сама компания ARM сильно заинтересованы занести в компиляторы оптимизации, которые выдадут высокую производительность на разных нагрузках, включая Spec 2017.
А байкалу остается только подтянуть все эти существующие оптимизации и компиляторы ARM, чтобы выдать максимальный результат для своих процессоров. И ничего самим придумывать не надо. Но они в итоге выдали только 7.9 / 8.0 в Spec2017 в Байкал-М.
У Эльбрусов людских ресурсов значительно меньше. Там для Эльбрусов только несколько человек занимаются компиляторами C++ / Fortran. Так неужели эти единичные разработчики под Эльбрус сейчас круче всего мирового сообщества разработчиков компиляторов под ARM?
Поэтому и сравниваю лучшие результаты в такой схеме:
пара оптимизаторов на Эльбрусах против всего остального мира оптимизаторов под ARM на массовых ядрах A57/A75.
По-моему это вполне честное сравнение.
Пусть все показывают свои лучшие результаты на нагрузках Spec 2017. И в пересчете на ядро у Эльбруса там результат пока выше, чем у A57/A75.
Корректно. Это показывает производительность на такт. Именно за этот показатель борются в последнее время все. Если посмотреть презентации новых ядер или процессоров у AMD и Intel, то они там сами выставляют новым процессорам одинаковую низкую частоту наравне со старым процессором (ядром), и сравнивают именно производлительность на такт у старого и нового процессора.
Так они показывают именно микроархитектурные изменения и приросты. А обывателю оставляют право самостятльно сделать простую операцию умножения той удельной производительности на частоту.
Но микроархитектрную скорость можно сообщить заранее для всех продуктов сразу, а конкретную частоту выдать в последний момент. И частоты будут разные. В ноутбуке и сервере частота будет ниже, а в десктопе - выше.
Так и в случае Байкала мы уже знаем достаточно хорошо производительность на такт этого ядра A75, но не знаем финальных частот конечного продукта. Но когда те частоты сообщат, останется только подставить частоту в формулы.
Вот пусть тогда байкал "играется" с компилятором, и выдаст более высокий результат Spec 2017 у Байкал-М. Но они не выдали. У Эльбруса Spec 2017 FP в два раза больше. Кто мешает байкалу поднять свой результат Spec 2017 FP?
А в Geekbench им не дают играться, и исполняют то, что дают всем.
Излишне. Средний результат по всему набору нагрузок хорошо отражает изменения.
Очевидно, что rate.
В этой статье у Armmaster есть только результаты rate Spec2017.
Для Элбрус 8СВ и Байкал-S публиковали только rate.
Бывает еще разбивка Peak / Base, но для обсуждаемых процессоров (Байкал, Эльбрусы и M1) публиковали только одну цифру из двух возможных: Base или Peak. Поэтому эти единственные доступные цифры и рассматриваем. Свободы выбора из двух вариантов по цифрам никто пока не давал. Поэтому и ошибиться нельзя.
Да, там есть результат байкала на частоте 2.5 GHz, где только 24 ядра. Но это баловство "на попробовать".
Частота зависит от техпроцесса. А нормированная по частоте производительность зависит от микроархитектуры. И такую производительность можно замерить даже на эмуляторе до появления реального продукта. А потом просто подставить частоту в формулу, и получить итоговую производительность.
Для примера: SiFive объявила свое новое ядро Performance P650, которое дает >11 SpecINT2k6 / GHz.
https://www.sifive.com/cores/performance-p650
Вот так они не сообщили про частоту. Но сообщили про микроархитектурную производительность.
Байкал-S в такой же нагрузке - 9.5 SpecINT2k6 / GHz.
Лучший результат Байкал-М - это 226:
https://browser.geekbench.com/v5/cpu/search?utf8=✓&q=astra+aarch64
405 / 226 = 1.79
1.79 / 2.0 GHz * 1.5 GHz = 1.344 - это прирост микроархитектурной скорости ядра всего процессора Байкал-S относительно Байкал-M для нагрузки single core. Но эта цифра не совсем надежная из-за того, что одно ядро байкал-S получило 512 KB кэша L2, 2 MB кэша L3 и 32 MB кэша L4, а одно ядро Байкал-M - только 1 MB и 8 MB. Поэтому часть большого прироста single core получается из-за большого кэша. А вот в Multi-Core на каждое ядро будет равенство кэша:
Байкал-M: 12 MB / 8 = 1.5 MB кэша на ядро.
Байкал-S: 80 MB / 48 = 1.67 MB кэша на ядро.
Поэтому нагрузки Multi-Core хорошо отражают среднию производительность ядра с учетом разного размера кэша и разного числа ядер.
Лучше брать результаты Spec 2017 rate, но Armmaster их "забраковал" для Байкал-S. Поэтому скатываемся до Geekbench. Но и в Spec 2017 rate, и в Geekbench разница примерно в 9-10 раз относительно Байкал-М.
Для эльбрусов и байкалов взял цифры из этой статьи. Для M1 Max - из тестирования на сайте anandtech.com:
https://www.anandtech.com/show/17024/apple-m1-max-performance-review/5
int = 48.57 / float = 75.67 для 8 ядер M1 Max на частоте 3 GHz.
48.57 / 24 = 2.02 - int
75.67 / 24 = 3.15 - float
Так предложил считать "микроархитектурную скорость" Armmaster в предыдущей статье про Эльбрус, чтобы принизить Эльбрус относительно высокого показателя у Epyc.
Если Байкал и Эльбрус имели одинаковую частоту 1.5 GHz на 28 нм, то никакую поправку вносить не надо.
Если на 16 нм будет разная частота в финальном продукте, можно учесть поправку. Пока же исходим из того, что официально будет по 2.0 GHz у них.
Там уже запускали одинаковый исполняемый файл Geekbench, который содержит оптимизации одинакового уровня для любых процессоров ARM. И все микроархитектурные приросты туда попадают.
И в этом Geekbench прирост получился в 9 раз у Байкал-S относительно Байкал-М. А число ядер увеличилось в 6 раз. Значит ядро в среднем дает больше в 1.5 раза по производительности. Но в эти 1.5 раза уже входит увеличение частоты в 1.33 раза c 1.5 GHz до 2 GHz. Поэтому "микроархитектурная скорость" в A75 выросла не так сильно, как вы намекаете.
Когда вы топили Эльбрус в предудущих статьях, вы использовали показатель "микроархитектурная скорость":
Но когда та же "микроархитектурная скорость" у перспективного Байкала оказывается еще ниже уровня Эльбруса, вы почему-то сразу забыли про этот показатель. Напишите, например, во сколько раз "микроархитектурная скорость" Байкала слабее "микроархитектурной скорости" современных процессоров x86. И почему нужно игнорировать эту разницу в случае Байкала, но нельзя в случае Эльбруса.
Добавлю еще Apple M1 Max в табличку микроархитектурной скорости Spec2017:
0.66 / 0.67 Baikal-M
0.75 / 0.84 Baikal-S
0.89 / 1.38 Эльбрус 8СВ
2.02 / 3.15 Apple M1 Max
При этом микроархитектуру M1 Max считают лучшей в мире. Но M1 Max выигрывает только в 2.3 раза у Эльбруса по микроархитектурной скорости Spec2017.
А еще он сказал, что на пиковой нагрузке даже на 2.0 GHz они уже могут потреблять на уровне TDP. А значит без уменьшения числа ядер нельзя будет поднять частоту. Высокую частоту на легкой нагрузке можно сделать для баловства. Но в реальных серверах, где нужно будет всегда гарантировать предельные токи и потребление TDP для любой нагрузки, такие эксперименты ставить слишком рискованно. Проще выдать всем стабильные 2.0 GHz или 2.2 GHz.
Не все так однозначно.
Новейший Graviton3 использует ядро Neoverse V1, которое отличается от Neoverse N2 этими самыми гигафлопсами, которых там в 2 раза больше. Так они пожертвовали низким потреблением и числом ядер ради гигафлопсов. При этом у них гигафлопсов в ядре Graviton3 все равно меньше, чем в ядре Эльбрус-16С.
"Архитектурная скорость" на 1 GHz одного ядра для Int/Float Spec2017 RATE по "вашей" методике:
0.66 / 0.67 Baikal-M
0.75 / 0.84 Baikal-S
0.89 / 1.38 Эльбрус 8СВ
Тут нет никаких 1.5 раза прироста у A75 относительно A57. Пока получили только 13% и 26% прироста для int/float.
А рост частоты Байкала до 2.5 ГГц не является официальным. И они не сообщили какое напряжение нужно будет выставить для той частоты. Поэтому этот рост частоты до 2.5 ГГц могут еще и отменить.
А что насчет "архитектурной скорости" у ядер A75 в Байкал-S в сравнении с Эльбрусами на тестах SpecCPU 2017?
Как сильно увеличили ту "архитектурную скорость" в A75 относительно A57?
Вот тут ваш предыдущие комментарии по "архитектурной скорости":
Но получается, что архитектурная скорость ядра A75 все еще значительно ниже архитектурной скорости ядра Эльбруса для FP. И весь Эльбрус слабее только из-за низкого числа ядер.
А по частотам пока нет окончательной ясности для новых Эльбрусов и Байкалов. Например, даже новейший Graviton3 имеет частоту только 2.6 GHz, что не сильно отличается от новых Байкалов и Эльбрусов.
Вы написали:
Вот компания Nvidia, которая на уровне Intel или AMD, прямо заявила, что ее процессор Xavier делали 2 тысячи человек 4 года, и все это стоило 2 миллиарда долларов, что очень сильно противоречит всем вашим цифрам по стоимости разработки и числу разработчиков.
Поэтому такой важный факт по заданной теме тоже стоило упомянуть в статье. Можно, конечно, написать еще и предположение, что Nvidia соврала в этой оценке, а разработка Xavier стоила значительно дешевле, если вы так считаете. Но только Nvidia публично сообщила хоть какие-то цифры по стоимости разработки процессоров из всех мировых процессорных компаний.
Зачем Nvidia потратила в 20 раз больше на Xavier?
Вот тупые?
9900K - это всего лишь добавление 4 ядер в Skylake, который сделали уже давно.
Nvidia рассказывала про затраты на разработку своего последнего процессора Xavier:
With more than 9 billion transistors, Xavier is the most complex system on a chip ever created, representing the work of more than 2,000 NVIDIA engineers over a four-year period, and an investment of $2 billion in research and development.
При этом Xavier по CPU части в 2-3 раза слабее, чем 9900K, хотя там тоже 8 ядер.
А казалоcь бы, что такая крутая компания как Nvidia могла легко вместо 2 миллиардов потратить ваши "$100 млн", и сделать процессор уровня 9900K. Но они потратили в 20 раз больше, и сделали процессор слабее по производительности CPU ядер.
Поэтому в реальности все может отличаться и на порядок от приведенных циферок.
С другими примерами тоже не все так очевидно.
Nuvia не закончила разработку.
От SiFive физически доступна только дорогая плата unmatched, где процессор SiFive в разы слабее любых эльбрусов.
Esperanto ничего пока не довела до массового производства.
А по срокам разработки нужно учитывать дату tapeout и дату получения первого рабочего инженерного образца. Так tapeout для Элбрус-16С был где-то весной 2020. Тогда вероятно и закончилась основная часть разработки этого процессора. А после этого идет тестирование, устранение проблем, второй tapeout с исправлениями, и подготовка к серийному производству.
Нам вообще не нужен промежуточный A73, чтобы сравнивать XT-910 c российскими процессорами.
Есть известные данные
6.11 SPECInt/GHz - XT-910 - в статье
6.13 SPECInt/GHz - Cortex-A57 - это реальные тесты Байкала.
7.8-8.0 SPECInt/GHz - Cortex-A75 - это наиболее вероятная оценка, и которая есть на некоторых слайдах.
Этих соотношений достаточно, чтобы утверждать, что XT-910 проигрывает ядру A75. Поэтому они и выбрали A73 для сравнения, а не A75.
Аналогично для SCR7 выбрали совсем слабое ядро A53 на своих слайдах, чтобы не позориться на фоне высокой производительности ядер A57 и A72.
Посмотрите слайды XT-910.
Там перечисляют его характеристики:
• 3-decode，8-issue
Вот и подумайте для начала, чем issue отличается от decode. И не путайтесь в этих терминах.
У Эльбрус-16С есть 1500 GFLOPS на FP32. Это в 2.5 раза больше, чем у XT-910. А число ядер одинаковое - 16 штук.
Я уже написал свою основную позицию.
Ядро Эльбруса примерно на уровне A75 для INT, и сильнее ядра A75 на FLOAT.
Никаких RISC-V уровня A75 не существует физически. Только есть SiFive P550 в проекте. Но российским разработчикам до уровня ядра P550 очень далеко.
Если кто-то и придумает свои расширения RISC-V для FLOAT, то у Эльбруса тоже уже есть много этих GFLOPS.
Так фактически российские разработчики своих ядер выйдут на уровень производительности ядра Эльбруса только через несколько итераций и через несколько лет.
Не быстрее.
6.75 SPECInt/GHz - Cortex-A73 - в статье
6.13 SPECInt/GHz - Cortex-A57 - это реальные тесты
Попробуйте вписать A72 между ними.
A72 использовали в серверных Graviton и Kunpeng. А ядро A73 сделали специально для смартфонов. A73 не быстрее, но оно потребляет меньше.
Этим и отличается хорошая разработка от слабой.
A73 - это лучшее ядро, которое имеет только два декодера. Но никто больше не смог повторить на 2 декодерах такую высокую производительность.
SCR7 - тоже не смогли.
Так A75 - это очень хорошее ядро на 3 декодерах.
XT-910 - тоже 3 декодера. Но производительность ниже, чем у A75.
Так даже крупные разработчики на RISC-V проигрывают ядрам Cortex по производительности. А российские RISC-V проиграют еще больше. До уровня Cortex там очень далеко. А ядра Эльбрус уже на том уровне для INT, и даже выше для FP нагрузок.
Один бенчмарк - плохо.
Средний результат из 10 нагрузок - уже хорошо. Этого достаточно для точных оценок.
Coremark я не доверяю. Известно, что там даже простейшие мипсы без OoO накручивали до высокого уровня. Это слишком специфичный и мелкий бенчмарк, где научились хорошо прокачивать слабые ядра.
Там на слайде NBench A73 выиграл в среднем. Например, там есть нагрузка, где A73 выиграл у xt-910 в 1.6 раза.
EEMBC и Coremark - это мелкие нагрузки.
Нагрузки Spec 2006 показательнее, а там xt-910 проиграл. И так мы знаем, что xt-910 получился на уровне A57 в итоге - 6.11 SPECInt/GHz.
Выводы.
Крупная компания Alibaba спроектировала RISC-V ядро класса A57. Российские разработчики тоже смогут сделать такое ядро когда-нибудь в будущем. Но ядро Эльбруса уже производительнее этого уровня.
Перенос допустим. Найти реальные цифры Spec CPU2017 для A53 трудно. Никто не публиковал их. Но определить выигрыш A57 от A53 легко. Есть миллионы устройств на этих ядрах, и можно использовать то среднее преимущество на 70%, которое показывает geekbench 5.
И единственная надежная оценка производительности для SCR7 - это тот слайд про 20%.
В обоих случаях это не какой-то случайный результат на одной нагрузке, а среднее среди множества нагрузок - 9 штук для SCR7. И так же много нагрузок для geekbench.
Поэтому этим отдельным оценкам про 70% и 20% вполне можно доверять. И можно совмещать эти оценки в итоговый результат про 40% преимущества A57 над SCR7.
Когда не хватает конкретных конечных выводов, надо уметь пользоваться инструментами и данными, которые доступны.
Если сомневаетесь в моих выводах, попробуйте самостоятельно определить или найти информацию про то, как отличаются A57 и A53 по производительности.
A57 - это 3 декодера и OoO.
A53 - это 2 декодера без OoO.
Если бы между ними не было большой разницы по производительности, тогда такой OoO можно было бы признать бесполезным.
SCR7- это 2 декодера и OoO.