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

Это случайно или нет? decomp. ratio по отношению к ARM зависят у всех остальных ~линейно от частоты с коэффициентом ~1.5, а comp.ratio с коэффициентом ~2.

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

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

А что из десктопных / серверных задач хорошо параллелится на уровне инструкций?

Про декодирование слышал. Что-нибудь ещё? Или наперегонки с ноутбучными APU-шками декодировать видосики собрались? Так не догоните – у них читы в виде vaapi есть :D

А что из десктопных / серверных задач хорошо параллелится на уровне инструкций?

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

Так не догоните – у них читы в виде vaapi есть :D

Так и задачи такой не стоит ;) Обычно научные вычисления больше интересуют, результаты там гораздо ярче

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

С CUDA собрались соперничать? Вроде бы проскакивала инфа, что CUDA в предсказуемую погрешность не может…

Тогда с опен сорсным ROCm собрались соперничать? :D

У интелей, вроде бы, тоже была вундерваффе для научных вычислений – Xeon Phi.

На правах бреда – а может МЦСТ стоит не центральные процы делать, а видюшки? Ну а что, пре-GCN радеоны тоже VLIW были.

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

Ну а как по мне, десктопный проц в 2k19 должен быстро компилять в свои машинные коды – в браузере, в жабке и .NET – JIT. Раскраска и автодополнение кода на девелоперских машинах, по хорошему, требует построения AST. Gentoo опять же :D

Ну а остальное, даже на 10-летней давности нетбуке с AMD E-сколько-то, не тормозит.

алгоритм очень плохо параллелится на уровне инструкций

святая простота! :-) ну или мимикрия под простоту.. (там где это выгодно:))

тоесть это чтоже у нас получается?!!!

получается это что ПРОГРАММЫ виноваты в том что они медленные на Эльбрусах? :-) а не Эльбрусы виноваты что не могут их быстро исполнять???

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

нельзя?!

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

Вообще говоря зависит от того как написать.

А как написать — это уже лет 20 как gcc/x86(_64). Сколько было надежд на, например, GPU — ну никак оно для прикладника не проявляется, кроме узких областей, узкому кругу интересных. Написанный вполуручную код для радстойких и медленных FPGA тоже не представляет широкого интереса.

Чистым экспериментом будет взять фортрановский код, написанный до x86/gcc, собрать его заточенным под Эльбрус компилятором, слинковать с родной матбиблиотекой, и сравнить логическую скорость с gcc/x86_64.

святая простота! :-) ну или мимикрия под простоту.. (там где это выгодно:))

Причём здесь это? Просто я понимаю что где как и зачем измеряется, понимаю почему результаты такие а не другие.

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

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

Заранее спасибо

Хотя судя по вашему молчанию уже можно сделать некоторые предположения

Отнюдь. На ваш вопрос аноним кинул ссылку на свежую публикацию, мне показалось что этого достаточно (рекомендую её прочесть). Если нет, то дополню.

Во-первых память в Эльбрусах тэгирована всегда - это необходимо для работы в нормальном режиме. То про что Вы говорите называется «защищённый режим». Он позволяет на аппаратном уровне искать выходы за границы массивов, работу с невалидной памятью. Работы над ним постоянно ведутся, это всё ещё одна из крутых фишек Эльбруса. Безусловно, внедрение такого механизма связано с некоторыми трудностями. Например пока что пришлось использовать библиотеку uClibc в качестве стандартной. Также пришлось немного доработать входы в ядро.

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

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

С CUDA собрались соперничать? Вроде бы проскакивала инфа, что CUDA в предсказуемую погрешность не может…
Тогда с опен сорсным ROCm собрались соперничать? :D
У интелей, вроде бы, тоже была вундерваффе для научных вычислений – Xeon Phi.

МЦСТ ни с кем не соперничает, а выполняет ОКРы минпромторга. Остальное - побочные эффекты.

На правах бреда – а может МЦСТ стоит не центральные процы делать, а видюшки? Ну а что, пре-GCN радеоны тоже VLIW были.

Есть ОКРы на видюшки?

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

Да много чего. Где-то с 25:50 идёт рассказ про разрабатываемые машины, и то кто и где их применяет. Там вся лекция интересная, но звук кошмарный.

Ну а как по мне, десктопный проц в 2k19 должен быстро компилять в свои машинные коды – в браузере, в жабке и .NET – JIT. Раскраска и автодополнение кода на девелоперских машинах, по хорошему, требует построения AST. Gentoo опять же :D

Ну, JIT есть, работает вроде как.

Ну а остальное, даже на 10-летней давности нетбуке с AMD E-сколько-то, не тормозит.

Кек, у меня гуглопочта на i5-6500 тормозит :)

Просто так сложилось что за десятилетия доминирования интела, который покрывал кривой код программистов (причём не только по производительности, но и по безопасности), программисты разучились писать, и теперь у меня на i5-6500 гуглопочта грузится по 15 секунд и больше.

А сам что-то про конструктивность говорил…

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

Во-первых память в Эльбрусах тэгирована всегда - это необходимо для работы в нормальном режиме. То про что Вы говорите называется «защищённый режим». Он позволяет на аппаратном уровне искать выходы за границы массивов, работу с невалидной памятью. <...> Заставить работать ядро в нём - сомневаюсь.

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

