GCC для «Эльбруса»

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

Пытался разок (правда на sanitizer). Но разбирать runtime ошибки в проекте, которым не занимаешься долго и сложно. Особенно если не можешь предоставить исходник, на котором падает. Не осилил, короче.

Очень странно сравнивать -O3 у совершенно разных компиляторов, не имеющих общей кодовой базы. Где-нибудь точно существует компилятор, у которого -O16 является валидной и совершенно безопасной опцией 8).

Справедливо, но в данном случае сравнение относительно корректное. По крайней мере в случае с gcc мне приходилось сбрасывать опции до -O1, а разок даже до -O0 чтобы заработало.

Гента и гентоюзеры, у которых половина мана gcc в CFLAGS - это отдельный вопрос.

Если мне не изменяет память, то у меня там только -O3 и было. Так вот, у меня vim давал segfault прям при запуске. Причём здесь я готов поверить что это vim кривой. Но на штатных бенчмарках (SPEC CPU 2006) мне приходится на некоторых тестах занижать уровень оптимизаций.

По крайней мере в случае с gcc мне приходилось сбрасывать опции до -O1, а разок даже до -O0 чтобы заработало.

Просто пиши код без UB.

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

По крайней мере в случае с gcc мне приходилось сбрасывать опции до -O1, а разок даже до -O0 чтобы заработало.

Просто пиши код без UB.

Да ладно! А я то думал о_О

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

Падающий код, кстати, был из известного бенчмарка.

Скорее обнаружив падение прописываете -O0 в ключи. А потом начинаете рассказывать, что вот-де, надо без оптимизации собирать, падет же.

Но на штатных бенчмарках (SPEC CPU 2006) мне приходится на некоторых тестах занижать уровень оптимизаций.

С результатами для е2к возможно ознакомиться?

Но на штатных бенчмарках (SPEC CPU 2006) мне приходится на некоторых тестах занижать уровень оптимизаций.

С результатами для е2к возможно ознакомиться?

Год или 2 назад сливали в сеть результаты, но они несколько устарели - сейчас те же машины сильно лучшие результаты показывают.

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

Я правильно пониманию, что после анонса(?) архитектуры проца, она принципиально не менялась, а последние цать лет был пердолинг с разработкой компилятора под нее?
Какой % от теоретически возможной производительности при кодогенерации сейчас достигнут?
Есть ли какие-то математические(или любые другие, хоть эмпиричные(вручную асме)) обоснования, что эффективная реализация типичных востребованных алгоритмов на ней возможна?
Или есть производительные киллер-фичи, которые востребованы именно в ВПК?

Или есть производительные киллер-фичи, которые востребованы именно в ВПК?

производительные
ВПК

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

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

Ну есть еще вопрос надежности, отказоустойчивости, защиты. Бабаян вроде говорил, что даже баги там проще ловятся.
Но вся эта секретность - security through obscurity. Потенциальные злоумышленники, я уверен, давно имеют на руках всю документацию(если вообще существует предмет разговора). Больше похоже на попытку прикрыть голого короля.

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

Видел их реализацию «доверенной загрузки». Такое в провинциальном университете даже в качестве курсача стыдно было бы сдавать.

Что у них с остальным можно себе представить.

Я правильно пониманию, что после анонса(?) архитектуры проца, она принципиально не менялась, а последние цать лет был пердолинг с разработкой компилятора под нее?

Что считать анонсом? Ей нормально смогли заниматься примерно со времён Эльбрус-4С (система команд v3). Потом был Эльбрус-8С (система команд v4). Скоро будет Эльбрус-8СВ (система команд v5). В разработке Эльбрус-16С (система команд v6).

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

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

Какой % от теоретически возможной производительности при кодогенерации сейчас достигнут?

А для какой задачи и на какой машине? :) Например в пакете Linpack процент от пиковой производительности для Эльбрус-8С следующий:

• 85% на HPL
• 6+% на HPCG (выжали ещё не всё)

Это довольно дофига, для сравнения можно посмотреть результаты здесь.

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

Просьба пояснить. Есть относительно объективные бенчмарки, которые говорят что ещё как возможна.

Или есть производительные киллер-фичи, которые востребованы именно в ВПК?

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

Что у них с остальным можно себе представить.

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

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

У нас есть такие приборы, но мы вам их не покажем)

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

У нас есть такие приборы, но мы вам их не покажем)

Приходи на любую тематическую выставку, тебе всё покажут, расскажут, дадут попробовать

Что, и даже физлицу продадут?)

Это довольно дофига, для сравнения можно посмотреть результаты здесь.

Это довольно на уровне «студенты оптимизировали».
По твоей ссылке суперкомпьютеры, а в пределах одной системы утилизация на x86 на уровне 90-95% от пиковой теоретической.

// Например сейчас рядом шуршит Ryzen о 8 ядрах с ~230 GFlops при пиковых 256 для этой частоты.

Что, и даже физлицу продадут?)

Нет, зачем?

Это довольно на уровне «студенты оптимизировали».
По твоей ссылке суперкомпьютеры, а в пределах одной системы утилизация на x86 на уровне 90-95% от пиковой теоретической.

Лол что?

// Например сейчас рядом шуршит Ryzen о 8 ядрах с ~230 GFlops при пиковых 256 для этой частоты.

А теперь HPCG по нему в студию

6+% на HPCG (выжали ещё не всё)

Этот тот тест, на котором векторные машины рвут всё и вся?

По идее, тест проверяет скорость обращения к памяти. Но с векторными машинами это всё равно не честно, потому что латентности там съедаются.

А теперь HPCG по нему в студию

Не Ryzen, но близко:

Genji AMD – bull Ghibli, AMD EPYC 7301 16C 2.2GHz, Mellanox EDR Infiniband Bull, Atos Group

Fraction of Peak = 4.0%

Там 16 сокетов, если я правильно понял. Наверное, с увеличением числа нод эффективность теста не растёт.