Повышение производительности при компиляции Java в нативный код?

Question

Есть ли какая-либо производительность, которая может быть достигнута в наши дни от компиляции Java до нативного кода, или современные компиляторы горячих точек в конечном итоге делают это со временем?

Answer 1

Недавно было похожее обсуждение вопроса В чем преимущества байт-кода над нативным кодом? . Вы можете найти интересные ответы в этой теме.

Answer 2

Еще несколько неподтвержденных доказательств. Я работал над несколькими критически важными для торговли финансовыми приложениями в реальном времени. Я согласен с Фрэнком, почти каждый раз, когда ваша проблема не в отсутствии компиляции, а в вашем алгоритме или структуре данных. Современные компиляторы горячих точек очень хороши с правильным кодом, например, библиотека CERN Colt находится в пределах 90% от скомпилированного, оптимизированного Fortran для числовой работы.

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

За последние несколько лет мы использовали только один скомпилированный код для скорости в одном экземпляре, поэтому мы могли использовать CUDA и получить серьезную производительность графического процессора.

Answer 3

Ваш вопрос немного велик, ответ сильно варьируется

• Если вы используете компиляцию Just In Time (JIT) или нет
• Когда вы используете ,, если ваш процесс выполняется в течение длительного времени или нет

Все последние версии JVM используют JIT, но на старых JVM код java в несколько раз медленнее, чем собственный код.

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

Мы написали один и тот же пакет как на C ++, так и на Java и запустили его с другим набором данных, результат отличается примерно на 3 секунды, а набор данных занимает от 5 минут до нескольких часов.

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

Answer 4

Производительность памяти или производительность процессора? Или они одинаковы в наши дни?

Мое единственное доказательство - анекдотичный и на другой платформе: после портирования множества приложений, нагруженных процессором, на C # (.NET 2.0) я не заметил существенной потери производительности (я не считаю 10% существенной). Хорошо написанный код хорошо работает на разных архитектурах.

Большинство приложений тратят / тратят время на:

• Операции ввода-вывода, которые не выиграют от статического (во время компиляции) анализа.
• Плохие алгоритмы, которые не выиграют от статического анализа.
• Плохое расположение памяти в критических внутренних циклах ЦП. Хотя технически возможно, что здесь нам помогут компиляторы, я еще не видел, чтобы настоящий компилятор делал что-нибудь интересное.

Итак, исходя из моего опыта, если вы не пишете видеокодек, компиляция Java-приложений не принесет никакой пользы, а просто полагается на компиляторы горячих точек.

Answer 5

Попробовал Hello-World с шестью различными реализациями, просто чтобы проверить накладные расходы и разница была ошеломляющей. Java была вне чартов, в то время как скомпилированные языки работали одинаково хорошо. Я мог бы доказать все доказательства (в воспроизводимых), если это необходимо.