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

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

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

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

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

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

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

33
задан Seki 11 June 2015 в 09:44
поделиться