МЦСТ раскрыл исходные коды компонентов Linux, системных библиотек и ПО для платформы «Эльбрус»

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

Неоднократно обновлялся компилятор, вышел Эльбрус 6 поколения, а те кто не хотел заниматься онанизмом оптимизацией пришли к методу «запинать толпой»

https://www.youtube.com/watch?v=-3rNcjoIR2I

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

Решить вопрос качества, количеством ядер.

может пора этот вопрос тогда уже и в ширнармассах обсуждать

Что и делается, тем или другим способом.

на большее времени нет

Для этого и существует сервис «краткого пересказа», https://300.ya.ru/v_XQgxa0qK. Но в данном случае, краткий пересказ уж очень краток ) - три небольших абзаца от 20 минутного видео.

Главное, чтобы кристалл в стойку помещался

Внезапно https://rscgroup.ru/product/rsc-tornado-servers/tqn310e/

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

// Акцент у дамы по ссылке весьма занимательный.

Я-я, зер гут.

Ну, я ж ведь не дурак, по четвертому-то разу на Ваши ссылки смотреть. Вы мне про Фому, я я Вам про Ерему. Компилятор в студию! Бинутилс в студию! Полное описание процессора в студию! А это все ВАше «вокруг да около» и «только для избранных» оставьте себе. Не пойду я в вашу песочницу, мне своих хватает. Вот пока вы будете обсуждать методы оптимизации «узким кругом», круг ваш ну никак не расширится. И ничего кроме срача здесь и пары толковых статей на Хабре в год на выходе не будет.

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

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

Слишком кратко. :)

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

Компилятор lcc медленный. Это осбенность VLIW компиляторов — в этой архитектуре на него вся надежда. Поэтому не надо сравнивать время компиляции, компиляторы под VLIW всегда будут медленнее компиляторов под x86_64.

Получайте удалённый доступ и крутите, как хотите. Документация также в наличии.

http://ftp.altlinux.org/pub/people/mike/elbrus/docs/elbrus_prog/html/chapter10.html

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

Комментарии МЦСТ к тестированию СБЕР

http://www.mcst.ru/files/61c195/f2dece/61d641/e4549f/sber_kommentariy_mtsst.pdf

У Газпромбанка с «Эльбрус» проблем не возникло.

Меня интересует не время компиляции как таковое, а «запас по оптимизации» для произвольно взятого кода на классе задач. Счетную задачу оптимизировать можно. А задачу компиляции, то есть, по-сути, поиск по таблице и проход по конечному автомату, и так много раз, — нет. А с «производительностью в среднем» у Эльбруса плохо. Ну вот и приехали.

Разработчик неосознанно оптимизирует свой код под ту платформу, на которой сидит он сам. Это было очень заметно, когда я сидел на RPi4 в качестве десктопа. Поэтому тут всё равно сравнение будет не очень.

Но в целом, кто бы занялся :-)

Я сменил в жизни штук шесть платформ. Для определенной ОС писал, конечно. Для VMS надо писать не так, как для UNIX. Но вот так, что бы для конкретного процессора... Ну ассемблерные вставки, разве что. Всегда было требование портабельности в той или иной степени.

У Газпромбанка с «Эльбрус» проблем не возникло.

Ну, может быть, Эльбрус уложился в их технические требования. Такое возможно. А, может быть, просто «политика». :(

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

К такому выводу можно прийти, зная историю МЦСТ. Эмулятор процессора Эльбрус еще на СПАРКах они еще в 90е как-то сделали, и змулятор x86го у них появился раньше нативного компилятора, насколько можно предположить.

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

Зачем тогда вообще lcc? Генерим код x86_64 чем угодно -> пропускаем через lintel -> profit!

Можно заключить то, что режим двоичной трансляции на «Эльбрус», по крайней мере в данном случае работает весьма эффективно и не сильно уступает нативному.

Примерно такие же заявления мы слышали в своё время от трансметы, поэтому там не бились лбом о компилятор, а просто транслировали х86.

И где теперь эта Transmeta.

«К чему этот долгий и мучительный путь?» — подумал он и вылил бутылку пива в унитаз... :)

Ну так на открытом рынке-то и Эльбрус там же уже был бы...

