Процессор Эльбрус — почему статья о тупике несостоятельна
На протяжении почти двух десятилетий рунет пестрит различными негативными статьями об Эльбрусах. В течении последних десяти лет я наблюдал развитие риторики с «существует только в виде .jpeg» до «дорогой и медленный». В основном вся эта риторика исходит от людей, которые машину в глаза не видели, и тратить время на ответы таким людям смысла не имеет. Но недавно на Хабре вышла довольно резонансная статья про тупиковость развития Эльбруса. В целом она не отличается от общей массы таких статей (состоит из манипуляций и ошибок), но кое-что в ней заставило меня написать ответ.
Сейчас России наблюдается чёткое движение в сторону импортозамещения, что, безусловно, не может не радовать. А последние несколько лет мы можем отметить реальные результаты в виде потери крупными иностранными игроками больших долей на российском рынке. Разумеется, такие успехи нравятся не всем, и лоббисты стремятся переписать правила игры прямо на ходу. И вот, в это непростое время @Armmaster бывший сотрудник МЦСТ, ныне сотрудник одного из страдающих крупных иностранных игроков публикует статью в лучших антиэльбрусовских традициях. С учётом личности автора моё чувство справедливости на столько ущемилось, что я решил разобрать статью бывшего коллеги.
Собственная архитектура
Парадокс в том, что это большой недостаток. Проблема в том, что своя архитектура означает портирование всего стэка софта, необходимого пользователям.
На текущий момент наиболее распространённой архитектурой процессоров общего назначения является x86_64. Существует ещё несколько популярных архитектур, но пока что никто из них не вышел в нишу настольных компьютеров, а в серверном сегменте сдвиги только начинаются. В момент продвижения архитектуры ARM все дружно двинулись переносить своё ПО на него, никто не говорил что собственная архитектура — это плохо. Сейчас в Европе активно продвигается RISC-V, но никто не плачет о новой несовместимой архитектуре — все дружно берут и переносят своё ПО. Но почему-то как только речь заходит про архитектуру Эльбрус, сразу начинаются стоны о том что своё — это плохо и сложно. Тут, как вы поняли, эталонное «это другое».
А теперь посмотрим на факты. Сейчас для Эльбруса существует несколько дистрибутивов GNU/Linux, для примера рассмотрим АльтЛинукс. На текущий момент в нём портировано более 14500 пакетов. При этом исправлений, по заявлению разработчиков, потребовало около 1% пакетов от общего количества. Это не считая многочисленных статей даже на хабре о переносе проектов под Эльбрус (легко ищется прямо на сайте). По отзывам в случаях отсутствия архитектурно-зависимого (т. е. ассемблерного) кода, перенос на платформу совершается гладко благодаря хорошей совместимости эльбрусовского компилятора с gcc. Таким образом, заявление об излишней (!) сложности выглядят сомнительно при взгляде на цифры.
А теперь вспомним что существует ПО без исходного кода, которое способно запускаться только на x86 машинах. Процессоры Эльбрус такое ПО запускать умеют. Могут ли другие не-x86 процессоры процессоры похвастаться этим же? Просто удивительно как автор смог преподнести настолько уникальную возможность (над которой он сам работал) как недостаток. Аплодирую стоя.
VLIW-архитектура
Сначала приведу разбор узких технических моментов, потом пройдёмся по более общим высказываниям.
Пришедший указатель или сложная работа с памятью — и вы не можете спланировать Load выше операции Store (и наоборот).
В области разработки компиляторов существует целое направление, занимающееся решением именно этой проблемы — анализ указателей (на самом деле это два направления, но не будем лезть в подробности), которое «разрывает зависимости» между операциями. Наличие операций Load/Store — не приговор, необходимо анализировать код. Всегда ли возможно разорвать зависимость? Конечно же нет, более того это довольно сложно. Получается ли разрывать зависимости на практике? Да, получается, много где. Более того, в Эльбрусе разрыв зависимостей возможен не только во время компиляции, но и во время исполнения. Одним из таких механизмов является DAM, позволяющий аппаратно разрывать зависимости, которые не смог порвать компилятор.
Если в горячем цикле есть вызов функции — его надо обязательно заинлайнить, иначе мимо него нельзя будет ничего поднять вверх и тем более применить критически важную оптимизацию конвейеризации цикла. Но при компиляции без профиля установить какие циклы горячие невозможно
И снова неверное утверждение. Точнее, верное только от части. Подстановка вызовов (inline) действительно является одной из важнейших оптимизаций, и не только для VLIW архитектур, а вообще для всех. Только вот компилятор вполне способен определить горячие участки с неплохой вероятностью, и в дальнейшем их оптимизировать. Такой механизм называется «предсказание профиля», он работает на основе анализа кода и определённого количества эвристик. Этот механизм есть и в других компиляторах, но полагаю что в компиляторе эльбруса он развит лучше ввиду его необходимости. Кстати, даже если процедуру не удалось подставить, не обязательно что её нельзя «поднять вверх». В компиляторе существует оптимизация выявления функций без побочных эффектов, которая даёт определённую свободу действий.
Но это стоит транзисторов, перформанса и всё равно имеет много ограничений для применения в реальности. … И хотя это стоит определённых транзисторов и мощности, на выходе такой подход оказывается более эффективным
Там транзисторы — плохо, тут хорошо. Ну вы поняли.
Кстати, про профиль следует понимать ещё одну любопытную вещь. Последние лет пять (даже больше) в основных компиляторах (gcc, llvm) очень активно ведётся разработка использования профиля для улучшения оптимизаций — PGO (Profile Guided Optimizations). И это делается именно для RISC/CISC + OoO + Branch Prediction процессоров. Т.е. почему-то разработчики считают что «их замечательные транзисторы» недостаточно замечательные, и им нужна помощь в виде поддержки компилятора, двухпроходной компиляции и всех прочих прелестей этого замечательного режима. Так что возможно заявления о том что всё решается транзисторами не такие уж и верные.
Архитектура Эльбрус крайне плохо исполняет код, если в нём появляются не заинлайненные вызовы функций. В таком случае производительность может падать на порядок
Это действительно так. Только вот автор приводит полностью синтетический пример, который в реальности попросту не встречается. На практике проблемы с подстановкой функций будут встречаться если вызываемая в горячем коде функция располагается в другом модуле, и компилятор не видит её тело. Что ж, я за такой код бил бы линейкой по пальцам независимо от целевой платформы.
Ну и снова стоит напомнить что эта проблема свойственна не только для VLIW архитектур (хотя в этом случае плохой код даёт бОльшие штрафы), но и вообще всем. Поэтому в компиляторах активно разрабатывается технология межмодульных оптимизаций LTO (Link Time Optimization), направленная на решение именно этой проблемы. Кстати, по умолчанию Rust компилируется как раз с включённым lto.
Если в данном цикле вызов функции get_int_val по какой-то причине не заинлайнится компилятором, то для RISC/CISC архитектуры с OoO итерация цикла будет занимать ~1 такт, не отличаясь принципиально от случая, если инлайн сработал
Тут снова фактическая ошибка, на которую автору указали в комментариях. Более того он сам сказал что не получал такого результата, и это его предположение. Т.е. приводя сравнение автор просто взял цифру с потолка. Кстати, эти три такта, которые он получил тоже будут только в хороших случаях, в общем случае нам понадобится не менее 4 тактов.
Но минимальное усложнение кода, например, путем добавления бОльшего числа команд в функцию, легко сломает логику работы инлайна в реальной жизни
Даже не знаю что тут сказать. Очень хотелось бы таких примеров из реальной жизни, а не из синтетического примера (хотя и тут не представляю что для этого нужно сделать). Могу только сказать что подстановка функций — одна из самых важных и сложных оптимизаций в компиляторе. Она постоянно дорабатывается, в ней исправляются ошибки, улучшаются эвристики. Я даже знаю как сделать «плохие» примеры для конкретной версии компилятора, только вот в реальной жизни как раз всё обычно весьма неплохо.
Как видно, VLIW-процессоры на тех же нанометрах, имеют меньшие тактовые частоты, при этом имеют более высокое тепловыделение и больше транзисторов
Не знаю на кого рассчитана эта фраза с учётом того что в той таблице нет других процессоров с теми же нанометрами (только Эльбрус другой линейки). И нет, из этой таблицы нельзя сделать вообще никаких выводов — чистая манипуляция.
В итоге VLIW процессоры проигрывают не только по микроархитектурной скорости в пересчёте на Герцы …
Добрый день, а это то откуда следует? Ни одной цифры для подобных выводов вообще не приведено в статье.
Кстати, напомню что статья была посвящена отечественным процессорам. А теперь попробуйте найти хоть одно сравнение с ними. Т.е. автор заявляет одну тему статьи, в теле приводятся несравнимые, местами неверные и выдуманные данные, делаются далекоидущие выводы. Ладно, от мелких узкотехнических ошибок пойдём к более глобальным и весёлым.
Потому что если на небольших бенчмарках или тем более Spec2006/2017 (которые вылизывали 20+ лет) компилятор худо-бедно справляется и может сгенерировать близкий к оптимальному код, то на реальных проектах он уже не справляется, а т.к. аппаратура тут подстраховать не может, то производительность падает в разы
Ну что ж, давайте посмотрим реальные проекты. Вот из свеженького: «По результатам тестов можно сделать вывод о том, что процессор «Эльбрус-8СВ» успешно решает задачу построения системы хранения данных и позволяет получать достойные результаты на HDD». Или даже на хабре: «Так что по абсолютной скорости Эльбрус достаточно близок к современным процессорам Intel (это при значительной разнице в тактовой частоте!) и превосходит x86–64 с AVX в тактах более чем в 1.5 раза (для 3 и 4 поколения), а x86–64 с AVX2 — в 1.3 раза (для 5 поколения)», «В отличие от Магмы, можно говорить о сопоставимой абсолютной скорости и преимуществе в тактах более чем в 2 раза», и ещё несколько интересных сравнений прямо в статье. Можно приводить примеры и дальше, но в целом это высказывание выглядит особенно забавно на фоне оттачиваемого десятилетиями ПО под x86.
Дело в том, что VLIW-архитектура принципиально уступает по производительности современным RISC/CISC процессорам с Out-of-Order (OoO) исполнением
Вообще, когда говорят о производительности ВК (вычислительных комплексов), существуют общепризнанные тесты, на результаты которых принято ссылаться. Например, ни один профессионал не сошлётся на результатов теста drystone или whetstone — его просто насмех поднимут. Если мы говорим про производительность на широком круге задач, то не существует набора тестов лучше чем SPEC CPU2017 или его более старой версии 2006 года. Эти тесты представляют из себя подборку популярных приложений, например bzip2, perl, blender и т. п.
Т.к. мы говорим про отечественное процессоростроение, то сейчас единственным сумевшим приблизиться к Эльбрусам процессором является Байкал M1000. С ним и будем сравнивать.
Все сравниваемые процессоры имеют по 8 ядер, выполнены по топологии 28 нм. Запуск производился на одном процессоре в режиме 8 потоков (т.е. измеряется скорость работы 8 параллельно запущенных задач). Результат измеряется в спековских «попугаях», чем выше значение — тем выше производительность.
Частота, МГц | Архитектура | SPEC CPU 2006 | SPEC CPU 2017 | Выпущен | |||
Байкал M1000 | 1500 | armv8 | 56.70 | 55.7 | 7.92 | 8.01 | 2019 |
Эльбрус 8С | 1300 | e2kv4 | 80.07 | 92.98 | 9.60 | 13.38 | 2016 |
Эльбрус 8СВ | 1500 | e2kv5 | 102.55 | 122.25 | 10.68 | 16.55 | 2018 |
Из результатов следует что Эльбрус 2016 года выпуска с частотой 1300 МГц работает быстрее Байкала 2019 года выпуска с частотой 1500 МГц. На текущий момент Эльбрусы с большим запасом являются самыми быстрыми российскими процессорами (на сколько термин «российский» вообще применим к Байкалам).
Кстати, именно с этой проблемой связана достаточно странная политика МЦСТ, когда получить Эльбрус можно только написав официальный запрос на имя генерального директора
И как же так получилось что у энтузиастов поднят godbolt сервер с компилятором, в музее Яндекса стоит машина со свободным доступом к ней, а получить удалённый доступ можно практически свободно, зайдя в эльбрусовский чатик? Я уже не говорю про такие шедевры как любительский ютуб канал с запуском игр на Эльбрусах.
Теперь ещё одна веселящая меня штука: «Ведь казалось бы, если вы хотите продавать свои процессоры, надо их максимально пиарить и первые партии раздавать чуть ли не бесплатно». А вот в комментах какой-то другой прибежавший на помощь эльбрусофб утверждает: «На фоне этого разнообразия Эльбрус выделяется исключительно агрессивным маркетингом, а не какими-то выдающимися ноу-хау». Выбирай что больше нравится @ кидай предъяву.
А тут такие бюрократические препоны. Дело в том, что руководство МЦСТ в общем-то прекрасно понимает недостатки Эльбруса и максимально пытается избежать негативной огласки
Не то чтобы я считал что для компании не стоит пытаться избежать негативной огласки, но опять же это неправда. Например, тесты, на которые автор ссылался в своей статье являются негативными для Эльбруса т. к. Эльбрус в них показывает себя крайне плохо. Но при этом сделаны тесты были на предоставленной без каких-либо условий машине (более того, у автора был исключительный доступ к инженерным образцам последних моделей). Ну и в целом всё на что я тут ссылался ранее (а также тонны других статей на хабре с замерами Эльбрусов) сделаны без какого-либо цензурирования со стороны МЦСТ. Утверждение автора справедливо к ситуации разве что пятилетней давности, примерно в то время он и ушёл из МЦСТ.
А тут надо будет не только разобраться в коде, но ещё и понять, а что же компилятор «сделал не так» и что исправить в коде, чтобы решить проблему
Я бы мог много написать про то что программистам неплохо бы разбираться в компьютерах, но пожалуй остановлюсь на том что автор не в курсе вектора разработок МЦСТ и одно из направлений — это как раз отчёт о применении оптимизаций для помощи пользователю.
Резюмируя — процессорная платформа, которая претендует стать массовой и конкуретной на рынке десктопных и серверных процессоров, не может быть VLIW архитектурой, т.к. это заведомо проигрышный путь
Думаю что на основе всего выше сказанного я поставлю под сомнение это утверждение.
Именно поэтому, при всей уникальности линейки процессоров Эльбрус, они не могут служить базовой платформой для массового производства отечественной вычислительной техники
Ещё раз обращу внимание на эту хитрую манипуляцию: автор не привёл ни одного сравнения с российскими процессорами. Более того, даже с импортными процессорами сколько-нибудь адекватные сравнения отсутствуют. Собственно, вся статья строится на голословных утверждениях, ошибках и полёте фантазии автора.
Резюмируя — в данной статье я указал на большое количество ошибок и манипуляций в разговоре про Эльбрусы. Более того, я опубликовал результаты замеров SPEC CPU2006/2017 двух ведущих российских разработчиков, из которых видно что Эльбрус имеет неоспоримое преимущество. Возможно, через какое-то время Байкал и сможет составить ему конкуренцию, но объективные данные говорят что сейчас Эльбрус является самым быстрым российским процессором и вполне заслуженно выступает в качестве лидера и перспективы отечественного процессоростроения.
