Почему больше программного обеспечения Java не компилируется исходно?
Я осознаю преимущества байт-кода по сравнению с собственным кодом (мобильность).
Но скажите, что Вы всегда знаете, что Ваш код будет работать на x86 архитектуре, почему не затем компилируют для x86 и получают выигрыш в производительности?
Обратите внимание, что я предполагаю, что существует увеличение производительности к компиляции собственного кода. Некоторые люди ответили, что не могло на самом деле быть никакого усиления, которое является новостями мне..
8 ответов
Потому что повышение производительности (если таковое имеется) не стоит усилий.
Кроме того, сборка мусора очень важна для производительности. Скорее всего, GC JVM лучше, чем тот, который встроен в скомпилированный исполняемый файл, скажем, с GCJ .
И своевременная компиляция может даже привести к лучшей производительности, потому что JIT имеет больше информации, доступной во время выполнения для оптимизации компиляции, чем компилятор во время компиляции. См. Страницу в Википедии на JIT .
Он уже будет скомпилирован JIT в собственный код Solaris после запуска. Вы не получите никаких других преимуществ, если скомпилируете его перед загрузкой на целевой сайт.
«Solaris» - это операционная система, а не архитектура процессора. JVM, установленная на реальной машине, будет компилироваться в соответствии с инструкциями собственного процессора. Solaris может иметь архитектуру SPARC, x86 или x86-64.
Кроме того, JIT-компилятор может выполнять оптимизацию для конкретного процессора в зависимости от того, какое у вас фактическое семейство ЦП. Например, разные последовательности инструкций выполняются быстрее на процессорах Intel, чем на процессорах AMD, и JIT-компилятор для вашей конкретной платформы может воспользоваться этой информацией для создания высокооптимизированного кода.
Байткод запускается в виртуальной машине Java, которая скомпилирована для (например) Solaris. Он будет чертовски оптимизирован для этой операционной системы.
В реальных случаях вы часто увидите равную или лучшую производительность Java-кода во время выполнения, благодаря использованию кода виртуальной машины для таких вещей, как управление памятью - этот код развивался и совершенствовался годами.
Существует больше преимуществ создания кода для JVM, чем просто переносимость - например, каждый раз, когда выпускается новая JVM, ваш скомпилированный байткод получает любые оптимизации, алгоритмические улучшения и т.д., которые приходят от лучших в своем деле. С другой стороны, как только вы скомпилировали свой код на C, это все.
Потому что при своевременной компиляции есть тривиальный выигрыш в производительности.
На самом деле многие вещи JIT может делать быстрее.
Вы можете получить, а можете и не получить выигрыш в производительности. Но более вероятно, что вы получите штраф за производительность: JIT оптимизация невозможна при статической компиляции, поэтому производительность будет только настолько хорошей, насколько компилятор может сделать ее "с завязанными глазами" (без фактического профилирования программы и соответствующей оптимизации, что и делают JIT компиляторы, такие как HotSpot).
Интуитивно удивительно, насколько дешевой (с точки зрения ресурсов) является компиляция, и как много можно автоматически оптимизировать, просто наблюдая за работающей программой. Черная магия, но нам на пользу :-)
Кстати, все эти разговоры о JIT устарели примерно на семь лет. Соответствующая технология сейчас называется HotSpot, и это не просто JIT.
Я думаю, потому что JIT-компиляция (точно в срок) очень продвинута.