Это верно. Но верно и обратное — нативный режим особого выигрыша не дает. А вот это уже сильно хуже.

Теорэма о независимости от промежуточного представления? Забавно-с.

Ну вот в силу этого я и предположил, что компилятор устроен именно так, что транслирует в конечные команды нечто похожее на x86. Если прочитать вышеприведенную статью на Хабре про e2k-бекенд для llvm и про родство компиляторов и двоичного транслятора, то еще больше как-то утверждаешься в этом мнении. А если еще учесть ограниченный человеческий ресурс разработчиков, то ничего другого и придумать нельзя.

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

Есть группа преобразований алгоритма, оставляющая инвариантным результат его выполнения. Для любого представления алгоритма можно найти преобразование, приводящее его к виду, дающему минимальное время исполнения на данной железке. То есть неважно, представили алгоритм в виде машинного кода x86_64, или в виде псевдокода на выходе clang или фронт-энда lcc – все равно он преобразуется в машинный код e2k единственного предельного вида (с точностью до остаточной группы преобразований, не меняющих время выполнения).

Как-то так в изложении нематематика.

Примерно такие же заявления мы слышали в своё время от трансметы, поэтому там не бились лбом о компилятор, а просто транслировали х86.

Там разве не собирались выполнять всякую вендопоцприетарщину без исходников?

Э, батенька, завязывай с обобщениями. А то мы с тобой сейчас до теории вычислимости, теории категорий и монад договортмся. :) А я с собакой гуляю, вот покурить присел. До утра курить придется.

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

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

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

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

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

Это неудивительно, что написано для х86-64 и будет хорошо работать в этом режиме.

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

Если оптимизировать, то разница по сравнению с х86-64 может достигать порядка, за счёт архитектурного превосходства «Эльбрус».

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

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

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

Поручик, давайте что ли про баб-с?

Поручик, давайте что ли про баб-с?

Спорили тут как-то бабы об архитектурном превосходстве... ;)

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

Поэтому наивный вопрос: в этом случае достигается максимально возможная для данного алгоритма производительность?

И встаёт вопрос - а нужен ли такой сверхумный компилятор, если от него прока не слишком много?

Что-то подсказывает, что бОльшей части компилятора, генерящей оптимизированный машинный код e2k, все равно, из чего его генерить. Вопрос: эта часть общая для бэкенда lcc и для lintel?

Мну не математик-программист, чтобы это обсуждать.

Может быть стоило просто исходники исправить, чтобы и обычный компилятор их переварил к виду удобному для Эльбруса?

clang/clang++ в среднем такое же время исполнения дает, как и lcc. Потому что бэкенд у них один и тот же.

// Кстати, у фронтенда clang более внятные сообщения об ашыпках. Например, при вызове члена класса, неявно объявленного как private, clang++ так и пишет. А lcc в простоте своей говорит «член не доступен».

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

Вопрос не имеет смысла.

Вопрос: эта часть общая для бэкенда lcc и для lintel?

Это ровным счётом ничего не меняет

clang/clang++ в среднем такое

И чё?

Это на форуме. :)

Ну, кстати, интересно бы было иметь jit-компилятр арма на эльбрусе. И сравнить.

Запас по оптимизации, заметим, --ручной, на счетных задачах продемонстрирован. Окей. А что с задачами управления, реальным временем и тд? Как е2к себя ведет на анализе трафика, например? Чот нигде нет данных.

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

И почему мне всё это вдруг напомнило старый анекдот про японскую бензопилу и суровых сибирских лесорубов??.. ;) :))

Только пила не японская :)

Вопрос не имеет смысла.

Если вам ужэ таки все понятно, объясните популярно для прикладников?

Только пила не японская :)

И мужыки ужэ не те, а то бы огого.

«Эльбрус» обходил «Байкал», не помогли даже покупные ARM ядра.

«Эльбрус» используют для аналитики

http://www.mcst.ru/files/603669/c9dece/610e79/90a70b/210216_elbrus_tech_day._3logic_group_graviton.pdf

http://www.mcst.ru/files/61c194/72dece/615141/e4549f/balabanov_m__3logic_vnedrenie_pak_pautina.pdf

Наоборот, «Эльбрус» и создавался для обработки больших массивов данных.