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

В браузерах или pcre это дохлый номер

В браузерах тоже jit, в чём проблема? Более того для браузеров и вообще бытовой приложухи, КМК более актуально количество параллельных потоков исполнения.

существуют generic-сборки для x86_64, которые неплохо

ЯННП. Ассемблерный код в библиотеках в основном (я другого не видел никогда) делают ради векторизации на SIMD инструкциях. И там во-первых учитывают шедулинг (это просто т.к. задействуется один конкретный модуль проца), а во-вторых ясное дело, что оптимально векторизованный код будет быстрее обычной сборки.

В браузерах тоже jit, в чём проблема?

В том, что у тебя нет нескольких минут для генерации хорошего кода.

В свое время JIT-компиляцию через LLVM пытались прикрутить ко всем возможным ЯП. В WebKit в течение года LLVM использовали в качестве бэкэнда для финальной стадии JIT, которую использовали только для компиляции WASM и наиболее часто и долго выполняющегося JS-кода (например, тогда был в моде asm.js для компиляции из натива, для такого кода бы она сработала). Потом заменили на самописный компилятор B3, так как LLVM слишком медленно работает. Хотя качество оптимизации у LLVM лучше, с этим никто и спорить не пытался. Все остальные проекты по JIT’ованию скриптухи LLVM’ом загнулись по сходным причинам.

В серверной сегменте Epyc от AMD очень даже популярным становится,уже в первых позициях top500 появлялся. В ноябре 1, 3, 8, 9 места, а на втором не Intel даже, он только на 4 и 10 местах появляется в 10-ке.

В российском топ50 у AMD Epyc с 1 по 4 места.

Ассемблерный код в библиотеках в основном (я другого не видел никогда) делают ради векторизации на SIMD инструкциях

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

нет нескольких минут для генерации хорошего кода

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

Я когда ставлю powersave governor и т.о. тактовая фиксируется на 1.2ГГц не чувствую каких-то проблем в браузере. «Тяжёлые» сайты КМК более тяжелы с точки зрения потребления памяти, чем проца. Вряд ли снижение производительности, допустим, на 30% из-за отсутствия рантайм шедулера (и средней оптимизации при компиляции) будет большой практической проблемой.

Цены на POWER9-10 и SPARC64 со сравнимыми характеристиками не сильно лучше.

А есть пруфы про «сравнимые характеристики», если речь не о тепловыделении?

openssl целые алгоритмы на асме написаны

Я не в курсе для чего там это сделано, но уверен что не потому что кто-то хотел попрактиковаться в ассемблере и от балды навалял код (авось OoO вывезет). Это довольно специальный инструмент. Могу догадываться, что это сделано для того чтобы например отбить атаки «по анализу мощности», т.е. код специально так подобран, чтобы выравнять энергопотребление при операциях. Поэтому данный пример немного не в кассу.

(1) Там где OoO процессор, не получивший ещё данные для одной команды, просто отложит её и зависимые от неё и возьмётся за другую, VLIW будет стоять и ждать всеми своими блоками, даже если от результата зависшей команды ничего не зависит. (2) Поэтому VLIW абсолютно непригоден для больших частот.

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

Причём чем выше частоты, тем проблема критичнее: мало того что фиксированные задержки внешней памяти в наносекундах на больших частотах превращаются в больше тактов ожидания, так для больших частот ещё и требуется больше уровней кэша, а это добавляет ещё больше задержек, ведь запрос к Ln+1 кэшу делается после того как в Ln поискали и не нашли данные. В современных x86, например, начало обращения к внешней памяти происходит через 40+ тактов после попытки найти данные в L1.

Так этот механизм одинаков и для VLIW и для RISC/CISC. Почему для второго это норм, а для первого - целая проблема?

Вряд ли снижение производительности, допустим, на 30% из-за отсутствия рантайм шедулера (и средней оптимизации при компиляции) будет большой практической проблемой.

