Эльбрусы снова делают

видео да ещё VK... Но спасибо.

Я веб-макака, откуда мне знать тонкие материи про все эти ваши детерминированные выполнения, «невидимость» спекуляции кешей, спекулятивные выполнения по косвенному адресу.

Я хочу тыкать кнопочки и чтобы все работало само. Вон там выше специалистов море.

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

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

Ты словно не в 21 веке живешь. ) Есть же сервисы пересказа, тот же 300.ya.ru.
Но да, там 2-х часовое видео, так что не быстро.

А насчет вк, достаточно перетащить ссылку на плеер mpv. Когда пошла вся эта чехарда с ютубом, выкладывал на ЛОРе видео с сервисов вк и рутуба, и каждый раз делал упоминание про mpv, и что заходить на сайт необязательно, зная отношение к ним у некоторых ЛОРчан.

Плюс, у данной ссылки таймкоды в наличии.

Отрывок пересказа яндекса:

 00:19:53 Производительность Эльбруса

    • Эльбрус требует более тщательной оптимизации кода по сравнению с Intel.

    • Включение флага -3 компиляции ускоряет код в 7,5 раз.

    • Для равномерной загрузки всех ядер необходимо хорошо знать компилятор и его оптимизацию.


00:21:53 Рекомендации по написанию кода

    • Частые функции лучше держать в хедерах для лучшей работы компилятора.

    • Инкапсуляция и выделение сеттеров и геттеров в отдельные модули может замедлить код.


00:22:51 Совместимость с x86

    • ПО, написанное под x86, может плохо работать на Эльбрусе.

    • Возможность запуска ПО под x86 на Эльбрусе существует, но эффективность будет низкой.


00:23:50 Бинарный транслятор

    • Бинарный транслятор существует и работает неплохо, обеспечивая 70–80% производительности от Intel на той же частоте.

    • Проблема может быть в разнице частот процессоров.

    • Известны случаи запуска Windows 7 под бинарным транслятором.


00:24:44 Портирование софта на Эльбрус

    • Софт на C++, Fortran и других языках легко портируется на Эльбрус, если он компилируется под GCC или C-Lang.

    • Можно использовать алиас для запуска GCC, который потянет за собой LCC.

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


00:26:40 Особенности ассемблера на Эльбрусе

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

    • Рекомендуется сначала использовать компилятор с опциями O3 и LTO, прежде чем переходить к ассемблеру.

    • Переписывание на ассемблере может быть сложным и долгим процессом.


00:27:35 Портирование системных ОС

    • Ядро операционной системы и базовые тулы уже портированы для Эльбруса.

    • Дистрибутивы Debian-based также частично портированы.

    • Проблемы с FDF и другими ограничениями часто решаются добавлением собственных конструкций.


00:29:21 Открытость экосистемы Эльбрус

    • Эльбрус выпустил кросс-компилятор в open source.

    • Стремление к открытости существует, но ограничено юридическими и коммерческими ограничениями.

    • Основные источники информации об архитектуре Эльбрус доступны на сайте.


00:31:43 Прагмы и оптимизация

    • Прагма loop count помогает компилятору оптимизировать циклы, указывая количество итераций.

    • Оптимизации могут иметь оверхед, поэтому важно учитывать количество итераций.

    • Знание длины цикла и выравнивание данных важны для эффективной оптимизации.

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

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

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

Ты устарел, центурион. Смотри последние модели.

Так что там с перым языком то?

Ты какую-то ерунду пишешь. Сам изучи тему перед отвветами.

Там есть «режим безопасных вычислений», который отслеживает всякие use-after-free и другие ошибки при работе с памятью. Подробностей не знаю, не специалист.

Мы тоже думали, что все недостатки и неподъёмную сложность железа можно решить программно. Сейчас я знаю, что вера в компилятор утопична.

На мой взгляд, то, что можно сделать заранее, надо делать компилятором. То, что надо делать в процессе выполнения, надо делать процессором. Режим Безопасных Вычислений в процессоре обеспечивает безопасность с потерей 20% скорости. Аналогичный программный Fil-C с потерей в разы. Но определение порядка выполнения микрокоманд можно сделать заранее. Интел не делает только потому, что в ISA x86 нет нужных команд (для определения порядка выполнения), а совместимость надо обеспечивать.

