Причем ведь были и свои разработки: от железа (например, легендарный «Эльбрус») до ПО (застал заведующего кафедрой — директора по науке НИИУМС: их разработки "с нуля" были вполне уровне, пусть и специфичные)
Российское импортозамещение напоминает театральную постановку: актёры в костюмах «патриотов» разыгрывают пьесу о технологической независимости.
Тут дело в том что министерства (минцифры итд) которые всю эту движуху инициируют, им самим это все не нужно, в том смысле что никаких IT отделов и серверов у них нет. Таким образом получается ситуация когда, человек которого это все не касается (ни прямо ни косвенно) предписывает другому как и на чем ему работать. Довольно абсурдно, но по факту так и есть.
Логика конечно подсказывает что министерство наоборот как бы должно быть максимально на стороне госзаказчиков и чихвостить участников, но на деле у нас министерство взяло на себя роль няньки, а IT-бизнес воспринимает как сироток которые надо гос-сиськой кормить иначе он умрет. Ну а госзаказчик он как бы мужик и потерпит. Проблема в том что под "сиротками" как правило скрываются ветераны сосания бюджетов которые очень отчаяно защищают свою кормушку от конкурентов. За примером далеко лазить не буду, инди-разработчики известные по RTC Syrian Warfare, когда решили получить финансирование от гос-фонда созданного вроде как для поддержки игр, столкнулись с тем что с них начали требовать бухучеты и документу по госту о выполненных работах. Для чего это сделано - вполне понятно, для того что бы такие залетные в гостему даже не совались, а правильные люди будут теперь раз в трехлетку делать Смуты, Сталинграды, и рекламировать по первому каналу в новостях.
Они не бесплатные, нужна все равно какая-то компания которая будет собирать из исходников и тестировать версии на совместимость. И огромный плюс СПО как раз в том что это может делать любая, достаточно компетентная компания. Тогда как закрытый софт это собственность компании-разработчика и только она его билдит и сопровождает. Можно ли считать "интеллектуальную собственность" пусть даже российских компаний общенациональной - это большой вопрос.
По мне так нельзя, пока она не выложит код под свободной лицензией.
Сравниваем 1 Байкал-С с 4-мя Э16С и делаем вывод, что т.к. 1 не обгоняет 4-х (кстати, обгоняет), то он проиграл.
Сравниваю серверные процессоры. Один штатно может в многопроцессорную конфигурацию и ему для этого не нужно никаких контроллеров и прочего, с чего бы это не учитывать? Это базовая вещь для серверного процессора. Для байкала заявлен CCIX но оно вроде как не для объединения процессоров на общей памяти, а для интерконекта со всякое фигней типа модуля NeuroMatrix, и опять таки в глаза бросается то что у байкала на сайте:
Интерконнект:Три интерфейса CCIX x16, каждая полоса работает со скоростью 16 Гбит/с. Интерфейсы ввода/вывода:80 линий PCIe Gen 4.0 (48 линий общие для CCIX-интерфейса);
как бы все правильно это обычная паропускная способность PCIe yj в документации к стандарту CCIX речь идет про GT/s (миллиарда транзакций в секунду) потому что суть интерфейса как раз в том что бы не гонять данные туда сюда (с чем справляется обычный PCIe), а что бы расшарить общую память для ускорителей при этом да используя тот же PCIe.
Зачем так написано? Затем что у эльбрусов написано 16гбит/с в каждую сторону ? Ну так там то как раз данные пересылаются между процессорами.
В общем и целом имеем очередное "поделие" для пускания пыли в глаза чиновникам, процессор для облачных сервисов (например облачной нейросети с ускорителями) который на серьезных щах подают как серверный процессор для СХД, то есть повторяется ситуация как с таволгой куда сунули процессор для embadded в качестве десктопного. Так что проблема не в Т-Платформах и не в Опанасенко, а в самой этой компании Байкал Электроникс, которая не ориентирована на то что бы создавать востребованный рынком продукт, а на то что бы пилить бабло на госзакупках и некомпетентности чиновников.
Это уже сравнение двух серверных процессоров, что хорошо. Уже появился множитель 3х. Правда он на реальных задачах будет не 3х, а скорее 5-10,
Это не множитель это количество процессоров на сервере которых данный байкал типа как бы закрывает, то есть до четырех процессорного сервака на эльбрусе он уже не дотянет. Вот так выглядит сервер на этом байкале:
Таким образом имеем: - 8и ядерный недопроцессор для десктопа с нафиг не нужным энергопотреблением вместо производительности. - 48и ядерный армовый Threadripper который позиционирует себя как EPYC
И ладно бы если бы это сами мучилисьи выдали хоть такое зато свое, но это все целиком закуплено в виде технологий/лицензий за бюджетные деньги. То есть вкладываем заведомо в фуфло которое не приблежает к желаемому ни на шаг, ни компьютеров нормальных ни хай-энд серверов как небыло так и нет и с таким подходом не будет и в будущем.
Полистал. Писанина буквально на уровне книжки МЦСТ про архитектуры их микропроцессоров. Большая часть повещена разным историческим экскурсам, с отсылками к работам 70х-80х годов. Впрочем и название то кричит что это учебник для студентов. Типа курс лекций: Дизайн современных процессоров. Тема: Основы/База Суперскалярных процессоров.
К чему это вообще? Вы же вроде по софту, зачем лезете в железо. Вам скинут книгу про основы С++ какого нибудь столярова и скажут "вот так современный софт на плюсах разрабатывается". Сказать что это будет странно это ничего не сказать.
Байкал-М 8 core 28nm 1,5 ГГц DDR4-2400 2018г (то же самое что Эльбрус-8СВ) Байкал-S 48 core 16нм 2ГГц 6 каналов памяти 2021г (примерно то же самое что 3xЭльбрус-16С -2 канала памяти)
Где передовые процессоры на 5-2нм 3-4Ггц? Зачем бюджетные деньги тратятся на лицензирование устаревшего железа которые студенты из мцст спокойно выдают в те же 3-5лет. Если нам не продают самое новое что бы идти в ногу со всеми то тогда и нет смысла идти по этому пути.
Во первых мцст разрабатывает и risc процессоры тоже, во вторых подсистема памяти, занимающая большую часть кристалла в любом процессоре, в эльбрусе не управляется из компилятора она управляется автоматически. Ну а в третьих в современных процессорах всей вот этой лабудой с планированием/перестроением очереди, даже распределением регистров занимается микрокод. Этакий низкоуровневый JIT компилятор обладающий рантайм информацией но ограниченный очень маленьким окном возможностей, поэтому обработку больших данных все равно приходится планировать вручную через упаковку данных в длинные вектора и прокачиванием их в кэш через префетч.
И да - ни мцст-шный risc, ни большинство арм процессоров на рынке микрокодом не обладают и чудес производительности не показывают, потому что внутри это такой же "просто конвеерный процессор" с малым количеством блоков, так как большее количество без сложных манипуляций с кодом тупо не прогрузить.
Какие перспективы у российского ARM по сравнению с китайским? Внутри то же самое а цена раз так в 10 дороже. Не вижу смысла в байкале ни с рыночной ни тем более с какой то там суверенной-безопасной точки зрения. Эльбрус по крайней мере, помимо того что он в доску свой, он еще и инженерную школу выращивает.
Байкал же изначально свою необходимость обосновывал тем что под арм мол все написано и не надо ничего будет самим писать и он будет дешевле и доступней. По факту и правки в ядро оказалось надо делать (а в свете всех событий уже и форк ядра надо держать) и ценой с доступностью не отличается. Вот на что деньги пора перестать тратить.
Ладно бы если бы это еще был мобильный ARM для р-фонов всяких, но это десктопный-серверный арм с десктопной переферией.
Сейчас ситуация обратная, гуглпоиском пользоваться невозможно, нейросети его рлностью сломали, сколько не изменяй свой вопрос он сует одно и то же и ему плевать на суть. А вот картинки в гугле ищет отлично чего не скажешь о яндексе. Зато в яндексе поиск работает более менее, выводит сайты с документацией и уроками, а нейропомощник отдельно предлагает свой вариант, все как в старом добром поисковике.
Никто у него ничего не забирал, грядущий пашин телеграмм еще помню заглушки во вконтакте рекламировали. Дуров всегда был в тренде технологий и видел как развиваются групповые защищенные ме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, ниразу не однозначный и на любой аргумент можно привести контраргумент (а то и не один).
Тут дело в том что министерства (минцифры итд) которые всю эту движуху инициируют, им самим это все не нужно, в том смысле что никаких IT отделов и серверов у них нет. Таким образом получается ситуация когда, человек которого это все не касается (ни прямо ни косвенно) предписывает другому как и на чем ему работать. Довольно абсурдно, но по факту так и есть.
Логика конечно подсказывает что министерство наоборот как бы должно быть максимально на стороне госзаказчиков и чихвостить участников, но на деле у нас министерство взяло на себя роль няньки, а IT-бизнес воспринимает как сироток которые надо гос-сиськой кормить иначе он умрет. Ну а госзаказчик он как бы мужик и потерпит.
Проблема в том что под "сиротками" как правило скрываются ветераны сосания бюджетов которые очень отчаяно защищают свою кормушку от конкурентов. За примером далеко лазить не буду, инди-разработчики известные по RTC Syrian Warfare, когда решили получить финансирование от гос-фонда созданного вроде как для поддержки игр, столкнулись с тем что с них начали требовать бухучеты и документу по госту о выполненных работах. Для чего это сделано - вполне понятно, для того что бы такие залетные в гостему даже не совались, а правильные люди будут теперь раз в трехлетку делать Смуты, Сталинграды, и рекламировать по первому каналу в новостях.
Они не бесплатные, нужна все равно какая-то компания которая будет собирать из исходников и тестировать версии на совместимость. И огромный плюс СПО как раз в том что это может делать любая, достаточно компетентная компания. Тогда как закрытый софт это собственность компании-разработчика и только она его билдит и сопровождает. Можно ли считать "интеллектуальную собственность" пусть даже российских компаний общенациональной - это большой вопрос.
По мне так нельзя, пока она не выложит код под свободной лицензией.
Сравниваю серверные процессоры. Один штатно может в многопроцессорную конфигурацию и ему для этого не нужно никаких контроллеров и прочего, с чего бы это не учитывать? Это базовая вещь для серверного процессора. Для байкала заявлен CCIX но оно вроде как не для объединения процессоров на общей памяти, а для интерконекта со всякое фигней типа модуля NeuroMatrix, и опять таки в глаза бросается то что у байкала на сайте:
Интерконнект:Три интерфейса CCIX x16, каждая полоса работает со скоростью 16 Гбит/с.Интерфейсы ввода/вывода:80 линий PCIe Gen 4.0 (48 линий общие для CCIX-интерфейса);как бы все правильно это обычная паропускная способность PCIe yj
в документации к стандарту CCIX речь идет про GT/s (миллиарда транзакций в секунду) потому что суть интерфейса как раз в том что бы не гонять данные туда сюда (с чем справляется обычный PCIe), а что бы расшарить общую память для ускорителей при этом да используя тот же PCIe.
Зачем так написано? Затем что у эльбрусов написано 16гбит/с в каждую сторону ? Ну так там то как раз данные пересылаются между процессорами.
В общем и целом имеем очередное "поделие" для пускания пыли в глаза чиновникам, процессор для облачных сервисов (например облачной нейросети с ускорителями) который на серьезных щах подают как серверный процессор для СХД, то есть повторяется ситуация как с таволгой куда сунули процессор для embadded в качестве десктопного. Так что проблема не в Т-Платформах и не в Опанасенко, а в самой этой компании Байкал Электроникс, которая не ориентирована на то что бы создавать востребованный рынком продукт, а на то что бы пилить бабло на госзакупках и некомпетентности чиновников.
Это не множитель это количество процессоров на сервере которых данный байкал типа как бы закрывает, то есть до четырех процессорного сервака на эльбрусе он уже не дотянет. Вот так выглядит сервер на этом байкале:
Таким образом имеем:
- 8и ядерный недопроцессор для десктопа с нафиг не нужным энергопотреблением вместо производительности.
- 48и ядерный армовый Threadripper который позиционирует себя как EPYC
И ладно бы если бы это сами мучилисьи выдали хоть такое зато свое, но это все целиком закуплено в виде технологий/лицензий за бюджетные деньги. То есть вкладываем заведомо в фуфло которое не приблежает к желаемому ни на шаг, ни компьютеров нормальных ни хай-энд серверов как небыло так и нет и с таким подходом не будет и в будущем.
Полистал. Писанина буквально на уровне книжки МЦСТ про архитектуры их микропроцессоров. Большая часть повещена разным историческим экскурсам, с отсылками к работам 70х-80х годов.
Впрочем и название то кричит что это учебник для студентов. Типа курс лекций: Дизайн современных процессоров. Тема: Основы/База Суперскалярных процессоров.
К чему это вообще? Вы же вроде по софту, зачем лезете в железо. Вам скинут книгу про основы С++ какого нибудь столярова и скажут "вот так современный софт на плюсах разрабатывается". Сказать что это будет странно это ничего не сказать.
И где это у байкала "нормальные процессоры"?
Байкал-М 8 core 28nm 1,5 ГГц DDR4-2400 2018г (то же самое что Эльбрус-8СВ)
Байкал-S 48 core 16нм 2ГГц 6 каналов памяти 2021г (примерно то же самое что 3xЭльбрус-16С -2 канала памяти)
Где передовые процессоры на 5-2нм 3-4Ггц? Зачем бюджетные деньги тратятся на лицензирование устаревшего железа которые студенты из мцст спокойно выдают в те же 3-5лет. Если нам не продают самое новое что бы идти в ногу со всеми то тогда и нет смысла идти по этому пути.
Во первых мцст разрабатывает и risc процессоры тоже, во вторых подсистема памяти, занимающая большую часть кристалла в любом процессоре, в эльбрусе не управляется из компилятора она управляется автоматически. Ну а в третьих в современных процессорах всей вот этой лабудой с планированием/перестроением очереди, даже распределением регистров занимается микрокод. Этакий низкоуровневый JIT компилятор обладающий рантайм информацией но ограниченный очень маленьким окном возможностей, поэтому обработку больших данных все равно приходится планировать вручную через упаковку данных в длинные вектора и прокачиванием их в кэш через префетч.
И да - ни мцст-шный risc, ни большинство арм процессоров на рынке микрокодом не обладают и чудес производительности не показывают, потому что внутри это такой же "просто конвеерный процессор" с малым количеством блоков, так как большее количество без сложных манипуляций с кодом тупо не прогрузить.
Какие перспективы у российского ARM по сравнению с китайским? Внутри то же самое а цена раз так в 10 дороже. Не вижу смысла в байкале ни с рыночной ни тем более с какой то там суверенной-безопасной точки зрения. Эльбрус по крайней мере, помимо того что он в доску свой, он еще и инженерную школу выращивает.
Байкал же изначально свою необходимость обосновывал тем что под арм мол все написано и не надо ничего будет самим писать и он будет дешевле и доступней. По факту и правки в ядро оказалось надо делать (а в свете всех событий уже и форк ядра надо держать) и ценой с доступностью не отличается. Вот на что деньги пора перестать тратить.
Ладно бы если бы это еще был мобильный ARM для р-фонов всяких, но это десктопный-серверный арм с десктопной переферией.
Только какое отношение к этому всему имеют докладчики? Свои то игры (успешные) у них есть для примера?
А толку его выкладывать если без тулчейна ничего не соберешь, а тулчейн под NDA был
Сейчас ситуация обратная, гуглпоиском пользоваться невозможно, нейросети его рлностью сломали, сколько не изменяй свой вопрос он сует одно и то же и ему плевать на суть. А вот картинки в гугле ищет отлично чего не скажешь о яндексе. Зато в яндексе поиск работает более менее, выводит сайты с документацией и уроками, а нейропомощник отдельно предлагает свой вариант, все как в старом добром поисковике.
Никто у него ничего не забирал, грядущий пашин телеграмм еще помню заглушки во вконтакте рекламировали. Дуров всегда был в тренде технологий и видел как развиваются групповые защищенные ме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, ниразу не однозначный и на любой аргумент можно привести контраргумент (а то и не один).