Выпуск Simply Linux 10.1 для RISC-V

Пациент Nova_Logic просто не знает, что OOE и возможно бранч предикшен немножечно подсыпали в последних версиях архитектуры E2K

Перепутал курей, порей и сельдерей. Бранч предиктор есть в е2к с самого начала, в компиляторе. Как предиктнет, так и будет тормозить. OoO, естественно нет, это всю идею VLIW на нет сводит. Ты перепутал со спекулятивным исполнением, оно как бы есть в том плане, что компилятор, если он подозревает, что данные для определения правильной ветки могут быть не готовы, может вставить команды для обеих веток. Есть поддержка в архитектуре, чтоб инструкции из не той ветки по NRE, например, не падали. На практике редкая тупизна, нужная только чтоб показать «мы тут тоже не пальцем деланные», так как нормальные процессоры занимаются спекуляциями только когда реально не могут определить, какая ветка понадобится, а в эльбрусе будет вхолостую работать в любом случае, коль скоро компилятор думал что тут вот может быть проблема.

прочем, какой смысл в этом, если компилятор и так видит как надо код выполнять и заранее поставит так, чтобы OOE не был нужен.

Вот тут ты на 100% прав. ЕСЛИ компилятор видит. Мы про этот компилятор, который вот-вот нам привезёт волшебник в голубом вертолёте, слышим уже лет 15. Ещё чуть-чуть подождать и будет норм. А тем временем всё становится хуже и хуже, если 15 лет назад было в общем-то насрать с какой скоростью там выполняются всякие питоны/джаваскрипты, один хрен всё серьёзное писалось на сях/плюсах, то теперь даже если волшебный компилятор вот прямо завтра появится, половина кода будет тормозить, потому что написано на всякой скриптне и прочих джавах/дотнетах. Волшебнику придётся свой голубой вертолёт туда-сюда нонстоп гонять, подвозить оптимизированную кодогенерацию под каждый новый язычок.

Но Эльбрус действительно больше крутая молотилка данных, нежели исполнятор чего то этакого

Знаешь в чём трагедия? OoO для Эльбруса - это такой «сын маминой подруги», который делает всё то же, но лучше. Даже самая сильная сторона Эльбруса, эта самая числомолотилка, она ничуть не лучше присутствующего в классических архитектурах SIMD. При этом SIMD ещё и масштабируется лучше, вон, в том же RISC-V, правда на уровне пропозала, торчит векторное расширение неопределённой ширины. Т.е. код, работающий на процессоре с 64битными векторными регистрами сможет без перекомпиляции начать работать на процессоре с 1024битными регистрами, просто станет выполнять за один проход не 2 итерации цикла, а 32. Всё что требуется - это чтоб компилятор умел в векторизацию и проверил ширину векторных регистров. Понятно, что этого нет, и может даже и не будет, но это хотя бы в теории может работать, в отличие от

Есть в компиляторе != есть в процессоре, это значит, что архитектура этого в реальности не поддерживает, и все сводится к прохладным влажным мечтам о том что вот-вот наконец во VLIW появится чудо-компилятор, который все нормально сделает. Мы-же о железе говорим, и об очевидной проблеме - что наличие этого в процессоре дает преимущество в производительности, позволяя без необходимости сидеть и править компилятор/сырцы добиваться хорошей производительности, что экономит время разработчиков и первого и второго

Люди на ЛОРе воспитанные, до такого не дойдет

Хе, ну да, ну да)

*с тревогой* У вас какие-то сомнения по данному поводу?

в том же RISC-V, правда на уровне пропозала, торчит векторное расширение неопределённой ширины.

Уже в стандарте, это Али немного поторопился.

Т.е. код, работающий на процессоре с 64битными векторными регистрами сможет без перекомпиляции начать работать на процессоре с 1024битными регистрами,

И ядро уже есть такое: http://www.andestech.com/en/2022/12/08/andes-announces-risc-v-multicore-1024-bit-vector-processor-ax45mpv/

Осталось дождаться реализации в железе.

