# Optimizing question(s)...

• 05-04-2009
yaya
Optimizing question(s)...
I think I may already know the answer for this question, but just to make sure...
C++ Optimizations You Can Do "As You Go"
and it has intrigued me that passing an int (or even a bool) as an argument would be slower than by reference/pointer. So here's my questions:
On 32 bit machines, pointers are 32bits, and 64 for 64bit machines, right?
And 32 bit CPUs can only process 32bits at a time (for each core), hence anything from 8 bits to 32 bits would take the same speed, right?
If yes to both, then would that mean a double (64 bits) on a 64 bit machine would take the same length of time to process as an int (32 bits) on a 32 bit machine?
What if I had 4 different 8 bit variables on a 32 bit machine? Would the CPU compress it and process it as it would with a 32bit int?

Sorry for the overload, but this has sparked my interest.

Cheers.
• 05-04-2009
laserlight
Quote:

Originally Posted by yaya
and it has intrigued me that passing an int (or even a bool) as an argument would be slower than by reference/pointer.

That is not likely, and is not postulated in the article that you linked to (which says otherwise, in fact).
• 05-04-2009
JVene
I have found it helpful to understand the assembler implications of some of these ideas.

Pushing a 32 bit integer is no different than pushing a reference to that integer in a 32bit build. A push on the stack is a push on the stack, though in some cases if a reference or pointer is pushed instead of a value of the same size (float at 32bits, integer, etc), there might be a reason to dereference the value FOR the push which is what might take longer, but it's trivial.

A 64 bit push may take about the same time as a 32 bit push in theory, but it IS twice the data - it may be that cache is filled up faster, and that consumption could lead to slower operation for complex reasons in certain situations, but again this is a trivial difference. There are gains in speed on balance that overcome that issue.

Many of the other points in the article are of significant value.

To your last question, the chip doesn't compress anything, and the compiler can choose optimized means regarding some actions, but 4 8 bit values would be pushed as 4 values (4 push operations) in most cases.

Compilers can do some amazing things during optimization, many you wouldn't think of yourself, and sometimes I've had a hard time believing what it can do. To many examples to illustrate. There are times when the compiler can forgo pushing an argument to a function if it realizes that can be optimized for speed without changing the meaning of your code.
• 05-05-2009
matsp
Quote:

Originally Posted by yaya
I think I may already know the answer for this question, but just to make sure...
C++ Optimizations You Can Do "As You Go"
and it has intrigued me that passing an int (or even a bool) as an argument would be slower than by reference/pointer. So here's my questions:
On 32 bit machines, pointers are 32bits, and 64 for 64bit machines, right?
And 32 bit CPUs can only process 32bits at a time (for each core), hence anything from 8 bits to 32 bits would take the same speed, right?

Yes, but passing an integer as a reference AND THEN USING it will have an overhead in the called function (callee) as the callee will have to dereference the address passed, rather than directly use the value. It's got nothing to do with size, and everything to do with "how the processor uses the information passed".

There are other consequences: If you take the address of an integer, it can not be (permanently) placed in a register. Which will slow down the code in the calling function (caller).

Quote:

If yes to both, then would that mean a double (64 bits) on a 64 bit machine would take the same length of time to process as an int (32 bits) on a 32 bit machine?
Yes, no and maybe. Floating point values are treated separately of 64-bit integer values. If we are talking of x86, then floating point values are generally passed on the FPU stack (32-bit) or in SSE registers(64-bit), which are separate from the regular register set and the stack. Although sometimes the value is indeed pushed onto the regular CPU stack, in which case there are extra instructions involved in decrementing the stack-pointer, then storing the value itself.

Other processor architectures may be different, as floating point calculations are sometimes done in the main CPU registers (or pairs of CPU registers in case of 32-bit CPU's doing 64-bit FPU operations), but often in a separate set of registers.
Quote:

What if I had 4 different 8 bit variables on a 32 bit machine? Would the CPU compress it and process it as it would with a 32bit int?
I'm not aware of ANY compiler that stores 4 x 8 bits in a 32-bit register when passing arguments to functions. In fact it's likely that this will lead to extra overhead in compressing in the caller and then extracting the values in the callee - it's simply faster to pass a 8-bit value as a 32-bit value.

--
Mats