10 ms·

Experiment with particles using WebAssembly and WebGL

137 points by Schampu 9y ago

Schampu 9y ago
Source: https://github.com/maierfelix/wasm-particles https://github.com/maierfelix/wasm-particles
dvdplm 9y ago
Crashes on Safari Nightly and Firefox Nightly, but very neat when it works! :)
- steveklabnik 9y ago
  Did it just straight-up crash on Firefox for you? It seems to work well on my Nightly.
  - dvdplm 9y ago
    It worked on yesterday's Nightly, then I updated to today's and it crashed immediately.
    - steveklabnik 9y ago
      You should file a bug! I only started doing so a few weeks ago, and the devs have been pretty responsive.
      - dvdplm 9y ago
        No kidding! It took them all of 24h to get it sorted, impressive. :)
- bobajeff 9y ago
  It works on my phone's browser (which is a fork of Chrome for Android). No crashes. I even have 34 tabs open.
  - johnhenry 9y ago
    Likely, 33 of those tabs are suspended?
    - bobajeff 9y ago
      Well, most of them were suspended but I believe there were still a few that were active at the time.
- mastax 9y ago
  Works on Android Firefox nightly (surprisingly).
- memco 9y ago
  I'm also getting crashes in Safari tech preview. Firefox developer ed. and chrome canary both run it, but Firefox can handle about twice as much as Chrome at roughly 2 million particles while still getting over 40FPS. Chrome slows down a lot with anything over a million. This is on a 2014 MBP.
neals 9y ago
Is there an performance gain in using WASM?
- steveklabnik 9y ago
  In general, there should be, but it depends on what you're doing. For example, wasm can't access the DOM directly yet, so you have to call back into JS to do it, which is much slower than the eventual native API will be. For stuff like this, though, it should have much lower overhead.
  - k__ 9y ago
    Wasn't the main point of WASM that it is faster to parse than JavaScript?
    - steveklabnik 9y ago
      It's one of the main points, yes. Parsing isn't the only aspect of overall performance, though.
      - deleted 9y ago
        [deleted]
    - flohofwoe 9y ago
      Parsing of WASM byte code is massively faster* than parsing JS source code, but calling back and forth between JS and WASM is an entirely different topic. It's not that slow though, for instance each call to WebGL incurs that overhead, but the overhead is small enough that it doesn't matter that much (for overall performance) compared to asm.js or "normal" JS code. Still, if you want the best performance, avoid as many calls into the JS side as possible (e.g. by eliminating redundant WebGL calls). edit: * at least in Firefox, Chrome still has some... potential :)
    - j1vms 9y ago
      > Wasn't the main point of WASM that it is faster to parse than JavaScript? That is only one of the advantages of WASM. The major advantage is that seen by CPU-bound code sections where WASM can be efficiently executed at "near" native speed. Conversely, this performance advantage is not enjoyed by I/O-heavy operations which will not see any major improvement versus regular JS - this is roughly due to the browser having to apply sandboxing/security/protection (or by just forcing you to make JS calls to achieve this).
shurcooL 9y ago
Crashes in latest Chrome and Safari on latest iOS (11.1.1). Will have to try on desktop later.
- cordite 9y ago
  Chrome on iOS is just a wrapper around a safari web view, plus some nice to haves. Same behavior observed here too.
  - shurcooL 9y ago
    > Chrome on iOS is just a wrapper around a safari web view, plus some nice to haves. I’m aware, thanks. I tested in both anyway just to have more data.
  - johnrivera 9y ago
    I thought it was using wkwebview, which is faster than uiwebview, but still behind safari in terms of js performance on iOS.
tandav 9y ago
Why WASM can't give native performance?? (games in a browser?). All demos I saw only gives 8-10x performance boost?? (with respect to JS)
- steveklabnik 9y ago
  > Why WASM can't give native performance? As with any language, it depends on how good the optimizations are; wasm is designed to be able to be JITted fast, but is still fairly new, so there's still stuff left on the table. Additionally if you're compiling a language to wasm, you're also at the mercy of that compiler as well, so it always depends. > only 8-10x performance boost I'll take it ;)
  - tmzt 9y ago
    > Additionally if you're compiling a language to wasm, you're also at the mercy of that compiler as well, so it always depends. and potentially runtime, depending on the language you are compiling from
    - dangerbird2 9y ago
      Most wasm toolchains use clang for c/c++, so poor compiler generation is rarely a significant issue. IIRC, the emscripten toolchain uses musl as the C runtime, which is reasonably performant runtime. Of course, if you write algorithmically inefficient code, no toolchain is going to improve it.
