Я понимаю преимущества для байт-кода и собственного кода (переносимость).
Но скажите, что вы всегда знаете, что ваш код будет работать на архитектуре x86, почему бы не компилировать его для x86 и получить выгоду от производительности?
Обратите внимание, что я предполагаю, что есть усиление производительности для компиляции собственного кода. Некоторые люди ответили, что на самом деле не может быть никакой выгоды, которая для меня новость.
Потому что выигрыш в производительности (если есть) не стоит проблем.
Кроме того, сборка мусора очень важна для производительности. Скорее всего, что GC JVM лучше, чем встроенный в скомпилированный исполняемый файл, например GCJ.
И только во время компиляции может даже привести к повышению производительности, поскольку JIT имеет больше информации, доступной во время выполнения для оптимизации компиляции, чем компилятор во время компиляции. См. Страницу wikipedia на JIT.
"Solaris" - это операционная система, а не архитектура процессора. JVM, установленный на фактическом компьютере, будет скомпилирован с инструкциями собственного процессора. Solaris может быть архитектурой SPARC, x86 или x86-64.
Кроме того, JIT-компилятор может выполнять оптимизацию, зависящую от процессора, в зависимости от того, какое у вас семейство CPU. Например, на процессорах Intel быстрее работают разные последовательности команд, чем на процессорах AMD, а компилятор JIT для вашей точной платформы может использовать эту информацию для получения высоко оптимизированного кода.
Байт-код запускается на виртуальной машине Java, которая скомпилирована для (например) Solaris. Он будет оптимизирован, как черт для этой операционной системы.
В реальных случаях вы часто видите равную или лучшую производительность Java-кода во время выполнения, благодаря созданию кода виртуальной машины для таких вещей, как управление памятью - этот код будет развиваться и созревать в течение многих лет.
Там больше преимуществ для создания JVM, чем просто переносимости - например, каждый раз, когда выпущена новая JVM, ваш скомпилированный байт-код получает любую оптимизацию, алгоритмические улучшения и т.д., которые исходят из лучших в бизнесе. С другой стороны, как только вы скомпилировали свой C-код, это его.
Потому что с компиляцией Just-In-Time существует тривиальное преимущество в производительности.
На самом деле, многие вещи JIT могут делать быстрее.
Он уже будет скомпилирован JIT в собственный код Solaris после запуска. Вы не можете получать какие-либо другие преимущества, если компилируете его перед загрузкой на целевой сайт.
Вы можете или не можете получить выгоду от производительности. Но, скорее всего, вы получите штраф за производительность: оптимизация JIT невозможна при статической компиляции, поэтому производительность будет такой же хорошей, как компилятор может сделать ее "с завязанными глазами" (без фактического профилирования программы и ее оптимизации соответственно, что и есть JIT-компиляторы, такие как HotSpot).
Интуитивно удивительно, как дешево (с точки зрения ресурсов) компиляция, и сколько можно автоматически оптимизировать, просто наблюдая за запущенной программой. Черная магия, но хорошо для нас: -)
Все эти разговоры о JIT - это около семи лет устаревших BTW. Соответствующая технология теперь называется HotSpot, и это не просто JIT.
"почему бы не компилировать для x86"
Потому что тогда вы не можете воспользоваться конкретными особенностями конкретного процессора, на котором он запускается. В частности, если мы хотим прочитать "компилировать для x86" как "создать собственный код, который может работать на 386 и его потомках", тогда полученный код не может полагаться даже на то, что старое, как инструкции mmx.
Таким образом, конечный результат заключается в том, что вам нужно скомпилировать для каждой точной архитектуры, в которой он будет работать (что еще не существует), и попросите установщика выбрать, какой исполняемый файл ввести в действие. Или я слышал, что компилятор Intel С++ выпустит несколько версий одной и той же функции, отличающихся только используемыми функциями cpu, и выберите правильный во время выполнения на основе того, что сообщает CPU как доступный.
С другой стороны, вы можете просмотреть байт-код как "скомпилированный" источник, аналогичный промежуточному формату, который нативный компилятор (если не задал вопрос) не записывает на диск. Затем среда выполнения может выполнять окончательную компиляцию, зная, какая архитектура будет использоваться. Это причина, по которой некоторый код С#/.NET может немного превосходить С++-код в некоторых задачах с высокой интенсивностью процессора в некоторых тестах некоторое время назад.
"Окончательная компиляция" байт-кода также может сделать дополнительные предположения о оптимизации, которые (с точки зрения статической компиляции) отчетливо небезопасны *, и просто перекомпилировать, если эти предположения будут обнаружены позже.
Я думаю, потому что компиляция JIT (как раз вовремя) очень продвинута.