Optimizing question(s)...

This is a discussion on Optimizing question(s)... within the C++ Programming forums, part of the General Programming Boards category; I think I may already know the answer for this question, but just to make sure... I was reading up ...

  1. #1
    Not stupid, just stupider yaya's Avatar
    Join Date
    May 2007
    Location
    Earthland
    Posts
    204

    Thumbs up Optimizing question(s)...

    I think I may already know the answer for this question, but just to make sure...
    I was reading up at this page:
    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.

  2. #2
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,439
    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).
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  3. #3
    Registered User
    Join Date
    May 2007
    Posts
    147
    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.

  4. #4
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by yaya View Post
    I think I may already know the answer for this question, but just to make sure...
    I was reading up at this page:
    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).

    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.
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Problem building Quake source
    By Silvercord in forum Game Programming
    Replies: 16
    Last Post: 07-11-2010, 09:13 AM
  2. questions....so many questions about random numbers....
    By face_master in forum C++ Programming
    Replies: 2
    Last Post: 07-30-2009, 08:47 AM
  3. A very long list of questions... maybe to long...
    By Ravens'sWrath in forum C Programming
    Replies: 16
    Last Post: 05-16-2007, 05:36 AM
  4. Trivial questions - what to do?
    By Aerie in forum A Brief History of Cprogramming.com
    Replies: 23
    Last Post: 12-26-2004, 08:44 AM
  5. questions questions questions.....
    By mfc2themax in forum A Brief History of Cprogramming.com
    Replies: 1
    Last Post: 08-14-2001, 07:22 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21