Really the core concept here that needs to be understood is anything that is not supervised by an expert is probably being done less efficiently than it should be. "Zero cost" is just not a good term. It's never zero cost. We could have a different term, surely.
-
-
Replying to @cmuratori @Jonathan_Blow and
But the term "zero cost" should be retired because it gives people (especially those that don't know how to look at compiler output!) a false sense of security that they are not creating inefficient programs by employing a particular feature, when often times they actually are.
1 reply 0 retweets 5 likes -
Replying to @cmuratori @Jonathan_Blow and
It doesn't necessarily mean they should do that, because maybe they don't have time / aren't capable of / etc. doing the optimal thing. But there's a difference between _choosing_ to make inefficient code, and _not knowing_ you made inefficient code.
1 reply 1 retweet 15 likes -
Replying to @cmuratori @Jonathan_Blow and
Yet another way to say it would be to say that "zero cost abstractions" are often "zero cost" in the same way that watching a movie on Netflix is "zero cost". It's only "zero cost" if you don't count the $15/mo subscription fee, the fact that the selection is limited, etc.
2 replies 2 retweets 8 likes -
Replying to @cmuratori @Jonathan_Blow and
We all understand that watching a movie on Netflix isn't "zero cost", but we don't all understand that using various modern language features isn't "zero cost", and we should. That's all.
1 reply 0 retweets 14 likes -
Replying to @cmuratori @Jonathan_Blow and
An example of this: Someone tried this with rust (Which claims to have zero cost abstractions), found a bug in the compiler where a case is NOT zero cost https://www.joshmcguigan.com/blog/cost-of-indirection-rust/ … causing a substantial performance degradation (2x slower, seemingly due to cache misses)
2 replies 0 retweets 1 like -
Replying to @ArtirKel @cmuratori and
The discussion above is about whether lambdas _can be_ implemented in a way that is not "complex and slow", or if the abstraction itself is _inherently_ "complex and slow". Compiler bugs are bad, obviously, but don't answer this question one way or the other.
0 replies 0 retweets 2 likes -
This Tweet is unavailable.
-
Replying to @Jonathan_Blow @ArtirKel and
No disagreement there! But to take that into account, I think one would need to determine empirically which abstractions are a significant source of compiler bugs that could otherwise have been avoided. In this specific case, digging a bit deeper...
1 reply 0 retweets 1 like -
This Tweet is unavailable.
This is a really important point that is often overlooked. Optimizer complexity is combinatoric in many ways - you can't just say "well this thing is zero cost in isolation", because it may _not_ be zero cost when combined with something else.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.