Но тогда условному хомячку, который на компе запускает образом браузер, поделки на Electron и игрушки с LuaJIT или какой-то еще скриптухой внутри, понадобится на 30% больше вычислительной мощности. А будет ли это проблемой, зависит от цены этих 30% и их влияния на энергопотребление, в теории все решаемо. Но все равно остается привкус копроэкономики.

Но есть альтернативный вариант - сделать трансляцию в духе Transmeta. Например, код браузера будет компилироваться для, например, RISC-V, и JIT будет под него же машкод выплевывать, а дальше транслятор будет в рантайме конвертировать машкод в VLIW-инструкции, загружая все ALU и выполняя хотя бы минимальный шедулинг. В принципе, у МЦСТ есть в разработке трнаслятор для x86, но я хз, насколько это хорошо работает, и х86 это точно не оптимальный вариант для «промежуточной» ISA.

Я вот глянул тесты производительности этих эльбрусов, а также способы его получения и использования, возник вопрос, возможно ответ лежит на поверхности. Если взять бесплатно на помойке древний интел уровня i7-6700k, то чем это будет хуже чем если бы я купил эльбрус?

У Эльбруса безумно дорогое переключение контекста, например. Типа переключаем контекст... И весь разогнанный VLIV-конвейер идет куда? Правильно, превращается во внезапно остановившийся метрошный эскалатор вместе со всей на нем толпой ,) И эта штука от частоты не зависит.

Значит что? Правильно, коль от частоты не зависит, значит ограничений у VLIW на частоту нет.

Я как-то принимал участие в разработке одного проприетарного компилятора (на букву «P» и ныне рипнувшегося:), так вот когда я сказал нашему директору, что PowerPC A2 (== вычислительные ноды BlueGene/Q) не поддердивает OOoE, он был очень растроен - ведь косяки шедулинга теперь никто не скроет. А в «самопальных» JIT’ах, напомню, шедулинг вообще не делают.

Но все равно остается привкус копроэкономики

Ну тут как бы щито поделать.

В принципе, у МЦСТ есть в разработке трнаслятор для x86, но я хз, насколько это хорошо работает

Я про это не заикался именно потому что хрен знает как оно там работает. С другой стороны это по факту тот же JIT вид сбоку, т.е. каких-то отдельных рассуждений не требует. Более того, если рассматривать это как идею в целом, т.е. некий промежуточный код который будет дооптимизироваться рантайм, то наверное можно придумать более удобный байткод конкретно под Эльбрус, а не мудохаться с копролитами типа x86.

Совершенно неинтересно что под Эльбрус, но позитивно что по линукс.

Если взять бесплатно на помойке древний интел уровня i7-6700k, то чем это будет хуже чем если бы я купил эльбрус?

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

Надеюсь, понятно объяснил.

ограничений у VLIW на частоту нет

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

Если взять бесплатно на помойке древний интел уровня i7-6700k, то чем это будет хуже чем если бы я купил эльбрус?

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

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

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

Но с этим сейчас небольшая проблемка - все бегут за лучшими техпроцессорами к TSMC, а нам туда путь заказан

Тут намечается более серьёзная проблемка – бежать скоро будет некуда вообще, т.к. улучшать дальше вообще не получится.

Ну да, дошли до атомов

Но с этим сейчас небольшая проблемка - все бегут за лучшими техпроцессорами к TSMC

Это не проблема, это её следствие. А сама проблема - в узколобии, кишечном мышлении и отсутствии фантазии с дерзостью.

Проще говоря, всевозможные иксперты только и могут, что «пук-среньк надо идти к TSMC, потому что Весь Мир™ так делает».

Помойка - списанное и по знакомству?

А сама проблема - в узколобии, кишечном мышлении и отсутствии фантазии вкупе с дерзостью.

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

Так у Интела есть реальная причина ехать по накатанной: у него и так всё ок. Но при этом почему-то строит свои фабрики в США 🙂

А когда ты не скован историей (грузом легаси и текущими успехами) - неумение выйти за общие шаблоны это оно самое и есть, скудоумие и холопство.

Поэтому я жду, когда у нас уже начнут развивать асинхронную вычислительную электронику.

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

