sleef VS streamvbyte

I'm the main author of Highway, so I have some opinions :D Number of operations/platforms supported are important criteria.

A hopefully unbiased commentary:

Simde allows you to take existing nonportable intrinsics and get them to run on another platform. This is useful when you have a bunch of existing code and tight deadlines. The downside is less than optimal performance - a portable abstraction can be more efficient than forcing one platform to exactly match the semantics of another. Although a ton of effort has gone into Simde, sometimes it also resorts to autovectorization which may or may not work.

Eigen and SLEEF are mostly math-focused projects that also have a portability layer. SLEEF is designed for C and thus has type suffixes which are rather verbose, see https://github.com/shibatch/sleef/blob/master/src/libm/sleef... But it offers a complete (more so than Highway's) libm.

But the other part about SIMD: I'm unsure if mgl-mat uses SIMD for transcendental functions or even for something like element-wise multiplication and division*. SIMD easily provides a speed-boost of 4-8 times which numpy uses. Libraries like sleef have been put to use by many.

Highway and Agner's VectorClass also have math functions. And SLEEF should definitely be mentioned.

"SIMD Library for Evaluating Elementary Functions, vectorized libm and DFT" - https://github.com/shibatch/sleef

Not mentioned in the list of users is SLEEF (https://github.com/shibatch/sleef), which provides fast approximations for various elementary functions. (It generates coefficients for the approximations with mpfr)

SLEEF itself is used by PyTorch.

If you are looking at floats, there's https://sleef.org

It would be interesting to see SLEEF added in the benchmarks.

Be direct and put the onus on the reporter/contributor to do more work before you will engage.

e.g., here is Daniel Lemire responding to a very open-ended bug report: https://github.com/lemire/streamvbyte/issues/72

There is something similar in customer service for my SaaS. Customers give horribly vague bug reports. I used to try to divine what they wanted. That way leads burnout. Instead, make them do more of the work.

You're right, I used a lot of unsafe. I started with the implementation from the C source and then my main goal was to add a bounds-check without sacrificing performance. I got there by manually unrolling the inner loop a few times and then bounds checking only once per iteration of the outer loop. So instead of 1 bounds check for every 4 inputs, I have one every 16 or 32 inputs (with a correspondingly more conservative bounds check).