But actually it's not even zero-cost if you remove all those things. It's hypothetical zero-cost is only if you assume that the compiler does a perfect job of trading off between "commonizing" and specializing the monomorphs, which no compiler does.
-
-
Replying to @cmuratori @Jonathan_Blow and
Because actually what happens is that the compiler usually overspecializes, producing specialized versions for every possible morph, rather than parameterizing some in ways that are free to do in asm (like with register instead of immediate offsets).
1 reply 0 retweets 3 likes -
Replying to @cmuratori @Jonathan_Blow and
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.
1 reply 0 retweets 4 likes -
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
That analogy makes sense to me. Indeed, in C++, "zero cost" usually means "you couldn't have written better C++ by hand", not "you couldn't have written better assembly by hand".
1 reply 0 retweets 0 likes -
Replying to @BatmanAoD @Jonathan_Blow and
Again, just to be clear, _you could_ have written better C++ by hand. That was the point of the monomorphization - what the compiler generates is not as good as if you have manually written what you wanted, because you can make better "commonization" tradeoffs.
1 reply 0 retweets 0 likes -
Replying to @cmuratori @BatmanAoD and
"Zero cost" is literally just false. It's not true that it's zero cost over C++, and it's not true that it's zero cost over asm. It's just plain wrong. Things should just be called abstractions, never "zero cost" abstractions because they aren't, and that's that.
2 replies 1 retweet 2 likes -
Replying to @cmuratori @Jonathan_Blow and
That's an extremely interesting claim. I have no idea how to evaluate it, though; would you recommend just comparing the assembly generated by template-heavy code to some hand-written code doing the same thing? Do you have an example of a specific resource you could point me to?
1 reply 0 retweets 0 likes
Not to beat a dead horse, but evaluating my claim that there _aren't_ "zero cost abstractions" is also approaching the problem the wrong way around. Shouldn't the goal be to evaluate the _original_ claim that there _are_ zero cost abstractions?
-
-
Replying to @cmuratori @BatmanAoD and
One thing you will notice if you look at it, is that basically nobody who claims to provide a "zero cost abstraction" ever offers any proof that it is. They just say something like "and the compiler can do it" and that's it. But where is the evidence? Where are the case studies?
1 reply 1 retweet 6 likes -
Replying to @cmuratori @BatmanAoD and
The onus shouldn't be on people to prove that something _isn't_ "zero cost", it should be on the people claiming it's "zero cost" to prove that it _is_, right? And that proof is nowhere to be found.
1 reply 0 retweets 8 likes - Show replies
New conversation -
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.