Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Exploring SIMD performance improvements in WebAssembly (2021)

awelm.com

Post reply on HN
Print view View original

21–25 of 25 posts

Re: Exploring SIMD performance improvements in WebAssembly (2021)

#21

Post by fwsgonzo »

syrusakbary wrote: post #18
fwsgonzo wrote: post #8

I compared against native: #define ITERATIONS 1000 int main() { const size_t BUFFER_SIZE = 64ul \* 1024 \* 1024; __m128i\* data_buffer = (__m128i *)memalign(64, BUFFER_SIZE); const __m128i all_ones = _mm_set1_epi8(0xFF); for (size_t i = 0; i I had to fixup the WAT because set_local and get_local don't exist anymore. They are called local.get and local.set now. At higher number of iterations the C version converges on…

Hi, I'm Syrus from Wasmer. Have you tried with the llvm backend? I believe the results might be even better there! $ time ./wasmer run --llvm fill_buffer.wasm -i fillBufferWithSIMD 1000

$ time ./wasmer fill_buffer.wasm --llvm -i fillBufferWithSIMD 1000

real 0m5,233s

It seems to be a 25% longer run-time with LLVM backend. I did not know about that option! Very interesting.

Re: Exploring SIMD performance improvements in WebAssembly (2021)

#22

Post by syrusakbary »

fwsgonzo wrote: post #21
syrusakbary wrote: post #18

Earlier quoted context omitted.

Hi, I'm Syrus from Wasmer. Have you tried with the llvm backend? I believe the results might be even better there! $ time ./wasmer run --llvm fill_buffer.wasm -i fillBufferWithSIMD 1000

$ time ./wasmer fill_buffer.wasm --llvm -i fillBufferWithSIMD 1000 real 0m5,233s It seems to be a 25% longer run-time with LLVM backend. I did not know about that option! Very interesting.

It's strange that llvm runs slower (perhaps the of the 5s some of that is spent being compiled).

Could you share the fill_buffer.wasm (or the WAT file) so I can do some tests? Thanks!

Re: Exploring SIMD performance improvements in WebAssembly (2021)

#23

Post by Dylan16807 »

jcelerier wrote: post #20
Dylan16807 wrote: post #15

Earlier quoted context omitted.

> when If native performance is "very very very" not fast enough then that's supercomputer work and it doesn't really matter if WASM is 3x native or 0.3x native. So that context should be where you're the least depressed.

> then that's supercomputer work today's laptop work is late 90's supercomputer's work (and it was even more depressing back then).

And today's supercomputer work was impossible in the late 90's.

That doesn't really change my argument. When you're looking at languages that are used for small tasks today, their speed doesn't have much relevance to how vastly bigger tasks are accomplished. And by the time those tasks can be run on a laptop, WASM implementations are going to be much better and we still might not be using it at all for those larger tasks.

Re: Exploring SIMD performance improvements in WebAssembly (2021)

#24

Post by janwas »

skywal_l wrote: post #19
kevingadd wrote: post #4

Earlier quoted context omitted.

In practice it's not possible to optimize "generally" for all possible target architectures your wasm will run on. You're going to optimize for x86-64 or ARM, and probably going to specifically optimize for modern intel, modern amd, or apple's m1. If you try to optimize for everything you're going to run into really painful tradeoffs and probably have mediocre performance on a bunch of architectures after a lot of ha…

Wouldn't it be possible to have a binary containing multiple versions of your program compiled optimized for various CPU configuration and have a switch at runtime which would select depending on your CPUid. I think intel have a compiler for that.

Yes, our github.com/google/highway does that for SSE4/AVX2/AVX-512. It targets at the level of instruction sets, though, not specific microarchitectures.

Re: Exploring SIMD performance improvements in WebAssembly (2021)

#25

Post by fwsgonzo »

syrusakbary wrote: post #22
fwsgonzo wrote: post #21

Earlier quoted context omitted.

$ time ./wasmer fill_buffer.wasm --llvm -i fillBufferWithSIMD 1000 real 0m5,233s It seems to be a 25% longer run-time with LLVM backend. I did not know about that option! Very interesting.

It's strange that llvm runs slower (perhaps the of the 5s some of that is spent being compiled). Could you share the fill_buffer.wasm (or the WAT file) so I can do some tests? Thanks!

Here you go: https://gist.github.com/fwsGonzo/2968cf0bc3364eb1ff0e0500569...

Hopefully I did not mess anything up!

Post reply on HN