Experiment with particles using WebAssembly and WebGL | Hacker News Reader

Experiment with particles using WebAssembly and WebGL

maierfelix.github.io

137 pointsSchampu57 comments

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?

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

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

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.

> 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 thought it was using wkwebview, which is faster than uiwebview, but still behind safari in terms of js performance on iOS.

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)

> 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 ;)

> 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

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.

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.

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)

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

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.

Is performed on CPU; example you linked is performed on GPU so JS speed isn't a factor

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.

Weird, it seems to be locked at 60 FPS (with 361k particles) for me. (Firefox Nightly on MacBook Pro 13.)

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?

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.

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.

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.

> 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.

Is there an performance gain in using WASM?

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?

It's one of the main points, yes.

Parsing isn't the only aspect of overall performance, though.

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 :)

> 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).

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.

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...

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

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. :)

It works on my phone's browser (which is a fork of Chrome for Android). No crashes. I even have 34 tabs open.

Likely, 33 of those tabs are suspended?

Well, most of them were suspended but I believe there were still a few that were active at the time.

Works on Android Firefox nightly (surprisingly).

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.

Firefox 58, 60FPS.

Chrome: 40 FPS

I get a steady 60FPS in both FF 56 and Chrome 61/62.

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.

So… Who else drew their name?

3 fps?

I get 23 on a beastly desktop with dual GeForce 980Ti. Not bad for 1.8 million 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 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?

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.

only 56fps for 900k particles, expected steady 60fps

Reply on news.ycombinator.com