Java 64 位是否比 32 位版本性能更好？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/589057/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Does Java 64 bit perform better than the 32-bit version?
提问by Joshua
采纳答案by Charlie Martin
Define your workload and what "perform" means to you.
定义您的工作量以及“执行”对您的意义。
This is sort of a running annoyance to me, as a performance geek of long standing. Whether or not a particular change "performs better" or not is dependent, first and foremost, on the workload, ie, what you're asking the program to do.
作为一个长期存在的性能极客，这对我来说是一种烦恼。特定更改是否“表现更好”首先取决于工作负载，即您要求程序执行的操作。
64 bit Java will often perform better on things with heavy computation loads. Java programs, classically, have heavy I/O loads and heavy network loads; 64 bit vs 32 bit may not matter, but operating systems usually do.
64 位 Java 通常在计算负载较重的情况下表现更好。经典的 Java 程序具有繁重的 I/O 负载和繁重的网络负载；64 位与 32 位可能无关紧要，但操作系统通常会如此。
回答by Chris Ballance
Yes, especially if your code is built to target a 64 bit platform.
是的，特别是如果您的代码是针对 64 位平台构建的。
回答by Tom Hawtin - tackline
On most CPU architecures 32-bits is faster than 64-bit, all else being equal. 64-bit pointers require twice as much bandwidth to transfer as 32-bits. However, the x64 instruction set architecture adds a bit of sanity over x86, so it ends up being faster. The amount of handling of long types is usually small.
在大多数 CPU 架构上，32 位比 64 位快，其他条件相同。64 位指针传输所需的带宽是 32 位指针的两倍。然而，x64 指令集架构比 x86 增加了一点理智，所以它最终会更快。long 类型的处理量通常很小。
Of course it also depends upon the implementation of Java. As well as the compiler, you might find differences in the implementation; for instance, NIO assumes 64-bit pointers. Also note that Sun previously only shipped the faster server HotSpotimplementation for x64. This meant that if you specified -d64, you would also switch from client to server HotSpot, IIRC.
当然这也取决于Java的实现。与编译器一样，您可能会发现实现上的差异；例如，NIO 假设使用 64 位指针。另请注意，Sun 以前仅提供用于 x64的更快服务器HotSpot实现。这意味着如果您指定-d64，您还将从客户端切换到服务器 HotSpot，IIRC。
回答by Andreas Petersson
Some improvements: operations with doubles on 64 bits compute equally fast as floats on 32 bits, as well as operations on long at 64 bit compared to int.
一些改进：64 位双精度运算与 32 位浮点运算的计算速度一样快，以及与 int 相比，64 位 long 运算的计算速度相同。
So if you are running code with tons of longs you might see a real improvement.
因此，如果您正在运行具有大量 long 的代码，您可能会看到真正的改进。
回答by Darron
Almost always 64 bits will be slower.
几乎总是 64 位会更慢。
To quote Sun from the HotSpot FAQ:
从HotSpot FAQ 中引用 Sun ：
The performance difference comparing an application running on a 64-bit platform versus a 32-bit platform on SPARC is on the order of 10-20% degradation when you move to a 64-bit VM. On AMD64 and EM64T platforms this difference ranges from 0-15% depending on the amount of pointer accessing your application performs.
当您迁移到 64 位虚拟机时，在 64 位平台上运行的应用程序与在 SPARC 上运行的 32 位平台的性能差异大约会降低 10-20%。在 AMD64 和 EM64T 平台上，此差异范围为 0-15%，具体取决于访问应用程序执行的指针数量。
There are more details at the link.
链接中有更多详细信息。
回答by Peter Lawrey
64-bit perform better if you need much more than 1.2 GB. On some platforms you can get up to 3 GB but if you want 4 - 384 GB for example, 64-bit is your only option.
如果您需要超过 1.2 GB 的空间，64 位的性能会更好。在某些平台上，您最多可以获得 3 GB，但如果您想要 4 - 384 GB，例如，64 位是您唯一的选择。
I believe Azul supports a 384 GB JVM, does anyone know if you can go higher?
我相信 Azul 支持 384 GB JVM，有谁知道你是否可以更高？
回答by Daniel
My experience differs from the other answers.
我的经历与其他答案不同。
Java 64bit may be faster than 32bit. At least with my tests it always was! The pointer argument is not valid when less than 4GB are used because then the 64bit-VM will also use short pointers internally. You get however the faster instruction set of the 64bit CPUs!
Java 64 位可能比 32 位快。至少在我的测试中它总是如此！当使用小于 4GB 时，指针参数无效，因为 64 位虚拟机也将在内部使用短指针。但是，您将获得 64 位 CPU 的更快指令集！
I tested this with Windows 7 and JDE1.8.0_144, but maybe the real reason are different internal JVM setting. When you use the 64-bit JVM it starts in "server" mode, while the 32-bit VM starts in "client" mode.
我用 Windows 7 和 JDE1.8.0_144 对此进行了测试，但可能真正的原因是内部 JVM 设置不同。当您使用 64 位 JVM 时，它以“服务器”模式启动，而 32 位 VM 以“客户端”模式启动。
回答by sebrockm
I know that this question is quite old and the voted answers were probably correct at the time when they were written. But living in 2018 now, things have changed.
我知道这个问题已经很老了，投票的答案在撰写时可能是正确的。但是现在生活在 2018 年，事情发生了变化。
I just had an issue with a Java client application running on Win 10 64Bit on a Java 8 32Bit JVM. It was reading 174 MBof data from an HttpsURLConnection's InputStreamin 26swhich is awfully slow. The server and network were proven not to be the cause of this.
我刚刚遇到了在 Java 8 32Bit JVM 上的 Win 10 64Bit 上运行的 Java 客户端应用程序的问题。它在 26秒内从's读取174 MB数据，这非常慢。事实证明，服务器和网络不是造成这种情况的原因。HttpsURLConnectionInputStream
Thinking "Hey, there cannot be a huge difference between 32Bit and 64Bit JRE" it took some time until I tried having the very same code executed by a 64Bit JVM. Fortunately, in the end I did it: It was reading the very same 174MB in 5s!
想着“嘿，32 位和 64 位 JRE 之间不可能有很大的区别”，我花了一些时间才尝试让 64 位 JVM 执行完全相同的代码。幸运的是，最后我做到了：它在 5 秒内读取了相同的174MB！
I don't know if I could make it even faster, but the key take-away is this:
我不知道我是否可以让它更快，但关键的要点是：
- jre1.8.0_172 32Bit : 6.692MB/s
- jre1.8.0_172 64Bit : 34.8MB/s
- jre1.8.0_172 32Bit：6.692MB/s
- jre1.8.0_172 64 位：34.8MB/s
for the very samejar file being executed on Windows 10 64Bit.
对于在 Windows 10 64Bit 上执行的相同jar 文件。
I have no idea what could be the reason for this, but I can answer this question by "Yes, 64Bit Java is better than 32Bit Java". See also the numbers in the answer of my questionregarding this issue.
我不知道这可能是什么原因，但我可以通过“是的，64 位 Java 比 32 位 Java 更好”来回答这个问题。另请参阅我关于此问题的问题的答案中的数字。
