Collaborative Map-Reduce In the Browser 188
igrigorik writes "The generality and simplicity of Google's Map-Reduce is what makes it such a powerful tool. However, what if instead of using proprietary protocols we could crowd-source the CPU power of millions of users online every day? Javascript is the most widely deployed language — every browser can run it — and we could use it to push the job to the client. Then, all we would need is a browser and an HTTP server to power our self-assembling supercomputer (proof of concept + code). Imagine if all it took to join a compute job was to open a URL."
Random Thoughts (Score:5, Interesting)
Two comments:
1. He places the map/emit/reduce functions in the page itself. This is unnecessary. Since Javascript can easily be passed around in text form, the packet that initializes the job can pass a map/emit/reduce function to run. e.g.:
In fact, the entire architecture would work more smoothly using AJAX with either JSON or XML rather than passing the data around as HTML content. As a bonus, new types of jobs can be injected into the compute cluster at any time.
2. Both Gears and HTML5 have background threads for this sort of thing. Since abusing the primary thread tends to lock the browser, it's much better to make use of one of these facilities whenever possible. Especially since multithreading appears to be well supported by the next batch of browser releases [owensperformance.com].
(As an aside, I realize this is just a proof of concept. I'm merely adding my 2 cents worth on a realistic implementation. ;-))
A bunch of problems (Score:2, Insightful)
I think this approach to MapReduce is a pretty creative angle to take on it. However, there are a number of distributed systems-type problems with doing it this way, that would need to be solved to actually make this realistically possible:
1) The dataset size is currently limited by the web server's disk size.
Possible solution: push the data to S3 or some other large store.
2) There is a single bottleneck/point-of-failure in the web server. In theory 10,000 clients could try to emit their map keys all at once to the web server. IIRC, Google's mapreduce elects nodes in the cluster to act as receivers for map keys during the map/sort phase.
Possible solution: Again, if you were using S3, you could assign them temporary tokens to push their data to S3 -- but that would be a large number of S3 PUT requests (one per key).
3) Fault-tolerance -- what happens when a node in the browser compute cluster fails for any of N reasons? How does the web server re-assign that map task? You'd especially want to ensure that computation finishes on a job in an unknown environment such as 1,000,000 random machines on the internet.
Possible solution: If you haven't heard from a node in N seconds, you could reassign their map task to someone else. This is a similar idea to the MapReduce paper's description of sending multiple machines on a single map task, and racing them to the finish.
4) Security -- there is no way to deterministically know whether the data emit()ed from a user's browser session is real or not. How do you trust the output of 1,000,000 users' Javascript browser executions (I think the answer is, you don't).
Re:A bunch of problems (Score:4, Insightful)
Further down in the Slashdot comments, a poster also pointed out that Javascript is a poor platform for computationally intensive work. Which I agree with on a general level. The Javascript number system is designed for genericity, not performance.
In the end this is just a cute idea that has any number of practical problems. Many of them reflect the fact that distributed computing is hard, but many of them also reflect the fact that the suggested platform is less than ideal for this function. Especially if you're going to be pushing workloads that take more time and resources to transmit back and forth than to simply compute them.
Doesn't stop me from humoring him, though. We all have to dream. ;-)
And besides, this may just inspire the next fellow down the line to use the technology for a more practical purpose.
Re: (Score:2)
Re: (Score:2)
Unity [unity3d.com] (a game development platform) translates JavaScript (and Python) into .NET CLR opcodes and then runs them via Mono, which ends up being quite a bit faster than just running the JavaScript in a traditional interpreter.
SquirrelFish (a bytecode interpreter in WebKit) and V8 (a native JIT compiler in Chrome) are also available to speed things up.
Looking at it from the .NET CLR bytecode perspective, Silverlight 2.0 is available on Windows platforms and OS X (Intel); once Moonlight hits 2.0, that'll make a
Re: (Score:2)
Problem 3 has to be solved in any real-world implementation, so is pretty obvious (and tractable with timeouts etc) imo.
Problem 4 is the tough one - you can either slug your performance hard by running calculations multiple times, or you figure out some way to authentica
Re:New concept for worms... (Score:2)
AJAX + self updating js saved in cookies
Re: (Score:2)
Local Storage APIs would probably work better. The entire data set could even be dumped to local storage to allow recovery from browser failures. In addition, using the SQL engine of the Local Storage database can speed up certain sorting and aggregation tasks, thus (potentially) allowing for a faster response than making Javascript do all the heavy lifting.
Re: (Score:2, Informative)
What does Java have to do with anything?
Maybe you should try reading the post you're responding to?
Re: (Score:2)
There is a very tenuous connection.
First note that ECMA script is the core language. Add a few fewtures and you have the cross browser script base. The (cross browser script base)+DOM is what is portable between browsers.
I use the term cross browser script base, because unfortunately there really is no name for this language.
Everybody implements something that is basically an extended version of the cross-browser base script.
Microsoft calls their implementation JScript.
Netscape (and now Mozilla) call their
Re: (Score:3, Interesting)
I found this somewhat startling:
http://code.google.com/p/doctype/wiki/ArticleHereComesTheSun [google.com]
If you create a javascript object named 'sun' (or several other names), netscape and family (including firefox) load java into memory.
Re: (Score:2)
Translation: Who wants a patent suit from Digg.com?
Re: (Score:2)
And then Firefox (or Epiphany) pops up a dialog after JS maxes out the CPU for 30 seconds asking if you want to permit the execution to continue.
So you have to limit yourself to 20 seconds per page load, and have the overhead of using Javascript as opposed to a better language like Java. Actually, a Java applet seems like what you would really want to do if you were re
The future of banner ads? (Score:3, Interesting)
Re: (Score:2, Insightful)
high-volume sites such as /. could support themselves by taxing, say, 10% of a viewer's CPU with an unobtrusive background thread
What happens when I open 15 tabs at 10% each?
Re: (Score:2)
*ahem* I mean, the script could set a "last batch accepted" timestamp in a cookie or somesuch when it starts, and delete the cookie when it's done, and only run a processing batch when either it can't find a cookie or it's been 10min since the last task.
Re: (Score:2)
Who wants to open up a page that suddenly uses all of their cycles and makes their computer useless for anything else while this is running.
Can you actually do that on a modern OS and a modern CPU? I regularly have my CPUs on 101% load and it stays snappy as ever. Only heavy I/O on the system drive makes it unresponsive. This applies for both Gentoo and Vista. (The default install of Linux Mint, however, sucks horribly.)
Re: (Score:2)
Slashdot manages it on an eee and xubuntu. Both were developed recently, if that counts as 'modern'.
Slashdot managed to freeze firefox for 5-6 seconds on a Core 2 Duo, until I disabled Javascript for it. Now it behaves.
Re:Java (Score:2)
Actually, once upon a time, there was a distributed Java applet [archive.org], alot like BOINC but in a browser. This particular project was about calculating the emission of gamma rays from nuclear waste.
It didn't last long, probably about a year or two, but it did get quite a few results.
Re: (Score:2)
Botnet (Score:4, Insightful)
Imagine how much *spam* you could send using this approach.
No, wait...
Re:Botnet (Score:5, Insightful)
With ever-increasing JavaScript performance, there's a lot of cpu power available for cracking passwords and captcha's... Just include the code in an ad and you're done. No tricky installs needed, just the idletime of the user's web browser.
Rather have a cold PC (Score:3, Insightful)
-B
Re: (Score:2)
I really don't think laptops were designed to run at 100% all the time anyway, so yeah, I'd avoid any distributed computing projects on your computer.
I run it on my two desktops at home though, and there's barely any difference in my electric bill. Idle vs load for me is about 40W difference -- I could save more by turning off a fairly dim bedside lamp.
Re: (Score:2)
I configured my desktop machine at home to suspend when I hit the power button. I only use it for games, so it's never fully powered on throughout the day. My electric usage would definitely go up a bit if it was always powered on running compute-intensive software.
-B
Re: (Score:2)
Well, a light on each side of the bed is handy for those of us who don't sleep alone...
Re: (Score:2)
Re: (Score:2)
This is eerily plausible, but I think there's one thing keeping this from becoming a massive problem:
Anyone running a legitimate site will kick their advertiser to the curb if their ads start sucking down lots of CPU. The only people who'd allow this sort of advertising
Re: (Score:2)
You don't see many Russian malware authors writing CureForCancer@home or StemCellSim@home, do ya?
No, but you might meet some of their representatives in person (for the first and last time IYKWIM) if you start implementing this and undercutting their networks.
Join compute cloud (Score:5, Insightful)
BOINC (Score:5, Insightful)
If you were really interested enough to donate your CPU cycles, is it really that much harder to install BOINC, and get a job running?
Plus then you can run native code instead of having to run in [shudder]Javascript[/shudder].
Re: (Score:2)
BOINC is quite possibly the single worst bit of software I've ever seen. It's kind of like the team did a detailed study of the best practices for software usability and then did the exact opposite.
Re: (Score:2)
If you're talking about the UI, then I'll agree it needs a bit of work, but then it is still a "nerd project" at this point. With any nerd project, the interface is at the bottom of the TODO list.
If you're talking about the code, care to explain? I've never looked at it.
Re: (Score:2)
With any nerd project, the interface is at the bottom of the TODO list.
Which is exactly why many people won't use many of these tools even if the tool is "better." UI is extremely important for most people to consider using a tool.
Re: (Score:2)
I don't get what's the big problem people have with "[shudder]JavaScript[/shudder]".
It's a Turing-complete language, which means it can be used to do anything from simple form validation to ray tracing and neural net simulations.
With AJAX to handle file interactions, I don't understand the problem that people have with it. What is it that you think JavaScript can't do that 'x' language can?
I wish people would get over this childish bias and accept that JavaScript is a /real/ language, and not
Re: (Score:3, Insightful)
A big thing is the same thing people have against VB: there may not be anything technically wrong with it, but bad programmers are drawn to it because it's easy, so you hardly ever see a good VB program. There's especially nothing wrong with VB now, when writing a program in VB.NET gets you the same result as if you'd written it in C#: you still get CIL code when it's compiled.
However, Javascript gets used for way too much, and historically it's been a huge browser security issue. Even if you use it respons
Re: (Score:2)
I'd like to see Javascript elsewhere. In the browser, it's limited by that turd known as DOM... imagine what Javascript could do if it had libraries that weren't utter shite. It could easily take over all the tasks done by Lua now, and possibly most of Python and Ruby as well.
The problem is people get into web development, find out that DOM is crap, then they assume the problem is Javascript and not DOM. JS is fine; DOM would be just as crap if you were working with it in Python.
Re: (Score:2)
It's certainly not the exact opposite of "utter shite" but JavaScript on Windows via Windows Script Host has lots of libraries immediately available which makes a lot of tasks on Windows (including administration) much easier via the FileSystemObject, WMI, etc.
Beats the crap out of cobbling things together with BAT files.
Re: (Score:2)
> have you actually tried to write something in javascript?
yes. I'm the author of KFM [verens.com] as well as a [verens.com] few [verens.com] little [verens.com] tricks [verens.com]
> what works in one browser doesnt work in another...
jQuery, ProtoType, MooTools, Ext, etc
> the number of simple functionalities that are
missing sleep() for instance?
can be emulated with setTimeout().
PHP has array_merge() but C doesn't. Does that mean that C is crap?
> and its only just recently got threading support
again, could be emulated with setTimeout(). Even for
Noscript (Score:5, Informative)
Progress is running less JavaScript, not more.
Re:Noscript (Score:5, Funny)
Re:Noscript (Score:5, Insightful)
Actually it was the '90s, but whatever. The thing is, non-DHTML web pages are actually pretty good for most things... what made those early '90s web pages so awful was no CSS, slow connections, and the fact that people really didn't know how to design for this new medium.
Probably 99% of the web still shouldn't need Javascript or flash, though pages usually do need to be dynamic on the server side.
Re: (Score:2)
But the argument against javascript is one that is countered by your own comment: "the fact that people really didn't know how to design for this new medium".
Javascript is a tool just like another on the Internet. It can be used for good or evil depending on who writes the program. And as you mentioned, retreating from javascript means going back to a purely
Re: (Score:2)
Actually it was the '90s, but whatever. The thing is, non-DHTML web pages are actually pretty good for most things... what made those early '90s web pages so awful was no CSS, slow connections, and the fact that people really didn't know how to design for this new medium.
Sure it's fine when you've got a 2GHz processor and a smack of RAM to compile and run an interpretive language -- with the sole purpose of relatively simple data manipulation, validation, and perhaps some light processing to kick a chunk of data back. But when you are talking about serious data crunching, you want code running natively, not in a locked down little box, like SETI@Home, and optimized for that architecture and platform.
People think because you can put it on the web, you should. That is, at bes
Re: (Score:2)
Re: (Score:2)
1. Non-essential visual effects (most of which are part of current web standard drafts)
2. Slideshows (with a "manual" fallack, of course)
Re: (Score:2)
I think that opinion, although quite frequently espoused on slashdot, suffers from a problem of framing current technology around past application models. Technology for technology's sake, such as Web 2.0 using AJAX/Flash, is not a wasteful exercise. Technology doesn't only stem from innovation; a good chunk of innovation stems from technology. The efforts with Web2.0 are leading to furthering the refinement of cloud computing and distributed,
Re: (Score:2)
You keep your noscript plugin, and I'll keep intuitive webUI.
'Intuitive' web UI doesn't need JavaScript -- it can be done purely with CSS.
Example [meyerweb.com]
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
I don't use noscript. However, I dislike most flash- and javascript-based UIs. They're often heavy and unintuitive, and they usually break the back button, deep linking and "open in a new tab".
What's more, javascript-intensive UIs are terrible for the disabled, for scripts, for search engines, and often for mobile devices as well.
That's not to say that Javascript is useless, or even Flash. They have their place in web design, but they do give designers an awful lot of rope.
Re: (Score:2)
Which is to say that Javascript is the future of all computing progress.
"First they ignore you, then they ridicule you, then they fight you, then you win." --Mahatma Gandhi
Mwuhahaha! MWHahaha! MUHAHAHAAAAAAaaaaaa--
*cough* *cough* *wheeze* *sputter* *wheeze*
*clears throat* 'scuze me!
MWUHAHAHAAHAHAAAA!!!! :-P
Re: (Score:2, Informative)
"First they march you through hundereds of miles of jungle without food or water, then they shoot you, then they disembowel you, then you lose." --Mahatma Gandhi, had the Japs won WW2.
Re: (Score:2)
Yeah, yeah, and Usenet was the ultimate discussion group and everything's been downhill from there, right? And 25x80 column monitors were plenty (who needs proportional fonts?) and color is way overrated, and...
Why is it that we always need the previous generation twho remembers "what it was like before all this newfangled nonsense" to die off before we can make progress?
Just because you're looking for the web to look like a static newspaper doesn't mean the rest of the world wants the same thing.
Re: (Score:2)
Just because you're looking for the web to look like a static newspaper doesn't mean the rest of the world wants the same thing.
There are situations where JavaScript is good, but it simply breaks things like the ability to bookmark your page and then restore it as it was from the bookmark. Then you have the sites which really abuse it: for example, you can't book a flight with Ryanair if you have JS disabled (or a browser which doesn't support it: they don't seem to have come across the concept of degrading gracefully).
Re: (Score:2)
How come the new kids who come in can't tell the difference between progress and two-steps-forward-two-steps-back? You make a valid point that some people resist change for poor reasons, but I would say an equal or greater problem is people embracing change for poor reasons.
DHTML is fine when it works, and it's just starting to get there. But I'd say that web usability was at an all-time low between 2000 and 2006 when the new kids thought everything should be dynamic without the slightest understanding of
Re: (Score:2)
Haha, his complaint that the 1st column's background colour won't stretch to the height of the 2nd column has been solved for quite some time.
The main problem associated with pure table layouts came from good ol' Netscape 4's inability to render very complex tables quickly; thankfully, those days are long gone. These days it's about usability and searchability, which complex table layouts kill dead.
No one is stopping you from doing pure tables, but the solutions are there in CSS that make things so much bet
Would this work for music? (Score:4, Funny)
You could also use this to index the MP3 files on everybody's hard drives, then share the music just by visiting a URL!! ... oh wait...
Re: (Score:2)
There, fixed that for you.
Why? Why? WHYWHYWHYWHY??? (Score:5, Insightful)
Javascript really isn't suited for this kind of thing, even with worker threads, for two reasons I can think of. First, web clients are transient... they'd have to report back often in case the user clicks away.
But more importantly, Javascript just isn't a good language for massive computation. It only supports one kind of number (double), has no vectorization or multicore capabilities, has no unboxed arrays, and even for basically scalar code is some 40x slower than C, let alone optimized ASM compute kernels. (This is for crypto on Google Chrome. Other browsers are considerably slower on this benchmark. YMMV.)
Re:Why? Why? WHYWHYWHYWHY??? (Score:5, Insightful)
Re: (Score:2)
Or they could use an Applet or JWS and get several times the performance for only a mild reduction in install base. JWS would even be able to run offline or when the browser window's closed and cache some output to a JVM-managed scratchpad file on disk.
Re: (Score:3, Interesting)
It would need to be 10000x at the very minimum.
If a user downloads, say, folding@home, it's running all day, every day, on all cores of the machine, whenever the computer is on and idle, which is most of the time. The user doesn't have to remember to run it, doesn't have to devote screen real estate, attention and so on, and the program is less annoying because of its low priority and relatively low memory footprint (less boxing).
Additionally, the 40x I cited was in the fastest available browser (Chrome),
Re: (Score:2)
In which case, I would find it easy to believe that for every one slashdotter who would install a distributed comput
Re: (Score:2)
Re:Why? Why? WHYWHYWHYWHY??? (Score:4, Insightful)
Javascript really isn't suited for this kind of thing, even with worker threads, for two reasons I can think of. First, web clients are transient... they'd have to report back often in case the user clicks away.
I don't see why web clients being transient is a problem. The whole point of the MapReduce algorithm is that each worker (the web clients in this case) don't need to know anything about what the other worker is doing, what the system as a whole is doing, nor what it had done with any past job.
Re: (Score:2)
I don't see why web clients being transient is a problem. The whole point of the MapReduce algorithm is that each worker (the web clients in this case) don't need to know anything about what the other worker is doing, what the system as a whole is doing, nor what it had done with any past job.
Which is why Map-Reduce is only suitable for "easily" distributed problems. Lucky for Google that almost all their computational problems fit into this mold. But in the rest of the world, this just isn't the case. Which is why Map-Reduce is more interesting and trendy than a solid change in how distributed systems are designed.
Re: (Score:2)
If the user leaves before a task completes, you don't have anything to reduce.
Google's implementation of MapReduce already takes this into account. Haven't you heard of how they just have a bunch of vanilla x86 networked together, and when one of them fails, they just throw it away plug in a new one.
Re: (Score:2)
Javascript just isn't a good language for massive computation. It only supports one kind of number (double), has no vectorization or multicore capabilities, has no unboxed arrays, and even for basically scalar code is some 40x slower than C, let alone optimized ASM compute kernels. (This is for crypto on Google Chrome. Other browsers are considerably slower on this benchmark. YMMV.)
YMMV is true. I see speed differences of x5-x10 between -O3 C code and V8 - significant, but far from x40.
As for having only doubles, that is true for the language, but not for engines, which can implement an integer type as well. This is a little tricky to do, but certainly possible: Anything that starts out as an integer will remain one over addition, subtraction and multiplication; you need to add checks for overflows and to handle division. In other words, developers have the convenience of only work
Re: (Score:2)
Re: (Score:2)
I think you accidentally the last sentence of your post.
Link (Score:5, Informative)
http://en.wikipedia.org/wiki/MapReduce [wikipedia.org]
Re:Link (Score:5, Insightful)
Re:Link (Score:4, Funny)
Re:Link (Score:4, Funny)
Re: (Score:3, Funny)
Here, let me google that for you. [lmgtfy.com]
MapReduce fanboyism (Score:5, Insightful)
Oh, please, make the MapReduce fanboyism stop.
Yes, it's a neat technique. It's also very old and obvious. Google's implementation is also good, but this stuff is just not rocket surgery. It's just a simple pattern of how to massively parallelize some types of computational tasks.
But somehow, just because some dudes at Google wrote a paper about it, it's become the second coming of Alan Turing or something among some silly folks. Hell, a couple of weeks ago somebody was saying on the comments here that MapReduce was a good alternative to relational databases. Now that is silly.
Re: (Score:3, Funny)
rocket surgery (Score:2)
It's probably related to brain science.
I stopped at... (Score:3, Insightful)
"Javascript...â" every browser can run it..."
There is a huge difference between being able to run javascript apps and run javascript apps well - not to forget that a lot of the javascript I see out there really only works on PC's with IE or Firefox, Opera and Safari, especially on OS X seem to have trouble with some sites that aren't coded for compatibility, but instead pushed out quickly with little regard for anything other than IE on Windows.
Bandwidth and Exercise (Score:4, Insightful)
A common mistake in multi-server builds is that bandwidth is free.
Bandwidth Costs Money and Time. Both are reduced by having the network closer to the processing. This is one of the reasons google bought all that "dark fiber" left around after the .com bust.
Another flaw is that computation of data is difficult to provide "good results" in blocks unless they're doing relativity matrices (Think PageRank).
Something to think about:
If I'm sending names to your pc, what can I derive from that list without having the entire list?
Re: (Score:3, Interesting)
Something to think about: If I'm sending names to your pc, what can I derive from that list without having the entire list?
Frequency of each name? Frequency of characters in names? Bayesian probability of one character following another in names? Number of names of a particular length?
Each worker would compute the stats for their chunk of work (the "Map" part of MapReduce), and then send the results back to the server to be aggregated (the "Reduce" part of MapReduce).
Some of these may seem interesting, but then again, what interesting data can you derive at all from a list of names, even if you had the whole list?
Pay Me (Score:5, Interesting)
If there were a couple-few or more orgs competing to use my extra cycles, outbidding each other with money in my account buying my cycles, I might trust them to control those extra cycles. If they sold time on their distributed supercomputer, they'd have money to pay me.
As a variation, I wouldn't be surprised to see Google distribute its own computing load onto the browsers creating that load.
Though both models raise the question of how to protect that distributed computing from being attacked by someone hostile, poisoning the results to damage the central controller's value from it (or its core business).
Scripts taking too long (Score:4, Funny)
Is this why my browser keeps telling me scripts on the slashdot main page are taking too long and do I want to stop them for the last few months?
Re: (Score:3, Informative)
I sometimes have that with a 1.7GHz box. And even when I don't, reloading the front page of /. makes Firefox sluggish or non-responsive for 5 to 20 seconds.
Re: (Score:3, Informative)
Just change your prefs- under Index/General uncheck "Beta Index" and check "simple design" and "low bandwidth." With those prefs Slashdot loads almost instantly on my somewhat aged machine (P4 2.4) and is still usable on a 700MHz P3.
Re: (Score:2)
Just change your prefs- under Index/General uncheck "Beta Index"
I did exactly that, only to find out that there's nothing on Slashdot to complain about. So I turned it on again.
Re: (Score:2)
I was getting the same thing with my 2.8GHz P4 under Mozilla, but it seems to have gone away since I recently (week ago) switched to SeaMonkey, so it may have more to do with slow JavaScript implementations than clock speed (although obviously a combination of the two).
Self-defeating idea (Score:2, Insightful)
imagine a Beowulf cluster of trojans and drive-bys (Score:2)
hijack-weasels who need to be shot have pretty much ruined the idea of distributed donated computing resources, thanks.
What about the data? (Score:2)
MapReduce is interesting because at Google and Hadoop it has a distributed filesystem underneath it too. The clever part is how data is distributed, and processing is moved to the data rather than moving data to the processing. I don't really see how this really helps matters, unless you are going to have data involved too - which brings in the privacy concerns yadda yadda yadda.
Sure, some things would work that require huge amounts of processing power on limited data, but why would you use map-reduce for t
Inefficiency (Score:2)
This is an old patent application (Score:2)
I'm sorry, but isn't this practically identical to the patent application to use javascript to treat browsers as distributed clients to perform a job like a distributed super computer? The patent application is at http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.html&r=1&f=G&l=50&s1=%2220020198932%22.PGNR.&OS=DN/20020198932&RS=DN/20020198932 [uspto.gov]
Outsourcing? (Score:2)
Remember folks, be sure to filter ALL user input!
Doing Evolutionary Algorithms in the browser (Score:2)
We published a paper that did evolutionary algorithms in the browser some time ago: Browser-based distributed evolutionary computation: performance and scaling behavior [acm.org]. In the same conference, there was another paper: Unwitting distributed genetic programming via asynchronous JavaScript and XML [acm.org]
Look at older projects (Score:2)
http://it.slashdot.org/article.pl?sid=03/12/31/2246241&tid=93
MD5CRK used a JavaApplet that used this Chinese Lottery concept. The applet performed 95% as fast as a pure C implementation of MD5. JavaScript is another matter however. And an assebly code that inlieved MMX/SSE with ALU was much faster.
Background threads in browsers will help of course.
Re: (Score:3, Insightful)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)