On some microcontrollers, marking variables/arrays as const allows the compiler to access them directly from flash rather than having to copy them into RAM at startup.
I used this to great effect on a PIC24 with 256KB flash/16KB RAM.
Why Const Doesn't Make C Code Faster
41–50 of 197 posts
Re: Why Const Doesn't Make C Code Faster
#42Earlier quoted context omitted.
The fact that std::launder ( https://en.cppreference.com/w/cpp/utility/launder ) exists blows my mind. Like, why is this a thing that the standard allows?
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p053... has an explanation. In short, placement new (or some scenarios involving unions) technically cause undefined behavior if you try to use the object after the call to placement new, since the pre-existing object there has had its lifetime expire. std::launder lets you use a pre-existing pointer to the memory at the same location to access the data there.
Yes, I know what std::launder does, and that document contains some of my own thoughts: namely, placement new (the only use I've seen suggested) should automatically launder, and std::launder should just not exist.
Re: Why Const Doesn't Make C Code Faster
#43I hardly ever bother optimizing my code anymore, with -O3 nothing I do ever really seems to make a difference. The real reason to use "const" is to show intent. See "Const and Rigid Parameters" in this wonderful article about the Doom 3 source code: https://kotaku.com/the-exceptional-beauty-of-doom-3s-source-...
> I hardly ever bother optimizing my code anymore, with -O3 nothing I do ever really seems to make a difference.
Your choice of data structure or algorithm would…
Re: Why Const Doesn't Make C Code Faster
#44gcc has some attributes to help with that, for example try __attribute__((pure)) on funcs that will always return the same thing for the same inputs (given the same global state) and do not modify said input or state (and thus can be called more or fewer times than programmer wrote). Usually gcc will be quite aggressive with optimizations if you use that. For even more aggressiveness, try __attribute__((const)) which…
Does it enforce these attributes or are they just a promise by the code author?
They are a promise and that is precisely what makes them powerful. It gives GCC info it might not be able to derive, but you know to be true.
You can even promise a func is pure without even implementing it in the same translation unit! That produces lots of improvement. See these two godbolt links:
Re: Why Const Doesn't Make C Code Faster
#45Unfortunately in C++, the compiler is not allowed to assume that if it passes a const reference to a function, that function will not change the object. The function is allowed to cast away const and modify the object. I'm not happy that they did it that way; I would have preferred it if cast-away-const were more restricted (for example, allowed when calling a child function that takes a char* but doesn't modify the…
I find it awesome that you can do that, the extra flexibility is great, e.g. when you're working with const char* arrays, sometimes, you need to create a copy of that char array, but save its pointer (char* ) in a (const char* ) variable, but you're still going to need to delete that copy later... and then you're glad that you can simply recast a (const char* ) into (char* ).
I save the data of whether or not it's a copy into a flag variable, so my program knows when and when not to delete a const char* .
The alternative would be of course to create a two variables, one char* and one const char* , but that would double the memory needed, but only one type of variable would be used at a time.
Re: Why Const Doesn't Make C Code Faster
#46Many laws exist that express the intent of a law-making body but are either unenforceable or too expensive to enforce in any meaningful way. Perhaps the const declaration in C is an example of this type of law.
In contrast, a Standard ML compiler can enforce this law because the language itself insists that all bindings are immutable.
Re: Why Const Doesn't Make C Code Faster
#47This assumes that the compiler can actually infer that a const-by-reference isn't modified.
The second we have indirection (function pointers), or a different source file without whole-program-optimization, or a library, these assumptions break down.
Further, the author assumes that the compiler can't benefit from the knowledge that something is const because the const can be cached away. This isn't true, e.g. per ISO9899 6.7.3.5:
If an attempt is made to modify an object defined with a const-qualified type through use of an lvalue with non-const-qualified type, the behavior is undefined. If an attempt is made to refer to an object defined with a volatile-qualified type through use of an lvalue with non-volatile-qualified type, the behavior is undefined.
Re: Why Const Doesn't Make C Code Faster
#48I hardly ever bother optimizing my code anymore, with -O3 nothing I do ever really seems to make a difference. The real reason to use "const" is to show intent. See "Const and Rigid Parameters" in this wonderful article about the Doom 3 source code: https://kotaku.com/the-exceptional-beauty-of-doom-3s-source-...
> I hardly ever bother optimizing my code anymore, with -O3 nothing I do ever really seems to make a difference. Your choice of data structure or algorithm would…
Yes, true, though I consider that "structural/procedural" optimization as opposed to "technical" optimization.
This means, I won't bother using "inline" anymore, but I will consider how many subfunctions in total I'd call.
Re: Why Const Doesn't Make C Code Faster
#49> This is true in practice because enough real-world C code has “I know what I’m doing” casting away of const.
I found this out the hard way when I implemented OptimumC, the first data flow analysis optimizer for DOS C compilers back in the 1980's.
I had to undo doing optimizations on const.
Anecdote: Optimum C blew away all the other C compilers on a magazine benchmark article because it figured out that the benchmark code did nothing and deleted it. The author didn't ask me about it, he just assumed the compiler was buggy and gave us a bad review. Sigh.
When other compilers did DFA, the benchmarks got changed.
Re: Why Const Doesn't Make C Code Faster
#50Earlier quoted context omitted.
Yes, profile. Anecdotally, I once removed a number of virtual function calls as they were imposing significant overhead in a tight loop (image processing). Would that be the case today? No idea; I'd have to measure it again.
Image processing is a different beast. A lot of subtle things are in play here. I remember getting big improvements by iterating through the images buffer either line vs row or even arranging memory in 64 byte squares instead of linear. I was often surprised when I looked at the optimized assembly. Optimizer are really clever and do a lot of surprising things....
Yes: row traversal (no hopping around in memory and causing cache flushes) and block size reads/writes are a big deal. Luckily they're easy enough to do right every time once you know. I used to take some flak from the "premature optimization blah blah" side of the house on occasion.