Experiment with particles using WebAssembly and WebGL(maierfelix.github.io)
maierfelix.github.io
Experiment with particles using WebAssembly and WebGL
https://maierfelix.github.io/wasm-particles/static/
58 comments
That is correct; it is the WASM binary http://webassembly.org/docs/binary-encoding
Crashes in latest Chrome and Safari on latest iOS (11.1.1). Will have to try on desktop later.
Chrome on iOS is just a wrapper around a safari web view, plus some nice to haves.
Same behavior observed here too.
Same behavior observed here too.
I thought it was using wkwebview, which is faster than uiwebview, but still behind safari in terms of js performance on iOS.
> 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.
I’m aware, thanks. I tested in both anyway just to have more data.
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)
All demos I saw only gives 8-10x performance boost?? (with respect to JS)
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.
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.
WASM is not native code, so there's no guarantee it will have the same performance. There have been earlier attempts to have cross-browser and cross-platform native code execution on the web, not to mention plenty of nonportable web plugins, but WASM's just-in-time compilation of a low-level bytecode is a good balance between performance across different architectures and feasibility of sandboxing code execution (you don't want a web app to gain access to your filesystem and kernel syscalls with impunity)
> 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 ;)
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 ;)
> 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
and potentially runtime, depending on the language you are compiling from
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.
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.
> Impressive.
... is it ? tech demos ten years ago were already north of 1 million particles.
https://www.youtube.com/watch?v=3xN2PkxNRHs
... is it ? tech demos ten years ago were already north of 1 million particles.
https://www.youtube.com/watch?v=3xN2PkxNRHs
Is performed on CPU; example you linked is performed on GPU so JS speed isn't a factor
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.
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
Looking at the source, seems they render all the points in software (WASM) to a 2D texture then to the screen.
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.
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?
How does it work? What sort of VM is it running on? How is it compiled?
User rossisred ported his "Funky Karts" game from C++ (targeting Android) to WASM.
Direct link to the game: https://www.funkykarts.rocks/demo.html
Blog post on porting the engine: http://www.rossis.red/wasm.html
Original thread: 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.
Direct link to the game: https://www.funkykarts.rocks/demo.html
Blog post on porting the engine: http://www.rossis.red/wasm.html
Original thread: 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.
these barrels remind me of that fun old DOS game, Skunny. Quite fun, very nice port !
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.
- 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.
> mobile games will port over fine.
If they take advantage of OpenGL ES 3.0, 3.1 and 3.2 features not present in WebGL, it is going to be a bit hard.
If they take advantage of OpenGL ES 3.0, 3.1 and 3.2 features not present in WebGL, it is going to be a bit hard.
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/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.
Here's a 2014 Unreal Engine asm.js demo now running on WASM:
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.
Is there an performance gain in using WASM?
The last point in my handy WASM FAQ explains the main reasons why WASM (and also asm.js) is faster than 'idiomatic' Javascript:
http://floooh.github.io/2017/06/09/webassembly-demystified.h...
http://floooh.github.io/2017/06/09/webassembly-demystified.h...
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.
Wasn't the main point of WASM that it is faster to parse than JavaScript?
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 :)
edit: * at least in Firefox, Chrome still has some... potential :)
> 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).
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).
It's one of the main points, yes.
Parsing isn't the only aspect of overall performance, though.
Parsing isn't the only aspect of overall performance, though.
[deleted]
It's possible to come up with a close result with JS, but with WASM you have a lot space to add more things on top than just moving a particle back to it's origin.
Crashes on Safari Nightly and Firefox Nightly, but very neat when it works! :)
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.
Did it just straight-up crash on Firefox for you? It seems to work well on my Nightly.
It worked on yesterday's Nightly, then I updated to today's and it crashed immediately.
You should file a bug! I only started doing so a few weeks ago, and the devs have been pretty responsive.
No kidding! It took them all of 24h to get it sorted, impressive. :)
Works on Android Firefox nightly (surprisingly).
Firefox 58, 60FPS.
Chrome: 40 FPS
Chrome: 40 FPS
So… Who else drew their name?
3 fps?
only 56fps for 900k particles, expected steady 60fps
I get 23 on a beastly desktop with dual GeForce 980Ti. Not bad for 1.8 million particles!
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?
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?
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
EDIT: Ah just noticed I'm only using 586k particles.
EDIT: Ah just noticed I'm only using 586k particles.
17fps with 712000 particles on a Nexus 6P. That's really impressive.
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).
I wonder what an iPhone would get, I'm led to believe their GPUs are pretty strong (to say the least).
Quite interesting to read. I don't know much about WASM but I presume the big Uint8Array is the actual C program or something?