Почему сложно превзойти AOT-компилятор с помощью JIT-компилятора (с точки зрения производительности приложения)? - PullRequest
Новая
       64

Почему сложно превзойти AOT-компилятор с помощью JIT-компилятора (с точки зрения производительности приложения)?

32 голосов
/ 29 сентября 2011

Я думал, что компиляторы JIT в конечном итоге превзойдут компиляторы AOT с точки зрения производительности скомпилированного кода из-за присущего JIT преимущества (можно использовать информацию, доступную только во время выполнения). Одним из аргументов является то, что компиляторы AOT могут тратить больше времени на компиляцию кода, но виртуальная машина сервера также может тратить много времени.

Я понимаю, что JIT, кажется, побеждает компиляторы AOT в некоторых случаях, но в большинстве случаев они все еще отстают.

Итак, мой вопрос: какие конкретные, жесткие проблемы мешают компиляторам JIT побеждать компиляторы AOT?

EDIT:
Некоторые общие аргументы:

  • Компиляторы AOT могут тратить больше времени на расширенную оптимизацию -> Если вы используете виртуальную машину сервера в течение нескольких дней, вы можете потратить столько же времени, если не дольше.
  • Интерпретация байтового кода стоит -> В наши дни большинство JIT-компиляторов кэшируют собственные машинные инструкции.

Еще одно редактирование:
Конкретный пример см. В этой статье: Улучшение производительности Swing: JIT vs AOT Compilation . Из того, что я могу извлечь из этой статьи, авторы в основном говорят, что, когда нет горячих точек, преимущество наличия информации времени выполнения уменьшается и, таким образом, выигрывает AOT без издержек JIT. А на 40% ?? Это не имеет большого смысла. Просто ли сравниваемый JIT-компилятор не был настроен для этой ситуации? Или это что-то более фундаментальное?

1 Ответ

29 голосов
/ 29 сентября 2011

Существует определенный компромисс между JIT и AOT (досрочно) компиляцией.

Как вы сказали, JIT имеет доступ к информации времени выполнения, которая может помочь в оптимизации.Это включает в себя данные о машине, на которой он выполняется, что позволяет использовать встроенную оптимизацию для конкретной платформы.Однако у JIT также есть издержки на перевод байт-кода в нативные инструкции.

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

Например,взято из статьи, на которую вы ссылались :

... что мы должны улучшить в отсутствие явных узких мест производительности?Как вы уже догадались, такая же проблема существует для JIT-компиляторов с профильным управлением.Вместо нескольких «горячих точек», которые нужно агрессивно оптимизировать, существует множество «теплых точек», которые остаются нетронутыми.

Компиляторы AOT также могут тратить столько времени на оптимизацию, сколько им нравится, тогда как компиляция JITсвязаны с требованиями времени (для поддержания отзывчивости) и ресурсов клиентского компьютера.По этой причине компиляторы AOT могут выполнять сложную оптимизацию, которая была бы слишком дорогостоящей во время JIT.

Также см. Этот вопрос SO: JIT-компилятор по сравнению с автономными компиляторами

...