Теоретическая база в российских универах уже проработана, а в железе все не спешат реализовывать. Все как обычно, а потенциал большой.

Боюсь, что придется еще и менять ст.228, без веществ такое не разработать

Вот веществ как раз не надо 😄 вопреки стереотипам, они очень редко приводят к хорошим результатам

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

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

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

Да, полученный бесплатно либо за смешные деньги

Самостiйный проц в первую голову нужен для ТАДАМ! магистрального сетевого оборудования и прочих критических применений. Потом для серверов. Потом уже для пекарен. Начали почему-то в обратном порядке, с предсказуемым разочарованием.

Байкал-Т – это «начали в обратном порядке» по-твоему?

Оч странный посыл. Так-то с учетом всяких jit и ИИ, потенциал видится большим.

Так-то уже даже дебилам понятно, что отнять у нас могут все и в любой момент.

Тоже вариант. Хотя имеющегося x86 железа большинству хватит надолго. Например я своим ноутом пользуюсь уже лет 10.

Так-то с учетом всяких jit и ИИ, потенциал видится большим.

Вот с jit у эльбрусов как раз конкретная проблема. Но только не с vliw, а с раздельными стеками из-за анальной озабоченности безопасностью. Надо списывать эльбрус. Там накуролесили акадЭмики. В итоге всё тормозит.

Сбер не смог, а вы смогли ? https://habr.com/ru/news/t/595467/

не смог, а вы смогли ?

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

Приведу пример. Postgresql для 1С дистрибутивный и Postgresql Pro для 1С. Под Эльбрус, естественно. Простейший тест показал выигрыш Pro на 30% сходу. А если ещё подумать? Ну и что лицензия, если оно того стоит? Так-то вот.

раздельными стеками

Это вообще никакая не проблема. Адресация и переходы на Эльбрусе гораздо мощнее и гибче. Там просто не нужен этот костыль с исполняемым стеком или закидыванием туда адреса возврата.

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

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

Может, ты хотел сказать, что VLIW не нужны высокие частоты, потому что современные известные реализации VLIW не очень то их утилизируют?

Что за глупость? Всем нужны высокие частоты, просто VLIW в них очень сильно страдает. Из этого следует, что VLIW не нужен. Представь, что ты проектируешь машину для гонок, которая разваливается при достижении высокой скорости. Вот это VLIW. И ни на какие «современные реализации» это не списать, тут всё упирается в основополагающий принцип VLIW. Если убрать то, что не позволяет эффективно работать на высоких частотах то процессор перестанет быть VLIW.

Так этот механизм одинаков и для VLIW и для RISC/CISC. Почему для второго это норм, а для первого - целая проблема?

Объяснение, почему это относительно небольшая проблема для OoO и огромная для VLIW ты отквотил выше.

JIT в рантайме код генерирует. Это проблема для эльбруса.

На это можно посмотреть и иначе: никаких недостатков в целом VLIW не имеет.

Нельзя так смотреть, так как VLIW имеет несовместимое с жизнью число недостатков. Он достоинств не имеет. Точнее так: он решает некоторую задачу на, условно, 80%, но эту же задачу решают на 70% другим методом, и на 50% третьим, при этом второй и третий метод совместимы между собой и поэтому в реальных существующих продуктах она решается комбинацией на 90%. VLIW - это тупиковая ветвь, изобретённая 50 лет назад, для других технологий, когда современные конкурирующие с ней решения просто не были ещё изобретены.

По недостаткам вцелом. Про зависимость от чистоты кода и, следовательно, неспособность к эмуляции и к JIT тебе уже написали. Это недостаток №1 и по-чеснаку его уже достаточно чтоб обходить VLIW стороной. Про очень плохое масштабирование по частотам я писал. Это №2. Ну и для красоты подкидываю №3: VLIW малопригодны для развития. Вот, скажем, Intel собирается проектировать новое поколение, берёт существующий софт и профилирует. И обнаруживает, что блок 1 постоянно простаивает, а блок 2 постоянно загружен. Значит узкое горлышко - это операции, выполняемые блоком 2. Ну и дальше думают, либо удвоят число блоков 2, либо оптимизируют их, чтоб пропускали больше инструкций, либо какую-то простенькую функцию, которая сейчас может выполняться на блоке 2, перенесут в блок 1 или блок 3. И вот выходит новое поколение процессоров и оно на тех же частотах вдруг начинает работать намного быстрее.

