Generalised Intrinsic

[sirinath]

Can we have generalised intrinsic which are not dependent on any particular platform. This can follow the approach used in SIMDe but not limited to SIMD instructions. Also the intrinsic can be more generalised. Also there should be a generic or platform specific fall back for platforms which do not directly support a particular intrinsic.

[ghost]

Tagging subscribers to this area: @tannergooding
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Can we have generalised intrinsic which are not dependent on any particular platform. This can follow the approach used in SIMDe but not limited to SIMD instructions. Also the intrinsic can be more generalised.

Author:	sirinath
Assignees:	-
Labels:	api-suggestion, area-System.Runtime.Intrinsics, untriaged
Milestone:	-

[gfoidl]

Is Use SIMD-accelerated numeric types something you have in mind?

[sirinath]

What I had in mind is having additional functionality in System.Runtime.Intrinsics which is not platform specific and extensive bringing it in parity with C/C++/Fortran so there is not need to call native code for simple fucntionality. This should not be limited to SIMD instructions. This can bring .net in parity with C/C++/Fortran intrinsics, built-ins, pragmas, etc. in a platform independent way without the need of native calls.

[Wraith2]

Assuming that intrinsics implemented by any given platform are higher performance than doing the same work without them because otherwise there would be no reason for their existence, what is the benefit of doing what you suggest? It would allow you to write more complex code that ran slower and that doesn't seem helpful.

[sirinath]

• Code that runs faster in supported platforms but still work without modification in others.
• Also have a common schematics for accessing accelerate computations when they are supported in multiple platforms but have some schematic differences on how they are used.

[Wraith2]

Code that runs faster in supported platforms but still work without modification in others.

Intrinsics code should always be written with general fallbacks and guarded by availability checks. A good example of this is the string comparison code in .net 5. The downside of this is that there are multiple code paths for the same operation, the upside is that each variation is entirely optimized for the instructions that are available to it.

If the only version that were provided is the most intrinsic heavy version then the versions of that code compiled with partial hardware support for the required operations could still be slower than a hand optimized version. To users the reason for the speed differences wouldn't be clear and the code would be the most complex version possible rather than it being obvious that there were multiple strategies depending on the available hardware.

Given that all intrinsics code must be new since the feature is relatively recent there is no large body of code which needs to be brought into the new runtime via compatibility layers. Intrinsics are optional and an advanced use case for highly optimized scenarios.

Also have a common schematics for accessing accelerate computations when they are supported in multiple platforms but have some schematic differences on how they are used.

Where possible the exposed api surface is made sensible and reviewed in excruciating depth by the api design review team. It's exposing very complex instructions and behaviours though so there isn't a simple way to abstract them and maintain the ability to lookup the vendor supplied documentation.

[tannergooding]

Can we have generalised intrinsic which are not dependent on any particular platform

Of all intrinsic APIs (which is approx. 1500-2000 methods, including overloads) there is a limited subset that can be represented as "general-purpose" APIs and that is essentially what is exposed today via System.Numerics.Vector<T>

The functionality that isn't exposed either isn't easy to express cross-platform or may not be possible to expose on Vector<T> since it is variable-sized.

I have a backlog item to create a proposal for similar functionality on Vector64<T>, Vector128<T>, and Vector256<T>. Of those three, only Vector128<T> is currently supported on x86, x64, ARM32, and ARM64. The main benefit of doing it here is that certain operations that only make sense for "fixed-sized" vectors can also be exposed.

[sirinath]

You can use an approach like what SIMDe but not limited to SIMD where there is support of bittwidling, parallel programming, string and array manipulation, memory management, memory model related intrinsics, etc. Where possible there should be a generalised methods which may or may-not map into platform specific intrinsics. Platform specific intrinsics should always have a fall back. Maybe you can borrow some of this code from SIMDe and perhaps upstream it also. Again intrisics need not be limited to SIMD.