1C объявила начало сборки для Linux в архитектуре Эльбрус

а всё ещё не всё.

А что, есть жизнь? Разработка? Хорошо если так.

А звук разве не унесли ещё на DSP в картах? Собственно обсчёт видео и картинок туда же.

бывает Очень Дорого, и оба слова с большой буквы

Хм, а это с чем связано? Только не надо говорить потому что гладиолус VLIW.

Иногда проще наладить выпуск старого железа, чем переписывать софт. Рассказывали такую байку начала-середины 90х. В DEC пришли представители Volvo с просьбой сделать что-нибудь с дисками, которые на их PDP-11 как раз посыпались. А то, говорят, работать не можем, PDPшки станками с ЧПУ рулят. А DEC в то время не то что PDP, они и VAXы-то уже на тот момент пару лет как перестали делать. Ну сейлы обрадовались, думают как они на Volvo будут альфы отгружать.... Потом пресейлы с инженерами подумали как они будут на эти альфы софт управляющий переносить и управляющие интерфейсы переделывать и поняли, что никак. Кончилось дело тем, что DEC выпустил для Volvo спецпартию MicroPDP-11. :)

иначе они бы так с NetBurst не обосрались

Они обосрались совсем по другой причине.

С шириной команды, длиной конвейера, сбросом кешей... С архитектурой процессора, наконец.

С шириной команды, длиной конвейера, сбросом кешей

А на x86 или ARM не надо сбрасывать кэши и конвееры? Или на Эльбрусе стейт в 100 раз больше?

похоже второе/ Стейт длиннее и ядра параллелят не так как остальные. Как я понимаю Эльбрус всеми своими ядрами обрабатывает одну команду, а остальные — каждое ядро свою.

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

Диска нынче столько, что две .text секции на фоне всей остальной херни не отсвечивают.

Как я понимаю Эльбрус всеми своими ядрами обрабатывает одну команду

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

Походу, потому, что ядра по другому работают и контекст длиннее. Все заняты обработкой одной команды и переключение контекста означает переключение контекста на всех ядрах. И еще механизм переключения контекста другой, не такой как у X86. Говорят, что больше похож на MIPS. И да, выходит, потому, что гладиолус :)

Подробности тут —

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&am...

Не, оно вот так, примерно, выглядит:

gleb@macpro ~ % ls /Applications/Emacs.app/Contents/MacOS
Emacs			bin			lib-x86_64-10_14
Emacs-arm64-11		bin-arm64-11		libexec
Emacs-arm64-11.pdmp	bin-x86_64-10_11	libexec-arm64-11
Emacs-x86_64-10_11	bin-x86_64-10_14	libexec-x86_64-10_11
Emacs-x86_64-10_11.pdmp	launch.rs		libexec-x86_64-10_14
Emacs-x86_64-10_14	lib-arm64-11
Emacs-x86_64-10_14.pdmp	lib-x86_64-10_11
gleb@macpro ~ % 

до того, что бы собрать мультиархитектурный бинарь «один на всех», даже они еще не дошли :)

А посреди длинной команды контекст переключить можно? Я же не сам это придумал, жаловались люди. Утверждается, что сам механизм переключения контекста похож больше на MIPS, чем на Штеуд и АРМ.

Да нет, в том числе и по этой. Они думали, что тормоза можно будет решить частотой.

Вот когда происходит «не в основном» - вот тогда начинается самый смак. Особенно, если это проприетарные модули ядра для кастомного железа. И бинари к ним, тоже проприетарные.

А вот надо сторониться такого железа, у которого модули ядра проприетарные.

Все еще хуже, на программиста :) — https://habr.com/ru/post/647165/

А что, есть жизнь? Разработка? Хорошо если так.

Посмотрел последнее, не очень понятно. С одной стороны Т-Платформы правда не очень, с другой появился Baikal Electronics.

Спасибо. Про тип счётчика не знал. Надо будет проверить на паре задач.

Кстати, пишут, что у Эльбруса есть какое-то систематическое и фиксированное penalty по времени на вызов процедуры, например. А контекст там тоже через CALL переключается.

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

Ок, в вещах вроде JVM в серверном режиме теоретически это может взлететь, если все грамотно сделать и прикрутить оптимизатор от суперкомилятора

У sun с его majc не взлетело

А звук разве не унесли ещё на DSP в картах?

В единичных случаях и для ограниченного применения.

Если для устойчивости программно-аппаратной экосистемы постоянно приходится затыкать дыры по всему стеку: в микрокоде, компиляторах, ОС и софте, то такая экосистема костыльная и есть.

Ещё раз повторяю: назвав передовые технологии «костылями» ты ничего не доказал. Должно быть что-то посерьёзнее обзывалки.

всяко лучше вендорлока на экосистемы без поддержки с запланированным устареванием в виде постоянных затормаживающих патчей

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

Это какие такие десятки архитектуры доступны в России для возможности независимого развития продуктов на них?

Примерно любые. Бери и развивай. Хоть открытые, хоть купи лицензию.

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

Ничего там не усложнит. Вон игры с денувой ломают, и это при том что там своя «архитектура» под каждую игру, не ограниченная никакими практическими соображениями. А твои эльбрусы - это одна архитектура, ломанули её быстрее чем денуву, лет 10 назад и с тех пор эти эксплоиты лежат и ждут своего часа. И ничего изменить МЦСТ, не поломав всё, не сможет.

Забавно читать, что ты считаешь, что это вендор лок.

А что, e2k не принадлежит МЦСТ? Они вон даже доки не особо дают, разве они позволяют любой американской фирмочке взять и начать производить эльбрус-совместимые процессоры?

