Looks very interesting!

I've been having trouble getting good SIMD performance from WASM. Are there any benchmarks posted anywhere comparing Highway's performance on various native targets vs WASM?

:) There are some wasm vs native benchmarks in the context of JPEG XL (for example https://github.com/niutech/jxl.js#benchmark) Could also be interesting for you to run the vqsort benchmark: https://github.com/google/highway/blob/master/hwy/contrib/so...

Looks cool. Are you familiar with Halide? In terms of target support or implementation complexity, how would you company using highway vs using Halide for similar projects? (I work at Google, use Halide)

Thanks! Yes indeed. Halide has good support for stencils and convolutions, especially taking care of the border handling, which is a pain with explicit SIMD if you are unable to 'define that away' by padding etc. Boilerplate is a bit more (~100 lines vs ~50 for Highway) but that's probably worthwhile.

Target support is good, though AFAIK non-constexpr-size vectors (SVE/RVV) are not supported.

The biggest concern I'd have is predictability. A thin wrapper over intrinsics makes it easy to experiment with codegen and see what's going on. We've seen some compiler bugs but usually narrow scope and relatively easy to reproduce. By contrast, Halide involves extensive compiler transforms. When that breaks, it's much harder to move forward. There is also a risk of performance cliffs because the language is very flexible and AFAIK lacks 'this is going to be slow' guardrails.

It's great for prototyping and image processing and this is probably what you're using it for? But I also would not expect peak performance, at one point I reimplemented parts of RAISR with explicit SIMD and saw a surprisingly high speedup.

Thanks for the response! Your point about Halide not being as predictable and having few guardrails is good.

Yes I work on image processing, same pipeline as RAISR actually.

This is beautiful work. Do you think it would be possible to port this to Rust some day?

Thanks! > Do you think it would be possible to port this to Rust? Yes, I think so. The main tricks are redefining macros based on the current compilation target, and compiling the same code multiple times. I believe Rust can do both, but have only surface-level familiarity. One stumbling block is getting the C++ equivalent of #pragma target, but I think Rust also has that.

There's been other interest in a Rust port, feel free to open an issue to perhaps start a discussion.