
QMachine – a supercomputer made out of crowdsourced Web browsers - sktrdie
https://www.qmachine.org/
======
angersock
Sean is a really great guy--glad to see he got something like this working!

------
norswap
Example application? (excepted scientific computing)

~~~
jerf
Fun, probably. It's hard to imagine a workload in which this would be the
truly best solution. Real supercomputers nowadays use immense intra-node
bandwidth, and if you care about performance (and why are you using a
supercomputer if you don't?), languages and environments that run around an
order of magnitude faster than Javascript (on Javascript's best day) even
before we talk about them running on a supercomputer environment, with the
aforementioned bandwidth.

(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.

~~~
wilkinson
> languages and environments that run around an order of magnitude faster than
> Javascript (on Javascript's best day)

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](http://benchmarksgame.alioth.debian.org/u32/javascript.php)
and play with it a little bit ;-)

~~~
jerf
Javascript's speed can be overstated, especially on benchmarks, where
everything can be _just so_ , and maximize the amount of time you spend in the
C portion of the runtime. In practice, you do not get a "mere" 3x performance
loss in Javascript code, especially for things like what supercomputers do. At
least, I haven't seen anyone seriously report that result for anything like
real code.

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.

~~~
wilkinson
Google V8's regular expressions can outrun C for real bioinformatics
workflows, and it's actually not even close. I routinely write JS that outruns
C and C++, and you haven't seen it in reports because my papers haven't been
accepted yet. I doubt that I'm the only person capable of writing "amazing"
code. Do you write JS?

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.

~~~
jerf
"Do you write JS?"

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.

------
cing
A similar service: [http://crowdprocess.com/](http://crowdprocess.com/)

------
jlebrech
where are my QCoins?

~~~
wilkinson
Coming soon, if you'd like to help, actually :-)

