Было много ажиотажа по поводу JIT-компиляторов для таких языков, как Java, Ruby и Python. Чем JIT-компиляторы отличаются от компиляторов C / C ++ и почему компиляторы, написанные для Java, Ruby или Python, называются JIT-компиляторами, а компиляторы C / C ++ просто называются компиляторами?
Ответы:
JIT-компиляторы компилируют код на лету, прямо перед их выполнением или даже когда они уже выполняются. Таким образом, виртуальная машина, на которой выполняется код, может проверять наличие шаблонов при выполнении кода, чтобы разрешить оптимизацию, которая была бы возможна только с информацией времени выполнения. Кроме того, если виртуальная машина решит, что скомпилированная версия по какой-либо причине недостаточно хороша (например, слишком много кеш-памяти или код часто выдает конкретное исключение), она может решить перекомпилировать ее другим способом, что приведет к гораздо более умной сборник.
С другой стороны, компиляторы C и C ++ традиционно не являются JIT. Они компилируются за один раз на компьютере разработчика, а затем создается исполняемый файл.
JIT - это сокращение от "своевременного компилятора", и его называют "misson": во время выполнения он определяет полезные оптимизации кода и применяет их. Он не заменяет обычные компиляторы, но является частью интерпретаторов. Обратите внимание, что языки, такие как Java, которые используют промежуточный код, имеют как обычный компилятор для перевода исходного кода в промежуточный, так и JIT, включенный в интерпретатор для повышения производительности.
Оптимизация кода, безусловно, может выполняться «классическими» компиляторами, но обратите внимание на основное отличие: JIT-компиляторы имеют доступ к данным во время выполнения. Это огромное преимущество; эксплуатировать его должным образом может быть трудно, очевидно.
Рассмотрим, например, такой код:
m(a : String, b : String, k : Int) {
val c : Int;
switch (k) {
case 0 : { c = 7; break; }
...
case 17 : { c = complicatedMethod(k, a+b); break; }
}
return a.length + b.length - c + 2*k;
}
Обычный компилятор не может сделать слишком много с этим. Однако JIT-компилятор может обнаружить, что он mвызывается только k==0по какой-то причине (подобные вещи могут происходить по мере изменения кода с течением времени); затем он может создать уменьшенную версию кода (и скомпилировать его в нативный код, хотя я концептуально считаю это второстепенным):
m(a : String, b : String) {
return a.length + b.length - 7;
}
В этот момент он, вероятно, даже встроит вызов метода, поскольку теперь он тривиален.
По-видимому, Sun отклонил большинство оптимизаций, javacиспользуемых в Java 6; Мне сказали, что из-за этих оптимизаций JIT сильно мешал, и в конце концов наивно скомпилированный код работал быстрее. Пойди разберись.
mверсию, которая не проверяет, kпоскольку он не сможет доказать, mчто никогда не будет вызван с ненулевым k, но даже без возможности доказать, что он может заменить это с static miss_count; if (k==0) return a.length+b.length-7; else if (miss_count++ < 16) { ... unoptimized code for м ...} else { ... consider other optimizations...}.
k=0 всегда означает, что это не является функцией ввода или среды, можно отказаться от теста, но для его определения требуется статический анализ, который очень дорог и, следовательно, доступен только во время компиляции. JIT может победить, когда один путь через блок кода выбирается намного чаще, чем другие, и версия кода, специализированная для этого пути, будет намного быстрее. Но JIT все равно будет выдавать тест, чтобы проверить, применяется ли быстрый путь , и, если нет, выбрать «медленный путь».
Base* pпараметр и через него вызывает виртуальные функции; Анализ во время выполнения показывает, что фактический объект, на который указывает всегда (или почти всегда), кажется, имеет Derived1тип. JIT может создать новую версию функции со статически разрешенными (или даже встроенными) вызовами Derived1методов. Этому коду будет предшествовать условие, которое проверяет, pуказывает ли указатель vtable на ожидаемую Derived1таблицу; если нет, вместо этого он переходит к исходной версии функции с более медленными динамически разрешаемыми вызовами методов.