Question

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.

Answer 1

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)