И компилятор уже работает не хуже планировщика Интел (потому что у планировщика алгоритм очень простой), а в большинстве случаев лучше (всегда, если надо учесть операции идущие после или если время алгоритма оптимального выбора зависит от объёма контекста, а в процессоре приходится выбирать неоптимальный, но с временем работы O(1)).

Там два набора. Один неотключаемый (отдельный стек адресов возврата), второй отключаемый (режим безопасных вычислений, обеспечивающий проверку указателей на корректность). Второй снижает скорость примерно на 20%, но в основном по той же причине, по которой аналогичное снижение было при переходе с 32 бит на 64: для безопасных вычислений указатель 128 бит.

Я это вижу немного по другому. Есть задача - сделать максимально дешёвый и простой кремний с максимально высоким потенциалом производительности. Почему выбран именно такой баланс сейчас к делу не относится. Сказано - сделано. Всё остальное - это объяснялки, почему то, что можно было сделать в кремнии сделано не было. Как результат, имеем изделие с минимальной начальной производительностью но почти безграничными возможностями для оптимизации.

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

очень плохой процессор общего назначения

Он уже не хуже любого Интела с той же частотой.

И компилятор уже работает не хуже планировщика Интел (потому что у планировщика алгоритм очень простой), а в большинстве случаев лучше…

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

Что должен делать компилятор если:

• возникает конфликт по банкам?
• данные обычно лежат в L2?
• данные обычно лежат в L3?
• данные обычно лежат в ОЗУ?
• несколько непредсказуемых обращений в память?
• после обработки данных из памяти идёт вызов функции?

Я намеренно игнорирую маркетинговые сравнения с решениями Интел, АМД, или АРМ. Это непрофессионально. Хотите таких сравнений - покажите значения SPEC CPU.

Может как процессор выполнять те команды, которые можно выполнять без данных из этой памяти (если таковые есть в очереди).

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

после обработки данных из памяти идёт вызов функции?

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

https://www.altlinux.org/Эльбрус/тесты/результаты
SPEC нету, но есть ещё немало интересного.
На инженерник 16С есть тут https://habr.com/ru/companies/icl_group/articles/648219/

У меня пока где-то 2.5 года работает (но младший), тьфу тьфу пока живой. Пыхтит своими двумя ядрами кушая электроэнергию.

SPEC CPU

Эльбрус-8С, 1,3 ГГц.

SPEC INT 2006: 13.03

SPEC FP 2006: 17.02

https://sdelanounas.ru/blogs/95446/

Спасибо за ответ. Это наглядная демонстрация утверждения:

разбивается в пух и прах когда вспоминают про память

Ну вот это уже что-то. Теперь если отбросить то, что это неофициальные источники и мы не можем посмотреть, соблюдены ли правила тестирования, но мы можем с уверенностью говорить, что значение 13.03 где-то в районе одноядерного Xeon 5130 или четырехядерного Opteron 8220 SE. Это уже прямо показывает, где примерно расположен это процессор среди типичных четырёх-шестнадцатиядерных процессоров 2005-2010 годов. Для этого времени на этих задачах типичный кремний даёт значения порядка 50-70. Много 13.03 или мало уже нужно судить по другим критериям.

Здесь, безусловно, собрано большое количество тестов, оценить которые на первый взгляд не так просто. Сразу вижу, что одноядерные решения очень слабые, STREAM в районе 2GB/s и Linpack - 800 MFlops это решения конца 90х. Хорошо, что кто-то проделал большую работу, протестировал, собрал в едино. Если мне когда-нибудь понадобится такое сравнение, я знаю, где взять.

Кстати, для 16с SPEC CPU 2006 int rate тоже указано значение 24, что совпадает по порядку с 13.03 из другого источника. Это полностью подтверждает первоначальный тезис, что возможности компилятора сильно переоценены. Без ручного вмешательства выжать разумную производительность не представляется возможным.

что значение 13.03 где-то в районе одноядерного Xeon 5130 или четырехядерного Opteron 8220 SE

Я же написал, сравнивай с любым на 1,3 ГГц. Или масштабируй на частоту. Тогда можно будет оценить эффективность планировщика (микро)операций.

Или масштабируй на частоту.

С чего бы?

Или масштабируй на частоту.

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

Зачем это? Не нужно играть цифрами.

Больше будет, очевидно, но до 5ГГц VLIW отмасштабировать врядли возможно.

Можно, почему нет? Если сделать восемь целочисленных ALU, то можно их все на 5GHz загрузить без ущерба расплавить.

Зачем это? Не нужно играть цифрами.

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

С чего бы?