Например, здесь в 20k строк на Go + 1.5k строк asm запрограммировали для x86_64 ядро, поверх которого исполняется nginx, redis + необходимые библиотеки: https://www.usenix.org/conference/osdi18/presentation/cutler

Вам, насколько понимаю, костыль типа Go не нужен, так как контроль обращений к памяти уже в аппаратуре, и можно писать на привычном C.

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

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

Почему тогда нельзя собрать для защищенного режима glibc?

Это замечательно, что прозрачно для пользователя. Но ведь там упоминается возможность для пользователя управлять тегами (выставлять 0b00 - число или 0b01 - неинициализированное значение). Или под пользователем имелся в виду компилятор?

Кстати, о прозрачности этого режима для разработчика стоило бы упомянуть где-то большими буквами. Как ни странно, но это не очевидно, я искренне полагал, что инициализация такого массива требует использования отдельного API. Вот здесь и проявляется типичный недостаток российского подхода - никто не хочет «нянчиться» с клиентом по принципу «мы тут создаем уникальные вещи и нам некогда все разжевывать и в рот класть, у нас слишком высокий уровень чтобы тратить время на такую ерунду». А разжевывать то все равно надо, ведь клиент в итоге видит другую картину, не такую как специалисты изнутри, это приводит к недопониманию. Надеюсь, МЦСТ преодолеет этот момент.

Как минимум из-за слишком большой кодовой базы. А ведь всё это надо ещё и отлаживать. Здесь можно примерно оценить масштабы работ даже по простым функциям:

Перенос из glibc и отладка libm в uclibc-ng: 7 ошибок
Исправлен алгоритм работы с глобальной переменной signgam в функций lgamma, lgammaf, lgammal
Исправлены реализации функций nan, nanf, nanl, strtof_nan, strtod_nan (возвращали значение nan с неверной мантиссой)
Добавлена поддержка работы с флагом исключения FE_DENORMAL
Был добавлен изначально отсутствующий функционал обработки исключений математических функций с помощью функции matherr. Функция-обработчик может быть определена пользователем для перехвата исключений (аналог try/catch в C++).

Возможно потому что у защищенного режима указатель 128 бит, что сделает невалидным любой алгоритм, где предполагается строго 64 бита?

Или под пользователем имелся в виду компилятор?

Думаю, имелось ввиду что присвоение значения переменной в программе меняет тэг с 0b01 на 0b00.

Возможно потому что у защищенного режима указатель 128 бит, что сделает невалидным любой алгоритм, где предполагается строго 64 бита?

Эта проблема встречается не только в glibc. Для решения пришлось много с бубном танцевать

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

Это уже как проект пойдёт. Скорее какую-нибудь ОС реального времени попытаются доработать.

Эта проблема встречается не только в glibc. Для решения пришлось много с бубном танцевать

Вот кстати в D массив как раз 128 бит, т.к. содержит указатель+размер. И зависимость от стандартной сишной либы в D опциональна. Было бы интересно портировать его на Эльбрус, как минимум Эрланг же портировали, если не ошибаюсь, причем чуть ли не случайно? Насколько будет сложно с организационной точки зрения, чтобы разработчики компилятора выложили в открытый доступ все необходимое для портирования других языков? Бекэнд ведь можно в блобах предоставить, т.е. открывать нужно только документацию в части glue layer между фронтэндом и бекэндом (имхо, я тут не специалист).

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

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

Да, речь про сторонних разработчиков. А можете поподробнее про конвертер, что он из себя представляет в общем и что реализовано в частности?

Да, речь про сторонних разработчиков. А можете поподробнее про конвертер, что он из себя представляет в общем и что реализовано в частности?

Наверное, могу в общих словах сказать - транслятор из LLVM IR в представление lcc. Делается для rust'а, если быть точным, то для работы новых firefox. Подробностей пока не скажу

Подробностей пока не скажу

Но все равно же интересно!) Это будет adhoc решение лишь бы лиса собралась или более общее решение? Когда можно будет подробности узнать?

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

почему бы их не освещать полуофициально?

потому что найдется гипотетический хер-с-горы, который будет заявлять (а то и последствия устроит), вот, де, имярек, аффилированный с ООО «Рога и Копыта» производит на стороннем ресурсе слив стратегической информации.

в какой-то мере, я автора понимаю…

так-то, да, всё это довольно-таки интересно, и я недоумеваю с обсираторов, которые тут недавно набижали…

Но все равно же интересно!) Это будет adhoc решение лишь бы лиса собралась или более общее решение? Когда можно будет подробности узнать?

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

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

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

Да, это было бы круто и интересно, но как бы это было с технической стороны. Для этого от каждого отдела нужен специальный человек, который: 1. Умеет говорить/писать 2. Хочет и любит это делать. 3. Уточняет что и когда говорить можно, а что и когда - нет. 4. Имеет загрузку, позволяющую этим заниматься. Найти человека, хорошо владеющего хотя бы одним из этих пунктов - уже проблема.

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

Хотя, есть у нас один неофициальный информатор - Макс Горшенин. У него есть ютуб канал, свой сайтец, он ведёт группу вк, там периодически проскакивает занятный материал. Но да, именно инженерных подробностей там мало.

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

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

С интересом буду ждать результатов. На самом деле возможность трансляции с llvm ir в коды Эльбруса это очень значимая веха будет.

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

Вам за это отдельное спасибо!