С VLIW так нельзя. Да, разработчики могут посмотреть и обнаружить, что VLIW-команды полупустые, в них для блока 1 постоянно операция NOP стоит, да, они могут точно так же или увеличить число/производительность блоков 2 или вынести часть функций в другие блоки, но старый код от этого работать быстрее не будет, придётся как минимум обновлять систему команд, обновлять компилятор, и сгенерированный новым компилятором код на старых процессорах вообще работать не будет.

Вот нафига вообще кому-либо такое счастье?

Это проблема для эльбруса

ЛОЛ, а ни чё что эффективная бинарная трансляция заявляется как фишка?

С VLIW так нельзя. Да, разработчики могут посмотреть и обнаружить, что VLIW-команды полупустые, в них для блока 1 постоянно операция NOP стоит, да, они могут точно так же или увеличить число/производительность блоков 2 или вынести часть функций в другие блоки, но старый код от этого работать быстрее не будет, придётся как минимум обновлять систему команд, обновлять компилятор, и сгенерированный новым компилятором код на старых процессорах вообще работать не будет.

У меня на компе стоит ОС, которая полностью компилируется из исходного кода, и которую можно легко пересобрать после любого обновления компилятора. То, что было проблемой в 2000-х в экосистеме Wintel, в реалиях Linux является проблемой проприетарщиков.

Ты вообще случайные фразы произносишь. Бинарная трансляция нужна для запуска x86 кода на эльбрусе. При чём здесь jit какой-нибудь джавы, джаваскрипта или дот нета? У тебя интернетик будет тормозить, потому что эльбрус не может нормально в jit для javascript. Т.е. офисное применение отпадает.

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

Причём это на криворукость разрабов из МЦСТ не списать: у Интела с Итаниумом была та же проблема.

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

На заборе тоже пишут. Нет там никаких проблем с JIT в Эльбрусе. А тем более если говорить про VLIW вообще.

плохое масштабирование по частотам я писал

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

Дядя ты дурак? VLIW ничего ждать не будет, т.к. все зависимости известны заранее и значение уже подгрузилось параллельно и заблаговременно (в т.ч. спекулятивно).

но старый код от этого работать быстрее не будет, придётся как минимум обновлять систему команд, обновлять компилятор, и сгенерированный новым компилятором код на старых процессорах вообще работать не будет

Крайне незначительная проблема на практике. Для мобильных систем решается так, как сделал Гугл с Android.

условный M1 может выполнять старый x86 код быстрее чем старые x86 процессоры

Ну ты и сказочник.

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

Вон, наши геологи/нефтяники в начале 2000х покупали софт написанный на SunOS, который был несовместим с солярисом, и чтоб он работал, покупали старые же сановские рабочие станции, потому что новые с SunOS несовместимы.

Так они даже под обыный проц собрать не могут …

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

Можно покупать софт только с исходниками. Наша экосистема - наши правила, несогласные могут идти лесом.

В процессорах legacy-подхода есть свои недостатки - для получения производительности необходимо опираться на костыли в кремнии: OoO, предсказатели переходов и т.д, это является проблемой т.к.:

Во-первых все быстрые реализации огорожены патентами, а без необходимого набора патентов и лицензий на костыли не сделать быстрого процессора в рамках legacy-подхода. Эльбрусам же совершенно побоку все эти патенты

Во-вторых в этих ускорителях вылезают все новые и новые дыры

В гугле забанили? Бенчи Розетты вполне находятся, вот например: https://www.anandtech.com/show/16252/mac-mini-apple-m1-tested/6

От 60% до 90% от натива.

Т.е. если M1 в новом компьютере у тебя быстрее старого в 1.5 раза (а при меньшем приросте как бы и апгрейдиться смысла нет), то старые программы как минимум не замедлятся.