I compiled hello world in Rust into wasm the other day for the first time and it was incredibly satisfying for whatever reason. New technology is fun I guess.
Note: This page isn't rendering properly on iPhone
We've done some initial tests ourselves. WASM doesn't yet support SIMD so WebGL tends to be 5-10x faster. SIMD is actively being worked on by many smart people in Chromium / other browsers, so I would expect to see huge wins in the near term future. When that happens, deeplearn.js will have a WASM backend. WASM has a much better memory management story (destructors on the C++ side) so I'm super excited about its future.
GPUs are at least an order of magnitude faster at training neural nets than CPUs. This is why companies like Google very large amounts of multi-thousand dollar GPUs like the Tesla V100. If cpu WASM is ever faster than WebGL, it's just that the webGL implementation is suboptimal (or that WebGL has too much overhead for real GPU compute)
So what's the explanation for the 20x difference? Is the JS implementation untuned?
edit: seems the JS is written in the straightforward, idiomatic JS way without employing speed hacks or typed arrays. So that I guess explains some of it.
My comment was meant to imply that if you're using JS, then you already care about other things _more_ than you care about performance.
Once you've decided that you do care about those other things, then getting the best performance you can is great and deeplearnjs is very useful.
But if what you care about most is performance, then using JS is not the way to go. I'm guessing deeplearnjs is an order of magnitude slower (at least) for training a modern convnet relative to cudnn or MKL. And I don't think it's currently possible to use multiple GPUs? Although you could imagine some crazy distributed asynchronous training running in browsers all over the world.
The WebAssembly implementation pegs 100% of one CPU core (as monitored in htop) on my system until it is completed.
The JS button sits between 66.2%-66.8% and 19-26% of one core depending on whether the tab is focused or not.
The JS version does not use Web Workers. I can, however, see two references to setTimeout(). This leads me to assume that the JS version is being slowed down so that the UI does not lock up.
Completely understandable, but patently dishonest, as there is no mention of this fact on the webpage.
The JS version should be reimplemented so it can run at 100% speed.
I'm currently re-writing the JS version to not use the setTimeout functions, in favour of just running the whole thing in a WebWorker, to still maintain browser usability.
I'm focusing more on a WebGL version, but once that's done, it should be a fairer comparison.
woah, I never expected this much traffic! Thank you for all the suggestions, don't worry, I am still hard at work on this.
I'm currently most focused on designing and implementing a WebGL version (partially working FC forward shader, so far), between uni assignments, trying to see if I can get it working nicely together with WebAssembly (need to figure out the best way to create the contexts with an off-screen canvas).
The JS version uses setTimeout to stop locking up the browser, and is something old, which I'm about to change, in favour of using WebWorkers, and (optionally) collecting error data in an array, for displaying charts at the end of training, instead of during. That should come out in version 3.3, unless the GPU stuff comes out first, in v4.0.
I didn't expect the link would get posted somewhere, so the library versions used were pretty old, haha, but I'll update them now. I've also added a note about the setTimeout thing, which, again, will be removed soon.
Note: This page isn't rendering properly on iPhone