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

21–30 of 197 posts

Re: Why Const Doesn't Make C Code Faster

#21

Post by eterm »

archgoon wrote: post #13
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 is primarily for documentation to indicate that the assignment happens only once and won't be redefined. Using 'let' or 'var' indicates to the reader that the variables value will be reassigned in the function. It's not about the compiler.

Also let/const don't get hoisted to the start of the function, declaration using var does.

Re: Why Const Doesn't Make C Code Faster

#22

Post by vizzier »

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.

I've not seen this as the basis for the default usage of const over var (or let) in javascript. The primary reason that I'm aware of is that if you use const by default, the compiler will tell you if you accidentally re-define the value of a variable. Possibly because people feel that immutability by default reduces error frequency, though I don't have any data to back up that assertion.

Re: Why Const Doesn't Make C Code Faster

#23

Post by chrisseaton »

vortico wrote: post #15
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.

Actually no, compilers can't assume that `foo` is const. var foo = 0; eval("foo = 1"); With that said, virtually nobody uses `const` for performance reasons, but for developer readability and avoiding mistakes.

> Actually no, compilers can't assume that `foo` is const.

They can assume it, they just need to be able to reverse that assumption if you do change it through something like eval. This is called 'speculative optimisation' and we use it to optimise languages like JavaScript, Ruby, Python, etc.

Re: Why Const Doesn't Make C Code Faster

#24

Post by saagarjha »

not2b wrote: post #18

Unfortunately 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…

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?

Re: Why Const Doesn't Make C Code Faster

#25

Post by badsectoracula »

> So most of the time the compiler sees const, it has to assume that someone, somewhere could cast it away, which means the compiler can’t use it for optimisation. This is true in practice because enough real-world C code has “I know what I’m doing” casting away of const.

Some years ago i'd agree, but experience has shown that C/C++ compiler writers would rather win benchmark games than keep working code working. So it'd be nice if there was a better reason than "well, a lot of code would break if they did that".

Re: Why Const Doesn't Make C Code Faster

#26

Post by Ididntdothis »

EpicEng wrote: post #6
Ididntdothis wrote: post #5

I have done a lot of profiling work and I have observed similar things. One thing is const, another is virtual functions. A lot of people think they add overhead and avoid them for performance reasons but my profiling almost never showed them as a problem. Same for const and inline. it’s really hard to predict what the optimizer will do. Obviously there are stupid things that can be avoided from the start but in gene…

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....

Re: Why Const Doesn't Make C Code Faster

#27

Post by echelon »

wnevets wrote: post #11
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 doesn't actually stop data from changing, just reassignment. const user = {id: 1, status: 'active'}; user.status = 'disabled'; is valid javascript

Which is to say that the const pointer itself doesn't change. It doesn't impose any constraints on the values of any underlying data structures.

Javascript could use some proper immutable types.

Re: Why Const Doesn't Make C Code Faster

#28

Post by aflag »

badsectoracula wrote: post #25

> So most of the time the compiler sees const, it has to assume that someone, somewhere could cast it away, which means the compiler can’t use it for optimisation. This is true in practice because enough real-world C code has “I know what I’m doing” casting away of const. Some years ago i'd agree, but experience has shown that C/C++ compiler writers would rather win benchmark games than keep working code working. So…

I think the point is that correct code could break.

Re: Why Const Doesn't Make C Code Faster

#30

Post by [deleted] »

chrisseaton wrote: post #23
vortico wrote: post #15

Earlier quoted context omitted.

Actually no, compilers can't assume that `foo` is const. var foo = 0; eval("foo = 1"); With that said, virtually nobody uses `const` for performance reasons, but for developer readability and avoiding mistakes.

> Actually no, compilers can't assume that `foo` is const. They can assume it, they just need to be able to reverse that assumption if you do change it through something like eval. This is called 'speculative optimisation' and we use it to optimise languages like JavaScript, Ruby, Python, etc.

[deleted]
Post reply on HN