jvm на многоядерном
Я считал сообщение в блоге только что, утверждая, что JAVA-приложение работало лучше, когда было позволено использовать единственный CPU в многоядерной машине: http://mailinator.blogspot.com/2010/02/how-i-sped-up-my-server-by-factor-of-6.html
Чем причины могли там быть для JAVA-приложения, работая на многоядерных машинах для выполнения намного медленнее, чем на одноядерной машине?
9 ответов
Если существует значительная конкуренция между общими ресурсами в разных потоках, возможно, что для блокировки и разблокировки объектов требуется большое количество IPI (межпроцессорные прерывания) и процессоры могут тратить больше времени на сброс своих кэшей L1 и L2 и повторную выборку данных с других процессоров, чем они фактически тратят на решение проблемы.
Это может быть проблемой, если приложение имеет способ слишком тонкой блокировки . (Однажды я слышал, как он резюмировал «нет смысла иметь более одной блокировки на строку кэша ЦП», что определенно верно и, возможно, все еще слишком детально.)
Java «каждый объект является мьютексом» может привести к к наличию слишком большого количества блокировок в работающей системе, если слишком много живых и спорных.
Я не сомневаюсь, что кто-то мог намеренно написать такое приложение, но, вероятно, это не очень распространено. Большинство разработчиков писали бы свои приложения, чтобы уменьшить конкуренцию за ресурсы там, где это возможно.
Для этого нет причин, специфичных для Java, но перемещение состояния от ядра к ядру или даже от CPU к CPU занимает время. Это время может быть использовано лучше, если процесс остается на одном ядре. Кроме того, в таких случаях можно улучшить кэширование.
Однако это актуально только в том случае, если программа не использует несколько потоков и может эффективно распределять свою работу по нескольким ядрам/ЦП.
Это полностью спекуляция без рассматриваемой статьи / данных, но есть некоторые типы программ которые плохо подходят для распараллеливания - возможно, приложение никогда не привязано к ЦП (это означает, что ЦП не является узким местом, возможно, это какой-то ввод-вывод).
Однако этот вопрос / разговор без дополнительных подробностей безосновательны.
Я сомневаюсь в "многом".
Я предполагаю, что затраты на перенос состояния с одного процессора на другой достаточно высоки, чтобы быть заметными. Обычно вы хотите, чтобы задания оставались на одном процессоре, чтобы его данные кэшировались как можно больше локально.
С точки зрения чистой производительности, проблема часто связана с подсистемой памяти. Поэтому, хотя больше процессоров часто хорошо, наличие процессоров, которые не находятся рядом с памятью, в которой сидят объекты Java, очень, очень дорого. Это ОЧЕНЬ специфично для конкретной машины и сильно зависит от точного пути между каждым процессором и памятью. И Intel, и AMD использовали здесь различные формы/скорости, и результаты сильно различаются.
См. раздел NUMA о причинах, по которым многоядерность может мешать.
Мы видели разницу в производительности в диапазоне 30% и более в зависимости от того, как JVM прикреплены к процессорам. SPECjbb2005 теперь в основном выполняется в режиме "multi-JVM" с каждой JVM, связанной с определенным CPU / памятью, по этой причине.
Приложение может очень плохо использовать блокировку межпоточной коммуникации. Однако это может быть связано только с тем, что приложение запрограммировано исключительно плохо.
Нет никаких причин, почему любое даже посредственно запрограммированное многоядерное приложение с умеренно распараллеливаемой рабочей нагрузкой должно работать медленнее на нескольких ядрах.
CPU часто имеют ограничение на количество тепла, которое они могут выделять. Это означает, что микросхема с меньшим количеством ядер может работать с высокой частотой, что может привести к тому, что программа будет работать быстрее, если она не будет эффективно использовать дополнительное ядро. Сегодня разница между 4, 6 и 8 ядрами, где больше ядер по отдельности медленнее. Я не знаю ни одной одноядерной системы, которая была бы быстрее самой быстрой четырехъядерной системы.
Это будет зависеть от количества потоков, порождаемых приложением. Если вы создадите, скажем, четыре рабочих потока, выполняющих тяжелую обработку чисел, приложение будет почти в четыре раза быстрее на четырехъядерном компьютере, в зависимости от того, сколько бухгалтерского учета и слияния вы должны выполнить.