В компании Rad Hat ведётся разработка нового легковесного JIT-компилятора MIR, обеспечивающего выполнение кода, предварительно преобразованного в промежуточное представление MIR (Medium Internal Representation, не путать с другим промежуточным представлением MIR (mid-level IR), применяемым в компиляторе Rust). Проект нацелен на предоставление основы для реализации быстрых и компактных интерпретаторов и JIT. Код проекта написан на языке Си и распространяется под лицензией MIT...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52223
Может всё-таки JIR?
jinr? :)
Бинарник собранный gcc 25 мегабайт? Что там? Эти тоже "забыли" стрипнуть?
Это размер КОДА самого компилятора
LLVM посчитать забыли, там гигабайт 20.
> LLVM посчитать забыли, там гигабайт 20.А точно не 100500?
.
> 27M 15 дек. llvm-7.0.1.src.tar.xz
> 57M 11 янв. llvm70/lib/libLLVM-7.sohttps://packages.debian.org/jessie/libllvm3.5
> Installed Size 29,817.0 kB
> LLVM посчитать забыли, там гигабайт 20.Как это? Пакет с либой весит 7 мегов?
>> LLVM посчитать забыли, там гигабайт 20.
> Как это? Пакет с либой весит 7 мегов?Для начала необходимо выяснить, что именно они имели в виду. Если это зависимость, которую этот код будет использовать для компиляции и только она, то логично будет сравнивать с равноценным кодом из gcc (он тоже умеет во всё то же, что и llvm, и даже лучше). А то выглядит как очередное сравнение тёплого с мягким и ни у кого из них не возникает никаких вопросов, главное результат и красивые слайдики.
А компиляторы llvm в процессе сборки действительно потребляют десятки гигабайт, и на диске там не 7 мегабайт в результате выходит.
да какая разница, если статичная линковка, то это очень круто
>> Бинарник собранный gcc 25 мегабайт? Что там? Эти тоже "забыли" стрипнуть?
> да какая разница, если статичная линковка, то это очень крутоОчередная перепись нечитавших новость?
> Here are the notes for each table row:
> [1]: Wall time of compilation of sieve code (without any include file and with using the memory file system for GCC).
> [2]: The best wall time of 10 runs.
> [3]: The stripped sizes of cc1 for GCC, and the MIR core and interpreter or generator for MIR.сс1 (правда ни разу не статистически слинкованный) размер из того же gcc9, плюс-минус лапоть, совпадает с приведенным в табличке.
Тут уже предлагают libllvm сравнивать. Давайте тогда libcc1 считать вместо этого, он там около сотни килобайт.
> Тут уже предлагают libllvm сравнивать.Кто и с чем предалагает?
> Давайте тогда libcc1 считать вместо этого, он там около сотни килобайт.Те, кому для сборки LLVM нужны "десятки гигабайт", могут сравнивать что хотят и с чем хотят – кто же им запретит-то? o_O
>потребляет десятки гигабайтЯ привык собирать в tmpfs, очень болезненно реагирую на десятки гигабайт. Приходится собирать, сохраняя файлы на диск, а это намного медленней. А что?
>>потребляет десятки гигабайт
> Я привык собирать в tmpfs, очень болезненно реагирую на десятки гигабайт. Приходится собирать, сохраняя файлы на диск, а это намного медленней. А что?Ну например вот это вот:
> 57M 11 янв. llvm70/lib/libLLVM-7.soиз недавнего "самосбора" (кастом с clang, lld-gold, без доков, санитайзеров и lldb - конченый результат ~ 400МБ) , сборка в tmpfs с лимитом в 5GB, на машинке с аж 8GB ОЗУ.
Брат^W все нормально собралось в фоне.
А что такое старьё то? В 1 поток? Я много чего раньше собирал в tmpfs, включая компиляторы и браузеры, но теперь так не получается. Правда, llvm вроде собирается (в 4 потока), но я как-то проследил сколько данных записано на диск в процессе. А какие таргеты? Бэкенды вроде NVPTX? Это может быть очередной регрессий по типу регулярных проблем gcc с lto?
> Я много чего раньше собирал в tmpfs, включая компиляторы и браузеры, но теперь так не получается.Ну дык - собирайте без LTO.
А то получается как в том анекдоте "Доктор, если я делаю вот так вот …" ;)
Или clang с lto=thin (которое "ThinLTO compilation is a new type of LTO that is both scalable and incremental"), если так хочется.LTO конечно вещь, но заметная оптимизация (не 3%-5% как в Огнелисе, вперемежку с регрессиями http://hubicka.blogspot.com/2018/12/even-more-fun-with-build...) получается только в довольно специфичных случаях, а вот ресурсов оно жрет ой-ёй-ёй.
> А что такое старьё то?
"за надом!" (с) народный аноним
Ну и вроде бы: "Релиз набора компиляторов LLVM 7.0 - OpenNET 19 Sep 2018".Но могу предложить LLVM + Clang 8 (давно собирал, но тоже все нормально собиралось).
Или относительно свежий LLVM+Clang 9 (тут уже обрезаны таргеты, зато собран с lto=thin, конечный результат со всеми санитайзерами и lldb ~ 800МБ).
Единственно, собирался долго, но памяти оставалось еще с пару ГБ.
Но вообще, в том же фрибсд "обпиливают" связку clang + llvm 9, собирающей всю систему и большую часть портов, до 70-80 МБ.> В 1 поток?
В 3 - 4.
> А какие таргеты? Бэкенды вроде NVPTX?
Registered Targets:
aarch64 - AArch64 (little endian)
aarch64_be - AArch64 (big endian)
amdgcn - AMD GCN GPUs
arm - ARM
arm64 - ARM64 (little endian)
armeb - ARM (big endian)
bpf - BPF (host endian)
bpfeb - BPF (big endian)
bpfel - BPF (little endian)
hexagon - Hexagon
lanai - Lanai
mips - Mips
mips64 - Mips64 [experimental]
mips64el - Mips64el [experimental]
mipsel - Mipsel
msp430 - MSP430 [experimental]
nvptx - NVIDIA PTX 32-bit
nvptx64 - NVIDIA PTX 64-bit
ppc32 - PowerPC 32
ppc64 - PowerPC 64
ppc64le - PowerPC 64 LE
r600 - AMD GPUs HD2XXX-HD6XXX
sparc - Sparc
sparcel - Sparc LE
sparcv9 - Sparc V9
systemz - SystemZ
thumb - Thumb
thumbeb - Thumb (big endian)
x86 - 32-bit X86: Pentium-Pro and above
x86-64 - 64-bit X86: EM64T and AMD64
xcore - XCore
> Это может быть очередной регрессий по типу регулярных проблем gcc с lto?Я собирал clang самим clang-ом. LLVM+Clang 7/8 без LTO, LLVM+Clang 9 с "-flto=thin".
> Я привык собирать в tmpfs, очень болезненно реагирую на десятки гигабайт.Подключайте десятки гигабайт свопа -- tmpfs+swap работает всё равно быстрее ext4, например.
Использовать журналируемые ФС для временных файлов (а сборка именно их и создаёт, там ничего такого невосполнимого-ценного нет) вообще не очень мудрая идея. ;)
Чем оно лучше GNU Lightning?
Разные подход к снаряду, в GNU Lightning нет промежуточного языка.
Тут в пору спросить чем лучше wasm or polyglot
Это что же, у нас будут интерпретаторы Си и Си++? Они понимают что через полгода после релиза питонисты и прочие ПХПшники начнут массово убивать себя от безысходности? Эти два интерпретатора вытеснят на серверах всё кроме Лиспа. По понятной причине...
так а по какой такой понятной причине? ;)
У тебя есть "подкроватный" сервер? Вот и попробуй выпилить оттуда Лисп и сам всё поймёшь.
# eix -I lisp
No matches found
ну в принципе да, нельзя вытеснить того, чего нет
> # есть закурить?
> No matches found"а если найду?"
>>> ну в принципе да, нельзя вытеснить того, чего нет
(простите (не . удержался))
Не вытеснят из-за порогов вхождения в Питоны и Пыхи.
> Не вытеснят из-за порогов вхождения в Питоны и Пыхи.Си прост, да и Си++ не сложен пока не возиться с шаблонами и не городить что-то нетривиальное с наследованием. "Питоны и Пыхи" просто станут не нужны. Я во всяком случае не вижу никаких их преимуществ.
Трoллинг глупостью в 2020 году смотрится уже немного архаично, не находите?
Ну так и не тролльте.
Интересно, а зачем использовать C++, если не использовать его нетривиальные возможности? Захотелось просто так в ногу пострелять?
Понятия не имею о чём ты говоришь. Хочешь -- используй, не хочешь -- не используй.
> Понятия не имею о чём ты говоришь. Хочешь -- используй, не хочешь
> -- не используй.С утверждением "хочешь - используй" спорить даже не собираюсь. Но я говорил про это:
>> Си++ не сложен пока не возиться с шаблонами и не городить что-то нетривиальное с наследованием.
Для решения простых задач C++ (речь не о лабораторных работах первокурсников, разумеется, а реальных потребностях) зачастую не оптимален в качестве инструмента: дольше разработка, больше риски ошибок. Опять же, существую языки, изначально заточенные для работы в той или иной области... C++ - тяжеловес-универсал, нужный тогда, когда другие перестают справляться. Он ценнен как раз своими возможностями вроде упомянутых вами множественного наследования и template'ов (которые сравнивать с generic-типами в языках типа Java язык не повернётся). И говорить о C и C++ в одном контексте, право слово, почти всегда некорректно.
>Для решения простых задач C++ зачастую не оптимален в качестве инструмента: дольше разработка, больше риски ошибок.Для простых задач "тяжеловес" Си++ ничем не хуже других языков. Совсем. Более того: внятное объявление типов и очевидная работа с памятью пресекают бОльшую часть ошибок ещё на этапе до компиляции. И это более заметно именно на небольших проектах. На больших проектах всё равно придётся обложиться планами, тестами т.п.
>И говорить о C и C++ в одном контексте, право слово, почти всегда некорректно.
Может и так, но они оба входят во множество хороших и привычных языков программирования и использовались мной именно в этом контексте.
R уже есть..
В каком месте R вообще замена си? Эт ж надо такое придумать! :)
> Эти два интерпретатора вытеснят на серверах всё кроме Лиспа. По понятной причине...Есть такое малознакомое понятие как ИТ безопасность, вот именно по этому понятию интерпретаторов, тем более с JIT на серверах у людей не будет.
Такая "безопасность" работает только при условии, что у злоумышленника не хватит квалификации собрать статический бинарник под целевую платформу. То есть — от пользователей Kali, разве что.
У людей имеющих элементарные понятия ИТ безопасности вся память, включая дисковую подсистему, выделяется или exec,ro или noexec,rw. Это требование DAC.А запуск бинаря через:
/lib/ld-linux.so.2 /tmp/virus
У дистрибутивах для людей не работает.
> Такая "безопасность" работает только при условии, что у злоумышленника не хватит квалификации собрать статический бинарник под целевую платформу.Садись, опять двойка.
Речь идет о выделении оперативной память в режиме RX для исполняемых программ, RW для изменяемых данных или только R для не изменяемых данных. Это базовые, обязательные требования DAC. Выделять оперативную память в режиме WX категорически запрещается!
Использование JIT противоречит этим правилам изменяя исполняемую область памяти.
Как с этим всем связаны уязвимости с переполнение буфера местным двоечника тоже объяснять надо?
Не противоречит. Современные приличные JIT делают простую вещь: сначала выделяют память как RW, потом меняют права на (R)X. Все довольны.
> Это что же, у нас будут интерпретаторы Си и Си++?Скачай уже наконец TCC и вот оно счастье :D. Он таки это самое умеет, прям в ридми написано.
И таки да - он таки сперва компилит, потом запускает. Хоть и быстро и оптимизации рядом не стояли с gcc и шлангом, но по сравнению с питоном и пыхом... :)))
TCC - GPL. А это резко ограничивает возможности его применения. Собственно, мне кажется, потому он и не взлетел в качестве платформы для массового JIT.
Не очень ффтыкаю как GPL компилера "в режиме интерпретера" ограничивает что-то. Код с ним при этом не линкуется.А если это про более серьезную кодогенерацию - там скорее "ограничивает" общая тривиальность конструкции, все заточено на быстрый компил и простой код компилера. Но вот оптимальность такого кода по сравнению с gcc/clang... гм...
>> Это что же, у нас будут интерпретаторы Си и Си++?Подумали в своё время умные люди и создали Perl.
Забавно, но нет.Perl создавался для решения задач, которые при создании C ещё не были толком актуальны, а при создании C++ не рассматривались как основные.
>MIRКрасноперые решили потролить неудачников из каноникала.
... скромные боги тихо собирают МИР ...
Зачем захватывать мир, если можно сделать свой?
Весьма валидный пойнт. Но LLVM с шлангом они кажется все-таки малость подтроллили.
> Компиляция в MIR должна осуществляться как минимум в 100 раз быстрее, чем в GCC;Остальное время будет добрано на целевых компьютерах во время выполнения.
>> Компиляция в MIR должна осуществляться как минимум в 100 раз быстрее, чем в GCC;
> Остальное время будет добрано на целевых компьютерах во время выполнения.Исполнение MIR с использованием JIT должно быть не более чем на 30% медленнее, чем производительность исполняемого файла, собранного на основе того же Си-кода в GCC (с оптимизациями "-O2");
про компиляцию в внутреннее представление JIT намеренно умолчали? или не знали о таком?
Закон сохранения энергии.
Или как вариант, код будет передаваться на "облака" RedHat и этот MIR, на самом деле, просто frontend.
Интересно, по какому закону сохранения этот "frontend" будет работать без интернета (а он будет).
Зачем столько новых промежуточных представлений? Уже существующих недостаточно?
Это не считая того, что выходной x86(-64) код - тоже промежуточное представление, внутри проца оно совершенно иное :D
Фатальный недостаток-с(с) у всех же.
> Исполнение MIR с использованием JIT должно быть не более чем на 30% медленнее, чем производительность исполняемого файла, собранного на основе того же Си-кода в GCC (с оптимизациями "-O2")Эпическое ненужно.
С другой стороны они все верят что именно их xIT будет праивть миром. В то время пока рынок не могут поделить .NET реализация и Java реализация, а они блин были первые выдумщики.Осталось только дождаться когда Python и PHP выпустит свой Just-In-Time транслаторы и все мир будет счастлив.
а почему нельзя просто скомпилировать бинарник?ну или два бинарника: для x86-64 и для aarch64 .
Почему бы не погуглить, зачем нужен jit?
а почему бы сразу не написать сюда на форум, действительно, зачем же нужен jit ?наверное чтобы сожрать оперативную память на которую пользователь ПК потратил денег а теперь не знает какбы утилизировать? для этого?
или для того чтобы запускаемая программа имела бы непредсказуемую производительность, неуправляемые характеристики?
Потому что в принципе бессмысленно что-то объяснять, если человек не знает, где используются скрипты
Там где нет денег сделать из MVP и POC проекта полноценное решение?
Тут всем на помощь и приходят полурешения на JIT
Господи, откуда вы беретесь?
вам лучше этого не знать, поверьте
Значит пользователь ПК потратил недостаточно денег на оперативную память, чтобы запускаемая программа имела бы предсказуемую производительность, управляемые характеристики.
Дык известно же что производители железа просто щемят программистов этим вот и все
> а почему нельзя просто скомпилировать бинарник?Потому что в языке с динамической типизацией проблематично просчитать все возможные изменения переменных, например, на этапе компиляции. Просто по Тюрингу - компилер не может вынести вердикт о том чего будет с вон той переменной дальше. И поэтому не может сгенерить сколь-нибудь эффективный код, всегда надо предусматривать что переменная внезапно полностью сменила тип. А это стало быть конкретный кус кода навешивать придется. Медленный и жирный.
Потому что в случае eval() надо еще... внезапно притащить с собой ВЕСЬ КОМПИЛЕР. В рантайме. Ну или как eval() то выполнять без этого? :)
> Просто по ТюрингуВот с этого момента можно дальше не читать - уровень содержимого примерно такой же: "слышал звон".
>> а почему нельзя просто скомпилировать бинарник?
> Потому что в языке с динамической типизацией проблематично просчитать все возможные изменения
> переменных, например, на этапе компиляции. Просто по Тюрингу - компилер не
> может вынести вердикт о том чего будет с вон той переменной
> дальше. И поэтому не может сгенерить сколь-нибудь эффективный код, всегда надо
> предусматривать что переменная внезапно полностью сменила тип. А это стало быть
> конкретный кус кода навешивать придется. Медленный и жирный.
> Потому что в случае eval() надо еще... внезапно притащить с собой ВЕСЬ
> КОМПИЛЕР. В рантайме. Ну или как eval() то выполнять без этого?
> :)вообще первоначальный тезис был про
"""С другой стороны они все верят что именно их xIT будет праивть миром. В то время пока рынок не могут поделить .NET реализация и Java реализация, а они блин были первые выдумщики."""
а автор уже лишь только потом добавил в сообщение про Python и PHP.
а в .NET и Java какие нафиг ещё динамические типизации? это когда ты делаешь абсолютно всю программу через переменные лишь только Оbject-типа, а затем уже будешь через рефлексию/и/кастования вызывать нужный тебе метод? :-)
В C# есть такая штука как dynamic, почитайте: https://docs.microsoft.com/ru-ru/dotnet/api/system.dynamic.d...В JRE по крайней мере до недавнего времени всё было более грустно, но я не слежу за ней последние годы внимательно.
Уже есть numba. Она даже cuda умеет. Результаты так себе, скажем, cython обеспечивает производительность равную си, а тут может ещё и хуже в зависимости от условий стать.
так cython УЖЕ есть
правда жизни состоит в том что в том месте где живут питоны и пыхи - самое место итерпретаторам
а всякие ускорители выполнения они конечно хорошо - но ускорители написания - как бы важнее
(унас_было_14_стандартов.жпг)Но идея годная. Если взлетит, будет хорошо.
Я не понял, там названия кончились что ли?
Они хотят "крутое" название из трех букв. н.р ( C компиляторы: pcc, tcc, lcc, gcc..) итд по другим пунктам
> Они хотят "крутое" название из трех букв.Пусть обратятся к Russian Hackers, они подскажут. И даже отправят туда.
> под лицензией MIT ... не исключается возможность портирования GCC на использованиеУшли у батьки Столлмана конпилятор...
Эх, успеют корпорасты реализовать задумки из "Право прочесть" к 2096-му году.
> Ушли у батьки Столлмана конпилятор...К тем, кто будет использовать старый gcc — выедут специально обученные люди, настучат по почкам и отправят в Siberia.
А чому не в Nigeria?
Потому что название не толерантное.
+1 стандарт
Пока код ISO на присвоят — не стандарт.
А если ISO выпустят релиз, а все остальные на эту бамажку покладут известно что, то это всё равно будет стандарт? ;) Многие вещи стандартизируют задним числом, если вы не в курсе. В том числе и в ISO.
я что не понял - чем оно от вм и байткода ллвм отличается кроме того что написано другими людьми и имеет меньшее окружение?
Какая-то детская фиксация на цифре 100. В сто раз быстрее, меньше... Прям как "мой папа в сто раз сильнее твоего, он машину одной рукой поднимет".
Современные физики и инженеры с их «разница величин оценивается как минимум в два порядка» недалеко от них ушли.
На два порядка. Логарифмы складываются.
Ну а что, иногда даже правда. Нацепит экзоскелет - и подымет.
>> Код проекта написан на языке Сину, хотя бы, подходящий язык для реализации выбрали, а не хипстерскую растишку, уже норм.
>> в будущем планируется реализовать возможность генерации MIR для WebAssembly, байткода Java, CIL (Common Intermediate Language), Rust и C++в случае с растишкой - это правильное решение, всё равно этому языку ничего не светит в системном программировании, а пилить веб-фреймворки хипстерам будет сподручнее на языке, транслируемом в представление для последуюшей JIT-компиляции вот этим вот JIT-компилятором MIR, к примеру.
транслировать же С и С++ в промежуточное представление... хз. зачем, если есть жаба.
> всё равно этому языку ничего не светит в системном программировании... говорят люди, не имеющие понятия ни о расте, ни о системного программировании...
Это всё гуманитарные дисциплины, и настоящему айтишнику их знать не надо. Вот философия Unix — это да, без неё — вон из профессии.
растишка - это диверсия в сфере разработки системного ПО. язычёк, в котором манипуляция объектамм в памяти осуществляется посредством костылей, придуманных для неосиляторов адресной арифметики, объективно не нужен
Растишка переносит отлов багов с адресной арифметикой с этапа исполнения на этап компиляции. Вот такая простая идея.
А нужно ему или нет каждый решает сам.
> транслировать же С и С++ в промежуточное представление... хз. зачем, если есть жаба.GCC и сейчас это до некоторой степени делает. Хоть и несколько своеобразно.
Зачем? А затем что компилеру целящему в более чем 1 архитектуру удобнее сперва сгенерить код "абстрактно" а потом это уже транслировать в конкретный набор команд с их особенностями. Вообще совсем целиком переписывать вообще все пути кода под каждую новую архитектуру несколько утомительно.
речь о промежуточном представлении для компиляции JIT-компилятором. а в случае с GCC дело не только в трансляции под разные архитектуры. абстрактное представление позволяет также добавить поддержку нового ЯПа
Насколько я понял идею этой штуки - это предлагается как некий IR, более логичный и юзабельный чем LLVMовский. В том числе в этом вроде бы предполагается возможность притащить "абстрактный" бинарник а на целевой платформе его перегнать в нативный относительно малой кровью.В случае LLVM они подобные юзкейсы не предусмотрели как класс, насколько я понимаю. Что довольно странно, но жираф большой, ему видней. В этом местя есть некий шанс подстебать этих господ, занвя кусочек "их" ниши.
Просто llvm очень жирный и долго работает перегоняя свой ir в наивный код. Автор делает тоже самое только его реализация маленькая и быстро делает наивный код за счёт минимальной оптимизации.
Вообще всякие JIT нужны для того, чтобы не светить исходниками клиентам, для чего это конторе, которая вроде как опенсорсом занимается?..
ой, простите, совсем забыл, что там новый хозяин... тогда всё становится на свои места, понятно, кто задачку поставил...
Опять пятнадцатицентовые из оракла. Унылые и однообразные, как всегда.
Еще один убийца джавы?
Весело год начался. Один выкатывает очередного убийцу мейка, эти выкатывают убийцу джавы. Кто у нас будет следующим, очередной шел?
как всегда — в libjit нашли Фатальный Недостаток.
Судя по описанию - достаточно разные штуки.
> Судя по описанию - достаточно разные штуки.авторы сами срвнивают свой продукт с gcc(jit) и llvm. про libjit и firm же стыдливо умолчали — потому что не вышло бы тогда броского сравнения. и пришлось бы признаться, что MIR стали делать только потому, что libjit и firm под мерзкой, ненавистной корпорастам GPL.
ах, ну да: ещё MIR героически внедрил инновацию отказа от SSA. SSA чуть позже завезут — когда придётся докидывать оптимизаций; но уже без шума и помпы. запомните этот твит.
Они об этом прямым текстом говорят, предсказатель вы наш: "If we implement more optimizations, SSA transition is possible when additional time for expensive in/out SSA passes will be less than additional time for non-SSA optimization implementation".Ну или вы хотели как-то странно пошутить, но не вышло. Сочувствую, со всеми бывает.
ты плохой, ненастоящий господи. потому что глупый очень.
> Промежуточный код MIR может быть представлен в бинарном и текстовом (читаемом) виде.Хм, непосредственно править байт код ... хм.
В текстовом виде — это уже не байт-код, а лайн-код.
> Хм, непосредственно править байт код ... хм.Ассемблер же правят. А это чем хуже?
> Ассемблер же правят. А это чем хуже?Тут просто кто то спросил чем ЭТО лучше чем JAVA байт код.
Ну например JAVA выросла в адского переусложненного монстра который подразумевает немеряный рантайм и либы и половина перечисленных в сабже юзкейсов на основе жабы просто не выглядит жизнеспособно.
>В текущем виде реализация MIR во многим опережает изначально поставленные цели: проведённые тесты показали, что производительность компиляции в MIR быстрее "GCC -O2" в 178 разЭЭ братан, не надо сравнивать тёплое с мягким, ты знаешь как компилируется сишный код. Сначала, идёт добавление заголовочных файлов, затем работает синтаксический и лексический анализаторы, затем код ассемблируется, только после, всего этого ассемблерный код синтаксиса, трушно Юниксового AT&T, превращается в бинарь.
>производительность исполнения отстаёт от нативного кода на 6%, размер кода меньше в 144 раза
Конечно, интерпретируемая Природа всегда медленее компилируемой природы.
>реализация MIR JIT составляет 16 тысяч строк кода.
Это не показатель. Разработчики GCC пишут на С++.
Затея интересная, точно будет полезна для JIT-изации и получения переносимого промежуточного во многих случаях. Однако, MIR целенаправленно содержит минимальный набор инструкций без SIMD, CMOV, FFS/CLZ/CTZ/POPCOUNT, SIN/COS и т.д. Получается этакий PDP-11 с поддержкой 32/64-битных операндов.Такое "обрезание" совершенно оправдано назначением MIR и позволяет в разы сократить как объем кода, так и затраты на оптимизацию. Но нужно видеть и обратную сторону медали:
- при трансляции из GCC и LLVM в MIR для каждого builtin-а придется выбирать одно из трех: инлайнить цепочку инструкций, оформлять вызов к runtime-библиотеки (которую нужно поддерживать и поставлять отдельно), генерировать ошибку (т.е. нарушать совместимость с GCC/LLVM).
- использование продвинутых инструкций CPU всех определенного в MIR минимума потребует затрат на вызов функции (и связанного с этим пере-распределения регистров).
- оптимизация MIR-представления до уровня GCC/LLVM будет очень дорогой, так как требуется восстановление/распознание builtin/intrinsic-паттернов из россыпи простых MIR-инструкций и runtime-вызовов.Поэтому на некоторых задач MIR будет вносить существенное замедление и никогда не сможет догнать GCC/LLVM. Это совершенно не проблема, и даже не недостаток, а осознанный компромисс. Главное потом не устраивать героическую битву с этим компромиссом (как в JVM).
>- при трансляции из GCC и LLVM в MIR для каждого builtin-а придется выбирать одно из трех: инлайнить цепочку инструкций, оформлять вызов к runtime-библиотеки (которую нужно поддерживать и поставлять отдельно), генерировать ошибку (т.е. нарушать совместимость с GCC/LLVM).Там речь идет про LLVM IR он тоже довольно простой, особых проблем быть не должно.
> - оптимизация MIR-представления до уровня GCC/LLVM будет очень дорогой, так как требуется восстановление/распознание builtin/intrinsic-паттернов из россыпи простых MIR-инструкций и runtime-вызовов.
Этого делать не планируеться, MIR это на подобии C1 из JVM.Вся эта работа изначально делалась для Ruby. Там сейчас подобие C2 из JVM на основе LLVM/GCC, а теперь пилят C1. Хотя сомневаюсь что Ruby что то поможет.
Будем надеяться что у Владимира Макарова получиться, но работа очень большая в одного можно зарюхаться.
> Будем надеяться что у Владимира Макарова получиться, но работа очень большая в
> одного можно зарюхаться.такова печальная судьба больных NIH-синдромом. пусть хрюкается, сам этого захотел.
Ну все немного сложнее, изначально это был пет проект как я понимаю. Потом шапка разрешыла работать фултайм. Ну а идея была в том что бы добавить в Ruby jit, хотя у core team очень странное видение, они хотят все свое без внешних зависимостей.
(на всякий случай: я не имел в виду ничего негативного. просто автор сознательно пошёл в NIH-территорию, а там Свои, Особые Правила. ;-)
>>- при трансляции из GCC и LLVM в MIR для каждого builtin-а придется выбирать одно из трех: инлайнить цепочку инструкций, оформлять вызов к runtime-библиотеки (которую нужно поддерживать и поставлять отдельно), генерировать ошибку (т.е. нарушать совместимость с GCC/LLVM).
> Там речь идет про LLVM IR он тоже довольно простой, особых
> проблем быть не должно.Вы принципиально неправы. На всякий уточню:
- в MIR только самые простые инструкции, см. https://github.com/vnmakarov/mir/blob/master/mir.h
- в LLVM IR в 2 раза больше базовых типов данных, в ~10 раз больше базовых инструкций и несколько сотен intrinsic-ов, см. https://llvm.org/docs/LangRef.html
- невозможно "просто так" преобразовать LLVM IR в MIR, возникают масса проблем, в том числе обозначенные мной.
- с GIMPLE в GCC ровно тоже самое.
Эти отключают оптимизации llvm, дабы генерить как можно более простой llvm ir. О полном один в один переносе речь конечно не идёт.Если вы уже залезли в репу то посмотрите что там сделано в llvm2mir
> Эти отключают оптимизации llvm, дабы генерить как можно более простой llvm ir.
> О полном один в один переносе речь конечно не идёт.Теоретически конечно можно генерировать "более простой llvm ir".
Но практически это не имеет ценности:
- вы должны обучить каждый ir-генератор (условный clang или rust) генерировать такой куцый ir (фактический отдельный диалект LLVM IR).
- соответственно вы должны выпилить из условного rust все возможности связанные с расширенными инструкциями сделав куцый вариант условного rust.
- совместимость с таким куцым условным rust потребует правки исходников.
> Если вы уже залезли в репу то посмотрите что там сделано в
> llvm2mirПосмотрел, там ровно то, что я описал в первоначальном комментарии.
Есть чуть конкретнее, то llvm2mir просто сообщает "unsupported/unimplemented" почти во всех случаях, о которых я говорю.
Собственно это явно описано в README проекта, только в других формулировках.
Да вы правы, будут проблемы.
следующая версия будет содержать все инструкции :D
> следующая версия будет содержать все инструкции :DПонимая сарказм, уточню на всякий:
- никакая следующая версия MIR не может поддерживать "все инструкции" LLVM IR, ибо тогда MIR потеряет смысл и превратиться в LLVM.
- следующие версии llvm2mir очевидно будут поддерживать большие IR-инструкций и интринисков, но большинство из них вынуждено будет транслировать в вызовы дополнительной runtime-библиотеки.
Что значит "сренегерировать"?
>В компании Rad Hat ведётся разработка нового легковесного JIT-компилятора MIR
>Код проекта написан на языке СиЭто все что надо знать о нужности современных язычков...
ну дак не на расте же писать, у тех девственниц истерика случается при виде указателя.
ГНУтые поделия постепенно выбрасываются, скоро и ядро перелицензируют на какой-нибудь MIT.
А для питона будет?
В ложку питона сколько бочек мёда не докидывай - всё равно питоном останется.
Для какой-нибудь обкоцаной недо-версии с более-менее статическими типами и без всяких eval... ?
Лучше бы Red Hat развивал ZFS, выкупив её у Oracle.
Я просто оставлю это здесь https://github.com/wasmerio/wasmer
ну и зачем ты напачкал?
Может кто то поиграть захочет с теми же яйцами только в профиль.
Но WASM же делает то же самое. Нахера?
>Но WASM же делает то же самое. Нахера?и ллвм делает почти тоже самое, даже больше. Если кто знает - напишите зачем оно нужно при наличии ллвм и остального?
>>Но WASM же делает то же самое. Нахера?
> и ллвм делает почти тоже самое, даже больше. Если кто знает -
> напишите зачем оно нужно при наличии ллвм и остального?MIR предлагает простой универсальный компактный JIT с пермиссивной лицензией, который легко использовать, поддерживать и интегрировать. При этом для более 90% задач выдается более 90% скорости от полноценной "нативной" оптимизации.
1. Использование MIR в условном вашем проекте потребует в ~5 раз меньше усилий в сравнении с LLVM.
При этом не возникает пропорции "один рябчик (ваш код) и один конь (код LLVM)". Вам в разы проще поддерживать ваш проект и "владеть" вашим кодом.2. Добавление и поддержка новой CPU-архитектуры в MIR требует в 50-100 раз меньше работы в сравнении с LLVM или GCC.
3. Если взять средний интерпретатор, то основное падение производительности происходит в циклах при работе с нативными машинными типами данных. Использование MIR позволяет получить тут более 90% от нативной оптимизации LLVM, но для этого потребуется в 5-10 раз меньше ресурсов, как при интеграции MIR, так и при работе MIR в runtime.
Как-то так.
Можно, наверное, написать ридер mir-ir для Схемы, если там так мало инструкций. И получится компилятор Руби в Схему. Отличное решение, я считаю.