I've been running https://noclip.website https://noclip.website for a few years now, which, while not a "real-world" workload, clearly approaches the amount of

I've been running https://noclip.website https://noclip.website for a few years now, which, while not a "real-world" workload, clearly approaches the amount of data that a game has to render. Check out e.g. https://noclip.website/#smg/AstroGalaxy https://noclip.website/#smg/AstroGalaxy which approaches the number of draw calls I'd expect a modern game to render with. There are a lot of upsides to running it through the web platform (the big one is that I can give people a link and they can click it, rather than convince them to run an app, but there are others, too). There are downsides: performance is heavily variable. A new Chrome can launch and my performance can be 5x worse than before, which is why I now always test in Canary to make sure I'm ahead of all issues. In Chrome, the WebGL layer is pretty solid, but I still find plenty of bugs and performance issues (e.g. looking at a profile unearthed this very simple issue causing browser resizing to be way slower than it needed to be https://bugs.chromium.org/p/chromium/issues/detail?id=1103473 https://bugs.chromium.org/p/chromium/issues/detail?id=110347... ). Firefox is quite a bit slower and has a bit more draw call overhead than Chrome (I'm guessing they run validation on the main thread rather than an IPC process, causing JS to block) Most of the performance problems I encounter are actually JS-related, it's super easy to be knocked off of a fast path by complete accident, and there aren't good tools to know what I'm doing wrong. Math and ALU is plenty fast -- doing matrix multiplication on the CPU has never been a bottleneck, and you actually want that more on the CPU so that the GPU doesn't have to run a matrix mul for every pixel. Uniform data computation belongs on the CPU. My big thing that I fight is the garbage collector, and you can see the awkward "manual register allocation" code style I sometimes resort to to make sure my allocations per-frame are super minimal, especially in fast math code. It doesn't look like traditional ergonomic JS code: https://github.com/magcius/noclip.website/blob/master/src/SuperMarioGalaxy/Shadow.ts#L249-L252 https://github.com/magcius/noclip.website/blob/master/src/Su... I could go on if wanted but this comment is already getting pretty long.