Unstructured optimization



  •  My first days as a C coder at a small company, I noticed that every non trivial function in the code base had a high number of parameters.

    12 parameters were a bare minimum, 20 params very frequent and I found a monster function with 37 (or was it 47) parameters !

    When I asked my boss about this, he very seriously explained it as an optimization : "You see, if you use a structure, the program needs to take its address and add an offset each time you access a field. Thus by avoiding structures, we save a lot of time."

    He also gave this useful tip : "Since the parameters are stored on a stack,  try to always specify them in the order of use in the function, to speed up access".

     



  •  YARCI, they are more prevalent than people would like to admit

     keeping the parameters on the stack means that you need to take the the address of the top of the stack and add an offest, costing you the same amount of time



  • Technically he's not exactly wrong. The first parameters are passed in registers and the rest on the stack. So you can do computations with the values in the registers already, while waiting for the stack values to be loaded from ram in registers. Also you cannot pass struct parameters to functions, which means you do need to pass by address. This is the reason why some numeric code is faster when written in FORTRAN where you can use pass-by-value semantics for functions taking e.g. large arrays as parameters, but the compiler can deduce you're not modifying them so it does a pass by reference, but unlike in C, it doesn't need to care about aliasing. However, nowadays you can use the "restrict" keyword to mark your pointers as not-aliased. You should show it to your boss and educate him how making every pointer restricted will improve runtime and memory use compared to the pass-by-value functions you use now.



  • @ratchet freak said:

     YARCI, they are more prevalent than people would like to admit

     keeping the parameters on the stack means that you need to take the the address of the top of the stack and add an offest, costing you the same amount of time

    YARCI? http://acronymsandslang.com/meaning-of/YARCI.html

    What does "Youth as Resources of Central Indiana" have anything to do with this?



  • @ratchet freak said:

    YARCI, they are more prevalent than people would like to admit

    You Are Really Crud Intensive?

    Young Aardvarks Really Chase Insects?


  • Discourse touched me in a no-no place

    @gvh said:

    12 parameters were a bare minimum
    WTF!@gvh said:
    20 params very frequent
    WTF!@gvh said:
    monster function with 37
    I think there's some kind of repeating pattern here.



  • Solution: write a benchmark demonstrating both "optimization" steps and see if they actually do anything.



  • Since you're probably using the same sets of parameters every time, the obvious "C"-like solution is to #define the list of parameters so you won't have to repeat them every time.



  • @dtech said:

    Solution: write a benchmark demonstrating both "optimization" steps and see if they actually do anything.

    here you go. Note: It's been years since I last touched C and I never had any real experience with it.

    In the few runs I did the differences were in the milliseconds (with 1 millions executions). The struct was generally faster



  • The printfs and their general interaction with OS state will clobber any variance from the actual function call. Do some simple arithmetic computation instead and see if you can find a difference.

    If you're on x86-64, the calling convention means that the struct is essentially passed as a parameter in both the stack and in registers.



  • @gvh said:

     My first days as a C coder at a small company, I noticed that every non trivial function in the code base had a high number of parameters.

    12 parameters were a bare minimum, 20 params very frequent and I found a monster function with 37 (or was it 47) parameters !

    When I asked my boss about this, he very seriously explained it as an optimization : "You see, if you use a structure, the program needs to take its address and add an offset each time you access a field. Thus by avoiding structures, we save a lot of time."

    He also gave this useful tip : "Since the parameters are stored on a stack,  try to always specify them in the order of use in the function, to speed up access".

     

    OK, I've had my "performance first" phase as a programmer, but many years have passed and I've learned that maintainable code is always the best strategy. You can always win a few nanoseconds somewhere else or with more hardware.



  • @blakeyrat said:

    @ratchet freak said:
    YARCI, they are more prevalent than people would like to admit

    You Are Really Crud Intensive?

    Young Aardvarks Really Chase Insects?

    Yet Another Really Crappy Implementation?

    Yet Another Really Crappy Idea?

    Yet Another Retarded C Implementation?



  • @darkmattar said:

    @blakeyrat said:
    @ratchet freak said:
    YARCI, they are more prevalent than people would like to admit

    You Are Really Crud Intensive?

    Young Aardvarks Really Chase Insects?

    Yet Another Really Crappy Implementation?

    Yet Another Really Crappy Idea?

    Yet Another Retarded C Implementation?

    "Yoda?" Asked Really Cool Indonesians



  • @Ben L. said:

    @darkmattar said:
    @blakeyrat said:
    @ratchet freak said:
    YARCI, they are more prevalent than people would like to admit

    You Are Really Crud Intensive?

    Young Aardvarks Really Chase Insects?

    Yet Another Really Crappy Implementation?

    Yet Another Really Crappy Idea?

    Yet Another Retarded C Implementation?

    "Yoda?" Really Cool Indonesians, Asked

     

    YTFY

     



  • @Mo6eB said:

    The first parameters are passed in registers and the rest on the stack. So you can do computations with the values in the registers already, while waiting for the stack. [...] However, nowadays you can use the "restrict" keyword to mark your pointers as not-aliased. You should show it to your boss and educate him how making every pointer restricted will improve runtime and memory use compared to the pass-by-value functions you use now.

     

    While all of this may be true, I highly doubt that is what the OP's boss meant.

    Since the parameters are stored on a stack,  try to always specify them
    in the order of use in the function, to speed up access

    Reading this, I get the feeling he thinks of the stack as a strict LIFO queue* instead of random access, or some similar madness. Maybe he thinks a computer is a pushdown automaton.
    (*If you'd use a second stack to store away the elements that you had to pop out of the stack to get to a specific item, you'd even be Turing complete again, iirc. Who knows what he had in mind, but I'm pretty sure it wasn't fastcall calling conventions)

     


  • Discourse touched me in a no-no place

    @Mo6eB said:

    Technically he's not exactly wrong. The first parameters are passed in registers and the rest on the stack. So you can do computations with the values in the registers already, while waiting for the stack values to be loaded from ram in registers. Also you cannot pass struct parameters to functions, which means you do need to pass by address. This is the reason why some numeric code is faster when written in FORTRAN where you can use pass-by-value semantics for functions taking e.g. large arrays as parameters, but the compiler can deduce you're not modifying them so it does a pass by reference, but unlike in C, it doesn't need to care about aliasing. However, nowadays you can use the "restrict" keyword to mark your pointers as not-aliased. You should show it to your boss and educate him how making every pointer restricted will improve runtime and memory use compared to the pass-by-value functions you use now.

    Cut that out! Ignoring for the moment the register-vs-stack issue, because not all memory models work that way, nor will all compilers (x86-64 has 16 GP registers, not 32, so you have AT LEAST 18 you can use for parameters if you wanted!) this shows a fundamental misunderstanding of C. Structure field offsets are calculated at compile-time!



  • @topspin said:

    Since the parameters are stored on a stack,  try to always specify them
    in the order of use in the function, to speed up access

    Reading this, I get the feeling he thinks of the stack as a strict LIFO queue* instead of random access, or some similar madness. Maybe he thinks a computer is a pushdown automaton.

    $deity help us, they're making managers out of old FORTH programmers!

     



  • Yuppie Asshole Refactors Code Incorrectly?



  • @Ben L. said:

    @darkmattar said:
    @blakeyrat said:
    You Are Really Crud Intensive?

    Young Aardvarks Really Chase Insects?

    Yet Another Really Crappy Implementation?

    Yet Another Really Crappy Idea?

    Yet Another Retarded C Implementation?

    "Yoda?" Asked Really Cool Indonesians

    Yet Another Retarded, Clueless Idiot@ratchet freak said:
    YARCI, they are more prevalent than people members of the designated population would like to admit
    FTFY People who are not members of the designated class readily admit how prevalent they are.



  • @Ben L. said:

    @darkmattar said:
    @blakeyrat said:
    @ratchet freak said:
    YARCI, they are more prevalent than people would like to admit

    You Are Really Crud Intensive?

    Young Aardvarks Really Chase Insects?

    Yet Another Really Crappy Implementation?

    Yet Another Really Crappy Idea?

    Yet Another Retarded C Implementation?

    "Yoda?" Asked Really Cool Indonesians

    I think it's actually textspeak for "you see". But what would I know? I'm so out of touch I still put a nose on my emoticons ;o)


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.