Создание экосистемы свободного ПО для процессоров «Эльбрус»

Исправить это можно либо поломав обратную совместимость и выкинув на помойку все работы по компилятору

Ну и ладно. :) Компилятор - не маски для кристалла, перепишут.

Покажи пример, выложи код на godbolt

Читай сюда: https://wiki.osdev.org/Memory_Management_Unit

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

с VLIW они могут лучше выполнять свою работу.

Не могут.

Просто повторю комментарий выше: Спасибо что привел так много аргументов, и ссылки на источники.

А зачем тогда было брать за основу VLIW

Потому что быстро и дёшево. Другое на тот момент было невыполнимо.

Бедняжка

Дальше этот шизобред не стал читать.

Потому что быстро и дёшево. Другое на тот момент было невыполнимо.

Это, мягко говоря, неправда, даже если они сами так говорят. МЦСТ всю историю делал еще и спарки, и сейчас, кстати говоря, продолжает. Их собственный спарк r2000 от 2018 года лишь чуть-чуть уступает в производительности вливу эльбрус-8св с тем же количеством ядер, при том, что потребляет в три раза меньше энергии.

VLIW, судя по всему, это просто «любимый» проект. Но средства на RISC, как и компетенции их разработки, у них были всегда. Важно понимать, что спарки мцст - это не купленные ядра, они разработаны самостоятельно, а спарками называются из-за купленной лицензии на архитектуру.

А ещё у них были SPARC наработки. Был бы прикол, если бы МЦСТ стали ведущим дизайнером чипов на SPARC и вытянули бы эту архитектуру после смерти солнцевских. Благо, софта вот под SPARC как раз хватает, да и архитектура не то чтобы прямо наивсратейшая.

Ну… лично мне тут парировать нечем: они сами несколько раз говорили, что, вероятно, взяв за основу спарк наработки, можно было бы получить коммерчески-пригодный результат в более быстрые сроки. Лично меня их коммерческие перспективы не заботят, это их головная боль. А вот если они таки завершат свои исследовательские проекты и выкатят годный влив - это будет шикарно. По этому, даже если это и была ошибка с точки зрения капитализации, то это, возможно, окажется прорывом с научной точки зрения. :)

А если добавить сюда необходимость пилить мегасложный компилятор? Всё ещё на порядок более простые?

А как вы думаете? Вот сейчас у них нет никаких возможностей заказывать что-либо на Тайване. И что? Уйти в отпуск? Или самое время допилить наконец компилятор?

Но если во VLIW-чип засунуть Out-of-Order, то возникает вопрос: а нахера, собственно, тут VLIW

Для МЦСТ vliw не является какой-то священной коровой, и очевидно что от чистого vliw’а они будут отходить, по вполне понятным причинам. Уже начинают отходить. Поэтому если сегодня ваши упрёки к разработчикам по поводу vliw ещё как-то прокатывают, то лет через 5-10 они, подозреваю, вообще будут что называется не в кассу.

То, что всем нужны те или иные аппаратные оптимизации - это и так очевидно… Теперь эту (очевидную для всех) проблему решили.

До-о-о. Настолько очевидно, что сначала интел шел по пути VLIW, и понял, что железо без ОоО не обойдется, а потом МЦСТ тоже решил побиться головой в ту же стену. Просто и те и другие думали, что подход хороший, а оказалось, что проще отдать всё это на откуп очень умному железу.

Если бы её не решили, влив можно было бы хоронить - тут спору нет.

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

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

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

Для МЦСТ vliw не является какой-то священной коровой, и очевидно что от чистого vliw’а они будут отходить, по вполне понятным причинам. Уже начинают отходить. Поэтому если сегодня ваши упрёки к разработчикам по поводу vliw ещё как-то прокатывают, то лет через 5-10 они, подозреваю, вообще будут что называется не в кассу.

Когда они отойдут от чистого VLIW, он вполне может превратиться в RISC.

До-о-о. Настолько очевидно, что сначала интел шел по пути

Я сказал «проблема очевидная», а не решение. Про её готовое решение я сам только сегодня и узнал из вашей ссылки про пульсон. :) До этого, я лишь теоретически говорил, что, дескать, надо её как-то решать… А, уже решили? Ну и замечательно. :)

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

Ну были там рассуждения, что эльбрусу это поможет не радикально. Что отставание сократится, но не достаточно. Что в нём и так говна хватает. :) Мне это не особо интересно, меня перспективы интересуют, а не проблемы с легаси. Не сумеют сам Эльбрус допинать - оставят хотя бы наработки в виде научных публикаций, алгоритмических наработок, патчей к компиляторам, и тд. Не всё делается с 1го раза.