- flohofwoe 9y ago
  WASM currently doesn't support SIMD and threading, other than that it is already close to single-threaded native performance (usually within 1.2x to 1.5x, there are some runtime checks happening after all). Frankly, I would be surprised to see well-written Javascript code that's consistently 8x to 10x slower than (single-threaded, non-SIMD) native performance. You have spikes from GC and re-compilation, but JITed JS is not that slow.
- dangerbird2 9y ago
Kiro 9y ago
https://maierfelix.github.io/wasm-particles/dist/bundle.js https://maierfelix.github.io/wasm-particles/dist/bundle.js Quite interesting to read. I don't know much about WASM but I presume the big Uint8Array is the actual C program or something?
- __s 9y ago
  That is correct; it is the WASM binary http://webassembly.org/docs/binary-encoding http://webassembly.org/docs/binary-encoding
qbaqbaqba 9y ago
3 fps?
- BatFastard 9y ago
  I get 23 on a beastly desktop with dual GeForce 980Ti. Not bad for 1.8 million particles!
  - onion2k 9y ago
    17fps with 712000 particles on a Nexus 6P. That's really impressive.
    - PuffinBlue 9y ago
      That's pretty good! Get between 11-29 fps at 753620 particles on Galaxy s7, mostly sits at 16 or 17fps though. I wonder what an iPhone would get, I'm led to believe their GPUs are pretty strong (to say the least).
  - PuffinBlue 9y ago
    I get 23 fps at 1.8 million particles with a single gtx1070. Well, 17-24 fps but sits mostly at 23. Quite interesting to see the comparison between generations. EDIT - The above was in Chrome. In Firefox I actually get 23/24 fps at 4k (3.83M particles). At 1.8M in Firefox I get 48-50fps. Pretty good from Firefox. Doesn't seem hardware limited, CPU and GPU utilisation doesn't go above 20% and I'm running other stuff like a decent sized VM and some other programmes. I really don't know much about WASM. Would these numbers be deemed good? Is there more performance to squeezed out? I'm guessing there is as it's not fully utilising the hardware?
  - avisaven 9y ago
    That's odd, I'm running on a Macbook with an Intel Iris Pro integrated graphics card and I'm getting 60FPS. Using Chromium 62.0.3202.89 (Developer Build) (64-bit) though. https://i.imgur.com/wbiUT5l.jpg https://i.imgur.com/wbiUT5l.jpg EDIT: Ah just noticed I'm only using 586k particles.
- 9y ago
Santosh83 9y ago
I'm getting a steady 40 FPS on Firefox 56 and 58 on Windows 10. About 5 FPS slower on Chrome 62 on the same machine. And Vivaldi is almost identical to Chrome, which is expected considering they share the same internals. Impressive. EDIT: ~640,000 particles on all browsers.
- jcelerier 9y ago
  > Impressive. ... is it ? tech demos ten years ago were already north of 1 million particles. https://www.youtube.com/watch?v=3xN2PkxNRHs https://www.youtube.com/watch?v=3xN2PkxNRHs
  - giancarlostoro 9y ago
    WebGL is a new frontier for many. I myself was impressed by what I could do with three.js at work. Also impressed by other three.js projects / products out there.
  - benaadams 9y ago
    Is performed on CPU; example you linked is performed on GPU so JS speed isn't a factor
- Izmaki 9y ago
  935040 particles at a steady 91 FPS, 1080p full screen (minus windows launch bar + tabs/frame of browser). This is in Chrome. I don't get the purpose of the site, though.
  - SimeVidas 9y ago
    Weird, it seems to be locked at 60 FPS (with 361k particles) for me. (Firefox Nightly on MacBook Pro 13.)
fulafel 9y ago
This is webgl 1 I guess? WebGL 2 has some nice particle suited features like transform feedback: https://gpfault.net/posts/webgl2-particles.txt.html https://gpfault.net/posts/webgl2-particles.txt.html
- sehugg 9y ago
  Looking at the source, seems they render all the points in software (WASM) to a 2D texture then to the screen.
- pharrington 9y ago
  This isn't a guide for implementing an actual modern particle system, but rather the author's learning project/proof-of-concept for WebAssembly. The presented effect itself trivially translates to a fragment shader.
