The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Red Hat развивает JIT-компилятор MIR

21.01.2020 08:48

В компании Red Hat ведётся разработка нового легковесного JIT-компилятора MIR, обеспечивающего выполнение кода, предварительно преобразованного в промежуточное представление MIR (Medium Internal Representation, не путать с другим промежуточным представлением MIR (mid-level IR), применяемым в компиляторе Rust). Проект нацелен на предоставление основы для реализации быстрых и компактных интерпретаторов и JIT. Код проекта написан на языке Си и распространяется под лицензией MIT.

На текущей стадии разработки трансляторы в промежуточное представление MIR подготовлены для языка Си и биткода LLVM (Bitcode), но в будущем планируется реализовать возможность генерации MIR для WebAssembly, байткода Java, CIL (Common Intermediate Language), Rust и C++. Проект развивается одним из разработчиков JIT-движка MJIT, используемого в Ruby. В первую очередь JIT на базе MIR планируется реализовать для CRuby и MRuby. В будущем также не исключается возможность портирования GCC на использование MIR.

Промежуточный код MIR может быть представлен в бинарном и текстовом (читаемом) виде. Данный код можно будет исполнить в интерпретаторе, сгенерировать на его основе машинный код (x86_64, в планах ARM64, PPC64 и MIPS64). Возможно и выполнение обратного преобразования - из MIR в CIL, байткод Java, WebAssembly и код на языке Си.

Из особенностей MIR выделятся строгая типизация, поддержка модулей и функций, предоставление набора инструкций для преобразования типов, сравнения, арифметических и логических операций, ветвления и т.п. Модули, включающие набор функций, преобразованных в формат MIR, могут загружаться в форме библиотек, а также загружать внешний код на языке Си.

Ключевым достоинством выполнения промежуточного кода в JIT вместо компиляции в нативные исполняемые файлы, является возможность формирования компактных файлов, которые могут выполняться без пересборки на разных аппаратных архитектурах (x86, ARM, PPC, MIPS). Для неподдерживаемых архитектур доступен режим интерпретации, который в случае MIR работает в 6-10 раз медленнее JIT.

Из недостатков существующих JIT-компиляторов GCC и LLVM называется их излишняя раздутость, низкая скорость компиляции и трудность реализации комбинированных оптимизаций для разных языков программирования. Разработчики MIR попытались решить эти проблемы и поставили перед собой цели:

  • Компиляция в MIR должна осуществляться как минимум в 100 раз быстрее, чем в GCC;
  • JIT для исполнения MIR должен быть очень компактным и включать примерно 15 тысяч строк кода;
  • Исполнение MIR с использованием JIT должно быть не более чем на 30% медленнее, чем производительность исполняемого файла, собранного на основе того же Си-кода в GCC (с оптимизациями "-O2");
  • Стадии инициализации до начала фактического исполнения должны занимать в 100 раз меньше времени;
  • MIR-представление для JIT должны быть в 100 раз меньше собранного в GCC исполняемого файла.

