If you care about performance use GPU shaders.
If you care about performance, don't use JS for training neural networks.
MNIST training: Showdown between JavaScript and WebAssembly
21–30 of 34 posts
Re: MNIST training: Showdown between JavaScript and WebAssembly
#22Re: MNIST training: Showdown between JavaScript and WebAssembly
#23It would be a more fair comparison to https://deeplearnjs.org/ , since CPU training is not standard practice for neural nets these days.
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 futu…
Re: MNIST training: Showdown between JavaScript and WebAssembly
#24This seems like a race between crawling and hopping on one foot.
Re: MNIST training: Showdown between JavaScript and WebAssembly
#25If you care about performance use GPU shaders.
https://github.com/pair-code/deeplearnjs
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.
Re: MNIST training: Showdown between JavaScript and WebAssembly
#26This is NOT a fair and honest comparison.
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.
Re: MNIST training: Showdown between JavaScript and WebAssembly
#27I 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
Re: MNIST training: Showdown between JavaScript and WebAssembly
#28PLEASE NOTE This is NOT a fair and honest comparison. 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…
Re: MNIST training: Showdown between JavaScript and WebAssembly
#29PLEASE NOTE This is NOT a fair and honest comparison. 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…
It's still an order of magnitude slower though at least on my machine
Re: MNIST training: Showdown between JavaScript and WebAssembly
#30My browser at least seems to struggle to download the file at https://ai.danruta.co.uk/webassembly/mnist.js - how big is this file in total?
It is 20 Megabytes, transmitted gzipped at 2.4 Megabytes. It is super slow to grab though, due to the other end.