SIMD revision proposal

[WhiteBlackGoose]

Improves the SIMD experience in Maths.

[Perksey]

Some pre-review comments: after these are addressed, please mark it as "Ready for Review" and we will review it in the meeting

[Perksey]

Proposal needs work (open questions addressed). Discussed in Working Group meeting 29/11/2021, 19:13 UTC.

Note: it has been assumed that all SIMD proposal elements are also being applied to Scalar.

• IEEE754

  • All methods and code thus far just follows whatever makes it fast, no compliance to any standard or other behaviour (c# builtin, hardware, etc) is guaranteed
    • Pretty good to be that way, as we can be the fastest and 100% accuracy most people don't care about
  • There's a difference between doing things for correctness and doing it for performance.
  • example optimization which could be problematic: treating NaN as 0, assuming it'll never happen (case in point: GCC fastmath)
  • Don't throw exceptions in performant, use NaN instead to represent exceptional circumstances? What about ints?
  • The only time you can accelerate if a value is a constant (JIT-level knowledge...)
  • Separate methods for opt-in correctness-sacrificial optimizations?
    • "I'm aware of the implications, and am ready for them"
  • Most sense, least surprise (0 / 0 = 0)
  • Something like a "IsMaximum" API to represent the "maximum representable value for a T" and use that in operations
  • .NET's default behaviour is changing to match Rust, WASM etc - platform-specifics (i.e. faster paths)
  • "do whatever the operator will do"
  • Just throw exceptions where they're not trivially avoidable.
  • We want all of the APIs to be as close as they can to hardware-accelerated.
    • are we sure? should they be explicitly labelled?
    • If we're using an inaccurate algorithm, should it be explicitly labelled?
    • Figure out ULP, and document if we're making this decision? The user could check the docs, find the ULP, and then either use the library or don't use the library according to that.
    • It's not trivial to find edge cases, could catch people out without realising?
    • Let's just add estimate APIs
  • For estimate APIs should they throw exceptions?

• Reciprocal of int

  • see consensus

• IsHardwareAccelerated

  • Make IsHardwareAccelerated per-type
  • Perhaps we could make a smarter way of doing IsHardwareAccelerated, but the working group thinks it's not necessary (and also has no ideas)
  • "Some or most of the APIs for this type are hardware accelerated"
    • Methods that aren't are slow-path
  • Static class with a whole bunch of static APIs for indicating?
  • Where do we draw the line?
  • Lots of checks can hurt the JIT/inliner
  • Usually we optimize "all or nothing" for a given type. There may be a few exceptions, but these would be few and far between.
  • Per-method and per-type is just pernickety and the working group sees no use case for this today/doesn't really matter...

Consensus

• IEEE754: We'll have estimate APIs and "native"/"more precise" APIs, two versions of all except things built in to the hardware (at a given baseline)
• Reciprocal: do what C# does for non-estimate (and for estimate as well we guess)
• IsHardwareAccelerated: one boolean per type. Not worth making a new flag for the few cases where we have a couple of functions which are slow for a given type.

[Perksey]

Happy to merge this once comments are addressed and open questions are answered in the doc. If you need any comment clarifications lmk and I'll shake the brain bush.

[WhiteBlackGoose]

There's some fair amount of work to distinguish methods which do need Estimate APIs from methods which don't... couldn't yet find time to resolve this 😅

[Perksey]

Merging with outstanding comments, as it is only a proposal after all and not gospel... Renamed file to indicate it needs work.