caxapa.ru :: Любой JIT-компилятор (.NET, Java, Lua, ECMAScript и другие) нужно писать почти с нуля. Особенно для экзотических VLIW-архитектур, коей является Эльбрус. Либо делать базовый порт, который уронет производительность в N раз, потому что будет всегда использовать только один исполнительный блок из нескольких.

lloyd (15.12.2021 10:08, просмотров: 341) ответил Kpoк на Вот очень хочется знать, что за софт, который впадлу переписать с нуля ради новой (предполагаем, хорошей) платформы? Ну вот поимённо?

Любой JIT-компилятор (.NET, Java, Lua, ECMAScript и другие) нужно писать почти с нуля. Особенно для экзотических VLIW-архитектур, коей является Эльбрус. Либо делать базовый порт, который уронет производительность в N раз, потому что будет всегда использовать только один исполнительный блок из нескольких.

Опять же, тезис в том, что Эльбрус - отвратительная платформа для General Computing. На VLIW хорошо ложатся только и только числодробительные задачи с принудительной векторизацией. То есть, когда вам нужно считать мегабайтные FFT без отвлечений на формошлепство. Для последнего намного лучше подходит любой RISC с предсказанием и спекулятивным выполнением кода.

Ответить

- Чего это? Они же на Ц пишутся. - Kpoк(15.12.2021 12:45)
  - Какая разница на чем они написаны? Они же создают машинный код для конкретной целевой платформы: x86, ARM, RISC-V или Эльбрус. Под каждую платформу - свой JIT компилятор. - LightElf(15.12.2021 12:50)
    - Там всё по-другому работает. Сначала Вы пишете компилятор, который любую команду языка Ц (например, но лучше Паскаля) переводит в код Эль-76. А потом весь говнокод на Яве и Питоне (и проч.) преводится в Ц, И уже потом в Эль-76. - Kpoк(15.12.2021 23:18)
      - Я, видимо, свою мыслю плохо излагаю. Для эффективной работы VLIW нужно изменять не просто код, а сам алгоритм. Компиляторы этого не умеют. Может какая нейросеть сможет, но встанет вопрос верификации результата. - LightElf(16.12.2021 14:37)
        
        Эвристики - это рак от мира разработки компиляторов. Это как у GCC было разное поведение в зависимости _количества_строчек_кода_ (sic!) в функции. Сейчас, с осознанием разработчиками компиляторов, что почти любой ЯП можно привести к функциональной форме, оптимизации стали более осмысленными. Но, чтобы оптимизации работали, нужно в стиле кода для TI C66x писать через строчку t_assert(...), говоря компилятору, что здесь "Я РАЗРЕШАЮ" допустить выровненность указателя и прочие lloyd(13 знак., 16.12.2021 14:43)
        
        Просто к компиляторным эвристикам нужен противовес — ебанистики. RxTx(1 знак., 17.12.2021 22:01, картинка)
        
        У меня как-то была история, на x86. Был кусок сишного кода, где время от времени нужен был синус. Код был старый, и программист для ускорения использовал таблицу с рассчитанными синусами. На Pentium 3 оказалось, что радикально быстрее синус таки считать, а не использовать таблицу. Причем выигрыш мог составить десятичный порядок. - LightElf(16.12.2021 15:02 - 15:25)
        
        Где-то пробегало, если не путаю, есть алгоритм, который на SSE считает синус за пару тактов, это быстрее чем из кеша готовый результат достать. - =AlexD=(16.12.2021 15:13)
        
        Ну там код на FPU был. Команда FSIN занимает под 100 тактов и не ломает конвейер, а промах мимо кэша при обращении к таблице - в разы больше и с конвейером какие-то неприятности получаются. - LightElf(16.12.2021 15:24)
      - Там - это где? JIT должен по определению компилить "на лету" и делать это быстро, порождая более-менее приличный машинный код. Хороший JIT-компилятор сделать - ни фига не лобио скушать. И сильно ли поможет транспилер, если даже официальный эльбрусовский Цэ компилятор генерирует так себе (примеры есть на том же хабре) код? - LightElf(16.12.2021 02:32)
        
        Для чего "приличный машинный код"? Для интернет-серфинга? Для котиков? Там сойдёт любой. А для двух-трех приличных задач можно и напрячься - написать хорошие проги. - Kpoк(16.12.2021 06:48)
        
        Сбер не захотел "напрячься". - LightElf(16.12.2021 14:27)
        
        Да пропади он пропадом! - Kpoк(16.12.2021 17:10)
        
        В кровавом энтерпрайзе таки считают производительность, потому что там не котики, а банковские транзакции, и их не один, а десятки-сотни тысяч в единицу времени. - lloyd(16.12.2021 07:28)
        
        Разным задачам - разные камни! Кстати, у банкиров скорее всего целочисленная арифметика? - Kpoк(16.12.2021 09:35)
        
        У банков JVM. Чего не умеет делать JVM - то не будет работать, хоть какой умный Эльбрус будет. Арифметика-то целочисленная, но, как правило, длинная. И между пользовательским кодом и ассемблером ну очень дофига слоёв. Код->Библиотеки->IR->ASM. lloyd(497 знак., 16.12.2021 10:08, ссылка)
        
        Интересно, но не весело. Видно, что компилятор старается как может, но из изначально последовательного алгоритма параллельность выдоить получается совсем не всегда - LightElf(16.12.2021 14:28 - 14:33)
        
        Механизм OoOE превращает любой CPU в параллельный на уровне последовательности инструкций, так что дело не в параллельности. - =AlexD=(16.12.2021 15:16)
        
        Сложность несопоставимая. OoOE на RISC-процессоре делается легко и непринужденно (сканируешь команды, распихиваешь по исполнительным блокам). VLIW не предполагает OoOE, он предполагает, что его сделал компилятор на этапе компиляции (к слову Hyper-Threading на x86_64 получился из-за того, что компилятор этого сделать нормально не может). - lloyd(16.12.2021 15:19)
        
        Вы немножко охренели. Сейчас блок OoOE занимает до половины CPU. Частоты давно у всех одинаковые и производительность практически полностью зависит от этого блока. И что-то не видно особой лёхкости, тот же Интел совершенствовал по 2% в год. Это самый-самый хайтек. И хотите сказать, что МЦСТ или Байкал с лёхкостью запилят его для RISC-V ? /facepalm/ - =AlexD=(16.12.2021 15:26)
        
        Ну, это, как сказать, оно в каком-то виде уже разработано? lloyd(1 знак., 16.12.2021 15:32, ссылка)
        
        В "каком-то виде" и компилятор для Эльбруса параллелит. Выж не в каком-то виде хотите, а непременно в конкурентоспособном. Давайте для начала дождёмся тестов одного с другим. Но я не верю в халяву. - =AlexD=(16.12.2021 15:37)
        
        угу, легко и непринуждённо. а схемы контроля зависимостей между инструкциями? а схемы чтобы подождать зависимую инструкцию, а учёт того, что конвейер не пуст частями... атомы без ОоО потому и намного проще и экономичнее. хоть и медленные до безобразия. - Mahagam(16.12.2021 15:24)
        
        да там проблем много, начиная даже с вопросов безопасности и заканчивая лицензионным огораживанием - =AlexD=(16.12.2021 15:27)
        
        Ну, что показывает, что любой VLIW на обычной стандартной программе прервращается в RISC - lloyd(16.12.2021 14:32)
        
        Да, причем в медленный RISC - LightElf(16.12.2021 14:33)
        
        Т.е. заведомый тупик. Получается что Эльбрусом должны заняться органы по признакам мошенничества, очковтирательства и некомпетентности, причем не только разработчиков но и тех кто ставил ТЗ и принимал работу. Ухлопали кучу времени и денег на заведомо тупиковое направление. Как когда то штаты навязали союзу СОИ а маразматики из ЦК радостно заглотили наживку. - 3m(16.12.2021 14:46)
        
        Как спецвычислитель, где софт разрабатывается с нуля под задачу - вполне норм и скорее всего прекрасен. Вполне может быть, что если взять какой-нибудь Postgres и вылизать на асме особо узкие места - тоже будет гуд. Но кто это будет делать, если МЦСТ до недавнего времени даже систему команд секретил. - LightElf(16.12.2021 14:52)
        
        Вы это серьезно "Postgres и вылизать на асме" ??? И так все 100500 пакетов из состава Debian ? - 3m(16.12.2021 15:12)
        
        На серверах редко крутятся все 100500 пакетов Debian и еще реже они как-то влияют на общую производительность. "Вылизать на асме" - это полемический задор :). Переписать некоторые куски так, чтобы они хорошо на VLIW ложились. - LightElf(16.12.2021 15:32)
        
        Нет, не тупик. У Техаса вон серию VLIW-DSP до сих пор не похоронили (хотя кажется, что желающих с ним связываться с каждым годом всё меньше, учитывая плюшки ARM). Просто не нужно пытаться гонять на VLIW-процессорах код общего назначения. Эльбрус хороший процессор, но только, как ускоритель математических операций. Кодеки всякие-там, ~~радиолокация~~. Для персоналок и серверов лучше брать что-то менее экзотическое, вроде ARM или RISC-V. - lloyd(16.12.2021 14:48)
        
        Да и для персоналок пойдёт. Главное, чтобы наперсоналено было нативным кодом. И полная ясность от государства, что в это стоит вкладывацца, а то, хуже будет. - mse homjak(16.12.2021 14:53)
        
        Зачем давиться кактусами, когда есть бесплатные открытые архитектуры, которые будут работать гарантированно лучше Эльбруса в задачах "нарисовать рабочий стол" - lloyd(16.12.2021 15:00)
        
        Был тут ролик от "Байкалов". Ихний главный по технике, весьма скептично относицца к "бесплатным открытым". И я ему, чота, верю. Роль государства в процессе - решающая.Если решено иметь своё, то на этом нужно стоять до логического конца. Достигать поставленной задачи. По крайней мере, этапов. Полумеры тока вредят и приводят к просёру денег и времени. - mse homjak(16.12.2021 15:11)
        
        +1000 - PlainUser(21.12.2021 22:07)
        
        Государство уже просрало кучу времени с Эльбрусом. Теперь выяснилось что надо начинать с начала. - 3m(16.12.2021 15:05)
        
        Не вижу ничего страшного в этом. Это опыт. - PlainUser(21.12.2021 22:07)
        
        Тем более есть смысл запрыгнуть на RISC-V и ехать на мировом энтузазизме, чтобы не терять время. - LightElf(16.12.2021 15:07)
        
        И чем он, в смысле "ПО для Сбера" лучше Эльбруса? - mse homjak(16.12.2021 15:13)
        
        Под него половина мира сосредоточенно пилит софт. - LightElf(16.12.2021 15:44)
        
        Какой? Очередной дистрибутив Линукса? Вот с Эльбрусом можно попасть в струю: гос-во финансирует разработку Росатым какого аналога Ансиса и непременное условие, что платформа будет Эльбрус и/или Байкал/комдив или как их там. - mse homjak(16.12.2021 18:06)
        
        В первую голову - средства разработки. Во вторую - да, линукс. Что важно, так как никаких внятных альтернатив ему сегодня нет. В третьих - всевсяческие СУБД, виртуализаторы, сетевые сервисы и прочая всеми любимая порнография. - LightElf(16.12.2021 18:15)
        
        Ну, дык, для Эльбрусов тоже напилено линуксов, баз датых и прочего. Если будет понятно, что это надолго, многие будут вкладываться в разработку инструментов и приложений, потому, что на этом можно будет заработать. Ещо раз: чтобы роспроцессоры стали актуальны, нужна железная воля государства. И больше ничего. - mse homjak(16.12.2021 18:21)
        
        Мы о разном говорим. - LightElf(16.12.2021 18:40)
        
        Хороший вопрос. Как бы не получилось "опять двойка". На планете есть только две архитектуры под которую пилят весь софт: это x86 и Arm (и то и другое в 32-х и 64-битных вариантах). Все остальное и близко не лежало и не факт что когда либо допилят все по под RISC-V. - 3m(16.12.2021 15:23)
        
        Да и для АРМа "ПО для Сбера" нет. И не факт, что будет. Ща как попрут какие Эпики на 128ядер 256 потоков @4ГГц и будет тот АРМ бедный. Исходить нужно из того, что для прогрессивного человечества мы своими не будем никогда. А "ПО для Сбера", это очень хороший кукан и инструмент влияния. - mse homjak(16.12.2021 15:31)
        
        Я думаю в хай перфомансе АРМы уже не влезут, вместо них полезут РИСК-5. - =AlexD=(16.12.2021 15:32)
        
        ХЗ, ИМХО, щас Р-5, чистый хайп. "Модно, стильно, молоджно". Вон, в ролеке про Байкал ихний дядька был однозначен: по сравнению с АРМ, все сосуд. Из тех, кого можно купить за деньги, ессно. - mse homjak(16.12.2021 18:01)
        
        Если говорить о конкретных доступных дизайнах - возможно. А если говорить об архитектуре для разработки своего ядра - то совсем не факт. - LightElf(16.12.2021 18:07)
        
        ХЗ... Но человек, профессионально пишущий чипы, наверняка понимает в архитектурах и их возможностях. Особенно, если он имеет возможность выбирать: купить лицензию или взять бесплатно но доработать напильником. - mse homjak(16.12.2021 18:16)
        
        Очевидно, что купить - быстрее. Что для относительно небольшой компании может быть критически важно. С другой стороны та же Alibaba ковыряет все подряд, бо денег жопой жуй. - LightElf(16.12.2021 18:37)
        
        Жрать электроэнергии будет меньше при той же или бОльшей производительности - lloyd(16.12.2021 15:15)
        
        Господа, вы реально сравниваете процессор, производимый по гораздо более "толстым" тех процесса с небольшой частотой и медленной (по современным меркам) памятью, и утверждаете, что всё дело в VLIW??? - =AlexD=(16.12.2021 15:21)
        
        А давайте сравним Эльбрус с старыми серверными процессорами, произведенными по тому же техпроцессу. ~~И он им сольет.~~ - LightElf(16.12.2021 15:37)
        
        Думаю это не сложно найти спеки. Сравнивайте. - =AlexD=(16.12.2021 15:39)
        
        Сравнивать спеки? А смысл? Все и так знают, что Эльбрус "быстрее всех в двух синтетических тестах". - LightElf(16.12.2021 15:46)
        
        (пожимает плечами) с точки зрения оценки архитектурных решений предложенный вами способ имеет хоть какой-то смысл, с точки зрения же коммерческой это всё пустое - =AlexD=(16.12.2021 16:06)
        
        "Сколько волка не корми, у слона все равно толще". Вот и интересно, есть ли смысл кормить волка. - LightElf(16.12.2021 16:10)
        
        Всем интересно, и не смотря на бла-бла-бла обсирателей эльбруса всё не выглядит совсем уж безнадёжным. Слишком они в секретность заигрались, это единственный зримый ощутимый недостаток конторы. - =AlexD=(16.12.2021 16:21)
        
        Посмотрим. Но думаю Байкал или Syntacore выглядят перспективнее. - LightElf(16.12.2021 21:37)
        
        Мы говорим, что 200 регистров и 15 исполнительных блоков на обычной программе ничего не делают, а за них ты платишь потреблением и площадью кристалла. Без Hyper-Threading нереально загрузить CPU на все исполнительные блоки. lloyd(84 знак., 16.12.2021 15:27)
        
        200 регистров и 15 исполнительных блоков есть в любом процессоре с OoOE и они не простаивают. - =AlexD=(16.12.2021 15:29)
        
        Что-бы в мобильном банке когда в кнопки тыкаешь, транзакции не подтупливали. - =AlexD=(16.12.2021 07:23)

Средства и методы разработки