xstartup 9y ago
Firefox 58, 60FPS. Chrome: 40 FPS
- calibas 9y ago
  I get a steady 60FPS in both FF 56 and Chrome 61/62.
- tzs 9y ago
  It would probably be useful to include hardware. 60 FPS in Firefox 57.0, Chrome 62.0.3202.89, and Safari 11.0.1, on a 2017 iMac running High Sierra (10.13.1) with a 3.4 GHz Intel Core i5 and a Radeon Pro 570 4 GB.
everyone 9y ago
Could one use WASM to build a game engine that runs from the web in a browser and actually performs good? How does it work? What sort of VM is it running on? How is it compiled?
- jdub 9y ago
  Yes, you could. In 2014. (Using the old asm.js.) Here's a 2014 Unreal Engine asm.js demo now running on WASM: https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGard... It's running on your browser's JavaScript VM (maybe in a special mode). The code compiled to WASM just like any other machine language. Quite a few compilers support WASM as a target now.
- notaboutdave 9y ago
  User rossisred ported his "Funky Karts" game from C++ (targeting Android) to WASM. Direct link to the game: https://www.funkykarts.rocks/demo.html https://www.funkykarts.rocks/demo.html Blog post on porting the engine: http://www.rossis.red/wasm.html http://www.rossis.red/wasm.html Original thread: https://news.ycombinator.com/item?id=14411328 https://news.ycombinator.com/item?id=14411328 His post helped me demystify what WASM is capable of and how it fits with the DOM. He shares some eye-opening code snippets, but the game itself is closed source so it leaves something to be desired.
  - jcelerier 9y ago
    these barrels remind me of that fun old DOS game, Skunny. Quite fun, very nice port !
- flohofwoe 9y ago
  You can, but with a lot of caveats: - single-thread CPU performance is pretty much 'good enough' now - WebGL and WebGL2 too, but you have very different performance behaviour than a native GL driver (much higher call overhead for instance) - pretty much all other HTML5 APIs: oh boy what a mess :/ Don't expect a 100 GB AAA Steam game to run on the web anytime soon, but mobile games will port over fine. It's better to define the web as your main platform, and design a new game from scratch around it's limitations. So if you have a project which needs to do 3D rendering, audio, touch input etc... CPU performance is the least of your problems.
yakshaving_jgt 9y ago
So… Who else drew their name?

137 points by Schampu 9y ago

Schampu 9y ago

Source: https://github.com/maierfelix/wasm-particles https://github.com/maierfelix/wasm-particles

dvdplm 9y ago

Crashes on Safari Nightly and Firefox Nightly, but very neat when it works! :)

steveklabnik 9y ago
Did it just straight-up crash on Firefox for you? It seems to work well on my Nightly.
- dvdplm 9y ago
  It worked on yesterday's Nightly, then I updated to today's and it crashed immediately.
  - steveklabnik 9y ago
    You should file a bug! I only started doing so a few weeks ago, and the devs have been pretty responsive.
    - dvdplm 9y ago
      No kidding! It took them all of 24h to get it sorted, impressive. :)
bobajeff 9y ago
It works on my phone's browser (which is a fork of Chrome for Android). No crashes. I even have 34 tabs open.
- johnhenry 9y ago
  Likely, 33 of those tabs are suspended?
  - bobajeff 9y ago
    Well, most of them were suspended but I believe there were still a few that were active at the time.
mastax 9y ago
Works on Android Firefox nightly (surprisingly).
memco 9y ago
I'm also getting crashes in Safari tech preview. Firefox developer ed. and chrome canary both run it, but Firefox can handle about twice as much as Chrome at roughly 2 million particles while still getting over 40FPS. Chrome slows down a lot with anything over a million. This is on a 2014 MBP.

neals 9y ago

Is there an performance gain in using WASM?

