Сегодня на МНСК выступал студент нашего ВУЗа с докладом про C0 — неоптимизирующий JIT-компилятор.
Вкратце — интерпретатор хотспотовской JVM на Эльбрусе работает из рук вон плохо. C1 для Эльбруса не написан; вместо него используется C2 с отключенными оптимизациями.
Он всего лишь вдвое быстрее честного C2, т.к. порождает множество временных структур (которые не использует, т.к. выполняет мало оптимизаций).
Это и мотивировало написание с нуля C0, который порождал бы код, работающий быстрее интерпретатора, но при этом тратил бы не так много времени на стартапе, как урезанный C2.
Доклад получил диплом I степени, практически единогласно
Плюсы: энтузиасты всё же потихоньку делают отечественную платформу пригодной к использованию.
Минусы: ни у широкой общественности, ни даже у ведущих ВУЗов доступа к железкам по-прежнему нет, несмотря на громкие выступления про "независимость" и "импортозамещение". Я было обрадовался, решил что нам в одну из лабораторий завезли-таки партию устаревших машинок — нет, докладчик просто работает в МЦСТ.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Плюсы: энтузиасты всё же потихоньку делают отечественную платформу пригодной к использованию. S>Минусы: ни у широкой общественности, ни даже у ведущих ВУЗов доступа к железкам по-прежнему нет, несмотря на громкие выступления про "независимость" и "импортозамещение". Я было обрадовался, решил что нам в одну из лабораторий завезли-таки партию устаревших машинок — нет, докладчик просто работает в МЦСТ.
Здравствуйте, Sinclair, Вы писали:
S>Плюсы: энтузиасты всё же потихоньку делают отечественную платформу пригодной к использованию.
Все таки не энтузиасты, а специалисты МЦСТ. Которых конечно тоже можно с некоторой натяжкой назвать энтузиастами. JVM там если что давно пилят, периодически доклады на всяких JUG делают, но там все очень сложно и долго.
По поводу закрытости и т.д, недавно кстати было видео и небольшим инсайдом: https://www.youtube.com/watch?v=O2VcGGbualY&t=1281s
Вкратце — МЦСТ проблему сознает и что то пытается далать и возможно будут улучшения, но там много факторов играют, которые называть нельзя.
И вообще у товарища весьма неплохой цикл видео в том числе и про Эльбрус, без модного хейта, но и без пафоса, достаточно объективно.
Здравствуйте, Sinclair, Вы писали:
S> Я не готов оспаривать само архитектурное решение — может быть, это у Интела не взлетело, а у нас взлетит.
Вот интервью с человеком работавшим в Унипро, которая занимается джитом жабы под e2k.
S> Но я считаю, что раз уж сказали "а", надо говорить и "б". То есть если считаете, что VLIW имеет какие-то перспективы — ну так, @#$, сделайте всё, чтобы эти перспективы реализовать!
Видимо, возможность получить эти доки все же есть.
Здравствуйте, rudzuk, Вы писали:
R>...но на гитхабе, вроде, есть какие-то доки полученные путем реверс-разработки.
Не смеши мои тапочки: в интеловском мануале больше 4х тысяч страниц, обычно он поставляется в трёх томах. Обычно к этому мануалу ещё нужен Optimization Reference Manual, к которому прилагается код на гитхабе. Они из года в год их обновляют и несколько десятилетий исправляют ошибки. Поэтому когда копаешь какую-то тему, то ещё и в томики erratas заглядываешь. Часть информации находится в сторонних книжках: их авторы добывали её из спецификаций, с помощью дебага и Intel VTune.
Опираться при разработке на то, что там наковыряли энтузиасты-реверсеры просто тупо.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, rudzuk, Вы писали:
R>Официальной доки по системе команд нет. Она закрытая, и это официальная позиция. Все что они предлагают — это готовый LLVM-бэкенд.
Значит это мертворождённый проект
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, rudzuk, Вы писали: R>Ты компилятор для e2k писать собрался? Они предлагают готовый LLVM-бэкенд.
Написать (или улучшить) JIT-компилятор для управляемой платформы без доступа к Reference Manual и Optimization Guide невозможно.
Написать эффективные Low-level библиотеки без доступа к Reference Manual и Optimization Guide невозможно.
Посмотрите на то, как пилится дотнет — там для любителей писать близко к железке завезли SIMD-интринсики для Интела и ARM.
Чтобы добиться аналогичного перформанса у банальных вещей вроде List<int>.IndexOf(), нужны аналогичные интринсики для e2k.
Всё это напилить нельзя ни энтузиастам без документации, ни МЦСТ в силу ограниченности ресурсов.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, elmal, Вы писали:
E>Здравствуйте, Gt_, Вы писали:
Gt_>>наверху были люди, что понимали что бы достать интел-амд хотя бы 0.01% от их бюджета придется вложить, но МЦСТ софт практически не пилило все эти годы, зачем-то выкатывая железяки неакутальных техпроцессов. накой было выкатывать 65нм с ddr4 в 2019 ? показать что отставая в техпроцессе в 7 раз софт эльбруса умудряется тормозить в 50+ раз ? E>Тормоза в 50+ раз касается в основном Java и подобном. Ибо сложности портирования. В том, что можно скомпилить из Си/C++ источников, в принципе производительность неплохая.
во, нашел ту статью: С помощью нехитрых приёмов мне удалось получить на Эльбрусе впечатляющее ускорение в 44 раза и приблизить время вычисления на Эльбрусе к результату на современном Intel и IBM POWER8, причём с помощью тех же оптимизаций результат на Intel был улучшен в 4.1 раза, а на IBM — в 11.5 раза https://habr.com/ru/articles/647165/
за 10+ лет уж можно было такие простые оптимизации реализовать, но весь пар ушел в погоню за нанометрами, которая, понятно, что не даст выигрыша на порядок, как компилятор.
я про работы по оптимизации JVM лет пять слышу, но судя по всему прогресса нет. Странные они в МЦСТ, вместо того что бы сказать, что у нас нет продакшен реди платформы, есть пртотип ковыряют какую-то ерунду силами двух разрабов и пропихивают в прод госсектору. такой подход лишь усиливает ощущение что у платформы нет перспектив.
по мне они должны набрать сотни девелоперов, портировать что-то типа JVM и показать, что оно не сливает в разы. после этого можно строить планы на массовое производство и пропихивание в госсектор, который явно не готов жрать x86 эмуляцию на кирпичах 65нм.
Здравствуйте, Sinclair, Вы писали:
S> R>Ты компилятор для e2k писать собрался? Они предлагают готовый LLVM-бэкенд.
S> Написать (или улучшить) JIT-компилятор для управляемой платформы без доступа к Reference Manual и Optimization Guide невозможно.
Этим занимается МЦСТ, у которой проблем с доками нет.
S> Написать эффективные Low-level библиотеки без доступа к Reference Manual и Optimization Guide невозможно.
S> Посмотрите на то, как пилится дотнет — там для любителей писать близко к железке завезли SIMD-интринсики для Интела и ARM.
Ты о Vector2/3/4/<> и вот этом всем? Не вижу тут необходимости у прикладного кода лезть напрямую к процу. Это уже дело джита, которым занимается тот, у кого все что для этого нужно есть.
S> Чтобы добиться аналогичного перформанса у банальных вещей вроде List<int>.IndexOf(), нужны аналогичные интринсики для e2k.
Насколько я понимаю, МЦСТ не хочет себя связывать обратной совместимостью т.к. архитектурно VLIW, это процессор управляемый компилятором. В следующей ревизии архитектуры они что-то поменяют, и все сторонние микрооптимизации пойдут лесом. На мой взгляд, зря вообще с этим вливом связались, интел же доказал, что не взлетает оно. Впрочем, МЦСТ с их e2k, слава всевышнему, не единственная надежда отечественного импортозаместителя, хотя и самая доступная, пока.
Здравствуйте, Философ, Вы писали:
Ф> К несчастью мы периодически сталкиваемся с багами компиляторов, и в VS C++ например, и ещё, и в GCC тоже
Ф> Расследовать такие проблемы без документации невозможно.
Я согласен, и полагаю, при реализации конкретного проекта есть возможность подписать кучу бумажек и получить заветную доку. Ну или, консультации специалистов МЦСТ.
Gt_>>longson — mips ерунда, так толком и не взлетевшая и явно проигрывающая risc-v
V>В чём именно проигрывающая?
в частоте, longson это 2ghz, т.е. они умудрились примитивные mips команды до частоты vliw команд эльбруса затормозить
V>Что такого чудесного есть в risc-v?
у risc-v 5Ghz и он по тестам вполне на уровне с арм.
V>ИМХО, risc-v — сплошной набор компромиссов.
зато есть ядра и софт, просто бери и компануй. при этом скорость сравнима с арм, полагаю в той же java даже $100 четырехядерники уже уделают э16с.
Здравствуйте, Gt_, Вы писали:
Gt_>я про работы по оптимизации JVM лет пять слышу, но судя по всему прогресса нет. Странные они в МЦСТ, вместо того что бы сказать, что у нас нет продакшен реди платформы, есть пртотип ковыряют какую-то ерунду силами двух разрабов и пропихивают в прод госсектору. такой подход лишь усиливает ощущение что у платформы нет перспектив. Gt_>по мне они должны набрать сотни девелоперов, портировать что-то типа JVM и показать, что оно не сливает в разы. после этого можно строить планы на массовое производство и пропихивание в госсектор, который явно не готов жрать x86 эмуляцию на кирпичах 65нм.
Набор сотен девелоперов крайне затруднён. Во-первых, просто набрать 100 девелоперов для чего угодно- уже тяжкая задача. Если же нам будут нужны люди, которые способны ковыряться в потрошках JVM и приносить при этом пользу, то задача ещё затрудняется.
Во-вторых, каждая сотня девелоперов — это ориентировочно 30 миллионов рублей ежемесячно на ФОТ и налоговые отчисления.
По мне они должны раздать сотни машинок и сотни тысяч эмуляторов во все мало-мальски значимые учебные центры, и регулярно организовывать открытые конкурсы.
И уже по результатам брать к себе единичных победителей или целые команды. Или вовсе не брать людей, а мёрджить полезный код в репозиторий.
Та же МНСК — 3 доклада об оптимизациях JVM под традиционные платформы (в спонсорах — Хуавей и подобные конторы), 1 доклад по Эльбрусу. В прошлом году было 3 доклада по оптимизации Котлина, 2 по оптимизации JVM, 0 по Эльбрусу.
Результат немного предсказуем, увы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, rudzuk, Вы писали:
R>Доступ к серверам на Эльбрусе МЦСТ предоставляет всем желающим, насколько мне известно. Недавно узнал, что они и дотнет портировали https://forum.ixbt.com/topic.cgi?id=8:26455:84411#84411
А у кого есть доступ к документации и как его получить? Маловато доступа к серверам — нужен software developers reference manual (не знаю как правильно это по русски написать) для платформы.
Всё сказанное выше — личное мнение, если не указано обратное.
S>Набор сотен девелоперов крайне затруднён. Во-первых, просто набрать 100 девелоперов для чего угодно- уже тяжкая задача. Если же нам будут нужны люди, которые способны ковыряться в потрошках JVM и приносить при этом пользу, то задача ещё затрудняется.
за десятилетие вполне можно было набрать 100 девелоперов.
S>Во-вторых, каждая сотня девелоперов — это ориентировочно 30 миллионов рублей ежемесячно на ФОТ и налоговые отчисления.
наверху были люди, что понимали что бы достать интел-амд хотя бы 0.01% от их бюджета придется вложить, но МЦСТ софт практически не пилило все эти годы, зачем-то выкатывая железяки неакутальных техпроцессов. накой было выкатывать 65нм с ddr4 в 2019 ? показать что отставая в техпроцессе в 7 раз софт эльбруса умудряется тормозить в 50+ раз ?
это удалось. теперь на том же верху много вопросов о перспективах, если рядом уже готовые байкалы, risc-v с уже готовым софтом.
а ведь догнать и перегнать с гарантированным отставанием в техпроцессе на самом деле лишь только у эльбруса шанс.
Здравствуйте, Философ, Вы писали:
R>>Доступ к серверам на Эльбрусе МЦСТ предоставляет всем желающим, насколько мне известно. Недавно узнал, что они и дотнет портировали https://forum.ixbt.com/topic.cgi?id=8:26455:84411#84411
Ф>А у кого есть доступ к документации и как его получить? Маловато доступа к серверам — нужен software developers reference manual (не знаю как правильно это по русски написать) для платформы.
Эм... Там линукс. Информация по системе комкнд процессора закрытая, но на гитхабе, вроде, есть какие-то доки полученные путем реверс-разработки.
Здравствуйте, Gt_, Вы писали:
Gt_>наверху были люди, что понимали что бы достать интел-амд хотя бы 0.01% от их бюджета придется вложить, но МЦСТ софт практически не пилило все эти годы, зачем-то выкатывая железяки неакутальных техпроцессов. накой было выкатывать 65нм с ddr4 в 2019 ? показать что отставая в техпроцессе в 7 раз софт эльбруса умудряется тормозить в 50+ раз ?
Тормоза в 50+ раз касается в основном Java и подобном. Ибо сложности портирования. В том, что можно скомпилить из Си/C++ источников, в принципе производительность неплохая.
Gt_>>наверху были люди, что понимали что бы достать интел-амд хотя бы 0.01% от их бюджета придется вложить, но МЦСТ софт практически не пилило все эти годы, зачем-то выкатывая железяки неакутальных техпроцессов. накой было выкатывать 65нм с ddr4 в 2019 ? показать что отставая в техпроцессе в 7 раз софт эльбруса умудряется тормозить в 50+ раз ? E>Тормоза в 50+ раз касается в основном Java и подобном. Ибо сложности портирования. В том, что можно скомпилить из Си/C++ источников, в принципе производительность неплохая.
да сыро там еще, была статья на хабре, где чувак просто взял какой-то бенчмарк, в паре мест код из методов затащил в мейн и получил прибавку в десятки раз. сходу не нашел статьи, помню у него еще был какой-то хреновый э16с, где он отключал кеш.
Здравствуйте, rudzuk, Вы писали:
R>Ты компилятор для e2k писать собрался? Они предлагают готовый LLVM-бэкенд.
Я как минимум дебажить собрался, профилировать и оптимизировать.
Практика показывает, что иногда в асм заглядывать таки приходится, и знать возможности платформы весьма полезно. А ещё практика показывает, что иногда приходится дампы в WinDbg открывать...
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, rudzuk, Вы писали:
R>Впрочем, МЦСТ с их e2k, слава всевышнему, не единственная надежда отечественного импортозаместителя, хотя и самая доступная, пока.
Здравствуйте, rudzuk, Вы писали:
S>> Посмотрите на то, как пилится дотнет — там для любителей писать близко к железке завезли SIMD-интринсики для Интела и ARM.
R>Ты о Vector2/3/4/<> и вот этом всем? Не вижу тут необходимости у прикладного кода лезть напрямую к процу. Это уже дело джита, которым занимается тот, у кого все что для этого нужно есть.
К несчастью мы периодически сталкиваемся с багами компиляторов, и в VS C++ например, и ещё, и в GCC тоже
Расследовать такие проблемы без документации невозможно.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, rudzuk, Вы писали:
R>Этим занимается МЦСТ, у которой проблем с доками нет.
У них проблемы с численностью персонала. Пока что даже для JVM, которую они пилят далеко не первый год, есть полтора джита.
R>Ты о Vector2/3/4/<> и вот этом всем? Не вижу тут необходимости у прикладного кода лезть напрямую к процу. Это уже дело джита, которым занимается тот, у кого все что для этого нужно есть.
Я обо всём неймспейсе System.Runtime.Intrinsics и его под-неймспейсах.
Например, https://learn.microsoft.com/en-us/dotnet/api/system.runtime.intrinsics.x86.avx2
Никогда в жизни джит не сможет всё это эффективно использовать. Та же автовекторизация в java работает так себе. И это неслучайно — джит работает в условиях ограниченного времени, он не может себе позволить длинные оптимизации.
В дотнете грамотное применение ручной векторизации позволяет объехать автовекторизатор С++.
Как минимум — на интеловской платформе. На e2k, полагаю, эффект будет ещё заметнее.
Кстати, часть докладов на всё той же МНСК была как раз про исследования AOT-компиляторов для Java, в том числе и с более агрессивным инлайнингом, чем у JIT.
Повторю очевидную мысль: чтобы подобные вещи попадали в эльбрусовую JVM, с ней должны экспериментировать не полтора магистранта в МЦСТ, а 20-50 команд по всей РФ.
S>> Чтобы добиться аналогичного перформанса у банальных вещей вроде List<int>.IndexOf(), нужны аналогичные интринсики для e2k. R>Насколько я понимаю, МЦСТ не хочет себя связывать обратной совместимостью т.к. архитектурно VLIW, это процессор управляемый компилятором. В следующей ревизии архитектуры они что-то поменяют, и все сторонние микрооптимизации пойдут лесом.
В итоге сторонние микрооптимизации идут лесом прямо сейчас, не дожидаясь изменений в следующей ревизии архитектуры. R>На мой взгляд, зря вообще с этим вливом связались, интел же доказал, что не взлетает оно. Впрочем, МЦСТ с их e2k, слава всевышнему, не единственная надежда отечественного импортозаместителя, хотя и самая доступная, пока.
Я не готов оспаривать само архитектурное решение — может быть, это у Интела не взлетело, а у нас взлетит.
Но я считаю, что раз уж сказали "а", надо говорить и "б". То есть если считаете, что VLIW имеет какие-то перспективы — ну так, @#$, сделайте всё, чтобы эти перспективы реализовать!
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, novitk, Вы писали:
n> R>Впрочем, МЦСТ с их e2k, слава всевышнему, не единственная надежда отечественного импортозаместителя, хотя и самая доступная, пока.
n> A что еще? Байкал?
Из реально существующих Байкал. На перспективу — RISC-V (в 2021 годы были планы уже к 2025 выпустить сервера на процессорах с этой архитектурой).
Здравствуйте, rudzuk, Вы писали:
R>Из реально существующих Байкал.
Для Байкала остановлено не только производство, но и покупка лицензионных ядер. И чтобы было представления о ресурсах, которые нужны для разработки собственных ядер. В мире осталось ровно две компании, кроме самой ARM, которые в состоянии разработать самостоятельные ядра на этой архитектуре — Apple и Cavium. Все остальные отказались, последним был Qualcomm.
R>На перспективу — RISC-V (в 2021 годы были планы уже к 2025 выпустить сервера на процессорах с этой архитектурой).
У рогозинской лунной базы больше шансов.
Здравствуйте, rudzuk, Вы писали:
n>> У рогозинской лунной базы больше шансов. R>Поживем-увидим. Все равно другого выхода у нас нет.
Чем RiskV лучше чем ARM? IP брать негде и надо делать свое. Для Байкала есть хоть какой-то задел.
Выход у РФ один. Покупать процы(армы, а не подобный по бессмысленности Эльбрусу Loongson) у китайцев.
Здравствуйте, novitk, Вы писали:
n> R>Поживем-увидим. Все равно другого выхода у нас нет.
n> Чем RiskV лучше чем ARM? IP брать негде и надо делать свое. Для Байкала есть хоть какой-то задел.
"Для некоторых отраслей это [недостаток JVM] неприемлемо".
Софт придумали, чтобы меньше зависить от железа. Теперь стали рабами софта.
За что боролись, на то и напоролись.
Gt_>>по мне они должны набрать сотни девелоперов, портировать что-то типа JVM и показать, что оно не сливает в разы.
V>Всё еще идет активная разработка архитектуры. V>Её нельзя назвать устаканившейся.
да ладно. она 20 лет как устаканилась. мне кажется даже инструкций не добавляли 20 лет. весь бюджет ушел на бессмысленные адаптации на 40 и 65нм, а на главный вопрос, не тухляк ли вкладываться в vliw и шедулинг и оптимизации на этапе компиляции, так ответа и нет, потому как в компилятор они так и ничего не вложили.
V>У китайцев есть тоже свой проект, по которому они не торопятся раскрывать спецификации, бо архитектура еще не устаканилась.
я уверен, что про все их процы слышал, начиная с амд ryzen клонов, заканчивая longson — mips ерунда, так толком и не взлетевшая и явно проигрывающая risc-v
Здравствуйте, novitk, Вы писали:
N>Чем RiskV лучше чем ARM? IP брать негде и надо делать свое. Для Байкала есть хоть какой-то задел. N>Выход у РФ один. Покупать процы(армы, а не подобный по бессмысленности Эльбрусу Loongson) у китайцев.
Про самолеты раньше тоже так говорили. Однако вот, летают помаленьку...
Здравствуйте, Gt_, Вы писали:
Gt_>>>longson — mips ерунда, так толком и не взлетевшая и явно проигрывающая risc-v
V>>В чём именно проигрывающая? Gt_>в частоте, longson это 2ghz, т.е. они умудрились примитивные mips команды до частоты vliw команд эльбруса затормозить
Откуда MIPS-опкоды примитивные?
Они полнее и упорядоченней, чем опкоды x86, чем-то напоминают систему команд DEC своей ортогональностью к файлу регистров, что позволило отказаться от микрокода при реализации этой архитектуры.
Там всей "примитивности", что отказались в первых версиях от умножения/деления, дабы все инструкции имели одинаковый тайминг, но эти времена закончились еще в первой половине 90-х, бо пошли уже и целочисленные умножение/деление, и достаточно длинные конвейеры, и ассоциативная кеш-память, и переименование регистров, и блоки предсказаний ветвлений, и сопроцессоры с плавающей точкой и т.д. (стандартов MIPS на сегодня более десятка) — в общем, топовые MIPS-процы стали суперскалярами.
А когда пошли 64-битные MIPS (первые 64-битные процы в истории, если что), то набор их команд стал тоже одним из самых широких.
Как тебе условные прерывания?
В любом случае, R8000 от 1994-го уже был одним из самых суперскаляров на рынке, на уровне спарков, R10000 вообще был самой пушкой, использовался для рабочих станций, а развитие — DEC Alpha, стал самым быстрым процом в те годы — нагибал как тузик грелку интелловские глуповатые пни более чем вдвое. ))
В общем, ты что-то путаешь...
Примитивным изначально являлся VLIW, бо это то же самое, что RISC, только для сигнальных процов изначально — VLIW содержали опкоды для нескольких автоматов в одном слове.
VLIW Эльбруса — это не есть классический RISC-подобный VLIW, который давал команды одному АЛУ, одному умножителю или нескольким управляющим автоматам (сдвиговым регистрам, если умножение выполнялось программно через сложение единиц со сдвигом), у Эльбруса это параллелизм на уровне железа — несколько АЛУ и несколько управляющих автоматов. Вместо OoO-исполнения в сочетании с переименованием регистров, Эльбрус использует рекордную на рынке спекулятивность исполнения большой размерности (множество порождаемых ветвлений — дерево вариантов), что позволяет делать вычисления с последующим ветвлением за один шаг ("проигравшая" ветка ветвления отбрасывается, т.е. отбрасываются все вычисления с ней) — именно поэтому Эльбрус на более низкой тактовой бьёт топовые архитектуры интел/амд, что конвейер на условных переходах не сбрасывается. Плюс туда же явная подгрузка ассоциативного кеша, что можно избежать задержек на когерентности кеша с внешим ОЗУ и т.д.
Эльбрус тормозит по тактовой не потому что сложнее CISC интела/амд, а потому что отсутствует возможность "вылизывать" разводку собсно кристалла с учётом техпроцесса.
Т.е. потому что нет прямого доступа к техпроцессу.
Там потенциал увеличения тактовой примерно вдвое БЕЗ пересмотра архитектуры, только за счёт доводки, собсно, матрицы кристалла.
И это при нынешних нормах.
А если взять передовые нормы 6 нм?
У китайцев схожая проблема для loоngson — недоступны топовые технологии реализации кристалла из-за санкций США, каким-то образом они умудряются нагибать Тайвань, бгг...
В том числе по этому Китаю имеет смысл взять Тайвань полностью под свою юрисдикцию.
V>>Что такого чудесного есть в risc-v? Gt_>у risc-v 5Ghz и он по тестам вполне на уровне с арм.
Т.е. уступает Эльбрусу примерно вдвое-трое?
V>>ИМХО, risc-v — сплошной набор компромиссов. Gt_>зато есть ядра и софт, просто бери и компануй.
Да без проблем, но это для "туповатой" ниши, типа периферии, принтеров, роутеров и т.д.
Вычислительные модули, скажем, для космоса и военки на risc-v не построишь.
А на Эльбрусе или Loongson — запросто, для этого их и делали.
Gt_>при этом скорость сравнима с арм, полагаю в той же java даже $100 четырехядерники уже уделают э16с.
Так арм проигрывает кратно Эльбрусу.
Вот как будет 20 GHz на армах — приходите.
V>Примитивным изначально являлся VLIW, бо это то же самое, что RISC
чувак, твой уровень настолько низок, что даже потешаться не интересно. RISC и VLIW четко противоположные лагеря. MIPS это классика RISC семейства, в соответствии со своей идеологии не имеет даже MMX команд, на столько они там примитивны. у MIPS один такт — одна инструкция, VLIW же за такт множество инструкций выполняет. китайца явно не смог найти инженеров, раз их MIPS работает на той же частоте, что и VLIW, имея нехилое преимущество в техпроцессе.
https://forum.ixbt.com/topic.cgi?id=8:26455:84411#84411
