No, they can't. To this day I still see compilers routinely screw up register allocation on code close or at the register limit. It is often not "zero cost", and that is why "zero cost" is a very bad term. It should be called "occasionally zero cost".
-
-
Replying to @cmuratori @BatmanAoD and
And similarly, the fact that people think that register allocation is "zero cost" is another good example of why that phrase is bad. People should understand that there are currently either no or almost no truly "zero cost" abstractions.
1 reply 0 retweets 3 likes -
Replying to @cmuratori @BatmanAoD and
Many (all?) the things they think are free actually aren't free at all.
1 reply 0 retweets 1 like -
Replying to @cmuratori @mttkay and
I don't have experience actually writing assembly, but I can imagine there being cases where a human can hand-optimize register allocation better than some specific compiler, sure. So, to take a different example: what about generic monomorphization? Isn't that "free" at runtime?
1 reply 0 retweets 0 likes -
Replying to @BatmanAoD @cmuratori and
(...since it happens at compile time?) I.e., a monomorphized function call is equivalent to a non-polymorphic function call. So that seems truly zero-cost.
0 replies 0 retweets 0 likes -
This Tweet is unavailable.
-
Replying to @Jonathan_Blow @BatmanAoD and
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.
1 reply 0 retweets 4 likes -
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
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.
-
-
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 - 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.