МЦСТ публикует исходные тексты ядра Linux 6.1 для архитектуры Эльбрус

и контекст на всю программу (а не сотню байтов как у процессора). Недостаток в многословности команды.

Но нет контекста на входные данные.

И все они делают DSP а не General Purpose CPU.

Он есть больше, чем у процессора. Компилятор может проанализировать константы, может сделать профилирование. Процессор память, которая ещё не попала в регистры, не видит никак. У процессора «входные данные» только от предсказателя переходов. Но у компилятора есть они же и он вместо подготовленного перехода может делать переход по предсказателю.

Так и знал что пойдет про гостовские шифры. Нашли удобный бенчмарк и бегают с ним как с писаной торбой

У вас генератор нейрослопа сломался почините

Мне что-то подсказывает что «контекст на всю программу» это голимый звездеж. Все что можно было заоптимизировать «на всю программу» уже заоптимизировали по самые помидоры. Еще и UB приплели чтоб рукоблудить под видом оптимизаций.

Но это никак не помогает против реальных программ, где 11% кода это jmp, je, jne и 8% call. Причем часто indirect.

В этом то вся и проблема. Код для DSP можно заоптимизировать в усмерть потому что там будет крутиться один ну два или три алгоритма. А обычные программы они подленькие. Там очень, ну очень рулит задержка от начал команду чтения из памяти до пришла первая команда после перехода. Или задержка вида увидел jmp - потерял сколько то тактов

Простота эльбрусовского декодера это на самом деле хорошо и как я понял условные операции по предикатам тоже. Предикаты вообще кучу ветвлений убивают. Но не все и особенно непонятно что делать с виртуальными методами и подобной им лабубе.

Результаты SPEC CPU 2006 и SPEC CPU 2017 были приведены ранее, где «Эльбрус» обошёл ARM.

Да разобрали оказывается уже «ответ» эльбрусовцев.

https://habr.com/ru/articles/576420/

Как я и говорил - бурмалда это и демагогия. Полтора бенчмарка таскают юродивые и везде ими тыкают потому что больше показать нечего. Частота дно. Код даже банальной сортировки начинен нопами, чем занимался «оптимизирующий» компилятор не понятно. Купить нельзя, документации вменяемой внезапно тоже нет, я искал. То что они там что-то открыли это я даже не знаю как описать. Оно не позволяет создать бэкэнд компилятора типа GCC или LLVM просто потому что там нет описания формата vliwов.

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

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

Вот уж покойный Алкснис точно не писал про «бесполезную». Он как раз возмущался, что такую крайне нужную вещь не могут доделать (в фактической части ссылаясь на признания вице-премьера Иванова), и предупреждал, чем это может закончиться.

Сейчас бы мог порадоваться, если был бы жив.

Полтора бенчмарка

SPEC CPU — это стандарт для объективной оценки производительности процессоров общего назначения.

https://habr.com/ru/articles/576420/

https://habr.com/ru/articles/576420/comments/#comment_23460456

Купить нельзя

Можно, непосредственно у МЦСТ.

справедливости ради глонасс не является извинением для эльбруса. это реально плохой процессор.

я сам был в команде которая в 2016м чуть в сколково не прошла именно с проектом vliw-проца. спасибо эксперту от Элвиса что зарубили найдя патент интела про многоголовые процы и синхронизацию регистровых файлов. Он один дал негативный отзыв. Так вот, даже он был out-of-order. Просто в отличие от эльбруса он был explicitly out-of-order.

каждый vliw выполняется последовательно, но сами они имеют поле «связей» и они могут идти параллельно. это было удобно потому что радикально уменьшало количество логики в планировщике. цель ведь упростить и убыстрить: ну вот и оно. да и кстати vliwы были 64 бита а на 128.

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

Мне с кем только общаться не приходится, поэтому ко всем отношусь спокойно.

люди не будут запускать бенчмарки. они будут запускать игори, а там ТОРМОЗИИИИИИТ и люди сразу ffffffuuuuuuuuuuuu. или сервера с жавой. вы видели код который в банках жаберы пишут? я то видел, жена там работает и бывает сижу рядом помогаю. там вызов функции на вызове и вызовом погоняет. и каждый виртуальный.

out-of-order позволяет хотя бы как-то затерпевать. но он сложный, да. хочется уменьшить сложность: я для этого придумал группировать инструкции в vliw, немного плюшек если в один не помещается, и явные зависимости между vliwами. всё здорово, но есть нюанс: размер контекста килобайт 40. это не х86 где rflags,rax…r15,ymm0…ymm15 сохранил и сиди радуйся. там всё грустно и несовместимо с х86.

они будут запускать игори

Уже давно запускают на «Эльбрусе»

https://rutube.ru/video/e31c236c9db382da764a9474ccff3a27/?t=699

или сервера с жавой