Но ведь в Эльбрусе реализован динамический разрыв зависимостей между операциями обращения в память (DAM), плюс программно-аппаратная конвейеризация циклов со смещаемым регистровым окном и предподкачка линейно-регулярных данных в цикле (APB).

Но ведь это всё бесполезно, когда данные, которые ждали сразу, ну, может, в самом худшем случае через 10 тактов, приходится ждать 100+ тактов. Префетч, кстати, не только в эльбрусе есть, нашли чем удивить.

Не работает это всё и не будет работать никогда.

В общем-то практика показала, все VLIW-архитектуры благополучно сдохли.

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

Подробности тут

Это у меня есть, всё никак не дойдут руки почитать.

Все заняты обработкой одной команды и переключение контекста означает переключение контекста на всех ядрах

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

А посреди длинной команды контекст переключить можно

Вопрос интересный. Допустим что нет. Встречный вопрос: а посреди выполнения команд OoO переключить можно? Вероятно тоже нет и нужно дожидаться пока все ожидающие команды раздуплятся.

Кстати, пишут, что у Эльбруса есть какое-то систематическое и фиксированное penalty по времени на вызов процедуры, например

Звучит странно учитывая что вызов процедуры там поддерживается аппаратно гораздо лучше чем у x86.

контекст там тоже через CALL переключается

Он и на x86 через call переключается, если я правильно помню.

Мой друг хороший, известный тут как croco, говорил мне байки с их ВМК. Типа профессора-американцы высказывали питомцам Тихонова и Самарского «легкое недоумение», типа нахрена ж столько численных методов-то натворили? Оно столько не надо. Как бы, берешь вариант «для бедных» в виде библиотеки к книжке Numeric Recipes, если мало, то есть «дорого-багато» в виде NAG library. Ну MKL еще привернуть можно. Мы, кстати, приворачивали MKL к некой нейронной сети, там скалярное умножение было в количестве миллионов раз, так MKL и векторизация выигрыш дает заметный.

Звучит странно учитывая что вызов процедуры там поддерживается аппаратно гораздо лучше чем у x86.

Там call больше состояния сохраняет, а не только push ebp, mov ebp, esp.

Он и на x86 через call переключается, если я правильно помню.

JUMP FAR на TSS, по моим детским воспоминаниям. :)

Ну вот и для меня ХЗ, но есть ощущение, что e2k распараллеливает одну длинную команду по нескольким ядрам. Надо мануал курить, а он до сих пор полный секретный.

Там call больше состояния сохраняет, а не только push ebp, mov ebp, esp.

Я про то и говорю. В x86 переход по адресу гейта сохраняет контекст выполнения в защищённом режиме. Типа того.

e2k распараллеливает одну длинную команду по нескольким ядрам

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

Да, похоже ты прав. У меня какие-то сведения обрывочные от первых Эльбрусов остались. Действительно по 6 АЛУ на ядро, и ядра независимые. а вот то, что call иногда вынужден еще и регистровое окно на стеке сохранять накладняк.и вызывает.

А какой вообще смысл в Эльбрусах этих, когда TSMC больше не печёт их?

Зависит от типа задачи. Если бы всё реализовывалось просто перемножением или сводилось к матричному уравнению, но нет.

К тому же методы в библиотеках тоже не из пустоты появляются, их сначала должен кто-то разработать.

Пока никакого, а там посмотрим. Жизнь длинная.

Как я понимаю Эльбрус всеми своими ядрами обрабатывает одну команду

Не, ядра там классически работают, обычное SMP. Дорогое переключение контекста, в первую очередь, из-за монстроидального регистрового файла. Что вы хотели, когда есть 256 регистров и регистровые окна?

до того, что бы собрать мультиархитектурный бинарь «один на всех», даже они еще не дошли :)

Т.е. уже утратили навыки сборки FAT Binary? Лошары…

В общем-то практика показала, все VLIW-архитектуры благополучно сдохли.

Техасские TMS до сих пор живы. важное уточнение про «общего назначения».

Так вроде ж ещё на спарках для этого несколько наборов РОН для ядра и юзерспейса держали? Или я за давностью ковыряний всё попутал уже?

А что, e2k не принадлежит МЦСТ?

И что? А Linux не работает на других архитектурах? Или ПО для Linux можно собрать только для E2K?

А я и не знал, что у них было такое :) Чудеса, да и только. Ну странно, да. Хотя надо посмотреть на «родные» яббловские пакеты, может это сборщики емакса лошары. Завтра гляну, интересно.

Не, это сборщики Emacs'a — лошары, у фрайерфокса все хорошо:

gleb@macpro ~ % lipo -info /Applications/Firefox.app/Contents/MacOS/firefox
Architectures in the fat file: /Applications/Firefox.app/Contents/MacOS/firefox are: x86_64 arm64 
gleb@macpro ~ % 

смысл существования Эльбруса - это посадить Россию на МЦСТшный вендор лок и потом доить нас вечно

А в чем отличие от того, что нас вечно доит интл и амд? На самом деле эффект должен быть прямо противоположный. Увидят, что у нас свои процы есть, которые еще и на экспорт могут идти, которые и софтверно поддерживаются - начнут конкурировать, а не блокады устраивать.

Нам (прогерам) от этого всего только плюс. Будем код писать, портировать и т.д. А вот без процов мы нахер никому не нужны.

Так вроде ж ещё на спарках для этого несколько наборов РОН

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

Не, это сборщики Emacs’a — лошары

Просто они выше этого :D

А какой вообще смысл в Эльбрусах этих, когда TSMC больше не печёт их?

Их можно делать и по более старым техпроцессам. Которые доступны даже без многострадальной зеленоградской фабрики. Почему этого не делают — отдельная история.