3 ms·

It's an interesting article but I am not a fan of some of the self contradiction. On the one hand the article states that jo operations are no big deal, the CPU

by Kranar 5y ago

It's an interesting article but I am not a fan of some of the self contradiction. On the one hand the article states that jo operations are no big deal, the CPU can pipeline it and execute it cheaply, but on the other hand, removing them results in code that runs twice as fast. Another detail I think is important is that injecting the stamp is not the same as writing a proof and informing the compiler that some property is true. You're doing what other languages would call an unsafe operation and asserting that something is true. Providing a proof would be interesting and some languages do have the ability to express such proofs (a static type system is one way, among others). That said, it's still interesting to see details about how to get a dynamic language like Ruby to extract some static properties from the source code. I did some work on this at Microsoft when they were working on IronPython, it's definitely challenging stuff. At the time the consensus was that the pay-off wasn't worth it, it ends up being a lot of work to extract very small guarantees and that one is almost certainly better off off-loading performance related code to C# (or C in the case of CPython). But that was 15 years ago, it's nice to see progress being made.

fulafel 5y ago
Re the unexpected jo effect, it's covered but left a mystery: > Didn’t we say that jo didn’t add much of an impact? Well that’s what I was always taught - maybe I should reconsider that and measure it a bit more.
chrisseaton 5y ago
Yes the cost of the jo is not what people seem to conventionally think and teach. I don’t have an explanation yet. Maybe the scheduling is much better without it as it’s trying to run the overflow checks as fixed control flow otherwise? I was also expecting to be writing about how removing overflow checks enables multiple arithmetic operations to be selected into single LEA instructions using addressing modes, as that’s the other common wisdom, but I couldn’t get the instruction selector to do that. Don’t know why yet either. And the injection isn’t the proof - the mask was the proof. The injection is to see if we can do it without the actual mask instruction if we cared about that. You’re right it’s unsafe - I have an example of the failure mode of abusing it in the article. Turns out we didn’t need it in this case anyway as it’s the same performance.
masklinn 5y ago
> On the one hand the article states that jo operations are no big deal It states that as the conventional wisdom, very explicitely, and before going any further already states that it will hinder further optimisations (because the arithmetics operations can’t be merged / fused).

by Kranar 5y ago

fulafel 5y ago

Re the unexpected jo effect, it's covered but left a mystery: > Didn’t we say that jo didn’t add much of an impact? Well that’s what I was always taught - maybe I should reconsider that and measure it a bit more.

chrisseaton 5y ago

Yes the cost of the jo is not what people seem to conventionally think and teach. I don’t have an explanation yet. Maybe the scheduling is much better without it as it’s trying to run the overflow checks as fixed control flow otherwise? I was also expecting to be writing about how removing overflow checks enables multiple arithmetic operations to be selected into single LEA instructions using addressing modes, as that’s the other common wisdom, but I couldn’t get the instruction selector to do that. Don’t know why yet either. And the injection isn’t the proof - the mask was the proof. The injection is to see if we can do it without the actual mask instruction if we cared about that. You’re right it’s unsafe - I have an example of the failure mode of abusing it in the article. Turns out we didn’t need it in this case anyway as it’s the same performance.

masklinn 5y ago

> On the one hand the article states that jo operations are no big deal It states that as the conventional wisdom, very explicitely, and before going any further already states that it will hinder further optimisations (because the arithmetics operations can’t be merged / fused).