Const call-by-references vs. const call-by-value

Started to rewrite some (not to say ALL) parameters of a bunch of classes to be "const". That and that I begin to doubt the usefulness of my "ConstRef" meta class (it gives you either a reference type or a normal type depending on what's smaller). I used it decide a minimum data transfer during compilation time, but I get my doubts if it's better than using const T&. Even if the resulting type is smaller, you need to invoke the template processor which's output will maybe no as optimized as const reference variant. Think about: when inlining a function, you'll probably want "directly insert" a constant reference if you only read and never change the variable or depend on a type conversion before you start the function body. So using a constant reference directly tells the compiler much more about how possibly you could insert it directly. And well a constant reference SHOULD be the optimal case: no changes made to it and theoretically no stack operation required. And what about a constant value as parameter? Looks bad. It's constant, yes, but it's a copy of the variable you got and will always be. Unless your compiler is smart enough to detect it automatically, it's still a variable to push on the stack. What is if you use the normal variable parameter for implicit type conversion? The compiler can't know it exactly, so it'll either push it a copy on the stack or insert it directly, creating something unexpected when compiling fully optimized. That's a point, eh? Also, I think of coyping something small becomes rather ineffective since you need to bitmask stuff, type conversion and so on it's an int, char or so. I learned that using the system's native word size is the most performant way t0 do operations. So if the compiler doesn't inline the function for a number of reasons, he'll simply copy an address which has the size or a word. Though you'd need to load the pointer value and then variable value... It's more work, but it's probably much more clean for optimizers to loop up. And cause I'll never again code something CPU-heavy without optimization on, I should risk it and be happy.

You can only give hints to your compiler. He still knows it better then me what to do with a large chunk of code! He knows what my computer's able to do - I do not except that I know some random Hz number, memory sizes but not much else. I didn't even knew there's a fsincos command in assembler, so I'm just a random guy beeing concerned about my code running quick and fine. In a more special sense, I'm still more some kind of videogame programmer than anything else, so I can take this as an excuse to let others do the real lowlevel optimization work.

No comments: