Presumably .Net goes to great lengths to optimise overflow-checking, as the checks are enabled for production use. I wonder if they manage to get the overhead to below the 8.7% mentioned in the article.
edit: I had put OpenJDK and .Net but tom_mellior is right to point out that Java has wrapping arithmetic
Why would OpenJDK do integer overflow checking? Java integers have well-defined two's complement wrapping semantics. When you add two positive numbers and get a negative result, this might not be what the programmer wanted, but it is not undefined behavior like it is in C.
Are you maybe mixing this up with array bounds checking?
Maybe, but LLVM has the disadvantage that speculating “this won’t overflow” and creating a fast path with that information is not something that can be fixed if more profiling data comes in at runtime saying it was a poor choice.
Those aren’t the optimizations I’m talking about. That’s not even how JSC optimizes overflow checks.
I’m talking about:
- abstract interpretation using a streamlined version of the octagon domain.
- instruction selection and register allocation hacks to emit the best possible code for checked math. I don’t think llvm has parity with B3 here, particularly in cases where inputs to the math are live on the failing case.
- probably other stuff. IRs that start out with checked math tend to include checked math reasoning in more optimizations.
> - abstract interpretation using a streamlined version of the octagon domain.
Do you have any links/source code where I can read up about this (possibly in the context of compilers)? I've never heard of the term octagon domain before.
The C/C++ standards allow compilers to do whatever they want as long as it does not cause observable output changes.
So LLVM could do runtime profiling if it wanted. But I suspect that in the majority of the cases the cost of the profiling would be worse than the potential gains.
They aren’t literally implemented as floating point in most cases. That’d be crazy! If the number fits in an integer then a sensible implementation uses an integer.
Hm - I was wondering exactly what "ud2" does when it's triggered (looks like an "undefined opcode"... causes a seg fault?), but what's worse? An app that crashes with no apparent cause, or a bank account that resets to $0 if it gets too big?
Presumably .Net goes to great lengths to optimise overflow-checking, as the checks are enabled for production use. I wonder if they manage to get the overhead to below the 8.7% mentioned in the article.
edit: I had put OpenJDK and .Net but tom_mellior is right to point out that Java has wrapping arithmetic