В чем принципиальные особенности процессора российской разработки Эльбрус? О ней в последнее время много говорят: как хвалят, так и ругают. Но давайте углубимся в архитектуру процессора, чтобы все-таки понять в чем его плюсы и минусы.
Расскажу, что такое скрытый и явный параллелизм, как используются предикаты и осуществляется подготовка переходов. Почему Эльбрусу не нужны push и pop команды и в чем особенности его регистрового окна. Какая защита от атак есть у российского процессора и какие возможности дает защищенный режим.
Данная статья — транскрипт моего выступления на конференции HighLoad++.
Что такое Эльбрус
Эльбрус не является клоном какого-либо процессора. Это абсолютно российская, даже еще советская разработка. Эльбрус умеет исполнять код x86, но делает это не аппаратно, а путем бинарной трансляции. Современные версии довольно производительны. Например, Эльбрус-16С — это 16 ядер, 2 ГГц, 750 Гфлоп/с, 16 нм. И 2 ГГц Эльбруса — это не 2 ГГц того же самого Интела, потому что Эльбрус умеет запускать на один такт до 50 инструкций. Конечно, компилятор должен суметь сгенерировать такой код, но технически это возможно.
Эльбрус серийно производится с 2014 года. Имеет поддержку МСВС, ALT Linux, Astra Linux. Есть версия QNX, российские ОСРВ и Postgres. На него вообще перенесено довольно много кода.
Эльбрус — довольно специфичный вид процессоров. Он непохож на то, к чему все привыкли. В нем есть все те же базовые инструкции: сложение, вычитание, умножение, условные и безусловные переходы, но у него теговая архитектура. Процессор тегирует данные в памяти таким образом, что знает тип объектов. Когда обычный процессор обращается в памяти к какому-то значению, он просто считывает битовую строку и трактует ее как float, или int, или pointer. Эльбрус же точно знает, что лежит в данной ячейке памяти.
Закон Мура
Есть закон Мура: каждые два года количество транзисторов на одном кристалле в среднем удваивается. Появился он давно, но работает до сих пор.
До 1995 года это было абсолютной синекурой для программистов: удвоение давало прямой прирост производительности единственного ядра процессора, и программы без приложения усилий со стороны программиста работали быстрее. Заменили 8086 на 286 — все ускорилось, 386 — еще быстрее, 486 — еще быстрее, Пентиум — программы просто летали. Но дальше начались проблемы. Прирост производительности отдельного ядра замедлился, и развитие процессоров пошло в сторону параллелизма. Ускорение начали делать за счет увеличения числа ядер, и программисты больше не могли просто запускать программы на более быстром процессоре, их пришлось распараллеливать. Тогда и появились процессоры со встроенным распараллеливанием исполнения кода.
Скрытый параллелизм
В 1995 году у Интел возникла проблема с тем, что программы завязаны на набор команд, но в архитектуре x86 мало регистров. Например, мы написали часть кода, который использует все 8 регистров, но следующая часть кода тоже их использует. Если за счет мощности процессора попытаться исполнить две части кода параллельно, они все равно упрутся в одни и те же регистры.
Чтобы решить проблему Интел начал разбивать сложные инструкции на простые, которым назначалось больше регистров, чем видно с точки зрения программиста. Когда два таких набора инструкций обращались к одному и тому же регистру, использовали его — загружали, считали и записали в память — они распараллеливались. Им выдавались две отдельные копии виртуального регистра AX.
На схеме слева показано, как устроена инструкция Интел, справа — как это сделано в RISC процессоре, который такую инструкцию исполняет. В Интел инструкция сама может сходить в память, считать значения, сделать вычисления и сохранить данные в память. В процессорах RISC инструкции фиксированного размера: либо инструкция читает из памяти, либо она выполняет регистровую операцию. Поэтому одна инструкция Интел на RISC-машинах разбивалась на серию простых инструкций.
Это до сих пор позволяет ускорять программы не сильно нагружая программистов, за счет выявления процессором в коде скрытого параллелизма и реализации его в виде реального параллельного запуска участков кода. Но такой подход сильно усложняет процессор. Ему приходится много анализировать и внутри него возникает много дополнительных действий, связанных с разбором инструкций, исполнением микроинструкций и выяснением где они заканчиваются.
Явный параллелизм
Конечно, полностью снять с программиста задачу распараллеливания, не получилось. Под многоядерные процессоры все равно нужно писать мультритредные программы и искать способы прогрузки всех аппаратных средств. Поэтому компиляторы внутри процессора и код прикладной программы сложны и требуют от программиста ручного распараллеливания алгоритмов. Хотя в пределах ядра модель CISC/RISC преобразования на x86/x64 процессорах до сих пор работает.
VLIW: ручной параллелизм
При разработке Э2К был принят кардинально другой подход. Чтобы процессор не распараллеливал изначально линейный код, эту работу полностью перенесли на компилятор. Он и так знает о программе больше, чем процессор. Может анализировать крупные участки кода, вплоть до всей программы, и принимать решения об оптимизации на более высоком уровне. Поэтому Эльбрус не пытается разбираться, где и что можно параллельно исполнять в коде, а оставляет это компилятору. Компилятор генерирует большую сложную инструкцию и подробно объясняет процессору, какие именно исполняющие устройства в данной инструкции должны делать.
Обычному интеловскому компилятору надо знать, что происходит в процессоре и подавать код так, чтобы процессору было легче его распараллеливать. А в процессорах с длинным командным словом (таких как Эльбрус и, кстати, Интел Itanium) — это полностью происходит на стороне компилятора. Процессор упрощается и существенное количество его аппаратуры можно потратить на исполнение, исполняющие устройства и кэш.
На борту Эльбруса
У каждого ядра процессора Эльбрус шесть АЛУ (арифметико-логических устройств), которые работают параллельно и могут исполнять шесть полноценных параллельных инструкций: вычисления, доступ к памяти, и все, что считается инструкцией. В очень широкой команде Эльбруса у каждого АЛУ свой фрагмент — слог, где точно определено, что надо делать. Например: складывать, вычитать, делить, записывать в память.
Кроме слогов для шести АЛУ широкая команда может содержать:
одну субинструкцию для юнита, которая управляет переходами
3 вычисления на предикатах и 6 квалифицирующих предикатов
4 инструкции для асинхронного чтения данных в цикле
4 литерала в 32 бита, которые идут в исполнение как константы
Интересное решение заложено в предикатах.
Предикаты
У процессора Эльбрус есть отдельный регистр, который называется регистром предикатов. Один бит в этом регистре (на самом деле там два бита) — это булево значение, которое можно использовать для условного исполнения инструкций. Когда вы запускаете на исполнение огромную инструкцию, то 6 субинструкций для каждого АЛУ можно завязать на предикаты. Это позволяет экономить на jmp потому, что некоторые простые условные операции можно закодировать в одной инструкции таким образом, что первая половина IF выполняется, если предикат 1, а вторая, если он 0. Мы сразу кладем в команду оба варианта кода для IF и для ELSE, и проверяем по определенному биту, какую из них исполнять.
Еще есть субинструкции для самих предикатов, которые позволяют посчитать их перед исполнением команды. В регистре предикатов можно связать биты по И, ИЛИ, получить ответ, и по этому ответу условно использовать команду или оставить ответ в регистре предикатов. Это как бы большой флаговый регистр, в котором можно сохранять большое количество булевых значений.
Еще большое количество булевых вычислений, которые относятся, как правило, к control-flow, можно исполнять параллельно с основным кодом программы.
Все современные процессоры это пайплайновые устройства. Каждая команда исполняется в процессоре много тактов — 5, 7 до 19. Из-за того, что в каждом такте команды исполняются по очереди: от первой инструкции первый шаг, от второй второй, от третьей третий и т.д., они расположены ступенью.
В первой инструкции мы только считываем инструкцию из памяти, на втором такте для следующей инструкции считываем ее из памяти, а для предыдущей декодируем ее, и т.д. Так мы движемся по цепочке и процессор каждую инструкцию исполняет, скажем, 10 тактов. Но за счет того, что в каждом такте исполняется очередной этап десяти инструкций, в сумме процессор выполняет одну инструкцию за такт.
Так устроены все современные процессоры. Команда перехода (jmp) сбивает работу конвейера и обходятся процессору как десяток других команд. Она вынуждает процессор доработать все висящие в пайплайне инструкции: полностью закончить исполнение, сделать переход и потом снова начать наполнять пайплайн с нуля в новом месте. Из-за этого теряется огромное количество процессорного времени. Один jmp по стоимости может достигать 10-20 инструкций. Это огромная проблема для компиляторов, поэтому и компиляторы, и процессоры максимально оптимизируют код, избегая команд перехода.
Эльбрус может избежать этой проблемы не только с помощью предикатов, но и за счёт по другому устроенной команды переходов.
Подготовка переходов
В обычном процессоре есть две традиционные команды. Jmp, по которой процессор переходит на новый адрес инструкции и исполняет код с нового места. И условный jmp, который проверяет условие (в Эльбрусе это, как правило, предикат) и делает переход, если условие исполнилось.
В Эльбрусе условный и безусловный переход, вызов подпрограммы и возврат из подпрограммы можно разделить на две части. Сначала мы готовим переход и специальной инструкцией сообщаем процессору, что планируем перейти по такому-то адресу и сообщаем, как вычислить адрес перехода. Аппаратура Эльбруса параллельно с исполнением других конструкций выполняет это вычисление. Она может сходить в память, прочитать этот адрес и подготовиться к исполнению перехода.
Затем исполняется инструкция собственно перехода.
Если между подготовкой и исполнением перехода процессор успел выполнить другие задачи, переход оказывается «бесплатным». Потому что процессор параллельно подготовился, выяснил адрес перехода и подготовил к этому свою аппаратуру, и никакого сбоя пайплайна не происходит.
Процессор позволяет подготовить до 3 переходов одновременно. У него есть три специальных регистра, которые используются для подготовки jmp. Например, мы не знаем по какому адресу будем переходить, у нас типичный код IF (может быть, перейдем по нему, может, нет), но заранее знаем куда будем переходить потому, что адрес константный. Два из трех регистров обычно используется для подготовки переходов внутри кода функции, а третий умеет вызывать функции и возвращаться из них.
Еще в Эльбрусе необычно сделано регистровое окно.
Регистровое окно
В обычном процессоре есть 10-20-40 регистров. Он пишет в регистры промежуточные значения и читает из них. Обычно при вызове функций в регистрах сохраняются аргументы и возвратные значения. На Интеле и АРМе обычная функция устроена так. Перед ее вызовом команда push сохраняет в память регистров значения, которые понадобятся после возврата. Вызывается функция, что-то делает с этими регистрами, возможно затирает. Потом важные регистры поднимаются командой pop из стека и работа продолжается.
В Эльбрусе команды push и pop не используются. Процессор содержит пул из 256 84-разрядных регистров. Не все они видны программе: каждая функция «заказывает» у процессора нужное количество и процессор выделяет ей часть пула, в которой она будет жить.
Видимая подпрограмме группа регистров (окно в регистровый файл) делится на три последовательные части:
Общие регистры для нас и для вызвавшей нас функции, в которых находятся переданные нам параметры.
Регистры, в которых мы просто работаем, они видны только нашей функции.
Регистры, в которых мы будем передавать параметры вызываемой функции. Они готовятся перед вызовом.
Когда мы вызываем функцию, окно сдвигается вверх так, что параметры для следующей функции становятся нижней частью окна регистров. Дальше образуется следующая ее личная часть и те регистры, которые функция будет использовать для вызова уже своих функций:
В момент вызова функции регистровый файл виртуально сдвигается вниз — первая и вторая группы уходят ниже и не видны вызванной функции. Третья группа становится первой, а новые вторую и третью группы вызванная функция заказывает себе у процессора специальной командой.
Стек регистров
Для большей части кода все происходит без обращений к памяти. На глубину 10-20 вызовов хватает пула из 256 регистров. Если процессору хватило физических регистров для обеспечения вызывающей и вызываемой функции, то обращений к памяти не происходит. Если регистровый файл кончается, процессор прозрачно для прикладного и системного кода сохраняет в стек части регистрового файла. Если функция запрашивает регистры, а свободных в файле нет, то процессор прозрачно для программы сохраняет «нижнюю» часть регистрового файла в стеке одной крупной операции записи. Что куда более эффективно, чем обслуживание мелких push/pop инструкций в традиционных архитектурах. Естественно, что по мере возвратов из функций процессор так же прозрачно для кода возвращает регистры из стека.
Регистровое окно содержит отдельную часть, которая не передвигается, а является глобальной. Она видна всем функциям и может использоваться как обычные регистры в обычном процессоре. Либо как временный регистр, и мы понимаем, что в момент вызова функции он будет затираться вызванной функцией, поэтому длительно ничего в нем не храним. Либо, наоборот, как глобальный регистр, например, регистр для хранения ссылок на глобальные данные или position-independent code регистр, который используется компиляторами для глобальных таблиц с нужными данными.
Подкачка данных для цикла
Быстродействие современных процессоров в огромной мере упирается в обмен с памятью. Доступ в ОЗУ в сотни раз медленнее, чем операции внутри самого процессора, особенно с ожиданием результатов. Запись выполняется отдельными записывающими юнитами. Неважно когда они произведут запись, работу это не останавливает. А вот считывание останавливает. Например, вы обсчитываете видео или звук: считываете значения из буфера, посэмплово их обрабатываете и записываете. Если вы закодируете эту операцию обычным циклом (часть кода, jmp на начало, снова та же часть кода, который исполняется в цикле), то на каждой итерации будет обращение к памяти, на котором процессор зависнет, пока не получит данные из памяти. Поэтому разработчики архитектуры стараются сделать так, чтобы мы узнали о потребности считывания из памяти как можно раньше, желательно до того, как оно стало критичным. Практически во всех современных процессорах есть инструкция, которая готовит данные для использования, и старается заранее сохранить их в кэш, чтобы мгновенно получить при считывании.
У Эльбруса есть отдельно параллельно работающий юнит аппаратной подкачки данных. Внутри цикла вы пишете не инструкцию считывания из памяти, а инструкцию выборки данных из FIFO. До начала цикла запускаете аппаратную подкачку, которой сообщаете, из какого места в памяти идти и как считывать значения. Она опережает цикл, выдергивает из памяти значения, которые нужны циклу и кладет в FIFO, а цикл параллельно забирает считанные значения оттуда. Если все сделано правильно, то считывание из памяти идет параллельно с работой процессора со скоростью, которая практически не задерживает исполнение цикла.
Эльбрус поддерживает схему исполнения циклов, которая запускает следующие итерации цикла на исполнение в процессоре до того, как закончились предыдущие. В традиционном процессоре, jmp не позволит исполнять следующую итерацию до окончания предыдущей, поэтому код будет исполняться строго до последней инструкции. В Эльбрусе внутри регистрового окна может быть выделено подокно, и коду цикла указывается не конкретный регистр, а подокно. Процессор аппаратно для каждой следующей итерации цикла выдает следующий регистр из этого подокна. Это позволяет логически написать обращение к одному и тому же регистру для 10 идущих подряд итераций цикла в коде, а физически каждая следующая итерация получает следующий отдельный регистр. Таким образом итерации работают с той степенью параллельности, которую допускает аппаратура процессора.
Эти подходы позволяют ускорить выполнение циклов и снизить зависимость от обращений к оперативной памяти.
Несколько стеков
Эльбрус поддерживает несколько параллельных стеков. В частности, есть стек вызовов, который полностью поддерживается аппаратно. Из-за того, что на него не сохраняются данные из регистрового файла и пользовательские данные, он может быть организован в отдельной части памяти. Инструкция вызова функции сохраняет на этом стеке информацию о текущем состоянии и все, что нужно для возврата в предыдущую функцию. Поэтому пересечение в стеке между адресами возврата и данными пользователя невозможно. Они находятся в двух разных стеках. Это защищает от типичного для Интела метода атаки на код на C, когда в переменную (обычно строковую, которая лежит на стеке) записывается больше, чем размер этой переменной. Старые функции типа strcpy такое позволяли. Если строка длиннее, чем буфер, в который ее копируют и буфер находится на стеке, то буфер перезаписывается. Данные в нем затираются, а вместо адресов возврата вписывается специальный адрес, и при выполнении возврата из функции, функция возвращается не туда, куда должна, а к вирусному коду. Перехват управления через переполнение буфера — типовая проблема, которая встречается до сих пор.
В Эльбрус это невозможно из-за того, что стеки находятся в разных местах. Но помимо этой особенности, у российской разработки есть и другие способы защиты кода.
Защищенный режим
Эльбрус устроен сложнее традиционных процессоров, поэтому большинство вирусов в нем не работают. Сохранение регистра происходит аппаратно и не доступно для прикладного кода, но для максимальной защиты, можно использовать защищенный режим, который заключается в тегировании данных в памяти процессора. С каждым значением в памяти лежат биты тегов, которые говорят — это число, а это указатель. Процессор знает, что именно он считывает из памяти. В защищенном режиме запрещено преобразование целых чисел и вообще чего бы то ни было в указатели. Поэтому получить указатель можно только из другого указателя. При этом первый указатель порождается в специальном режиме. Мало того, в защищённом режиме указатель не просто адрес в памяти, а 128 битная структура с тремя полями: базовый адрес (64 бита), размер окна и текущее положение в этом окне.
Чтобы получить обычный указатель, который смотрит на одно число в памяти, окно уменьшается до 4-8 байт. Раздвинутый указатель может смотреть уже на массив или структуру. Когда у указателя размер больше 8 байт, к нему можно применять адресную арифметику внутри поля. Если нам передали пойнтер на массив, то он указывает на начало массива, в размере указан размер массива, и он смотрит в опорную точку массива. От нее можно двигаться адресной арифметикой вверх и вниз, делать внутри этого массива все, что угодно, но выйти за его пределы нельзя. Адресная арифметика допустима в пределах [база, база+размер]. Этим же диапазоном ограничены указатели, которые можно породить из данного указателя.
Эффект от такого ограничения проще всего описать, как защищенность уровня Java или C#, то есть среды с managed указателями. Нельзя просканировать память! Можно обратиться только в ту часть памяти, к которой выдан указатель.
К сожалению, этим свойством Эльбруса мало пользуются из-за низкой совместимости существующего кода на Си с механизмами защиты. К примеру, недопустимо использование одного и того же поля структуры для хранения целого числа и указателя попеременно.. На сегодня сделать ядро Linux для защищенного режима пока не удалось.
На данный момент, защищенный режим можно использовать, например, как инструмент тестирования кода. Защищенный режим — это такой аппаратный valgrind с абсолютной скоростью исполнения на уровне скорости процессора, который всегда проверяет все ваши указатели. Можно не использовать его в продакшен-коде, но во время тестирования это помогает.
Но давайте вернемся к вопросу об исполнении кода x86.
Исполнение кода x86
Процессор Эльбрус не умеет исполнять Интеловский код аппаратно, но для него реализована программная бинарная трансляция кода x86 в код Э2К. Трансляция выполняется прозрачно для исполняемого кода и позволяет запускать на Э2К операционные системы для Интеловских процессоров.
Бинарная трансляция частично поддержана аппаратно — процессор содержит элементы аппаратуры архитектуры x86, которые слишком дорого эмулировать программно: например, сегментная адресация и набор сегментных регистров. Адресные вычисления при работе с сегментными регистрами процессор делает аппаратно, а все остальное программно.
Бинарный транслятор
Бинарный транслятор сделан в виде набора из трёх трансляторов и состоит из трех уровней кодогенерации:
Шаблонный, который реализует пошаговую трансляцию: берет одну инструкцию Интела, синтезирует для нее соответствующий набор инструкций Эльбруса и исполняет. Это эффективно только для кода, который исполняется один раз.
Быстрый регионный, который берет уже не одну инструкцию, а линейный фрагмент и компилирует его, учитывая взаимосвязи между инструкциями. В скомпилированный код вставляются точки замера, которые показывают часто или редко исполняется код. Для часто исполняемого кода запускается третий уровень кодогенерации.
Оптимизирующий уровень работает медленно и применяется для перекомпиляции горячих участков кода. Это тяжелый оптимизирующий компилятор, который выжимает из бинарной трансляции все, что возможно, и синтезирует эффективный код. По быстродействию он мало уступает прямому исполнению на родном Интеле.
Исполнение кода x86 было необходимо 10 лет назад, когда Эльбрус только появился и для него не было родных операционных систем. Сейчас запуск на Э2К операционных систем, скомпилированных под x86 не такактуален, в отличие от режима, который запускает скомпилированные под x86 Linux приложения на ядре Linux под Эльбрус.
В штатной скомпилированной под Эл/ьбрус ОС Linux возможен запуск бинарной трансляции для прикладного кода. Это позволяет запускать под Эльбрусом приложения или библиотеки, скомпилированные под x86.
Итоги
Я описал только верхний уровень. У Эльбруса ещё три этажа тонкостей и деталей, не все из которых надо знать прикладному программисту. С моей точки зрения, а я знаю довольно много процессоров и то как они устроены, Эльбрус — это инженерное чудо. Он в некотором смысле проще, чем Интеловские процессоры, но он не простой. С ним надо уметь жить. Практика показывает, что для оптимизации вычислительного кода надо приложить усилия, чтобы выкачать из Эльбруса всю его производительность. Но по этому поводу есть много статей и руководство от разработчиков для программиста на С, есть готовые библиотеки, которые уже оптимизированы под Эльбрус и большой опыт перенесения кода.
HighLoad++ 2021 пройдет 17 и 18 марта 2022 года в Крокус-Экспо. Доклады уже сформированы, но из-за короновируса придется немного подождать. Билеты купить можно здесь.
Комментарии (163)
LuggerMan
21.10.2021 11:53+8Как купить, если ты просто чел, который хочет поиграться? Стоимость? Куда воткнуть это чудо можно?
rstepanov
21.10.2021 12:01+4LuggerMan
21.10.2021 14:38+4Ого! Даже более-менее прилично стоит, примерно как три блока с Intel Core i9-11900KF и матерью формата StandardATX при DDR4 гига так на 64 за одну машину на Эльбрусе. Ожидал совсем космических значений
rstepanov
21.10.2021 14:41+3Покупайте, потом расскажете зачем купили :)
LuggerMan
21.10.2021 14:46+2Не расскажу xD
rstepanov
21.10.2021 14:48+2Что, в комплекте с платой идет форма допуска к гостайне и вы уже все подписали?
LuggerMan
21.10.2021 14:50Пока думалка не доходит до реальных применений в гражданском секторе =)
А другие идут, увы, в комплектеrstepanov
21.10.2021 14:55+6Брелок, подставка под фикус...
LuggerMan
21.10.2021 15:01+5Можно еще в рамочку вставить и при входе подвесить, аки произведение искусства. Лет через 50 коллекционеры передерутся =)
А если по серьезке чутка — да, мощность не оч, какой бы там потенциал не был. Цена как крыло от самолета.
Но IDE есть? есть. Наше? наше. Может не лучшее, но там и не интел с амд бабло вбухивал десятилетиями. Куда-то в системы класса 1 вполне подойдет, своя ниша с МСВС и Астрой будет, лет через пяток может и дойдут до чего-то совсем красивого. Почему бы и не задонить?rstepanov
21.10.2021 16:45+7Почему бы и не задонить?
Потому что документацию и исходники вы все равно в полном объеме не получите, как раз из-за военных применений, а что получите - скорее всего под NDA.И довольно быстро вы обнаружите, что тащить этот воз без документации и с непонятно какого качества поддержкой (скорее всего с никакой) как то сложно. И отправится комп как раз туда, куда я написал, - работать дорогой подставкой под фикус.
amartology
21.10.2021 18:26+1как раз из-за военных применений
да нет у E2K никаких военных применений, вы о чем вообще?
rstepanov
21.10.2021 21:46+3да нет у E2K никаких военных применений, вы о чем вообще?
Э, а зачем он тогда вообще нужен?
amartology
21.10.2021 23:40+2Честно говоря, никогда этого не понимал. Но в оборонке и аэрокосмической отрасли в ходу совершенно другие процессоры.
speaktr
21.10.2021 23:29+3Атомогозовонефтеконторы уже вовсю тестируют железки на Э для внедрения куда им надо. Естественно это не пользовательский и даже не прикладной серверный сегмент, а конкретные специфичные вещи, завязанные на промбезопасность.
Oxyd
21.10.2021 22:03+1Ой, не напоминайте мне об МСВС, за сотни нефти. И о том как наши разрабы с ней мучались. Единственная мякотка там, это кнопочки «Есть!» и «Отставить!» в гуях. ;-)
LuggerMan
22.10.2021 11:11Напоминай не напоминай, а она есть и даже вертится кое-где, где в гуях кнопочки «есть!» и «отставить!» неиллюзорно радуют пользователей xD
andersong
22.10.2021 11:26+1Серьезно? А можно скриншот? Хотя, очень вероятно, функционал скриншота отключен аппаратно)
JerleShannara
22.10.2021 11:43На самом популярном торрент трекере в рф (том, у которого первым домен отжали) вроде как был дистрибутив оной штуки версии 3.0
qw1
22.10.2021 12:23Нашёл на трекере раздачу. На скринах там «Да» вместо «Есть». Гражданская версия?
img-fotki.yandex.ru/get/31082/114185435.e/0_12aec2_a2043c06_orig
Oxyd
21.10.2021 22:01+1Я-б лучше купил что-нибудь из рапторов. Всё таки иметь «маленький кусочек суперкомпьютера», из первой пятёрки TOP500, это... Ну вообщем интересно... Да и архитектура открытая. Кстати, кто напомнит, почему интел отказался от итаниум, который тоже VLIW?
Vitalley
22.10.2021 01:12+1Кстати, кто напомнит, почему интел отказался от итаниум, который тоже VLIW?Как чего, AMD все планы испортила с 64 битной архитектурой и Athlon'ами 64.
У Итаниума была плохая совместимость с x86 - код работал медленно, а ведь даже на AMD64 уже начали массово переходить только в десятых годах.
unv_unv
26.10.2021 19:25Кстати, суперкомпьютер строить на «Эльбрусе» — хорошая затея. Потому что программу для суперкомпьютера будут заведомо вылизывать, а благодаря архитектуре, на «Эльбрусах» при таком вылизывании можно потенциально задействовать все аппаратные возможности по максимуму, поскольку аппаратура практически полностью открыта для программиста.
EntityFX
21.10.2021 18:44+4Можно получить бесплатный ssh доступ к серверу на процессоре Эльбрус. Писать админам YouTube канала Elbrus PC Test: https://www.youtube.com/c/ElbrusPCTest
BiosUefi
21.10.2021 11:54Используется ли какой то аналог БИОСа или u-boot, для настройки аппаратной конфигурации, памяти, периферии и пр.? Возможно ли обновление микрокода ?
13werwolf13
21.10.2021 14:22да, правда оно cli и довольно скудное, но вас же как профессионала это не напугает. и да микрокод можно обновлять.
что плохо так это то что на данный момент на эльбрусе невозможно загрузиться с raid ни с программного ни с аппаратного..BiosUefi
21.10.2021 14:41Для raid необходимо как минимум иметь поддержку OpROM . Она и для остальных PCIE устройств не помешала бы. PXE boot, видеокарты и пр. Даже если и пришлось бы его (OpROM) переписывать под архитектуру Эльбруса.
JerleShannara
21.10.2021 17:17+1Там прошлое МЦСТ (… Центр Спарк...) играет, всё в духе OpenBoot-а спарковского было раньше. ОпРомы в любом случае надо переписывать для железа (сия грабля торчит и в Arm-ах, но там всё решается тем, что ARM сейчас начинает торчать из серверов и, чуется мне, в скором времени в uefi опромах будет и секция с кодом под aarch64) не x86.
BiosUefi
21.10.2021 22:33Да, рэйд и высоконагруженные сетевухи, так и просятся на на ARM сервера. Жаль эмбеддед World в Нюрнберге стал виртуальным, там можно было походить и поспрашать, у предлагающих железо в ARM сегменте.
Lirein
21.10.2021 20:44+3Да, на оба вопроса. Подробности у техподдержки МЦСТ после приобретения платы. Охотно идут на встречу, особенно разработчикам собственных программно-аппаратных комплексов.
Готовится возможность встраивания ядра Linux+initrd в микрокод загрузчика.BiosUefi
21.10.2021 22:38》встраивания ядра Linux+initrd в микрокод загрузчика.
Да, в эмбеддед сегменте достаточно востребованное решение. Под заказ.
JerleShannara
22.10.2021 04:30Кстати, а что там с поддержкой eMMC? Штука то очень хорошая, особенно её интеловская реализация с областями под саму фирмварь (сразу с дублированием), областью под ядро ОС, и пользовательской частью. При этом области фирмвари могут быть защищены.
Lirein
22.10.2021 04:45Я думаю лучше задать вопрос напрямую в поддержку МЦСТ (support@mcst.ru), должны ответить в течение дня, отвечают обычно быстро. Но скорее всего пока остаётся по прежнему — SPI NOR Flash, хотя они такого объёма бывают, что в него вся система влезть может и ещё место под пользовательские конфиги останется.
Mox
21.10.2021 12:07+4Проблема в том что достичь сопоставимых с конкурентами скоростей без рантаймового переопределения порядка не получается, в Эльбрус 32 они все таки вставят этот блок и уберут эту простоту
А пока получается что несмотря на весь потенциал Эльбрус сливает Core i7 сделанному на аналогичном техпроцессе (
OpenA
21.10.2021 15:04+4в Эльбрус 32 они все таки вставят этот блок и уберут эту простоту
Ничего подобного они не собираются городить. Рантайм оптимизациями будет заниматься компилятор, а процессор будет собирать и выдавать ему статистику. Эта фича заявлена уже для Эльбрус-16С
В Эльбрус-32С хотят добавить предсказатель переходов, но не такой предсказатель как у суперскаляров если коротко это будет предсказатель подготовленных переходов и 7 управляющих регистров (сейчас только 3).Надеюсь что они учтут так же подготовку предсказания вызовов, потому что текущая реализация не позволяет подготовить заранее два-три вызова и поочереди их дергать.
Armmaster
21.10.2021 16:40+4Ничего подобного они не собираются городить. Рантайм оптимизациями будет заниматься компилятор, а процессор будет собирать и выдавать ему статистику
То, что не будут ничего такого городить - это хорошо и правильно. Другой разговор, что никакие рантайм оптимизации фундаментально не решат проблему отсутствия аппаратного ОоО.
В Эльбрус-32С хотят добавить предсказатель переходов, но не такой предсказатель как у суперскаляров если коротко это будет предсказатель подготовленных переходов и 7 управляющих регистров (сейчас только 3)
Я надеюсь что сейчас вы выступаете в роли Рабиновича, наигрывающего Моцарта. Потому что звучит вышенаписанное как лютая хрень.
OpenA
22.10.2021 19:11+1Процессоры без ОоО существовали и работали раньше и существуют и работают до сих пор. Никакой такой фундаментальной необходимости в ОоО нет, это чисто приблуда для повышения однопоточной производительности на сегодня уже исчерпавшая свой потенциал, не только из-за того что производительность уже не растет, но и из за дыр которые оно в итоге имплементирует.
Не надо всем его толкать как панацею, его уже довели до совершенства лидеры рынка, нам их не догнать. Сейчас они еще тонны денег в ресерчь вольют, прикроют свои дыры и пропиарят так что от процессоров без этих затычек будут шарахаться как от прокаженных. Рантайм профилирование и взаимодействие с компилятором в динамике это очень интересное и перспективное направление, для рантайм-языков так точно. Предложить то чего у других нет - вот ключ к успеху, а лепить свою формулу-1 и тащить на гонку с определившимися фаворитами на черт знает каком кругу, даже если допустят, бесперспективно.
Я надеюсь что сейчас вы выступаете в роли Рабиновича, наигрывающего Моцарта. Потому что звучит вышенаписанное как лютая хрень.
Хорошо, приведу цитату:
Архитектура «Эльбрус» предполагает наличие
в программном коде команд разной длины, поэтому
выдача предсказания для подкачки кода необходима
до выполнения его декодирования и определения
размеров и типа команд. В архитектуре «Эльбрус»
введены два типа операций перехода — подготов-
ленные и непосредственные, причем количество
непосредственных переходов в коде очень неве-
лико, для них весьма редко реализуется условие
перехода, т. е. в основном они обречены на промах,
в данном случае неизвестен заранее адрес пере-
хода. С учетом этих факторов было принято реше-
ние при проектировании устройства не рассматри-
вать операции непосредственного перехода.То есть переходы по командам ibranch предсказываться не будут, что логично в виду наличия в системе команд кучу инструкций для вычисления адреса перехода, плюс ошибки предсказания проще проглатываются:
Интересно отметить, что отсутствие неупорядо-
ченного исполнения команд и раннее вычисление ус-
ловия перехода в микропроцессорах с архитектурой
«Эльбрус» позволяют упростить реализацию услов-
ной отмены команд — вся деятельность при ошибоч-
ном предсказании ограничена устройством управ-
ления и кэш-памятью команд, а в исполнительные
устройства попадают команды только из правильной
ветви перехода.Главное чтоб можно было делать:
{ disp %ctpr1, malloc } { disp %ctpr2, my_funct } ... { call %ctpr1, wbs = 0x4 } { call %ctpr2, wbs = 0x4 }а не как сейчас. Судя по описанию реализации все для этого есть.
qw1
22.10.2021 21:09Предложить то чего у других нет — вот ключ к успеху, а лепить свою формулу-1 и тащить на гонку с определившимися фаворитами на черт знает каком кругу, даже если допустят, бесперспективно
Всё так, но тогда надо предлагать принципиально другие подходы к вычислениям, к рантайму, к ОС, организации алгоритмов. А то получается, берём «принципиально новый» процессор, и натягиваем его, как сову на глобус, на столетний C/C++ код (linux kernel и миллионы строк кода прикладных программ). Под это легаси игроки рынка десятилетиями оптимизировали свои мейнстрим процессоры, и на этом поле их не догнать.
Armmaster
22.10.2021 21:15Никакой такой фундаментальной необходимости в ОоО нет, это чисто приблуда для повышения однопоточной производительности
Это просто вишенка на торт к тому потоку дичайшего бреда, который вы написали в первых двух абзацах.
Хорошо, приведу цитату:
Это цитата из ресерч статьи, а в жизни всё может поменяться. Вы результаты видели там? минус 2 процента перфа. И ничего не сказано про главное - return из функции. В общем, это опять не нормальный бранч-предиктор, а очередной костыль, который пытаются впихнуть в реалии Эльбруса.
OpenA
23.10.2021 20:57+2Вы результаты видели там? минус 2 процента перфа.
Естественно, потому что бранчпредиктор не дает бесплатных переходов. В отличии от доп. конвеера с уже заранее подкаченными инструкциями бранча, у него один пайплайн и ему нужно угадать какими инструкциями из какого бранча в следующем такте его начать забивать вслед за инструкцией условного перехода для которой еще даже аргументы не сосчитались. Потому что если этого не сделать переход будет дорогим на всю длинну стадий конвеера.
Сам по себе это и есть костыль для пайплайновых процессоров дабы удешевить переходы, и ошибки предсказания (штатная ситуация для бранчпредикторов) дорого обходятся, так как в этом случае приходится сбрасывать конвейер.
Однако эльбрусовские классические подготовки как назло стоят там где бранчпредиктор вполне себе хорошо справляются и наоборот, плюс первый стоит дорого по оборудованию и не масштабируется, второй же более менее можно допиливать и расширять, вангую в итоге придут к урезаной версии конвеера подготовки и общему бранчпредиктору. Возможно что уже прешли, все таки дока выше 2016г и его в таком виде так и не имплементировали.
И ничего не сказано про главное - return из функции.
Бранчпредиктору все равно возврат, переход,, вызов, прыжок в начало цыкла или что то еще, он не исполняет инструкции он их выдает конвейеру по заранее предсказанному адресу.
YuriPanchul
11.11.2021 23:41*** Бранчпредиктору все равно возврат, переход,, вызов, прыжок в начало цыкла или что то еще, он не исполняет инструкции он их выдает конвейеру по заранее предсказанному адресу. ***
Ничего подобного. Я работал в MIPS и у нас был отдельный бранчпредиктор для возвратов из функции, другой чем главный бранчпредиктор
Это написано и в википедии:
https://en.wikipedia.org/wiki/Branch_predictor#Prediction_of_function_returns
Many microprocessors have a separate prediction mechanism for return instructions. This mechanism is based on a so-called return stack buffer, which is a local mirror of the call stack. The size of the return stack buffer is typically 4–16 entries.[8]
qw1
12.11.2021 10:47Тут речь не о том, как реализован предиктор, а о том, что происходит по результатам его действий. А именно, происходит подкачка кода в конвеер и его выполнение, возможно спекулятивное.
Оппонент выше написал, что предиктор можно заменить на инструкции disp, которые будут принудительно подкачивать код. Адрес, который надо подкачать, известен перед входом в функцию, но незадолго перед return такую команду разместить нельзя, потому что статически адрес возврата неизвестен. Поэтому динамическое предказание работает на возвратах, а статическое не работает.
derKodt1
26.10.2021 19:23+1К вопросу о костылях, согласно текущим реалиям, фронт процессоров (по сути на текущий момент они все RISC) последовательный, а бэк, соответственно, параллельный. Тогда вопрос, как вы будете организовывать параллельные вычисления на уровне какого-либо языка программирования?
qw1
27.10.2021 09:33А зачем? Грубо говоря, зачем программисту в выражении (a+b)*(c+d) вручную на уровне ЯП указывать, что считать параллельно, если компиляторы и ООО процессоры с этим отлично справляются?
Не согласны? Приведите пример, где ручной шедулинг настолько нужен, что автоматика точно не справится.derKodt1
27.10.2021 11:36+1Конечно нет, потому что, в итоге, скажем так, вы получите идеологический перекос и он начнет усугубляться, в будущем, в излишках железа и кода. Уже проверено и перепроверено. В итоге вам все равно придется переходить на "прямую" идеологию.
Простой пример. Есть у вас проц с параллельным бэком, вам из ЯП нужно организовать параллельное вычисление (не важно чего), тогда к текущим инструкциям камня пишете еще сет, на основе его пишите интерефейс и в виде библиотек подключаете его к ЯП, а потом уже в контексте процедур и функций этой библиотеки делаете свои параллельные дела. Ничего не напоминает?
Можно сделать по другому. Например, для такого кода:
Параллельно
Нач
х1 = 1;
х2 = 2;
х3 = 3;
Конец;
просто пишите "параллельный" компилятор и фронт камня делаете параллельным. Такой подход как раз дает равномерность при загрузке программера, компилятора и проца - каждый играет свою роль без переоборов или недоборов.
qw1
27.10.2021 16:29+1Вы пытаетесь текущий VLIW, что есть, натянуть на синтаксис ЯП. По сути, заставляя программиста писать на ассемблере под конкретную машину. Это слишком увеличивает когнитивную нагрузку. Нужно головой думать над каждой строчкой — а можно её параллельно выполнить с соседней, или нельзя.
И опять же, компилятор должен тут что-то неявно параллелить. Например выражение типаv = (a+b)*(c+d)вы будете заставлять человека вручную разбивать на широкие команды?
Реально полезного примера вы не предоставили. То есть, сейчас вам на таком языке ничего не хочется написать. Значит, идея ещё не готова к применению на практике.
qw1
27.10.2021 16:57Например, для такого кода: <...> просто пишите «параллельный» компилятор и фронт камня делаете параллельным
На самом деле, не просто.
«Просто» я напишу:Параллельно x1 = System.File.IO.ReadFloat(file1); x2 = gcd(z1, z2); // алгоритм Евклида x3 = sin(e); Конец;
Тут вызов ф-ции ОС, вызов длинного алгоритма и совсем простое — что-то посчитать на FPU (который возможно будет занят первой инструкцией). Формально я буду прав — это можно всё делать параллельно. Как компилятор должен это положить в код — потоками, VLIW или ещё как — задача на данный момент не имеет решения, компилятор не имеет достаточной информации о том, что происходит, чтобы принять оптимальное решение.
derKodt1
27.10.2021 02:57-1Усугубляю. Какой алгоритм решения той или иной задачи эффективнее, последовательный или параллельный (точнее будет сказать последовательно-параллельный, он же ППА)? Ответ по-моему очевиден. Тогда следующий вопрос - по "мотивам" ППА какой должен быть код на коком-либо ЯП? И опять все на поверхности, т.е. последовательно-параллельным ( ЯП тогда должен по-сути своей называться явно параллельным языком программирования - ЯПЯП)! Тогда для ЯПЯП каким должен быть компилятор и фронт процессора?
derKodt1
27.10.2021 03:03-1... и (как говорят в Одессе и Израиле)) вы будете утверждать, что ему никогда не присвоят почетного звания генерала Пурпозы)))?
Mox
06.11.2021 12:23Погодите, но ведь profile-guided оптимизация в gcc была еще хз с каких времен и ничего дополнительного в процессоре точно не требовалось? Не совсем понятно что именно нужно добавить в Эльбрус чтобы это заработало.
Armmaster
21.10.2021 13:07+20Несколько ремарок:
Это позволяет экономить на jmp потому, что некоторые простые условные операции можно закодировать в одной инструкции
Главная идея предикатов не в экономии jmp, а в том, чтобы убрать ветвления и создать максимально длинные последовательные участки кода. Иначе невозможно эффективно заполнить ШК,
Команда перехода (jmp) сбивает работу конвейера и обходятся процессору как десяток других команд
Это не так при наличии блока предсказателя переходов. А данный блок существует в любом мало-мальски приличном CPU уже лет 20 как.
Эльбрус может избежать этой проблемы не только с помощью предикатов, но и за счёт по другому устроенной команды переходов
Это уже было обсуждено в серии последних статей про Эльбрус - механизм подготовки переходов является одной из главных проблем архитектуры e2k, он катастрофически плохо работает. Именно поэтому МЦСТ в последних публичных заявлениях (неофициальных, правда) декларирует отказ от текущего мехнизма и переход к классическому предсказателю переходов
Если вы закодируете эту операцию обычным циклом (часть кода, jmp на начало, снова та же часть кода, который исполняется в цикле), то на каждой итерации будет обращение к памяти, на котором процессор зависнет, пока не получит данные из памяти
Опять-таки, это неверно, т.к. аппартный блок префетча заранее подкачает код в кэши и процессор записать не будет
В традиционном процессоре, jmp не позволит исполнять следующую итерацию до окончания предыдущей, поэтому код будет исполняться строго до последней инструкции
Конечно же нет. ОоО легко перемешивает инструкции из разных итераций цикла. Более того, это как раз одно из тех мест, где современный ОоО RISC процессор фундаментально проще и быстрее исполняет код, по сравнению с VLIW со статическим планированием. Т.е. каждый цикл в ОоО RISC автоматически и максимально эффективно накручивается (если хватает внутренних буферов, конечно же)
Бинарный транслятор сделан в виде набора из трёх трансляторов и состоит из трех уровней кодогенерации
Всё же из 4-х, там есть ещё интерпретатор (хотя это не транслятор, но тем не менее)
Быстрый регионный, который берет уже не одну инструкцию, а линейный фрагмент и компилирует его, учитывая взаимосвязи между инструкциями
Быстрый регионный транслятор оперирует регионами (т.е. произвольными CFG-графами), а не линейными фрагментами. Что собственно даже из его названия проистекает. Даже шаблонный транслятор оперирует трассами (хотя транслирует код "шаблонно" по одной x86-инструкции)
Это тяжелый оптимизирующий компилятор, который выжимает из бинарной трансляции все, что возможно, и синтезирует эффективный код. По быстродействию он мало уступает прямому исполнению на родном Интел
Тогда тут надо уточнить, что родной Интел должен быть года этак из 2005-го (это если мы говорим про Эльбрус-16С). Плюс/минус, конечно же.
yalex1442
21.10.2021 13:18-1>Тогда тут надо уточнить, что родной Интел должен быть года этак из 2005-го (это если мы говорим про Эльбрус-16С). Плюс/минус, конечно же.
То что эмулируемый на эльбрусе интел такой же как интел из 2005 года — это в смысле по поддерживаемым наборам инструкций (SSE, AVX и т.п.) и/или по производительности?
доп:
Если по скорости, то это не так — в эмуле даже на 8с удается запускать достаточно тяжелый Final Fantasy XV
А вот с cyberpank были проблемы, мб каких-нибудь avx не хватает?
Civil
21.10.2021 15:21+2Если по скорости, то это не так — в эмуле даже на 8с удается запускать достаточно тяжелый Final Fantasy XV
Если верить вашему чатику в неизвестном разрешении на Low графике игра показывает 16-20 фпс, строго говоря чтобы корректно сравнивать нужно было гонять бенчмарки, как делали в 18 году все обзорщики, но легко найти в интернете видео связки i3-2120+rx550 которые показывают в Low стабильные 36 фпс в той же сцене. Так конечно на Intel'ах 2005 года ее никто не пробовал запускать, но разница производительности на ядро между Core 2 Duo и i3-2120 - далеко не в два раза.
А вот с cyberpank были проблемы, мб каких-нибудь avx не хватает?
Cyberpunk без фанатских патчей требует AVX, но на первые патчи была фанатская модификация, которая позволяла его запускать если AVX нет, но есть SSE 4.2 (но разработчики впрочем потом это включили в хотфикс)
Armmaster
21.10.2021 16:23+2Если по скорости, то это не так
Согласитесь, достаточно странно спорить о производительности Lintel с человеком, который производительностью Lintel и занимался.
Производительность вообще надо уметь корректно мерять. Что касается вашего примера - измерять перф процессора на играх достаточно плохая затея, т.к. там скорее важнее перф видеокарты. Ну т.е. если вы запустили Final Fantasy XV с какой-то приемлемой производительностью, то это скорее всего заслуга видеокарты. Уж как минимум, надо детально разбираться, что там происходит.
Civil
21.10.2021 17:49+1Что касается вашего примера - измерять перф процессора на играх достаточно плохая затея, т.к. там скорее важнее перф видеокарты. Ну т.е. если вы запустили Final Fantasy XV с какой-то приемлемой производительностью, то это скорее всего заслуга видеокарты. Уж как минимум, надо детально разбираться, что там происходит.
В среднем да, но конкретно в этом случаи игра уперлась в процессор (если открыть их чатик и почитать, там челвоек показывает 100% загрузку цпу и отдыхающий половину времени GPU на графиках).
Вообще игры могут упираться в процессор, притом в разные части - все таки каждый фрейм это render call и его надо как-то обработать, а еще кроме самого рендера кадров нужно рассчитывать AI, скрипты и прочее, то есть процессор в современных играх тоже важен до какого-то момента. Тут еще проблема в том, что сложно найти тесты игр на множестве разных процессоров и видеокарт. Например на i3-2120 игра не упирается в процессор в 1080p. Но разрешение в котором игру тестировали в чатике том - неизвестно, известно что загрузка цпу была 100% на их 16 фпс, то есть можно прикинуть что резульаты Эльбруса примерно в 4 раза хуже чем i3-2120 для игр.
А про правильные бенчмарки - надо собирать много статистики и, по возможности, использовать воспроизводимые бенчмарки (например встроенные средства или уже написанные другими людьми, как в случаи с FF XV). Если смотришь на реальный геймплей, то выбирается сейв где делается очень предсказуемый набор действий, и в это время записывается много статистики, в духе загрузки CPU, загрузки GPU, времени рендера каждого кадра (чтобы потом можно было посчитать FPS и различные перцентили, например оценить наличие просадок), тогда можно предметнее говорить о бенчмарках в играх. И кстати, в некоторых играх когда процессор не может раскачать карту - будут заметны просадки именно в 99-99.9 перцентилях времени рендера, а для игрока это будет выглядеть как периодические фризы (или фризы в каких-то ситуациях), например во время боя или взаимодействия с предметами в случаи action'ов.
qw1
21.10.2021 21:50+3В среднем да, но конкретно в этом случаи игра уперлась в процессор
В этом-то и ирония. Если игра на интеле жрёт 25% процессора и выдаёт 60 fps, а на Эльбрусе жрёт 100% и выдаёт 20 fps, разница не в 3 раза, разница в 12 раз.Civil
21.10.2021 22:38В этом-то и ирония. Если игра на интеле жрёт 25% процессора и выдаёт 60 fps, а на Эльбрусе жрёт 100% и выдаёт 20 fps, разница не в 3 раза, разница в 12 раз.
Я не нашел адекватных тестов на очень старых интелах, в каком-то случайном видео на youtube'е загрузка была 50%, поэтому я округленно посчитал что 32/16 = 2 раза чистой производительности и скорее всего имея еще половину цпу свободным - еще 2 раза, так что 4. Но не принципиально.
Я видел еще тесты на каком-то сомнительном сайте где игра на i3-2100 давала 60 с чем-то FPS в 1080p@Low на RX 550 и 125 фпс если заменить видеокарту на rx570, но я не смог найти информацию про методику тестирования и это был буквально первый раз когда я видел этот сайт в глдаза, поэтому не стал его приводить (но думал об этом). Потому что по хорошему в рамках тестов надо фиксировать используемые версии и все доступные настройки, а этого эльбрусовцами сделано не было.
checkpoint
22.10.2021 03:56Все потому, что в Эльбрусе нет предсказателя, а статическая оптимизация (оптимизация на уровне компилятора) на деле оказалась полным фуфлом. Если Вашу игрушку перекомпилять с иcпользованием SIMD оптимизации, то она покажет те же 60 fsp при близкой к интеллу нагрузке. Недавно такой фокус проделали с Blender-ом и получили интересные результаты. Но засада в том, что сделать это в подавляющем большинстве случаев либо невозможно, либо сильно затруднительно.
Civil
22.10.2021 04:16+1Ссылка некорректная. Посмотрите на результат в ней и на картинку, которая была ранее (скриншот из статьи на которую они же ссылаются). Пока картинки не будут попиксельно идентичными, скорость сравнивать в принципе некорректно (например поломанные источники освещения могли привести к ускорению рендера, а не оптимизации).
Если Вашу игрушку перекомпилять с иcпользованием SIMD оптимизации, то она покажет те же 60 fsp при близкой к интеллу нагрузке.
Только при условии, если игра использует операции, которые хорошо векторизуются (что само по себе не факт), а также не стоит забывать про другие особенности Эльбруса типа нелюбви к ветвлениям (по понятным причинам, о которых в том числе вы сказали), но которые активно используются в играх.
checkpoint
22.10.2021 13:00+1Вы полностью правы. Все это говорит от том, что Эльбрус - процессор специализированного назначения (хорошая цифродробилка) и в тесте с Blender-ом он был задействован по своему прямому назначению, хоть тест и не совсем правильный. Желание МЦСТ навялить Эльбрус нашему государству как процессор общего назначения сталкивается в профессиональном обществе с резонным вопросом - "нахрена козе баян".
Лично моё мнение - на Эльбрусах можно и нужно делать видеоускорители, нейроускорители и прочие DSP. Но только те, где НЕ требуется многозадачность. Иначе длинный регистровый файл похоронит и эту нишу.
Civil
22.10.2021 15:13Лично моё мнение - на Эльбрусах можно и нужно делать видеоускорители, нейроускорители и прочие DSP. Но только те, где НЕ требуется многозадачность. Иначе длинный регистровый файл похоронит и эту нишу.
При позиционировании как числодробилки напрашивается будут уже другие сравнения. Там тоже интересный вопрос, как будет выглядеть результат.
checkpoint
22.10.2021 15:36+1Я уверен, криптомайнеры были бы счастливы помайнить на Эльбрусах - была бы цена доступной. ;-)
Civil
22.10.2021 16:44Совсем не факт, что им бы удалось эффективно загрузить эльбрус (там же очень много ограничений на то что с чем может сочетаться из операций). Хотя это скорее зависит от алгоритма.
checkpoint
22.10.2021 17:05+1У майнеров с алгоритмами как раз все в порядке - чистая математика, один раз заоптимизировал и реплицируй на сколько денег хватает. Структура потока данных не меняется (компилятор будет рад), так что можно постараться выжать максимум.
Civil
22.10.2021 17:13Только вот АЛУ непавноправные и не любой алгоритм позволит достичь пиковой производительности
qw1
22.10.2021 21:13-1криптомайнеры были бы счастливы помайнить на Эльбрусах
Бессмысленно. 8704 CUDA-ядер у RTX 3080, на которых параллельно выполняется 8704 потоков вычислений невозможно догнать никаким 8 или даже 16-ядерным CPU.
TimID
02.11.2021 01:19+1Ну они (эти 8704 ядра) не совсем параллельны как бы. Особенности архитектуры CUDA как раз в том, что это как раз вычисления (расчеты), а не работа АЛУ в чистом виде.
Алгоритмы биткоина действительно нацелены на "прямые" вычисления. Но есть ведь и другие криптовалюты.
qw1
02.11.2021 14:22Например, какие другие? Эфир, который упирается в пропускную способность памяти, вдруг будет лучше майниться на Эльбрусах, чем на NVidia RTX? (нет)
Andrey_Petroff
22.10.2021 15:02+2Шигорин там ошибся. Использовался не тот рендер.
Civil
22.10.2021 15:14+1Тут уж я деталей не знаю, просто увидел значительную разницу в картинке, которая легко может объяснить разницу в производительности. И просто сказал, что в случае рендера нужно чтобы была попиксельная идентичность результатов для корректного сравнения. Иначе это фигня какая-то.
Alekseyz
21.10.2021 13:14-7Зачем все эти потуги, может лучше было бы клонировать арм?
Oxyd
21.10.2021 22:11-2Я бы проголосовал за RISC-V. Ну просто потому что мне кажется эта архитектура довольно перспективной. Да и лицензионная чистота как бы тоже гуд.
amartology
21.10.2021 23:45У Байкала ARM и MIPS вполне лицензионно чистые.
qw1
21.10.2021 23:55+1У Байкала архитектурная лицензия на ARM?
А что будет, когда выйдет новая версия (условно, ARMv11), а продавать лицензию не захотят?amartology
22.10.2021 10:18+2У Байкала архитектурная лицензия на ARM?
Нет, не архитектурная. Она не имеет смысла для подавляющего большинства компаний, а Байкал не относится к той небольшой подгруппе, которая получает конкурентные преимущества за счет микроархитектуры.А что будет, когда выйдет новая версия (условно, ARMv11), а продавать лицензию не захотят?
А что будет, когда выйдет нова версия ARM, а продавать ее Apple и Qualcomm они не захотят?
Если же вы переживаете насчет каких-то новых санкций, то побеспокойтесь лучше о том, как производить процессоры на 180 нм, если отключат не лицензию на ARM, а доступ к TSMC.Civil
22.10.2021 11:47Если же вы переживаете насчет каких-то новых санкций, то побеспокойтесь лучше о том, как производить процессоры на 180 нм, если отключат не лицензию на ARM, а доступ к TSMC.
Кстати, а сопутствующие материалы, типа тех же пластин, для тех фабов в рф вообще делают? А то что то мне подсказывает, что там зависимостей несколько больше.
amartology
22.10.2021 12:57+2Кстати, а сопутствующие материалы, типа тех же пластин, для тех фабов в рф вообще делают? А то что то мне подсказывает, что там зависимостей несколько больше.
Правильно подсказывает. Пластины импортные, фотошаблоны — импортные, даже у полностью отечественных чипов, большая часть химии импортная, все производственное оборудование, запчасти и поддержка к нему — импортные.
LightPeet
30.11.2021 15:40как то в одной статье попалось высказывание, что - на отечественных фабах, из местных ингредиентов только воздух, да и то очищенный через импортные фильтры
qw1
22.10.2021 12:36+1А что будет, когда выйдет нова версия ARM, а продавать ее Apple и Qualcomm они не захотят?
То есть, RISC-V это минус один риск.побеспокойтесь лучше о том, как производить процессоры на 180 нм, если отключат не лицензию на ARM, а доступ к TSMC
Чисто теоретически, материковые китайцы лет через 5 смогут выполнять заказы на более-менее актуальные нанометры.amartology
22.10.2021 12:59-1Чисто теоретически, материковые китайцы лет через 5 смогут выполнять заказы на более-менее актуальные нанометры.
А чем именно технологическая зависимость от КНР лучше зависимости от США и Тайваня?То есть, RISC-V это минус один риск.
Я очень слабо представляю себе ситуацию, когда ARM запретят, а иностранные фабы — нет. Эти риски почти наверняка придут вместе, поэтому надо избавляться или от обоих сразу, или ни от одного.
И САПР для проектирования еще — третий риск в комплекте.qw1
22.10.2021 13:14Я очень слабо представляю себе ситуацию, когда ARM запретят, а иностранные фабы — нет
Разница в том, что абстрактных иностранных фабов теоретически может быть несколько, не все сразу запретят. А лицензиар конкретной архитектуры — ровно один.amartology
22.10.2021 13:29Неабстрактных фабов, способных производить чипы с требуемыми нормами, в мире ровно четыре, и все они аккуратно сотрудничают с властями США. Дада, и китайская SMIC тоже.
Когда Хуавею запретили доступ к TSMC, они даже не стали пробовать договариваться с Samsung, потому что понимали, что ничего не выйдет.
Civil
22.10.2021 13:01Чисто теоретически, материковые китайцы лет через 5 смогут выполнять заказы на более-менее актуальные нанометры.
Если смогут освоить производство оборудования в достаточной мере, чтобы быть свободными от экспортных ограничений. И если сами захотят портить отношения с другими ради помощи соседу. И если этот сосед с ними не поругаться раньше. В общем очень ую много если.
qasta
21.10.2021 14:57+3Спасибо за статью. Читается на одном дыхании, многих аспектов не знал, хотя за Эльбрусами посматриваю довольно давно.
P.S. Если кто пугается текущих цен на модули, то скажу, что раньше модулей или не было, или они были дороже. С массовостью цены неизбежно будут ниже, хотя, конечно, до Интел или АМД вряд ли опустятся - масштабы производства сильно отличаются всё-таки.
T_Cirkla
21.10.2021 21:39Время идёт, а никакого массового производства Эльбрусов и Байкалов почему-то нет. Трудно дать заказ TSMC или они заказ этот не принимают?
Am0ralist
23.10.2021 12:15+1Время идёт, а никакого массового производства Эльбрусов и Байкалов почему-то нет. Трудно дать заказ TSMC или они заказ этот не принимают?
Они загружены сильно, так что не особо принимают. 10к байкалов, вроде, привезли, около 10к эльбрусов вроде в первом квартале следующего года должны привезти.
Oxyd
21.10.2021 22:13А откуда тут возьмётся массовость, если весь этот марлезонский балет регулируется не потребностями рынка, а деньгами налогоплательщиков?
NickSin
21.10.2021 17:28Спасибо за статью. Было интересно читать.
Эх, я все жду когда выпустят маленькие модулю с выводами под usb, sata отдельными, чтобы можно было это дело в кастомное шасси ноута вставить и попробовать это дело все потыкать.
AVI-crak
21.10.2021 17:43+5В Эльбрусе команды push и pop не используются. Процессор содержит пул из 256 84-разрядных регистров. Не все они видны программе: каждая функция «заказывает» у процессора нужное количество и процессор выделяет ей часть пула, в которой она будет жить.
Вот этот момент явно отличается от всего что сделано раньше, и даже сейчас. В связи с чем вопрос - каким образом функция может вернуть больше одного регистра, например структуру.
В нормальных цпу перед вызовом подпрограммы выделяется место на стеке. В сильно оптимизированном виде пространство данных может быть выделено прямо в регистрах. Но как выяснилось, у эльбруса два стека на поток: откачка лишнего из раздутого "кеша" регистрового поля, и стек заточенный под сохранение данных. Лично мне как пользователю ARM - данный прикол кажется дикой дикостью. Это-ж сколько нужно дополнительной индексной информации параллельно обслуживать, чтобы вытащить нужное из глубины стека.
И дополнительно, сообщите плиз уровень вашей боли при переключении контекста.
dzavalishin Автор
22.10.2021 02:01+1Не вижу проблемы. Вы точно так же можете оставить место в окне параметров под структуру, или передать параметр с адресом.
qw1
22.10.2021 12:56Проблема разве что с совместимостью с C-кодом, когда берётся этот адрес структуры и передаётся в другую функцию. Ведь у Эльбруса её нет в памяти, она существует только в регистровом файле. Компилятор будет вынужден вокруг этого делать какие-то танцы с бубном?
qw1
22.10.2021 12:40+1Но как выяснилось, у эльбруса два стека на поток: откачка лишнего из раздутого «кеша» регистрового поля, и стек заточенный под сохранение данных. Лично мне как пользователю ARM — данный прикол кажется дикой дикостью. Это-ж сколько нужно дополнительной индексной информации параллельно обслуживать, чтобы вытащить нужное
Как по мне, это плюс: железо может два, а то и три стека обслуживать параллельно. И между ними не будет зависимостей по данным (т.е. условный call/ret никак не пересекается с push/pop).
з.ы. пишу интерпретатор стековой машины и разнёс стеки числовых и ссылочных значений (строк) в разные структуры. Никаких проблем от этого, только касты исчезли между uint64 и void*
beroal
26.10.2021 19:33+1Вот этот момент явно отличается от всего что сделано раньше, и даже сейчас.
Это Register Stack Engine (RSE), как в Itanium. Подобное было в SPARC-е и в каком-то Hobbit-е.
TimID
02.11.2021 01:36Накладные расходы (конструктивные) на регистровые файлы намного меньше, чем на конвейеризацию. Это прямо - бинго в плане размена, на что тратить логические ячейки. Однако "обычные" процессоры давным давно изобрели кэш третьего уровня, работающий на частоте ядра.
Меня вот смущает реализация многопоточности. Одно дело, когда компилятор собирает код единственного потока - тут можно оптимизировать сколько угодно. И регистровый файл тут в масть.
Но совсем другое дело - жонглирование большим количеством потоков. Явно, что переключаться туда-сюда нельзя будет, поскольку одно дело, хранить для каждого потока один указатель на вершину его собственного стека, и совсем другое - где-то брать уникальную копию регистрового файла в самом железе процессора.
Ведь нет никакой гарантии, что к моменту переключения потоков (завершения кванта, выделенного потоку) стек будет хотя бы приблизительно в том же месте, где при входе в этот самый квант.
beeruser
02.11.2021 02:20Накладные расходы (конструктивные) на регистровые файлы намного меньше, чем на конвейеризацию. Это прямо — бинго в плане размена, на что тратить логические ячейки. Однако «обычные» процессоры давным давно изобрели кэш третьего уровня, работающий на частоте ядра.
Вы сплели 3 несвязанные между собой вещи в один абзац. Не ясно что вы хотели этим сказать.
Все современные процессоры конвейеризированы (и Эльбрус). А уж имеют ли они вращающиеся регистры или кэш L3, то это вообще тут не причём.где-то брать уникальную копию регистрового файла в самом железе процессора.
Никакой копии там нет (в Эльбрусе). Стеки сохраняются в память.
Например на Sparc может быть до 32 окон по 16 регистров (512+8) в теории. Смена задач или любое нарушение порядка вызовов может вызывать сброс регистров в память.
В процессорах типа Niagara (Ultrasparc T1+) есть 4-way SMT, что несколько улучшает положение.
В любом случае идея с вращающимися регистрам ущербна сама по себе для процессора общего назначения.
Она годится только для вычислений в однозадачной среде.
icps.u-strasbg.fr/people/loechner/public_html/enseignement/SPARC/sparcstack.htmlThat was the idea, anyway. The drawback is that upon interactions with the system the registers need to be flushed to the stack, necessitating a long sequence of writes to memory of data that is often mostly garbage. Register windows was a bad idea that was caused by simulation studies that considered only programs in isolation, as opposed to multitasking workloads, and by considering compilers with poor optimization. It also caused considerable problems in implementing high-end Sparc processors such as the SuperSparc, although more recent implementations have dealt effectively with the obstacles. Register windows is now part of the compatibility legacy and not easily removed from the architecture.
ModestONE
21.10.2021 23:03+2Разработчики молодцы! Не смотря ни на что.
Но хотелось бы побольше фоток железок и желательно с чистой мета-датой. Также, интересно было бы узнать, а проходят ли аудит другие комплектующие? Ну и увидеть бы код биос и/или его производную.
third112
22.10.2021 00:48+1Очень красиво написано, но почему бенчмарков нет? Нужно убедительное сравнение со "всякими интелами".
DaytonCavalet
22.10.2021 01:23+2Мне, как не профи в этом вопросе - каждый раз, разумеется, любопытно читать статьи, которые то восхваляют Эльбрусы, то выбивают из них последний дух. Особенно доставляет прочтение комментариев.
Но такой вопрос, просто, чтобы разобраться:
Если Эльбрус плох, то зачем и на что существует разработчик?
Если Эльбрус так хорош, то почему его распространение НАСТОЛЬКО ограничено даже при всех тех попытках, которые осуществляет государство для его проталкивания в жизнь?
dzavalishin Автор
22.10.2021 02:02+3Процессоры дешевеют при массовом производстве. Для массового производства нужен массовый заказ. Для массового заказа процессор должен быть дешёвым.
VoxelCat
22.10.2021 15:02+2Для массового заказа процессор ещё должен быть востребован массовым заказчиком, эффективно удовлетворяя его потребности в пересчёте на единицу стоимости и потребляемый Ватт. И удобен во всех смыслах разработчикам массово используемого ПО. Так то и Broadcom BCM2711, и какой-нибудь EPYC – оба массовые.
Pyhesty
22.10.2021 10:22распространенние никто не ограничивает, по моему опыту софт всегда отстает от железа, малое количество софта и отсутствие программистов в данном сегменте ограничивает применимость архитектуры и процессора.
считаю, что по мере наработки софта, под эту архитектуру станет проще разрабатывать, потребителей станет больше, появится спрос на программистов, повысится их зп и престиж, но альтернативный вариант, признать Эльбрус неперспективным и использовать всем только х86, так как это проще (нет).
amartology
22.10.2021 10:29+3Если Эльбрус плох, то зачем и на что существует разработчик?
Разработчик существует на выделяемые из бюджета деньги. В Минпромторге считают, что стране нужна собственная архитектура. Ее коммерческая успешность Минпромторг волнует в меньшей степени, чем независимость.
Sheti
25.10.2021 18:52+1А чем обусловлена необходимость именно своей архитектуры? Чем плохи другие в том числе и открытые?
amartology
26.10.2021 02:38+1Я не знаю ответа на этот вопрос. Те аргументы, которые я в разное время слышал, мне не кажутся убедительными. С моей точки зрения это выглядит так, что когда-то некоторые люди начали удовлетворять свои научные амбиции и проверять свои гипотезы за государственный счет, сумев убедить кого-то из принимающих решения о выделении бюджетных денег, а сейчас наработок уже так много, что бросать их стало жалко, несмотря на очевидную уже всем тупиковость выбранного подхода и наличие лицензионно чистых альтернатив.
Am0ralist
26.10.2021 16:06А что сейчас открытого есть из современного? Только Риск5, примеров которого высокопроизводительного пока нет, хотя обещаний много.
АРМ — вон, китайцам выделили компанию для лицензирования, чтоб под санкции США против Китая не попала возможность лицензирования китайцев, а после этого при попытки покупкой Нвидией оказалось, что не могут сменить там главу. Хотя деньги исправно получают.
Китайцы усиленно свои архитектуры пилят, и не сказать, что достигли высот, хотя возможностей у них по идее было больше.
Итого пилили её уже давно, пока она была нужна по-большей части абстрактно, а сейчас имеют наработки и вполне нормальные варианты, но можно попробовать соскочить на рискV, к которому на самом деле тоже есть вопросы некоторые, но считай их «отечественных» не будет ещё года-4-5 вообще (как и девайсах на них), тогда как эльбрусы прямо сейчас упираются только возможность производства на ТСМЦ, в том числе и 16С вроде как на этапе проверки и верификации, после которого только ждать, пока у ТСМЦ будет время на этот небольшой заказ.Sheti
26.10.2021 16:13Есть ещё OpenRISC и OpenSPARC. Ну и не стоит забывать хоть и про лицензируемую, но довольно распространенную архитектуру MIPS. Всё же на ARM свет клином не сошелся.
Кроме того у МЦСТ есть опыт в работе со SPARC, что могло бы помочь.
Am0ralist
26.10.2021 16:47Мипс как раз в том что ли году закопался? Или я спутал?
Любые лицензируемые так же не особо вариант ровно по той же причине, по какой АРМ создал китайский АРМ, а потом потерял управление над ней.
Всё прочее сколько существует, ага, в принципе. Но в чём выигрыш использования оных?Sheti
26.10.2021 16:53В чем выигрыш открытых решений? В их открытости. Я думаю это не надо объяснять. Помимо этого, под выше перечисленные архитектуры есть рабочие сборки linux.
МЦСТ не спешить открывать документацию на Эльбрус. Без этого можно довериться только их уровню компетенции в адаптации ОС и компиляторов под их же архитектуру.
Лично мне кажется, что открытая архитектура была бы предпочтительнее, чем закрытая хотя бы в той части, что больше разработчиков могло бы её изучать и адаптировать софт. А ещё более предпочтительно не только открытая, но и так которая уже использовалась.Am0ralist
26.10.2021 18:18-1МЦСТ не спешить открывать документацию на Эльбрус.
Он весьма активно это делает, насколько может. Ну и уже есть способы работы с оным, вроде, через тот же ростелеком, хотя не знаю, насколько это реально работает.Без этого можно довериться только их уровню компетенции в адаптации ОС и компиляторов под их же архитектуру.
Эм, у них ОС только как базовый дистриб, компилятор они пишут, да. А ОС таки уже другие под них пилят. То есть тут скорее компетенции всяких альтов и прочих играют роль больше, которые доступ к документации имеют активно. Комплексы будут не с дистрибом МЦСТ продаваться.В чем выигрыш открытых решений? В их открытости.
А я думал основной смысл был в производительности решений, а так же насколько архитектура имеет ошибки при изначальном создании…хотя бы в той части, что больше разработчиков могло бы её изучать и адаптировать софт.
Угу, по этому умерший мипс и отрытые мало кому нужные решения (но вы можете мое мнение о тех архитектурах изменить, если покажете какие-то реальные массовые производительные решения) вы предлагали, чтоб потом их дорабатывать, изменять и получить в итоге опять что-то своё, да?но и так которая уже использовалась.
Сетунь! Считаю, что настоящий RISC может быть только троичным!
Извините, x86 нельзя, армы — лицензируются, а основные претензии к эльбрусам и так — производительность, чтоб ещё тянуть какие-то никому не нужные архитектуры, получить тоже самое скорей всего. И всё это ради шильдика «зато открытое»?
РискV в этом плане интересен, но в общем фокусе интереса компаний появился только недавно, представлен в 10, только в 15 движуха началась хоть какая-то, обосновывать этим отказ делать эльбрусы все нулевые и десятые — ну то же как-то странно.
Да, вот сейчас можно думать, куда плыть. Имеет смысл и риски чтоб делали.
Вот только сразу закапывать эльбрусы просто потому, что кто-то через несколько лет чего-то пообещал (так вы тоже говорите (с))? По мне — странно.Sheti
26.10.2021 18:28Вот вы всё упираете на производительность и архитектурные ошибки. Но насколько мне не изменяется память за исключением каких то экзотических и экспериментальных архитектур всё что дожило до наших дней и делалось в кремнии вполне себе не хуже. У каждой архитектуры есть достоинства и недостатки. При условии, что не надо тянуть за собой груз обратной совместимости производительность будет +- одна. Всё упирается уже в техпроцесс и хитрые оптимизации в виде дополнительных расширенных инструкций, мощного блока предсказания ветвлений, конвейеров.
Тот же ARM очень долгое время оставался нишевым процессором не выделяющимся особой производительностью на фоне x86-64 в абсолютных выражениях. Но как только появилась потребность и деньги, так его быстро подтянули до нужных высот.
С другой стороны x86-64 и ARM в своих недрах не так уж и различны. А вот VLIW это совсем другой подход и судя по тому что я читал есть серьезные трудности с наращиванием его производительности в обычных задачах.
Am0ralist
26.10.2021 18:42Я?
Нет, это в куче статей на хабре сейчас упирают на производительнсть, как основной аргумент того, что эльбрус не нужен.При условии, что не надо тянуть за собой груз обратной совместимости производительность будет +- одна.
Вы это расскажите решениям китайцев по «импортазмещению». Можете рассказать бульдозерам АМД. Можете посравнивать производительность реализации АРМ Эплом, самсунгом и кто там ещё своё пили.А вот VLIW это совсем другой подход и судя по тому что я читал есть серьезные трудности с наращиванием его производительности в обычных задачах.
Но вы обещаете, что указанные вами архитектуры, в которые никто эти деньги не вливал, получилось бы у нас довести до аналогичной производительности, даже не смотря на то, что те, кто придумали МИПС его же и свернули в итоге?Но как только появилась потребность и деньги, так его быстро подтянули до нужных высот.
Угу, один МЦСТ с копеечным финансированием смог бы это сделать не хуже, чем ЭПЛ, которая пилила десяток лет процы под смартфоны и вложила туда миллиарды, видимо, продавая эти смартфоны так же миллардами.
Ну вот и МЦСТ с сериями в 10-20к штук смог бы совершенно не хуже, так?судя по тому что я читал есть серьезные трудности с наращиванием его производительности в обычных задачах.
Так вы ж говорите, чтоВот вы всё упираете на производительность
Но сами в итоге аргументируете её же и сравниваете решения с многомиллиардынми вливаниями.
Кстати, вот амазон вливал в АРМ деньги, где его производительность не хуже x86? Не хуже на ватт — видел, а вот чтоб прям такая же — не заметно. А в течении пары лет Интел и АМД кучу весьма весёлых решений в те же серверы завезёт, причём это точно будет. А серверные армы — ну… обещаются, кому-то развозят, но… А ведь там тоже финансируют нехило так.
Но ведь всё просто, взяли лицуху арма и готово. Воспользовался открытой архитектурой — и делать нечего.Sheti
27.10.2021 02:52-1Я не понимаю почему вы так упираете в то что MIPS свернули? Это не проблема архитектуры, как таковой, а проблема экономической обоснованности.
Вообще, чтобы говорит о том сколько нужно денег для создания сравнимого с x86-64 по производительности процессора на другой архитектуре необходимо понимание почему у них эта самая производительность разная. Лично я не берусь вот так лихо на глаз сказать, что нужно Х мил. долларов.
Я высказываю предположение, что RISC архитектура в любой конечной реализации в силу своей близости к x86-64 проще довести до нужной производительности, чем VLIW у которого довольно сильные отличия именно в базе. К тому же есть опыт Intel в этом направлении и опыт неудачный. А уж кто, как не Intel понимали в чем причина производительности x86.
Am0ralist
27.10.2021 11:22-1Я не понимаю почему вы так упираете в то что MIPS свернули? Это не проблема архитектуры, как таковой, а проблема экономической обоснованности.
Потому что китайцы его выбрали, как вы советовали. Не вижу, чтоб он не то что бы порвал на том же кремнии армы и x86, но и приблизился к ним.Вообще, чтобы говорит о том сколько нужно денег для создания сравнимого с x86-64 по производительности процессора на другой архитектуре необходимо понимание почему у них эта самая производительность разная.
Потому что в них куча инженеров кучей всяких хаков добились большего. Там каждые +5% обеспечены вложение миллионов в инженеров.Я высказываю предположение, что RISC архитектура в любой конечной реализации в силу своей близости к x86-64 проще довести до нужной производительности
А потом окажется, что из-за недоучета некоторых особенностей при создании набора команд, это всё можно достичь только за счёт спектров и метлдаунов, как у x86 Интела, да?А уж кто, как не Intel понимали в чем причина производительности x86.
Угу, это наглядно показали те ошибки, которые всплыли для кучи поколений процессоров.К тому же есть опыт Intel в этом направлении и опыт неудачный.
Там было много всего весёлого, начиная от того, что считай весь софт тогда писался под девизом «кросплатформенность, что это за фигня?», а все компиляторы были сильно тупее на фоне современных?
Итого, рассказы за риск (к коему армы, например, уже не особо то и относятся, как и современные x86 это не чистые cisc) — они про всё хорошее против всего плохого. Ну, то есть чисто абстрактные.
Конкретика в том, что 11 лет с момента зачатия riskV прошло и его хорошо использовать в микроконтроллерах. О том когда и какое же будет крутое ядро на нём — пока только в обещаниях.
О том, что наши на нём сделают крутой чип за 3 года — отличный рассказ, как обычно в будущем времени. Причём, замечу, сразу после этого (в течении недели, что ли) пошло урезание осётра по тем же частотам, насколько помню. Ну, потому что пообещать то можно многое. А вот с первой попытки выдать результат…
Поэтому, повторюсь, если бы выбирать прямо сейчас, куда идти — да, смотреть на риск — надо. Но, вливы у нас уже есть и их уже можно юзать в куче задач (серии в десяток тысяч процов это не настолько большая доля в море ежегодно покупаемого только государством оборудования)
Получается классика с журавлём в небе и уткой под кроватью
amartology
27.10.2021 02:43+1В чем выигрыш открытых решений? В их открытости.
Вы же понимаете, что говоря об «открытых» RISC-V, OpenPOWER или иже с ними, мы по факту имеем в виду проприетарные реализации открытой системы команд?
То есть, если вам по каким-то причинам была бы нужна архитектурная лицензия на ARM, то RISC-V — это экономия. А если нужно конкретное ядро, то разницы между ARM и RISC-V никакой нет.Sheti
27.10.2021 02:46А что нужно РФ? В статьях о Эльбрусах, как один из плюсов это то что в процессоре своя архитектура без вражеских закладок. Но открытая архитектура в этом плане ничем не хуже.
amartology
27.10.2021 08:05что нужно РФ?
Если бы на поставленный таким образом вопрос существовал короткий прямой ответ, он был бы публичным достоянием.
Но в реальности это вопрос из серии «за все хорошее против всего плохого». Не существует никакого «нужно РФ». Есть люди, боящиеся «вражеских закладок». Есть люди, не верящие в существование «вражеских закладок». Есть люди, считающие импортозамещение жизненной необходимостью, есть люди, считающие его одним большим распилом.
Есть люди, считающие опенсорс единственным выходом, есть люди, считающие, что опенсорс в конечном итоге подконтролен США.
checkpoint
22.10.2021 03:41+4От длинных регистровых файлов отказались сразу, как только их придумали и испытали в 80х. Основная причина - потеря производитеьлности при переключении контекста в многозадачных ОС, которые уже в то время начали доминировать. Более подробно об этом можно прочесть в статьях Д.Паттерсона и Дж. Хеннесси в сборнике "Электроника СБИС. Проектирование микроструктур", Мир, 1989. В сборнике есть много интересной статистики по исполнению различного кода, от компляторов и ОС, до числодробилок.
beroal
26.10.2021 19:24+1Насколько я понял, в эльбрусе не просто большой регистровый файл, а Register Stack Engine (RSE), как в Itanium. Если RSE в фоновом режиме сохраняет в основную память участок не на вершине стека, то производительность будет не хуже любого процессора.
Да и сохранение большого регистрового файла можно оптимизировать, если помечать, какие регистры были изменены, и сохранять только их.
Большой регистровый файл хуже маленького, только если маленькая доля регистров используется. Если используется весь большой регистровый файл, тогда процессор с маленьким регистровым файлом будет обращаться не к регистрам, а к кеш-памяти, то есть работать быстрее не будет.
qw1
27.10.2021 09:46Если RSE в фоновом режиме сохраняет в основную память участок не на вершине стека, то производительность будет не хуже любого процессора
А что произойдёт в момент переключения контекста? Всё несохранённое на текущем потоке надо сохранить в память, вершину стека нового потока загрузить в кеш. Это нельзя делать «в фоновом режиме», т.к. выполнение второго потока на первой же инструкции обратится к регистру из регистрового файла, а там ещё ничего нет.Да и сохранение большого регистрового файла можно оптимизировать, если помечать, какие регистры были изменены, и сохранять только их.
Только память DDR сейчас работает длинными передачами. Выгоднее отправить одну транзакцию на 256 байт, чем 7 транзакций по 8 байт.процессор с маленьким регистровым файлом будет обращаться не к регистрам, а к кеш-памяти, то есть работать быстрее не будет
Тут же вопрос переключения контекста. Кеш L1 не надо сбрасывать при его переключении. Пришло прерывание от таймера — процессор увеличил 1 переменную (все регистры вообще не надо сохранять), вернулся к программе.beroal
27.10.2021 14:21+1Только память DDR сейчас работает длинными передачами. Выгоднее отправить одну транзакцию на 256 байт, чем 7 транзакций по 8 байт.
Ну и используйте регистры длинными блоками.
А что произойдёт в момент переключения контекста? Всё несохранённое на текущем потоке надо сохранить в память
Всё несохранённое надо сохранять в любом процессоре. Надо сравнивать процессор и другой процессор, а не процессор и чудесное устройство, которое не пользуется кэш-памятью вообще. Размер несохранённого в процессоре с обычным регистровым файлом задано электронной схемой процессора (размер регистрового файла), а в процессоре с RSE задаётся динамически, как размер области стека, к которой программа часто обращается.
qw1
27.10.2021 16:39Всё несохранённое надо сохранять в любом процессоре
Я же привёл пример: обработчик прерывания от железки может сохранить только пару регистров (которые он использует), всякие SSE-FPU вообще не трогать, увеличить какую-то переменную или поставить какой-то флажок и вернуть управление программе, которая была прервана. Кеш L1, играющий роль регистрового файла, останется нетронутым.
qw1
27.10.2021 16:43а в процессоре с RSE задаётся динамически
Очень интересно. Какой минимальный размер я могу запросить? Могу запросить 4 или 8 регистров? А если опкод обратится к 10-му, что будет?
user2010
22.10.2021 11:24-5А давайте не будем углубляться в архитектуру! Нам нужен свой процессор! Сделанный в России а не в Китае! А пока этого нет гордиться не чем!
Civil
22.10.2021 11:49+3А чем вам комдив в таком случае не нравится?
Ну или спарки от мцст, что то там у модуля, элвис ещё и прочие?
amartology
22.10.2021 13:05+2Существуют и активно применяются процессоры с собственной архитектурой и микроархитектурой, произведенные в Москве и в Зеленограде. Правда, по нормам от 180 до 500 нм.
JerleShannara
22.10.2021 15:10+1Но давайте будем честны: зайти на хабр в ветку с 1000 комментами и написать «я гордо пишу это с компьютера с отечественным процессором» при их использовании скорее всего получится слегка медленно и некомфортно, если вообще возможно.
amartology
22.10.2021 15:42+2А никто не говорил, что будет легко)
Кому очень надо гордиться — пусть гордятся тем, что есть. Кому надо, чтобы работало — пусть продолжают изготавливать чипы на Тайване.
checkpoint
22.10.2021 15:13А еще можно взять пару вёдер логики серии K155 и построить процессор на ней - вполне доступное, полностью отечественное решение. На чем там Эльбрус 3 был собран ? ;-)
JerleShannara
22.10.2021 15:55+1А что будет с моей ногой, если я его на неё уроню? Её потом врачи собрать смогут, или сразу в банку с тушенкой посоветуют запаковать? :)
checkpoint
22.10.2021 16:53+2Скорее у Вас будет другая проблема - не потеряться среди леса шкафов одного из шести АЛУ.
checkpoint
22.10.2021 15:05+4Для того, что бы процессор был сделан в России, в России нужно сначала построить фабрику по выпеканию кристаллов по современным тех процессам. Но для этого, во-первых нет такого количества денег (около $10 млрд на саму фабрику и еще столько же на заводики обеспечения размером поменьше), во-вторых, нет технологий - все оборудование импортное и под жестким контролем американцев, приобрести его не представляется возможным. Перед тем как построить фабрику, нужно еще решить вопрос с поставкой расходных материалов и программным обеспечением, все это тоже находится в руках наших западных партнёров. А еще перед этим нужно вырастить специалистов в этой области и сделать так, что бы они не сбежали на Запад до того, как фабрика будет построена и не умерли от старости. Иными словами, про процессор "сделанный в России" в ближайшие лет 30 можно смело забыть.
России нужно налаживать отношения с Западом и включаться в общий поток развития технологий, брать на себя какой-то небольшой участок этого необьятного процесса, двигать его вперед и коммитить результаты в общий котёл. Одной из таких тем, я считают, может быть разработка архитектуры и микроархитектуры RISC-V и высокопроизводительных процессоров на ней. Другой такой темой может быть разработка новых методов литографии (с использованием рентгена) и наладка серийного производства станков. В обеих темах у нас есть все шансы быть в авангарде и заслужить признание мировой общественности. Что в свою очередь приведет к более тесной интеграции и невозможности отрезать нас от мировых производителей и технологий производства. Нужно интегрироваться в мировое сообщество, а не отгораживаться от него со словами "сейчас мы наш православный процессор построим и тогда ух...".
amartology
22.10.2021 15:40про процессор «сделанный в России» в ближайшие лет 30 можно смело забыть.
Не «тридцать лет», а навсегда забыть. Микроэлектроника — глобализованная отрасль, что бы по этому поводу ни думали правительства России, США или Китая.Другой такой темой может быть разработка новых методов литографии (с использованием рентгена)
В смысле, заново изобрести EUV?checkpoint
22.10.2021 16:46В смысле, заново изобрести EUV?
EUV это "недорентген" (l=13.5нм). Сейчас идут дебаты по поводу использования более высоких частот с длиной волны до 6нм, что позволит производить структуры в несколько атомов. Там есть масса нерешенных задач, за которые можно взяться имея под собой хорошую финансовую опору и материальную базу. И даже в EUV тоже есть чем заниматься - тут недавно была статья про многослойные зеркала от некого корейца который на самом деле украинец работающий в китае.
Вот нашел статью в Nature, новая потенциальная технология называется Beyond-EUV (BEUV).
amartology
22.10.2021 17:27+3EUV это «недорентген» (l=13.5нм).
Рентген — это все, что имеет длину волны ниже 100 нм, а не ниже 10. EUV называют иначе в силу сложившихся исторических причин, а именно громкого провала ранних попыток создания рентгеновской литографии, подмочивших репутацию и уверенность инвесторов. Тем не менее, EUV — вполне себе рентгеновское излучение.новая потенциальная технология называется Beyond-EUV (BEUV).
BEUV — это не новая технология, а логическое развитие EUV, и нет никаких причин, по которым какие-то российские компании смогут внезапно преодолеть многолетнее отставание и опередить ASML или даже китайцев. В отличие от условий уважаемого koreec, никакими «неограниченными бюджетами» на такие исследования в России и не пахнет.
user2010
22.10.2021 19:05-2А какую сумму уже потратили? Воот! То, что вы озвучиваете, это не такая большая сумма, Китай просто.. Тихонечко скупает старое оборудование для литографии ... старые это 14н.
И спокойненько без шума налаживает производство! Если бы, извините .. этой конторы не было жуликов, то реально было у правительства на это деньги получить! Просто это вам не 40 лет лепить процессор, а потом оправдываться по производительности! Тут уже реально потребуют продукцию, а это работать надо! Если бы сейчас АРМ проц. не появились, еще лет 20 бы разрабатывали!
Am0ralist
23.10.2021 12:18+3А, вот и пришли пользователи, которые заявляют, что если абсолютно всё не было сделано в одно рыло, то и нечего вообще делать продукт. Видимо и картошку они копают так: вначале добывают руду и угль, для выплавки стали…
Civil
23.10.2021 12:32+1А, вот и пришли пользователи, которые заявляют, что если абсолютно всё не было сделано в одно рыло, то и нечего вообще делать продукт.
А человек такого нигде не заявлял. Это очень креативное искажение его слов.
Am0ralist
23.10.2021 12:42+1Правда? Ну то есть эпл не может гордится своими телефонами, которые были сделаны в Китае, например, потому что что?
А ведь ворота двигать можно будет всегда: поставишь фабрику — а станки то иностранные! Сделаешь станки — а сырьё то иностранное! И так вплоть до того, что все вещи внутри обязаны будут быть своими: и химические реактивы (что там было у самсунга и какими-то реактивами из Японии), и пластины, и все элементы станков, и все инженеры, и всё прочее. Ни у кого такого нет, а у тебя быть обязано будет. То, что куча контор без производства всего производит продукцию — просто игнорируется.
Это как в теме про центрифуги рассказывали, что это всё благодаря немцам.
Вместо внятных целей и возможностей их достичь сразу заявляется, что если финальную уже не достигли, то двигаться не имеет смысла.Civil
23.10.2021 13:03Правда?
Да. Человек заявил про "сделанный в России " не уточняя про сырье и так далее, поэтому не надо додумывать за него.
Соответственно остальной опус смысла не имеет
Am0ralist
23.10.2021 13:06+2Нет, человек заявил, что нельзя гордится ничем, пока не будет процессора, сделанного в России. То, что большая часть продукции подобной делается в международной кооперации — просто выбрасывается. Эти 146 млн должны быть круче, чем миллиарды вне. Причём сам он лично для этого не будет делать ничего.
Так что не имеют смысла именно опусы данных людей, которые стремятся обесценивать любые чужие достижения, классические токсики.
Люди могут сами выбирать, чем им гордиться, без попытки удовлетворить токсичность интернет ноунеймов.
user2010
24.10.2021 16:18-2Это только говорит о том, что я прав! Реально отвечать за готовые коробочки с процессором это конкретика которая лежит на столе!
А тыкать пальчиком в графики, и сравнивать мягкое с теплым, это наше всё!
Am0ralist
26.10.2021 16:09+3Ну так всякие эльбрусы 8с и 8св — это уже то, что реально лежит на столе, а вот ваши
вопливысказывания в интернетике — это не про «реально отвечать» за что либо.
Но ваша цель, повторюсь, была только набрасывать, что раз типа сразу из коробки не всё своё, то двигаться никуда не надо. Тогда как окружающий мир показывает, что только двигаясь куда-либо можно куда-то прийти. А если лежать на диване и критиковать — то точно никуда не попадёшь.user2010
27.10.2021 11:45Все у вас красиво звучит, если бы не более 40 лет и миллиардов денег! За наш счет!!!
POPSuL
22.10.2021 17:05Это все конечно классно, супер, вы молодцы! Но где тестовые платы за адекватные деньги для того, чтобы потестить?
И я не про продакшн варианты, а про образцы ну не за 100к как с остальными эльбрусами... Для обычных людей :)
edo1h
31.10.2021 17:12+2статья хорошая, решения описываются интересные.
но я так и остаюсь при своём мнении: vliw не нужен.dzavalishin Автор
09.11.2021 18:57-1Покупайте процессоры Мультиклет. Оригинальная Российская архитектура с традиционной длиной команды.
amartology
Люблю такое очень, когда сначала говорят, что
А абзацем позже выясняется, что по факту
А вообще отличная статья, спасибо большое!
rstepanov
наверное просто нет смысла писать вирусы для Эльбруса?
dzavalishin Автор
Ок, я переформулирую. Множество известных сценариев взлома кода на Эльбрусе нереализуемо.
Что касается смысла - stuxnet был написан для поражения одного конкретного противника.
На Э2К работает, в частности, одна из ключевых федеральных систем РФ - паспорта. Я бы не счёл нулевой вероятность появления заказчика на её взлом.
unv_unv
Только вот взлом можно делать не только посредством взлома на уровне кода. Гораздо эффективнее, подчас, взламывать людей. Нужен всего-то системный администратор, который выполнит нужную последовательность действий — и защита на уровне процессора от этого не защитит. Что не означает, конечно, что такой защиты быть не должно.
qw1
Ведь что такое традиционный вирус? Программа, которая ищет на диске исполняемые файлы и «заражает» их — дописывает свой код, корректируя служебные структуры. Как тут может помешать защита Эльбруса? Да никак.
В бытовом значении сейчас вирусами называют бэкдоры и боты: вредоносное ПО, работающее без разрешения владельца системы. И тут защита Эльбруса тоже никак не помогает. Это чаще всего отдельный исполняемый модуль, скомпилированный по всем правилам, как любая другая программа.
Что хотел сказать автор? Защита есть от некоторых эксплойтов, а именно направленных на разрушение памяти. Но это лишь небольшая часть всех эксплойтов, т.к. есть ещё SQL (и прочие) инъекции, дыры в конфигурировании доступа, баги на уровне логики приложения. Это всё будет работать, как и в любой другой архитектуре.
qw1
На всякий случай, я это прочитал как «большинство вирусных технологий, работающих на x86».
Или может автор буквально хотел сказать «большинство вирусов», как скомпилированных под другую архитектуру, а значит имел ввиду эффект «неуловимого джо»?
dzavalishin Автор
Извините. Это причёсанный транскрипт выступления, он неидеален, я согласен.
Вы правы.
dzavalishin Автор
Разве тут есть противоречие?
amartology
На вид — есть. Текст выглядит как «вот куча возможностей по защите, но на практике использовать их нельзя, потому что в таком режиме нельзя собрать линукс». Если это на самом деле не так, то этот пункт стоило бы раскрыть поподробнее. Тема защищенности Эльбруса и его преимуществ над x86 в этом отношении довольно животрепещущая.
Особенно интересует, есть ли разница в том, как происходит защита в нативных приложениях и в транслированных.