5 ms·

> apparently that isn't an issue on JS, Java and .NET JITs in adopting more modern architectures. I think it'd be an issue irrespective of the architecture? Op

> apparently that isn't an issue on JS, Java and .NET JITs in adopting more modern architectures. I think it'd be an issue irrespective of the architecture? Optimizations are generally expected to preserve semantics and those languages all specify IEEE 754 semantics which aren't necessarily associative. For instance, from the Java language spec [0]: > Floating-point arithmetic is carried out in accordance with the rules of the IEEE 754 Standard, including for overflow and underflow (§15.4), with the exception of the remainder operator % (§15.17.3). Or the .NET reference [1]: > The Double type complies with the IEC 60559:1989 (IEEE 754) standard for binary floating-point arithmetic. Or the ECMAScript 2027 spec [2]: > Numeric operators such as +, ×, =, and ≥ refer to those operations as determined by the type of the operands. [] When applied to Numbers, the operators refer to the relevant operations within IEEE 754-2019. [0]: https://docs.oracle.com/javase/specs/jls/se26/jls26.pdf https://docs.oracle.com/javase/specs/jls/se26/jls26.pdf [1]: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/types https://learn.microsoft.com/en-us/dotnet/csharp/language-ref... [2]: https://tc39.es/ecma262/#sec-mathematical-operations https://tc39.es/ecma262/#sec-mathematical-operations

pjmlp 2mo ago
Regardless, those optimisations are available on the respective JITs. RyuJIT target CPU modes, breaking change due to dropping support for older hardware, https://github.com/dotnet/docs/issues/48045 https://github.com/dotnet/docs/issues/48045 > Native Image now targets x86-64-v3 architecture by default on AMD64 and provides a new -march option to specify target compatibility. Use -march=compatibility for best compatibility or -march=native for best performance if a native executable is deployed on the same machine or on a machine with the same CPU features. To list all available machine types, use -march=list. https://www.graalvm.org/release-notes/JDK_20 https://www.graalvm.org/release-notes/JDK_20
- aw1621107 2mo ago
  > those optimisations are available on the respective JITs. I'd assume they aren't applied by default and/or without the programmer explicitly opting in to those altered semantics, though. Would you be able to show otherwise? I don't see how changing targeted instruction sets is relevant here as the instructions you use is orthogonal to whether you assume floating point operations are associative.
  - pjmlp 2mo ago
    I pasted the links for a reason.
    - aw1621107 2mo ago
      Neither of those appear to say anything about treating floating point operations as associative nor reordering them as a standard optimization, let alone allowing the programmer to opt into such an optimization.
- afdbcreid 2mo ago
  > Regardless, those optimisations are available on the respective JITs. I'm pretty sure this is wrong. No JS engine, RyuJIT or or HotSpot break IEE-754. Java does have intrinsics for algebraic floating point operations (but does not apply them by default and I don't think they're exposed), the other I don't think.
  - pjmlp 2mo ago
    I linked the documentation....
    - afdbcreid 2mo ago
      I'm not sure what you tried to prove by those docs, but they don't say that they deviate from IEEE-754.
  - jcranmer 2mo ago
    I did a deep dive a while back into the floating-point semantics of many languages, included JIT'd languages, which mostly uncovers that very few languages are particularly precise in their specification. The tl;dr for the relevant languages here is: * Java requires full IEEE 754 conformance (and bounds ULPs on java.lang.Math functions, although not fully correctly-rounded), although (now removed) strictfp permitted a slightly more relaxed mode to make it easier to implement using x87 FPU arithmetic. * C# has license for excess precision mode and denormal flushing. * JS is strict IEEE 754 conformance, except for math library functions (which can be more approximate). * Go permits FMA contraction (but is otherwise silent). * Most other interpreted/JIT'd languages pretty much go "you get your machine floating-point." And, FWIW, all of those floating-point semantics are orthogonal to things enabled by -ffast-math or similar flags! The only languages that really discuss such things are C (in a TS nobody implements), Fortran (which lets you rearrange expressions as long as you preserve parentheses), Julia (which has a fast_fma-like function and a fast-math macro), and now Rust.
    - memming 2mo ago
      @fastmath in Julia!

pjmlp 2mo ago

Regardless, those optimisations are available on the respective JITs. RyuJIT target CPU modes, breaking change due to dropping support for older hardware, https://github.com/dotnet/docs/issues/48045 https://github.com/dotnet/docs/issues/48045 > Native Image now targets x86-64-v3 architecture by default on AMD64 and provides a new -march option to specify target compatibility. Use -march=compatibility for best compatibility or -march=native for best performance if a native executable is deployed on the same machine or on a machine with the same CPU features. To list all available machine types, use -march=list. https://www.graalvm.org/release-notes/JDK_20 https://www.graalvm.org/release-notes/JDK_20

aw1621107 2mo ago
> those optimisations are available on the respective JITs. I'd assume they aren't applied by default and/or without the programmer explicitly opting in to those altered semantics, though. Would you be able to show otherwise? I don't see how changing targeted instruction sets is relevant here as the instructions you use is orthogonal to whether you assume floating point operations are associative.
- pjmlp 2mo ago
  I pasted the links for a reason.
  - aw1621107 2mo ago
    Neither of those appear to say anything about treating floating point operations as associative nor reordering them as a standard optimization, let alone allowing the programmer to opt into such an optimization.
afdbcreid 2mo ago
> Regardless, those optimisations are available on the respective JITs. I'm pretty sure this is wrong. No JS engine, RyuJIT or or HotSpot break IEE-754. Java does have intrinsics for algebraic floating point operations (but does not apply them by default and I don't think they're exposed), the other I don't think.
- pjmlp 2mo ago
  I linked the documentation....
  - afdbcreid 2mo ago
    I'm not sure what you tried to prove by those docs, but they don't say that they deviate from IEEE-754.
- jcranmer 2mo ago
  I did a deep dive a while back into the floating-point semantics of many languages, included JIT'd languages, which mostly uncovers that very few languages are particularly precise in their specification. The tl;dr for the relevant languages here is: * Java requires full IEEE 754 conformance (and bounds ULPs on java.lang.Math functions, although not fully correctly-rounded), although (now removed) strictfp permitted a slightly more relaxed mode to make it easier to implement using x87 FPU arithmetic. * C# has license for excess precision mode and denormal flushing. * JS is strict IEEE 754 conformance, except for math library functions (which can be more approximate). * Go permits FMA contraction (but is otherwise silent). * Most other interpreted/JIT'd languages pretty much go "you get your machine floating-point." And, FWIW, all of those floating-point semantics are orthogonal to things enabled by -ffast-math or similar flags! The only languages that really discuss such things are C (in a TS nobody implements), Fortran (which lets you rearrange expressions as long as you preserve parentheses), Julia (which has a fast_fma-like function and a fast-math macro), and now Rust.
  - memming 2mo ago
    @fastmath in Julia!