32 OR 64 BIT для JVM?

Ответ 1

Это скорее общая производительность. Если у вас есть недавний 64-битный процессор и много неиспользуемой памяти, единственное возможное усиление с использованием JVM 32 вместо JVM 64 будет заключаться в том, что некоторые петли могут полностью входить в кеш с 32-разрядными адресами, а не с 64-битными, что приводит к меньшей основной памяти доступ с 32-разрядной JVM. Я действительно не могу оценить прирост, но, за исключением особых случаев, я сомневаюсь, что он достигает 5-20% - заметьте, я только сомневаюсь, не уверен...

Но если вы используете ограниченную ресурсами систему, в конечном счете, потому что вы хотите оптимизировать свое оборудование и запустить на нем множество виртуальных машин, 32-битная JVM будет использовать гораздо меньше памяти, чем 64-битную. Он оставит больше свободной памяти другим приложениям и системе, избегая при этом обмена и позволяя системе лучше кэшировать диск IO.

ИМХО, нет общего правила. Я бы просто использовал следующее правило: если при запуске JVM и всех других приложений система все еще имеет достаточно памяти для кэширования ввода-вывода, я бы использовал 64-битную JVM и 32-битную единицу в противном случае.

Конечно, выше только имеет смысл, если приложение Java само по себе не нуждается в большой памяти, навязывая использование 64-битной JVM, и, в случае необходимости, добавляет больше памяти в систему, потому что память не так дорого сегодня

Ответ 2

Я скептически отношусь к утверждению автора о том, что использование 32-разрядной версии JVM даст улучшение производительности на 5-20%. Тем не менее, я не использую Java много, поэтому я не знаю точно. Но чтобы исследовать эти утверждения, я рассмотрел некоторые результаты SPEC.

Я искал результаты SPECjEnterprise2010, и самый высокий балл для архитектуры x86-64 был системой Oracle, которая использовала 64-разрядную версию JVM.

Я также посмотрел на SPECjvm2008, если эти меньшие рабочие нагрузки могут выиграть от 32-битной архитектуры. Но снова самая эффективная система x86-64, на этот раз с Huawei использовала 64-битную версию JVM.

Если бы 32-разрядная версия JVM была действительно лучше, я бы ожидал, что люди, представившие свои результаты SPEC, выбрали бы это при настройке своих рабочих нагрузок (но я мог ошибаться).

Я не сомневаюсь, что есть некоторые рабочие нагрузки, когда 32-разрядная версия JVM будет превосходить 64-битную версию. Как отмечали другие, он использует больше памяти для адресов. Однако архитектура x86-64 имеет больше доступных регистров, и я подозреваю, что в 64-битном режиме работы основное внимание уделяется оптимизации.

Производительность системы имеет много компонентов, и я не думаю, что 32-разрядная версия JVM обязательно превзойдет 64-битную версию (для этого это будет иметь значение только для загружаемых по ЦП рабочих нагрузок). Я бы сказал, что если вы дойдете до этого момента в процессе настройки производительности, чтобы проверить свою собственную рабочую нагрузку для двух разных параметров и использовать результаты своих собственных тестов для принятия решения, а не предполагать, что использование 32 -бит лучше, чем 64-разрядный из-за экономии пространства памяти для адресов, как правило, потому что есть другие факторы, которые могут быть более важными, чем это.

Ответ 3

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

Если вы когда-либо задавали этот вопрос, другими словами, имели свой выбор, это означает, что вы уже работаете в 64-битной системе с 32-битным режимом (с приемлемой производительностью, то есть без эмуляции программного обеспечения), которая, скорее всего, AMD64 aka x86-64.

В таких системах Oracles JVM поддерживает "сжатые oops", что означает использование 32-разрядных ссылок в куче Java, если максимальная куча не превышает 32 ГБ (если это так, я сомневаюсь, что использование 32-битного кода является допустимым выбором для это приложение). Он может по-прежнему потреблять больше оперативной памяти по сравнению с 32-разрядной JVM, поскольку некоторые компоненты по-прежнему требуют использования указателей на 64 бита, но это, как правило, не соответствующие производительности части приложения.

Обратите внимание, что для архитектуры AMD64 aka x86-64 с использованием режима 64 бит подразумевается не только изменение размера указателя. Примечание позволяет использовать только 64 бит для каждого регистра, а также имеет больше используемых регистров. Это действительно другая архитектура, реализованная в одном чипе, и в зависимости от вашего приложения, что позволяет улучшить его.

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

