在 64 位 java 中使用 long 代替 int 会带来好处

发布于 11-27 18:15 字数 287 浏览 1 评论 0原文

在 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

星光不落少年眉2024-12-04 18:15:16

使用 long 作为 int 可能会降低你的速度。

您最关心的是 64 位 CPU 上的 int 是否需要额外的处理时间。这在现代流水线 CPU 上是不太可能发生的。我们可以用一个小程序轻松测试这一点。它所操作的数据应该足够小以适合 L1 缓存,因此我们正在测试这个特定问题。在我的机器(64 位 Intel Core2 Quad)上基本上没有区别。

在真实的应用程序中,大多数数据不能驻留在 CPU 缓存中。我们必须担心将数据从主内存加载到缓存,这相对非常慢并且通常是瓶颈。这种加载以“缓存行”为单位进行,即 64 字节或更多,因此加载单个 longint 将花费相同的时间。

然而,使用long会浪费宝贵的缓存空间,因此缓存未命中会增加,这是非常昂贵的。 Java的堆空间也受到压力,因此GC活动会增加。

我们可以通过读取具有相同数量元素的大型 long[]int[] 数组来演示这一点。它们比缓存所能容纳的要大得多。长版本在我的机器上花费了 65% 的时间。测试受限于内存->缓存的吞吐量,long[]内存体积要大100%。 (我无法理解为什么不花 100% 多的时间;显然还有其他因素在起作用)

Using long for int 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 or int 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[] and int[] 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)

云裳2024-12-04 18:15:16

我总是根据您的问题域使用正确的数据类型

我的意思是,如果您需要 64 位长,则使用 64 位长,但如果您不需要 64 位长,则使用 int。

在64位平台上使用32位并不昂贵,并且基于性能进行比较没有任何意义。

对我来说,这看起来不对:

for(long l = 0; l<100; l++)
 //SendToTheMoon(l);

并且 SendToTheMoon 与它无关。

I always go with use the right datatype based on your problem domain.

What I mean by this is if you need 64 bit long then use a 64bit long, but if you don't need a 64 bit long then use an int.

Using 32 bits on a 64 bit platform is not expensive, and it makes no sense to do a comparison based on performance.

To me this doesn't look right:

for(long l = 0; l<100; l++)
 //SendToTheMoon(l);

And SendToTheMoon has nothing to do with it.

谁的年少不轻狂2024-12-04 18:15:16

可能会更快,也可能会更慢。取决于具体的 Java 实现以及您如何使用这些变量。但总的来说,可能还没有足够的差异值得担心。

Might be faster, might be slower. Depends on the specific Java implementation, and how you use those variables. But in general it's probably not enough difference to worry about.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文