the situation is even worse with ELF dynamic libraries due to the interaction of two rules: a) by default, all functions are exported, and b) by default, all functions can be interposed, e.g. by LD_PRELOAD. here, if you specify -fPIC in the compilation arguments (as is required to produce a modern dynamic library), inlining is totally disabled. for small functions, the call overhead can be substantial.
When static makes your C code 10 times faster
51–60 of 113 posts
Re: When static makes your C code 10 times faster
#52Really wish it was the default.
Re: When static makes your C code 10 times faster
#53If I could travel back in time I'd tell Dennis to make "static" the implicit default, and have a special keyword like "public" or "export" for items that are meant to be accessible from outside the compilation unit. I'd also ask him to make "switch" break by default. Then I'd go kill Hitler or something.
Re: When static makes your C code 10 times faster
#54you can tell how much low-level optimisation they have done if they think its gonna change codegen reliably, or at ll.
Re: When static makes your C code 10 times faster
#55the use of static is just a tool to inform the compiler that the value is a constant (which const /might/)
Re: When static makes your C code 10 times faster
#56I agree with many of the sibling comments, static vs. non-static is almost a complete red-herring. Static only means that the variable is local to the translation unit (the C file). The relevant difference in the example is actually the const-ness of the variable, which you may put explicitly, but which a powerful compiler can also infer here in the static case. Other than this optimization possibility, const and sta…
const doesn't do this thanks to const_cast etc. maybe things have changed, but const on a file level variable doesn't do this reliably, or at least hasn't for considerable lengths of time.
of course 'static const' is the better answer. :)
Re: When static makes your C code 10 times faster
#57I think a simple “const” would have also done the trick. Sometimes -O3 is clever enough to figure out that the value is never written, so it makes it an asm constant.
Re: When static makes your C code 10 times faster
#58When the compiler can assume your values don't change magically, it can optimize their use.
This is true for restricted pointers, for global-scope variables which can only be accessed in the same translation unit, for stuff in inlined functions (often), etc.
--------------------------------------------
const is a bit shifty. const makes the compiler restrict what it allows you to write, but it can still not really assume other functions don't break constness via casting:
void i_can_change_x_yeah_i_can_just_watch_me(const int* x)
{
*(int*) x = x + 1;
}
now, if the compiler sees the code, then fine (maybe), but when all you see is: void sly(const int* x);
You can't assume the value pointed to by x can change. See this on GodBolt: https://godbolt.org/z/fGEMj9Meoand it could well be the same for constants too. But somehow it isn't:
Re: When static makes your C code 10 times faster
#59Const / static allows for "immediate" ASM instruction generation: which means the value is known at compile time so it can compare it directly inline as opposed to the overhead of comparing it to a labeled memory address. It's generally good practice whenever possible.
static doesn't imply the value can be known, only in some cases where its not modified in that compilation unit (which is trivial to detect with SSA)
const is something else.
Re: When static makes your C code 10 times faster
#60really? people mentioned const? you can tell how much low-level optimisation they have done if they think its gonna change codegen reliably, or at ll.