Очередная перепись нечитавших новость?

> 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, плюс-минус лапоть, совпадает с приведенным в табличке.

Си прост, да и Си++ не сложен пока не возиться с шаблонами и не городить что-то нетривиальное с наследованием. "Питоны и Пыхи" просто станут не нужны. Я во всяком случае не вижу никаких их преимуществ.

Perl создавался для решения задач, которые при создании C ещё не были толком актуальны, а при создании C++ не рассматривались как основные.

ну или два бинарника: для x86-64 и для aarch64 .

Пусть обратятся к Russian Hackers, они подскажут. И даже отправят туда.

авторы сами срвнивают свой продукт с gcc(jit) и llvm. про libjit и firm же стыдливо умолчали — потому что не вышло бы тогда броского сравнения. и пришлось бы признаться, что MIR стали делать только потому, что libjit и firm под мерзкой, ненавистной корпорастам GPL.

ах, ну да: ещё MIR героически внедрил инновацию отказа от SSA. SSA чуть позже завезут — когда придётся докидывать оптимизаций; но уже без шума и помпы. запомните этот твит.

Тут просто кто то спросил чем ЭТО лучше чем JAVA байт код.

такова печальная судьба больных NIH-синдромом. пусть хрюкается, сам этого захотел.

Вы принципиально неправы. На всякий уточню:
- в 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 ровно тоже самое.

Понимая сарказм, уточню на всякий:
- никакая следующая версия MIR не может поддерживать "все инструкции" LLVM IR, ибо тогда MIR потеряет смысл и превратиться в LLVM.
- следующие версии llvm2mir очевидно будут поддерживать большие IR-инструкций и интринисков, но большинство из них вынуждено будет транслировать в вызовы дополнительной runtime-библиотеки.

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.

Как-то так.