Это ж лор, как тут без срача. Когда местным стоновится скучно… В прочем результат уже имеет место быть (=

https://habr.com/ru/post/575302

Есть желание написать гадость про Neuromatrix и Elcore?

Не статья, а генератор испанского стыда. В ответ на указание проблем шапкозакидательство. Зачем-то постоянный переход на личность оппонента, какие-то хейтеры кругом мерещатся.

В остальном довольно примитивная демагогия, в ответ на необходимость портирования под e2k зачем-то вспомнил про RISC-V, но забыл уточнить, что RISC-V - это просто ещё один RISC, ему не нужен суперкомпилятор. Как бы цена «портирования» в разы различается, а экономическая мощность за рынками тоже различается, но в другую сторону. Вспомнил зачем-то про трансляцию x86. Бабаян про неё тоже рассказывал, но было это давно, сейчас на фоне современных эмуляторов с перекомпиляцией Эльбрусу вообще гордиться нечем. Ну и сравнение с байкалом. Но только в правильных тестах, в которых эльбрус побеждает. В Потому что он «отечественный». С неотечественными сравнивать нельзя. И неправильными бенчами тоже пользоваться нельзя, так как «засмеют», да и в них байкал ещё чего доброго победит. Забыл только рассказать о разнице в стоимости заказа на тайване процессоров на устаревшем ядре и устаревшем техпроцессе и проекта эльбрус.

Соглашусь лишь, что программные эмуляторы x86 сделают аппаратную трансляцию не нужной однажды

Волшебнику придётся свой голубой вертолёт туда-сюда нонстоп гонять, подвозить оптимизированную кодогенерацию под каждый новый язычок.

Хм. А интерпритатор этого каждого нового язычка чем компилируется? Ну или назови компилируемые язычки, и с процентом занятия.

Джаваскрипт. Одного его достаточно. А так слышал всякое pypy, например. Ещё есть llvm, используемый в качестве бжкенда много где, включая эмуляторы. Ну а интерпретаторы, собранные чудо-компилятором, вот условное let a = 2*b + c, его интерпретация хорошо ляжет на VLIW? Будет там вообще хоть какая-то разница, собран интерпретатор плотным компилятором или нет?

Джаваскрипт. Одного его достаточно.

Ну так он испольняется в рамках интерпретатора, который собирается компилятором, ориентированным на архитектуру.

Ну а интерпретаторы, собранные чудо-компилятором, вот условное let a = 2*b + c, его интерпретация хорошо ляжет на VLIW?

Это вопрос, который отличается от того, что интерпретатор в принципе нуждается в отдельной оптимизации. Оно не исключено, но далекто не обязательно, что не хватит оптимизирующего c/c++ для сборки интерпретатора.

Ну так он испольняется в рамках интерпретатора, который собирается компилятором, ориентированным на архитектуру.

Нет. Все современные джаваскрипт-движки умеют в компиляцию, умеют определять, где динамическую типизацию можно заменить статической, умеют даже иногда заменять numeric на отсутствующий в js int. На этих особенностях живёт, например, проект asm.js, который компилирует сишный код в js, оформленный таким образом, чтоб оптимизирующий компилятор js смог сгенерировать нативный код с минимальным оверхедом.

Готовы ли МЦСТ добавлять VLIW-оптимизации в каждый такой jit-компилятор?

Это вопрос, который отличается от того, что интерпретатор в принципе нуждается в отдельной оптимизации. Оно не исключено, но далекто не обязательно, что не хватит оптимизирующего c/c++ для сборки интерпретатора.

Для эффективной работы VLIW нуждается в большом количестве независимых друг от друга безусловных операций. А интерпретатор наоборот представляет собой код с множеством условий, просто по факту того, что это программа, управляемая интерпретируемые кодом. Так что к обычному оверхеду, создаваемому интерпретатором, в VLIW ещё добавится дополнительное неудобство связанное с искусственным убийством параллельности. Код на интерпретируемом языке может быть просто идеальным для Эльбруса, какие-нибудь длинные цепочки операций над элементами цикла, но с точки зрения процессора это будут постоянные условные переходы перемежающиеся парой инструкций. Компилятору, неважно хорошо он оптимизирует под VLIW или не очень, просто негде тут будет развернуться

Компилятору, неважно хорошо он оптимизирует под VLIW или не очень, просто негде тут будет развернуться

Так расскажи мне разницу между микрокодом произвольного процессора и кодом, выходящим из-под компилятора, кроме того, что сам микрокод уже почти не поддаётся внешней оптимизации? Уже ARM - не x86 и не RISC.

Разве это неочевидно? Декодер в общем случае знает какие операции нужно будет исполнять, а компилятор не знает.

Вот как выглядит типичный горячий код?

for(auto i = 0; i < vec.size(); ++i) process(vec[i], ...);

Умному компилятору во VLIW тут есть где развернуться. Он подставит тело функции process, оценит сколько ему надо регистров для выполнения тела цикла, поделит их общее количество на это число, получит N, заменит код на

for(auto i = 0; i+N <= vec.size(); i += N) {
    process(vec[i], ...);
    process(vec[i+1], ...);
...
    process(vec[i+N-1], ...);
}
...

Перемешает инструкции из разных вызовов process чтоб они плотно упаковывались в слова. А как выглядит типичный код интерпретатора?

while((command = get_next()).code != STOP){
   implementations[command.code](command);
}

Ну или что-то со switch примерно того же типа.

Причём функция исполнения для большинства команд либо короткая, либо ветвистая, так что внутри одной функции хорошо не поупаковываешь.

Компилятор может заинлайнить get_next и даже добавить код эффективной предварительной выборки, но ему неизвестно что это будут за команды. соответственно перемешать инструкции из последовательных итераций он не сможет. Типичный суперскалярный OoO процессор таких проблем иметь не будет. Пока первая итерация запнулась и ждёт поступления данных по implementations[command.code] get_next для следующей команды уже исполняется, хотя бы в спекулятивном режиме. Соответственно CPU сможет перемешивать инструкции из разных итераций. Аналогичное решение для VLIW потребовало бы извлекать по N последовательных операций, затем извлекать из implementations_multiplexed размером implementations.size() ^ N, или же делать более хитрую и микшировать только самые частые инструкции, а остальные и дальше выполнять по одной, но тогда не факт, что код для выборки мультеплексированной инструкции не будет выполняться дольше чем экономия, получаемая от этого мультиплексирования.

А как выглядит типичный код интерпретатора?
while((command = get_next()).code != STOP)
implementations[command.code](command);

Такой код и не предполагает оптимизации. Тут значения и вызовы непредсказуемые, любой процессор на таком коде будет больше простаивать, но интерпритаторы и не обещают быстроту.

Если же ты думаешь что бранчпредиктор может как то заранее угадать адрес функции значение для которой еще не получено, то у меня для тебя плохие новости.

На функцию не смотри, её, вероятно, компилятор заинлайнит. В остальном твоя ошибка в том что ты смотришь на этот код как на последовательный. А он последовательный только с точки зрения архитектуры, после обработки декодером он превратится в куски, предназначенные для разных аппаратных регистров и запускаться будет в разном порядке, пропуская те части, которые ещё не готовы. Например get_next будет выполняться параллельно с предыдущей командой. В этом и плюс ОоО: железный оптимизатор, может не такой умный, как тот что в компиляторе, но он обладает актуальной информацией, и даже там где что-то неизвестно и приходится полагаться на предиктор и выполнять спекулятивно, это одна из двух веток, а не развесистой дерево.

Каким образом компилятор должен заинлайнить то, адрес чего будет вычислен только во время исполнения?
Твоя проблема в том что ты плохо понимаешь что происходит на аппаратном уровне, для чего процессору требуются все эти спекулятивные вычисления и предсказатели переходов.

В твоем примере, если он подразумевает произвольность вызовов и их количества, не поможет ничто, но еще раз повторю не весь код создан для того что бы исполнятся с максимальной скоростью.
Зачастую лучше пренибречь скоростью ради компактности кода, обработка консольных комманд одна из таких вещьей.

Я про функцию get_next() вообще-то, её заинлайнит. В остальном всё как написал выше. Предиктить там ничего особо и не надо, возврат из функции безусловен, так что получение следующего кода операции можно и параллельно с завершением текущей выполнять.

И я вообще не понимаю нахрена ты влез. Человек придумал, будто суперкомпилятор Эльбруса сможет как-то ускорить и код интерпретатора и, соответственно, скорость интерпретируемой программы. Я объяснил, почему это невозможно. Ну а то что суперскалярный ОоО процессор тут позволит немного параллелизма вытянуть - так это так, бонус