BEPUphysics VS U8String

Go and have a look at Bepu Physics v2: https://github.com/bepu/bepuphysics2

It can be quite performant these days, sadly I'm stuck developing in Unity Mono C# which is quite a bit behind.

> The other problem with simd is that in modern cpu-centric languages it often requires a rewrite for every vector width.

It does not: https://github.com/bepu/bepuphysics2/blob/master/BepuUtiliti...

Also you can’t go to GPU for most tasks SIMD is used in CPUs today. Good luck parsing HTTP headers with that.

This may be your personal experience but it is used successfully and happily by many in a variety of domains way different to "boring OOP back-ends". No popular general purpose language is confined to a single domain like you describe. C# lets you do things like writing a competitive Redis implementation[0], advanced physics engine that beats Jolt[1] or a game engine that does not rely on C++ or C[2], cross-platform applications[3] and so on and so forth. The language itself lets you go from high level FP style approach for business domain modeling to very low-level data crunching that is competitive with systems programming languages.

[0]: https://microsoft.github.io/garnet/docs/benchmarking/results...

[1]: https://github.com/bepu/bepuphysics2

[2]: https://www.stride3d.net

[3]: https://avaloniaui.net

The best pure-C# physics library (hands-down) is bepuphysics2, which unfortunately is mainly a 3D physics library, but could be used for 2D if you wanted to get your hands dirty.

Bepu Physics is pretty good and is written in really optimized C#, the author's blog post are really interesting to read.

I use https://github.com/bepu/bepuphysics2. I haven't worked with 3d physics engines before so I can't really comment on it's quality but it is definitely an impressive project! The developer is very active and helpful and some of the demo scenes are pretty large and complex.

Mask add looks neat! I wish there was a way to directly manipulate AVX512's mask registers in .NET intrinsics but for now we have to live with "recognized idioms".

Some months ago I wrote a similar ASCII in UTF-8 upcase/downcase implementation: https://github.com/U8String/U8String/blob/main/Sources/U8Str...

(the unrolled conversion for below vectorization lengths is required as short strings dominate most codebases so handling it fast is important - the switch compiles to jump table and then branchless fall-through to return)

For now it goes as wide as 256b as it already saturates e.g. Zen 3 or 4 which have only 256x4 SIMD units (even though Zen 4 can do fancy 512b shuffles natively and has very good 512b implementation). The core compiles to:

              cmp      rdx, 32

A little more on topic, if you like SIMD and C#, dotnet/runtime now has an introductory guide to Vector128/256/512 API:

https://github.com/dotnet/runtime/blob/main/docs/coding-guid...

Now, the default syntax can still be a bit more wordy with byref arithmetics than ideal, but you can add a few extension methods to look it closer to Rust's pointer arithmetics: https://github.com/U8String/U8String/blob/main/Sources/U8Str...

Writing performance-sensitive code in C and calling it via interop used to be the way to go during .NET Framework days but since then has become a performance trap.

Especially for small methods, calling them through interop is a deoptimization because they cannot be inlined, and involve GC frame transition (which you can suppress) as well as an indirect jump and maybe interop stub unless you are statically linking the dependency into your AOT deployment. In case the arguments are not blittable to C - marshalling too.

It is also complicates the publishing process because you have to build both .NET and C parts and then package them together, considering the matrix of [win, linux, macos] x [x64, arm64], it turns into quite an unpleasant experience.

Instead, the recommended approach is just continuing to write C# code, except with pointer and/or ref based code. This is what CoreLib itself does for the most performance-sensitive bits[0]. Naturally, it intentionally looks ugly like in Rust, but you can easily fix it with a few extension methods[1].

[0]: https://github.com/dotnet/runtime/blob/main/src/libraries/Sy...

[1]: https://github.com/U8String/U8String/blob/main/Sources/Share...