С того, что результаты SPEC CPU пропорциональны частоте. И с того, что оптимальность распределения команд от частоты не зависит.

А кроме инт АЛУ там критический путь разве не больше чуть ли не на каждой стадии конвейера?

Нет, если сравнивать эффективность архитектуры, вообще не нужно трогать конкурентов. Нужно брать задачу, скажем из того же SPEC, их там порядка 50. Для этой задачи генерируется SPEC значение в автоматическом режиме. Потом берётся алгоритм задачи и вычисляется его степень параллелизма в виде ILP. После этого одно делится на другое - вот это настоящая немаркетинговая эффективность. А подгонять цифры под частоту - это монка Бабаян научил, большой был специалист жонглировать результатами.

С того, что результаты SPEC CPU пропорциональны частоте.

Это ложь. Легко проверяется делением одного на другое для разных архитектур и компиляторов. Возьмите любой Интел процессор, прогоните SPEC с использованием icc, icx, и gcc. Убедитесь, что результаты будут разные. Как так, ведь частота процессора не менялась?

вычисляется его степень параллелизма в виде ILP. После этого одно делится на другое

Для тебя чем ILP ниже, тем лучше???

Возьмите любой Интел процессор, прогоните SPEC с использованием icc, icx, и gcc. Убедитесь, что результаты будут разные. Как так, ведь частота процессора не менялась?

Естественно. Пропорционально частоте при равных условиях. Возьми процессоры Интел с одинаковой архитектурой, SPEC будет строго пропорционален частоте (если не упирается в производительность памяти).

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

Так делить на автоматическое или на максимально возможное предлагаешь?

А вот вы просто сходите в табличку и посмотрите результаты для одного и того же процессора от разных спонсоров. Убедитесь, что частота тут не при чем. Да и зачем гадать, объясните разницу между base и peak.

одно на другое.

степень параллелизма в виде ILP. После этого одно делится на другое - вот это настоящая немаркетинговая эффективность

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

Возьми процессоры Интел с одинаковой архитектурой, SPEC будет строго пропорционален частоте

Но ты то предлагаешь масштабировать Эльбрус на Интел. Причём тут одинаковая архитектура? Во времена 8-и битных процессоров, был такой MOS 6502, весьма популярный. Он делал команд на такт значительно больше z80, однако, более 1Mhz не гнался. А Z80 - гнался до 4-8. В результате, Z80 оказался быстрее. Вот, разгоните для начала Эльбрус, а потом масштабируйте.

Отличный пример быстрого дрочева на трёх регистрах )

Так там же стандарты одинаковые должны быть, формат схем и т.д.

Нет. Каждая фабрика поставляет свое ПО, чтобы в нем подготавливали проект под ее оборудование, если ты не хочешь отдавать на сторону свой Verilog/VHDL, который, конечно же, сразу же сопрут хоть тайваньцы хоть китайцы.

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

ILP - это не свойство процессора, это свойство алгоритма задачи. Здесь две независимые вещи. Архитектура процессора позволяет выполнять несколько операций одновременно. Вопрос 1 - может ли процессор безопасно загружать все свои устройства продолжительное время? Допустим, что да, хотя сейчас такие процессоры больше не делают. Независимо от процессора, есть задача, алгоритм которой допускает параллельное выполнение операций. Вопрос 2, может ли компилятор автоматически скомпилировать программу с соответствующей степенью параллелизма. Монк говорит - да, легко. Я говорю вообще нет шансов. Вопрос 3, поскольку я говорю, что шансов нет, я спрашиваю насколько далёк компилятор от совершенства? Это и есть эффективность.

Скажу ещё одну вещь. Доказать не могу. Получено эмпирическим путём. Итак тезис такой «любой код скомпилированный современным компилятором можно сократить на треть.» Это убивает тезис ILP, поскольку если это правда, то процессор выполняет много мусорных ненужных инструкций.

Эльбрус-8В7 уже 2,5ГГц.

Только его никто не видел.

Кто-то видел: https://tehnoomsk.ru/wp-content/uploads/2025/10/%D0%AD%D0%BB%D1%8C%D0%B1%D1%80%D1%83%D1%81-8%D0%927_%D0%AD%D0%BB%D1%8C%D0%B1%D1%80%D1%83%D1%81-32%D0%A1-%D0%9C%D0%A6%D0%A1%D0%A2-2025-1024x650.webp

Это ИИ рендер.

Синьюз - это такая же помойка, как и всё остальное.