Когда они отойдут от чистого VLIW, он вполне может превратиться в RISC.

Да я ведь уже объяснил, что ничего похожего на реальный ОоО, там не может быть по определению. Как они могут прийти к РИСКу, если в рисках не используются бандлы параллельных инструкций?

Теперь тебе уже и RISC не нравится? :)

Бандлы OoO не помеха. Добавляется еще одно ограничение, что commit/retire должен произойти для всего бандла, а не для единичной инструкции. Или добавить еще регистр для отслеживания частичного исполнения бандла.

То есть ты не можешь привести пример.

Пример чего? Настройки MMU? Серьёзно?

Получается, ты мало того что не знаешь даже самых поверхностных вещей о эльбрусе

Архитектура закрыта, как я могу о ней знать?

Просто повторю комментарий выше: Спасибо что привел так много аргументов, и ссылки на источники.

Повторюсь: источников выше натаскали целый тред.

Основной аргумент таков: если VLIW так хороша, почему же все – вообще все! – процессоры на ней такое тормозное говно?

Для МЦСТ vliw не является какой-то священной коровой

То есть, Эльбрус закопают?

Поэтому если сегодня ваши упрёки к разработчикам по поводу vliw ещё как-то прокатывают, то лет через 5-10 они, подозреваю, вообще будут что называется не в кассу.

Напомни мне об этом лет через 5-10. Если МЦСТ не сдохнет.

Пример чего?

Прямо в комментарии выше я писал. Ты рыбка?

Повторю:

Покажи пример использования 128 битного указателя с теми же свойствами, и ошибку с неинициализированной переменной

Все это жду от тебя на https://godbolt.org/

Архитектура закрыта, как я могу о ней знать?

Поверхностно знать можешь из открытых источников, их достаточно, что бы знать о теме нашего разговора.

Покажи пример использования 128 битного указателя с теми же свойствами, и ошибку с неинициализированной переменной

Я нигде не писал, что в x86 есть 128-битные указатели. Я написал, что ровно той же защиты можно добиться с помощью MMU. Остальное – твои фантазии.

Кстати, для тегирования указатели совершенно не должны быть 128-битными. В ARM хватает 64 бит. И прикол в том, что чип с MTE у меня вот прямо сейчас в телефоне стоит. А про Елбус я только на ЛОРе читаю и кекаю.

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

Поверхностно знать можешь из открытых источников, их достаточно, что бы знать о теме нашего разговора.

Из открытых источников я могу только сделать вывод, что Элбус не может, что на нём пилят бабло, и что это убожество никогда не взлетит.

Теперь тебе уже и RISC не нравится? :)

Из чего ты сделал этот вывод?

Да я ведь уже объяснил, что ничего похожего на реальный ОоО, там не может быть по определению.

Это было описано в статьях, а не ты объяснял.

Как они могут прийти к РИСКу, если в рисках не используются бандлы параллельных инструкций?

Уберут бандлы %)

Потому что быстро и дёшево. Другое на тот момент было невыполнимо.

А сейчас что мешает? Они пилить напильником этот VLIW ещё 30 лет будут, и не факт что допилят. Я склоняюсь к тому что не осилят, ресурсов не хватит. И потянет это ещё миллиарды. Сколько ещё нужно лет чтобы понять что это путь в никуда?

Бандлы OoO не помеха.

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

Добавляется еще одно ограничение, что commit/retire должен произойти для всего бандла, а не для единичной инструкции.

Ну, по крайней мере в пульсоне - да. Ссылки на киттсон пока не подвезли. :)

Или добавить еще регистр для отслеживания частичного исполнения бандла.

Я так понимаю, это и есть примерно то, что Бабаян запатентовал под названием vectorized instruction pointer. Но, как по мне, это тоже не беспроблемный вариант, ибо вот он как раз уже может привести и к межбандловому переупорядочиванию. :) Чего совсем не хотелось бы допускать.

Я сказал «проблема очевидная», а не решение.

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

Ну были там рассуждения, что эльбрусу это поможет не радикально. Что отставание сократится, но не достаточно. Что в нём и так говна хватает. :) Мне это не особо интересно, меня перспективы интересуют

Интересуют перспективы, но не интересуют проблемы. И как же ты собрался понимать перспективы, если не интересуешься проблемами? Вопрос риторический.

