Comment by ris | Hacker News Reader

Comment by ris | Hacker News Reader

It's cool and everything but I don't go along with the whole why-don't-people-just tone of the whole thing. I think it's fairly understandable to want to limit the number of micro-optimized implementations of however many hot routines your library has & maintain them for an ever expanding array of SIMD extensions and variants, each of which you either have to ship with your resulting ever-expanding binaries (if you're doing runtime capability detection) or will likely never see the light of day for 99.9% of users who get shipped a baseline binary for compatibility (if you're doing build-time capability detection).

I'm sure libpng is in a better place with his improvement but I don't think not already having it is purely because they're dummies or "not ambitious enough".

In a world where profile-guided fuzzers are getting better every day, maintaining a high-profile library in a non-memory-safe language can be nerve-wracking enough with just a single implementation of your array-processing loops.

Not that I'm necessarily disagreeing, but simde has made life a lot easier here. If you want to write SIMD stuff and don't want to use a higher-level library or depend on the compiler to optimize the code down to SIMD (both of which honestly seem like pretty good options these days), simde is worth taking a look at. You write code that looks like native code, but it'll translate it to the other archs for you. Well, "other archs" just means partially-supported NEON here, but I'd still consider that quite a win.

No relation with the project, just a user.

I was curious about these libraries a few weeks ago and did some searching. Is there one that's got a clearly dominating set of users or contributors?

I don't know what a good way to compare these might be, other than perhaps activity/contributor count.

[1] https://github.com/simd-everywhere/simde

[2] https://github.com/ermig1979/Simd

[3] https://github.com/google/highway

[4] https://gitlab.com/libeigen/eigen

[5] https://github.com/shibatch/sleef

I'm not familiar with all of those but simde is afaict lower level than the others. It doesn't attempt to build any higher level abstractions, just translate between the existing standards and instruction sets.

This entire space has a lot of options, and it's still an open question about what is the right approach. The fact is that C++ is a scalar language, with scalar guarantees and scalar assumptions built into their types. Hacking around this requires sacrifices, and different libraries are choosing different approaches. EVO (not featured in your list) is trying to approach it from an algorithms point of view. Highway is portable wrappers around common functionality.

I think this is inherently a language-compiler problem. When libraries are using intrinsic functions to override compiler decisions, they interact poorly. One example: here's comparing a scalar versus an avx-512 intrinsic version of accumulate.

https://godbolt.org/z/cMafh4Pnv

IDK if you can read assembly, but the intrinsic version is waaaay worse, and about 4x slower. This is because using intrinsics makes it very hard for the compiler to do other optimizations it otherwise would (e.g. unrolling and reordering).

I agree compiler transforms sometimes do not interact well, but some still do help intrinsics.

Interestingly, even `#pragma clang unroll(4)` is ignored here. Often in such cases we have to manually unroll, e.g. introduce multiple accumulators.

Can I pick your brain? I'm working on yet another C++ based SIMD library, and my head is sort of boiling over.

Happy to discuss, preferably via issue on github.com/google/highway, would you like to open one?

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. Eigen is similarly useful for higher-level linear algebra that you probably do not want to reimplement yourself. However, I am skeptical of its expression template approach, in my experience one can run into trouble when the code gets complex (maybe some compiler limits are reached). Both of them may be less useful in non-math domains, AFAIK they lack many of the specialized instructions Highway has (e.g. interleaved load/store, compress/expand, software AES/CLMUL, popcount, lzcnt, saturated add/sub, 128-bit compare/minmax, fixed-point mul). I think Eigen would struggle with dynamic dispatch because of its header-only style, and SLEEF (understandably) lacks 8/16-bit types.

Highway is used in multiple projects and because it is just a collection of wrapper functions around intrinsics, it is more predictable/reliable. For this reason it is also currently AFAIK the only solution that supports scalable vectors in SVE and RISC-V V. The main downside is that it requires C++11, and so we are unable to help projects that are C-only and cannot compile parts of their code as C++.

I've also run into this thinking, and have been looking to solve it in codebases I'm working on.

I've run across: https://github.com/aff3ct/MIPP but have not worked with it extensively yet. It looks to be a solution to the rewriting X parallel pipeline into Y SIMD extensions.

Perhaps something like this, or languages introducing something similar into their standard libraries/modules would be a solution.

None of this of course solves the run-time detection of capability/growing binary size to support such.

I totally agree we don't want multiple optimized implementations, but that is no longer necessary. Highway (mentioned below) lets you write your code once but be compiled+specialized for the major SIMD targets. If you're writing say a thousand lines of SIMD, the binary size impact is a few dozen KiB.

This is also a purely library solution, so no build system magic is required.

I don't agree with this argument at all when the domain is a relatively fixed format with a specification.

Reply on news.ycombinator.com