6 ms·
Browser API calls add 1us of overhead. If your code is conscious of this, then it won’t be a problem. Much of the thought process behind react is to update the
by jkelleyrtp 6y ago
Browser API calls add 1us of overhead. If your code is conscious of this, then it won’t be a problem. Much of the thought process behind react is to update the dom as little as possible, because it usually takes a while to repaint. Similarly, your WASM code will have this small overhead, but even 1000 calls is just 1ms. Regardless, there is still much more performance gains to be had by WASM-compatible languages when providing computationally expensive features.
My favorite example is Rapier http://rapier.rs/ http://rapier.rs/, check out the 3D demos. It blows every JS physics engine out of the water, and it’s using Conrod, a native gui library which has a webgl backend.
- Rochus 6y agoThanks for the link. I tried the cubes 3d demo which takes about 45 seconds on my laptop until no cube moves anymore (around step 590); probably not the expected performance; if I find time I will run the Rust version locally.
- CyberDildonics 6y agoI tried the same thing and it took 4 seconds on my 8 year old computer.
- Rochus 6y agoThanks for the info. My laptop has about the same age. Maybe you have the much faster graphics chip than my HP EliteBook.
- CyberDildonics 6y agoDrawing a few boxes with webgl has nothing to do with a graphics card. This is about webasm which is single core performance.
- Rochus 6y agoFrom https://en.wikipedia.org/wiki/WebGL https://en.wikipedia.org/wiki/WebGL: "WebGL is fully integrated with other web standards, allowing GPU-accelerated usage of physics and image processing and effects as part of the web page canvas" So I would guess that when your graphics chip is faster than mine you get a higher performance.
- CyberDildonics 6y agoThese two things have nothing to do with each other. This is a physics engine running on your CPU, not your GPU. The webgl window is run with your GPU and is extremely simple. Drawing a few dozen boxes is something graphics cards from 22 years ago would have no problem with.
- JoshTriplett 6y agoAnd yet the graphics are actually the performance bottleneck. I tried that on a 4k monitor, and it ran quite slowly. I then made the window smaller, and it ran much faster. It's bottlenecked on the graphics, not on the physics engine.
- CyberDildonics 6y agoI think that says a lot more about your combination of software and hardware than webasm. If someone says "webasm is slow, this demo took 45 seconds to run" and you say "it ran slow for me when I made the window so big that between my browser's webgl implementation, my gpu drivers and my graphics card, a hundred cubes make everything run at 1/10th the speed" what point is that making?
- JoshTriplett 6y agoThis subthread started because two people saw wildly different performance for the same demo, and some attributed that to wasm. My point was that given that the demo seems heavily dependent on graphics performance, it's unlikely that the observed performance differences had anything to do with wasm.
- raxxorrax 6y agoLooks like a nice physics engine, but I wouldn't say it blows JS engines out of the water performance wise. They are surprisingly fast these days. Ammo js: http://kripken.github.io/ammo.js/examples/webgl_demo/ammo.html http://kripken.github.io/ammo.js/examples/webgl_demo/ammo.ht... Ammo wasm: http://kripken.github.io/ammo.js/examples/webgl_demo/ammo.wasm.html http://kripken.github.io/ammo.js/examples/webgl_demo/ammo.wa... They can be faster, but it is still insane how fast JS interpreters have become. So for smaller application it might be ok to stay in JS land.