steveklabnik 9y ago
In general, there should be, but it depends on what you're doing. For example, wasm can't access the DOM directly yet, so you have to call back into JS to do it, which is much slower than the eventual native API will be. For stuff like this, though, it should have much lower overhead.
- k__ 9y ago
  Wasn't the main point of WASM that it is faster to parse than JavaScript?
  - steveklabnik 9y ago
    It's one of the main points, yes. Parsing isn't the only aspect of overall performance, though.
    - deleted 9y ago
      [deleted]
  - flohofwoe 9y ago
    Parsing of WASM byte code is massively faster* than parsing JS source code, but calling back and forth between JS and WASM is an entirely different topic. It's not that slow though, for instance each call to WebGL incurs that overhead, but the overhead is small enough that it doesn't matter that much (for overall performance) compared to asm.js or "normal" JS code. Still, if you want the best performance, avoid as many calls into the JS side as possible (e.g. by eliminating redundant WebGL calls). edit: * at least in Firefox, Chrome still has some... potential :)
  - j1vms 9y ago
    > Wasn't the main point of WASM that it is faster to parse than JavaScript? That is only one of the advantages of WASM. The major advantage is that seen by CPU-bound code sections where WASM can be efficiently executed at "near" native speed. Conversely, this performance advantage is not enjoyed by I/O-heavy operations which will not see any major improvement versus regular JS - this is roughly due to the browser having to apply sandboxing/security/protection (or by just forcing you to make JS calls to achieve this).

shurcooL 9y ago

Crashes in latest Chrome and Safari on latest iOS (11.1.1). Will have to try on desktop later.

cordite 9y ago
Chrome on iOS is just a wrapper around a safari web view, plus some nice to haves. Same behavior observed here too.
- shurcooL 9y ago
  > Chrome on iOS is just a wrapper around a safari web view, plus some nice to haves. I’m aware, thanks. I tested in both anyway just to have more data.
- johnrivera 9y ago
  I thought it was using wkwebview, which is faster than uiwebview, but still behind safari in terms of js performance on iOS.

tandav 9y ago

Why WASM can't give native performance?? (games in a browser?). All demos I saw only gives 8-10x performance boost?? (with respect to JS)

steveklabnik 9y ago
> Why WASM can't give native performance? As with any language, it depends on how good the optimizations are; wasm is designed to be able to be JITted fast, but is still fairly new, so there's still stuff left on the table. Additionally if you're compiling a language to wasm, you're also at the mercy of that compiler as well, so it always depends. > only 8-10x performance boost I'll take it ;)
- tmzt 9y ago
  > Additionally if you're compiling a language to wasm, you're also at the mercy of that compiler as well, so it always depends. and potentially runtime, depending on the language you are compiling from
  - dangerbird2 9y ago
    Most wasm toolchains use clang for c/c++, so poor compiler generation is rarely a significant issue. IIRC, the emscripten toolchain uses musl as the C runtime, which is reasonably performant runtime. Of course, if you write algorithmically inefficient code, no toolchain is going to improve it.
flohofwoe 9y ago
WASM currently doesn't support SIMD and threading, other than that it is already close to single-threaded native performance (usually within 1.2x to 1.5x, there are some runtime checks happening after all). Frankly, I would be surprised to see well-written Javascript code that's consistently 8x to 10x slower than (single-threaded, non-SIMD) native performance. You have spikes from GC and re-compilation, but JITed JS is not that slow.
dangerbird2 9y ago

Kiro 9y ago

https://maierfelix.github.io/wasm-particles/dist/bundle.js https://maierfelix.github.io/wasm-particles/dist/bundle.js Quite interesting to read. I don't know much about WASM but I presume the big Uint8Array is the actual C program or something?

__s 9y ago
That is correct; it is the WASM binary http://webassembly.org/docs/binary-encoding http://webassembly.org/docs/binary-encoding

qbaqbaqba 9y ago

3 fps?

BatFastard 9y ago
I get 23 on a beastly desktop with dual GeForce 980Ti. Not bad for 1.8 million particles!
- onion2k 9y ago
  17fps with 712000 particles on a Nexus 6P. That's really impressive.
  - PuffinBlue 9y ago
    That's pretty good! Get between 11-29 fps at 753620 particles on Galaxy s7, mostly sits at 16 or 17fps though. I wonder what an iPhone would get, I'm led to believe their GPUs are pretty strong (to say the least).
- PuffinBlue 9y ago
  I get 23 fps at 1.8 million particles with a single gtx1070. Well, 17-24 fps but sits mostly at 23. Quite interesting to see the comparison between generations. EDIT - The above was in Chrome. In Firefox I actually get 23/24 fps at 4k (3.83M particles). At 1.8M in Firefox I get 48-50fps. Pretty good from Firefox. Doesn't seem hardware limited, CPU and GPU utilisation doesn't go above 20% and I'm running other stuff like a decent sized VM and some other programmes. I really don't know much about WASM. Would these numbers be deemed good? Is there more performance to squeezed out? I'm guessing there is as it's not fully utilising the hardware?
