Сегодня на МНСК выступал студент нашего ВУЗа с докладом про 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
Вкратце — МЦСТ проблему сознает и что то пытается далать и возможно будут улучшения, но там много факторов играют, которые называть нельзя.
И вообще у товарища весьма неплохой цикл видео в том числе и про Эльбрус, без модного хейта, но и без пафоса, достаточно объективно.
я про работы по оптимизации JVM лет пять слышу, но судя по всему прогресса нет. Странные они в МЦСТ, вместо того что бы сказать, что у нас нет продакшен реди платформы, есть пртотип ковыряют какую-то ерунду силами двух разрабов и пропихивают в прод госсектору. такой подход лишь усиливает ощущение что у платформы нет перспектив.
по мне они должны набрать сотни девелоперов, портировать что-то типа JVM и показать, что оно не сливает в разы. после этого можно строить планы на массовое производство и пропихивание в госсектор, который явно не готов жрать x86 эмуляцию на кирпичах 65нм.
Здравствуйте, 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 (не знаю как правильно это по русски написать) для платформы.
Эм... Там линукс. Информация по системе комкнд процессора закрытая, но на гитхабе, вроде, есть какие-то доки полученные путем реверс-разработки.
Здравствуйте, rudzuk, Вы писали:
R>...но на гитхабе, вроде, есть какие-то доки полученные путем реверс-разработки.
Не смеши мои тапочки: в интеловском мануале больше 4х тысяч страниц, обычно он поставляется в трёх томах. Обычно к этому мануалу ещё нужен Optimization Reference Manual, к которому прилагается код на гитхабе. Они из года в год их обновляют и несколько десятилетий исправляют ошибки. Поэтому когда копаешь какую-то тему, то ещё и в томики erratas заглядываешь. Часть информации находится в сторонних книжках: их авторы добывали её из спецификаций, с помощью дебага и Intel VTune.
Опираться при разработке на то, что там наковыряли энтузиасты-реверсеры просто тупо.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, 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>Официальной доки по системе команд нет. Она закрытая, и это официальная позиция. Все что они предлагают — это готовый LLVM-бэкенд.
Значит это мертворождённый проект
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, rudzuk, Вы писали:
R>Ты компилятор для e2k писать собрался? Они предлагают готовый LLVM-бэкенд.
Я как минимум дебажить собрался, профилировать и оптимизировать.
Практика показывает, что иногда в асм заглядывать таки приходится, и знать возможности платформы весьма полезно. А ещё практика показывает, что иногда приходится дампы в WinDbg открывать...
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, rudzuk, Вы писали: R>Ты компилятор для e2k писать собрался? Они предлагают готовый LLVM-бэкенд.
Написать (или улучшить) JIT-компилятор для управляемой платформы без доступа к Reference Manual и Optimization Guide невозможно.
Написать эффективные Low-level библиотеки без доступа к Reference Manual и Optimization Guide невозможно.
Посмотрите на то, как пилится дотнет — там для любителей писать близко к железке завезли SIMD-интринсики для Интела и ARM.
Чтобы добиться аналогичного перформанса у банальных вещей вроде List<int>.IndexOf(), нужны аналогичные интринсики для e2k.
Всё это напилить нельзя ни энтузиастам без документации, ни МЦСТ в силу ограниченности ресурсов.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, 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, слава всевышнему, не единственная надежда отечественного импортозаместителя, хотя и самая доступная, пока.
Здравствуйте, rudzuk, Вы писали:
R>Впрочем, МЦСТ с их e2k, слава всевышнему, не единственная надежда отечественного импортозаместителя, хотя и самая доступная, пока.