Основной аргумент таков: если VLIW так хороша, почему же все – вообще все! – процессоры на ней такое тормозное говно?

«Основной» ответ: ровно то же самое происходило с многоядерниками 20 лет назад, когда никто (даже Кнут) не понимал, а накуя оно? Ведь пришлось переучивать целое поколение программеров, и переписывать с нуля тонны однотридного старого кода.

Но это сделали!

Всех пошлют на… Эльбрус. Покорять.

«Основной» ответ: ровно то же самое происходило с многоядерниками 20 лет назад, когда никто (даже Кнут) не понимал, а накуя оно? Ведь пришлось переучивать целое поколение программеров, и переписывать с нуля тонны однотридного старого кода.

Очень дерьмовый ответ. Во-первых, про «никто не понимал» – лютая брехня. Хотя бы потому что многопроцессорные системы существовали с древних времён, так что SMP не было чем-то новым. А во-вторых, VLIW-чипы появились раньше многоядерных процессоров, но всё равно не взлетели. Itanium скоро будет 30 лет (или уже было, если считать с самого начала разработки), и за 30 лет он успел родиться, доказать всем неработоспособность VLIW как идеи и сдохнуть.

Но это сделали!

А быстрый VLIW не сделали лол

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

Интересное заключение, учитывая, что Интел все имеющиеся проблемы решил ещё в Пульсоне (но, на той исторической итерации, было уже поздно), а Бабаян, являясь частью Интел, запатентовал vectorized instruction pointers.

Не признали они неправоту. Просто не всё даётся с 1го раза.

Интересуют перспективы, но не интересуют проблемы. И как же ты собрался понимать перспективы, если не интересуешься проблемами? Вопрос риторический.

Конечно риторический, если МЦСТ пообещал их все решить. Нерешаемых пока не вижу. А связанных с конкретными реализациями и их наследием из прошлого - таких полно, и никто их не отрицает.

надо было делать совместимый с RISC-V чип, чтобы не переносить весь софт на планете на свою ни с чем не совместимую архитектуру. Лицензия, благо, позволяет.

ещё до «поднятия» живых имплементаций RISC-V, был готовый ынтерпайзный открытый всем ветрам ISA POWER9

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=452133d11a56ba520edce7870a06357f

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

И еще этот указатель может стать 64-битным, если звёзды сойдутся. В типичном коде, у которого 90% рантайма - это epoll и поиск по хешмапе, дополнительные проверки де факто бесплатные, в т.ч. на Эльбрусе. В нетипичном коде редко бывают сложные паттерны работы с памятью, и эксплойты в нём почти не встречаются.

Я нигде не писал, что в x86 есть 128-битные указатели. Я написал, что ровно той же защиты можно добиться с помощью MMU. Остальное – твои фантазии.

О как завертелся, ну давай показывай те же примеры с использованием MMU. Я жду.

Кстати, для тегирования указатели совершенно не должны быть 128-битными.

Ну показывай в ARM те же свойства указателя, на godbolt можно выбрать архитектуру. Или опять на самом деле ты не говорил, что это одно и тоже?

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

Конечно, разрешить бесконечный цикл, узнать заранее какие if будут работать а какие нет, все очень просто.

Из открытых источников я могу только сделать вывод, что Элбус не может, что на нём пилят бабло, и что это убожество никогда не взлетит.

Я тебе ссылку дал, там написано достаточно, что бы ты мог показать мне как через MMU будет достигаться тот же уровень, и как в ARM хватает 64 битов. Понять бы еще зачем правительство Англии стало финансировать проект где у указателя зачем то аж 128 битов в ARM.

Очень дерьмовый ответ. Во-первых, про «никто не понимал» – лютая брехня. Хотя бы потому что многопроцессорные системы существовали с древних времён, так что SMP не было чем-то новым.

Ну и что? Это как-то мешало линуксу и большинству юниксов использовать в те годы биг кернель лок? Не было тогда ни квалификации, ни соответствующих инструментов, типа фьютексов, быстрых контекст-свичей, и прочих причендалов. Но допилили.

и за 30 лет он успел родиться, доказать всем неработоспособность VLIW

Видно, что статью про пульсон вы так и не прочитали. Просто когда что-то запаздывает на 10-15 лет, то, в этом историческом контексте, оно уже не взлетает - это очевидный факт. Вот у пульсона уже не было возможности спасти итаник, но не по техническим причинам, а просто по тому, что тот поезд уже уехал.

То есть, Эльбрус закопают?