В МЦСТ на практике ускоряли работу банковских Java-приложений.

я для этого придумал группировать инструкции

https://patents.google.com/patent/RU2816094C1/ru

А что мне этот патент? Он ко мне никаким боком. Vliw там был только для того чтоб собрать команды в кучку и не следить ни за памятью ни за регистрами. А лишь за метками на командах.

размер контекста килобайт 40

Лол, я за килобайт-то переживал )
BTW, что скажешь про реинкарнацию EDGE/TRIPS(?) - LinxISA?
Мнение VIT тоже было бы крайне интересно.

Ну молодцы ускоряли жабу. Я вот решил просто добавить risc-v декодер в параллель. Это дешевле по рабочей силе, да и профиль rva23 ужас конечно но не ужас ужас.

У мцст-то такой опции нет из коробки, поэтому говна приходится поесть и с жабой и с браузерами и с pcre и с базами данных даже. Везде где есть jit.

А как быть с игорями где скрипты на Lua и есть hot pages? Роблокс, minetest, много их.

Это одна из причин почему я выкинул проект проца с vliwом. Даже с учетом того что там был не честный vliw а лишь способ маркировки команд. И даже вторую редакцию которая уже была ближе к нормальным процам, и даже поддерживала бинарную трансляцию х86 без jump tables, байт в два байта. И третью где уже было почти байт в байт. Хотя там главная причина это все таки 40кб контекста.

Главная проблема это количество софта который надо переписать. И поддерживать потом потому что хром и Фокс обновляются и надо хорошо понимать как ихняя vm работает. И базы данных тоже jitом увлекаются и нету общей библиотеки где можно централизовано все это поддержать. Был бы везде asmjit проблемы бы не было

И базы данных тоже jitом увлекаются

Так в постгресе вроде llvm jit?

Охота, рыбалка или туризм положительных впечатлений приносят куда больше и на куда большее время, нежели ковыряние с «Эльбрусом».

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

Не только в постгрессе. Но даже llvm надо патчить. У Эльбруса уже появился бэкэнд к llvm? Нет. Ну вот и пожалуйста. Захотели vliw - получайте в нагрузку охулиарды проблем буквально везде.

Кстати моя первая версия vliw проца влетела помимо патентных проблем еще и в llvm. Он заточен как и GCC на обычные процы. Например мне потребовалось там делать две точки входа в функцию - одну при вызове без оптимизации а другую при вызове с оптимизацией когда компилятор «видит весь контекст» как говорят фанаты Эльбруса. И два варианта выхода с опорой на биты в адресе возврата. Это ого-го какие изменения. Если так не делать - проц посасывал на вызовах функций. Если делать эффект как от инлайна.

То есть на самом деле мы живем в мире где все заточено под «обычные процы». Даже компиляторы. Тот же Эльбрус можно ведь жестко улучшить по похожей на мою схеме. Он будет рвать врагов на грелки как тузик. Но в итоге мы все равно упираемся в гору размером с Эльбрус из софта который надо мучительно и долго портировать

Везде где есть jit.

А как быть с игорями где скрипты на Lua и есть hot pages?

Аппаратный предсказатель переходов в 7 поколении процессоров «Эльбрус», ссылка на патент которого была приведена ранее.

Роблокс, minetest, много их.

https://rutube.ru/video/007327bfb605a724caa8283cd741432d/

две точки входа в функцию - одну при вызове без оптимизации а другую при вызове с оптимизацией

А это разве не дело ABI, и просто два варианта кода, а не два входа?

Но в итоге мы все равно упираемся в гору размером с Эльбрус из софта который надо мучительно и долго портировать

МЦСТ уже представлена технология для автоматического портирования и оптимизации ПО под платформу «Эльбрус»

МЦСТ публикует исходные тексты ядра Linux 6.1 для архитектуры Эльбрус (комментарий)

ABI писали под … Хотя нет, x86-64 использует ABI итаника. Хотел сказать «нормальные процессоры» но итаник гавно рогатое. Оно ABI вообще рассчитано на то что у тебя есть вот столько регистров и все. А у меня архитектура включала уничтожение большинства команд mov. Их так-то 38% всего кода из-за register allocation в компиляторе. Я их убрал а заодно и aliasing в c/c++. Хочешь память? Посчитай адрес и положи в адресный регистр(навеяно Motorola 68020) укажи какая зона из 4096 регистров ассоциирована и обращайся туда как к регистрам. Отсюда и оптимизация вызова функций: ничего не надо пушить в стек. Указываешь ветку кода, базовые номера регистров от которых в функции идет отсчет и получаешь инлайн без инлайна

А llvm столько не поддерживает.

Плюс в llvm есть класс представляющий функцию. Он из коробки не предусматривает две точки входа и две выхода. Ах да, там еще был цирк с указателями. В них надо вносить инфу сколько надо прибавлять чтоб попасть в оптимизированную точку входа. llvm это тоже ой как не поддерживает.

