Никто у него ничего не забирал, грядущий пашин телеграмм еще помню заглушки во вконтакте рекламировали. Дуров всегда был в тренде технологий и видел как развиваются групповые защищенные меcсенджеры вроде Tox, GNU Ring, конечно же ватсап iMessage и Google Talk всеми забытые. Он видел что время соцсетей прошло и перепрыгнул из одного поезда в другой.
Что касается вконтакта, никогда им не пользовался так как там и при благословенном паше были дебильные правила про то что на профиль можно вешать только свои фотографии а потом и регистрацию по телефону, в данный момент вконтакт убивает то, что менеджмент компании ВК начал стрелять себе в ноги борясь со старыми пользователями ВК заливавшими аниму и прочий контент в рамках своих групп, все ради того что бы сделать из платформы аналог ютуба. По мимо этого еще схватились за аналог твича, аналог стима и игровой движок. В итоге толком не получилось ни того ни другого ни третьего, хотя аналог стима и твича вполне могли бы потянуть. Соцсеть с группами и видеоплатформой есть, надо было только стриминговый сервис и магазин сделать и интегрировать их в соцсеть, но в руководстве ВК похоже сказочно некомпетентные люди.
Компилятор при том, что именно он достает лоад из под проверки, нарушает порядок его исполнения и все вот это, именно он создает уязвимую ситуацию. В интеле же компилятор выдает правильный порядок, который уже нарушает само железо своим спекулятивным исполнением. В первом случае эльбрус не может ничего сделать, он понятия не имеет о первоначальной последовательности и просто исполняет то что дают, во втором компилятор никак не может запретить процессору менять порядок.
Поэтому и нельзя это считать полноценной аппаратной уязвимостью, максимум программно-аппаратной, и то в процессоре предусмотрены механизмы защиты, но именно софт их по разным причинам не использует.
Что касается васи хакера, то он конечно может много чего неприятного собрать подсунуть, например OpenSSL старой версии, но если компилятор начнет выявлять и закрывать/обходить такие грабли, то что вася-хакер с этим поделает? Не ну конечно может старым "дырявым" собирать тоже, да.
В эльбрусе нет предсказателя ветвлений, есть условное исполнение и подготовка ветвлений которые грузятся в конвеер, но реально не выполняются. В будущих процессорах предсказатель будет, интересно будет посмотреть работает ли в нем описываемая вами атака связанная с неверным предсказанием и возможным спекулятивным исполнением кода в нем. Если это будет работать это будет первая аппаратная уязвимость.
Текущая же демонстрирует скорей уязвимость софта (компилятора). А раз так то какие то ситуации компилятор мог бы и отлавливать.
-fno-control-spec Отключить механизм спекулятивности по управлению и по данным на фазе if_conv
Эта опция, насколько я понимаю отключает и спекулятивные загрузки и спекулятивные операции вроде деления на ноль.
-fcontrol-spec Запретить использование спекулятивных обращений в память -fno-dam Отключить DAM - аппаратный механизм разрешения конфликтов по чтению-записи
А вот эти две опции отключают конкретно механизм спекулятивного обращения в память. DAM это тоже какой то буфер хранящий адреса, нужен он только при спекулятивном обращении в память, лучше тоже отключать вместе с ним.
так то оно так, но в них входят 32 однобитных предиката ( тоже с тегами но сколько битов на каждый я не могу сказать), поэтому все таки 192 общих-числовых.
Есть ли там дублирование на 2 физических регистровых файла для каждого кластера я точно сказать не могу.
Убрали кластеры, об этом есть как устные разъяснения мцст (вроде бы применили кастомный дизайн блоков регистровых файлов), так и обзор спила кристала от House of что-то там, где видно что кластеров больше нет.
В общем я о чем - 64 битная часть в регистрах полноценная, к старшей и младшей части можно обращаться через одинарное представление любыми операциями, а +16битное расширение (превращающее его в 80и битный), к нему никак отдельно обратится нельзя, оно строго для умножения 64битных с переполнением и 80и битной вещественной арифметики. Что то мне подсказывает что в 8СВ вот это расширение регистра с конотацией %xr просто увеличили до [64 [32 32]] засчет того что убрали лишний кластер освободив кучу места при том же техпроцессе и размере кристала. Но есть так же предположение что в 16С все таки сделали полноценный четверной регистр, на это косвенно указывает новая коннотация %qr иначе какоеоно квадро если не сплитуется на четыре одинарных.
Так то в эльбрусе 192 регистра в регистровом файле + 32 предикатов в предикатном файле + 32 глобальных.
регистровые файлы продублированы в кластерах и технически там 448 регистров.
Помимо этого согласно документации каждый %dr0 делится на %r0 и %r1 (hi и lo часть), так что субъективно там 448 32битных регистра в одном кластере.
Со 128и битными %qr не очень понятно, они сплитуются так же или там нижняя часть это %dr регистр а старшая отдельно и используется только с векторными устройствами. Но может быть сплитуются все, тогда в современных эльбрусах получается аж 856 32битных регистра в локальной части и еще 128 в глобальной. Хотя в одной процедуре все равно можно использовать только 120.
Противопоставляете утверждением о том что компилятор всегда исходит из писсимистичных сценариев, а вот мол процессор то в динамике больше видит.
Ну так и что из того что он видит? Он не может внести в код изменений на лету как тот же JIT, который как раз использует профилировку и налету перекомпилирует участки кода.
Процессор занимается своими задачами, он не может с кодом программы ничего сделать кроме как грузить и исполнять. Единственное что он может себе позволить из оптимизаций это в наглую попытаться разорвать лютую зависимости и поиметь профит, и этот "профит" проиграет хорошо оптимизированному коду всего в 5-10 раз, а не в 20-40 как на эльбрусе например.
В качественном коде и качественном компиляторе нуждаются абсолютно все. Эльбрус, как и другие vliw процессоры, выделяет то что они крайне чувствительны к качеству кода который компилятор выдает специально для них. Об этом всегда и были разговоры, мол это требует совершенно других компиляторов (в том числе JIT) что просто ведет платформу в условный тупик. Когда оно мутировало в то что чуть ли не в железе все оптимизации происходят у внеочередных суперскалярах я не понимаю.
Профилировка помогает не исходить из писсимистичных либо оптимистичных сценариев, а вырабатывать конкретную стратегию по оптимизациями на основе обрабатываемых данных. Вполне универсальный инструмент, который используется не только в компиляторах но и в кодировании видео.
Только лишь статическое планирование -- это путь к пессимистическим прогнозам и потерянной эффективности.
Для этого есть профилировка и подсказки компилятору ( inlinerestrictconstexpr pragma итд). Динамическое планирование внутри процессора и оптимизация кода компилятором это совершенно разные задачи - динамический фронтенд не видит всей программы/процедуры у него нет на это ни ресурсов ни времен, он работает строго в маленьком окошке c пачкой команд которые ему нужно максимально эффективно расставить как в параллель так и в очередь. Он при всем желании не может заменить компилятор (ни статический, ни JIT) не нужно их противопоставлять.
Антогонистом динамике процессора является не компилятор, а большая структурированная супер-команда (ШК) в которой заранее все можно распланировать в ширь и в очередь, процессору остается только декодировать все это дело.
Плюсы и минусы есть у обоих подходов. Например жирные эльбрусовские команды со всем вот этим закодированным в них барахлом прилично отъедают кэш, а у интела/арма команды деленые+компактные и кэш занимают по минимуму. С другой стороны в эльбрусовскую ШК можно впихнуть что угодно например метки о том что код/данные следует закачать в L2, интелу-арму для этого придется добавлять новые инструкции вроде префетчера. ШК требует полной синхронизации портов/каналов исполнения, тогда как в суперскаляре порты работают асинхронно. С другой стороны ШК позволяет из простого последовательного процессора недорого получить производительность уровня внеочередного процессора, пусть может не на всех задачах, но зато и без аппаратных уязвимостей.
В общем тут ворпрос уровня cmake vs cargo, ниразу не однозначный и на любой аргумент можно привести контраргумент (а то и не один).
это архитектура, в которой несколько инструкций упаковываются в одно длинное машинное слово, выполняемое процессором за один такт.
Просто несколько risc-инструкций (компилятором) засовываются в одну длинную инструкцию что позволяет их за один такт считывать, но они не исполняются за один такт.
Все инструкции в таком пакете выполняются параллельно, что позволяет значительно повысить производительность
Повысить по сравнению с чем? Если по сравнению с голыми последовательными процессорами - да, а суперскаляры тоже исполняют инструкции параллельно и по сравнению с ними однозначно можно говорить только про более лучшую энергоэффективность.
Сначала навалим на неких абстрактных "айтишников" плюшек в виде отсрочек от службы и льготных ипотек (что может пойти не так?), а потом спустя 3 года займемся проверкой а действительно ли числящиеся по штату "айтишники" имеют отношение к айти специальностям.
Вроде как бы принято говорить что лучше поздно чем никогда, но как то не хочется. Проблема то все равно останется
выдавать патроны за помаду это плохой путь. Да компьютер особо не скрывает что военный, и выпускает его ... МГТУ Имени Баумана, просто а почему бы и нет? Почему бы ПТУ №6 не заказать на таиване чипы и тоже не собирать что нибудь.
Проблема не в кодировке отдельных инструкций а в структуре ШК как видно какие то люди поднапряглись и разобрали структуру чтоб сделать эмулятор в QEMU. Подчеркиваю это не список команд а описание структуры блоков из которых может состоять широкая команда (и какие в ней предусмотрены атрибуты для микрокоманд). И все это актуально только для архитектуры v4 и то я не вижу описания %xrN регистров (80 битные расширения), очевидно потому что разбирающий не встречал кода с ними, а таких штук там вагон.
какие то из команд могли стать уже легаси и на их место в v7 вставили что-то другое.
Бабаян сам говорил что примерно в том же году дейв дицел привез в институт микропроцессор UltraSpark и там было транзисторов больше чем в шкафу на фоне которого они с этим процессором сфотографировались. Этим Шкафом был Эльбрус-3 и смысла с ним возится небыло, надо было осваивать новые технологии проектирования микропроцессоров, чем они и занялись под вывеской МЦСТ.
Сделали бы для начала простую генерацию субтитров из аудиодорожки. Что бы любой любительский перевод или дубляж можно было получить в виде .srt или даже .ass.
А если кому то надо перевод, то переводить текст всяко проще чем аудио налету. Короче пока выглядит как слишком замороченный костыль который если даже доделают, им все равно никто не будет пользоваться.
И при этом он говорит что провальная ССБИС была нужна, а эльбрус-3 нет. У первой (неограниченное) финансирование забрали, а у второй все было в порядке, просто бабаян не довел.
В любом случае не хочу спорить о персооналиях и их личных обидах/неприязни друг к другу. Приведенная в оп-посте статья прекрасно ставит все на свои места, госкомиссия поставила планку достичь 10гигафлопс, 10 процессорный эльбрус-2 выдавал 2Гфлопс (200мфлопс на процессор), векторные сопроцессоры позволяли ускорять только спецзадачи. Госкомиссия заняла сторону Э-3, а Бурцев проиграв ушел в другую организацию. Спустя 20 лет госкомисси таки сдадут эльбрус-3М1 выдающий 7.5Гфлопс, а "замечательные решения" ссбис аж трех поколений даже на fpga не покажут. Хоть это и не проект Бурцева, но он тем не менее зачекм то его защищал.
Ну и черту в вопросе провел Терехов, ИТМиВТ на статический подход перешло не только из за интересных разработок на западе, но и из за опыта других отечественных разработок:
Разработка линии “Эльбрус” прекратилась с моим уходом из Института. Не последняя роль в этом принадлежит Б.А. Бабаяну. “Эльбрус-3” основывался уже на совершенно иных принципах, чем “Эльбрус-1” и “Эльбрус-2”.
В 1985 году я перешел из ИТМ и ВТ в лабораторию академика Г.И. Марчука. К тому моменту конструкторская документация векторного процессора уже была принята заводом-изготовителем. Но эти работы прекратили по совету Б.А. Бабаяна и ставшего директором ИТМ и ВТ Г.Г. Рябова, поставивших вопрос – зачем делать процессор на старой элементной базе, не лучше ли сразу на новой – МВК “Эльбрус-3”? При этом забыли принцип С.А. Лебедева – “шаг за шагом”.
Еще одна значимая работа, которую вели в Институте проблем кибернетики (ИПК) под руководством академика В.А. Мельникова, – векторно-конвейерная суперЭВМ “Электроника ССБИС”. Конечно, это была громоздкая машина – аналог Cray, но в ней содержалось много интересных решений. Когда В.А.Мельников умер, мне пришлось объединить два института, но сохранить разработку не удалось. Эту работу ликвидировали под предлогом недостатка средств. Было изготовлено четыре машины “Электроника ССБИС”, и их пришлось разбирать. Колоссальные деньги оказались затраченными впустую. Единственная польза – при демонтаже мы сдавали золото, и я получил разрешение на выручку покупать приборы.Таким образом, перестал существовать весь передовой фронт работ над суперЭВМ.
То есть Бурцев хотел делать векторный сопроцессор для эльбруса-2, но видимо проиграл в дебатах с министерством и ушел в лагерь, который смотрел в сторону машин Крэя. Но при этом они свою работу не сделали потому что им финансирование порезали под предлогом трудного времени, а бабаян свою не доделал по другим причинам растущим не из того места, а не по каким либо другим. Предвзятости и/или обиды тут конечно же нет.
Дело в том что llvm задумывался как проект в котором фронтенды и бакенды отдельно, а все это, да, стыкуется через промежуточную сущность.
Но на деле разработчики фронтендов её (сущность) как раз не используют, так как оно ограничивает им возможности по интеграции, они тупо форкают llvm и делают свои rustc ghc итпА вот разработчики железа уже такой возможности не имеют им приходится подстраиваться под "представление" которое llvm выдает для низкого уровня и там уже приходится как то изголяться. Особенно архитектурам отличным от arm и x86. Говорят что низкоуровневый бакенд для видеокарт AMD сумарно больше чем все остальные архитектуры вместе взятые, настолько там костылей пришлось наворотить. Эльбрус просто использует бакенд родного компилятора который научили понимать представление LLVM. Результат ожидаемо хуже родного компилятора, и в два раза это еще оптимистично.
Никто у него ничего не забирал, грядущий пашин телеграмм еще помню заглушки во вконтакте рекламировали. Дуров всегда был в тренде технологий и видел как развиваются групповые защищенные меcсенджеры вроде Tox, GNU Ring, конечно же ватсап iMessage и Google Talk всеми забытые. Он видел что время соцсетей прошло и перепрыгнул из одного поезда в другой.
Что касается вконтакта, никогда им не пользовался так как там и при благословенном паше были дебильные правила про то что на профиль можно вешать только свои фотографии а потом и регистрацию по телефону, в данный момент вконтакт убивает то, что менеджмент компании ВК начал стрелять себе в ноги борясь со старыми пользователями ВК заливавшими аниму и прочий контент в рамках своих групп, все ради того что бы сделать из платформы аналог ютуба. По мимо этого еще схватились за аналог твича, аналог стима и игровой движок. В итоге толком не получилось ни того ни другого ни третьего, хотя аналог стима и твича вполне могли бы потянуть. Соцсеть с группами и видеоплатформой есть, надо было только стриминговый сервис и магазин сделать и интегрировать их в соцсеть, но в руководстве ВК похоже сказочно некомпетентные люди.
Компилятор при том, что именно он достает лоад из под проверки, нарушает порядок его исполнения и все вот это, именно он создает уязвимую ситуацию. В интеле же компилятор выдает правильный порядок, который уже нарушает само железо своим спекулятивным исполнением. В первом случае эльбрус не может ничего сделать, он понятия не имеет о первоначальной последовательности и просто исполняет то что дают, во втором компилятор никак не может запретить процессору менять порядок.
Поэтому и нельзя это считать полноценной аппаратной уязвимостью, максимум программно-аппаратной, и то в процессоре предусмотрены механизмы защиты, но именно софт их по разным причинам не использует.
Что касается васи хакера, то он конечно может много чего неприятного собрать подсунуть, например OpenSSL старой версии, но если компилятор начнет выявлять и закрывать/обходить такие грабли, то что вася-хакер с этим поделает? Не ну конечно может старым "дырявым" собирать тоже, да.
В эльбрусе нет предсказателя ветвлений, есть условное исполнение и подготовка ветвлений которые грузятся в конвеер, но реально не выполняются. В будущих процессорах предсказатель будет, интересно будет посмотреть работает ли в нем описываемая вами атака связанная с неверным предсказанием и возможным спекулятивным исполнением кода в нем. Если это будет работать это будет первая аппаратная уязвимость.
Текущая же демонстрирует скорей уязвимость софта (компилятора). А раз так то какие то ситуации компилятор мог бы и отлавливать.
-fno-control-spec Отключить механизм спекулятивности по управлению и поданным на фазе if_conv
Эта опция, насколько я понимаю отключает и спекулятивные загрузки и спекулятивные операции вроде деления на ноль.
-fcontrol-spec Запретить использование спекулятивных обращений в память-fno-dam Отключить DAM - аппаратный механизм разрешения конфликтовпо чтению-записиА вот эти две опции отключают конкретно механизм спекулятивного обращения в память. DAM это тоже какой то буфер хранящий адреса, нужен он только при спекулятивном обращении в память, лучше тоже отключать вместе с ним.
Да там вроде есть специальный флаг отключающий спекулятивность, отказываться от оптимизаций совсем не вариант
так то оно так, но в них входят 32 однобитных предиката ( тоже с тегами но сколько битов на каждый я не могу сказать), поэтому все таки 192 общих-числовых.
Убрали кластеры, об этом есть как устные разъяснения мцст (вроде бы применили кастомный дизайн блоков регистровых файлов), так и обзор спила кристала от House of что-то там, где видно что кластеров больше нет.
В общем я о чем - 64 битная часть в регистрах полноценная, к старшей и младшей части можно обращаться через одинарное представление любыми операциями, а +16битное расширение (превращающее его в 80и битный), к нему никак отдельно обратится нельзя, оно строго для умножения 64битных с переполнением и 80и битной вещественной арифметики. Что то мне подсказывает что в 8СВ вот это расширение регистра с конотацией %xr просто увеличили до [64 [32 32]] засчет того что убрали лишний кластер освободив кучу места при том же техпроцессе и размере кристала.
Но есть так же предположение что в 16С все таки сделали полноценный четверной регистр, на это косвенно указывает новая коннотация %qr иначе какоеоно квадро если не сплитуется на четыре одинарных.
Так то в эльбрусе 192 регистра в регистровом файле + 32 предикатов в предикатном файле + 32 глобальных.
регистровые файлы продублированы в кластерах и технически там 448 регистров.
Помимо этого согласно документации каждый %dr0 делится на %r0 и %r1 (hi и lo часть), так что субъективно там 448 32битных регистра в одном кластере.
Со 128и битными %qr не очень понятно, они сплитуются так же или там нижняя часть это %dr регистр а старшая отдельно и используется только с векторными устройствами.
Но может быть сплитуются все, тогда в современных эльбрусах получается аж 856 32битных регистра в локальной части и еще 128 в глобальной. Хотя в одной процедуре все равно можно использовать только 120.
Противопоставляете утверждением о том что компилятор всегда исходит из писсимистичных сценариев, а вот мол процессор то в динамике больше видит.
Ну так и что из того что он видит? Он не может внести в код изменений на лету как тот же JIT, который как раз использует профилировку и налету перекомпилирует участки кода.
Процессор занимается своими задачами, он не может с кодом программы ничего сделать кроме как грузить и исполнять. Единственное что он может себе позволить из оптимизаций это в наглую попытаться разорвать лютую зависимости и поиметь профит, и этот "профит" проиграет хорошо оптимизированному коду всего в 5-10 раз, а не в 20-40 как на эльбрусе например.
В качественном коде и качественном компиляторе нуждаются абсолютно все. Эльбрус, как и другие vliw процессоры, выделяет то что они крайне чувствительны к качеству кода который компилятор выдает специально для них. Об этом всегда и были разговоры, мол это требует совершенно других компиляторов (в том числе JIT) что просто ведет платформу в условный тупик. Когда оно мутировало в то что чуть ли не в железе все оптимизации происходят у внеочередных суперскалярах я не понимаю.
Профилировка помогает не исходить из писсимистичных либо оптимистичных сценариев, а вырабатывать конкретную стратегию по оптимизациями на основе обрабатываемых данных. Вполне универсальный инструмент, который используется не только в компиляторах но и в кодировании видео.
Для этого есть профилировка и подсказки компилятору ( inline restrict constexpr pragma итд). Динамическое планирование внутри процессора и оптимизация кода компилятором это совершенно разные задачи - динамический фронтенд не видит всей программы/процедуры у него нет на это ни ресурсов ни времен, он работает строго в маленьком окошке c пачкой команд которые ему нужно максимально эффективно расставить как в параллель так и в очередь. Он при всем желании не может заменить компилятор (ни статический, ни JIT) не нужно их противопоставлять.
Антогонистом динамике процессора является не компилятор, а большая структурированная супер-команда (ШК) в которой заранее все можно распланировать в ширь и в очередь, процессору остается только декодировать все это дело.
Плюсы и минусы есть у обоих подходов. Например жирные эльбрусовские команды со всем вот этим закодированным в них барахлом прилично отъедают кэш, а у интела/арма команды деленые+компактные и кэш занимают по минимуму. С другой стороны в эльбрусовскую ШК можно впихнуть что угодно например метки о том что код/данные следует закачать в L2, интелу-арму для этого придется добавлять новые инструкции вроде префетчера.
ШК требует полной синхронизации портов/каналов исполнения, тогда как в суперскаляре порты работают асинхронно. С другой стороны ШК позволяет из простого последовательного процессора недорого получить производительность уровня внеочередного процессора, пусть может не на всех задачах, но зато и без аппаратных уязвимостей.
В общем тут ворпрос уровня cmake vs cargo, ниразу не однозначный и на любой аргумент можно привести контраргумент (а то и не один).
Просто несколько risc-инструкций (компилятором) засовываются в одну длинную инструкцию что позволяет их за один такт считывать, но они не исполняются за один такт.
Повысить по сравнению с чем? Если по сравнению с голыми последовательными процессорами - да, а суперскаляры тоже исполняют инструкции параллельно и по сравнению с ними однозначно можно говорить только про более лучшую энергоэффективность.
На этом "заводе полного цикла" люди тупо вручную собирают готовые изделия пришедшие из китая в виде отдельных запчастей https://mosreg.ru/gubernator/press-slujba/press-relizi/andrei-vorobev-i-igor-shegolev-posetili-zavod-yadro-fab-dubna-1
Сначала навалим на неких абстрактных "айтишников" плюшек в виде отсрочек от службы и льготных ипотек (что может пойти не так?), а потом спустя 3 года займемся проверкой а действительно ли числящиеся по штату "айтишники" имеют отношение к айти специальностям.
Вроде как бы принято говорить что лучше поздно чем никогда, но как то не хочется.
Проблема то все равно останется
выдавать патроны за помаду это плохой путь. Да компьютер особо не скрывает что военный, и выпускает его ... МГТУ Имени Баумана, просто а почему бы и нет? Почему бы ПТУ №6 не заказать на таиване чипы и тоже не собирать что нибудь.
Проблема не в кодировке отдельных инструкций а в структуре ШК как видно какие то люди поднапряглись и разобрали структуру чтоб сделать эмулятор в QEMU.
Подчеркиваю это не список команд а описание структуры блоков из которых может состоять широкая команда (и какие в ней предусмотрены атрибуты для микрокоманд).
И все это актуально только для архитектуры v4 и то я не вижу описания %xrN регистров (80 битные расширения), очевидно потому что разбирающий не встречал кода с ними, а таких штук там вагон.
какие то из команд могли стать уже легаси и на их место в v7 вставили что-то другое.
Бабаян сам говорил что примерно в том же году дейв дицел привез в институт микропроцессор UltraSpark и там было транзисторов больше чем в шкафу на фоне которого они с этим процессором сфотографировались. Этим Шкафом был Эльбрус-3 и смысла с ним возится небыло, надо было осваивать новые технологии проектирования микропроцессоров, чем они и занялись под вывеской МЦСТ.
Сделали бы для начала простую генерацию субтитров из аудиодорожки.
Что бы любой любительский перевод или дубляж можно было получить в виде .srt или даже .ass.
А если кому то надо перевод, то переводить текст всяко проще чем аудио налету.
Короче пока выглядит как слишком замороченный костыль который если даже доделают, им все равно никто не будет пользоваться.
И при этом он говорит что провальная ССБИС была нужна, а эльбрус-3 нет.
У первой (неограниченное) финансирование забрали, а у второй все было в порядке, просто бабаян не довел.
В любом случае не хочу спорить о персооналиях и их личных обидах/неприязни друг к другу. Приведенная в оп-посте статья прекрасно ставит все на свои места, госкомиссия поставила планку достичь 10гигафлопс, 10 процессорный эльбрус-2 выдавал 2Гфлопс (200мфлопс на процессор), векторные сопроцессоры позволяли ускорять только спецзадачи. Госкомиссия заняла сторону Э-3, а Бурцев проиграв ушел в другую организацию. Спустя 20 лет госкомисси таки сдадут эльбрус-3М1 выдающий 7.5Гфлопс, а "замечательные решения" ссбис аж трех поколений даже на fpga не покажут. Хоть это и не проект Бурцева, но он тем не менее зачекм то его защищал.
Ну и черту в вопросе провел Терехов, ИТМиВТ на статический подход перешло не только из за интересных разработок на западе, но и из за опыта других отечественных разработок:
https://www.youtube.com/watch?v=_sYjUukwJzM
https://www.youtube.com/watch?v=-LNliIS-AiE
То есть Бурцев хотел делать векторный сопроцессор для эльбруса-2, но видимо проиграл в дебатах с министерством и ушел в лагерь, который смотрел в сторону машин Крэя. Но при этом они свою работу не сделали потому что им финансирование порезали под предлогом трудного времени, а бабаян свою не доделал по другим причинам растущим не из того места, а не по каким либо другим. Предвзятости и/или обиды тут конечно же нет.
Дело в том что llvm задумывался как проект в котором фронтенды и бакенды отдельно, а все это, да, стыкуется через промежуточную сущность.
Но на деле разработчики фронтендов её (сущность) как раз не используют, так как оно ограничивает им возможности по интеграции, они тупо форкают llvm и делают свои rustc ghc итп А вот разработчики железа уже такой возможности не имеют им приходится подстраиваться под "представление" которое llvm выдает для низкого уровня и там уже приходится как то изголяться. Особенно архитектурам отличным от arm и x86. Говорят что низкоуровневый бакенд для видеокарт AMD сумарно больше чем все остальные архитектуры вместе взятые, настолько там костылей пришлось наворотить. Эльбрус просто использует бакенд родного компилятора который научили понимать представление LLVM. Результат ожидаемо хуже родного компилятора, и в два раза это еще оптимистично.
А что подходит? Просто пытаюсь представить на чем еще писать гуеваое приложение с библиотеками или игровой движок. Кросплатформенный разумеется.