QMachine – a supercomputer made out of crowdsourced Web browsers
qmachine.org
qmachine.org
(Tack on another order of magnitude or two if we're talking about something like GPU computation, which I would not yet trust in WebGL, even ignoring the problem of bandwidth for the problem specification. If you work the math, it becomes difficult to overcome orders of magnitude in performance differences by throwing lots of slow resources at a problem, because you get to the point where it becomes impossible to make up the difference due to additional communication overheads.)
This basically limits this "supercomputer" to embarrassingly parallel problems that have very small specifications, for which performance is no particular concern, including the fact that one does not even know how much resources you will have for the problem on a second-by-second basis. This is not a large niche, but it can be fun.
And even if your JS is running at native speeds, it doesn't solve the bandwidth problem, which is nowadays arguably the distinguishing characteristic of a supercomputer, since the compute nodes of a supercomputer are hardly any faster than a commodity desktop anymore. (Some, yes, sure, but nowhere near the multiples there used to be.)
> his basically limits this "supercomputer" to embarrassingly parallel problems that have very small specifications
note support for map-reduce so it goes a step beyond "embarrassing" (map).
> It's hard to imagine a workload in which this would be the truly best solution.
Biology offers a few examples - typically (alignment-free) sequence analysis is limited by memory, not by communication, so being able to reach a large number of volunteers may be more significant that the time it takes for each of them to communicate their piece of the problem. Here's an example: http://www.almob.org/content/7/1/12
I'd love to see the programming language that's an order faster than Google V8. See http://benchmarksgame.alioth.debian.org/u32/javascript.php and play with it a little bit ;-)
asm.js may overcome that to some extent, but as I mentioned elsewhere, the real problem is bandwidth. Frankly you could run things effectively instantaneously on the client side, and still end up with wildly worse performance on this sort of cluster than a real supercomputer.
As for bandwidth, there is no reason to believe that bandwidth is an issue for all parallel architectures. Stream processing works very well under the given constraints, for example.
Yes, along with a ton of other languages. It is well known that if you use a slow language to set up problems for code written in fast implementations, the result can still be quite fast, but it's the fast bit, not the slow bit that's responsible. See also NumPy. It's not Javascript being fast, it's the regex engine. If what you're doing is regexes, it's almost certainly more efficient to just do the regexes than to try to ship the relevant strings down over commodity internet connections... which is, indeed, exactly why you don't take this approach in your code.