Ответ 4

Если вы намереваетесь использовать одну из виртуальных машин Oracle, вопрос будет больше связан с тем, хотите ли вы использовать клиент или JIT сервера, поскольку нет никакого JIT-клиента, доступного для любого 64-битного процессора от Oracle.

Серверная VM доступна как для 32-разрядных, так и для 64-битных процессоров, а разницы в производительности серверов VM на процессорах x86/AMD64 довольно малы (по моему опыту это меньше +/- 5% в Windows или Linux), хотя для 64-битной виртуальной машины обычно требуется примерно на 20% больше памяти.

Если вашему приложению требуется размер памяти кучи более 1,3 ГБ, вам придется использовать 64-битную виртуальную машину, поскольку 32-разрядные виртуальные машины от Oracle не будут начинаться с размеров кучи, превышающих размер (на Linux это ограничение немного выше).

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

С другой стороны, VM-сервер имеет возможность значительно быстрее выполнять вычислительный интенсивный код. Фактические различия в производительности сильно различаются в зависимости от кода, который вы выполняете, но могут составлять от -10% до + 200%. Обычно он по крайней мере на 30% быстрее для всего, что требуется для запуска более нескольких сотен миллисекунд.

Вы можете настроить оба JIT с различными параметрами, чтобы сделать их более похожими, но вы по-прежнему получаете быстрое время запуска только с клиентской VM и максимальными скоростями выполнения только с VM сервера.

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

Ответ 5

32-битные адреса памяти меньше. Это само по себе, вероятно, приводит к лучшему кэшированию, локальности ссылок и т.д.

Ответ 6

32-разрядный адрес меньше объема памяти Максимальный теоретический предел составляет 4 ГБ, но на практике он составляет 1,3 ГБ в системе Windows. Вы можете указать некоторые из них (от 300 до 400 МБ) на ядро ​​Linux. Для более подробной информации используйте http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit (память пространства кучи)

В 64-битной версии используются более высокие биты. Таким образом, общее потребление памяти также выше. Можно использовать указатель сжатой памяти. Узнайте больше об этом на http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html#compressedOop

Ответ 7

Причина, по которой бит 64 бит медленнее, вызван большими паузами в сборке мусора. Создание большего количества кучи означает, что GC выполняет большую работу, очищая его от неиспользуемых объектов. Что это означает в реальной жизни, так это то, что вы должны быть осторожны при создании кучи размером более 12-16 ГБ. Без точной настройки и измерения вы можете легко ввести полные паузы GC, охватывающие несколько минут.

Ответ 8

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

Итак, если есть экзотические ошибки, скрывающиеся в 32-битной версии, вы, возможно, первыми узнаете. Это будет тип ошибок, которые будут менее заметны на настольных системах и более заметны в долгосрочном программном обеспечении на стороне сервера. Подумайте о таинственных авариях через несколько недель/дней. Утечки памяти и т.д.

Итак, если вы развертываете на сервере, в значительной степени идите на 64 бит, если у вас нет очень сильной причины. Есть множество решений для snakeoil, которые распространяются, когда речь идет о использовании памяти Java и сборке мусора. Поэтому я бы с осторожностью использовал это как аргумент в любом случае, если вы не можете поддержать его с помощью каких-то твердых показателей. По моему опыту, инженеры java, которые знают, как правильно настроить jvm, на самом деле довольно редки, и большинство из них просто случайно копируют паттерны на JVM_ARGS до тех пор, пока не будут работать. Большинство из них в конечном итоге стреляют в ногу с решениями, которые либо не оптимальны, либо больше не подходят для JVM, которые они используют, либо активно вредны. Настройка Jvm - это немного черное искусство. Лучше не смущать слишком много, если вы не знаете, что делаете.

Для клиентских систем переходите 32 бит, если вам нужно поддерживать апплеты или старые настольные системы. Например. Windows до недавнего времени поставляла 32-битные версии своей ОС, и множество приложений на окнах и osx продолжали оставаться 32 бит. В основном вам не нужно выбирать и в любом случае, и вы можете оставить этот выбор пользователю.

Для людей, обеспокоенных размером адреса, 64-разрядная версия может выполнять сжатие указателя для куч размером меньше 32 ГБ. Вы должны (и, вероятно, захотите) включить это в аргументах JVM: -XX:+UseCompressedOops..