Здравствуйте, 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 имеет какие-то перспективы — ну так, @#$, сделайте всё, чтобы эти перспективы реализовать!
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S> Я не готов оспаривать само архитектурное решение — может быть, это у Интела не взлетело, а у нас взлетит.
Вот интервью с человеком работавшим в Унипро, которая занимается джитом жабы под e2k.
S> Но я считаю, что раз уж сказали "а", надо говорить и "б". То есть если считаете, что VLIW имеет какие-то перспективы — ну так, @#$, сделайте всё, чтобы эти перспективы реализовать!
Видимо, возможность получить эти доки все же есть.
Здравствуйте, Философ, Вы писали:
Ф> К несчастью мы периодически сталкиваемся с багами компиляторов, и в VS C++ например, и ещё, и в GCC тоже
Ф> Расследовать такие проблемы без документации невозможно.
Я согласен, и полагаю, при реализации конкретного проекта есть возможность подписать кучу бумажек и получить заветную доку. Ну или, консультации специалистов МЦСТ.
Здравствуйте, 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_>>longson — mips ерунда, так толком и не взлетевшая и явно проигрывающая risc-v
V>В чём именно проигрывающая?
в частоте, longson это 2ghz, т.е. они умудрились примитивные mips команды до частоты vliw команд эльбруса затормозить
V>Что такого чудесного есть в risc-v?
у risc-v 5Ghz и он по тестам вполне на уровне с арм.
V>ИМХО, risc-v — сплошной набор компромиссов.
зато есть ядра и софт, просто бери и компануй. при этом скорость сравнима с арм, полагаю в той же java даже $100 четырехядерники уже уделают э16с.
Здравствуйте, 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, имея нехилое преимущество в техпроцессе.
Здравствуйте, 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+ лет уж можно было такие простые оптимизации реализовать, но весь пар ушел в погоню за нанометрами, которая, понятно, что не даст выигрыша на порядок, как компилятор.
