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

181–190 of 197 posts

Re: Why Const Doesn't Make C Code Faster

#181

Post by dmitrygr »

einpoklum wrote: post #140
dmitrygr wrote: post #44

Earlier quoted context omitted.

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: https://godbolt.org/z/v2zqJI https://godbolt.org/z/kk3Q3T

> You can even promise a func is pure without even implementing it in the same translation unit! Actually that's the main point, as if it's in the same TU, the compiler can probably figure out a function is pure.

often but not always, for example a function using asm() to access, say, some AES intrinsics is pure (const even) since the output only depends on input, but oftentimes compiler by itself will not declare a function with an asm() block pure or const

Re: Why Const Doesn't Make C Code Faster

#182

Post by einpoklum »

dmitrygr wrote: post #181
einpoklum wrote: post #140

Earlier quoted context omitted.

> You can even promise a func is pure without even implementing it in the same translation unit! Actually that's the main point, as if it's in the same TU, the compiler can probably figure out a function is pure.

often but not always, for example a function using asm() to access, say, some AES intrinsics is pure (const even) since the output only depends on input, but oftentimes compiler by itself will not declare a function with an asm() block pure or const

Well, fair point, but - compilers shouldn't be that lazy :-)

Re: Why Const Doesn't Make C Code Faster

#183

Post by marcinjachymiak »

icedchai wrote: post #172
will4274 wrote: post #104

Earlier quoted context omitted.

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…

With "const" you still need to rely on devs being good citizens since const can be trivially casted away. I've been programming in C for 25+ years. const is clutter.

Don't let consts get "trivially" casted away in code review. If something is no longer const than remove the keyword, or find another way to solve your problem

Re: Why Const Doesn't Make C Code Faster

#184

Post by gpderetta »

saagarjha wrote: post #177
gpderetta wrote: post #157

Earlier quoted context omitted.

AFAIK placement new does launder. But both new and launder have no effect on their argument (well, placement new of course constructs an object there), they only 'bless' pointer returned from it. The use case is if you placement new on some byte storage. Now you want to access the object stored there, and of course you do not want to placement new the storage again, nor you have cached the result of the previous plac…

> AFAIK placement new does launder. But both new and launder have no effect on their argument (well, placement new of course constructs an object there), they only 'bless' pointer returned from it. I may be misunderstanding, but this seems to directly contradict what the linked paper says: > Note that std::launder() does not “white wash” the pointer for any further usage. > The obvious question is, why don’t we simpl…

Because the placement new might have been called in a other translation unit for example so the compiler can't track the it.

Re: Why Const Doesn't Make C Code Faster

#185

Post by Gibbon1 »

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.

Rolling it over I think vaguely along the idea that marking a function as pure is a contract that tells the compiler that the function and it's call tree ultimately shouldn't modify external state.

A function that allocates memory isn't pure, except perhaps iff it frees that memory either itself or by compiler magic. Then perhaps it is.

Re: Why Const Doesn't Make C Code Faster

#186

Post by gpderetta »

dmitrygr wrote: post #180
fluffything wrote: post #165

Earlier quoted context omitted.

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.

sometimes it cannot infer it even from function, for example, here is a function that in my particular OS gets me a pointer to my library's globals. To my code the returned pointer never changes, but the compiler has NO way to tell this function is const without my annotation void* __attribute__((const)) getGlobals(void) { void* ret; asm ( " ldr %0, [r9] \n" " ldr %0, [%0, %1] \n" : "=r"(ret) : "I"(MY_MODULE_ID) : );…

Good point.

Re: Why Const Doesn't Make C Code Faster

#187

Post by will4274 »

icedchai wrote: post #172
will4274 wrote: post #104

Earlier quoted context omitted.

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…

With "const" you still need to rely on devs being good citizens since const can be trivially casted away. I've been programming in C for 25+ years. const is clutter.

> const can be trivially casted away.

Yes, types can be trivially casted away too. That's not a reason to use void* everywhere.

Re: Why Const Doesn't Make C Code Faster

#188

Post by will4274 »

stephc_int13 wrote: post #169
will4274 wrote: post #104

Earlier quoted context omitted.

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…

> Second, I think there are much better rules than spamming const to attain the same objective

Like?

> you might need more experience to really appreciate that.

Practically a picture perfect appeal to authority.

Re: Why Const Doesn't Make C Code Faster

#189

Post by daemin »

Buge wrote: post #176
daemin wrote: post #171

Earlier quoted context omitted.

Force inlining code is actually quite a useful optimisation still. We have found many instances that after a few inline functions the compiler gives up and just calls the function instead. Force inlining certain low level functions has actually improved performance by several percent in our codebase.

From the language standpoint, the inline specifier doesn't force the compiler to inline the function. But I guess some compilers could provide guarantees that go beyond what the spec says.

I was talking about __forceinline for MSVC and things like it for other compilers. One's which for better or worse will make your function inlined.

One thing that I did find out what that even if you inline or force inline a function, that if you have it exported from a DLL or in a class that is exported as a DLL, then the function might still be called non-inline.

Re: Why Const Doesn't Make C Code Faster

#190

Post by BubRoss »

sdinsn wrote: post #178
BubRoss wrote: post #63

Earlier quoted context omitted.

I would say that's unlikely. SIMD instructions don't usually get used by normal compilers without very specific loops that make sure there are no obstacles to vectorization. Also the best way to use SIMD is to loop through a large array of two and do very simple operations with them. Modern CPUs actually have three (I think) floating point slots so their total floating point throughput isn't simply a fraction of the…

> SIMD instructions don't usually get used by normal compilers without very specific loops Compilers are smart. Even Java's JIT will generate SIMD instructions pretty well

I would have to see this to believe it. Even Intel's own compiler is extremely sensitive to small changes turning off SIMD use in a loop. You can try out compilers and see their asm at godbolt.org
Post reply on HN