15
Я заметил, что Sun предоставляет 64-битную версию Java. Он работает лучше, чем 32-битная версия?Является ли Java 64-разрядным лучше, чем 32-разрядная версия?
A
ответ
12
Определите свою рабочую нагрузку и что означает «выполнить» для вас.
Это своего рода запутанное раздражение ко мне, как выродка производительности. Независимо от того, выполняется ли какое-либо конкретное изменение «лучше» или нет, зависит, прежде всего, от рабочей нагрузки, то есть от того, что вы просите у программы.
64-разрядная Java часто будет лучше работать с вещами с тяжелыми вычислительными нагрузками. Java-программы, классически, имеют тяжелые нагрузки ввода-вывода и тяжелые сетевые нагрузки; 64-разрядная и 32-разрядная версии могут не иметь значения, но обычно работают операционные системы.
-2
Да, особенно если ваш код построен для установки на 64-битную платформу.
+1
Как точно один целевой код Java для 64-битной платформы? – TofuBeer
+0
Использование 64-битных целых чисел вместо 32 бит .... и т. Д. –
2
На большинстве архитекторов CPU 32-бит быстрее 64-битного, при прочих равных условиях. Для 64-разрядных указателей требуется в два раза больше полосы пропускания для передачи в виде 32 бит. Однако архитектура набора команд x64 добавляет немного здравого смысла по сравнению с x86, поэтому она заканчивается быстрее. Количество обработки длинных типов обычно невелико.
Конечно, это также зависит от реализации Java. Как и компилятор, вы можете обнаружить различия в реализации; например, NIO предполагает 64-битные указатели. Также обратите внимание, что Sun ранее отправляла только более быстрый сервер HotSpot для x64. Это означало, что если вы указали -d64, вы также переключитесь с клиента на сервер HotSpot, IIRC.
2
Некоторые улучшения: операции с удвоениями на 64 бит вычисляются одинаково быстро, как поплавки на 32 бита, а также операции с длиной в 64 бит по сравнению с int.
Так что если вы используете код с тоннами длин, вы можете увидеть реальное улучшение.
18
Почти всегда 64 бит будут медленнее.
Процитируем Sun от HotSpot FAQ:
Разница в производительности по сравнению приложение, работающее на 64-битной платформе в сравнении с 32-битной платформы на SPARC составляет порядка 10-20% Деградация при переходе на 64-разрядную VM. На платформах AMD64 и EM64T эта разница колеблется от 0-15% в зависимости от от количества указателей, обращающихся к , которые выполняет ваша заявка.
Дополнительную информацию можно получить по ссылке.
+0
почти всегда быстрее на x86_64, как указано в предыдущем абзаце –
3
64-бит лучше, если вам нужно гораздо больше 1,2 ГБ. На некоторых платформах вы можете получить до 3 ГБ, но если вы хотите, например, 4 - 384 ГБ, ваш единственный вариант - 64-битный.
Я считаю, что Azul поддерживает JVM емкостью 384 ГБ, знает ли кто-нибудь, можете ли вы подняться выше?
+0
1.2GB или что? Память? – johnny
+0
@johnny Да, 1,2 ГБ памяти на 32-битных системах Windows. –
0
Мой опыт отличается от других ответов.
Java 64bit может быть быстрее 32 бит. По крайней мере, мои тесты всегда были!Аргумент указателя недействителен, если используется менее 4 ГБ, потому что 64-битная виртуальная машина также будет использовать короткие указатели внутри. Тем не менее, вы получаете более быстрый набор команд из 64-битных процессоров!
Я тестировал это с Windows 7 и JDE1.8.0_144, но, возможно, настоящая причина - это разные внутренние настройки JVM. Когда вы используете 64-битную JVM, он запускается в режиме «сервер», а 32-разрядная виртуальная машина запускается в режиме «клиент».
Не могу поверить, что ответ прост. Для меня 64 бит больше подходит для нагрузок, где 64-разрядное адресное пространство - это помощь, а не помеха. Для каждого указателя есть 2x стоимость, которая может быть перевешена, если вам нужны МНОГИЕ данных. кеш-сервер веб-сервера - отличный пример того, где выигрывает 64 бит. – Cheeso
Солнце говорит, что этот ответ неверен. – Darron
Даррон, у вас есть цитата для этого? Поскольку я работал в компании Sun в течение 10 лет, и поскольку ответ в основном «зависит от рабочей нагрузки и какой производительности вы заботитесь об измерении», я - как это сделать - не верьте вам. –