Оно ABI вообще рассчитано на то что у тебя есть вот столько регистров и все.

Ну сделай свой, делов-то? Я так и делаю.

Их так-то 38% всего кода из-за register allocation в компиляторе.

Ну не mov конкретно, наверное, а spill/fill? вроде поменьше 38%...

навеяно Motorola 68020

тут имхо скорее креями. Или вообще AT&T Hobbit/Bell CRISP.

Я забыл добавить - 2016й год, llvm 3.2. До LLVM IR еще как до луны. А весь код общий для бэкэндов заточен на использование одно из аллокаторов регистров. Можно свой написать но блин. Когда у тебя регистры это условность , быстрая ссылка на память, то вся логика llvm ломалась. То есть были адресные регистры ты туда пишешь где лежат данные сколько их и в какую зону номеров регистров они ложатся. Сами аппаратные регистры были кэшем L0 по сути. И вот кстати на этом и прилетел патент в ТОЙ реализации.

Хрен с патентом, можно переформулировать тем более сейчас уже там другая архитектура регистрового файла.

Но компилятор! Они жестко заточены под «обычные процы»

Именно mov инструкций. 38% mov, 11% jmp/je/jne, из них половина jmp, и 8% call. Я щас по лесу гуляю и пю поэтому ссылку не дам. Вообще я сделал декодер и анализатор бинарей чтоб понимать с каким адом столкнусь. Но он пока хероват.

Короче, «обычные программы» это ад для разработчика проца. Indirect jmp, indirect call - повсеместно.

Я когда-то в амд еще работал и предложил им оптимизацию которая использовала инструкцию indirect call на hd7000. Так мне сказали идея почти идеальна но perefetch команд сходит с ума и вообще мы по ошибке её добавили. Ветвление это боль всегда. А у тебя чуть ли не каждая четвертая команда ветвится

Сами аппаратные регистры были кэшем L0 по сути. И вот кстати на этом и прилетел патент в ТОЙ реализации.

Странно, вроде отображение с опциональной подкачкой ещё с 60х, как минимум, используется.

У Эльбруса уже появился бэкэнд к llvm?

https://unipro.ru/ru/clang-llvm/

https://habr.com/ru/articles/739394/

Именно mov инструкций.

Я про то, что mov на x86 довольно функциональный. И, говоря про аллокацию, и «уничтожение большинства команд mov», я так понимаю, что имелась в виду та их часть, что делала spill/fill?

Ну сейчас то регистры это именно регистры. У Эльбруса кстати регистры еще и стэк. Так что я не одинок.

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

Далее была версия 2 где vliw был уже наклейкой на cisc. И там тоже был цирк вокруг регистрового файла кстати. Это прямо сердце проца и там все страшно. Там уже была заточка под бинарную трансляцию х86 в режиме байт в два байта. То есть адрес N превращался в M+8*(N>>2) плюс младшие 3 бита шли как адрес микрокоманды в 64битном vliw. Которая кстати могла принимать ветвление в себя или не принимать чтоб если бинарный транслятор профукал ветвление то хотя бы по ошибке увидел его и сделал выводы.

Формат команды 64бита, 12бит явной информации о синхронизации, плюс 4 13битных байткодов.

Затем третья версия где еще более жесткая заточка, 95% кода x86-64 транслируются байт в байт, служебные данные vliw с 12бит усохли до 4х. Байткоды стали 15битными и 99% ходовых команд x86-64 стали или равны по длине или даже больше.

Пока ходил тут по парку придумал четвертую версию кстати. На самом деле придумал я её давно но там всегда была проблема: explictit out of order подразумевает что кишки проца видны и если ты ловишь банальный page fault по выгруженной в своп странице или просто переключение контекста то выгружаешь не 2к контекста как на х86-64 даже со всеми avx512 а все ветки исполнения со всеми регистрами. 40 килобайт. Page fault еще не проблема но смена процесса критична для микроядерных ОС.

Нет имелось ввиду что у тебя есть некоторое количество бит под команду. Чем меньше этих бит ты используешь для своего кода тем быстрее будет твоя программа потому что как показывал Крис касперски земля ему пухом в своей книге современные процы довольно терпимо относятся к кэш-промахам по L1d но жестоко мстят за промах по коду.

Поэтому я считаю ошибкой 128битовые vliw команды итаника и бруска. Я выбрал 64бита потому что это степень двойки, на 32битах это уже не vliw а arm thumb, а вот на 64 можно впердолить 2, 3 или 4 команды. Причем не урезанные как arm thumb. В последней моей версии где 15бит на команду, 16 регистров адресуются. Плюс префиксы которые добавляют чтение памяти непосредственные операнды и прочее.

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