- avisaven 9y ago
  That's odd, I'm running on a Macbook with an Intel Iris Pro integrated graphics card and I'm getting 60FPS. Using Chromium 62.0.3202.89 (Developer Build) (64-bit) though. https://i.imgur.com/wbiUT5l.jpg https://i.imgur.com/wbiUT5l.jpg EDIT: Ah just noticed I'm only using 586k particles.
9y ago

Santosh83 9y ago

I'm getting a steady 40 FPS on Firefox 56 and 58 on Windows 10. About 5 FPS slower on Chrome 62 on the same machine. And Vivaldi is almost identical to Chrome, which is expected considering they share the same internals. Impressive. EDIT: ~640,000 particles on all browsers.

jcelerier 9y ago
> Impressive. ... is it ? tech demos ten years ago were already north of 1 million particles. https://www.youtube.com/watch?v=3xN2PkxNRHs https://www.youtube.com/watch?v=3xN2PkxNRHs
- giancarlostoro 9y ago
  WebGL is a new frontier for many. I myself was impressed by what I could do with three.js at work. Also impressed by other three.js projects / products out there.
- benaadams 9y ago
  Is performed on CPU; example you linked is performed on GPU so JS speed isn't a factor
Izmaki 9y ago
935040 particles at a steady 91 FPS, 1080p full screen (minus windows launch bar + tabs/frame of browser). This is in Chrome. I don't get the purpose of the site, though.
- SimeVidas 9y ago
  Weird, it seems to be locked at 60 FPS (with 361k particles) for me. (Firefox Nightly on MacBook Pro 13.)

fulafel 9y ago

This is webgl 1 I guess? WebGL 2 has some nice particle suited features like transform feedback: https://gpfault.net/posts/webgl2-particles.txt.html https://gpfault.net/posts/webgl2-particles.txt.html

sehugg 9y ago
Looking at the source, seems they render all the points in software (WASM) to a 2D texture then to the screen.
pharrington 9y ago
This isn't a guide for implementing an actual modern particle system, but rather the author's learning project/proof-of-concept for WebAssembly. The presented effect itself trivially translates to a fragment shader.

xstartup 9y ago

Firefox 58, 60FPS. Chrome: 40 FPS

calibas 9y ago
I get a steady 60FPS in both FF 56 and Chrome 61/62.
tzs 9y ago
It would probably be useful to include hardware. 60 FPS in Firefox 57.0, Chrome 62.0.3202.89, and Safari 11.0.1, on a 2017 iMac running High Sierra (10.13.1) with a 3.4 GHz Intel Core i5 and a Radeon Pro 570 4 GB.

everyone 9y ago

Could one use WASM to build a game engine that runs from the web in a browser and actually performs good? How does it work? What sort of VM is it running on? How is it compiled?

jdub 9y ago
Yes, you could. In 2014. (Using the old asm.js.) Here's a 2014 Unreal Engine asm.js demo now running on WASM: https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGard... It's running on your browser's JavaScript VM (maybe in a special mode). The code compiled to WASM just like any other machine language. Quite a few compilers support WASM as a target now.
notaboutdave 9y ago
User rossisred ported his "Funky Karts" game from C++ (targeting Android) to WASM. Direct link to the game: https://www.funkykarts.rocks/demo.html https://www.funkykarts.rocks/demo.html Blog post on porting the engine: http://www.rossis.red/wasm.html http://www.rossis.red/wasm.html Original thread: https://news.ycombinator.com/item?id=14411328 https://news.ycombinator.com/item?id=14411328 His post helped me demystify what WASM is capable of and how it fits with the DOM. He shares some eye-opening code snippets, but the game itself is closed source so it leaves something to be desired.
- jcelerier 9y ago
  these barrels remind me of that fun old DOS game, Skunny. Quite fun, very nice port !
flohofwoe 9y ago
You can, but with a lot of caveats: - single-thread CPU performance is pretty much 'good enough' now - WebGL and WebGL2 too, but you have very different performance behaviour than a native GL driver (much higher call overhead for instance) - pretty much all other HTML5 APIs: oh boy what a mess :/ Don't expect a 100 GB AAA Steam game to run on the web anytime soon, but mobile games will port over fine. It's better to define the web as your main platform, and design a new game from scratch around it's limitations. So if you have a project which needs to do 3D rendering, audio, touch input etc... CPU performance is the least of your problems.

yakshaving_jgt 9y ago

So… Who else drew their name?