su 4. elok. 2019 klo 18.39 Flix ([email protected]) kirjoitti:

>> Please also keep in mind that using emulated SIMD is slower than not using 
>> SIMD at all.

This is not always true. It depends on what kind of emulation we are
talking about. We can emulate SSE on top of scalar C code, or SSE on
top of WebAssembly SIMD. Emulating SSE on top of scalar C code can be
equally as fast as hand-writing the scalar code itself, depending on
what the original SSE code looked like. (of course in many cases there
are extra swizzles that would be redundant, but depending on the
problem, the code can end up looking very identical)

Emulating SSE on top of Wasm SIMD can be faster than not having used
SIMD at all.

> I remember that last year, using an old version of emscripten, I managed it 
> compile (with SIMD+asm.js+polyfill), but it was extremely slow when running 
> inside the browser.
> Now using emscriptem +simde (https://github.com/nemequ/simde) it's much 
> faster.

The reason why it was extremely slow was that no browser ended up
shipping simd.js support, and the polyfill was implemented in
hand-written JavaScript. If you had run in Firefox Nightly which did
implement simd.js in hardware, you would have gotten the same result
as you are now getting with simde - both emulate SSE on top of
SIMD.js/wasm simd. That is, Emscripten with SSE+asm.js+simd.js used to
back on directly to hardware, but the SSE backing support was dropped
when Wasm SIMD support was added.

I am really glad to find that the project simde exists, that will
patch up the missing support in Emscripten. If the license is
appropriate, I think it would be great to bundle simde directly into
Emscripten so that -msse and -msse2 etc. work out of the box.

> However it seems that 
> https://github.com/emscripten-core/emscripten/blob/incoming/system/include/wasm_simd128.h
>  can't be used to convert existing SIMD code to WebAssembly SIMD.

> It would be too much work for me to make a full WebAssembly-SIMD conversion 
> for now, so I'm glad with the emulated version.

This has been a long recurring point of conversation that has not yet
been resolved. (long historical thread at
https://github.com/tc39/ecmascript_simd/issues/59) There is no sense
to always have to rewrite SSE code to Wasm SIMD just to have the
browser undo that Wasm-SIMD back to SSE on-the-fly when running on a
x86 hardware. Developers want to be able to write page_sse.wasm and
page_neon.wasm files and feature check to run the appropriate one
depending on the target. (and they also want to be able to write
page_simd.wasm that simultaneously targets both sse and neon) But
there is some hope to introduce proper SSE* instruction sets in a
future revision of the WebAssembly SIMD v2 or similar.

-- 
You received this message because you are subscribed to the Google Groups 
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/emscripten-discuss/CA%2B6sJ-3tW8KBNL65onQMtv9ujKaQ%3D7%2B8YS7rbMuRMHw%2Bdx4HEw%40mail.gmail.com.

Reply via email to