Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Const Doesn't Make C Code Faster

theartofmachinery.com

Post reply on HN
Print view View original

141–150 of 197 posts

Re: Why Const Doesn't Make C Code Faster

#141

Post by WalterBright »

Y_Y wrote: post #137
WalterBright wrote: post #54

Earlier quoted context omitted.

D has a `pure` attribute for functions, and yes it is enforced. It's enforced even to the point where it becomes a PITA, but when you manage to make functions pure, you know it's solid. One pain point with pure functions is you can't insert debug logging statements. D has a special case for that - purity for a statement isn't checked if it is prefixed with the `debug` keyword: pure int square(int x) { debug printf("c…

The same "trick" is especially handy in a pure-by-design language like Haskell. There you have the `trace` function which prints to stdout while pretending not to. It's similarly useful, even if it may get called zero or many times. Is the same true of D's debug?

No, in D any statement prefixed with `debug` does not get its purity checked. `debug` prefixed code is enabled via a command line switch, otherwise it is excised.

I.e. it's for conditionally inserting debugging code where you don't care about purity, you just want to find the bug.

Re: Why Const Doesn't Make C Code Faster

#142

Post by WalterBright »

mhh__ wrote: post #136
WalterBright wrote: post #127

Earlier quoted context omitted.

I did complain to the author, but the damage was done. Can't undo a magazine article. I didn't save a copy of the magazine I was so annoyed. BTW, it goes on. A couple years ago a kind soul gently suggested I implement DFA since clang had invented DFA. (No, I didn't invent DFA either, but I do believe that Datalight Optimum C was the first DFA compiler for DOS.) http://www.program-transformation.org/Transform/CCompile…

(Bottom link:) does that mean the dmd backend code dates back to the mid 80s?

Yes. That file in particular has seen little change.

Re: Why Const Doesn't Make C Code Faster

#143

Post by einpoklum »

ridiculous_fish wrote: post #40

const_cast risk is not why the compiler emits a reload. Indeed we don't even need to pass x to constFunc to get the reload: see line 7 in https://godbolt.org/z/TjmWxL Consider that `x` may point to a global variable which `something` may modify. That is why the reload is necessary. edit: I just realized that the reload would be necessary even without an intervening function call. https://godbolt.org/z/QhVzlV Consider…

You're mistaken. What you're thinking of is a pointer to a _volatile_ ; for a regular pointer, you only need one load - even if it's not a pointer-to-const. See:

https://godbolt.org/z/XWW9Nq

Re: Why Const Doesn't Make C Code Faster

#145

Post by tutfbhuf »

You should also test it with older compiler versions from the 80s/90s. There are some falsehood believes about programming now that were true some decades ago. I'm not saying that this is the case here, but it's worth to keep that in mind.

Re: Why Const Doesn't Make C Code Faster

#146

Post by mcv »

Not quite the same issue, but this reminds me of my very first job, back in 2001, where we used a homebrew C++ framework that separated lots of concerns, and then used a single massive .h file with 10,000 const uints to tie everything together.

Compiling took over 2 hours. The header was generated automatically, but after I added a macro that replaced those const uints with #defines, compile time dropped to 30 minutes, which was quickly voted the biggest productivity enhancement in that project.

More relevant to the topic, in javascript programming I recently switched to using const instead of let wherever possible. Most variables don't actually vary, so let's make that explicit. That can prevent some unexpected surprises (though not all, as objects and arrays in constants are not immutable).

Re: Why Const Doesn't Make C Code Faster

#147

Post by AstralStorm »

caf wrote: post #102
ljackman wrote: post #37

The key difference between `const` and the `register` and `inline` keywords is that, despite all of them often flagging optimisations that the compiler can often work out anyway, `const` still aids human comprehension by declaring constraints, whereas the latter two do not. It seems that interprocedure optimisations in modern compilers make a lot of const-by-reference optimisations apply even when the code is mutable…

Local constant stack values surely can be completely deterministically verified as such by the optimiser even without the `const` modifier. Only if their address doesn't escape.

The compiler will detect any attempt at taking the address of the variable (including fancy things like most inline assembly) and skip the optimization, marking it as requiring a memory location.

However, it can still cheat by rearranging the memory write or even letting linker initialize the address.

Re: Why Const Doesn't Make C Code Faster

#148

Post by boomlinde »

Buge wrote: post #108
ljackman wrote: post #37

The key difference between `const` and the `register` and `inline` keywords is that, despite all of them often flagging optimisations that the compiler can often work out anyway, `const` still aids human comprehension by declaring constraints, whereas the latter two do not. It seems that interprocedure optimisations in modern compilers make a lot of const-by-reference optimisations apply even when the code is mutable…

While specifying inline alone is useless for optimization, the inline specifier is important for another type of optimization: putting a function in a header file. If you put a function in a header file and don't mark it inline, that tends to be undefined behavior because it tends to violate the One Definition Rule, (both C and C++).

How does making the function static not solve this in C? Then the definition is local to the translation unit and there are no linkage concerns at all.

Re: Why Const Doesn't Make C Code Faster

#149

Post by WalterBright »

einpoklum wrote: post #139
WalterBright wrote: post #54

Earlier quoted context omitted.

D has a `pure` attribute for functions, and yes it is enforced. It's enforced even to the point where it becomes a PITA, but when you manage to make functions pure, you know it's solid. One pain point with pure functions is you can't insert debug logging statements. D has a special case for that - purity for a statement isn't checked if it is prefixed with the `debug` keyword: pure int square(int x) { debug printf("c…

Isn't that erroneous, in the sense that printf() has side-effects, breaking the "pure" promise?

Indeed it does break the pure promise. But it's only for debugging builds.

Re: Why Const Doesn't Make C Code Faster

#150

Post by boomlinde »

ricattierger wrote: post #138
Gibbon1 wrote: post #96

Earlier quoted context omitted.

Obviously a pure function can allocate memory on the stack. I would think it could also allocate memory on the heap, iff it was guaranteed that the memory was freed before the function exits. Was thinking that would be something the compiler would do. Forgive me I'm just a small brained firmware programmer.

So it seems that you are sort of talking about a function that is memoizable but not pure. Pure has no mutation of any global state. So hypothetically touching the heap means not pure - if somehow others can see it.

So where do we draw the line? Of course, no real computer implementation of any language is going to be able to generate fundamentally pure code because in the end they're going to be mutating memory (at the very least the program counter).

That's not a very useful distinction, and usually one talks about "purity" at a conceptual level. The language provides a layer of abstraction in which things can be considered pure (or not), even if the underlying implementation e.g. makes optimizations that require mutation. The language is just a guarantee that you can ignore these aspects of its implementation.

Post reply on HN