WikiDer > Производительность Java - Википедия

Java performance - Wikipedia
Эта статья представляет собой общую презентацию Платформа Java спектакль. За критику производительности Java и в целом по поводу Язык Java, видеть Критика Java.

В разработка программного обеспечения, язык программирования Ява исторически считался медленнее самого быстрого 3-е поколение напечатанный языки, такие как C и C ++.[1] Основная причина заключается в другом языковом дизайне, когда после компиляции Java-программы запускаются на Виртуальная машина Java (JVM), а не непосредственно на компьютере процессор в качестве собственный код, как и программы C и C ++. Производительность была поводом для беспокойства, потому что большая часть программного обеспечения для бизнеса была написана на Java после того, как язык быстро стал популярным в конце 1990-х - начале 2000-х годов.

С конца 1990-х годов скорость выполнения программ на Java значительно улучшилась за счет внедрения своевременная компиляция (JIT) (в 1997 г. для Java 1.1),[2][3][4] добавление языковых функций, поддерживающих лучший анализ кода, и оптимизацию в JVM (например, HotSpot становится по умолчанию для солнцеJVM в 2000 году). Аппаратное выполнение байт-кода Java, например, предлагаемого ARM Джазель, также было исследовано, чтобы предложить значительные улучшения производительности.

В спектакль из Байт-код Java скомпилированная программа Java зависит от того, насколько оптимально ее заданные задачи управляются хостом Виртуальная машина Java (JVM), и насколько хорошо JVM использует возможности компьютерное железо и Операционная система (OS) при этом. Таким образом, любой тест производительности или сравнение Java всегда должен указывать версию, поставщика, ОС и аппаратную архитектуру используемой JVM. Аналогичным образом производительность эквивалентной скомпилированной в собственном коде программы будет зависеть от качества ее сгенерированного машинного кода, поэтому при тестировании или сравнении также необходимо указать имя, версию и поставщика используемого компилятора, а также его активированный оптимизация компилятора директивы.

Методы оптимизации виртуальных машин

Многие оптимизации со временем улучшили производительность JVM. Однако, хотя Java часто была первой Виртуальная машина для их успешной реализации они часто использовались и на других подобных платформах.

Своевременная компиляция

Дальнейшая информация: Своевременная компиляция и HotSpot (виртуальная машина)

Ранние JVM всегда интерпретировались Байт-коды Java. Это привело к значительному снижению производительности - от 10 до 20 раз для Java по сравнению с C в обычных приложениях.[5] Для борьбы с этим в Java 1.1 был введен JIT-компилятор. Из-за высокой стоимости компиляции добавленная система под названием HotSpot был представлен в Java 1.2 и стал по умолчанию в Java 1.3. Используя эту структуру, Виртуальная машина Java постоянно анализирует производительность программы для горячие точки которые выполняются часто или неоднократно. Затем они предназначены для оптимизация, что приводит к высокопроизводительному выполнению с минимальными накладными расходами для менее критичного к производительности кода.[6][7]Некоторые тесты показывают 10-кратный прирост скорости благодаря этому.[8] Однако из-за нехватки времени компилятор не может полностью оптимизировать программу, и, таким образом, результирующая программа работает медленнее, чем альтернативы с собственным кодом.[9][10]

Адаптивная оптимизация

Дальнейшая информация: Адаптивная оптимизация

Адаптивная оптимизация - это метод в информатике, который динамическая перекомпиляция частей программы на основе текущего профиля выполнения. При простой реализации адаптивный оптимизатор может просто найти компромисс между своевременной компиляцией и интерпретацией инструкций. На другом уровне адаптивная оптимизация может использовать локальные условия данных для оптимизации удаленных ветвей и использования встроенного расширения.

А Виртуальная машина Java подобно HotSpot может также деоптимизировать код ранее JITed. Это позволяет выполнять агрессивные (и потенциально небезопасные) оптимизации, сохраняя при этом возможность позже деоптимизировать код и вернуться к безопасному пути.[11][12]

Вывоз мусора

Дальнейшая информация: Сборка мусора (информатика)

1.0 и 1.1 Виртуальные машины Java (JVM) использовали сборщик меток, что могло бы фрагментировать куча после сборки мусора. Начиная с Java 1.2, JVM изменились на коллекционер поколений, который имеет гораздо лучшее поведение при дефрагментации.[13]Современные JVM используют множество методов, которые были дополнительно улучшены вывоз мусора спектакль.[14]

Другие методы оптимизации

Сжатый ой

Сжатые Oops позволяют Java 5.0+ адресовать до 32 ГБ кучи с 32-разрядными ссылками. Java не поддерживает доступ к отдельным байтам, а только к объектам, которые по умолчанию выровнены по 8 байтов. Из-за этого младшие 3 бита ссылки кучи всегда будут равны 0. Путем снижения разрешения 32-битных ссылок до 8-байтовых блоков адресуемое пространство можно увеличить до 32 ГБ. Это значительно сокращает использование памяти по сравнению с использованием 64-битных ссылок, поскольку Java использует ссылки намного больше, чем некоторые языки, такие как C ++. Java 8 поддерживает более крупное выравнивание, такое как 16-байтовое выравнивание, для поддержки до 64 ГБ с 32-разрядными ссылками.[нужна цитата]

Проверка разделения байт-кода

Перед выполнением учебный класс, Sun JVM проверяет свое Байт-коды Java (видеть верификатор байт-кода). Эта проверка выполняется лениво: байт-коды классов загружаются и проверяются только тогда, когда конкретный класс загружен и подготовлен к использованию, а не в начале программы. (Другие верификаторы, такие как верификатор Java / 400 для IBM iSeries (System i) может выполнять большую часть проверки заранее и кэшировать информацию проверки от одного использования класса к другому.) Однако, поскольку Java библиотеки классов также являются обычными классами Java, они также должны загружаться при использовании, а это означает, что время запуска программы Java часто больше, чем для C ++ программы, например.

Метод с именем раздельная проверка, впервые представленный в Платформа Java, Micro Edition (J2ME), используется в JVM, поскольку Java версии 6. Он разделяет проверку Байт-код Java в два этапа:[15]

  • Время разработки - при компиляции класса из источника в байт-код
  • Время выполнения - при загрузке класса.

На практике этот метод работает, собирая информацию о потоке классов, имеющуюся у компилятора Java, и аннотируя байт-коды скомпилированного метода с синопсисом информации о потоке классов. Это не делает проверка во время выполнения заметно менее сложный, но позволяет несколько сокращений.[нужна цитата]

Анализ эвакуации и укрупнение замков

Дальнейшая информация: Lock (информатика) и Анализ побега

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

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

Поскольку библиотека Java не знает, какие методы будут использоваться более чем одним потоком, стандартная библиотека всегда блокирует блоки при необходимости в многопоточной среде.

До Java 6 виртуальная машина всегда заблокирован объекты и блоки по запросу программы, даже если не было риска изменения объекта сразу двумя разными потоками. Например, в этом случае местный вектор был заблокирован перед каждым из Добавить операции, чтобы гарантировать, что он не будет изменен другими потоками (вектор синхронизируется), но поскольку он строго локален для метода, в этом нет необходимости:

общественный Нить getNames() {     Вектор<Нить> v = новый Вектор<>();     v.Добавить("Мне");     v.Добавить("Ты");     v.Добавить("Ее");     возвращаться v.нанизывать();}

Начиная с Java 6, блоки кода и объекты блокируются только при необходимости,[16] поэтому в приведенном выше случае виртуальная машина вообще не блокирует объект Vector.

Начиная с версии 6u23, Java включает поддержку анализа выхода.[17]

Улучшения распределения регистров

Перед Java 6, размещение регистров был очень примитивным в клиент виртуальная машина (они не проживали блоки), что было проблемой в Проекты ЦП у которых было меньше регистры процессора доступно, как в x86s. Если для операции больше нет регистров, компилятор должен копировать из регистра в память (или память для регистрации), что требует времени (доступ к регистрам осуществляется значительно быстрее). Тем не менее сервер виртуальная машина использовала цветной график распределитель и не было этой проблемы.

Оптимизация распределения регистров была введена в Sun JDK 6;[18] тогда стало возможным использовать одни и те же регистры в блоках (когда это применимо), уменьшая доступ к памяти. Это привело к увеличению производительности примерно на 60% в некоторых тестах.[19]

Совместное использование данных класса

Совместное использование данных классов (называемое Sun CDS) - это механизм, который сокращает время запуска приложений Java, а также уменьшает объем памяти. Когда JRE установлен, установщик загружает набор классов из системы БАНКА файл (файл JAR, содержащий всю библиотеку классов Java, называемый rt.jar) в частное внутреннее представление и выгружает это представление в файл, называемый «общий архив». Во время последующих вызовов JVM этот общий архив с отображением памяти in, что позволяет сэкономить на загрузке этих классов и позволить большей части JVM метаданные чтобы эти классы были разделены между несколькими процессами JVM.[20]

Соответствующее сокращение времени запуска более очевидно для небольших программ.[21]

История улучшений производительности

Дальнейшая информация: История версий Java

Помимо перечисленных здесь улучшений, в каждом выпуске Java было много улучшений производительности в JVM и Java. интерфейс прикладного программирования (API).

JDK 1.1.6: Первый своевременная компиляция (SymantecJIT-компилятор)[2][22]

J2SE 1.2: Использование коллекционер поколений.

J2SE 1.3: Своевременная компиляция к HotSpot.

J2SE 1.4: см. здесь, для обзора Sun по улучшению производительности между версиями 1.3 и 1.4.

Java SE 5.0: Совместное использование данных класса[23]

Java SE 6:

Прочие улучшения:

  • Ява OpenGL Java 2D улучшения скорости конвейера[24]
  • Производительность Java 2D также значительно улучшилась в Java 6[25]

См. Также «Обзор Sun по улучшению производительности между Java 5 и Java 6».[26]

Java SE 6 (обновление 10)

  • Java Quick Starter сокращает время запуска приложения за счет предварительной загрузки части данных JRE при запуске ОС на дисковый кеш.[27]
  • Части платформы, необходимые для выполнения приложения, доступного из Интернета, когда JRE не установлена, теперь загружаются в первую очередь. Полный JRE составляет 12 МБ, типичному приложению Swing для запуска необходимо загрузить только 4 МБ. Остальные части затем загружаются в фоновом режиме.[28]
  • Графическая производительность на Windows улучшено за счет широкого использования Direct3D по умолчанию,[29] и использовать шейдеры на графический процессор (GPU) для ускорения сложных Java 2D операции.[30]

Java 7

Для Java 7 было выпущено несколько улучшений производительности: Будущие улучшения производительности запланированы для обновления Java 6 или Java 7:[31]

  • Обеспечить поддержку JVM для языки динамического программирования, после работ по прототипированию, которые в настоящее время проводятся на Машина да Винчи (Многоязычная виртуальная машина),[32]
  • Расширьте существующую библиотеку параллелизма, управляя параллельные вычисления на многоядерный процессоры,[33][34]
  • Разрешите JVM использовать как клиент и сервер JIT-компиляторы в том же сеансе с методом, называемым многоуровневой компиляцией:[35]
    • В клиент будет использоваться при запуске (потому что он хорош при запуске и для небольших приложений),
    • В сервер будет использоваться для долгосрочной работы приложения (поскольку оно превосходит клиент компилятор для этого).
  • Замените существующий параллельный сборщик мусора с малой паузой (также называемый сборщиком одновременной очистки меток (CMS)) новым сборщиком с именем Garbage First (G1), чтобы обеспечить согласованные паузы во времени.[36][37]

Сравнение с другими языками

Объективное сравнение производительности Java-программы и эквивалентной программы, написанной на другом языке, например C ++ требуется тщательно продуманный тест, который сравнивает программы, выполняющие идентичные задачи. Цель Платформа Java байт-код компилятор Платформа Java, а байт-код либо интерпретируется, либо компилируется в машинный код JVM. Другие компиляторы почти всегда нацелены на конкретную аппаратную и программную платформу, создавая машинный код, который практически не изменяется во время выполнения.[нужна цитата]. Из этих двух разных подходов возникают очень разные и трудно сравниваемые сценарии: статический или статический. динамические компиляции и перекомпиляции, наличие точной информации о среде выполнения и другие.

Java часто составлено точно в срок во время выполнения Java виртуальная машина, но также может быть составлен заранее, как и C ++. При своевременной компиляции микротест Игра "Тесты компьютерного языка" указать следующее о его характеристиках:[38]

  • медленнее, чем компилируемые языки, такие как C или же C ++,[39]
  • похож на другие языки, компилируемые точно в срок, такие как C #,[40]
  • намного быстрее, чем языки без эффективного компилятора машинного кода (JIT или же АОТ), Такие как Perl, Рубин, PHP и Python.[41]

Скорость программы

Бенчмарки часто измеряют производительность небольших программ с большим количеством вычислений. В некоторых редких реальных программах Java превосходит C. Одним из примеров является эталонный тест Джейк2 (клон Quake II написано на Java путем перевода оригинала GPL Код C). Версия Java 5.0 работает лучше в некоторых конфигурациях оборудования, чем ее аналог C.[42] Хотя не указано, как были измерены данные (например, если использовался исходный исполняемый файл Quake II, скомпилированный в 1997 году, что можно считать плохим, поскольку текущие компиляторы C могут обеспечить лучшую оптимизацию для Quake), в нем отмечается, что тот же исходный код Java может иметь огромное увеличение скорости, просто обновив виртуальную машину, чего невозможно достичь при 100% статическом подходе.

Для других программ аналог C ++ может и обычно работает значительно быстрее, чем эквивалент Java. Тест, проведенный Google в 2011 году, показал разницу в 10 раз между C ++ и Java.[43] С другой стороны, академический тест, проведенный в 2012 году с помощью алгоритма 3D-моделирования, показал, что Java 6 JVM в 1,09–1,91 раза медленнее, чем C ++ под Windows.[44]

Некоторые оптимизации, которые возможны в Java и подобных языках, могут быть невозможны при определенных обстоятельствах в C ++:[45]

  • C-стиль указатель использование может препятствовать оптимизации на языках, поддерживающих указатели,
  • Использование анализ побега методы ограничены C ++, например, потому что компилятор C ++ не всегда знает, объект будет изменен в данном блоке кода из-за указатели,[примечание 1]
  • Java может получить доступ к производным методам экземпляра быстрее, чем C ++ может получить доступ к производным виртуальным методам из-за дополнительного поиска в виртуальных таблицах C ++. Однако невиртуальные методы в C ++ не страдают от узких мест производительности v-table и, таким образом, демонстрируют производительность, аналогичную Java.

JVM также может выполнять оптимизацию для конкретного процессора или встроенное расширение. Кроме того, возможность деоптимизировать уже скомпилированный или встроенный код иногда позволяет ему выполнять более агрессивную оптимизацию, чем те, которые выполняются статически типизированными языками, когда задействованы функции внешней библиотеки.[46][47]

Результаты для микротест между Java и C ++ сильно зависит от того, какие операции сравниваются. Например, при сравнении с Java 5.0:

Примечания
  1. ^ Разногласия такого рода в программах на C ++ на уровне исходного кода могут быть уменьшены путем использования расширенных методов, таких как настраиваемые распределители, используя именно ту низкоуровневую сложность кодирования, которую Java была разработана для сокрытия и инкапсуляции; однако этот подход редко бывает практичным, если не принят (или, по крайней мере, ожидается), пока программа находится в стадии первичной разработки.

Многоядерная производительность

Масштабируемость и производительность приложений Java в многоядерных системах ограничиваются скоростью выделения объектов. Этот эффект иногда называют «стеной распределения».[54] Однако на практике современные алгоритмы сборщика мусора используют несколько ядер для выполнения сборки мусора, что в некоторой степени решает эту проблему. Сообщается, что некоторые сборщики мусора поддерживают скорость выделения более гигабайта в секунду,[55] и существуют системы на основе Java, которые без проблем масштабируются до нескольких сотен ядер ЦП и кучи размером в несколько сотен ГБ.[56]

Автоматическое управление памятью в Java позволяет эффективно использовать безблокирующие и неизменяемые структуры данных, которые чрезвычайно сложно, а иногда и невозможно реализовать без какой-либо сборки мусора.[нужна цитата] Java предлагает ряд таких высокоуровневых структур в своей стандартной библиотеке в пакете java.util.concurrent, в то время как многие языки, исторически использовавшиеся для высокопроизводительных систем, таких как C или C ++, все еще не имеют их.[нужна цитата]

Время запуска

Время запуска Java часто намного медленнее, чем у многих языков, включая C, C ++, Perl или же Python, потому что многие классы (и в первую очередь классы из библиотеки классов платформы) перед использованием необходимо загрузить.

По сравнению с аналогичными популярными средами выполнения для небольших программ, работающих на компьютере с Windows, время запуска похоже на Моно и немного медленнее, чем .NET.[57]

Кажется, что большая часть времени запуска связана с операциями ввода-вывода (IO), а не с инициализацией JVM или загрузкой класса ( rt.jar размер одного файла данных класса составляет 40 МБ, и JVM должна искать много данных в этом большом файле).[27] Некоторые тесты показали, что хотя новый проверка разделения байт-кода Метод улучшил загрузку классов примерно на 40%, он реализовал улучшение запуска только для больших программ примерно на 5%.[58]

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

Начиная с Java SE 6 Update 10, Sun JRE поставляется с программой Quick Starter, которая предварительно загружает данные класса при запуске ОС для получения данных из дисковый кеш а не с диска.

Excelsior JET подходит к проблеме с другой стороны. Оптимизатор запуска сокращает объем данных, которые необходимо прочитать с диска при запуске приложения, и делает чтение более последовательным.

В ноябре 2004 г. Строительный пистолетбыл публично выпущен «клиент, протокол и сервер для запуска программ Java из командной строки без дополнительных затрат на запуск JVM».[59] представляя впервые возможность скрипты использовать JVM как демондля запуска одного или нескольких приложений Java без дополнительных затрат на запуск JVM. Демон Nailgun небезопасен: «все программы запускаются с теми же разрешениями, что и сервер». Где многопользовательский безопасность необходима, гвоздь не годится без особых мер предосторожности. Сценарии, в которых запуск JVM для каждого приложения доминирует над использованием ресурсов, см. Один-два порядок величины улучшения производительности во время выполнения.[60]

Использование памяти

Использование памяти Java намного выше, чем использование памяти C ++, потому что:

  • Накладные расходы составляют 8 байтов для каждого объекта и 12 байтов для каждого массива.[61] в Java. Если размер объекта не кратен 8 байтам, он округляется до следующего кратного 8. Это означает, что объект, содержащий одно байтовое поле, занимает 16 байтов и нуждается в 4-байтовой ссылке. C ++ также выделяет указатель (обычно 4 или 8 байтов) для каждого объекта, который класс прямо или косвенно объявляет виртуальные функции.[62]
  • Отсутствие адресной арифметики делает создание контейнеров с эффективным использованием памяти, таких как плотно разнесенные структуры и Связанные списки XOR, в настоящее время невозможно (проект OpenJDK Valhalla направлен на смягчение этих проблем, хотя и не нацелен на введение арифметики указателей; это невозможно сделать в среде со сборкой мусора).
  • В отличие от malloc и new, средние накладные расходы на сборку мусора асимптотически близки к нулю (точнее, к одному циклу ЦП) по мере увеличения размера кучи.[63]
  • Части Библиотека классов Java должны загружаться перед выполнением программы (по крайней мере, классы, используемые в программе).[64] Это приводит к значительным накладным расходам памяти для небольших приложений.[нужна цитата]
  • Как двоичный код Java, так и собственная перекомпиляция обычно находятся в памяти.
  • Виртуальная машина использует значительный объем памяти.
  • В Java составной объект (класс A, который использует экземпляры B и C) создается с использованием ссылок на выделенные экземпляры B и C. В C ++ затрат памяти и производительности этих типов ссылок можно избежать, если экземпляр B и / или C существует внутри A.

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

Тригонометрические функции

Производительность тригонометрических функций плохая по сравнению с C, потому что Java имеет строгие спецификации для результатов математических операций, которые могут не соответствовать базовой аппаратной реализации.[65] На x87 подмножество с плавающей запятой, Java, начиная с версии 1.4, уменьшает аргументы для sin и cos в программном обеспечении,[66] что приводит к значительному снижению производительности для значений за пределами диапазона.[67][требуется разъяснение]JDK (11 и выше) имеет значительный прогресс в скорости вычисления тригонометрических функций по сравнению с JDK 8.[68]

Собственный интерфейс Java

В Собственный интерфейс Java вызывает большие накладные расходы, из-за чего пересечение границы между кодом, работающим на JVM, и собственным кодом обходится дорого.[69][70] Собственный доступ Java (JNA) предоставляет Ява программ легкий доступ к родным общие библиотеки (библиотека с динамической компоновкой (DLL) в Windows) только через код Java, без JNI или собственного кода. Эта функциональность сопоставима с Windows Platform / Invoke и Python ctypes. Доступ является динамическим во время выполнения без создания кода. Но у этого есть затраты, и JNA обычно медленнее, чем JNI.[71]

Пользовательский интерфейс

Качать воспринимается как более медленный, чем родной наборы инструментов для виджетов, потому что он делегирует рендеринг виджетов чистым Java 2D API. Однако тесты, сравнивающие производительность Swing и Стандартный набор инструментов виджетов, который делегирует рендеринг встроенным библиотекам графического интерфейса операционной системы, не показывает явного победителя, а результаты сильно зависят от контекста и среды.[72] Кроме того, более новый JavaFX framework, предназначенный для замены Swing, решает многие проблемы, присущие Swing.

Используйте для высокопроизводительных вычислений

Некоторые считают, что производительность Java для высокопроизводительные вычисления (HPC) похож на Фортран на тестах, требующих интенсивных вычислений, но у JVM все еще есть проблемы с масштабируемостью для выполнения интенсивного обмена данными на сеточные вычисления сеть.[73]

Однако приложения для высокопроизводительных вычислений, написанные на Java, выиграли соревнования по тестированию производительности. В 2008,[74] и 2009 г.,[75][76] апач Hadoop (проект высокопроизводительных вычислений с открытым исходным кодом, написанный на Java) на основе кластера был способен отсортировать терабайт и петабайт целых чисел быстрее всего. Однако аппаратная настройка конкурирующих систем не была исправлена.[77][78]

В соревнованиях по программированию

Программы на Java запускаются медленнее, чем на других компилируемых языках.[79][80] Таким образом, некоторые онлайн-системы судейства, особенно те, что размещены в китайских университетах, используют более длительные сроки для программ Java.[81][82][83][84][85] чтобы быть справедливым по отношению к участникам, использующим Java.

Смотрите также

Рекомендации

  1. ^ http://www.scribblethink.org/Computer/javaCbenchmark.html
  2. ^ а б "Своевременный Java-компилятор Symantec будет интегрирован в Sun JDK 1.1".
  3. ^ «Краткий обзор: Apple лицензирует своевременный компилятор Symantec». cnet.com. 12 мая 1998 г.. Получено 15 ноября, 2015.
  4. ^ «Java становится в четыре раза быстрее с новым оперативным компилятором Symantec».
  5. ^ http://www.shudo.net/jit/perf/
  6. ^ Кавагути, Косуке (30 марта 2008 г.). «Глубокое погружение в ассемблерный код с Java». Архивировано из оригинал 2 апреля 2008 г.. Получено 2 апреля, 2008.
  7. ^ «Быстрая и эффективная генерация кода в своевременном компиляторе Java» (PDF). Корпорация Intel. Получено 22 июня, 2007.
  8. ^ Этот статья показывает, что прирост производительности между интерпретируемым режимом и точкой доступа составляет более 10 раз.
  9. ^ Числовая производительность в C, C # и Java
  10. ^ Сравнение алгоритмической производительности языков программирования C, C ++, Java и C # В архиве 31 марта 2010 г. Wayback Machine
  11. ^ "Виртуальная машина Java HotSpot, v1.4.1". Sun Microsystems. Получено 20 апреля, 2008.
  12. ^ Наттер, Чарльз (28 января 2008 г.). «Lang.NET 2008: мысли первого дня». Получено 18 января, 2011. Деоптимизация очень интересна при решении проблем с производительностью, поскольку она означает, что вы можете проводить гораздо более агрессивные оптимизации ... зная, что вы сможете вернуться к испытанному и действительно безопасному пути позже.
  13. ^ Библиотека IBM DeveloperWorks
  14. ^ Например, теперь менее заметна продолжительность пауз. См., Например, этот клон Quake II написано на Java: Джейк2.
  15. ^ «Новая функция Java SE 6: средство проверки типов». Java.net. Получено 18 января, 2011.[постоянная мертвая ссылка]
  16. ^ Брайан Гетц (18 октября 2005 г.). «Теория и практика Java: оптимизация синхронизации в Mustang». IBM. Получено 26 января, 2013.
  17. ^ «Повышение производительности виртуальной машины Java HotSpot». Корпорация Oracle. Получено 14 января, 2014. Анализ выхода из режима - это метод, с помощью которого компилятор Java Hotspot Server может анализировать объем использования нового объекта и решить, следует ли разместить его в куче Java. Анализ побега поддерживается и включен по умолчанию в Java SE 6u23 и новее.
  18. ^ Отчет об ошибке: новый распределитель регистров, исправленный в Mustang (JDK 6) b59
  19. ^ Клиент HotSpot от Mustang стал на 58% быстрее! В архиве 5 марта 2012 г. Wayback Machine в блоге Освальдо Пинали Дёдерляйна на java.net
  20. ^ Совместное использование данных класса на java.sun.com
  21. ^ Совместное использование данных классов в JDK 1.5.0 на форуме Java Buzz по адресу разработчик artima
  22. ^ Маккей, Ниали. «Java становится в четыре раза быстрее с новым оперативным компилятором Symantec».
  23. ^ Обзор Sun по улучшению производительности между версиями 1.4 и 5.0.
  24. ^ STR-Crazier: улучшения производительности в Mustang В архиве 5 января 2007 г. Wayback Machine в блоге Криса Кэмпбелла на java.net
  25. ^ Видеть здесь для теста, показывающего прирост производительности примерно на 60% с Java 5.0 до 6 для приложения JFreeChart
  26. ^ Технический документ о производительности Java SE 6 в http://java.sun.com
  27. ^ а б Хаасе, Чет (май 2007 г.). "Consumer JRE: более экономичная, более серьезная технология Java". Sun Microsystems. Получено 27 июля, 2007. На уровне ОС все эти мегабайты должны быть прочитаны с диска, что является очень медленной операцией. На самом деле убийца - время поиска диска; последовательное чтение больших файлов относительно быстро, но поиск битов, которые нам действительно нужны, - нет. Таким образом, даже несмотря на то, что нам нужна только небольшая часть данных в этих больших файлах для любого конкретного приложения, тот факт, что мы ищем все в файлах, означает, что на диске много активности.
  28. ^ Хаасе, Чет (май 2007 г.). "Consumer JRE: более экономичная, более серьезная технология Java". Sun Microsystems. Получено 27 июля, 2007.
  29. ^ Хаасе, Чет (май 2007 г.). "Consumer JRE: более экономичная, более средняя Java-технология". Sun Microsystems. Получено 27 июля, 2007.
  30. ^ Кэмпбелл, Крис (7 апреля 2007 г.). «Более быстрая Java 2D с помощью шейдеров». Архивировано из оригинал 5 июня 2011 г.. Получено 18 января, 2011.
  31. ^ Хаасе, Чет (май 2007 г.). "Consumer JRE: более экономичная, более средняя Java-технология". Sun Microsystems. Получено 27 июля, 2007.
  32. ^ «JSR 292: Поддержка динамически типизированных языков на платформе Java». jcp.org. Получено 28 мая, 2008.
  33. ^ Гетц, Брайан (4 марта 2008 г.). «Теория и практика Java: воткните в нее вилку, часть 2». Получено 9 марта, 2008.
  34. ^ Лоример, Р.Дж. (21 марта 2008 г.). «Параллелизм с вилкой / объединением в Java 7». infoq.com. Получено 28 мая, 2008.
  35. ^ «Новые оптимизации компилятора в виртуальной машине Java HotSpot» (PDF). Sun Microsystems. Май 2006 г.. Получено 30 мая, 2008.
  36. ^ Скромный, Чарльз (13 мая 2008 г.). "JavaOne: сначала мусор". infoq.com. Получено 7 сентября, 2008.
  37. ^ Трус, Дэнни (12 ноября 2008 г.). «Java VM: пробуем новый сборщик мусора для JDK 7». Архивировано из оригинал 8 декабря 2011 г.. Получено 15 ноября, 2008.
  38. ^ "Тесты компьютерного языка". benchmarksgame.alioth.debian.org. Архивировано из оригинал 25 января 2015 г.. Получено 2 июня, 2011.
  39. ^ "Тесты компьютерного языка". benchmarksgame.alioth.debian.org. Архивировано из оригинал 13 января 2015 г.. Получено 2 июня, 2011.
  40. ^ "Тесты компьютерного языка". benchmarksgame.alioth.debian.org. Архивировано из оригинал 10 января 2015 г.. Получено 2 июня, 2011.
  41. ^ "Тесты компьютерного языка". benchmarksgame.alioth.debian.org. Архивировано из оригинал 2 января 2015 г.. Получено 2 июня, 2011.
  42. ^ : 260/250 кадр / с против 245 кадров / с (см. ориентир)
  43. ^ Хундт, Роберт. «Распознавание петель в C ++ / Java / Go / Scala» (PDF). Дни Scala 2011. Стэнфорд, Калифорния: Google. Получено 23 марта, 2014.
  44. ^ Л. Герарди; Д. Бругали; Д. Комотти (2012). «Оценка производительности Java и C ++: тест 3D-моделирования» (PDF). Университет Бергамо. Получено 23 марта, 2014. Использование серверного компилятора, который лучше всего настроен для длительно работающих приложений, вместо этого продемонстрировало, что Java от 1,09 до 1,91 раза медленнее (...) В заключение, результаты, полученные с помощью серверного компилятора, и эти важные функции предполагают, что Java может считаться действительной альтернативой C ++
  45. ^ Lewis, J.P .; Нойман, Ульрих. «Производительность Java по сравнению с C ++». Лаборатория компьютерной графики и иммерсивных технологий, Университет Южной Калифорнии.
  46. ^ «Механизм производительности Java HotSpot: пример встраивания методов». Корпорация Oracle. Получено 11 июня, 2011.
  47. ^ Наттер, Чарльз (3 мая 2008 г.). «Сила JVM». Получено 11 июня, 2011. Что произойдет, если вы уже встроили метод A, когда появится B? Здесь снова сияет JVM. Поскольку JVM по сути является динамической языковой средой исполнения, она остается бдительной, наблюдая за тем, чтобы происходили именно такие события. И вот что действительно здорово: когда ситуация меняется, JVM может деоптимизироваться. Это очень важная деталь. Многие другие среды выполнения могут выполнить оптимизацию только один раз. Компиляторы C должны делать все это заранее, во время сборки. Некоторые позволяют профилировать приложение и использовать его в последующих сборках, но как только вы выпустите фрагмент кода, он будет оптимизирован настолько, насколько это вообще возможно. В других виртуальных системах, таких как CLR, есть фаза JIT, но она происходит на ранней стадии выполнения (возможно, даже до того, как система начнет выполнение) и больше никогда не повторяется. Способность JVM деоптимизировать и возвращаться к интерпретации дает ей возможность быть оптимистичной ... возможность делать амбициозные предположения и изящно возвращаться в безопасное состояние, чтобы повторить попытку позже.
  48. ^ «Микробенчмаркинг C ++, C # и Java: 32-битная целочисленная арифметика». Журнал доктора Добба. 1 июля 2005 г.. Получено 18 января, 2011.
  49. ^ «Микробенчмаркинг C ++, C # и Java: 64-битная двойная арифметика». Журнал доктора Добба. 1 июля 2005 г.. Получено 18 января, 2011.
  50. ^ «Микробенчмаркинг C ++, C # и Java: файловый ввод-вывод». Журнал доктора Добба. 1 июля 2005 г.. Получено 18 января, 2011.
  51. ^ «Микробенчмаркинг C ++, C # и Java: исключение». Журнал доктора Добба. 1 июля 2005 г.. Получено 18 января, 2011.
  52. ^ «Микробенчмаркинг C ++, C # и Java: массив». Журнал доктора Добба. 1 июля 2005 г.. Получено 18 января, 2011.
  53. ^ «Микробенчмаркинг C ++, C # и Java: тригонометрические функции». Журнал доктора Добба. 1 июля 2005 г.. Получено 18 января, 2011.
  54. ^ И Чжао, Цзинь Ши, Кай Чжэн, Хайчуань Ван, Хайбо Линь и Лин Шао, Стена распределения: ограничивающий фактор приложений Java на новых многоядерных платформах, Материалы 24-й конференции ACM SIGPLAN по объектно-ориентированным языкам и приложениям систем программирования, 2009.
  55. ^ C4: Непрерывно параллельный коллектор уплотнения
  56. ^ Azul запугивает Java с помощью 768-ядерной машины
  57. ^ «Тестирование запуска и производительности системы для .Net, Mono, Java, C ++ и их соответствующих пользовательских интерфейсов». 2 сентября 2010 г.
  58. ^ "Как быстро работает новый верификатор?". 7 февраля 2006 г. Архивировано с оригинал 16 мая 2006 г.. Получено 9 мая 2007.
  59. ^ Строительный пистолет
  60. ^ Гвоздь Фон страница демонстрирует "лучший сценарий"ускорение в 33 раза (для скриптовых "Привет, мир!" программы т.е. краткосрочные программы).
  61. ^ http://www.javamex.com/tutorials/memory/object_memory_usage.shtml
  62. ^ «Архивная копия». Архивировано из оригинал 21 февраля 2008 г.. Получено 22 июн 2009.CS1 maint: заархивированная копия как заголовок (связь)
  63. ^ https://www.youtube.com/watch?v=M91w0SBZ-wc : Понимание Java Garbage Collection - выступление Гила Тене на JavaOne
  64. ^ http://www.tommti-systems.de/go.html?http://www.tommti-systems.de/main-Dateien/reviews/languages/benchmarks.html
  65. ^ «Математика (Java Platform SE 6)». Sun Microsystems. Получено 8 июня, 2008.
  66. ^ Гослинг, Джеймс (27 июля 2005 г.). "Трансцендентальная медитация". Архивировано из оригинал 12 августа 2011 г.. Получено 8 июня, 2008.
  67. ^ У. Коуэлл-Шах, Кристофер (8 января 2004 г.). «Обзор производительности девяти языков: сравнительный анализ математических операций и файлового ввода-вывода». Архивировано из оригинал 11 октября 2018 г.. Получено 8 июня, 2008.
  68. ^ Чеканов С.В., Гавалиан Г., Граф Н.А., Jas4pp - Среда анализа данных для исследований физики и детекторов, (2020), (https://arxiv.org/abs/2011.05329) (2020) ANL-HEP-164101, SLAC-PUB-17569
  69. ^ Уилсон, Стив; Джефф Кессельман (2001). «Производительность платформы JavaTM: использование собственного кода». Sun Microsystems. Получено 15 февраля, 2008.
  70. ^ Курзинец, Давид; Вайди Сундерам. «Эффективное взаимодействие между Java и собственным кодом - тест производительности JNI» (PDF). Архивировано из оригинал (PDF) 14 февраля 2005 г.. Получено 15 февраля 2008.
  71. ^ «Как производительность JNA сравнивается с пользовательским JNI?». Sun Microsystems. Получено 26 декабря, 2009.[постоянная мертвая ссылка]
  72. ^ Игорь, Крижнар (10 мая 2005 г.). «Сравнение характеристик SWT и Swing» (PDF). cosylab.com. Архивировано из оригинал (PDF) 4 июля 2008 г.. Получено 24 мая 2008. Трудно дать эмпирическое правило, в котором SWT превзойдет Swing или наоборот. В некоторых средах (например, Windows) SWT является победителем. В других (Linux, VMware хостинг Windows), Swing и его оптимизация перерисовки значительно превосходят SWT. Различия в производительности значительны: обычно бывает 2 и более в любом направлении.
  73. ^ Брайан Амедро; Владимир Боднарчук; Денис Каромель; Кристиан Дельбе; Фабрис Юэ; Гильермо Л. Табоада (август 2008 г.). «Текущее состояние Java для HPC». INRIA. Получено 9 сентября, 2008. Сначала мы проводим несколько микротестов для различных JVM, демонстрируя в целом хорошую производительность для основных арифметических операций (...). Сравнивая эту реализацию с реализацией Fortran / MPI, мы показываем, что они имеют одинаковую производительность в тестах с интенсивными вычислениями, но все же имеют проблемы с масштабируемостью при выполнении интенсивных коммуникаций.
  74. ^ Оуэн О'Мэлли - Yahoo! Grid Computing Team (июль 2008 г.). «Apache Hadoop побеждает в тесте терабайтной сортировки». Архивировано из оригинал 15 октября 2009 г.. Получено 21 декабря 2008. Это первый случай, когда победила Java или программа с открытым исходным кодом.
  75. ^ «Hadoop сортирует петабайт за 16,25 часа и терабайт за 62 секунды». CNET.com. 11 мая 2009 года. Архивировано с оригинал 16 мая 2009 г.. Получено 8 сентября, 2010. Детали оборудования и операционной системы: (...) Sun Java JDK (1.6.0_05-b13 и 1.6.0_13-b03) (32 и 64 бит)
  76. ^ «Hadoop бьет мировые рекорды сортировки данных». CNET.com. 15 мая 2009 г.. Получено 8 сентября, 2010.
  77. ^ Крис Ниберг; Мехул Шах. "Сортировка домашней страницы контрольных показателей". Получено 30 ноября, 2010.
  78. ^ Чайковский, Гжегож (21 ноября 2008 г.). «Сортировка 1ПБ с помощью MapReduce». Google. Получено 1 декабря, 2010.
  79. ^ «Архивная копия». Архивировано из оригинал 18 октября 2010 г.. Получено 21 июн 2010.CS1 maint: заархивированная копия как заголовок (связь)
  80. ^ http://acm.timus.ru/help.aspx?topic=java&locale=en
  81. ^ http://acm.pku.edu.cn/JudgeOnline/faq.htm#q11
  82. ^ «Архивная копия». Архивировано из оригинал 29 июня 2010 г.. Получено 25 мая, 2010.CS1 maint: заархивированная копия как заголовок (связь)
  83. ^ http://www.codechef.com/wiki/faq#How_does_the_time_limit_work
  84. ^ «Архивная копия». Архивировано из оригинал 19 февраля 2012 г.. Получено 13 ноября 2011.CS1 maint: заархивированная копия как заголовок (связь)
  85. ^ http://poj.org/faq.htm#q9

внешняя ссылка