> И да, драйверу GPU например несколько не комильфо стартовать новые процессы
> с компилером. Функцию библы позвать — еще куда ни шло.действительно, то ли дело — прямо в драйвер вкорячить немеряных размеров библиотеку компилятора. это же так секурно, а память вообще экономит прямо влёт: пользователь же каждую наносекунду какой-нибудь шэйдер компилирует!
намного разумней как раз отдельные процессы, стандартизованый язык и универсальный способ вызова компилятора. и не нужно таскать с собой костыли: большинство софта будет вызывать оный компилятор при установке, заранее собирая шейдеры под GPU, который на борту. и оставшаяся небольшая часть — вызывать по мере необходимости. that's all, folks!
> Аналогично — везде где надо скрипты или байткод выполнять, они тормозят если
> их интерпретировать, т.к. полезная логика всегда сильно разбавлена логикой интерпретатора.
> А если все заранее в нативный машинный код перегнать и выполнять
> его — можно сочетать достоинства компиляторов и интерпретаторов. От интерпретаторов —
> не надо заранее знать какая платформа + нет видимой програмеру фазы
> компиляции под каждую конкретную платформу. От компиляторов — скорость выполнения типичная
> для компилированного кода. Просто фазу окончательной компиляции в нативный код снесли
> на юзеря. Это чем-то похожа на гентушников :))) но совсем не
> в том виде каком они себе это представляли.
а этот пассаж вообще офигительно смешон. сразу видно человека, который проблематику JIT-компиляторов для «динамических» языков не понимает вообще. максимум — что-то там слышал краем уха, и уверен, что AOT-компилятор завсегда лучше JIT в любой области. и что полновесный AOT-компилятор типа GCC — это такая мелочь, оверхэд от которой вообще не стоит упоминания.
ещё раз отправляю тебя внимательно смотреть на LuaJIT2. и на то, как происходит кодогенерация в GCC и сколько все его фазы весят (как в плане памяти, так и в плане скорости). это для начала.
