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

161–170 of 197 posts

Re: Why Const Doesn't Make C Code Faster

#161

Post by ljackman »

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.

By ‘constant stack value’, I was referring to ‘effectively constant’ stack values, i.e. ones who aren’t reassigned in the scope or passed by mutable reference (or indeed are but aren’t actually modified by those functions anyway if the compiler can prove it).

My phrasing was probably a bit ambiguous there.

Re: Why Const Doesn't Make C Code Faster

#164

Post by hombre_fatal »

millstone wrote: post #128
xhkkffbf wrote: post #8

I've worked with JavaScript weenies who are in love with the const declaration. They don't have an answer, though, when I ask, "Shouldn't the compiler be able to notice that a variable isn't changed in it's lifetime?" Most of the const values are just local and never leave the function but the weenies continue to stomp their feet when I use "var". The compilers are smart. Let them do their thing.

'const' in JS is 100% for readability and enables no additional optimizations above 'let'. In fact 'const' and 'let' are often worse than 'var' because of the temporal dead zone.

> In fact 'const' and 'let' are often worse than 'var' because of the temporal dead zone.

Seems like a massive overstatement. What are you even referring to as the downside?

For 99% of usecases/people, TDZ just means you get a runtime error for your use-before-declaration bugs.

The only reason I can see for using `var` is if you're doing some very confident performance hacking in a hot loop and you have the performance testing harness to prove that you're not just wasting your time.

Re: Why Const Doesn't Make C Code Faster

#165

Post by fluffything »

gpderetta wrote: post #153
pingyong wrote: post #151

Earlier quoted context omitted.

>__attribute__((const)) which tells it that the func accesses NOTHING but the params, not even global vars. If you're actually not accessing any global state at all (including making no memory allocation), shouldn't the compiler figure that out anyway? That doesn't seem like something that would be very hard to check for.

Not if it is defined in another translation unit and you are not using LTO.

In other words, the compiler can infer this from the function definition (or at least clang does), but it cannot infer this from a function declaration, because the implementation is missing - unless you are using LTO like the parent mentions.

Re: Why Const Doesn't Make C Code Faster

#166

Post by amalcon »

einpoklum wrote: post #143
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

I think you're talking past each other. Grandparent is examining the case where there is a function call (the printf), but you do not pass anything relevant into it. You're looking at the case where there is no function call, so peephole optimization can observe that the memory at that location can't change.

"volatile" basically tells the compiler "Hey, wait, this might be modified by DMA, another thread, or another process. Assume nothing."

Re: Why Const Doesn't Make C Code Faster

#167

Post by bstamour »

rrss wrote: post #118
bstamour wrote: post #110

Earlier quoted context omitted.

If the initial object itself isn't const, then merely declaring the function parameter as a pointer to const won't guarantee that some other thread of execution won't change the value under your nose. Or if you have multiple pointer parameters, they can alias each other. Indirection in C and C++ is a mess, but at least C has the "restrict" keyword. Best to program with value types whenever you can, and use pointers a…

> won't guarantee that some other thread of execution won't change the value under your nose My understanding is that compilers can always assume that there is no other thread involved, which (part of) why C11 atomics are necessary. Is that not the case?

You're right, but what I meant about it was that just because the variable is const, doesn't mean it can't change from somewhere else between reads. Even if you use synchronization to avoid data races, if you read the pointer to const twice in the function, it could change between the reads.

Re: Why Const Doesn't Make C Code Faster

#168

Post by SAI_Peregrinus »

bstamour wrote: post #167
rrss wrote: post #118

Earlier quoted context omitted.

> won't guarantee that some other thread of execution won't change the value under your nose My understanding is that compilers can always assume that there is no other thread involved, which (part of) why C11 atomics are necessary. Is that not the case?

You're right, but what I meant about it was that just because the variable is const, doesn't mean it can't change from somewhere else between reads. Even if you use synchronization to avoid data races, if you read the pointer to const twice in the function, it could change between the reads.

The most common example of that is probably a const volatile variable for the input data register of some peripheral. New data can come in at any time, and writes do nothing.

Re: Why Const Doesn't Make C Code Faster

#169

Post by stephc_int13 »

will4274 wrote: post #104
stephc_int13 wrote: post #97

I once had a very stubborn intern who decided to add as much const as he could in our codebase. What followed was a heated discussion and I did a global replace of const by nothing. The main problem with const is that it's ugly, it's viral and it does not add any value to the code. And I know all the supposedly good things about this, but I never found any real usage in practice.

You should fire yourself. Seriously. Understanding which object parameters to a function are inputs and which ones are modified is key information about the behavior of a function. It's omission requires devs to divine the intent from the name and hope that every previous dev was a good citizen w.r.t keeping function names accurate to intent. Finding and replace const with empty is the moral equivalent of replacing a…

I strongly disagree, obviously. Using const to document code might seems like a good idea in some organizations, with extremely large codebase, I don't know.

But first, when you're an intern, you have to follow the local codestyle, even if you think it's not ideal.

Second, I think there are much better rules than spamming const to attain the same objective, but you might need more experience to really appreciate that.

Re: Why Const Doesn't Make C Code Faster

#170

Post by boomlinde »

DagAgren wrote: post #156
boomlinde wrote: post #148

Earlier quoted context omitted.

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.

Static but not inline functions will trigger warnings of unused functions. Static and inline does not trigger this.

> Static but not inline functions will trigger warnings of unused functions.

Well, isn't it true? It's true also in the inline case. I consider it strange behavior not to emit an explicitly enabled warning for a case that definitely satisfies the warning conditions.

> Static and inline does not trigger this.

Tried -Wunused-function in gcc 6.3.0 and clang 3.8.1-24, with an unused-but-defined function declared "static inline int add(int a, int b)". clang still emits the warning, gcc does not.

If you're already dependent on whatever additional semantics gcc tacked onto the inline keyword you can as well use "__attribute__((unused))" to disable the warning for a particular function, which more clearly communicates the intent to disable the warning.

Post reply on HN