Почему больше программного обеспечения Java не компилируется изначально?

Question

Я понимаю, преимущества байт-кода по сравнению с нативным кодом (переносимость).

Но скажем, вы всегда знаете, что ваш код будет работать на архитектуре x86, почему бы тогда не скомпилировать для x86 и не получить выигрыш в производительности?

Обратите внимание, что я предполагаю, что при компиляции собственного кода выигрыш в производительности. Некоторые люди ответили, что на самом деле не может быть никакой выгоды, что является новостью для меня ..

Answer 1

Потому что увеличение производительности (если есть) не стоит хлопот.

Также, сборка мусора очень важна для производительности. Скорее всего, GC JVM лучше, чем встроенный в скомпилированный исполняемый файл, скажем, с GCJ .

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

Answer 2

"Solaris" - это операционная система, а не архитектура процессора. JVM, установленная на реальной машине, будет компилироваться с собственными инструкциями ЦП. Solaris может быть SPARC, x86 или x86-64.

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

Answer 3

Байт-код выполняется на виртуальной машине Java, которая скомпилирована для (например) Solaris. Это будет оптимизировано, как черт возьми для этой операционной системы.

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

Существует больше преимуществ для создания JVM, чем просто переносимость - например, каждый раз, когда выпускается новая JVM, ваш скомпилированный байт-код получает любые оптимизации, алгоритмические улучшения и т. Д., Которые исходят от лучших в бизнесе. С другой стороны, как только вы скомпилировали свой код на C, вот и все.

Answer 4

Поскольку компиляция Just-In-Time обеспечивает тривиальное повышение производительности.

На самом деле, многие вещи JIT могут делать быстрее.

Answer 5

Вы можете или не можете получить выигрыш в производительности.Но, скорее всего, вы получите снижение производительности: оптимизация JIT невозможна при статической компиляции, поэтому производительность будет настолько хорошей, насколько компилятор сможет сделать ее «с завязанными глазами» (без фактического профилирования программы и соответствующей ее оптимизации, что и являетсяJIT-компиляторы, такие как HotSpot).

Интуитивно довольно удивительно, насколько дешевой (с точки зрения ресурсов) компиляции, и сколько можно автоматически оптимизировать, просто наблюдая за работающей программой.Черная магия, но хорошо для нас: -)

Answer 6

Он уже будет скомпилирован JIT в собственный код Solaris после запуска. Вы не сможете получить другие преимущества, если скомпилируете их перед загрузкой на целевой сайт.

Answer 7

"почему бы не скомпилировать для x86"

Потому что тогда вы не сможете воспользоваться специфическими особенностями конкретного процессора, на котором он запускается. В частности, если мы будем читать «compile for x86» как «производить нативный код, который может работать на 386 и его потомках», то результирующий код не может полагаться даже на что-то более старое, чем инструкции mmx.

Таким образом, конечный результат заключается в том, что вам нужно скомпилировать для каждой конкретной архитектуры, на которой он будет работать (как насчет тех, которые еще не существуют), и попросить установщика выбрать, какой исполняемый файл поместить на место. Или я слышал, что компилятор intel C ++ создаст несколько версий одной и той же функции, отличающихся только используемыми функциями процессора, и выберет правильную во время выполнения в зависимости от того, что процессор сообщает о доступности.

С другой стороны, вы можете просматривать байт-код как «полускомпилированный» источник, подобный промежуточному формату, в котором собственный компилятор (если не будет задан вопрос) фактически не будет записывать на диск. Затем среда выполнения может выполнить окончательную компиляцию, точно зная, какая архитектура будет использоваться. Именно по этой причине некоторое время назад некоторый код на C # /. Net мог немного превзойти код на C ++ в некоторых ресурсоемких задачах в некоторых тестах.

«Окончательная компиляция» байт-кода может также сделать дополнительные предположения по оптимизации, которые (с точки зрения статической компиляции) явно небезопасными *, и просто перекомпилировать, если эти предположения будут позже ошибочными.

Answer 8

Кстати, все эти разговоры о JIT устарели примерно на семь лет. Соответствующая технология сейчас называется HotSpot, и это не просто JIT.

Answer 9

Я думаю, потому что JIT (как раз вовремя) компиляция очень продвинута.