3 ms·

Author here, happy to discuss.

by janwas 4y ago

pistachiopro 4y ago
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?
- janwas 4y ago
  :) There are some wasm vs native benchmarks in the context of JPEG XL (for example https://github.com/niutech/jxl.js#benchmark 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/sort/bench_sort.cc https://github.com/google/highway/blob/master/hwy/contrib/so...
jackmott 4y ago
[dead]
mgraczyk 4y ago
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)
- janwas 4y ago
  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.
  - mgraczyk 4y ago
    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.
josephg 4y ago
This is awesome work. Do you think it would be possible to port this to Rust?
- janwas 4y ago
  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.

Author here, happy to discuss.

by janwas 4y ago

Author here, happy to discuss.

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?

janwas 4y ago
:) There are some wasm vs native benchmarks in the context of JPEG XL (for example https://github.com/niutech/jxl.js#benchmark 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/sort/bench_sort.cc https://github.com/google/highway/blob/master/hwy/contrib/so...

jackmott 4y ago

[dead]

mgraczyk 4y ago

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)

janwas 4y ago
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.
- mgraczyk 4y ago
  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.

josephg 4y ago

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

janwas 4y ago
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.