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.
I believe Azul supports a 384 GB JVM, does anyone know if you can go higher?
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.
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 MB of data from an HttpsURLConnection's InputStreamin 26s which is awfully slow. The server and network were proven not to be the cause of this.
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!
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
for the very same jar file being executed on Windows 10 64Bit.
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 question regarding this issue.
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.
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 HotSpot implementation for x64. This meant that if you specified -d64, you would also switch from client to server HotSpot, IIRC.
一些改进：64 位上的双精度运算的计算速度与 32 位上的浮点运算的速度相同，以及与 int 相比，64 位上的 long 运算的计算速度。
因此，如果您正在运行包含大量 long 的代码，您可能会看到真正的改进。
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.
So if you are running code with tons of longs you might see a real improvement.
Java 64 位可能比 32 位更快。 至少在我的测试中它总是如此！ 当使用的内存小于 4GB 时，指针参数无效，因为 64 位 VM 也会在内部使用短指针。 然而，您可以获得更快的 64 位 CPU 指令集！
我使用 Windows 7 和 JDE1.8.0_144 进行了测试，但真正的原因可能是内部 JVM 设置不同。 当您使用 64 位 JVM 时，它以“服务器”模式启动，而 32 位 VM 以“客户端”模式启动。
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!
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.
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.
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.
发布评论
评论（8）
如果您需要 1.2 GB 以上的空间，64 位的性能会更好。 在某些平台上，您最多可以获得 3 GB，但如果您想要 4 - 384 GB，则 64 位是您唯一的选择。
我相信 Azul 支持 384 GB JVM，有人知道是否可以更高吗？
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.
I believe Azul supports a 384 GB JVM, does anyone know if you can go higher?
我知道这个问题已经很老了，投票的答案在撰写时可能是正确的。 但现在生活在2018年，情况发生了变化。
我刚刚在 Java 8 32 位 JVM 上的 Win 10 64 位上运行 Java 客户端应用程序时遇到问题。 它在 26 秒内从
HttpsURLConnection的InputStream读取 174 MB 数据，速度非常慢。 事实证明服务器和网络不是造成这种情况的原因。想着“嘿，32 位和 64 位 JRE 之间不可能有巨大差异”，我花了一些时间才尝试让 64 位 JVM 执行完全相同的代码。 幸运的是，最终我做到了：它在 5 秒内读取了同样的174MB！
我不知道是否可以让它更快，但关键是：
对于非常相同< /strong> jar 文件正在 Windows 10 64 位上执行。
我不知道这可能是什么原因，但我可以通过“是的，64位Java比32位Java更好”来回答这个问题。 另请参阅我的问题的答案中有关此问题的数字。
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.
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 MB of data from an
HttpsURLConnection'sInputStreamin 26s which is awfully slow. The server and network were proven not to be the cause of this.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!
I don't know if I could make it even faster, but the key take-away is this:
for the very same jar file being executed on Windows 10 64Bit.
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 question regarding this issue.
在大多数 CPU 架构上，32 位比 64 位快，其他条件相同。 64 位指针传输所需的带宽是 32 位指针的两倍。 然而，x64 指令集架构比 x86 增加了一些理智，因此它最终速度更快。 长类型的处理量通常很小。
当然这也取决于Java的实现。 除了编译器之外，您可能会发现实现方面的差异； 例如，NIO 假定 64 位指针。 另请注意，Sun 之前仅提供针对 x64 的更快的服务器 HotSpot 实现。 这意味着，如果您指定
-d64，您还将从客户端 HotSpot、IIRC 切换到服务器 HotSpot。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.
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 HotSpot implementation for x64. This meant that if you specified
-d64, you would also switch from client to server HotSpot, IIRC.一些改进：64 位上的双精度运算的计算速度与 32 位上的浮点运算的速度相同，以及与 int 相比，64 位上的 long 运算的计算速度。
因此，如果您正在运行包含大量 long 的代码，您可能会看到真正的改进。
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.
So if you are running code with tons of longs you might see a real improvement.
我的经历与其他答案不同。
Java 64 位可能比 32 位更快。 至少在我的测试中它总是如此！ 当使用的内存小于 4GB 时，指针参数无效，因为 64 位 VM 也会在内部使用短指针。 然而，您可以获得更快的 64 位 CPU 指令集！
我使用 Windows 7 和 JDE1.8.0_144 进行了测试，但真正的原因可能是内部 JVM 设置不同。 当您使用 64 位 JVM 时，它以“服务器”模式启动，而 32 位 VM 以“客户端”模式启动。
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!
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.
是的，特别是如果您的代码是针对 64 位平台构建的。
Yes, especially if your code is built to target a 64 bit platform.
几乎总是 64 位会比较慢。
引用 Sun 的 HotSpot FAQ 中的内容：
链接中有更多详细信息。
Almost always 64 bits will be slower.
To quote Sun from the HotSpot FAQ:
There are more details at the link.
定义您的工作量以及“执行”对您意味着什么。
作为一个长期的性能极客，这对我来说是一种持续的烦恼。 特定的更改是否“表现更好”首先取决于工作负载，即您要求程序执行的操作。
64 位 Java 通常在计算负载繁重的情况下表现更好。 Java 程序通常具有繁重的 I/O 负载和繁重的网络负载； 64 位与 32 位可能并不重要，但操作系统通常很重要。
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.