What does HackerNews think of highway?

Interesting, thanks for sharing :)

At the time we open-sourced Highway, the standardization process had already started and there were some discussions.

I'm curious why stdlib is the only path you see to default? Compare the activity level of https://github.com/VcDevel/std-simd vs https://github.com/google/highway. As to open-source usage, after years of std::experimental, I see <200 search hits [1], vs >400 for Highway [2], even after excluding several library users.

But that aside, I'm not convinced standardization is the best path for a SIMD library. We and external users extend Highway on a weekly basis as new use cases arise. What if we deferred those changes to 3-monthly meetings, or had to wait for one meeting per WD, CD, (FCD), DIS, (FDIS) stage before it's standardized? Standardization seems more useful for rarely-changing things.

1: https://sourcegraph.com/search?q=context:global+std::experim...

2: https://sourcegraph.com/search?q=context:global+HWY_NAMESPAC...

Ah thank you for clarifying so you would have to create an abstraction layer on top of the current simd implementation like for example simd_vector(type, size). That abstraction would have to dynamically detect the hardware and dispatch it to the hardware like the project you shared (https://github.com/google/highway).

So technically it sounds feasible but all of the languages like Zig, C++ and Rust picked a simpler approach. Is it simply a first step to a more abstract approach?

You could study Google's Highway library [1].

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

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

It's indeed nice that SVE2 binaries can run on differing HW, and fragmentation will be less because it's required in ARMv9.

> the same code will work for both the super-computer and the cheap phone. That is not possible with the x86 SIMD instructions

Actually, when the code is expressed using "portable intrinsics" (https://github.com/google/highway), the source code looks the same but compiles to SSE4/AVX2/AVX-512 and NEON,SVE,SVE2 and RISC-V V instructions.

Disclosure: I am the main author of this library.

> If your goal is to understand how hardware SIMD works, you're probably better off sticking to C code with intrinsics

Agreed, and we're also using intrinsics in time-critical places. I am confident we will be able to hide both SVE and RVV behind the same C++ interface (https://github.com/google/highway) - works for RVV, just started SVE.

+1 to intrinsics or wrappers giving us more control over performance.

> Plus, when you get the hang of it, writing your own SIMD library is fairly simple

hm.. it's indeed easy to start, but maintaining https://github.com/google/highway (supports clang/gcc/MSVC, x86/ARM/RiscV) is quite time-consuming, especially working around compiler bugs.

Apart from the fact that you have to rewrite your code, the big disadvantage to something like this is that it's a bit slower.

With SIMDe you're still free to use functions like `_mm_maddubs_epi16` and they'll be really fast on x86, but still work everywhere.

With xsimd (and similar libraries) you're generally limited to the lowest common denominator.

FWIW, if abstraction layers are your thing you might want to look at std::experimental::simd (https://github.com/VcDevel/std-simd) instead. Google's Highway (https://github.com/google/highway) is also pretty interesting.