20

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.

Suraj Chandran
  • 24,433
  • 12
  • 63
  • 94
  • On some processors it is slower to read a 32 bit word into a 64 bit register than to read the 64 bit word. But most (all?) modern processors do not have that problem. – Hot Licks Aug 02 '11 at 02:40

3 Answers3

25

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)

irreputable
  • 44,725
  • 9
  • 65
  • 93
  • 1
    On the other hand, in a multi-threaded app on a multiprocessor, if you have two 4-byte variables in the same 8-byte machine word and they are frequently accessed by different threads/processors you'll generally see a significant slowdown (on the order of 10x or worse) vs having them in separate machine words. (And, of course, even in separate machine words isn't that great if they're in the same cache line.) – Hot Licks Aug 02 '11 at 02:35
  • 3
    @irreputable, why would using long instead of int waste cache space? – Suraj Chandran Aug 08 '11 at 07:12
  • I meant if you use `long` to represent `int`, obviously it will take more space. – irreputable Aug 10 '11 at 12:53
  • using long for iterator variables will result into bad code (not unrolled loops, probably worse branch prediction, etc) – bestsss Feb 02 '13 at 23:32
5

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.

JonH
  • 32,732
  • 12
  • 87
  • 145
  • ur answer would sufice for enterprise apps, but lets say that I am trying to micro-optimize my program which has no GUI and is higly performance oriented. Wont pulling a million 32 bit data a million times even be a microsecond slower than pulling 64 bit data. I am really trying to find the answer here and not provoke arguments.:) – Suraj Chandran Aug 01 '11 at 19:31
  • @Suraj Chandran - I don't know put some timing code in there and test to see if you get .0000001 better performance, highly unlikely. – JonH Aug 01 '11 at 19:33
  • but what do u say theorotically, do u have any thing against my theory in the question, or u thing is it wrong? If not atleast theorotically it should be slower. And then finally why would practical be different in theory in this case – Suraj Chandran Aug 01 '11 at 19:35
  • 1
    @Suraj Chandran - My answer is "as is", I do not believe you will see a performance changed based on your question or your comments. I might be wrong, hence test it. I always live by use what you need, and in this case if I can get by using an int / short why on earth would I use a long? – JonH Aug 01 '11 at 19:42
  • 3
    while this is good advice, it doesn't answer the question that was asked – Jason Wheeler Aug 01 '11 at 23:20
  • @Suraj -- In general processor speed is limited by memory speed -- the "average" processor would run 3-10x faster if not limited by memory accesses. So in general using smaller words, if you're using a lot of them and if they are compactly together, will spin through less storage and will produce better performance. (But of course there are many enlisted men for every general, and outside of a general all bets are off.) – Hot Licks Aug 02 '11 at 02:45
  • @daniel, this is not correct, i am sure i remeber that running 16 bit programs on 32 bit system is slower than 32 bit programs – Suraj Chandran Aug 02 '11 at 05:20
  • @Bigwheels - Sometimes there isn't a definite solution to a problem. – JonH Aug 02 '11 at 11:39
  • Running a 16-bit program on a 32-bit system is a different beast. Much of the 16-bit environment must be emulated, and system calls must take a longer path to map parameters. (And remember -- I said there are more enlisted men than generals.) – Hot Licks Aug 02 '11 at 11:52
1

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.

Hot Licks
  • 47,103
  • 17
  • 93
  • 151
  • why would it depend on implementation? what do u mean by "how you use those variables"? – Suraj Chandran Aug 01 '11 at 19:21
  • 3
    Some implementations have a 64 bit stack internally, some have a 32 bit stack. Variable size affects variable alignment, which, among other things, affects how multitasking performs. Lots of different variables in the equation. – Hot Licks Aug 01 '11 at 19:24
  • can u point me to atleast one 64 bit implementation that has a 32 bit stack. Its hard to believe :) – Suraj Chandran Aug 01 '11 at 19:26
  • Actually, it's hard to believe that even 32-bit implementations had a 32-bit stack, but that's a different matter. But I know several early "64-bit" implementations had a 32-bit stack. Don't know that any still exist. – Hot Licks Aug 01 '11 at 20:02
  • 1
    A more direct answer to your question: I'm pretty sure that the first Sun "64-bit" JVM had a 32-bit stack. It was a kludge built by just recompiling their 32-bit JVM with a few 64-bit tweaks to make use of 64-bit addressing features. Similarly, IBM produced two "64-bit" JVMs with 32-bit stacks. What may have been the first "production" 64-bit JVM, though, was the IBM iSeries JVM which did, indeed have a 64-bit stack from the start, since it was built from scratch to be a 64-bit JVM (whereas the Sun and the other IBM JVM lines were extended from 32-bit JVMs and #ifdefed). – Hot Licks Aug 02 '11 at 02:50
  • so we come back to 0, i.e., there probably wont be any "prodcution elvel" 64 bit jvm with 32 bit stack – Suraj Chandran Aug 02 '11 at 06:57
  • I don't know. The 32/64 scheme may still be popular, since it conserves storage better than a pure 64 scheme. – Hot Licks Aug 02 '11 at 11:50