MathSharp, a vector and matrix library written in C# using hardware intrinsics(github.com)
github.com
MathSharp, a vector and matrix library written in C# using hardware intrinsics
https://github.com/john-h-k/MathSharp
23 comments
I took a look at the code and I was wondering about the implementation performance where there are a lot of if() statements in the low level functions. Like Vector4F DotProduct2D() has if (Sse41.IsSupported) else if (Sse3.IsSupported) else if (Sse.IsSupported) and finally a default implementation. This seems inefficient but I don't know if somehow the booleans are more like compile time flags and the extraneous code disappears in a puff of logic.
Those might fall out during JIT compilation as constant expressions. Would be worth running it through ngen to see what happens. (I'd do it myself but I'm not at a PC at the moment.)
EDIT: Just realized the Intrinsics namespace was added in Core 3.0 preview. I don't have the setup to test this myself right now. I did find an online compiler, but it looked like it optimized away everything in release mode.
EDIT: Just realized the Intrinsics namespace was added in Core 3.0 preview. I don't have the setup to test this myself right now. I did find an online compiler, but it looked like it optimized away everything in release mode.
There was some discussion here on hn a few days ago [0] that linked to a blog post about those intrinsics [1]. Those should indeed be optimized away. The relevant section:
> The IsSupported checks are treated as runtime constants by the JIT (when optimizations are enabled) and so you do not need to cross-compile to support multiple different ISAs, platforms, or architectures. Instead, you just write your code using if-statements and the unused code paths (any code path which is not executed, due to the condition for the branch being false or an earlier branch being taken instead) are dropped from the generated code (the native assembly code generated by the JIT at runtime).
[0] https://news.ycombinator.com/item?id=20915430 [1] https://devblogs.microsoft.com/dotnet/hardware-intrinsics-in...
> The IsSupported checks are treated as runtime constants by the JIT (when optimizations are enabled) and so you do not need to cross-compile to support multiple different ISAs, platforms, or architectures. Instead, you just write your code using if-statements and the unused code paths (any code path which is not executed, due to the condition for the branch being false or an earlier branch being taken instead) are dropped from the generated code (the native assembly code generated by the JIT at runtime).
[0] https://news.ycombinator.com/item?id=20915430 [1] https://devblogs.microsoft.com/dotnet/hardware-intrinsics-in...
The JIT optimizes them away:
> The IsSupported checks are treated as runtime constants by the JIT (when optimizations are enabled) and so you do not need to cross-compile to support multiple different ISAs, platforms, or architectures. Instead, you just write your code using if-statements and the unused code paths (any code path which is not executed, due to the condition for the branch being false or an earlier branch being taken instead) are dropped from the generated code (the native assembly code generated by the JIT at runtime).
https://devblogs.microsoft.com/dotnet/hardware-intrinsics-in...
> The IsSupported checks are treated as runtime constants by the JIT (when optimizations are enabled) and so you do not need to cross-compile to support multiple different ISAs, platforms, or architectures. Instead, you just write your code using if-statements and the unused code paths (any code path which is not executed, due to the condition for the branch being false or an earlier branch being taken instead) are dropped from the generated code (the native assembly code generated by the JIT at runtime).
https://devblogs.microsoft.com/dotnet/hardware-intrinsics-in...
branch predictor gonna work well on those at least, if the jit doesn’t make then go away entirwlyy
came to say this. +1
yep, the JIT fully removes those checks when native code gen occurs :)
The following call which is in MatrixOperations for instance is about cameras - I assume this is some scene-object type of logic regarding 3d graphics?
That does not look like a general-purpose linear algebra library to me.
public static MatrixSingle CreateBillboard(in Vector4FParam1_3 objectPosition, in Vector4FParam1_3 cameraPosition, in Vector4FParam1_3 cameraUpVector, in Vector4FParam1_3 cameraForwardVector)
That does not look like a general-purpose linear algebra library to me.
public static MatrixSingle CreateBillboard(in Vector4FParam1_3 objectPosition, in Vector4FParam1_3 cameraPosition, in Vector4FParam1_3 cameraUpVector, in Vector4FParam1_3 cameraForwardVector)
Looks like this claims to be faster than other libraries but has no benchmarks.
Yeah. Fast compare to what ? Blas ? On which platform ? The Readme is a bit short for something that pretend to be "significantly faster than most mathematics libraries out there"
hi - lead dev of the library. there are a multitude of benchmarks in `MathSharp/samples/MathSharp.Interactive/Benchmarks`, I just haven't been able to put them into the seperate project because of personal time constraints so far
Any update on this inclusion? Looks like two or three were added
Probably not what you are looking for, but maybe useful: https://www.reddit.com/r/dotnet/comments/d2t7ti/mathsharp_a_...
There is already a Microsoft library for this - System.Numerics.Vectors, see documentation at https://docs.microsoft.com/en-us/dotnet/api/system.numerics?...
Not sure how MathSharp compares in performance or usability, however.
Not sure how MathSharp compares in performance or usability, however.
This is built on top of the newer hardware intrinsics capabilities added to the framework underneath a new namespace: System.Runtime.Intrinsics
https://devblogs.microsoft.com/dotnet/hardware-intrinsics-in...
https://devblogs.microsoft.com/dotnet/hardware-intrinsics-in...
that uses the old and very limited simd facilities of .net
> How to use
> TODO
:(
> TODO
:(
Sorry about that!! Will get on it ASAP when I have some spare time
[deleted]
I suggest that you use run-time code generation to create optimized classes that do not check for intrinsic features on each function call.
This is exactly what is happening here. The JIT generates code at runtime based on the target machine's capability.
"Parsing a typical JSON payload and accessing all its members using the JsonDocument is 2-3x faster than Json.NET with little allocations for data that is reasonably sized (that is, < 1 MB)."
From: https://docs.microsoft.com/en-us/dotnet/core/whats-new/dotne...
I'll definitely be checking this math(s) library out after I get our solutions updated from 2.2. I was playing around with some ray tracing in C#-land and something like this could come in really handy.