[bjpirt]

Personal WASM anecdote: I just implemented a WASM based 3d model boolean operation for three.js where I can intersect two models together. The pure js version ran in around 10s on a relatively simple model whereas the WASM version did the same thing in a little under 1s. I've been very impressed by the technology so far! Obviously this kind of CPU intensive work is where it can shine and it's a useful tool to have in your toolkit.

[shawn]

Can you post the code somewhere? I'm very interested in this.

[rasz]

and whats the performance using native code(c/c++)? Im guessing ~0.1sec on same models.

[RussianCow]

From benchmarks I've seen elsewhere, native code is generally roughly 2x faster than WASM, so I doubt that's the case. I'm sure it depends on a lot of factors, though.

[flohofwoe]

Single-threaded, non-SIMD x86-64 code being 1.2x to 2x faster than WASM is what I'm seeing as well. Interestingly I don't see such big differences between browsers as the PSPDFKit benchmark, my suspicion is that this mainly measures overhead when crossing the WASM-JS border.

[dangerbird2]

For geometry heavy stuff, web workers (possibly in addition to wasm) be super helpful in preventing the browser from blocking while number crunching.

[valarauca1]

wouldn’t shader libraries be better?

[jsheard]

Ideally yes, but the lack of geometry/tessellation/compute shaders in WebGL limits what you can do on the GPU.

Geometry processing that's more complex than moving vertices around has to be done on the CPU for now.

[valarauca1]

>Geometry processing that's more complex than moving vertices

Have you heard about our lord and savior abstract vector spaces?

everything is just moving vertices around in linear transformations.

[gnarbarian]

you should check out http://gpu.rocks/ pretty awesome GPGPU js library.