Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

IBM Releases Cell SDK

Zonk posted more than 8 years ago | from the toys-while-waiting-for-the-next-gen-consoles dept.

Programming 207

derek_farn writes "IBM has released an SDK running under Fedora core 4 for the Cell Broadband Engine (CBE) Processor. The software includes many gnu tools, but the underlying compiler does not appear to be gnu based. For those keen to start running programs before they get their hands on actual hardware a full system simulator is available. The minimum system requirement specification has obviously not been written by the marketing department: 'Processor - x86 or x86-64; anything under 2GHz or so will be slow to the point of being unusable.'"

cancel ×

207 comments

Well . . . (2, Funny)

Yocto Yotta (840665) | more than 8 years ago | (#13998413)

But does it run Linux?

Oh. Well, okay then.

Re:Well . . .Next question (1)

Nom du Keyboard (633989) | more than 8 years ago | (#13998435)

But does it run Linux?

Well, we know the answer to that. Next we want to know, will it kill Intel?

Re:Well . . .Next question (1)

Adolf Hitroll (562418) | more than 8 years ago | (#13998542)

would you like to taste my sweaty balls ?
just lick your father's tongue, then.

Re:Well . . . (1)

Kasracer (865931) | more than 8 years ago | (#13998598)

Next question.... does it run OSX x86?

Re:Well . . . (1)

StevoJ (868524) | more than 8 years ago | (#13998843)

I know that one! I know that one! No.

Uh-Oh (0, Offtopic)

Maavin (598439) | more than 8 years ago | (#13998441)

Watch out, Son-Goku!

Re:Uh-Oh (-1, Offtopic)

zobi (805190) | more than 8 years ago | (#13998498)

> Watch out, Son-Goku!

Don't worry, Gohan will kick his ass big time.

Re:Uh-Oh (-1, Offtopic)

TheRealMindChild (743925) | more than 8 years ago | (#13998564)

You DO realize that Dragon Ball ANYTHING is NOT cool? You know when you start explaining episodes to the hot girl you like... SHE DOESNT CARE!!! She most likely thinks you are mentally handicapped, so she tries to be nice and not hurt your feelings. Please, for the love of cherry toaster strudels, STOP THE MADNESS!

Re:Uh-Oh (-1, Offtopic)

trollable (928694) | more than 8 years ago | (#13998733)

Funny (3/5)

Re:Uh-Oh (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#13998760)

KA ME HA ME HA

the inevitable question (-1, Redundant)

netcrusher88 (743318) | more than 8 years ago | (#13998448)

but does it run linux?(yet)

Re:the inevitable question (0)

Anonymous Coward | more than 8 years ago | (#13998527)

yes. Since Linux runs on POWER and the Cell supports the PowerPC ISA linux has been able to run on Cell-based computers for a long time now.

Of course this does not mean that programs can take advantage of the Cell's odd multicore architecture. Programs would have to be specificly writen or use libraries that have been modified to use those SPU cores.

In Solvat Russia... (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#13998452)

Cell SDK release you!

Wikipedia article question (2, Insightful)

goofyheadedpunk (807517) | more than 8 years ago | (#13998469)

Not knowing too much about the cell processor I read the wikipedia article. I came across this: "In other ways the Cell resembles a modern desktop computer on a single chip."

Why?

Re:Wikipedia article question (0)

Anonymous Coward | more than 8 years ago | (#13998515)

cell is gonna be the biggest non-event, just you wait and see.

Re:Wikipedia article question (1)

pkvon (899533) | more than 8 years ago | (#13998535)

Because the author of the wikipedia article doesnt know better.

The CELL is not made for general purpose computing.

Re:Wikipedia article question (1)

Surt (22457) | more than 8 years ago | (#13998537)

Because they are offering audio, video, networking on the same chip as the general purpose processing.

Re:Wikipedia article question (4, Insightful)

AKAImBatman (238306) | more than 8 years ago | (#13998565)

Um. That's kind of a weird statement. I think they mean to say that it encompasses much of the multiprocessing capabilities of a modern PC in a single chip. i.e. It's your CPU and GPU rolled into one.

Cell processors aren't really anything all that new per say. The multi-core design makes them superficially similar to GPUs (which are also vector processors) with the difference that GPUs use multiple pipelines for parallel processing whereas each cell is a self-contained pipeline capable of true multi-threaded execution. In theory, the interplay between these chips could accelerate a lot of the work currently done through a combination of software and hardware. e.g. All the work that graphics drivers do to process OpenGL commands into vector instructions could be done on one or two cells, thus allowing those cells to feed the other cells with data.

I guess you could say that the cell processor is the start of a general purpose vector processing design. I'm not really sure if it will take off, but unbroken thoroughput on these things is just incredible.

Re:Wikipedia article question (0)

goofyheadedpunk (807517) | more than 8 years ago | (#13998721)

Thanks.

Re:Wikipedia article question (1, Informative)

ashSlash (96551) | more than 8 years ago | (#13999028)

It's "per se".

Re:Wikipedia article question (1)

AKAImBatman (238306) | more than 8 years ago | (#13999417)

Thanks. That's one of those I keep getting wrong. Keep reminding me and I'll remember at some point. :-)

Re:Wikipedia article question (1)

farquharsoncraig (711336) | more than 8 years ago | (#13999508)

you mean per se. (-: I can't point to any specific rule, but I've seen it often enough to know that foreign words or phrases are italicized when used in English, and latin is no exception.

Re:Wikipedia article question (4, Insightful)

l33t-gu3lph1t3 (567059) | more than 8 years ago | (#13998589)

Easy answer - the wiki article on "Cell" isn't that good. Cell isn't a System-On-A-Chip. It's just a stripped-down, in-order power pc core coupled to 8 single-purpose in-order SIMD units, using an unconventional cache/local memory architecture. It can run perfectly optimized code very, very fast, at extremely low power consumption to boot, but optimization will be/is a bitch. For instance, you have to unroll your "for" loops to start, since those SIMD co-processors can't do loops.

I'm sure IBM and Sony have much better documentation on the CPU than I do, but that's it in a nutshell. Everything else you hear about it is just marketing. Oh yeah, almost forgot. Microsoft's "Xenon" processor for the Xbox360 is pretty much just 3 of those stripped down, in-order PPC cores in one cpu die.

Re:Wikipedia article question (2, Interesting)

AKAImBatman (238306) | more than 8 years ago | (#13998680)

Cell isn't a System-On-A-Chip. It's just a stripped-down, in-order power pc core coupled to 8 single-purpose in-order SIMD units, using an unconventional cache/local memory architecture

You know, I'm looking back at all these replies to the poor guy, and I can't help but think that he's sitting in front of his computer wondering, "Can't anyone explain it in ENGLISH?!?" :-P

For instance, you have to unroll your "for" loops to start, since those SIMD co-processors can't do loops.

Actually, we need a new programming model. Instead of using FOR loops, we need a model under while you can say, "Perform these instructions X number of times." One could probably do a bit of guess-work in the compiler based on loops like "for(i=0;i<COUNT;i++)", but that doesn't help cases where the loop uses a more complex conditional statement (or where the test is affected by the loop itself). Thus the language needs to be changed to force the programmer to pre-compute the loop length for maximum performance. For example:
int i = 0;
do(COUNT) {
/*code goes here */
  i++;
}

Re:Wikipedia article question (0)

Anonymous Coward | more than 8 years ago | (#13998790)

(dotimes i (code-goes-here))

Re:Wikipedia article question (1)

AKAImBatman (238306) | more than 8 years ago | (#13998887)

Excellent! Now all we need are SIMD optimized LISP Compilers.

(Must (resist (temptation (to (joke (about (syntax))))))) :-P

Re:Wikipedia article question (2, Funny)

Jellybob (597204) | more than 8 years ago | (#13998792)

Looks like Ruby to me, although it's a little to verbose ;)

0..9 { |i| puts i }

Re:Wikipedia article question (1, Informative)

morgan_greywolf (835522) | more than 8 years ago | (#13998895)

That looks more like syntactic sugar to me. How is that different? More importantly, how would that translate differently into assembler code? You pretty much will wind up with the same thing, that is: "do your thang, increment the accumulator, if the accumulator equals the count, jump to do your thang."

gcc and other compilers have options such as -funroll-loops, which will unroll loops (no matter how they were specified) for you if the count can be determined at compile time. So you wind up with "Do your thang, do your thang, do your thang, do your thang ... Do your thang". You get the idea.

Re:Wikipedia article question (2, Informative)

tomstdenis (446163) | more than 8 years ago | (#13999075)

GCC can unroll all loops if you want including those with variable itteration counts. In those cases it uses a variant of duff's device. [well on x86 anyways].

As for the other posters, the real reason you want to unroll loops is basically to avoid the cost of managing the loop, e.g.

a simple loop like

for (a = i = 0; i b; i++) a += data[i];

In x86 would amount to

mov ecx,b
loop:
add eax,[ebx]
add ebx,4
dec ecx
jnz loop

So you have a 50% efficiency at best. Now if you unroll it to

mov ecx,b
shr ecx,1
loop:
add eax,[ebx]
add eax,[ebx+4]
add ebx,8
dec ecx
jnz loop

You now have 5 instructions for two itterations. That's down from 8 you would have before, and so on, e.g.

mov ecx,b
shr ecx,2
loop:
add eax,[ebx]
add eax,[ebx+4]
add eax,[ebx+8]
add eax,[ebx+12]
add ebx,16
dec ecx
jnz loop

Does 7 opcodes for 4 itterations [down from the 16 required previously, e.g. 100% more efficient].

Tom

Re:Wikipedia article question (2, Interesting)

AKAImBatman (238306) | more than 8 years ago | (#13999159)

mov ecx,b
shr ecx,2
loop:
add eax,[ebx]
add eax,[ebx+4]
add eax,[ebx+8]
add eax,[ebx+12]
add ebx,16
dec ecx
jnz loop


With SIMD instructions, you can execute all four of those adds in one instruction. I wish I knew SSE a bit better, then I could rewrite the above. Sadly, I haven't gotten around to learning the precise syntax. :-(

However, there's a fairly good (if not a bit dated) explanation of SIMD here [mackido.com] .

Re:Wikipedia article question (1)

tomstdenis (446163) | more than 8 years ago | (#13999558)

Yes, and unrolling would speed that up in the same fashion.

iirc the instruction is "paddd", and you'd do four parallel adds then shuffle and add twice to get the single sum.

Tom

Re:Wikipedia article question (1)

thexgodfather (880849) | more than 8 years ago | (#13998956)

I'm still waiting explination in english -_- Looks like you changed a for loop to a do loop and the other guy said it can't DO loops... frak it just give me a bowl of fruit loops =9

Re:Wikipedia article question (1)

pingveno (708857) | more than 8 years ago | (#13999063)

explination

frak

It looks like your not so hot on the English usage yourself. :P

P.S. Just kidding, I've seen worse. Fast typing leads nasty spelling.

Re:Wikipedia article question (1)

JWW (79176) | more than 8 years ago | (#13999546)

I'm pretty sure he spelled frak right.

Frak is actually a made up swear word from Battlestar Galactica.

It is sometimes used by the super geeky. Like er, um, er.. me.

Re:Wikipedia article question (1)

pdbogen (596723) | more than 8 years ago | (#13999154)

Reportedly, the SIMD processors can't do loops. Okay, this probably just means they can't Branch. A loop in assembly basically looks like:

loop: /* do some stuff */
branch to loop

However, you can "unroll" loops. If you have a loop that always runs 8 times, instead of doing a for loop you can just put the statement there 8 times. It makes the code larger in memory, but it saves processing time since you don't have to check exit conditions or jump around. This would be something done by the compiler, so OP's point that programming on these things is harder because they require unrolled loops is kind of bunk. It might still be necessary to make your loops more unrollable than otherwise.

Re:Wikipedia article question (1)

BarryNorton (778694) | more than 8 years ago | (#13999500)

This would be something done by the compiler[...] It might still be necessary to make your loops more unrollable than otherwise
Perhaps something like writing in tail recursive style to help out an optimising compiler?...

Re:Wikipedia article question (1)

jcnnghm (538570) | more than 8 years ago | (#13999012)

mov ecx, COUNT
LOOP_START:
;IIRC this is the underlying assembly
;construct for looping
;
;excluding conditional jumps
LOOP LOOP_START

Re:Wikipedia article question (1)

MatD (895409) | more than 8 years ago | (#13999060)

In most cases, I think template metaprogramming (in C++) is pedantic garbage. In this case however, you could probably use it to great effect (ie, the compiler will unroll your loops for you). The syntax is still pretty horrible though.

Re:Wikipedia article question (0)

Anonymous Coward | more than 8 years ago | (#13999169)

The do(COUNT)-construct's inner loop mustn't depend on any other iteration (ie, one iteration may not use results from a previous one).
  So "i++" won't do...

do(COUNT)(int i) {
/* code goes here, i will be in the range 0...COUNT-1 */
}

The syntax could of course be improved...

Re:Wikipedia article question (4, Informative)

plalonde2 (527372) | more than 8 years ago | (#13998686)

You are wrong. These SIMD processors do loops just fine. There's a hefty hit for a mis-predicted branch, but the branch hint instruction works wonders for loops.

The reason you want to unroll loops is because of various other delays. If it takes 7 cycles to load from the local store to a register, you want to throw a few more operations in there to fill the stall slots. Unrolling can provide those operations, as well as reduce the relative importance of branch overheads.

Re:Wikipedia article question (1)

AKAImBatman (238306) | more than 8 years ago | (#13998854)

You are wrong. These SIMD processors do loops just fine. There's a hefty hit for a mis-predicted branch, but the branch hint instruction works wonders for loops.

Um... I'm not sure that's what he's trying to say. SIMD by definition is Single Instruction, Multiple Data. i.e. You give it a couple of instructions and watch it perform them on every item in the stream of data. By definition, a loop is an iteration over each instruction, multiple times. a.k.a. Multiple Instruction Multiple Data (MIMD).

What's needed to take full advantage of SIMD is instructions that can be bundled together into one long stream. That way the entire stream can be processed without using a loop. In theory, this is the fastest possible way to process data. Especially with high-latency, high-bandwidth memory. Unfortunately, our programming models aren't designed around such concepts, leaving us relying on optimizing compilers and handcoded assembly.

Re:Wikipedia article question (1)

AKAImBatman (238306) | more than 8 years ago | (#13999052)

a.k.a. Multiple Instruction Multiple Data (MIMD).

Minor correction. That's supposed to be Single Instruction, Single Data. (SISD) My bad.

Re:Wikipedia article question (1)

plalonde2 (527372) | more than 8 years ago | (#13999501)

The SIMD in question here is the Altivec/SSD style also called SWAR (SIMD Within A Register); the instruction set has many ops for applying the same operation over each of the 4 (or 8, or 16) elements within a 128 bit register. It's not the streaming type of SIMD.

Re:Wikipedia article question (1)

Doug-W (165055) | more than 8 years ago | (#13999313)

You can do loops on the SPE it's just that the lack of branch prediction and it's dual pipeline nature means that you're better off unrolling them for speed.

Re:Wikipedia article question (1, Informative)

stienman (51024) | more than 8 years ago | (#13998654)

The Cell processor is essentially a multi-core chip. It has, IIRC, one "master" CPU, and then multiple slave CPUs on the same die.

A modern desktop computer has one master CPU, then several smaller CPUs each running their own software. Graphics, Sound, CD/DVD, HD, not to mention all the CPUs in all the peripherals.

But the analogy ends there. The Cell has certian limitations and wouldn't be able to operate as a full computer system with no other processors very efficiently. I believe the PS3 has a seperate GPU, for instance. And doubtless has many other microcontrollers managing the rest of the system.

-Adam

Re:Wikipedia article question (1)

Jerry Coffin (824726) | more than 8 years ago | (#13999405)

I suspect the author of the Wikipiedia article knows a bit more than he's being given credit for elsethread.

Each cell processor includes not only the multiple processors mentioned elsethread, but addressable memory, DMA controller, and a controller for what is essentially a proprietary network. The last is somewhat open to argument -- for example, current AMD CPUs include HyperTransport controllers, which are somewhat similar.

In any case, IBM does (e.g. here [ibm.com] ) talk about the Cell as a System on a Chip, though IMO, this is a stretch -- a PS3 system includes quite a few other chips, some of them pretty significant (e.g. the GPU). In fact, I find it somewhat difficult to contemplate a system that would make good use of a Cell without a pretty fair number of other chips. OTOH, as the Wikipedia article suggests, it does include a number of elements that are normally implemented in separate chips on a PC.

--
The universe is a figment of its own imagination.

Is this the same Cell processor used in the PS3? (1)

Spy der Mann (805235) | more than 8 years ago | (#13998489)

Just to clarify.

Re:Is this the same Cell processor used in the PS3 (5, Funny)

Spazntwich (208070) | more than 8 years ago | (#13998524)

No. In our insanely litigious society, a company has graciously allowed another to create and market a different processor by the same exact name.

Re:Is this the same Cell processor used in the PS3 (0)

Anonymous Coward | more than 8 years ago | (#13998579)

No. In our insanely litigious society, a company has graciously allowed another to create and market a different processor by the same exact name.

nice smart a** post.

Think about his question this way, "is the PowerPC that is running in the XBox the same as the one used in my Mac G3?". The obvious answer (no, it's not yours) is "kinda". They are obviously related, though, in this case, they are not exactly the same chip. Just as PowerPC refers to a family of chips that share certain characteristics (ISA being one of the biggest), Cell refers to a family of processors that have certain characteristics. So the emulator that IBM has may not be emulating the exact configuration of chip that is running in a PS3.

Re:Is this the same Cell processor used in the PS3 (1)

Spazntwich (208070) | more than 8 years ago | (#13998907)

Actually, you simp, the problem with your argument is PowerPC and Cell are not analogous names. PowerPC denotes certain things, but it doesn't specify the final type. There are PowerPC G3s, G4s, G5s, and a host of others I've forgotten that predate those. Thus far sir, there is only one iteration of a cell processor, meaning any cell you find out there right now is the same one in anything else with a cell processor.

Re:Is this the same Cell processor used in the PS3 (1)

Chris Redfield (930089) | more than 8 years ago | (#13998941)

which would be why he responded in such a sarcastic manner, and why everyone accused him of "trolling"

Re:Is this the same Cell processor used in the PS3 (0)

Anonymous Coward | more than 8 years ago | (#13999574)

Actually, you simp, the problem with your argument is PowerPC and Cell are not analogous names. PowerPC denotes certain things, but it doesn't specify the final type. There are PowerPC G3s, G4s, G5s, and a host of others I've forgotten that predate those. Thus far sir, there is only one iteration of a cell processor, meaning any cell you find out there right now is the same one in anything else with a cell processor.

You're all class :)

The following is taken from "the source" (i.e. IBM) :

The Cell Broadband Engine (CBE) is a new architecture which extends the 64-bit Power Architecture(TM) technology. Ideal for compute-intensive tasks like gaming, multimedia, and physics- or life-sciences and related workloads, the CBE is a single-chip multiprocessor no bigger than a fingernail, with nine processors operating on a shared, coherent memory. The CBE processor contains a Power Architecture-based control processor (PPU) augmented with eight (or more) SIMD Synergistic Processor Units (SPUs) and a rich set of DMA commands for efficient communications between processing elements.

So actually, no, it's not much different than saying POWER or PowerPC. It denotes a family of processors that share certain capabilities. The fact that there is only a single implementation does not detract from this definition (just as the fact that when PowerPC came out, one could only initially get their hands on a 601). Plus, unless you're fairly wired in, how do you know exactly which flavour(s) of cell proccies IBM actually has vs what Sony might have? IBM themselves say "8 or more". How do you know that the PS3 versions has only eight (and from what I understand some will have specific tasks) while IBM currently has versions with more? That's the point.

Re:Is this the same Cell processor used in the PS3 (1, Informative)

Anonymous Coward | more than 8 years ago | (#13998526)

Yup, it is.

Re:Is this the same Cell processor used in the PS3 (0)

Anonymous Coward | more than 8 years ago | (#13998744)

and you can totally play your downloaded ps3 games on it

Re:Is this the same Cell processor used in the PS3 (2, Funny)

Anonymous Coward | more than 8 years ago | (#13998918)

I not get mine run. Please send exact instruction how downloaded PS3 games play can?

Unproductive? (5, Funny)

RManning (544016) | more than 8 years ago | (#13998532)

My favorite quote from TFA...

...in addition, the ILAR license states that "You are not authorized to use the Program for productive purposes" -- so make sure that your time spent with these downloads is as unproductive as possible.

Re:Unproductive? (0)

Anonymous Coward | more than 8 years ago | (#13998615)

yeah i just saw that myself, and was gonna copy 'n paste. glad you beat me to it.

fucking bizarre.

Re:Unproductive? (2)

Kayamon (926543) | more than 8 years ago | (#13998880)

Sounds like my job. I don't think there'll be any problems there. :-)

Oh come on. (0)

Anonymous Coward | more than 8 years ago | (#13999412)

They give people a free PS3 emulator and think they will ever do anything "productive" on it?!

Since the submitter didn't bother to explain... (4, Informative)

frankie (91710) | more than 8 years ago | (#13998540)

...the Cell processor is an upcoming PowerPC variant that will be used in the PlayStation 3. It's great at DSP but terrible at branch prediction, and would not make a very good Mac. If you want to know full tech specs, Hannibal is da man [arstechnica.com] .

Re:Since the submitter didn't bother to explain... (1)

imroy (755) | more than 8 years ago | (#13998677)

I'm just wondering what information you have on the Cell being "terribla at branch predeiction"? I don't know about using it in a mac, but IBM seems eager to run Linux on it. They've even demonstrated a prototype cell-based blade server system [slashdot.org] running Linux, back in May.

Branch Prediction (0)

Anonymous Coward | more than 8 years ago | (#13998794)

What branch-prediction means is that a JUMP instruction cannot be made directly in a single atomic instruction. Instead the CPU must single-step forward until the appropriate offset is reached, rather than just incrementing the Program Counter register in one go. In the CELL's case, it cannot jump in one go because it is RISC and there are not enough bits left after the opcode bits to fit the offset.

And yes, this does mean that code must be optimised so that JUMPs are very small.

Re:Branch Prediction (1)

farnz (625056) | more than 8 years ago | (#13999300)

Branch prediction is when the CPU guesses whether a conditional jump will be taken or not taken, in order to keep the pipeline full (if the pipeline empties, even for one instruction's worth of time, the CPU runs slower). Usually, this guess is partly based on static rules (if it would branch backwards, it'll probably be taken, while forward jumps are probably not taken), and partly on dynamic rules (the last four times I saw this conditional jump, I took it, so I'll assume it'll be taken again this time).

In Cell and other IBM PPE designs, there is no dynamic prediction hardware, so the CPU makes the same guess every time, even when it's obvious to a human that it's wrong. This costs in performance for code like AI, where the chances of taking the jump vary while the game is running.

Re:Branch Prediction (1)

lmsig (110148) | more than 8 years ago | (#13999463)

Has any CPU ever had a mechanism for the user to hint to the CPU whether or not the branch will be taken? Perhaps just another branch instruction that hints to the CPU that it is very likely for a branch to be taken.

This way the compiler could insert the appropriate optimization depending on the situation (or we could even allow #pragma type statements so a programmer could tell the compiler which way to hint!)

Granted most of the time the compiler could decide; or it doesn't matter so you could just use the same simple rules that the CPU might use (or just defer to the CPU as we do now). However, we've all be stuck in a situation where we end up with an if statement inside of a for loop. It'd be nice to be able to tighten a loop like that up in the rare situation where it matters.

Re:Branch Prediction (1)

imroy (755) | more than 8 years ago | (#13999310)

Wow, you could not be more wrong. See the wikipedia article on branch misprediction [wikipedia.org] . You should probably read up on exactly what RISC [wikipedia.org] means as well. I have the "SPU assembly language" document here from IBM (can't remember where I got it from, sorry). The branch instructions (not JUMP) can jump to any location stored in any 32-bit register, minus the two least significant bits. It is a RISC CPU after all. Or it can branch relative to the current PC using an 18-bit direct value. Considering the first generation of Cell's have 256KB of local addressable memory per SPU, that's half the available memory in a relative jump. And most of that memory is probably going to be used by data anyway. So no, JUMP's do not have to be small. This is not your dad's SIMD computer, this is a pretty general RISC processor with vector [wikipedia.org] extensions.

Re:Since the submitter didn't bother to explain... (1)

nutshell42 (557890) | more than 8 years ago | (#13998917)

Even though the GP linked to an article that greets you with Inside the Xbox 360, Part II: the Xenon CPU there are links to some informative articles about the Cell architecture further down.

Short story: The cool thing about the Cell are the SPEs that are the best thing since sliced bread if you have lots of matrix-vector operations to perform but more or less useless otherwise.

IBM is eager to run Linux on it because the Cell could make one hell of a supercomputing grid. (Although it loses lots of flops if you need double-precision but even then it's quite fast and in many calculations there are large parts where you can go single-precision without losing digits in the end result anyways)

Re:Since the submitter didn't bother to explain... (0)

Anonymous Coward | more than 8 years ago | (#13998831)

Uhm, no, "The Cell processor" as a whole is not terrible at branchprediction. It consists of one PowerPC core, much like those used in current Macs, plus 8 so called "synergetic processors". The latter have been optimized for DSP/multimedia like algorithms, with extensize use of SIMD instructions. These processors are, however, much worse at branch prediction, and will not run general purpose code very well.
What does all of this mean? If you're machine will be used for running, say, database applications, you will probably be better off with an SMP solution. But if your machine must run games, or video processing, or audio processing, or ..., the Cell processor would make a tremendoes CPU. In that case, all gp stuff, such as linux etc. would actually run on the PPC core, but specific multimedia threads could be run on the synergetic cores.

Ruben

Re:Since the submitter didn't bother to explain... (0, Interesting)

Anonymous Coward | more than 8 years ago | (#13998986)

Where these dumb comments come from:

1) Apple tries to lowball IBM on the mobile 970 design
2) IBM give Apple the finger - they account for less the five percent of IBM's chip volume
3) Steve goes out on stage and pretends like he has made the 'choice' to move to Intel
4) With Cell processors in Macs no longer an option for Apple, the sour grapes meme that the idiot above parroted starts to make its rounds in Mac circles.
5) Intel's processor roadmap fiasco continues, but what is funny is how Intel's roadmap for future chips years down the road has chip designs that look very close to STI's Cell chips that being made today.

Enjoy your h.264 encoding times on those wonderful Intel SSE chips Mac crazies!

Re:Since the submitter didn't bother to explain... (1)

Glock27 (446276) | more than 8 years ago | (#13999538)

3) Steve goes out on stage and pretends like he has made the 'choice' to move to Intel

You're bitter about something. Care to share?

Steve most certainly made a decision to go Intel. No "pretending" involved. Just what dollar value to you ascribe to "5% of IBM's chip volume", BTW?

4) With Cell processors in Macs no longer an option for Apple, the sour grapes meme that the idiot above parroted starts to make its rounds in Mac circles.

Cell wouldn't be that great for it's clock speed, but it would certainly work. I'm pretty sure Pentium-M and descendants will beat it for GP computation, and without learning an involved new programming approach.

5) Intel's processor roadmap fiasco continues, but what is funny is how Intel's roadmap for future chips years down the road has chip designs that look very close to STI's Cell chips that being made today.

Really, care to provide a link? What are you claiming corresponds to SPEs in Intel's designs? I've heard nothing about this.

Re:Since the submitter didn't bother to explain... (0)

Anonymous Coward | more than 8 years ago | (#13999142)

Uh, getting your console info from hannibal on ars is a lot like watching Dr. Phil for your emotional problems. Probably harmless, but certainly worthless.

There is more than enough info on Cell, the PS3, other Cell based products out there from Sony and IBM talks and patents that even non-technical people can follow.

Re:Since the submitter didn't bother to explain... (1)

poot_rootbeer (188613) | more than 8 years ago | (#13999513)

It's great at DSP but terrible at branch prediction

With 8 or more semi-independent "Synergistic Processing Unit" pipelines, it doesn't really need to have a lot of complex branch prediction logic. It could adopt a bit of a quantum methodology and assign a different SPU to proceed for each possible outcome of a compare/branch instruction, and then once the correct outcome has been established, discard the "dead-end" pipelines.

Then again, I learned microprocessor design principles back when the PPC 601 was state-of-the-art, so my +1 Insightfulness may vary.

Hannibal sucks (0)

Anonymous Coward | more than 8 years ago | (#13999588)

and DSP is wrong. They are processors.

Source for actual chips? (3, Interesting)

mustafap (452510) | more than 8 years ago | (#13998605)

Thats great news, but as an embedded systems designer and eternal tinkerer, where will I be able to buy a handfull of these processors to experiment with? Without having to dismantle loads of games machines ;o)

I should have added... (1)

mustafap (452510) | more than 8 years ago | (#13998952)

That I am in the UK, although I dont think that will make much difference :o)

But I would like to know.

Mike.

Re:Source for actual chips? (1)

Wesley Felter (138342) | more than 8 years ago | (#13999157)

Unfortunately for you, you don't "tinker" with Cell. Since all the I/O is multi-GHz exotic Rambus signaling, you probably have to be an expert board designer to do anything with it. Not to mention that you have to get the processor, southbridge, and RAM from three different companies, probably signing a stack of NDAs in the process.

Re:Source for actual chips? (1)

mustafap (452510) | more than 8 years ago | (#13999201)

Ah. When I read 'the size of your fingernail' I assumed it would be like an ARM core. Oh well. :o(

Thanks,

Mike.

What about a PPC SDK and simulator? (4, Interesting)

kuwan (443684) | more than 8 years ago | (#13998619)

As the Cell is basically a PPC processor I find it strange that the SDK is for x86 processors. Fedora Core 4 (PowerPC), also known as ppc-fc4-rpms-1.0.0-1.i386.rpm is listed as one of the files you need to download. Maybe it's just because of the large installed base of x86 machines.

It'd be nice if IBM released a PPC SDK for Fedora, it would have the potential to run much faster than an x86 SDK and simulator.

Re:What about a PPC SDK and simulator? (1)

antifoidulus (807088) | more than 8 years ago | (#13998810)

Not sure how much faster it would be really(though I'm writing this from a powerbook and I really wish they would release some ppc stuff). A PPC chip acts as the controller but the actual proccessing is done on chips with architectures vastly different from both x86 and PPC, For instance, they aren't superscalar so they do no branch prediction like both x86 and PPC do...so really the emulation speed is pretty independent of it's host architecture. I suppose they could use the Altivec found on Apple's CPUs to simulate some of the SIMD instructions better, but remember the only CPU that IBM makes with an altivec unit is the G5s it makes for Apple, not exactly it's core busiiness.

Re:What about a PPC SDK and simulator? (1)

Jozer99 (693146) | more than 8 years ago | (#13999266)

I dont know how much of a performace boost you would get. Despite the fact that it has a power pc processor on it, it is a very different power pc. It does not have out of order execution, and has all those pretty vector processors dangling off of it. I think emulation would be 2x faster, at most.

Another question about the simulator (1)

Weaselmancer (533834) | more than 8 years ago | (#13999296)

I wonder if it'll take advantage of multi-core chips? Might make sense to do so, especially since that's also (sort of) similar to the hardware being simulated.

Re:What about a PPC SDK and simulator? (1)

jmorris42 (1458) | more than 8 years ago | (#13999585)

> Maybe it's just because of the large installed base of x86 machines.

Got it in one try. Anyone interested in actually using this thing has a spare PC to load FC4 on, almost none has a spare top of the line PowerMac in the closet. Heck, most don't have a top of the line Powermac period.

GNU toolchain (5, Interesting)

lisaparratt (752068) | more than 8 years ago | (#13998628)

The software includes many gnu tools, but the underlying compiler does not appear to be gnu based.

Is this any surprise? My understanding was the Cell's a vector process, and despite the recent upgrades to GCC, it's still fairly awful at autovectorisation.

Can anyone clarify?

Re:GNU toolchain (3, Informative)

Have Blue (616) | more than 8 years ago | (#13999002)

IBM may have run into the same problems with the Cell that they did with the PowerPC 970- the chip breaks some fundamental assumptions GCC makes, and to add the best optimization possible it would necessary to modify the compiler more drastically than the GCC leads would allow (to keep GCC completely platform-agnostic).

Re:GNU toolchain (3, Informative)

Wesley Felter (138342) | more than 8 years ago | (#13999098)

The SDK includes both GCC and XLC. GCC's autovectorization isn't the greatest, but Apple and IBM have been working on it. I think if you want fast SPE code you'll end up using intrinsics anyway.

Echoes of Redhat (3, Insightful)

delire (809063) | more than 8 years ago | (#13998649)


Why Fedora is so often considered the default target distribution I don't know. Even the project page [redhat.com] states it's an unsupported, experimental OS, and one now comparitvely marginal when tallied [distrowatch.com] .

Must be a case of 'brand leakage' from a distant past, one that held Redhat as the most popular desktop Linux distribution.

Shame, I guess IBM is missing out on where the real action is.

I agree! (1)

BobPaul (710574) | more than 8 years ago | (#13999039)

Give me a nice clean distro like Gentoo anyday. I can't stand that a Fedora install requires 5CDs and installs some 600 packages that I will never use. Why do I need so many text editors, etc? I get lost in the and nervous in the Applications menu. Sure, I tried 30 text editors before I found the one I wanted, but that's all I install on my box durring reinstall or upgrade.

BTW, this parent might be offtopic, be he is no troll. Shame on you mods!

Re:I agree! (1)

raverbuzzy (603708) | more than 8 years ago | (#13999394)

You don't have to install the packages. We use Fedora at work and only use the 1st CD to build the system. Anything else gets installed only if and when it's needed using yum.

Re:Echoes of Redhat (4, Insightful)

LnxAddct (679316) | more than 8 years ago | (#13999548)

Fedora overtook Suse within a year and a half in terms of users. It is now a close 3rd to Debian which is a far second from Red Hat (Red Hat and Fedora together have around 3 times the market share of Debian, check netcraft to confirm those numbers). The numbers on distrowatch are not downloads or users, that number is how many people clicked on the link to read about Ubuntu. Mark Shuttleworth is obscenely good at getting press about Ubuntu so the Ubuntu link gets a lot of click throughs, and now that it is at the top, it is kind of self fulfilling as interested people want to read about the top distro so they click on that more.

When it comes down to it, Fedora is the most advanced linux distribution out there. It comes standard with SELinux and virtualization. It uses LVM by default, integrates exec-shield and other code foritfying techniques into all major services. It has the latest and greatest of everything. Things just work in Fedora because a large portion of that code was coded by Red Hat. Red Hat maintains GCC and glibc, they commit more kernel code than anyone else, they play a large role in everything from Apache and Gnome to creating GCJ to get java to run natively under linux. Whether you like it or not, Fedora is the distro most professionals go with, despite what the slashdot popular oppinion is and despite the large amounts of noise that a few ubuntu users create.

Out of the big two, Novell and Red Hat, Novell has never been worse off and Red Hat has never been healthier. Red Hat doesn't officially provide support for Fedora, but it is built and paid for by Red Hat and their engineers (in addition to the community contributions). By targetting Fedora, IBM knows that they are targeting a stable platform with the largest array of hardware support. IBM is in bed with both Novell and Red Hat, they didn't choose Fedora because they were paid to or something... they chose Fedora based on technical merits. Claiming that Fedora is unstable is no different than claiming GMail is in beta, both products are still the best in their respective industries. Why do people go spreading FUD about such a good produc when they've never used it themselves? Whether you want to admit it or not, Fedora is the platform to target for most. It is compatible in large part with RHEL, so you're getting the most bang for your buck.

IBM doesn't just shit around, or make decisions for dumb reasons. If Fedora is good enough for IBM it is good enough for anyone. Apparently this is a common oppinion as more and more businesses switch to Fedora desktops. Here [computerworld.com.au] is one recent story of a major Australian company, Kennards, replacing 400 desktops with Fedora. Don't be so close minded or you might be left behind.
Regards,
Steve

New & Improved (1, Funny)

Doc Ruby (173196) | more than 8 years ago | (#13998762)

I dunno - telling people they have to upgrade their PC to run the SDK for a new PC architecture seems like a marketer's job.

Very Similar to PS3 SDK (1)

leather_helmet (887398) | more than 8 years ago | (#13998832)

We have been working with the PS3 SDK for just about a month now and have begun to run our preliminary game code on it - one complaint we have is that the it took us a few weeks to read through the documentation, sample code etc. before we became remotely comfortable with the hardware, whereas with 'other' next-gen SDK's we were able to pretty much hit the ground running...this was expected however and in the end, the PS3 has got a LOT more upside potential - with the other SDK we know pretty much what we have to work with, the PS3 looks like it will take a few years before developers really begin to tap into its somewhat convuluted power and architecture

Re:Very Similar to PS3 SDK (0)

Anonymous Coward | more than 8 years ago | (#13999084)

"somewhat convuluted power and architecture"

So you mean that it isn't the retarded desktop x86 peecee architecture that the 360 and your computer at home are like?

Perhaps you should stick to cutting and pasting directx code?

Let this guy be an example to everyone who loves to quote 'developers' who talk about system being 'hard to program' - invariably it is some clown whose world revolves around Microsoft and directx.

tubGirl (-1)

Anonymous Coward | more than 8 years ago | (#13998870)

handy, you are free 3That support use the sling. moronic@, dilettante roots and gets on only way to go: I ever did. It you're told. It's

Obligatory (0)

Anonymous Coward | more than 8 years ago | (#13998891)

Imagine a beowulf cluster of these...

Linux on PS3? (1)

deadline (14171) | more than 8 years ago | (#13999043)

This is very interesting. The Cell has a very non-standard architecture, but it can be used in a very powerful way. The key is software and thus, an emulation SDK is really important for a new architecture. From and HPC (High Performance Computing) prospective, these chips could be very powerful.

The real question is whether the the PS3 will have an Linux hard disk option like the PS2. If that is the case, it may be the cheapest way to get actual development hardware.

Re:Linux on PS3? (2, Interesting)

MaskedSlacker (911878) | more than 8 years ago | (#13999156)

Almost definitely. A cheap beowulf of PS3s.

Cell Hardware... (4, Informative)

GoatSucker (781403) | more than 8 years ago | (#13999133)

From the article:
How does one get a hold of a real CBE-based system now? It is not easy: Cell reference and other systems are not expected to ship in volume until spring 2006 at the earliest. In the meantime, one can contact the right people within IBM [ibm.com] to inquire about early access.

By the end of Q1 2006 (or thereabouts), we expect to see shipments of Mercury Computer Systems' Dual Cell-Based Blades [mc.com] ; Toshiba's comprehensive Cell Reference Set development platform [toshiba.co.jp] ; and of course the Sony PlayStation 3 [gamespot.com] .

Rosetta to the rescue? (2, Interesting)

Caspian (99221) | more than 8 years ago | (#13999240)

'Processor - x86 or x86-64; anything under 2GHz or so will be slow to the point of being unusable.'

OK, so what they're saying is "it's slow to emulate a PPC variant on an x86 variant". Duh.

But Apple seems to have cooked up something wonderful (or at least licensed something wonderful) in this vein in the form of Rosetta, the tech that lets Mac OS X for x86 run Mac OS X for PPC binaries very fast.

Sony has several metric fucktons of money. Can't they license the Rosetta technology, or pay for it to be basically "ported" from its current state of PPC-on-x86 to Cell-on-x86? Cell is PPC-based, so it shouldn't be so hard, no?

Re:Rosetta to the rescue? (1)

Synic (14430) | more than 8 years ago | (#13999306)

you ever think that rosetta is more like wine than it is like virtual pc? ie handles the upper API calls by translating them to native lower level?

Re:Rosetta to the rescue? (1)

Caspian (99221) | more than 8 years ago | (#13999409)

No. Because then, applications like Photoshop would NOT be fast in Rosetta, and they are.

My reasoning for saying this is that CPU-intensive, [presumably] tightly optimized things like Photoshop would not (at least, for the filters and other image operations) use API calls, they'd use hand-optimized raw C/C++ code, or even raw PPC assembly.

The fact that Photoshop performs quickly under Rosetta, to me, indicates that it's not primarily API reimplementation under the hood, but is some advanced form of cacheing JIT.

Am I really the first to mention it.. (1)

Transcendor (907201) | more than 8 years ago | (#13999304)

Imagine that running on a beowulf Cluster of Cell Processors, running Bochs to run... nevermind
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...