В текущем виде реализация MIR во многим опережает изначально поставленные цели: проведённые тесты показали, что производительность компиляции в MIR быстрее "GCC -O2" в 178 раз, производительность исполнения отстаёт от нативного кода на 6%, размер кода меньше в 144 раза, реализация MIR JIT составляет 16 тысяч строк кода.



  1. Главная ссылка к новости (https://news.ycombinator.com/i...)
  2. OpenNews: В PHP 8 будет добавлен JIT-компилятор
  3. OpenNews: Выпуск Pyston 0.6, реализации языка Python с JIT-компилятором
  4. OpenNews: Пример использования средств JIT-компиляции, появившихся в GCC 5
  5. OpenNews: Для WebKit реализован JIT-компилятор на основе наработок LLVM
  6. OpenNews: Выпуск LuaJIT 2.0.3, JIT-компилятора для языка Lua
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/52223-mir
Ключевые слова: mir, jit, compile, redhat
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (139) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 09:51, 21/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +19 +/
    Может всё-таки JIR?
     
     
  • 2.47, РэдХэд (?), 14:16, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    jinr? :)
     

  • 1.2, Аноним (2), 09:55, 21/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Бинарник собранный gcc 25 мегабайт? Что там? Эти тоже "забыли" стрипнуть?
     
     
  • 2.20, Имя (?), 11:11, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Это размер КОДА самого компилятора
     
     
  • 3.21, Аноним (2), 11:13, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    LLVM посчитать забыли, там гигабайт 20.
     
     
  • 4.43, Аноним84701 (ok), 13:46, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > LLVM посчитать забыли, там гигабайт 20.

    А точно не 100500?
    .
    >  27M 15 дек.   llvm-7.0.1.src.tar.xz
    >  57M 11 янв.  llvm70/lib/libLLVM-7.so

    https://packages.debian.org/jessie/libllvm3.5
    > Installed Size 29,817.0 kB

     
  • 4.53, Аноним (-), 14:27, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > LLVM посчитать забыли, там гигабайт 20.

    Как это? Пакет с либой весит 7 мегов?

     
     
  • 5.65, Аноним (2), 14:42, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >> LLVM посчитать забыли, там гигабайт 20.
    > Как это? Пакет с либой весит 7 мегов?

    Для начала необходимо выяснить, что именно они имели в виду. Если это зависимость, которую этот код будет использовать для компиляции и только она, то логично будет сравнивать с равноценным кодом из gcc (он тоже умеет во всё то же, что и llvm, и даже лучше). А то выглядит как очередное сравнение тёплого с мягким и ни у кого из них не возникает никаких вопросов, главное результат и красивые слайдики.

    А компиляторы llvm в процессе сборки действительно потребляют десятки гигабайт, и на диске там не 7 мегабайт в результате выходит.

     
  • 2.23, Аноним (23), 11:27, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    да какая разница, если статичная линковка, то это очень круто
     
     
  • 3.66, Аноним84701 (ok), 14:47, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> Бинарник собранный 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]: [B]The stripped sizes of cc1 for GCC[/B], and the MIR core and interpreter or generator for MIR.

    сс1 (правда ни разу не статистически слинкованный) размер из того же gcc9, плюс-минус лапоть, совпадает с приведенным в табличке.


     
     
  • 4.74, Аноним (2), 15:02, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Тут уже предлагают libllvm сравнивать. Давайте тогда libcc1 считать вместо этого, он там около сотни килобайт.
     
     
  • 5.75, Аноним84701 (ok), 15:15, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Тут уже предлагают libllvm сравнивать.

    Кто и с чем предалагает?
    > Давайте тогда libcc1 считать вместо этого, он там около сотни килобайт.

    Те, кому для сборки LLVM нужны "десятки гигабайт", могут сравнивать что хотят и с чем хотят – кто же им запретит-то? o_O

     
     
  • 6.76, Аноним (2), 15:18, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >потребляет десятки гигабайт

    Я привык собирать в tmpfs, очень болезненно реагирую на десятки гигабайт. Приходится собирать, сохраняя файлы на диск, а это намного медленней. А что?

     
     
  • 7.78, Аноним84701 (ok), 15:39, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >>потребляет десятки гигабайт
    > Я привык собирать в tmpfs, очень болезненно реагирую на десятки гигабайт. Приходится собирать, сохраняя файлы на диск, а это намного медленней. А что?

    Ну например вот это вот:
    >  57M 11 янв.  llvm70/lib/libLLVM-7.so

    из недавнего  "самосбора" (кастом с clang, lld-gold, без доков, санитайзеров и lldb - конченый результат  ~ 400МБ) , сборка в tmpfs с лимитом в 5GB, на машинке с аж 8GB ОЗУ.
    Брат^W все нормально собралось в фоне.  

     
     
  • 8.80, Аноним (2), 16:08, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А что такое старьё то В 1 поток Я много чего раньше собирал в tmpfs, включая к... текст свёрнут, показать
     
     
  • 9.105, Аноним84701 (ok), 00:16, 22/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну дык - собирайте без LTO А то получается как в том анекдоте Доктор, если я ... большой текст свёрнут, показать
     
  • 7.98, Michael Shigorin (ok), 19:42, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Я привык собирать в tmpfs, очень болезненно реагирую на десятки гигабайт.

    Подключайте десятки гигабайт свопа -- tmpfs+swap работает всё равно быстрее ext4, например.

     
     
  • 8.135, юникснуб (?), 19:25, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Использовать журналируемые ФС для временных файлов а сборка именно их и создаёт... текст свёрнут, показать
     

  • 1.3, Аноним (3), 09:57, 21/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Чем оно лучше GNU Lightning?
     
     
  • 2.118, GentooBoy (ok), 09:18, 22/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Разные подход к снаряду, в GNU Lightning нет промежуточного языка.
    Тут в пору спросить чем лучше wasm or polyglot  
     

  • 1.4, A.Stahl (ok), 10:01, 21/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Это что же, у нас будут интерпретаторы Си и Си++? Они понимают что через полгода после релиза питонисты и прочие ПХПшники начнут массово убивать себя от безысходности? Эти два интерпретатора вытеснят на серверах всё кроме Лиспа. По понятной причине...
     
     
  • 2.7, наше имя легион (?), 10:14, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    так а по какой такой понятной причине? ;)
     
     
  • 3.8, A.Stahl (ok), 10:16, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    У тебя есть "подкроватный" сервер? Вот и попробуй выпилить оттуда Лисп и сам всё поймёшь.
     
     
  • 4.149, Аноним (149), 23:29, 25/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    # eix -I lisp
    No matches found


    ну в принципе да, нельзя вытеснить того, чего нет

     
     
  • 5.150, Michael Shigorin (ok), 23:38, 25/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > # есть закурить?
    > No matches found

    "а если найду?"

    >>> ну в принципе да, нельзя вытеснить того, чего нет

    (простите (не . удержался))

     
  • 2.19, Аноним (19), 11:09, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Не вытеснят из-за порогов вхождения в Питоны и Пыхи.
     
     
  • 3.26, A.Stahl (ok), 11:34, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Не вытеснят из-за порогов вхождения в Питоны и Пыхи.

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

     
     
  • 4.37, Аноним (37), 12:44, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Трoллинг глупостью в 2020 году смотрится уже немного архаично, не находите?
     
     
  • 5.62, Аноним (-), 14:36, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Ну так и не тролльте.
     
  • 4.136, юникснуб (?), 19:26, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Интересно, а зачем использовать C++, если не использовать его нетривиальные возможности? Захотелось просто так в ногу пострелять?
     
     
  • 5.142, A.Stahl (ok), 19:45, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Понятия не имею о чём ты говоришь. Хочешь -- используй, не хочешь -- не используй.


     
     
  • 6.147, юникснуб (?), 15:03, 24/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    С утверждением хочешь - используй спорить даже не собираюсь Но я говорил про ... большой текст свёрнут, показать
     
     
  • 7.148, A.Stahl (ok), 15:39, 24/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >Для решения простых задач C++ зачастую не оптимален в качестве инструмента: дольше разработка, больше риски ошибок.

    Для простых задач "тяжеловес" Си++ ничем не хуже других языков. Совсем. Более того: внятное объявление типов и очевидная работа с памятью пресекают бОльшую часть ошибок ещё на этапе до компиляции. И это более заметно именно на небольших проектах. На больших проектах всё равно придётся обложиться планами, тестами т.п.

    >И говорить о C и C++ в одном контексте, право слово, почти всегда некорректно.

    Может и так, но они оба входят во множество хороших и привычных языков программирования и использовались мной именно в этом контексте.

     
  • 2.48, Аноним (48), 14:21, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    R уже есть..
     
     
  • 3.58, Аноним (-), 14:30, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В каком месте R вообще замена си? Эт ж надо такое придумать! :)
     
  • 2.51, Аноним (48), 14:23, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Эти два интерпретатора вытеснят на серверах всё кроме Лиспа. По понятной причине...

    Есть такое малознакомое понятие как ИТ безопасность, вот именно по этому понятию интерпретаторов, тем более с JIT на серверах у людей не будет.

     
     
  • 3.54, Аноним (37), 14:27, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Такая "безопасность" работает только при условии, что у злоумышленника не хватит квалификации собрать статический бинарник под целевую платформу. То есть — от пользователей Kali, разве что.
     
     
  • 4.131, Аноним (131), 15:36, 22/01/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    У людей имеющих элементарные понятия ИТ безопасности вся память, включая дисковую подсистему, выделяется или exec,ro или noexec,rw. Это требование DAC.

    А запуск бинаря через:
      /lib/ld-linux.so.2 /tmp/virus
    У дистрибутивах для людей не работает.

     
  • 4.132, Аноним (132), 16:06, 22/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Такая "безопасность" работает только при условии, что у злоумышленника не хватит квалификации собрать статический бинарник под целевую платформу.

    Садись, опять двойка.

    Речь идет о выделении оперативной память в режиме RX для исполняемых программ, RW для изменяемых данных или только R для не изменяемых данных. Это базовые, обязательные требования DAC. Выделять оперативную память в режиме WX категорически запрещается!

    Использование JIT противоречит этим правилам изменяя исполняемую область памяти.

    Как с этим всем связаны уязвимости с переполнение буфера местным двоечника тоже объяснять надо?

     
     
  • 5.137, юникснуб (?), 19:29, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не противоречит. Современные приличные JIT делают простую вещь: сначала выделяют память как RW, потом меняют права на (R)X. Все довольны.
     
  • 2.56, Аноним (-), 14:29, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Это что же, у нас будут интерпретаторы Си и Си++?

    Скачай уже наконец TCC и вот оно счастье :D. Он таки это самое умеет, прям в ридми написано.

    И таки да - он таки сперва компилит, потом запускает. Хоть и быстро и оптимизации рядом не стояли с gcc и шлангом, но по сравнению с питоном и пыхом... :)))

     
     
  • 3.102, funny.falcon (?), 21:11, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    TCC - GPL. А это резко ограничивает возможности его применения. Собственно, мне кажется, потому он и не взлетел в качестве платформы для массового JIT.
     
     
  • 4.109, Аноним (-), 04:19, 22/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Не очень ффтыкаю как GPL компилера "в режиме интерпретера" ограничивает что-то. Код с ним при этом не линкуется.

    А если это про более серьезную кодогенерацию - там скорее "ограничивает" общая тривиальность конструкции, все заточено на быстрый компил и простой код компилера. Но вот оптимальность такого кода по сравнению с gcc/clang... гм...

     
  • 2.82, nelson (??), 16:31, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +6 +/
    >> Это что же, у нас будут интерпретаторы Си и Си++?

    Подумали в своё время умные люди и создали Perl.

     
     
  • 3.138, юникснуб (?), 19:31, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Забавно, но нет.

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

     

  • 1.5, Аноним (5), 10:13, 21/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +10 +/
    >MIR

    Красноперые решили потролить неудачников из каноникала.

     
     
  • 2.16, Аноним (16), 10:55, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • –4 +/
    ... скромные боги тихо собирают МИР ...
     
     
  • 3.55, Аноним (37), 14:28, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Зачем захватывать мир, если можно сделать свой?
     
     
  • 4.63, Аноним (-), 14:40, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Весьма валидный пойнт. Но LLVM с шлангом они кажется все-таки малость подтроллили.
     

  • 1.6, Аноним (6), 10:13, 21/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    > Компиляция в MIR должна осуществляться как минимум в 100 раз быстрее, чем в GCC;

    Остальное время будет добрано на целевых компьютерах во время выполнения.

     
     
  • 2.9, Moomintroll (ok), 10:31, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >> Компиляция в MIR должна осуществляться как минимум в 100 раз быстрее, чем в GCC;
    > Остальное время будет добрано на целевых компьютерах во время выполнения.

    Исполнение MIR с использованием JIT должно быть не более чем на 30% медленнее, чем производительность исполняемого файла, собранного на основе того же Си-кода в GCC (с оптимизациями "-O2");

     
     
  • 3.27, Аноним (27), 11:35, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    про компиляцию в внутреннее представление JIT намеренно умолчали? или не знали о таком?
     
  • 2.15, bw (ok), 10:50, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Закон сохранения энергии.
    Или как вариант, код будет передаваться на "облака" RedHat и этот MIR, на самом деле, просто frontend.
     
     
  • 3.25, Аноним (37), 11:33, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Интересно, по какому закону сохранения этот "frontend" будет работать без интернета (а он будет).
     

  • 1.10, Аноним (10), 10:31, 21/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Зачем столько новых промежуточных представлений? Уже существующих недостаточно?
     
     
  • 2.12, Аноним (12), 10:43, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Это не считая того, что выходной x86(-64) код - тоже промежуточное представление, внутри проца оно совершенно иное :D
     
  • 2.87, Урри (?), 17:56, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Фатальный недостаток-с(с) у всех же.
     

  • 1.11, Аноним (12), 10:42, 21/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > Исполнение MIR с использованием JIT должно быть не более чем на 30% медленнее, чем производительность исполняемого файла, собранного на основе того же Си-кода в GCC (с оптимизациями "-O2")

    Эпическое ненужно.

     
     
  • 2.14, Аноним (14), 10:48, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    С другой стороны они все верят что именно их xIT будет праивть миром. В то время пока рынок не могут поделить .NET реализация и Java реализация, а они блин были первые выдумщики.

    Осталось только дождаться когда Python и PHP выпустит свой Just-In-Time транслаторы и все мир будет счастлив.

     
     
  • 3.22, X5asd5 (?), 11:20, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    а почему нельзя просто скомпилировать бинарник?

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

     
     
  • 4.30, Аноним (30), 11:44, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Почему бы не погуглить, зачем нужен jit?
     
     
  • 5.33, X5asd5 (?), 12:14, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    а почему бы сразу не написать сюда на форум, действительно, зачем же нужен jit ?

    наверное чтобы сожрать оперативную память на которую пользователь ПК потратил денег а теперь не знает какбы утилизировать? для этого?

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

     
     
  • 6.35, Аноним (30), 12:36, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Потому что в принципе бессмысленно что-то объяснять, если человек не знает, где используются скрипты
     
     
  • 7.100, Аноним (100), 20:37, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Там где нет денег сделать из MVP и POC проекта полноценное решение?
    Тут всем на помощь и приходят полурешения на JIT
     
     
  • 8.122, Аноним (30), 10:55, 22/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Господи, откуда вы беретесь ... текст свёрнут, показать
     
     
  • 9.139, господи (?), 19:34, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    вам лучше этого не знать, поверьте... текст свёрнут, показать
     
  • 6.83, Аноним (19), 17:46, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Значит пользователь ПК потратил недостаточно денег на оперативную память, чтобы запускаемая программа имела бы предсказуемую производительность, управляемые характеристики.
     
  • 6.101, Аноним (100), 20:38, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Дык известно же что производители железа просто щемят программистов этим вот и все
     
  • 4.61, Аноним (-), 14:33, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • –5 +/
    > а почему нельзя просто скомпилировать бинарник?

    Потому что в языке с динамической типизацией проблематично просчитать все возможные изменения переменных, например, на этапе компиляции. Просто по Тюрингу - компилер не может вынести вердикт о том чего будет с вон той переменной дальше. И поэтому не может сгенерить сколь-нибудь эффективный код, всегда надо предусматривать что переменная внезапно полностью сменила тип. А это стало быть конкретный кус кода навешивать придется. Медленный и жирный.

    Потому что в случае eval() надо еще... внезапно притащить с собой ВЕСЬ КОМПИЛЕР. В рантайме. Ну или как eval() то выполнять без этого? :)

     
     
  • 5.73, Аноним (73), 14:59, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Просто по Тюрингу

    Вот с этого момента можно дальше не читать - уровень содержимого примерно такой же: "слышал звон".

     
  • 5.104, X5asd5 (?), 22:30, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    вообще первоначальный тезис был про С другой стороны они все верят что именно... большой текст свёрнут, показать
     
     
  • 6.140, господи (?), 19:38, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    В C# есть такая штука как dynamic, почитайте: https://docs.microsoft.com/ru-ru/dotnet/api/system.dynamic.dynamicobject?view=

    В JRE по крайней мере до недавнего времени всё было более грустно, но я не слежу за ней последние годы внимательно.

     
  • 3.34, Аноним (2), 12:35, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Уже есть numba. Она даже cuda умеет. Результаты так себе, скажем, cython обеспечивает производительность равную си, а тут может ещё и хуже в зависимости от условий стать.
     
  • 3.93, 0ffh (??), 18:36, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    так cython УЖЕ есть
    правда жизни состоит в том что в том месте где живут питоны и пыхи - самое место итерпретаторам
    а всякие ускорители выполнения они конечно хорошо - но ускорители написания - как бы важнее
     

  • 1.13, Аноним (13), 10:45, 21/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    (унас_было_14_стандартов.жпг)

    Но идея годная. Если взлетит, будет хорошо.

     
  • 1.17, Ваш Анонимус (?), 11:06, 21/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    Я не понял, там названия кончились что ли?
     
     
  • 2.28, neAnonim (?), 11:35, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Они хотят "крутое" название из трех букв. н.р ( C компиляторы: pcc, tcc, lcc, gcc..) итд по другим пунктам
     
     
  • 3.38, Аноним (37), 12:47, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Они хотят "крутое" название из трех букв.

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

     

  • 1.18, myhand (ok), 11:07, 21/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > под лицензией MIT ... не исключается возможность портирования GCC на использование

    Ушли у батьки Столлмана конпилятор...

    Эх, успеют корпорасты реализовать задумки из "Право прочесть" к 2096-му году.

     
     
  • 2.24, Аноним (37), 11:30, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ушли у батьки Столлмана конпилятор...

    К тем, кто будет использовать старый gcc — выедут специально обученные люди, настучат по почкам и отправят в Siberia.

     
     
  • 3.32, Аноним (32), 12:14, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А чому не в Nigeria?
     
     
  • 4.36, Аноним (37), 12:41, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Потому что название не толерантное.
     

  • 1.29, Аноним (30), 11:43, 21/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    +1 стандарт
     
     
  • 2.39, Аноним (37), 13:06, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Пока код ISO на присвоят — не стандарт.
     
     
  • 3.141, господи (?), 19:41, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А если ISO выпустят релиз, а все остальные на эту бамажку покладут известно что, то это всё равно будет стандарт? ;) Многие вещи стандартизируют задним числом, если вы не в курсе. В том числе и в ISO.
     
  • 2.103, Аноним (103), 22:18, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    я что не понял - чем оно от вм и байткода ллвм отличается кроме того что написано другими людьми и имеет меньшее окружение?
     

  • 1.31, Аноним (31), 12:00, 21/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Какая-то детская фиксация на цифре 100. В сто раз быстрее, меньше... Прям как "мой папа в сто раз сильнее твоего, он машину одной рукой поднимет".
     
     
  • 2.40, Аноним (37), 13:07, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Современные физики и инженеры с их «разница величин оценивается как минимум в два порядка» недалеко от них ушли.
     
     
  • 3.86, Аноним (19), 17:53, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    На два порядка. Логарифмы складываются.
     
  • 2.64, Аноним (-), 14:41, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну а что, иногда даже правда. Нацепит экзоскелет - и подымет.
     

  • 1.41, nelson (??), 13:38, 21/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    >> Код проекта написан на языке Си

    ну, хотя бы, подходящий язык для реализации выбрали, а не хипстерскую растишку, уже норм.
    >> в будущем планируется реализовать возможность генерации MIR для WebAssembly, байткода Java, CIL (Common Intermediate Language), Rust и C++

    в случае с растишкой - это правильное решение, всё равно этому языку ничего не светит в системном программировании, а пилить веб-фреймворки хипстерам будет сподручнее на языке, транслируемом в представление для последуюшей JIT-компиляции вот этим вот JIT-компилятором MIR, к примеру.
    транслировать же С и С++ в промежуточное представление... хз. зачем, если есть жаба.

     
     
  • 2.42, Owlet (?), 13:46, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > всё равно этому языку ничего не светит в системном программировании

    ... говорят люди, не имеющие понятия ни о расте, ни о системного программировании...

     
     
  • 3.50, Аноним (37), 14:22, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это всё гуманитарные дисциплины, и настоящему айтишнику их знать не надо. Вот философия Unix — это да, без неё — вон из профессии.
     
  • 3.79, nelson (??), 15:52, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    растишка - это диверсия в сфере разработки системного ПО. язычёк, в котором манипуляция объектамм в памяти осуществляется посредством костылей, придуманных для неосиляторов адресной арифметики, объективно не нужен
     
     
  • 4.124, Анончик (?), 12:46, 22/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Растишка переносит отлов багов с адресной арифметикой с этапа исполнения на этап компиляции. Вот такая простая идея.
    А нужно ему или нет каждый решает сам.
     
  • 2.67, Аноним (67), 14:47, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > транслировать же С и С++ в промежуточное представление... хз. зачем, если есть жаба.

    GCC и сейчас это до некоторой степени делает. Хоть и несколько своеобразно.

    Зачем? А затем что компилеру целящему в более чем 1 архитектуру удобнее сперва сгенерить код "абстрактно" а потом это уже транслировать в конкретный набор команд с их особенностями. Вообще совсем целиком переписывать вообще все пути кода под каждую новую архитектуру несколько утомительно.

     
     
  • 3.81, nelson (??), 16:11, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    речь о промежуточном представлении для компиляции JIT-компилятором. а в случае с GCC дело не только в трансляции под разные архитектуры. абстрактное представление позволяет также добавить поддержку нового ЯПа
     
     
  • 4.110, Аноним (-), 04:26, 22/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Насколько я понял идею этой штуки - это предлагается как некий IR, более логичный и юзабельный чем LLVMовский. В том числе в этом вроде бы предполагается возможность притащить "абстрактный" бинарник а на целевой платформе его перегнать в нативный относительно малой кровью.

    В случае LLVM они подобные юзкейсы не предусмотрели как класс, насколько я понимаю. Что довольно странно, но жираф большой, ему видней. В этом местя есть некий шанс подстебать этих господ, занвя кусочек "их" ниши.

     
     
  • 5.125, Анончик (?), 12:49, 22/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Просто llvm очень жирный и долго работает перегоняя свой ir в наивный код. Автор делает тоже самое только его реализация маленькая и быстро делает наивный код за счёт минимальной оптимизации.
     

  • 1.44, None (??), 13:57, 21/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –8 +/
    Вообще всякие JIT нужны для того, чтобы не светить исходниками клиентам, для чего это конторе, которая вроде как опенсорсом занимается?..
    ой, простите, совсем забыл, что там новый хозяин... тогда всё становится на свои места, понятно, кто задачку поставил...
     
     
  • 2.52, Аноним (37), 14:24, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Опять пятнадцатицентовые из оракла. Унылые и однообразные, как всегда.
     

  • 1.45, Урри (?), 14:01, 21/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Еще один убийца джавы?
    Весело год начался. Один выкатывает очередного убийцу мейка, эти выкатывают убийцу джавы. Кто у нас будет следующим, очередной шел?
     
  • 1.46, arisu (ok), 14:12, 21/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    как всегда — в libjit нашли Фатальный Недостаток.
     
     
  • 2.68, Аноним (67), 14:48, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Судя по описанию - достаточно разные штуки.
     
     
  • 3.72, arisu (ok), 14:57, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Судя по описанию - достаточно разные штуки.

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

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

     
     
  • 4.143, господи (?), 19:48, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Они об этом прямым текстом говорят, предсказатель вы наш: "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".

    Ну или вы хотели как-то странно пошутить, но не вышло. Сочувствую, со всеми бывает.

     
     
  • 5.144, arisu (ok), 19:51, 23/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    ты плохой, ненастоящий господи. потому что глупый очень.
     

  • 1.49, Аноним (49), 14:22, 21/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Промежуточный код MIR может быть представлен в бинарном и текстовом (читаемом) виде.

    Хм, непосредственно править байт код ... хм.

     
     
  • 2.59, Аноним (37), 14:30, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В текстовом виде — это уже не байт-код, а лайн-код.
     
  • 2.69, Аноним (67), 14:49, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Хм, непосредственно править байт код ... хм.

    Ассемблер же правят. А это чем хуже?

     
     
  • 3.71, Аноним (49), 14:54, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Ассемблер же правят. А это чем хуже?

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

     
     
  • 4.111, Аноним (-), 04:28, 22/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну например JAVA выросла в адского переусложненного монстра который подразумевает немеряный рантайм и либы и половина перечисленных в сабже юзкейсов на основе жабы просто не выглядит жизнеспособно.
     

  • 1.57, Аноним (-), 14:30, 21/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    >В текущем виде реализация MIR во многим опережает изначально поставленные цели: проведённые тесты показали, что производительность компиляции в MIR быстрее "GCC -O2" в 178 раз

    ЭЭ братан, не надо сравнивать тёплое с мягким, ты знаешь как компилируется сишный код. Сначала, идёт добавление заголовочных файлов, затем работает синтаксический и лексический анализаторы, затем код ассемблируется, только после, всего этого ассемблерный код синтаксиса, трушно Юниксового AT&T, превращается в бинарь.

    >производительность исполнения отстаёт от нативного кода на 6%, размер кода меньше в 144 раза

    Конечно, интерпретируемая Природа всегда медленее компилируемой природы.

    >реализация MIR JIT составляет 16 тысяч строк кода.

    Это не показатель. Разработчики GCC пишут на С++.

     
  • 1.60, erthink (ok), 14:30, 21/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Затея интересная, точно будет полезна для 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).

     
     
  • 2.114, GentooBoy (ok), 08:29, 22/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >- при трансляции из 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 что то поможет.
    Будем надеяться что у Владимира Макарова получиться, но работа очень большая в одного можно зарюхаться.

     
     
  • 3.116, arisu (ok), 08:52, 22/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Будем надеяться что у Владимира Макарова получиться, но работа очень большая в
    > одного можно зарюхаться.

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

     
     
  • 4.120, GentooBoy (ok), 09:25, 22/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну все немного сложнее, изначально это был пет проект как я понимаю. Потом шапка разрешыла работать фултайм. Ну а идея была в том что бы добавить в  Ruby  jit,  хотя у  core team очень странное видение, они хотят все свое без внешних зависимостей.
     
     
  • 5.121, arisu (ok), 09:33, 22/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    (на всякий случай: я не имел в виду ничего негативного. просто автор сознательно пошёл в NIH-территорию, а там Свои, Особые Правила. ;-)
     
  • 3.123, erthink (ok), 11:50, 22/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>- при трансляции из 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 ровно тоже самое.

     
     
  • 4.126, Анончик (?), 12:58, 22/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Эти отключают оптимизации llvm, дабы генерить как можно более простой llvm ir. О полном один в один переносе речь конечно не идёт.

    Если вы уже залезли в репу то посмотрите что там сделано в llvm2mir

     
     
  • 5.129, erthink (ok), 14:19, 22/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Эти отключают оптимизации llvm, дабы генерить как можно более простой llvm ir.
    > О полном один в один переносе речь конечно не идёт.

    Теоретически конечно можно генерировать "более простой llvm ir".

    Но практически это не имеет ценности:
    - вы должны обучить каждый ir-генератор (условный clang или rust) генерировать такой куцый ir (фактический отдельный диалект LLVM IR).
    - соответственно вы должны выпилить из условного rust все возможности связанные с расширенными инструкциями сделав куцый вариант условного rust.
    - совместимость с таким куцым условным rust потребует правки исходников.
      

    > Если вы уже залезли в репу то посмотрите что там сделано в
    > llvm2mir

    Посмотрел, там ровно то, что я описал в первоначальном комментарии.
    Есть чуть конкретнее, то llvm2mir просто сообщает "unsupported/unimplemented" почти во всех случаях, о которых я говорю.
    Собственно это явно описано в README проекта, только в других формулировках.

     
  • 4.127, GentooBoy (ok), 13:35, 22/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Да вы правы, будут проблемы.
     
  • 2.128, Аноним (128), 13:57, 22/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    следующая версия будет содержать все инструкции :D
     
     
  • 3.130, erthink (ok), 14:25, 22/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > следующая версия будет содержать все инструкции :D

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

     

  • 1.70, Аноним (70), 14:54, 21/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Что значит "сренегерировать"?
     
  • 1.77, Аноним (77), 15:31, 21/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >В компании Rad Hat ведётся разработка нового легковесного JIT-компилятора MIR
    >Код проекта написан на языке Си

    Это все что надо знать о нужности современных язычков...

     
     
  • 2.84, Аноним (84), 17:48, 21/01/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    ну дак не на расте же писать, у тех девственниц истерика случается при виде указателя.
     

  • 1.96, kernel_panic (??), 18:46, 21/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    ГНУтые поделия постепенно выбрасываются, скоро и ядро перелицензируют на какой-нибудь MIT.
     
  • 1.97, Анонимныйаноним (?), 19:03, 21/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    А для питона будет?
     
     
  • 2.107, Led (ok), 00:20, 22/01/2020 [^] [^^] [^^^] [ответить]  
  • +8 +/
    В ложку питона сколько бочек мёда не докидывай - всё равно питоном останется.
     
  • 2.112, Аноним (-), 04:29, 22/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Для какой-нибудь обкоцаной недо-версии с более-менее статическими типами и без всяких eval... ?
     

  • 1.99, rc.conf (?), 20:09, 21/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Лучше бы Red Hat развивал ZFS, выкупив её у Oracle.
     
  • 1.115, GentooBoy (ok), 08:52, 22/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Я просто оставлю это здесь https://github.com/wasmerio/wasmer
     
     
  • 2.117, arisu (ok), 08:57, 22/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    ну и зачем ты напачкал?
     
     
  • 3.119, GentooBoy (ok), 09:21, 22/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Может кто то поиграть захочет с теми же яйцами только в профиль.
     

  • 1.134, s9gf4ult (ok), 19:37, 22/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Но WASM же делает то же самое. Нахера?
     
     
  • 2.145, Аноним (103), 13:53, 24/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >Но WASM же делает то же самое. Нахера?

    и ллвм делает почти тоже самое, даже больше. Если кто знает - напишите зачем оно нужно при наличии ллвм и остального?

     
     
  • 3.146, erthink (ok), 14:22, 24/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >>Но 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.

    Как-то так.

     

  • 1.151, Lockywolf (ok), 00:15, 03/02/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Можно, наверное, написать ридер mir-ir для Схемы, если там так мало инструкций. И получится компилятор Руби в Схему. Отличное решение, я считаю.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру