JVM на многоядерных - PullRequest
       6

JVM на многоядерных

8 голосов
/ 13 июля 2010

Я недавно прочитал пост в блоге, утверждая, что Java-приложение работает лучше, когда ему разрешено использовать один процессор на многоядерном компьютере: http://mailinator.blogspot.com/2010/02/how-i-sped-up-my-server-by-factor-of-6.html

Какие могут быть причины для Java-приложения, работающего на многоядерных машинах, работать намного медленнее, чем на одноядерном компьютере?

Ответы [ 10 ]

8 голосов
/ 13 июля 2010

Если между общими ресурсами в разных потоках существует значительная конкуренция, возможно, что для блокировки и разблокировки объектов требуется большое количество IPI (межпроцессорные прерывания), и процессоры могут тратить больше времени на отбрасывание их кэши L1 и L2 и повторная выборка данных с других процессоров, чем они фактически тратят на достижение прогресса в решении стоящей проблемы.

Это может быть проблемой, если приложение имеет слишком тонкую блокировку . (Однажды я услышал, что это подытожило: «Нет смысла иметь более одной блокировки на строку кэша ЦП», что определенно верно, и, возможно, все еще слишком мелко.)

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

Я не сомневаюсь, что кто-то мог специально написать такое приложение, но оно, вероятно, не очень распространено. Большинство разработчиков пишут свои приложения, чтобы уменьшить конкуренцию за ресурсы, где они могут.

1 голос
/ 15 октября 2010

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

Вот очень краткое объяснение барьеров памяти, оно также предоставляет аккуратную технику просмотра кода JIT: http://www.infoq.com/articles/memory_barriers_jvm_concurrency

Это не значит, что все приложения выиграют от размещения на одном ядре.

1 голос
/ 13 июля 2010

С точки зрения производительности, проблема часто заключается в подсистеме памяти.Таким образом, несмотря на то, что большее количество процессоров часто хорошо, иметь процессоры, которые не располагаются рядом с памятью, в которой находятся объекты Java, очень и очень дорого.Это ОЧЕНЬ специфично для машины и сильно зависит от точного пути между каждым ЦП и памятью.И у Intel, и у AMD здесь были разные формы / скорости, и результаты сильно различаются.

См. NUMA о причинах, которые могут мешать многоядерным процессорам.

Мы виделиперепады производительности в диапазоне 30% и более в зависимости от того, как виртуальные машины Java прикреплены к процессорам.По этой причине SPECjbb2005 теперь в основном работает в режиме «multi-JVM», где каждая JVM связана с данным ЦП / памятью.

1 голос
/ 13 июля 2010

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

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

1 голос
/ 13 июля 2010

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

Это актуально только в том случае, если программа не использует несколько потоков и, таким образом, может эффективно распределять свою работу между несколькими ядрами / процессорами.

1 голос
/ 13 июля 2010

Это полностью спекуляция без рассматриваемой статьи / данных, но есть некоторые типы программ, которые плохо подходят для распараллеливания - возможно, приложение никогда не привязано к ЦП (то есть ЦП не является узким местом, возможно, в некотором роде). I / O есть).

Однако этот вопрос / разговор довольно беспочвенны без подробностей.

1 голос
/ 13 июля 2010

Я сомневаюсь в "Многое".

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

0 голосов
/ 14 июля 2010

CPU часто имеют ограничение на количество тепла, которое они могут производить.Это означает, что чип с меньшим количеством ядер может работать с высокой частотой, что может привести к ускорению работы программы, если она не использует дополнительное ядро ​​эффективно.Сегодня разница между 4, 6 и 8 ядрами, где больше ядер по отдельности медленнее.Я не знаю ни одной одноядерной системы, которая бы работала быстрее, чем самая быстрая 4-ядерная система.

0 голосов
/ 13 июля 2010

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

0 голосов
/ 13 июля 2010

Последние процессоры Intel имеют Turbo Boost:

http://en.wikipedia.org/wiki/Intel_Turbo_Boost

...