在 64 位 java 中使用 long 代替 int 会带来好处
在 64 位 VM 中,使用 long 而不是 int 在性能方面会更好,因为 java 中的 long 是 64 位,因此拉取和处理 64 位字可能会有所不同。比在 64 位系统中提取 32 位字更快。 (我期待很多否定,但我正在寻找详细的解释)。
编辑:我的意思是“在 64 位系统中提取和处理 64 位字可能比提取 32 位字更快”,因为我假设在 64 位系统中,提取 32 位数据会要求您首先获取 64 位字,然后屏蔽前 32 位。
In a 64 bit VM, will using longs instead of ints do any better in terms of performance given that longs are 64 bits in java and hence pulling and processing 64 bit word may be faster that pulling 32bit word in a 64 bit system. (I am expecting a lot of NOs but I was looking for a detailed explanation).
EDIT: I am implying that "pulling and processing 64 bit word may be faster that pulling 32bit word in a 64 bit system" because I am assuming that in a 64 bit system, pulling a 32 bit data would require you to first get the 64 bit word and then mask the top 32 bits.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
发布评论
评论(3)
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
使用
long
作为int
可能会降低你的速度。您最关心的是 64 位 CPU 上的
int
是否需要额外的处理时间。这在现代流水线 CPU 上是不太可能发生的。我们可以用一个小程序轻松测试这一点。它所操作的数据应该足够小以适合 L1 缓存,因此我们正在测试这个特定问题。在我的机器(64 位 Intel Core2 Quad)上基本上没有区别。在真实的应用程序中,大多数数据不能驻留在 CPU 缓存中。我们必须担心将数据从主内存加载到缓存,这相对非常慢并且通常是瓶颈。这种加载以“缓存行”为单位进行,即 64 字节或更多,因此加载单个
long
或int
将花费相同的时间。然而,使用
long
会浪费宝贵的缓存空间,因此缓存未命中会增加,这是非常昂贵的。 Java的堆空间也受到压力,因此GC活动会增加。我们可以通过读取具有相同数量元素的大型
long[]
和int[]
数组来演示这一点。它们比缓存所能容纳的要大得多。长版本在我的机器上花费了 65% 的时间。测试受限于内存->缓存的吞吐量,long[]内存体积要大100%。 (我无法理解为什么不花 100% 多的时间;显然还有其他因素在起作用)Using
long
forint
probably will slow you down in general.You immediate concern is whether
int
on 64 bit CPU requires extra processing time. This is highly unlikely on a modern pipelined CPU. We can test this easily with a little program. The data it operates on should be small enough to fit in L1 cache, so that we are testing this specific concern. On my machine (64bit Intel Core2 Quad) there's basically no difference.In a real app, most data can't reside in CPU caches. We must worry about loading data from main memory to cache which is relatively very slow and usually a bottleneck. Such loading works on the unit of "cache lines", which is 64 bytes or more, therefore loading a single
long
orint
will take the same time.However, using
long
will waste precious cache space, so cache misses will increase which are very expensive. Java's heap space is also stressed, so GC activity will increase.We can demonstrate this by reading huge
long[]
andint[]
arrays with the same number of elements. They are way bigger than caches can contain. The long version takes 65% more time on my machine. The test is bound by the throughput of memory->cache, and the long[] memory volume is 100% bigger. (why doesn't it take 100% more time is beyond me; obviously other factors are in play too)