Комментарии 93
Архитектура «Эльбрус‑Б» построена на принципе параллельных вычислений. Она включает аппаратную часть, язык программирования и операционную систему. Система позволяет выполнять много задач одновременно.
Процессор, сделанный по технологии 90 нм, по мощности будет сопоставим с чипами, созданными по нормам 14 нм. На технологии 5 нм «Эльбрус‑Б», по словам разработчиков, станет недосягаем для других архитектур.
Как говорили классики: "Генерировать устный поток сознания — не кирпичи на стройке перекладывать".
А мне думается, что зря Вы так негативно. Если долго мучиться, то получится что-то и когда-то.
Тут может просто журналист виноват. Эльбрусы же на VLIW, речь скорее всего про это
Я просто в шоке от операционной системы, позволяющей выполнять много задач одновременно. Всю жизнь о таком мечтал, думал не доживу уж...
Тут речь не про многозадачность ОС, а про реально параллельное выполнение инструкций одним "ядром" процессора.
Streaming SIMD Extensions? Проблем с поддержкой ОС нет, да и надо только сохранение регистров при переключении контекста. Или интеграция GPU? С этим тоже проблем нет.
Это один из самых первых подходов получить больше параллелизма, но есть недостатки: они помогают только в узкоспециализированных случаях; надо писать интринсики, либо с трудом добиваться автовекторизации; сложно переносить на машину с другим размером вектора; и др.
>надо только сохранение регистров при переключении контекста
"контекст свич" позволяет создавать иллюзию многопоточности, а не саму многопоточность.
Тогда причём здесь операционная система?
Там смысл в том, что параллельность операций описана прямо команде явно и определяется на этапе компиляции, а не обеспечивается процессором в рантайме на основе предвыборки и предсказаний переходов.
Так происходит в VLIW, а тут идея в том чтобы загружать в процессор некий «набор операций», который описывает абстрактный параллелизм, но не то как его исполнять. А процессор («загрузчик») уже до-компилирует его в свои низкоуровневые инструкции.
собственно "набор операций" над чем?
как-то напоминает архитектуру ранних Эльбрусов, типа безадресные операции над стеком реализованные как микро операции над регистрами, если не изменяет память,
ключевой момент что именно под набором операций имеется в виду, пока это не определено, как на картинке есть только абстрактные алгоритмы и теги, обсуждать собственно нечего
Так Баяну-Бабаяну уже 91 год. Через пару лет, глядишь, ишак помрёт или падишах.
вот вы и генерите. причем довольно коряво. классики так не говорили.
Новая архитектура будет использовать язык программирования «Эль-22».
А есть какая-нибудь информация про этот язык? Судя по названию, ему уже 3 года, а гугл находит только такие пивные напитки.
Отличных калош? - Ах, те, что ты выслал. На прошлой неделе, Мы давно уже съели. И ждем, не дождемся, Когда же ты снова пришлешь...
Какая энергоэффективность ожидается, интересно? При заявленной производительности на 90нм техпроцессе он мб будет 300w в среднем кушать, что, с учетом ещё охлаждения, может быть многовато
По ссылке речь не про скорость, а про мощность. "Архитектура параллельной системы позволяет обеспечить мощность в 30-200 раз большую, чем зарубежные аналоги на аналогичных технологических нормах." Если хорошо постараться, наверно, можно создать процессор, который будет потреблять в десятки раз больше мощности, чем зарубежные аналоги.
мощность в 30-200 раз большую, чем зарубежные аналоги
Разве что потребляемую мощность...
...
Короче: "дайте денег".
По тексту похоже на очередной распил со вкусом Роснано, но с другой стороны Бабаян...
Архитектура «Эльбрус‑Б» построена на принципе параллельных вычислений. Она включает аппаратную часть, язык программирования и операционную систему. Система позволяет выполнять много задач одновременно. Это и дает прирост в производительности.
Звучит как задача уровня сразу нескольких корпораций.
Во-во, это главная проблема МЦСТ - вместо того чтобы делать консорциум, комитет по разивтию архитектуры, может быть - лицензировать ядра, обучать программированию под Эльбрус, поддерживать open-source сообщество в портировании софта - они там мелкой лавочкой пилят все - и железо и компилятор и ОС, чего в целом даже IBM не очень по силам.
В результате - ничего.
Те, кто вложился в Байкал-S - могут найти ARM других производителей, те кто вложился в Эльбрус - могут только ждать, потому что партии распроданы и больше ничего не будет.
МЦСТ не имеет отношения к этому Эльбрусу.
Как это так может быть?
http://www.mcst.ru/chips?f[0]=field_availability%3A33
Всегда во всех интервью именно представители МЦСТ заявляли что они делают Эльбрус.
У меня странное чувство, будто я перестал понимать русский язык.
По словам разработчиков, новая архитектура будет быстрее иностранных аналогов в 30–200 раз.
Так всё-таки в 30 или в 200? Не решили ещё? И по какому критерию устанавливается "аналогичность", если разница в производительности 200 раз? По техпроцессу, по стоимости?
Процессор, сделанный по технологии 90 нм, по мощности будет сопоставим с чипами, созданными по нормам 14 нм. На технологии 5 нм «Эльбрус‑Б», по словам разработчиков, станет недосягаем для других архитектур.
По тепловой мощности, да? Так сопоставим или в 200 раз быстрее? И по какому техпроцессу планируется производство? Потому как мне кажется, 90нм и 5нм это немножко разные процессоры.
Так всё-таки в 30 или в 200? Не решили ещё?
Сделали новую бомбу. После испытаний докладывают:
- Мощность взрыва от 10 до 100 килотонн.
- А почему разброс-то такой большой?
- Ну, мы сначала подумали 10 килотонн, а оно каааак бахнет!!!
ну, давайте с точки зрения языка вам отвечу:
"30-200" - таким образом, обычно, задают диапазон. Читается как "от 30 до 200" . Есть некоторое множество задач и если вот их замерить, то в худшем случае они быстрее в 30 раз, в лучшем в 200.
Ну и в первом сообщении говорится о скорости, а во втором о мощности. Так что ваш вопрос странный.
Плюс вам прямым текстом говорят, что делать его будут на 90 нм (так как других нет), но вот если бы, в теории, его можно было сделать на 5 нм TSMC , то вот тут да, это был бы лучший процессор в истории человечества с огромным отрывом.
По всему остальному ответить не могу, так как там уже обороты. И что там за быстрота не очень понятно и что считают аналогом (может IBM Cell из PS3 - на старте он был 90 нм и архитектура схожа с VLIW) и о какой мощности речь (может о тепловой, может ещё о какой), вот это всё не очень понятно.
Впрочем, о том, что эльбрус лучше всех и вот-вот всех переиграет и уничтожит, надо только подождать, мы уже лет 30 слышим, правда никто толком этих процессоров не видел, а видевшие не особо впечатлились
Я вот свой не дождался.
мы уже лет 30 слышим
Вот если бы E2K профинансировали в 1999, то он бы выглядел неплохо для своего времени. А сейчас такая архитектура не актульна.
К слову, просили тогда совсем ничего - 40 миллионов баксов.
"архитектура схожа с VLIW" - сходств чуть менее чем нисколько. IBM Cell - это чистый RISC-CPU с нормальными PPC инструкциями общего назначения. VLIW же на десктопе - это абсолютное уродство, и тупиковая архитектура.
И в чем уродство?
1) Сложность для компиляции. Для крошечных DSP кернелов не критично.
2) Большой объём кода. Оверхед при упаковке в ШК.
3) Медленно. Десктопный софт ветвистый со нерегулярным паттерном обращения в память. Это строго противоположно оптимальной программе для VLIW - статическое планированные циклы с линейным доступом в память.
4) Необходимость пересборки софта под каждый новый процессор.
Из-за статического планирования, код создаётся под конфигурацию/латентности конкретного чипа.
А для ДСП оверхэд не критичен? В дсп то памяти дохрена, не знают куда девать.
Все остальные аргументы отражают реальность примерно так же (никак):
Любой суперскаляр без предсказателя или с плохим предсказателем будет захлебываться на лапшекоде. То есть это не проблема VLIW
Любой новый интел что бы использовать все его новые возможности, требует сборки специально под него. Но никто этого не делает потому как у бедного школьника из уганды с pentium dual-core не будет возможности пользоваться свободным ПО вроде дебиана. А это не допустимо, поэтому сборка софта ведется под дженерик архитектуру с минимумом расширений. Что бы обойти такие ограничения программы типа libavc или 7z используют автодетект набора инструкций и вызывают оптимизированные под тот или иной набор функции, почему для vliw нельзя то же самое - непонятно.
Ну и да код от всех этих функций знатно распухает, в том же ffmpeg может достигать +100мб. Так же он распухает когда пишешь производительный код на интел и компиляторы пытаются разворачивать циклы потому что это как бы дает лучшее ускорение обработки данных. В то же время на эльбрусе компилятор наоборот пытается свернуть цикл в как можно меньшее количество команд на итерацию (в идеале - в одну) т.к. у эльбруса есть аппаратная поддержка циклов которая автоматом развернет эту команду на всю длину конвейера, таким образом получается наоборот vliw способствует лучшей компактности для производительного когда и в отличии от того что выше это именно заслуга vliw так как широкая команда позволяет подпихнуть в нее что угодно, и таким образом подсказать фронтенду в рантайме что происходит в потоке.
Ну а что касается реальных проблем эльбруса (не vliw):
Это в первую очередь защищеные стеки которые обеспечивают ему с одной стороны хорошую контекстную безопасность, так вот ломануть эльбрус как сломали PS2 не выйдет, с другой стороны она оборачиваются нагрузкой на ядро через системные вызовы если приложение что то хочет делать со своим стеком. Это довольно таки неприятный момент для виртуальных машин.
Другая проблема эльбруса, которая вроде как будет частично решена - это прокачка данных в кэш. Неважно насколько классно и плотно удалось натромбовать широкие команды, даже на всю ширину векторов, если цикл использует лоад/стор то это приговор для производительности. Даже обычное скалярное побайтовое последовательное сложение+умножение с подкачкой данных через array-префетчер уделает вот те команды на самом же эльбрусе раза так в четыре. Но арей-префетчер можно использовать только в конвейризованых циклах и с выравненными массивами, а другой подкачки на эльбрусе просто нет.
В седьмой версии вроде как завезут и бранчпредиктор для лапшекода и префетчер, и останется проблема только с безопасными стеками и как их подружить с прикладным ПО.Ну а конкретно с VLIW подходом проблем нету никаких вообще, программы компилируются и работают, все как на любом обычном процессоре.
Я понимаю что есть еще обширные теоритические притензии, мол вся вот эта куча устройств с конвеерами большую часть времени тупо стоит, и это мол неэффективное использование а на интеле хоть их и два-три зато они постоянно в работе, но тут нужно какое то научное исследование о том насколько это действительно обосновано так с точки зрения трудозатрат и конечной энергоэффективности.
Как мы знаем из нашей истории инженер Глушко выбрал многокамерную схему ракетных двигателей потому что в четырех маленьких камерах проще добиться стабильности горения чем в одной большой, и не прогадал хотя это вроде как неэффективно с точки зрения удельного веса и всего такого. Другой пример - центрифуги для обогощения урана. Чем больше (выше/толще) центрифуга тем лучше производительность и эффективней резделение изотопов, однако современные росатомовские центрифуги размером с пятилитровый термос, потому что это упрощает их обслуживание их раскрутку до высоких скоростей итд. итп. Так что эффективность в теории ничего не стоит.
А для ДСП оверхэд не критичен? В дсп то памяти дохрена, не знают куда девать.
Не критичен. Там обычно крошечные циклы, которые долго вылизывают.
Все остальные аргументы отражают реальность примерно так же (никак):
Всё что я написал - общеизвестно. Потому от VLIW все, кому надо запускать код общего назначения, уже отказались.
Любой суперскаляр без предсказателя или с плохим предсказателем будет захлебываться на лапшекоде. То есть это не проблема VLIW
Не так как VLIW. К суперскаляру прикрутить предсказатель несложно.
Вы курсе, в какой версии архитектуры Эльбруса они смогли прикрутить предсказатель, и как хорошо он работает?
Любой новый интел что бы использовать все его новые возможности, требует сборки специально под него.
Я не говорю про новые возможности. Я говорю про ускорение вследствие эффективного использования новых исполнительных устройств / снижения латентностей. Для VLIW программы просто не будут быстрее. Разве что только за счёт повышения частоты. Не получится увеличить количество ALU и рассчитывать на ускорение. Когда человек купил PII-233МГц вместо Пентиума MMX233, он мог рассчитывать на значительное ускорение за счёт ОоО, а не частоты.
т.к. у эльбруса есть аппаратная поддержка циклов которая автоматом развернет эту команду на всю длину конвейера
OoO движок делает это лучше и проще. Раскрытие циклов упрощает код и уменьшает т.о. количество тактов в каждой итерации.
Аппаратная поддержка циклов / вращающиеся регистры это ненужная сложность, вызывающая излишнюю головную боль.
о арей-префетчер можно использовать только в конвейризованых циклах и с выравненными массивами, а другой подкачки на эльбрусе просто нет.
Современные ядра настолько продвинулись в вопросе авто-префетча, что от ручной линейный префетч это каменный век.
а на интеле хоть их и два-три зато они постоянно в работе
Уже давно не 2-3. Впрочем Интел не является хорошим примером.
https://drive.google.com/drive/folders/1-Ls0SiqXBCBhMGr87ldA_47GETWfjCzQ
M4 может выполнить 19 микроопераций за такт.
но тут нужно какое то научное исследование о том насколько это действительно обосновано так с точки зрения трудозатрат и конечной энергоэффективности.
Мало кого ваши теоретические изыски взволнуют, тогда как лучшее обоснование это скорость выполнения программ.
Общеизвестно что страус прячет голову в песок, хотя в реальности страус никогда так не делает.
Вы курсе, в какой версии архитектуры Эльбруса они смогли прикрутить предсказатель, и как хорошо он работает?
Я в курсе. Предсказатель в эльбрус не стали вводить просто потому что Бабаян их не любит. Кстати в обозначеном Эльбрусе-Б так же никакого предсказателя не предполагается. В целом микроархитектура эльбруса от Бабаяновского концепта стала отходить только с 8СВ опираясь уже не на убеждения создателя, а на реальные задачи.
Но причина нелюбви г-на Бабаяна к предсказателям в том, что это по большому счету костыль пытающийся спасти конвеер от простоев. Единственный показатель его эффективности это количество ошибочности предсказаний на N запусков, и чем меньше он обсирается тем как бы лучше, но не ошибаться он не умеет и ускорять он ничего не ускоряет.
Реальная эксплуатация эльбруса показала что подготовки переходов очень хороши, но их всего три и у каждого есть еще своя специализация, например только ctpr2 умеет делать те самые конвейризованые циклы и когда оно используется, нельзя переключать конвееры, поэтому часто можно увидеть в таких циклах используется непосредственный переход типа ibranch. ну а если в коде нет пространства для подготовок (лапшекод) то вот эти подготовки начинают играть в минус, так как занимают две команды вместо одного перехода/вызова и все это плюсом к штрафу конвеера.
Теперь у каждой подготовленной команды будет непосредственный аналог - icall iret ibranch с возможностью условного исполнения и предсказанием, что позволит во первых исполнять обычные циклы с возвратом и лапшевызовами примерно с эффективностью на уровне арм/интел, А во вторых подготовки никуда не делись и бранчпредиктору не надо будет предсказывать такие сложные вещи как возможный возврат из цикла в предыдущую процедуру (если конечно компилятор справится). Интел же возвраты откуда угодно делать не умеет ему надо прыгать в конец процедуры к команде ret, а бранчпредиктору надо предсказывать три возможные путя на каждой итерации.
Но как это все в реальности покажут только реальные тесты реальных процессоров, которых еще нет в железе, поэтому говорить о том как это работает рановато.
Уже давно не 2-3. Впрочем Интел не является хорошим примером.
M4 может выполнить 19 микроопераций за такт.
Обращаю внимание что на блок-схеме отсутствует классический re-order buffer и переименование регистров (обязательный атрибут OoO), вместо них некая очередь с таблицей переотображения регистров.
Я полагаю работает это так:
1) микрокод декодирует 19 команд и распределяет их по ячейкам (как в ШК) так как у процессора нет общего планировщика, а определенный тип операций должен как то попасть на свое устройство.
2) На следующем такте (или скорей всего на 6-9ом) это все доходит до передачи в конвейер устройств. Так как целочисленная и вещественная+векторная группа алу подключены к своим регистровым файлам нужна таблица переназначения регистров которая работает похожим на базированные регистры эльбруса образом.
3) Если для микроопа не готовы аргументы тогда ШК с застрявшими в ней микроопом едет на длинный круг в +10 тактов. Всего в очереди 19 широких команд (361=19шк*19моп).
Так же бросается в глаза что у M4 аж три устройства перехода, в их наличии нет никакого практического смысла кроме одного - выполнить три перехода под условиями. Как раз подходит для вышеописанной ситуации с выходом из цикла и тремя вариантами выхода перехода.
Это конечно не похоже эльбрус, но зато похоже на
к которому прикрутили фронтенд. И эпл тут далеко не первопроходец так как уже был NVIDIA Denver с похожими решениями.
В любом случае мы видим живой пример как эпл с 2012г пыталсясь создать свой OoO суперскаляр (на первых блок схемах буфер перестановки есть) сделал в итоге VLIW-подобие без этих ваших сложных аппаратных механизмов.
Предсказатель в эльбрус не стали вводить просто потому что Бабаян их не любит.
Так себе аргумент, ведь Бабаян ушёл в 2004г.
чем меньше он обсирается тем как бы лучше, но не ошибаться он не умеет и ускорять он ничего не ускоряет.
Разумеется не умеет, ведь тогда бы он назывался не "предсказатель", а "пророк". Предсказатель уменьшает количество сбросов конвейера, поэтому он непосредственно ускоряет выполнение программ. Эффективность современных предсказателей превышает 99%
Реальная эксплуатация эльбруса показала что подготовки переходов очень хороши
Реальная эксплуатация эльбруса показала что толку от такого решения мало. Ручное предсказание как в эльбрусе работает только с коротким конвейером. т.е. с очень низкими частотами. В SPU с 28-стадийным конвейером, предсказатель надо было готовить за ~15 команд. Естественно работало это только с длительными циклами и ни о каких переходах внутри цикла речи не шло. Кстати по сложности наполнения слотов, SPU был подобен VLIW-у.
нИнтел же возвраты откуда угодно делать не умеет ему надо прыгать в конец процедуры к команде
ret
Не вижу в этом смысла. Согласно х86 ABI, нужно поправить стековый фрейм. А ещё там есть аппаратный стек адресов возврата, для корректного предсказания.
Обращаю внимание что на блок-схеме отсутствует классический re-order buffer и переименование регистров (обязательный атрибут OoO),
Классический механизм был на предыдущих ядрах. Я ещё не разбирался что поменяли. Но судя по значительно возвросшей производительности, поменяли в лучшую сторону.
три устройства перехода, в их наличии нет никакого практического смысла кроме одного - выполнить три перехода под условиями
Практически смысл очень простой - по статистике в современном коде условие идёт каждые 2-3 команды. При 10 командах за такт, то на то и выходит.
Это конечно не похоже эльбрус, но зато похоже на
В каком месте? Вообше ничего общего. Динамическое распредение из ROB, против статического распределения во VLIW.
на первых блок схемах буфер перестановки есть) сделал в итоге VLIW-подобие без этих ваших сложных аппаратных механизмов.
ROB никуда не делся. Сложные аппаратные механизмы никуда не делись. Микро/макрофьюжен никуда не делся.
Согласно х86 ABI, нужно поправить стековый фрейм
Классно, правим адрес на стеке и у нас процессор из процедуры возвращается это так по вашему работает?
Сложные аппаратные механизмы никуда не делись. Микро/макрофьюжен никуда не делся.
Все есть только вот планировщика нет и кто распределяет инструкции по устройствам - непонятно, а то что у "ROB-а" ровно столько же (19) входов-выходов за такт это конечно же совпадение.
А если серьезно то этот "ROB" это конвеер на птицефабрике - по конвееру катаются коробки для яиц, женщина-декодер их фасует, на другом конце их вместо того что бы просто грузить в газель (как на vliw) перегружают в другую тару по номерам, и если каким то место не нашлось они уезжают на повторный круг и так пока аргументы не подготовятся. Тут другого варианта просто не придумать, все упирается в отсутствие общего планировщика.
Это нынче такой трэнд духоподъемный в РФ - больше, выше, сильнее и тд. Прошлый глава Роскоса например обещал многоразовую ракету с многоразовостью в 100ни запусков не имея пока ничего. Космический X вроде достиг пока максимум 24 запуская иногда по 3-5 в неделю.
Система позволяет выполнять много задач одновременно. Это и дает прирост в производительности.
Мой старый-старый ноут всегда умел много несколько задач...
Судя по всему, это развитие идей:
статьи известные, но что за развитие понять пока трудно, больше общие слова
берешь ALC эльбруса распиливаешь их на отдельные, каждому даешь свой небольшой локальный регистровый файл получаются отдельные кластеры, которые в отличии от эльбруса обычного могут работать асинхронно так как нет широкой команды.
ALC это вероятно advance loop counter?
какой в этом смысл из одной команды сделать несколько, и почему именно ALC?
как синхронизация между кластерами устроена?
Будет интересно посмотреть. Главное, чтобы не получился очередной аналоговнет
Учитывая, что Борису Бабаяну больше 90 лет, в Intel он, наверное, в этот раз не сбежит... хотя, его сын Евгений - молодой (и 70 нет)...
Думаю это все для какого-то специфичного класса задач - типа нейросетей. Но для этих задач CPU никто и не использует, а видеокарты и так в сотни раз быстрее CPU.
А в целом - наверное хорошо как иссследовательский проект, но коммерческих перспектив у этого я не вижу - они даже с Эльбрусом облажались.
Хотят изобрести Мультиклет?
Если выражаться цензурно - то это отборная бредятина. Вообще, за такие презентации от советника Ростеха имеет смысл за профпригодность спросить. Иначе второй вариант - это уже где-то в районе статьи за мошенничество.
Я вот не понял, постами на хабре уже перед начальством уже отчитываются, за потраченные свободноконвертируемые?
Хороший стендап и доклады весёлые
Анекдот: решил как то старый армянин самый лучший процессор сделать, но денег не было. Видит - русские идут..
это от создателей ёмобиль?
20 лет назад он уже предал Эльбрус, сбежав в Интел...
Сейчас он хочет обманом перетянуть финансирование на себя отняв его у Эльбруса...
Предавший однажды -- предаст снова.
Да они похоже просто GPU собрались отечественный запилить да и всё. Отсюда "быстрее чем CPU в 200 раз"
Сооснователь МЦСТ озвучил планы выпуска российского процессора на архитектуре «Эльбрус-Б» к 2027 году