Kpoк (15.12.2021 12:45, просмотров: 337) ответил lloyd на Любой JIT-компилятор (.NET, Java, Lua, ECMAScript и другие) нужно
писать почти с нуля. Особенно для экзотических VLIW-архитектур,
коей является Эльбрус. Либо делать базовый порт, который уронет
производительность в N раз, потому что будет всегда использовать
только один исполнительный блок из нескольких.-
- Какая разница на чем они написаны? Они же создают машинный код для
конкретной целевой платформы: 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)
- Эвристики - это рак от мира разработки компиляторов. Это как у GCC
было разное поведение в зависимости _количества_строчек_кода_
(sic!) в функции. Сейчас, с осознанием разработчиками компиляторов,
что почти любой ЯП можно привести к функциональной форме,
оптимизации стали более осмысленными. Но, чтобы оптимизации
работали, нужно в стиле кода для TI C66x писать через строчку
t_assert(...), говоря компилятору, что здесь "Я РАЗРЕШАЮ" допустить
выровненность указателя и прочие lloyd(13 знак., 16.12.2021 14:43)
- Там - это где? 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, ссылка)
- угу, легко и непринуждённо. а схемы контроля зависимостей между
инструкциями? а схемы чтобы подождать зависимую инструкцию, а учёт
того, что конвейер не пуст частями... атомы без ОоО потому и
намного проще и экономичнее. хоть и медленные до безобразия. - Mahagam(16.12.2021 15:24)
- да там проблем много, начиная даже с вопросов безопасности и заканчивая лицензионным огораживанием - =AlexD=(16.12.2021 15:27)
- Вы немножко охренели. Сейчас блок OoOE занимает до половины CPU.
Частоты давно у всех одинаковые и производительность практически
полностью зависит от этого блока. И что-то не видно особой
лёхкости, тот же Интел совершенствовал по 2% в год. Это самый-самый
хайтек. И хотите сказать, что МЦСТ или Байкал с лёхкостью запилят
его для RISC-V ? /facepalm/ - =AlexD=(16.12.2021 15:26)
- Сложность несопоставимая. OoOE на RISC-процессоре делается легко и
непринужденно (сканируешь команды, распихиваешь по исполнительным
блокам). VLIW не предполагает OoOE, он предполагает, что его сделал
компилятор на этапе компиляции (к слову Hyper-Threading на x86_64
получился из-за того, что компилятор этого сделать нормально не
может). - lloyd(16.12.2021 15:19)
- Ну, что показывает, что любой 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)
- Нет, не тупик. У Техаса вон серию 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)
- Ну, дык, для Эльбрусов тоже напилено линуксов, баз датых и прочего.
Если будет понятно, что это надолго, многие будут вкладываться в
разработку инструментов и приложений, потому, что на этом можно
будет заработать. Ещо раз: чтобы роспроцессоры стали актуальны,
нужна железная воля государства. И больше ничего. - mse homjak(16.12.2021 18:21)
- В первую голову - средства разработки. Во вторую - да, линукс. Что
важно, так как никаких внятных альтернатив ему сегодня нет. В
третьих - всевсяческие СУБД, виртуализаторы, сетевые сервисы и
прочая всеми любимая порнография. - LightElf(16.12.2021 18:15)
- Какой? Очередной дистрибутив Линукса? Вот с Эльбрусом можно попасть
в струю: гос-во финансирует разработку Росатым какого аналога
Ансиса и непременное условие, что платформа будет Эльбрус и/или
Байкал/комдив или как их там. - mse homjak(16.12.2021 18:06)
- Хороший вопрос. Как бы не получилось "опять двойка". На планете
есть только две архитектуры под которую пилят весь софт: это 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)
- ХЗ, ИМХО, щас Р-5, чистый хайп. "Модно, стильно, молоджно". Вон, в
ролеке про Байкал ихний дядька был однозначен: по сравнению с АРМ,
все сосуд. Из тех, кого можно купить за деньги, ессно. - mse homjak(16.12.2021 18:01)
- Я думаю в хай перфомансе АРМы уже не влезут, вместо них полезут
РИСК-5. - =AlexD=(16.12.2021 15:32)
- Да и для АРМа "ПО для Сбера" нет. И не факт, что будет. Ща как
попрут какие Эпики на 128ядер 256 потоков @4ГГц и будет тот АРМ
бедный. Исходить нужно из того, что для прогрессивного человечества
мы своими не будем никогда. А "ПО для Сбера", это очень хороший
кукан и инструмент влияния. - mse homjak(16.12.2021 15:31)
- Жрать электроэнергии будет меньше при той же или бОльшей
производительности - 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)
- Всем интересно, и не смотря на бла-бла-бла обсирателей эльбруса всё
не выглядит совсем уж безнадёжным. Слишком они в секретность
заигрались, это единственный зримый ощутимый недостаток конторы. - =AlexD=(16.12.2021 16:21)
- "Сколько волка не корми, у слона все равно толще". Вот и интересно,
есть ли смысл кормить волка. - LightElf(16.12.2021 16:10)
- (пожимает плечами) с точки зрения оценки архитектурных решений
предложенный вами способ имеет хоть какой-то смысл, с точки зрения
же коммерческой это всё пустое - =AlexD=(16.12.2021 16:06)
- Сравнивать спеки? А смысл? Все и так знают, что Эльбрус "быстрее
всех в двух синтетических тестах". - LightElf(16.12.2021 15:46)
- Думаю это не сложно найти спеки. Сравнивайте. - =AlexD=(16.12.2021 15:39)
- Мы говорим, что 200 регистров и 15 исполнительных блоков на обычной
программе ничего не делают, а за них ты платишь потреблением и
площадью кристалла. Без Hyper-Threading нереально загрузить CPU на
все исполнительные блоки. lloyd(84 знак., 16.12.2021 15:27)
- 200 регистров и 15 исполнительных блоков есть в любом процессоре с OoOE и они не простаивают. - =AlexD=(16.12.2021 15:29)
- А давайте сравним Эльбрус с старыми серверными процессорами,
произведенными по тому же техпроцессу.
- Господа, вы реально сравниваете процессор, производимый по гораздо
более "толстым" тех процесса с небольшой частотой и медленной (по
современным меркам) памятью, и утверждаете, что всё дело в VLIW??? - =AlexD=(16.12.2021 15:21)
- Под него половина мира сосредоточенно пилит софт. - LightElf(16.12.2021 15:44)
- И чем он, в смысле "ПО для Сбера" лучше Эльбруса? - mse homjak(16.12.2021 15:13)
- Был тут ролик от "Байкалов". Ихний главный по технике, весьма
скептично относицца к "бесплатным открытым". И я ему, чота, верю.
Роль государства в процессе - решающая.Если решено иметь своё, то
на этом нужно стоять до логического конца. Достигать поставленной
задачи. По крайней мере, этапов. Полумеры тока вредят и приводят к
просёру денег и времени. - mse homjak(16.12.2021 15:11)
- Зачем давиться кактусами, когда есть бесплатные открытые
архитектуры, которые будут работать гарантированно лучше Эльбруса в
задачах "нарисовать рабочий стол" - lloyd(16.12.2021 15:00)
- Да и для персоналок пойдёт. Главное, чтобы наперсоналено было
нативным кодом. И полная ясность от государства, что в это стоит
вкладывацца, а то, хуже будет. - mse homjak(16.12.2021 14:53)
- Т.е. заведомый тупик. Получается что Эльбрусом должны заняться
органы по признакам мошенничества, очковтирательства и
некомпетентности, причем не только разработчиков но и тех кто
ставил ТЗ и принимал работу. Ухлопали кучу времени и денег на
заведомо тупиковое направление. Как когда то штаты навязали союзу
СОИ а маразматики из ЦК радостно заглотили наживку. - 3m(16.12.2021 14:46)
- Да, причем в медленный RISC - LightElf(16.12.2021 14:33)
- Механизм OoOE превращает любой CPU в параллельный на уровне
последовательности инструкций, так что дело не в параллельности. - =AlexD=(16.12.2021 15:16)
- Интересно, но не весело. Видно, что компилятор старается как может,
но из изначально последовательного алгоритма параллельность выдоить
получается совсем не всегда - LightElf(16.12.2021 14:28 - 14:33)
- У банков JVM. Чего не умеет делать JVM - то не будет работать, хоть
какой умный Эльбрус будет. Арифметика-то целочисленная, но, как
правило, длинная. И между пользовательским кодом и ассемблером ну
очень дофига слоёв. Код->Библиотеки->IR->ASM. lloyd(497 знак., 16.12.2021 10:08, ссылка)
- Разным задачам - разные камни! Кстати, у банкиров скорее всего
целочисленная арифметика? - Kpoк(16.12.2021 09:35)
- Что-бы в мобильном банке когда в кнопки тыкаешь, транзакции не подтупливали. - =AlexD=(16.12.2021 07:23)
- Сбер не захотел "напрячься". - LightElf(16.12.2021 14:27)
- Для чего "приличный машинный код"? Для интернет-серфинга? Для
котиков? Там сойдёт любой. А для двух-трех приличных задач можно и
напрячься - написать хорошие проги. - Kpoк(16.12.2021 06:48)
- Я, видимо, свою мыслю плохо излагаю. Для эффективной работы VLIW
нужно изменять не просто код, а сам алгоритм. Компиляторы этого не
умеют. Может какая нейросеть сможет, но встанет вопрос верификации
результата. - LightElf(16.12.2021 14:37)
- Там всё по-другому работает. Сначала Вы пишете компилятор, который
любую команду языка Ц (например, но лучше Паскаля) переводит в код
Эль-76. А потом весь говнокод на Яве и Питоне (и проч.) преводится
в Ц, И уже потом в Эль-76. - Kpoк(15.12.2021 23:18)
- Какая разница на чем они написаны? Они же создают машинный код для
конкретной целевой платформы: x86, ARM, RISC-V или Эльбрус. Под
каждую платформу - свой JIT компилятор. - LightElf(15.12.2021 12:50)