Эльбрус образца 2005 года закопают. Вместо него будет другой Эльбрус – с ОоО, ТБВ, ШК, блэкджеком и прочими полезными опциями.

Если МЦСТ не сдохнет.

Это едва ли. Если они в 90-е – 00-е не сдохли, то сегодня им тем более ничто не угрожает.

О как завертелся, ну давай показывай те же примеры с использованием MMU. Я жду.

Показать тебе исключение при обращении к неинициализированной странице? Держи доки: https://www.intel.com/content/www/us/en/docs/inspector/user-guide-linux/2022/uninitialized-memory-access.html

Конечно, разрешить бесконечный цикл, узнать заранее какие if будут работать а какие нет, все очень просто.

Зачем? Всё просто: если у тебя в каких-то code paths переменная используется до инициализации хотя бы в теории, просто кидаешь ошибку. Потому что стопудов это сишный говнокод.

Эльбрусы по своим возможностям постепенно приближаются к классическим risc-архитектурам. Разве это не то, чего ты хочешь? А чего же ты тогда хочешь?

Всё время — чего-то другого... ;)

Видно, что статью про пульсон вы так и не прочитали. Просто когда что-то запаздывает на 10-15 лет, то, в этом историческом контексте, оно уже не взлетает - это очевидный факт. Вот у пульсона уже не было возможности спасти итаник, но не по техническим причинам, а просто по тому, что тот поезд уже уехал.

Пульсон всё равно сливал по производительности цеонам при одинаковых техпроцессе и потреблении энергии. Никого бы он не спас даже близко.

Забавно, что ни один Itanium не работал быстрее 2.6GHz. Хотя цеоны уже тогда за 3.5GHz ушли.

1. Там нету неинициализированной переменной

2. Это не аппаратная реализация, твой код легко может потерять тег, например при передаче в С код и обратно

3. Он не соответствует 128 битному указателю из эльбруса по наполнению, у тебя просто языковая абстракция в виде slice, которая даже не распространяется на прочие типы

4. Никаких 128 битных указателей там нету

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

а разве не с этого начиналась эпоха линукса и спо? JFF

Интересное заключение, учитывая, что Интел все имеющиеся проблемы решил ещё в Пульсоне

Ага. Закапыванием итаниума. Просто они поняли, что раз им понадобился OoO, то нет смысла делать VLIW.

Нерешаемых пока не вижу.

Плохо смотришь.

Показать тебе исключение при обращении к неинициализированной странице?

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

Зачем? Всё просто: если у тебя в каких-то code paths переменная используется до инициализации хотя бы в теории, просто кидаешь ошибку. Потому что стопудов это сишный говнокод.

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

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

а вот цена - уже другое дело, должно быть доступно как и для покупателя, так и для его кошеля

Примеров я не дождусь, понятно.

Как и я не дождусь примеров работающего VLIW, который бы не тормозил как сучка :D

Так вот же, Эльбрус, свободная имплементация RISC-V от университета Англии сливает Эльбрус-8С.

На одном ядре он быстрее чем Ampere Altra Q80-30, хотя вот это не точно, пришлось через несколько цепочек сравнивать.

Ага. Закапыванием итаниума.

Здрасьте… Киттсон в каком году вышел? А в каком - пульсон?

Кстати, если кто вдруг не видел: Эволюция архитектуры за 6 поколений микропроцессоров Эльбрус. Смотреть с где-то с 5:04:20.

Здрасьте… Киттсон в каком году вышел? А в каком - пульсон?

В 2017. Это было 7 лет назад в рамках поддержки. С тех пор итаниум окончательно закопан.

Kittson has no microarchitecture improvements over Poulson; despite nominally having a different stepping, it is functionally identical with the 9500 series, even having exactly the same bugs, the only difference being the 133 MHz higher frequency of 9760 and 9750 over 9560 and 9550 respectively.

January 2019: Intel announces Itanium’s end of life with additional orders accepted until January 2020 and last shipments no later than July 2021.

Забавно, что ни один Itanium не работал быстрее 2.6GHz. Хотя цеоны уже тогда за 3.5GHz ушли.

Когда? Пульсон - 2012 год. И работал на 2.5. Ну а дальше его уже существенно и не тянули, так как было понятно, что этот поезд ушёл.

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

Горшенин закрыл магазин. Не знаю почему, видимо с гарантированными поставками не очень

Возможно дело в этом: https://www.cnews.ru/news/top/2024-02-28_rossijskij_proizvoditel

В 2017. Это было 7 лет назад в рамках поддержки. С тех пор итаниум окончательно закопан.

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