Slashdot Mirror
One Processor, 128 32-bit Cores
Max Entropy writes: "EETimes reports that a German company named Pact GmbH has developed a chip containing 128 microprocessor cores as part of the company's 'Extreme Processor Platform' (XPP). 'Each of the XPP's 128 processor cores sports its own 32-bit fixed-point multiplier, yielding a theoretical output of 12.8 billion multiply-accumulate operations per second at an expected clock frequency of 100 MHz. Pact claims the architecture will scale to produce devices capable of more than 400 giga operations/s in 2002 and into the peta-ops range within a decade.' The transistor budget for this behemoth is 30M, fabricated on a 0.21-micron process." Of course, each one of those processor nodes is completely proprietary and requires some peculiar programming.
'Each of the XPP's 128 processor cores sports its own 32-bit fixed-point multiplier, yielding a theoretical output of 12.8 billion multiply-accumulate operations per second at an expected clock frequency of 100 MHz. Pact claims the architecture will scale to produce devices capable of more than 400 giga operations/s in 2002 and into the peta-ops range within a decade.'
Mother of God! The first time some fool runs Quake IV Slaughter on a Beowulf cluster of these puppies (you knew that had to get in here somewhere), it'll instantly self-evolve into Quake X^100 and wipe out the human race!
A truly excellent pizza parlor is a delight unto the heavens. Treasure the sauce and the toppings!
Lets see. There is a mention of this that is still on the front page. Uhm... you guys really need to get together and talk, or at least read Slashdot before you post new articles.
Seriously, the editors need to start reading Slashdot more often. I know timothy posted this at 5:23 AM and he probably wasn't thinking clearly, but the quality of the articles is becoming a joke.
I have lost count of the number of duplicate articles that appeared on the same day. Or is this a side effect of Slashdot getting hacked (rouge processes non-deterministically posting articles)
If I were a Troll Brigadier, I might seriously think about posting stories straight into comments, and then having them "voted on" by moderators. Hence (once again!) you've hijacked Slashdot.
Will Taco flame me on IRC for this? Damn, I hope so! Think of the Dark Side Geek Aura!
be well;
JC.
--
"Don't declare a revolution unless you are prepared to be guillotined." - Anon.
Classical Liberalism: All your base are belong to you.
He eventually went to work around Beaverton Oregon for one of those silicon foundries, but I think he got more interested in parallel, hardware regular expression evaluators.
Seastead this.
Timothy doesn't read Slashdot
Posted by timothy on 04:20 AM April 1st, 2001
from the at-least-read-the-front-page dept.
Frac writes: "It seems rather obvious that timothy doesn't read Slashdot, considering that the an article still on the main page mentions the exact same news." Interesting stuff. And in other news, there are now proton polymer batteries available, results from ICANN elections, and a really interesting article at ZDNET on reverse-engineering.
Before you go off on tirades, maybe analyse what you're about to say first. First, there's nothing magical about QNX or BeOS. Sure, BeOS apps may be automatically multithreaded, but only in a relatively superficial way (by putting the message loop into a separate thread if I'm not mistaken). BeOS certainly doesn't take your linear code and somehow magically extract multiple threads of execuion--you still have to do the leg work. Same with QNX. Same with WinNT/2K, if you multi-thread you apps, they will spread quite nicely across CPUs (though HOW nicely is a matter of debate for the religious). Don't get me wrong, I think what BeOS is doing is perfectly fine and laudable, but it's not exactly what you're implying.
The fact is, in you model the unit of execution is the thread. What you yourself don't know how to de-serialise and pull into separate threads (and properly synchronise), the compiler or OS certainly won't do for you. So even if your app is multithreaded, if your threads are big fat chains of serial code, the app won't benefit any from multiple CPUs. The holy grail of MP is a compiler that could, for a trivial example, look at your loop and be able to unroll it into x smaller loops working on subunits of the data.
One of the big promises of MP is to avoid the end of Moore's law through parallel computing, IN GENERAL PURPOSE COMPUTERS, not just arcane research machines. We already know how to tickle esoteric MP hardware today into doing our bidding, but it's no trivial task and takes a lot of skill. If MP is to give us a mainstream migration path from single processing, it can't expect more from programmers than they can give today. In other words, MP machines will have to deliver even with mediocre programmers, because they form the bulk of the work force. You can't stipulate as a condition for effective MP an overall higher quality work force, because it ain't happening.
Note that this is NOT necessarily a general-purpose system. It seems currently intended more for high-volume data manipulation. On the other hand, I think that it would do a peachy job on many image rendering problems (for ray tracing, you could assign one processor to a group of rays). It would also be great for multi-threaded applications (Each process gets a handfull of processors). For Seti@Home, I think that it would kick butt. On the other hand, it would suck on a single task that was indivisibly serial (only a handfull of the 128+ processors doing anything).
Note that some processes that seem inherently serial (summing data from a single stream) are actually quite parallelizable (N processors each gets 1/Nth of the stream and pass their intermediate results, on demand, to a supervisor processor that totals the intermediate values.)
`ø,,ø`ø,,ø!
Free Software: Like love, it grows best when given away.