Комментарии 4
обёртывать существующие блоки кода для SQL opcode’ов в callback’и, вызываемые в JIT-компилируемом коде — это также позволяет избавиться от довольно нетривиального дублирования кода при использовании первого подхода.
не особо понятно, что это означает. Можно, пожалуйста, демонстрирующий идею пример?
Скорее всего, имеется ввиду повторное использование интерпретатора байт-кода, если можно так выразиться. Представь что у тебя в интерпретаторе байт-кода есть какая-нибудь функция handleSelect(). При генерации машинного кода грубо говоря встраивается вызов функции с аналогичной реализацией (с точностью до оптимизаций), который впоследствии должен inline-иться. И при таком подходе основной прирост производительности должен быть за счет этих самых inline-ов: захотел ты обработать R строк в таблице, на каждую строку при интерпретации у тебя было бы N вызовов, несущих в себе еще и PUSH/MOV-инструкции, а так у тебя в конечном счете выполняется на O(RN) инструкций меньше.
Привет!
@xhinhellhxвсё правильно написал. Проиллюстрирую на примере OP_Column: оборачиваем этот switch-case в функцию, добавляем её в бутстрап-модуль LLVM, загружаем её сигнатуру оттуда, и, наконец, генерируем вызовы к ней, когда JIT-компилируем OP_Column'ы.
Добавлю от себя ещё, что помимо сшития (избавления от интрукций перехода) машинного кода, который дает inlining, есть возможность использовать оптимизационные проходы LLVM — за счет динамической информации об аргументах callbaсk'ов (сейчас понял, что тут этот термин действительно немного не к месту здесь), помимо прочего, можно убирать целые ветки кода (читай: constexpr if statement). Причем при таком подходе результат получается автоматически.
LLVM - это тупиковая ветвь. При чём и в хорошем смысле тоже.
LLVM может выдавать хорошо оптимизированный код. Потому его есть смысл использовать для тяжёлых запросов. Но делает он это долго. Потому использовать его можно только для долгих запросов.
Сколько не видел проектов в opensource “а давайте для JIT прикрутим LLVM”, выжили только ориентированные на долгие во времени потребности: математика (julia, pystone), и долгие запросы в постгрессе. Или как последняя стадия для супер-пупер-горячих мест, когда затраты на ещё одну компиляцию оправдываются преимуществом перед кодом, выданным более лёгким JIT.
В том же PostgreSQL хоте ли бы больше компилить, но накладные расходы слишком высоки.
Все же «шустрые» JIT в основном самописные. MIR - реально стоящая инициатива в направлении универсального лёгкого JIT с хорошей лицензией. Попробовали бы вы его. Думаю, результат будет интереснее.
По-моему мнению, лицензия GPL - одна из причин, почему большинство других лёгких JIT не получили распространения: libjit, tcc (tinyc), gnu lighning - возможностей много, но в не GPL продукт не воткнешь.
Автор MIR же выбрал хорошую лицензию.
Do it yourself: JIT компиляция SQL в Tarantool