Except that instead of running SETI@home, they used heavily FPGA optimized designs. Since most radio astronomy only requires a few bits of precision (2-8) modern CPUs or GPUs are incredibly wasteful for them. So intead they use heavily optimized fixed-point math circuitry. By using FPGAs they can keep them easily reconfigurable and get enough throughput to deal with e.g. Hat Creek (http://en.wikipedia.org/wiki/Hat_Creek_Radio_Observatory).
The RAMP project (http://ramp.eecs.berkeley.edu/) tried that. We're actually looking for a old priest, a young priest and a couple of virgins. We haven't been able to get near the rack since we booted it up, and frankly the blood pouring from the faucets is starting to make a mess.
I find it amusing that the original post was by "BadAnalogyGuy" and you just used one.
Why do Java and.NET have better memory management? So that it's easier for people to work with memory. Why does ParLab exist? So that it will be easier to work with parallelism.
Part of the goal here is to make it so that, like with memory management, someone who knows what their doing (i.e. a hardcore manage-their-own-memory assembly or C++ programmer) can write a large parallel library, and someone who doesn't (i.e. a newbie-MCSE-.NET-programmer) can use it to solve a real problem.
Methings your argument supported the opposite conclusion from the one you drew.
Ironically the folks in ParLab (*ahem*) just arranged a field trip to meet with some of the people who do that kind of work. We read slashdot too you know...
But try putting that GeForce in your cell phone. And don't come crying to us when your ass catches on fire from the hot cell phone on your back pocket. Or for that matter when your pants fall down from carying the battery around.
If you want a more technical reason DRAM and CPU's don't go together, spend an informative hour looking up the IC fab process for CMOS logic (CPUs) and DRAM. They're VERY VERY different. DRAM needs capacitory density to get the price-per-bit down so they use their own custom fabs optimized for that. This makes it really hard to fit lots of logic and DRAM on to one chip.
ParLab is so not about branch predictors and out-of-order execution. As you say, that's a hardware design problem and a solved one at that. Boring.
While I'll agree that not all programmers are stuck with the serial programming model, threads aren't exactly a great solution (http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.html). They're heavyweight and inefficient compared to running most algorithms on e.g. bare hardware or even an FPGA. Plus they deal badly with embarrasing parallelism (http://en.wikipedia.org/wiki/Embarrassingly_parallel). And finally they are HARD to use, the programmer must explicitly manage the parallelism by creating, synchronizing and destroying threads.
Setting aside those problems which exhibit no parallelism (for whom there is no solution but a faster CPU really), there are many classes of problems which would benefit enormously from better programming models, which are more efficiently tied to the operating system and hardware rather than going through an OS level threading package.
The funding being announced here is for ParLab whose mission is to "solve the parallel programming problem". Basically they want to design new architectures, operating systems and languages. And before you get all "we tried that an it didn't work" there are some genuinely new ideas here and the wherewithall to make them work. ParLab grew out of the Berkeley View report (http://view.eecs.berkeley.edu/) which was the work of very large group of people to standardize on the same language and figure out what the problems in parallel computing were. This included everyone from architecture to applications (e.g. the music department).
RAMP is a multi-university group working to build architectural simulators in FPGAs. In fact you can go download one such system right now called RAMP Blue (http://ramp.eecs.berkeley.edu/index.php?downloads). With ParLab starting up there will be another project RAMP Gold which will build a similar simulator but specifically designed for the architectures ParLab will be experimenting with.
As a side note, keep in mind when you read articles like this that statements like the "Microsoft BEE3" are amusing when you take in to account that "B.E.E." standards for Berkeley Emulation Engine. Microsoft did a lot of the work and did a good job of it, but still...
Slashdot Mirror
Actually, if you check out the BEE2 website (http://bee2.eecs.berkeley.edu/, BEE2 being the precursor to BEE3) you'll notice a Casper (http://casper.berkeley.edu/) logo in the upper left. That is the SETI folks!
Except that instead of running SETI@home, they used heavily FPGA optimized designs. Since most radio astronomy only requires a few bits of precision (2-8) modern CPUs or GPUs are incredibly wasteful for them. So intead they use heavily optimized fixed-point math circuitry. By using FPGAs they can keep them easily reconfigurable and get enough throughput to deal with e.g. Hat Creek (http://en.wikipedia.org/wiki/Hat_Creek_Radio_Observatory).
The RAMP project (http://ramp.eecs.berkeley.edu/) tried that. We're actually looking for a old priest, a young priest and a couple of virgins. We haven't been able to get near the rack since we booted it up, and frankly the blood pouring from the faucets is starting to make a mess.
Bugger. I read the GP again, and he might've been making exactly the same point I just did. Oops.
I find it amusing that the original post was by "BadAnalogyGuy" and you just used one.
.NET have better memory management? So that it's easier for people to work with memory. Why does ParLab exist? So that it will be easier to work with parallelism.
Why do Java and
Part of the goal here is to make it so that, like with memory management, someone who knows what their doing (i.e. a hardcore manage-their-own-memory assembly or C++ programmer) can write a large parallel library, and someone who doesn't (i.e. a newbie-MCSE-.NET-programmer) can use it to solve a real problem.
Methings your argument supported the opposite conclusion from the one you drew.
Ironically the folks in ParLab (*ahem*) just arranged a field trip to meet with some of the people who do that kind of work. We read slashdot too you know...
But try putting that GeForce in your cell phone. And don't come crying to us when your ass catches on fire from the hot cell phone on your back pocket. Or for that matter when your pants fall down from carying the battery around.
ParLab (http://parlab.eecs.berkeley.edu/) is interested in MOBILE computing as well as your desktop.
Interestingly enough, Dave Patterson http://www.eecs.berkeley.edu/Faculty/Homepages/patterson.html, once president of ACM http://membernet.acm.org/public/membernet/storypage_2.cfm?ci=June_2006&announcement=1&CFID=1668767&CFTOKEN=37941036 was once on a project to do that http://iram.cs.berkeley.edu/. Now he's working on ParLab http://parlab.eecs.berkeley.edu/. I don't always agree with him (and vice versa) but he's nobody's fool.
Faith, young grasshopper...
If you want a more technical reason DRAM and CPU's don't go together, spend an informative hour looking up the IC fab process for CMOS logic (CPUs) and DRAM. They're VERY VERY different. DRAM needs capacitory density to get the price-per-bit down so they use their own custom fabs optimized for that. This makes it really hard to fit lots of logic and DRAM on to one chip.
The BEE2 does: http://bee2.eecs.berkeley.edu/wiki/Bee2LinuxKernel.html. The BEE3 wont. But we'll put a linux computer right next to it, just for you. I promise.
ParLab is so not about branch predictors and out-of-order execution. As you say, that's a hardware design problem and a solved one at that. Boring.
While I'll agree that not all programmers are stuck with the serial programming model, threads aren't exactly a great solution (http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.html). They're heavyweight and inefficient compared to running most algorithms on e.g. bare hardware or even an FPGA. Plus they deal badly with embarrasing parallelism (http://en.wikipedia.org/wiki/Embarrassingly_parallel). And finally they are HARD to use, the programmer must explicitly manage the parallelism by creating, synchronizing and destroying threads.
Setting aside those problems which exhibit no parallelism (for whom there is no solution but a faster CPU really), there are many classes of problems which would benefit enormously from better programming models, which are more efficiently tied to the operating system and hardware rather than going through an OS level threading package.
No, but that's the name of one of our computers that we use with the BEE2s ahref=http://bee2.eecs.berkeley.edu/rel=url2html-27089http://bee2.eecs.berkeley.edu/>.
We have "beehappy", "newbee", "beehive" and even "sting". The tradition of using bad puns to name computers lives on!
Actually RAMP Blue (the precursor to what ParLab used) had 1008. Good times. ahref=http://ramp.eecs.berkeley.edu/index.php?picturesrel=url2html-8126http://ramp.eecs.berkeley.edu/index.php?pictures>
Basically 1000 is the goal, anything over that is a bonus. And yes, we like powers of 2 as much as you.
ParLab (what's being funded): http://parlab.eecs.berkeley.edu/
RAMP (the people who are building the architectural simulators for ParLab): http://ramp.eecs.berkeley.edu/
BEE2 (the precursor to the not-quite-so-microsoft BEE3): http://bee2.eecs.berkeley.edu/
The funding being announced here is for ParLab whose mission is to "solve the parallel programming problem". Basically they want to design new architectures, operating systems and languages. And before you get all "we tried that an it didn't work" there are some genuinely new ideas here and the wherewithall to make them work. ParLab grew out of the Berkeley View report (http://view.eecs.berkeley.edu/) which was the work of very large group of people to standardize on the same language and figure out what the problems in parallel computing were. This included everyone from architecture to applications (e.g. the music department).
RAMP is a multi-university group working to build architectural simulators in FPGAs. In fact you can go download one such system right now called RAMP Blue (http://ramp.eecs.berkeley.edu/index.php?downloads). With ParLab starting up there will be another project RAMP Gold which will build a similar simulator but specifically designed for the architectures ParLab will be experimenting with.
As a side note, keep in mind when you read articles like this that statements like the "Microsoft BEE3" are amusing when you take in to account that "B.E.E." standards for Berkeley Emulation Engine. Microsoft did a lot of the work and did a good job of it, but still...