CODEWITHSUNDEEP
performance64-bit32-bit
Heinrich Ulbricht
Heinrich Ulbricht

Reputation: 10372

Where is the bottleneck when using 64-bit variables and 32-bit systems?

A colleague and I recently were arguing about whether or not it is a good idea to use 64-bit variables in 32-bit code. I took a side saying "It might be dangerous and slow us down somewhere", he said "Nah. Nothing bad will happen." So who is right?

The bitness of parts of our ecosystem is as follows:

Windows: either 32-bit or 64-bit

Compiler: 32-bit only (Delphi...)

Processor: modern Intel ones... that's 64-bit, isn't it?

Let's say we have some variables which use some 64-bit type built into the language, with Delphi that would be Int64. Is it safe (performance-wise) to scatter the code with calculations based on these?

Upvotes: 0

Views: 843

Answers (5)

SecurityMatt
SecurityMatt

Reputation: 6743

Ask yourself this:

Does this variable ever need to store a value that can be bigger than 32-bit, and then choose from the following:

If this answer is "no", use an unsigned int.

If the answer is "yes", use an unsigned 64-bit int. 64-bit ints aren't very memory expensive and are cheap to add or subtract (and reasonably cheap to multiply divide).

If the answer is "yes, but only on 64-bit systems" (for example the length of a buffer might be > 4GB on 64-bit but never on 32-bit), use a "size_t". This is defined to be 32-bit on 32-bit systems and 64-bit on 64-bit systems.

Write your program to be correct, and let the optimiser / performance tests help you get it fast afterwards. It's more expensive for you to write it fast first and fix it later than for you to write it correct first and make it fast later.

Upvotes: 0

David Heffernan
David Heffernan

Reputation: 612794

On x64 architecture, if you only need 32 bit wide integers, then using 32 bit wide integers will result in faster code, even when running 64 bit code.

Upvotes: 0

phkahler
phkahler

Reputation: 5767

It's bad. The data takes twice the memory, so it's like running on a processor with half the cache. It also requires 2 instructions to load, 2 instructions to add, and 2 instructions to store a pair of numbers. You can test this with simple programs like a prime number sieve. These will generally run measurably slower using the longer types on a 32bit machine, and even on a 64bit machine when you get larger than the cache. The worst part is that once you sprinkle this stuff all over your code, you'll have a systemic performance problem that will be hard to correct later. And yes, similar is even true of using 32 bit integers where shorts could be used, but only with regard to memory performance - a 32bit CPU can do 32bit math just as fast as 16bit - so don't worry about that (or your spreadsheet will only support 65K rows for example).

Upvotes: 0

Bernd Elkemann
Bernd Elkemann

Reputation: 23550

GCC (and i doubt your Delphi-compiler is much better) compiles/assembles its long long data-datatype so that it uses the EAX and ECX registers, loading them already takes longer than only loading one of them (if it is actually double the time depends on the cache). It then assembles multiple instructions where you would only need one for e.g. ADD/SUB/IDIV if you were only operating on a single 32-bit value. Then follow the stores for EAX and ECX which again take longer than storing only one of them.

Upvotes: 0

Joe Zitzelberger
Joe Zitzelberger

Reputation: 4263

It sounds like you are doing some premature optimization.

Even if it would cause a very slight performance hit, the hardware of your users are more likely to have 64-bit machines as the software ages. So it would be a self correcting problem, if it even is a problem.

If the compiler supports them, go ahead and use them. If you find a slowdown in a tight loop with lots of calculations, then perhaps consider changing it.

Upvotes: 1

Related Questions