Unleashing the Power of the Cell Broadband Engine

An anonymous reader writes "IBM DeveloperWorks is running a paper from the MPR Fall Processor Forum 2005 explores programming models for the Cell Broadband Engine (CBE) Processor, from the simple to the progressively more advanced. With nine cores on a single die, programming for the CBE is like programming for no processor you've ever met before."

Comments

Cell architecture

[rd4tech]

The Cell Architecture grew from a challenge posed by Sony and Toshiba to provide power-efficient and cost-effective high-performance processing for a wide range of applications, including the most demanding consumer appliance: game consoles. Cell - also known as the Cell Broadband Engine Architecture (CBEA) - is an innovative solution whose design was based on the analysis of a broad range of workloads in areas such as cryptography, graphics transform and lighting, physics, fast-Fourier transforms (FFT), matrix operations, and scientific workloads. As an example of innovation that ensures the clients' success, a team from IBM Research joined forces with teams from IBM Systems Technology Group, Sony and Toshiba, to lead the development of a novel architecture that represents a breakthrough in performance for consumer applications. IBM Research participated throughout the entire development of the architecture, its implementation and its software enablement, ensuring the timely and efficient application of novel ideas and technology into a product that solves real challenges; More...

New Me

[Doc Ruby]

I just want to draw a flowchart and have the compiler and realtime scheduler distribute processes and data among the hardware resources. If we are getting a new architecture and new "programming models", and therefore new compilers and kernels, how about a new IDE paradigm.

Re:New Me

[NanoGator]

"I just want to draw a flowchart and have the compiler and realtime scheduler distribute processes and data among the hardware resources. If we are getting a new architecture and new "programming models", and therefore new compilers and kernels, how about a new IDE paradigm."

Bingo, sir.

Re:New Me

[ultranova]

I just want to draw a flowchart and have the compiler and realtime scheduler distribute processes and data among the hardware resources. If we are getting a new architecture and new "programming models", and therefore new compilers and kernels, how about a new IDE paradigm.

Isn't this basically the dataflow paradigm ?

I think it should be possible to make any programming language automatically spread its work across multiple processors simply by analyzing which operations depend on which to generate "wait until operationx X is complete" points (essentially the same as current processors do to feed their multiple pipelines from a single stream of instructions, but might work better since the compiler has more info than the processor); how efficient this kind of system would be is another matter.

Or simply include support for constructs like

future int result = operation();<br>
doSomeThing();<br>
doSomeThingE lse(result);

where the keyword "future" tells the compiler to perform "operation()" in a separate thread if possible, and block at "doSomeThingElse()" if result is not yet available (or, better yet, block in doSomeThingElse() at the line where result is actually needed). This would allow for extremely easy thread programming - but it would propably still be neccessary to include a separate threading facility.

You can do something like this in Java with the Future interface, FutureTask class and the Executor interface, but it requires a lot of extra work for the programmer. It would be nice if the compiler could generate the code for me. It would be even better if the JVM included support for such constructs, since it would allow the exact same bytecode to be run as a single-threaded application in uniprocessor machine without any overhead, and still take advantages of multiple processors when available.

Re:New Me

[jo42]

...and don't forget to give everything a new, academic, name.

Re:New Me

[MikeFM]

Real geeks don't use IDEs! ;)

I'll use an IDE when they invent one that is fast, flexible, and chrome free as a normal bash command prompt. I have hated every IDE I've tried due to slowness and their insistance on making an ugly bloated interface. I don't need the IDE to try to guess what I'm typing, to offer code debugging while I'm typing, to FTP my files for me, etc.

Basic project management, checking my code for errors (when I ask.. not constantly), good seach and replace (with regular expressions and across multiple files), and a built-in reference guides for everything I'm doing (language, protocols, etc) would be good enough. Possibly an interface builder if it works well and stays out of the way when not needed. Much more than that and you're just letting wasting your time playing with an interface replace actual coding time.

Re:New Me

[Doc Ruby]

Enjoy your wallow in the 1970s. My coding experience, which started there, includes typing hex machine code into the Apple ][+ machine language monitor. And it also includes working with customers, graphic artists and mathematicians. Which is why productivity is clearly highest throughout the cycle with flowcharts of reusable schematic objects. We've got lots of native topological intuition and skills we almost use while coding and debugging, but which we're not skilled in operating by typing.

I want to keep the lexical tools you love, especially for geeks who can't use the multidimensional tools, but also just to keep their proven value. So what I'm looking for is a callgraph visualizer for your stuff, and a flowchart compiler that produces procedural code like C and Java. Then we can each use the machines for maximum productivity among all our individual idiosyncracies.

Re:New Me

[MikeFM]

Individual indiosyncracies are nice. I hate being forced to use a given enviroment to work on something. I keep working on my ideal enviroment which is of course ideal only to me. Fancy tools with low overhead. ;)

Re:New Me

[Doc Ruby]

I like subclassing and embedding :).

Re:New Me

[MikeFM]

My biggest fetish is making lots of extensible small programs/libraries and building other programs out of them.. so I guess I like subclassing and embedding too. I was once accused of creating my own custom programming language for everything I programmed. I do that less now but do like to expose the internals in ways that let my programs be modifed in all sorts of interesting ways.

Re:New Me

[Jarvo]

Your programming example would remove the need for mutexes, but that's about all. Spawning a thread, while faster than an entire process, has cost.

In your example, the context of the current thread would have to be duplicated (how does the compiler know what data operation() will use). They can't run from the same data - what if doSomeThing() modifies a field that operation() uses?

Java's FutureTask requires extra work, but it protects you from concurrent data modifications errors. (Or, it appears to. I'm not familiar with it...)

Your idea is good. We're eventually going to need a revolutionary way to parallelise computation on a larger scale (larger than instruction-level, anyway). But don't forget - at some point, all abstractions leak.

Even if we could split all function/method calls out to separate threads, there will still be waste. Just as instructions must wait for their inputs, so must your functions/methods. To get a well-optimised program, a software engineer will still be stuck with managing the critical path of execution.

Re:New Me

[ultranova]

Your programming example would remove the need for mutexes, but that's about all. Spawning a thread, while faster than an entire process, has cost.

No, you'd still need mutexes. My example is simply a clean and simple way of expressing "this task can be run on a separate worker thread".

In your example, the context of the current thread would have to be duplicated (how does the compiler know what data operation() will use). They can't run from the same data - what if doSomeThing() modifies a field that operation() uses?

Then you obviously need to synchronize accesses to those fields.

You seem to have misunderstood my basic idea. The idea is not to make different threads not require synchronization. The idea is to make an easy, simple and clean code construct for marking tasks for being executable on a background thread - a bit like the "for (SomeType t : someCollection) { t.doSomething(); }" construct for iterating over a Collection (it gets expanded into something like "for (Iterator i = someCollection.iterator(); i.hasNext(); SomeType t = i.next()) { t.doSomething(); }" by the compiler).

It would be very nice for something like loading data in the background (especially if they're loaded over the Net) while doing some other initialization tasks on the main thread.

So no, it's not a magical nonsynchronized thread, it's just a bit less painfull interface for using threading. Just a compiler macro, not unlike autoboxing; a little something to lessen the need for typing and make code a little easier to read.

Your idea is good. We're eventually going to need a revolutionary way to parallelise computation on a larger scale (larger than instruction-level, anyway). But don't forget - at some point, all abstractions leak.

Which is why we get these things called brains, to figure out which are usefull abstractions and which aren't :). But I'm not really sure that this is an abstraction, more like a way to express your intent to the compiler in less typing, and make code cleaner and easier to read at the same time.

Re:As Usual...

[Anonymous Coward]

Congratulations... but perhaps not everyone else did, and hopefully seeing a summary of a story you'd seen elsewhere didn't completely ruin your day.

Has nothing to do with Broadband

[ScottCooperDotNet]

Damn you marketing droids! This has nothing to do with broadband at all.

Re:Has nothing to do with Broadband

[Anonymous Coward]

Okay then, Sherlock, define broadband.

Re:Has nothing to do with Broadband

[Guilly]

I would assume they call it broadband because the 8 SPE's can communicate to each other over a 100GB/s link (called the Element Interconnect Bus -- yes, that's 100GB not 100Gb) and also because it provides plenty of SIMD instructions.

Oh yeah. If you read their web page they also mention the Cell processor will be able to handle broadband rich media applications and streaming content:
The first-generation Cell Broadband Engine (BE) processor is a multi-core chip comprised of a 64-bit Power Architecture processor core and eight synergistic processor cores, capable of massive floating point processing, optimized for compute-intensive workloads and broadband rich media applications.

Re:Has nothing to do with Broadband

[Anonymous Coward]

Frequency division multiplexing of multiple signals for transmission over a medium, such as coaxial cable.

Re:Has nothing to do with Broadband

[ScottCooperDotNet]

Simply because IBM mentions broadband doesn't mean it has anything to do with system-to-system data transmission. This sounds a bit like Intel's marketing of "shiny new Pentiums make the Internet faster."

"The Pentium III will make the Internet a much more consumer-friendly environment," says Jami Dover, Intel's marketing vice president. Surfing today, Dover maintains, is a limited experience because data-transfer rates over ordinary telephone lines do not allow for high-quality audio, video and 3D graphics. "You take people raised on TV and show them a flat, text [Web] page," says Dover. "It's quite a juxtaposition." I guess Intel was hoping the world could go through a phone line with enough compression.

To us this is a nitpick, to the general public this is more confusion in a jargon filled marketplace.

Re:Has nothing to do with Broadband

[Hurricane78]

Well... in fact, you won't believe it, but actually it DID make the internet faster. At least that's what zdnet wrote in some internet pro and pc pro tests... I'm sure i still have the article somewhere below tese piles of magazines... hmmm...

If i remember it correctly they did several "real-life" benchmarks by rendering huge graphics- and plugin-loaded webpages and measuring the time. They even wrote that before, they laughed at intel because they believed it was absurd. but ot after they did their tests..

Well sure this depends on how much you trust the zdnet-labs. I did back then. Nowadays i don't know... ...but who cares anyways, because i'm no fan of electricity powered heating plates with data processing facilities... they're not very economic... for both functions... ;)

Re:Has nothing to do with Broadband

[pomo monster]

Faster processors enable better compression so that you can squeeze more into less bandwidth. H.264, for example, is by most accounts the most bandwidth-efficient video codec (widely available right now), but it takes a lot of processor muscle to decode. AAC, same thing compared to MP3, though you'll never max out your processor playing AAC the way you might for a HD H.264 stream.

Re:Has nothing to do with Broadband

[Anonymous Coward]

This is a perfectly legit use of the term broadband from the perspective of a computer architect or communications specialist. Just because you like to apply the word to computer networks doesn't mean it is the only place you can apply the word.

Re:Has nothing to do with Broadband

[wpmegee]

Intel's pulled this trick before too. The P4 core is called NetBurst, and it makes the intarwebs really fly!

Re:Has nothing to do with Broadband

[Billygoatz]

Here's my definition of Broadband

Heart
Joan Jett and the Blackhearts
The Bangles

Re:Has nothing to do with Broadband

[mo^]

Oh for a Mod Point.

thanks for making me smirk

Wow ...

[JMZorko]

... all those _registers_ make me salivate! One of the coolest things about the RCA1802 (the processor I learned on) compared to others in its' time was that it had _loads_ of registers when compared to a 6502 or 8085. It spoiled me, though ... when I started exploring those other CPUs, I always thought "Huh? Where are all of the registers?"

So yes, I want a Cell-based devkit now, 'cuz this sounds like _fun_ :-)

Regards,

John

Re:Wow ...

[Ziviyr]

Umm, did the 6502 need many registers? If there were to be many more and they were to be useful command size might out-reach bus width, some fancy dancing might make it a break-even on speed. Best idea might be a scratchpad area built in, still not much of a win over just using zero-page.

I wonder how well an uber-multicore 6502 at appropriately modern clockspeeds would fare today...

Re:Wow ...

[tgd]

What, an accumulator wasn't enough for you?

Kids these days...

Re:Wow ...

[Ziviyr]

The 6502 had X and Y too.

Re:Wow ...

[the_greywolf]

X and Y are index registers, and they aren't used in calculations or any "real work," just primarily for adddressing memory. (though, admittedly, some basic instructions provided for X and Y could be used for "real work" if you feel like juggling registers.)

Re:Wow ...

[gabebear]

A quick calculation shows that the Cell has BUTT LOADS OF REGISTERS!!!

SPE registers = 8 SPEs * 128 registers * 128 bits
PPE registers = 2 threads * (32 integer + 32 floating pont) registers * 64 bits
PPE VMX-128 registers = 2 threads * 128 registers * 128 bits

Grand total = 21+ Kbytes of registers, not to mention the 2 Mbytes of SRAM on the SPEs.

This thing is going to be a lot of fun!

ps3 programming

[orlyonok]

from the article and if the ps3 cell cpu is even half the processor than this monster is i say that game companies will need a lot of real programmers to make real good games (as if they cared).

Re:ps3 programming

[Anonymous Coward]

from the article and if the ps3 cell cpu is even half the processor than this monster is i say that game companies will need a lot of real programmers to make real good games (as if they cared).

Huh? I always thought real programmers were the ones who could get Doom 3 to run faster on an 8088, not use excessive processing power to do simple tasks. Real programmers don't need the new processors. But real programmers are expensive and hardware isn't. Hire a couple of girlie-men programmers and some powerful hardware and then ship a bloated product. If real programmers were in such demand we wouldn't see the pseudo-languages of C# are VB (among others) to protect girlie-men programmers from themselves.

Ooh. Obligatory real programmer note: real programmers program only in FORTRAN, assembly language, or machine code.

Re:ps3 programming

[MikeFM]

It'd seem to me that a lot of the development trickery will be in getting a proper compiler and specialized libs out there that take advantage of this parallelism without requiring massive changes to how the average developer has to write their code.

Most of the bitching we've heard from developers so far hasn't been that the cell sucks but that their existing codebases don't take advantage of it's design and they don't want to make a rewrite that locks them into the platform.

As with every platform the really good stuff will come out a couple years after it's release. At least with the Cell they are pushing it to go mainstream instead of just for gaming consoles so we should expect to see development moving along much faster than with a plain console.

Re:ps3 programming

[tepples]

Obligatory real programmer note: real programmers program only in FORTRAN, assembly language, or machine code.

Or in situations where use of lowest-level languages is deprecated, such as when one set of program logic has to work on a PC-class machine and a handheld device[1], they program in C and make sure to look at the generated assembly language code (gcc -O3 -S) to make sure that the compiler is in fact doing its job.

[1] This situation is common in multiplatform video game development.

Re:ps3 programming

[NanoGator]

"from the article and if the ps3 cell cpu is even half the processor than this monster is i say that game companies will need a lot of real programmers to make real good games (as if they cared)."

I'm not so worried about the programming aspect of it. Yeah, it'll cost more, and in the beginning it'll be nerve wracking to get adjusted, but I expect that in the end it'll be the least of their concerns. Not only will the techniques be laid down, but I imagine there'll be a lot of engine licensing going on. I imagine they'll even get to a point where it's less about the technical aspects and more about the the technique. But.. I really am babbling about something I know little about so I'll let it rest there. Mainly I'm replying because I remember hearing comments about this with the PS2 and today you never really hear about it anymore other than the occasional developer comment that the XBOX and GameCube are easier to develop for. It's not like its game library suffered badly for it.

I imagine the big increase in spending will go towards the artists, designers, and the sound people. In summary, I mean content / assets. Lotsa RAM to fill up there with visuals. I'm seriously wondering if we're going to see a 100 million dollar game in the next 10 years.

Re:ps3 programming

[iota]

from the article and if the ps3 cell cpu is even half the processor than this monster is i say that game companies will need a lot of real programmers to make real good games (as if they cared).

1. Some of us do care, actually.
2. The Cell processor described is exactly the processor in the PS3.
3. Yes, regardless of what some would like to believe, there is no magic. It's different, but it's the way things are going, so some of us are adapting the way develop. It'll take work, and maybe a little time, but that's always been our job - we get hardware and we figure out how to do something cool with it.
4. It is actually really fun to work on and very impressive.

Re:ps3 programming

[orlyonok]

Yes that's true, and you can have this scenario developing for handhelds: you have coded the fastest possible algorithm in C and your code is beautifully optimized by gcc, but the testers say that the frame rate is still 20 to 30% bellow the bare minimum and your boss want it to be fixed by tomorrow in the morning, in those cases you develop a radically novel algorithm from scratch, take the assembly generated by the compiler and bump it to the maximum manually or pray to have a real programmer nearby, if all else fail, you find an elegant way to end your suffering.

Re:ps3 programming

[iota]

It'd seem to me that a lot of the development trickery will be in getting a proper compiler and specialized libs out there that take advantage of this parallelism without requiring massive changes to how the average developer has to write their code.

Certainly people are working on that very idea. However, it's a long way off and not likely to happen in the lifetime of this version of the processor. Both XLC (IBM's optimizing compiler) and GCC have a very difficult time vectorizing (i.e. taking advantage of the SIMD instruction sets) within a single processor. IBM has released a Cell SDK for managing the PPU/SPU at a higher level, which should make the transition slightly easier for some developers, but on the whole - there is no way around the fact that the final algorithms and data design are very different when targetting a Cell.

Most of the bitching we've heard from developers so far hasn't been that the cell sucks but that their existing codebases don't take advantage of it's design and they don't want to make a rewrite that locks them into the platform.

These developers that are bitching are just the decendants of the developers that were bitching when games moved from 2D to 3D. That caused a major upheaval as well. We lost a lot of programmers in that transition, we're bound to lose some here too. But times change and multi-processing has been a long time coming - it's not going anywhere. The Cell may be a hit, or not - but the software techniques will be the basis of what we do for quite a while.

Re:ps3 programming

[ctid]

2. The Cell processor described is exactly the processor in the PS3.

Not quite. I heard a talk from a Sony representative and she said that the PS3's cpu has eight SPEs, but only seven of them are enabled. This is to increase yields.

Re:ps3 programming

[BasilBrush]

True. But that may well be just software. Perhaps at power on it loads a test program into each of the SPEs, and chooses 7 of the SPEs that complete without error. Or perhaps it's done as part of a soak test at the factory, and the SPE that's not to be used stored in non-volatile memory on the PS3.

Re:ps3 programming

[ctid]

That's a good point. I hadn't thought of it that way.

Re:ps3 programming

[Andy_R]

The article suggests to me that game companies will only need average programmers to make real good games, but they will need some absolute geniuses if they want to optimise them.

Even if you forget the SPEs entirely, and just write for one of the two threads the PPC offers, then you'll have a lot more horsepower than the PS2 to throw around. I exepct we'll see some pretty impressive early games that have the SPEs doing either nothing, or fairly minimal things like generating music, or doing little bits of algorythmic texture generation, and it will be years before we have games routinely pushing the Cell's bandwidth and processing power limits on all avaialble cores.

If I was programming, then I'd be looking at learning to deal with SPEs at the lowest possible level, as that's going to be a very important skill as other CBEA chips (ie. different varieties of Cell) start popping up everywhere.

Re:ps3 programming

[TheRaven64]

C is an incredibly bad language for programming a modern CPU. There are many parts of the C language which assume that the target machine looks a lot like a PDP-11. Trying to turn this code into something that runs on a superscalar machine, let alone a vector processor is incredibly difficult - we can only do it at all because such a huge amount of effort has been invested in research. If you want a good language for programming something like the cell, then you should take a look at more or less any functional language.

Oh, and anyone who thinks functional languages are scary should realise that they probably use (a very primitive and unfriendly) one for their build system - make.

Re:ps3 programming

[waxwing]

A Bluebottle port to the Cell would be ideal as far as I am concerned. Then, a functional language like Ocaml or Moby was wanted, it could be written in Oberon. I've got a software realtime raytracer running on Bluebottle (dual boot Linux/BB x86 box). Boy, would I like to port it to Cell. Of course the tracer could be converted to C++. But that would be ugly.

Re:ps3 programming

[indigoid]

The article suggests to me that game companies will only need average programmers to make real good games, but they will need some absolute geniuses if they want to optimise them.

I would suggest that what game companies need to produce good games are good, creative game designers.

Unless, of course, you are hacking together Virtua Strip Poker, in which case you have my full blessing to spend 95% of the budget on pretty graphics ;-)

20 core die

[Anonymous Coward]

Amazing progress. So with 20 cores on a single die, we can play D&D in real time?

It's Saturday night and I'm all alone here, cut me some slack...

Re:20 core die

[Anonymous Coward]

Think it will be long until the 100 core for Cthulhu? ;)

Re:20 core die

[numbware]

It's Saturday night and I'm all alone here

I think that the D&D joke gave that away...

Re:As Usual...

[Anonymous Coward]

Then go back there.

Re:As Usual...

[Anonymous Coward]

Funny, I read this on your mama's back last night.

Re:ps3 programming...no, not really

[Fallen Kell]

I say no, they won't need lots of real programmers. They only need 1 or 2 per game team to do the overall design and let the compilers do the rest. Since the real guts of it will be compiler optimization. If your lead designers do their job, the compiler will be able to do its job and everything will work like it should.

Its when you take old code from previous things and then try to do a direct port that you will see some issues in performance hits. But if designed from the ground up in terms of the code for a cell environment (or ANY CPU architecture), it is all in the hands of the few top level software design architechs to properly structure the overall workings of the game's code. Once the structure is correct, sending the bits and pieces that need to be made to the rest of the code monkeys is no problem, they just need to follow the UML or whatever other design docs they are specifically suppose to implement.

Re:PS3 Suggestion

[spoonboy42]

The PS3 has 512M of memory by default. It is half Rambus XDR and half GDDR3, but both segments of memory can be addressed by both the processor and the GPU.

You earned your geek gold card!!

[Anonymous Coward]

Looks like you officially earn you geek gold card today! Congrats.

Re:PS3 Suggestion

[Trigun]

Just cut Sony out of the loop, and have IBM do the work. They could re-revolutionize the desktop PC market.

A couple of hundred registers...

[Gordonjcp]

What do you think Page 0 was for?

Oh baby!

[Anonymous Coward]

Damn, nothing gets me fired up on a Saturday night like the thought of a nine way!

yea but

[rrosales]

can it do infinite loops in 5 seconds?

Re:yea but

[Anonymous Coward]

Can Linux really do this? Whats the story behind this quote?

Re:yea but

[Maavin]

No, but I heard it can do the Kessel Run in less than twelve parsecs!

Re:yea but

[dohzer]

If it's still only 12 parsecs I guess we haven't really advanced much from "a long time ago".

Re:yea but

[Shaper_pmp]

Since 12 parsecs is a measure of distance (not speed), you wouldn't expect it to change.

(Less stellar drift/varying relative velocities, etc, but they shouldn't count for much on the scale of parsecs, unless "a long time ago" is of the order of millions of years).

Re:PS3 Suggestion

[Doppler00]

Waaaaiiit a minute. This is the same DRM the heck out of everything Sony we are talking about here right? There is no chance they are going to allow a linux distribution to run easily on this platform. They are probably encrypting everything like Microsoft is doing with the XBox360.

People keep forgetting that Sony and Microsoft are in absolutely no way interested in providing you with a cheap computing platform for your linux cluster endevours at their loss. They make money off of selling games for these things. If people find ways of loading their own software on these boxes you better beleive they are going to start filing lawsuits. Not that I agree with that, but that will be what happened.

Re:PS3 Suggestion

[rpdillon]

Every PS3 hard drive is shipping with Linux onboard.

Remind anyone...

[Kadin2048]

... of the promotional material for the Sega Saturn from a few years back?

I remember right about the time it came out, there was a lot of hype about it's architecture. Two main processors and a bunch of dedicated co-processors, fast memory bus, etc., etc. I don't remember any more specifics, but at the time it seemed very impressive. Of course it flopped spectacularly, because apparently the thing was a huge pain in the ass to program for and the games never materialized. Or at least that's the most often spoken reason that I've heard.

Anyway, and I'm sure I'm not the first person to have realized this, Cell is starting to sound the same way. The technical side is being hyped and seems clearly leaps and bounds ahead of the competition, but one has to wonder what MS is doing to prevent themselves from producing another Saturn on the programming side.

Re:Remind anyone...

[seebs]

MS?

Uhm. MS is the one with the 3-core PPC. This is a 1-core (dual-threaded) PPC with 8 coprocessors.

And I want one.

Re:Remind anyone...

[earnest murderer]

At the time there was also the issue of the PS1 being more powerful in addition to doing 3D while the Saturn basically had 3D support added in response and it not being very good.

This same "difficult to program" issue came up with the PS2 but seems to not have had much of an impact overall on sales. :)

Re:Remind anyone...

[Anonymous Coward]

There are some key differences between Sega and Sony. With the exception of the Master System, Sega's consoles were always inferior to the Nintendo (and later Sony) consoles. Sega was always playing catch-up to Nintendo, even though they were first to market with each generation. Sega made the mistake in the beginning of being the only publisher for Master System games. Getting developers to sign on was *already* a problem for Sega when the Saturn came out, and they were consistently doing poorly compared to Nintendo. Sega was also relatively small.

In contrast, Sony is huge, doing well, and has many publishers writing titles for their current consoles and portables.

Re:Remind anyone...

[Anonymous Coward]

Odd you mention that. Since it's the same tale told about the PS2, but I don't recall it flopping.

Re:Remind anyone...

[Jarnis]

Well, that would mean the first PS3 games that are any good are at least 2 years away.

Only recently (past 1-2 years) PS2 devs have begun to really exploit the aging hardware. And due to teeny RAM of PS2, it really takes skill.

Re:Remind anyone...

[Sycraft-fu]

Well, not quite. The odd processors were a problem for the Saturn, but not the major one. The really major problem was that it wasn't good at 3D. The Saturn was basically designed to be the ultimate 2D console, which it was. However 3D was kinda hacked on later and thus was hard to do and didn't look as good as the competition. This was at a time when 3D was new and flashy, and thus an all-important selling point.

However you are correct in that having a system with a different development model could be problematic. Game programmers (and I suppose all programmers) can be fairly insular. Many are already whining about the multi-core movement. They like writing single-thread code, a big while loop in essencde, since that's the way it's always been done. However the limitations of technology are forcing new thinking. Fortunately, doing multi-threaded code shouldn't require a major reqorking of the way things are done, espically with good development tools.

Well, the Cell is something else again. It's multi-core to the extreme in one manner of thinking, but not quite, because the Cells aren't full, independant processor cores. So programming it efficiently isn't just having 8 or 9 or however many cores worth of tasks for it.

Ultimately, I think the bottom line will come down to the development tools. Game programmers aren't likely to be hacking much assembly code. So if the compiler knows how to optimise their code for the cell, it should be pretty quick. If it doesn't and requires a very different method of coding, it may lead to it being under utilised.

Now it may not be all that imporant. Remember this isn't like the PS2, the processor isn't being relied on for graphics tranformations, the graphics chip will handle all that. So even if the processor is underultilised and thus on the slow side, visually stunning games should still be possible.

However it is a risk, and a rather interesting one. I'm not against new mthods of doing things, but it seems for a first run of an architecture, you'd want it in dev and research systems. Once it's been proven and the tools are more robust, then maybe you look at the consumer market. Driving the first generation out in a mass consumer device seems risky, espically given that the X-box has lead time and thus it's development model is already being learned.

Re:Remind anyone...

[TheRaven64]

Many are already whining about the multi-core movement. They like writing single-thread code, a big while loop in essencde, since that's the way it's always been done.

Meanwhile, those of us who have been advocating building large numbers of loosely coupled, message passing, components all running with their own process space gave enormous grins on our faces at the thought of being able to do the message passing via a shared cache with only a cycle or two penalty...

Re:Remind anyone...

[MikeFM]

I imagine the multi-core design will improve AI code, weather simulation, physics simulation, etc. Anything that needs lots of small concurrent calculations.

It seems that the cell design, once utilized, should make for games that feel better even if they look the same. Maybe the difference won't show in a screenshot but you'll be able to tell it's there when you play the game.

I'm interested in the rumor that multiple Cell processors will be able to work together even over the PS3's built-in networking. That could open up some interesting possibilities. Bigger tasks could be broken up across multiple Cell's for more bang. Especially awesome if the same will be true of Cell's in blade servers and other real world apps. Not needing a third party solution to run a program across multiple machines would be really awesome.

Re:Remind anyone...

[MikeFM]

All consoles suffer from the problem of games only really exlpoiting the systems full power after a couple years of developer practice. Really, unless it's based entirely on an existing known system, you have to expect that.

Underestimating RAM needs is a common problem too. At least since BG's 640K is enough for anyone.

Re:Remind anyone...

[spectecjr]

Meanwhile, those of us who have been advocating building large numbers of loosely coupled, message passing, components all running with their own process space gave enormous grins on our faces at the thought of being able to do the message passing via a shared cache with only a cycle or two penalty...

Yeah, but are you used to doing that in a DSP-like architecture, where most of your operations are going to be SIMD ones lest you hit massive branch penalties?

Re:Remind anyone...

[TheRaven64]

Interesting question. It probably could be done. Split the task into segments that can be done without conditional branching. Put each of these in a SPU task. Now your branching is not in the execution phase, it's in the part deciding where you send your results. Assuming that you have an OS that can multiplex the SPUs, this could work quite efficiently.

Re:As Usual...

[Durinthal]

Not to feed the troll or anything, but I haven't. And I do read digg regularly. Maybe I've missed something in the half-dozen different search terms I've tried (and feel free to correct me if I have), but it seems that this comment is nothing but troll. And honestly, even if it was on digg a week ago or whatever.. Why? Do you really hate /. so much that you take time from your day to make such caustic (and useless) posts?

Mambo development

[iota]

Development for the Cell is open. You are free to download IBM's Cell Simulator.

Written in C, a significant part of the Full-System Simulator's simulation capability is directly attributed to its simulation multitasking framework component. Developed as a robust, high-performance alternative to conventional process and thread programming, the multitasking framework is a lightweight, multitasking scheduling framework that provides a complete set of facilities for creating and scheduling threads, manipulating time delays, and applying a variety of interthread communication policies and mechanisms to simulation events.

The simulator runs a Redhat kernel, so the programming model will be familiar. Also both SCE's (gcc-based) and IBM's (XLC) compilers are available for both the PPU and SPU.

IBM will also be releasing Cell-based Blade servers next year, so pick one up if you're serious about development!

Reminds me of programming the nCube

[Animats]

The nCube, in the 1980s, was much like this. 64 to 1024 processors, each with 128KB and a link to neighboring processors, plus an underpowered control machine (an Intel 286, surprisingly.)

The Cell machines are about equally painful to program, but because they're cheaper, they have more potential applications than the nCube did. Cell phone sites, multichannel audio and video processing, and similar easily-parallelized stream-type tasks fit well with the cell model. It's not yet clear what else does.

Recognize that the cell architecture is inherently less useful than a shared-memory multiprocessor. It's an attempt to get some reasonable fraction of the performance of an N-way shared memory multiprocessor without the expensive caches and interconnects needed to make that work. It's not yet clear if this is a price/performance win for general purpose computing. Historically, architectures like this have been more trouble than they're worth. But if Sony fields a few hundred million of them, putting up with the pain is cost-justified.

It's still not clear if the cell approach does much for graphics. The PS3 is apparently going to have a relatively conventional nVidia part bolted on to do the back end of the graphics pipeline.

I'm glad that I don't have to write a distributed physics engine for this thing.

Re:Reminds me of programming the nCube

[bit01]

I'm glad that I don't have to write a distributed physics engine for this thing.

Granted, it's harder to program on a multi-processor. But it's not that much harder, more just fear of the unknown.

Programmers are already multiprocessing bigtime to handle multiple IO devices and to watch the wall clock time (independent of the processing time) and it's a rare real world programming problem that can't be easily partitioned, usually geometrically. In the case of the physics engine I'd initially just put the physics engine on a separate CPU. If that wasn't enough I'd just use a farmer-worker paradigm to farm out the physics work to multiple CPU's.

Having said that I'm a little scared of the number of programmers out there who don't know what a race condition is and how to avoid it...

---

Unrestricted DRM = Total Customer Control = Ultimate Customer Lockin = Death of the free market.

Re:Reminds me of programming the nCube

[plalonde2]

I disagree that that the cell architectures is "inherently less useful than a shared-memory multiprocessor".

Shared memory is the cause of 80% of the nasty little race conditions programmers leave peppered through their code on parallel machines - it's just too easy to break discipline, particularly considering the crap programming languages support we have - C and C++ are just not up to the task because of their assumption that you may touch anything in the address space.

Cell-like architectures have one other advantage, particularly in performance-sensitive applications: the explicit DMA to local stores *makes* you look at how the busses work on that machine, and they do not really differ from the busses on non-Cell-like modern machines; the structure of your Cell code will be bus-friendly on pretty much any architecture you port it to. And in our modern world, the bus is the bottleneck.

Re:Reminds me of programming the nCube

[MikeFM]

I wonder if they aren't considering inventing a new language, or modifying an existing language, that has constructs to make this kind of programming easier. Something that would let you create tasks that look like sepperate mini-programs running but can communicate easily using some common concept such as pipes. There is really no reason that programmers need to write everything in C and C++.

A Python-like language that had extra semantics for the multi-processor design and that compiled down to machine code would be good I think. Easier and less verbose than Java, C, or C++ with good OOP support. Why muck with the details when you can avoid doing so. It amusses me that most games and graphical programs just run in a while loop but that you still have to specify the while loop in the language. Couldn't the language just know little details such as that? It's not a big detail but over the course of a large program the little details add up and make the program harder to understand.

Or a OS that can do the same would work. Let it run the main program as programmers would normally expect and run the SPE programs as sepperate programs and again let them communicate in some known method such as pipes.

When I was a kid one of the first enviroments I learned to program in was MOO (MUD Object Oriented) which is a somewhat interesting enviroment to learn in as it consists of a text-based multi-user online enviroment that every user can add new programming to as the game runs. The entire system was object oriented and obviously objects could work together but you didn't need to worry about the details of what other objects were doing most of the time. THAT is an incredibly powerful concept I think and one that could be very suited to multi-core or multi-processor systems. :)

Faster Than Realtime - Just port Nethack

[billstewart]

Faster than realtime? Sure, no problem....

You can run a 68000 or 80386 emulator in each of the SPUs, or just run lots of native processes in parallel.

Re:Faster Than Realtime - Just port Nethack

[imsabbel]

Because those SPUs are SOOOO good at integer, especially the brach-heavy stuff like emulators need...
Not to mention having no cache at all will be SO great in such a non-streaming application (and no, those 256K ram dont count)

they gave up...

[YesIAmAScript]

Both Sony and MS realized they couldn't make a single true general-purpose CPU with the performance they wanted for a price they could afford to sell in their consoles.

Sony went to a CPU, GPU and 7 co-processors (Cell).
MS went to a 3 CPUs with vector-assist and a GPU.

Both companies are going to need to spend a lot of time and money on developer tools to help their developers more easily take advantage of their oddball hardware, or else they will end up right where Saturn did.

I guess the good news for both companies is that there is no alternative (like PS1 was to Saturn) which is straightforward and thus more attractive.

PS2 requires programming a specialized CPU with localized memory (the Emotion Engine) and it seems to get by okay. So developers can adapty, given sufficient financial advange to doing so.

Re:they gave up...

[thomasscovell]

No alternative? The Nintendo codename-Revolution will be comparatively "under"-powered, but will definitely be a simpler machine to code for and have novel (not novelty!) controller hardware that will afford the kind of possibilities Sony and Microsoft's idea of "next generation" don't offer. Just pushing more polygons isn't where it is at. There's been no growth in size of the gaming market since the SNES era, just more spending by those who do game. Nintendo's next generation model is at least looking to increase the gaming demographic, just the way their Nintendo DS handheld as (senior gamers? plenty of those in Japan not thanks to the DS!

Re:they gave up...

[Anonymous Coward]

There's been no growth in size of the gaming market since the SNES era, just more spending by those who do game.

Pardon me but...

My 3 year old nephew has been given some lessons in how to hold a controller recently, and although I'm not ready to call him "hardcore," he seems destined to become a "gamer"

So you're statement is completely wrong. Just in my own life I've helped to increase the gaming market by 1.

You must be too young still to have any next generation relatives or you would realize that the gaming market has grown unbelievably since the "SNES Era" - hell I have 4 cousins - all gamers - who weren't born when the SNES was hot stuff.

Mindstorms!

[fub]

Time to port the Lego Mindstorms development environment to the Cell processor!

Re:Blowjob

[Anonymous Coward]

Did you really have to give us details of the fun you are having with your dog?

Task switching...

[Anonymous Coward]

The cell seems to be great for system with a limited number of tasks (like a game console), but what about general OS ? Context changes seems to be a big problem and it looks like this CPU will be very bad in a general desktop computer.

I wonder... is there any processor that are good for tasks switching (by having, for example, several sets of registers and TLB so a task switch only mean using another set instead of saving and loading everything to memory) ?

Re:Task switching...

[freeduke]

For use with general OSes, what could be interesting would be a dual-core PPE with those 8 SPE.

The first core could be the main processor, handling processes, and the second core, could just be there to be interrupted by dedicated threads executed on the SPEs, and communicate with them. The main problem would come from memory bandwidth used by the core which handles the 8 SPEs, it should be designed to minimize the impact on the first core.

A solution to this could be to have a cell processor and a traditional single-core processor, both of them using HT to improve memory bandwidth. But it seems to be complicated. Anyway, this Cell processor could be interesing as a threads management unit.

Another point should be to double memory to each SPE, and prefetch context switches while another thread is running on it, and once, the context switch is done, retrieve data from the previous thread: this could me managed by the PPE. And if you combine this solution with a non-synchronized timer interrupts on each SPEs, I bet you can get a pretty good improvement on memory bandwidth consumption made by a cell unit...

With all those basics ideas, I think that there is plenty of room to use efficiently those cell processors

Re:Task switching...

[ja]

For use with general OSes, what could be interesting would be a dual-core PPE with those 8 SPE.

Well, it seems like it is (almost) your lucky day today.

The PPE is already hyperthreaded, posing as a dual core.

Re:PS3 Suggestion

[wheany]

I've wondered where the spammers have been hiding all this time. You fuckers spammed the hell out of my guestbook while I made no promises not to delete any messages. Here you have Slashdot, one of the world's most popular discussion forums and they do not delete (practically) any comments. Sure you will be moderated to -1 in no time, but the message will still be there for everyone to see, if they choose to.

Usually you are much more inventive. What the hell took you shitheads this long this time?

MOD PARENT DOWN

[imroy]

Note to moderators: the user "5, Troll" likes to cut and paste posts from other sites to gain karma. This one was found on the DeveloperWorks site with a quick google search.

Re:MOD PARENT DOWN

[imroy]

The proper thing to do in that case would be to post a link to the article. That is not what he's doing. He's copying someone elses *comment* from another forum and passing it off as his own. He's providing no indication whatsoever that he's doing this. No link, nothing. He's presumebly doing this to gain karma. And he obviously doesn't like me pointing this out, since he's just made me his foe.

Re:MOD PARENT DOWN

[Anonymous Coward]

He's presumebly doing this to gain karma.

Nope, as a result of this post which went up to 5 then down to -1 before settling at 1, my karma went from Good to Terrible (thanks to the warped Karma system penalizing double for downmods than it credits for upmods), and climbing out of that hole would be more trouble than I care to go through.

My goal is to achieve the moderation score of "5, Troll". Now that the cat's out of the bag, so to speak, all I need is more moderators on my side than are against me and I may just be able to achieve it.

Incidentally, if you are so cautious about improper karma acquisition, why didn't you post your "warning" as Anonymous Coward?

And he obviously doesn't like me pointing this out, since he's just made me his foe.

No shit? I'm "trolling" by adding value to the discussion. All you're doing is karma whoring (and having the audacity to accuse me of it?).

Does it run Windows?

[plusser]

The problem will be for much of the IT industry is that those making the decisions would ask only one question:

    Does it Run Windows?

If the answer is no that the manager will say something like:

    "I don't care if the processor is the most powerful ever developed, costs next to nothing to produce and will allow us to build a powerful computer the size of of pea. If it doesn't run Windows, then I'm not interested".

And that sums up the total IT knowledge of that manager.

Re:Does it run Windows?

[Anonymous Coward]

YES, IT WILL!

MS Windows Cluster Server ... (ha he he he)

Please don't forget to tip your waitresses...
I will be here all week...

Reply to: Reminds me of programming the nCube

[arrrrg]

IANAGP (game programmer), but it would seem to me that physics and lighting calculations should be easily parallelizable. Each processor can compute the physics for a separate set of objects / pixels / etc. Same for AI for each agent, if the companies actually bothered to put some effort into gameplay over graphics. On the other hand, I would guess that things like fluids (i.e. Far Cry) would be more difficult to do in parallel, due to the less local nature of the interactions.

CBE = Failure

[MOBE2001]

Mod me down if you wish but I think the CBE architecture is bound to fail. The reason is that you don't design your software model around a new processor. It should be the other way around. You first come up with a software model and then design a processor optimized for the new model. This way you are guaranteed to have a perfect fit. Otherwise, you're asking for trouble.

The primary reason that anybody would want to devise a new software model is to address the single most pressing problem in the computer industry: unreliability. The reason that software is unreliable is that it is based on the algorithm. Switch to a non-algorithmic, signal-based, synchronous model and the problem will disappear. Unfortunately current processor architectures, including the CBE, are optimized for the algorithm. Click on the link below for details on a new software model designed to solve the reliability problem.

Re:CBE = Failure

[plalonde2]

You're right - you don't design around a new processor.

But you should design around the changes in architecture that have been coming at us for the last 5-10 years: the bus is the bottleneck, and the Cell makes this explicit. It goes so far as to deal with the clock-rate limits we've reached by taking the basic "bus is the limit" and exposing it in a way that lets you stack a bunch of processors without excessive interconnect hardware (and associated heat) into a more power-efficient chip.

I've been working on Cell for nearly a year now, and it's been really nice being forced to pay attention to the techniques that will be required to get performance on all multi-core machines, which in essence means all new processors coming out. Our bus/clockrate/heat problems are all inter-dependent, and Cell is the first project I've seen that gets serious about letting programmers know they need to change to adapt to this new space.

Re:CBE = Failure

[Anonymous Coward]

lol, slashdot faggots -- "he expressed an opinion that made me cry because I'm a sensitive girl who wears training bras, so I'm going to mod him a Troll!"

Re:CBE = Failure

[Anonymous Coward]

Hi person who posted some annoying "mode me down if you must" comment and then whines anonymously about the faggots who are fed up with seeing another "mod me down" post, and actually do mod you down.

I hope your post gets moderated down into oblivion.

Re:CBE = Failure

[Anonymous Coward]

"The primary reason that anybody would want to devise a new software model is to address the single most pressing problem in the computer industry: unreliability. The reason that software is unreliable is that it is based on the algorithm. Switch to a non-algorithmic, signal-based, synchronous model and the problem will disappear. Unfortunately current processor architectures, including the CBE, are optimized for the algorithm. Click on the link below for details on a new software model designed to solve the reliability problem."

What is up with this guy??? Is this his response to every Slashdot article? Or is he just trying to get funding?

Re:CBE = Failure

[Anonymous Coward]

Damn, I hate you ACs that just bitch about other ACs bitching about "mod me down" posts from real slashdot users!

Slashdot just needs to get rid of ACs so I don't have to see another post like yours...

Re:CBE = Failure

[Anonymous Coward]

Damn, I hate you ACs that just bitch about other ACs bitching about other ACs bitching about "mod me down" posts from real slashdot users! Slashdot just needs to get rid of ACs so I don't have to see another post like yours..

rent out your ps3s redundant cell core?

[chumba]

if every ps3 was networked and sony rented out your redundant core to the DoD, how fast would the worlds most powerful super computer be?

Revolution

[HalAtWork]

I guess the good news for both companies is that there is no alternative (like PS1 was to Saturn) which is straightforward and thus more attractive.

It's called the Revolution.

HLL like Java & Smalltalk have two faults

[crovira]

the first is that they don't deal well with resource contention. No language, or any other thing for that matter, does.

When you fork N processes on N objects and you have N-M processors, it costs you computationally, which translates into efficiency.

Its one thing to think of this situation as a bunch (N) of ball-bearings going a bunch of holes (N-M) with each ball-bearing having its state information local to it. (Any kind of concept of a sieve can serve as a 'gedanken' experiment.)

The situation becomes hopelessly confused when there is any dependency on external data or process sources.

The mechanisms for handling that confusion are all basically ones of reducing the many threads down into a single thread and meting out the shared resource piece-meal.

A sufficiently evolved schema is capable of handling replication of a shared 'read-only' resource but, despite the efficiencies inherent in that situation, it merely shifts the burden of resource access up one level. There will be a stiffer computational penalty to be encountered when 'access starvation' is reached.

Hopefully the replication penalty will be acceptable, and there are ways to mitigate the computational cost of that penalty, but the trade-off is an instance-level, existential sort of thing and exists at run-time and can only be guess-timated at algorithm/method design-time.

The second fault is one of design of the languages themselves.

They are not designed to operate within a schema. Actually no language is so the efficiencies to be gained from using a schema are bolted on to the application and not an inherent part of it.

Re:HLL like Java & Smalltalk have two faults

[dlaur]

I wonder if we will see new language designs emerge due to the relative increase in the number of multi-processor/core CPUs out there. I mean something at a high level, not compiler improvements that try to overlap CPU operations from original top-down style code, but something that encourages the actual developers to use producer consumer patterns, co-routines, whatever, at their level to maximize utilization of CPU resources. We keep using the same old languages and assuming the compiler is smart enough to keep all the circuits busy. Anyone out there work on huge multi-processor systems or clusters that can free me from my ignorance?

Re:HLL like Java & Smalltalk have two faults

[TheRaven64]

Java and Smalltalk are both imperative languages and, while I am quite fond of Smalltalk, my post was about functional languages. Most functional languages don't permit aliasing, which dramatically reduces locking issues related to resource contention (and copy-on-write optimisations can make them very fast).

mnb Re:they gave up...

[Anonymous Coward]

You must be too young still to have any next generation relatives or you would realize that the gaming market has grown unbelievably since the "SNES Era" - hell I have 4 cousins - all gamers - who weren't born when the SNES was hot stuff.

I and most of my friends have stoped buying consoles and playing video games since the days of the SNES.

Add your 4, subtract my 4 and you get zero growth.

you're probably right

[YesIAmAScript]

Although Nintendo isn't even talking about the hardware specs, so we can't be sure.

But I didn't include the Revolution because Nintendo is saying the same thing they did with the Gamecube, that they don't need 3rd party developers. Revolution seems largely like a platform for Nintendo to sell you their older games again. Additionally, if Revolution is sufficiently underpowered compared to the other two, it may be that 3rd parties just plain cannot port their games to this platform, or else have to "dumb down" their game in such a way which might make the game uncompetitive with games that don't work on Revolution.

So, basically, N is downplaying new development so much on the Revolution that I simply left it out as a platform which would attract developers who were fed up with the other two. But probably I shouldn't have done so.

By the way, with all of this, I want to mention I'm a huge N fan. I have three GBAs, a DS and a Gamecube, plus all their other consoles back to the SNES. I just think that N is concentrating on 1st/2nd party development more than 3rd party development.

Re:you're probably right

[Anonymous Coward]

WHAT?!?

A lot of third parties have expressed their interest in the Revolution. Those last days rumours of Square-Enix releasing their games exclusively for the Revolution have been circulating all around the Internet.

Nintendo has learnt from its past mistakes, and know that they have to attract 3th parties.

Wow

[RESPAWN]

I haven't really done much programming since college and none of those programs have been multithreaded, so maybe I don't have the right background to comment. But, all I can say is wow. This is crazy compared to the Sparc processors that I learned assembly on. As somebody pointed out, not only do these processors have multiple cores, but apparently each one has 128 registers?! Processor design has come a long way.

That said, I see a lot of comments reflecting on how hard it will be for programmers to adjust to programming on this architecture. While I agree that there may be some learning that will have to take place, shouldn't most of the optimization take place on the compiler level? I mean, that's partly the point of languages such as C/C++: write a minimum ammount of architecture specific code and let the compiler do the rest.

Anyway, I find this new architecture very impressive and can't wait to see devices take advantage of this hardware.

Re:Wow

[Todd Knarr]

The compiler can't do a lot of the optimization this kind of processor needs. It's not a matter of instruction scheduling or selection, it's a matter of algorithm selection. To make use of the CBE you need to design your program to combine massive amounts of threading with massively parallel data processing within those threads. You're trying to get it so there's enough happening simultaneously to keep all those cores fed with instruction streams. The compiler can't rewrite your program to do that, the programmer has to handle that part of it.

That's also why the CBE and in fact any supercomputer's a bitch to program for for most programmers: they aren't taught to think in terms of dozens of parallel sequences at once. It's a whole different and very alien worldview, and if you don't have it you can't make the hardware perform very well. OTOH, if you do grok how the hardware wants to do things and can start thinking in those terms, you can make the hardware do things most people won't believe even after they see them (see what Gran Turismo 4 did with the PlayStation 2 hardware for an example).

Re:Wow

[quarkscat]

Imagine(TM) a cluster of these processor boards (PCI, PCI-X, SLI) with a compiler and IDE able to make use of them all. The Transputer computing engine has (AFAIK) all but died off, but this could conceivably be the 21st century's replacement.

Re:PS3 Suggestion

[Anonymous Coward]

Waaaaiiit a minute. This is the same DRM the heck out of everything Sony we are talking about here right? There is no chance they are going to allow a linux distribution to run easily on this platform. They are probably encrypting everything like Microsoft is doing with the XBox360.

WHooooo! Mod this tard up!
Massive multinational corporations act like they're a single unit with a single mind and a single philosophy to be applied from video game electronics to music!

Information was meant to be free
our only crime was curiousity!

Slash-dot! Slash-dot!
Nerd! nerd! nerd!

interconnect restrictions

[CdBee]

Since most of the inter-processor "interconnects" would be consumer-grade DSL/Cable links, it'd have phenomental capacity to process chunks of data but serious latency issues in distributing work units. Commercial cluster data-processing units probably use gigabit ethernet or faster connections to get around this.

Re:interconnect restrictions

[the_greywolf]

i was fortunate enough to see first-hand a prototype of a broadband LAN link (i forget what it's called) that at the time was capable of 800Mb/sec data transmissions with high efficiency when 1Gb links were still a year or so away. it was a chained network that avoided the problem of collisions by providing a direct connection from one computer to any other. the cable was about 0.5m long, but was a 24-line ribbon cable, and claimed to provide "100% efficiency" for over 200 computers. you could tell it was a prototype just by looking at the PCI cards. i think i wondered aloud how they got all that data on and off the PCI bus.

interesting at any rate.

by now, they've likely got it doing 16Gb/sec connections on higher-quality cables.

Re:interconnect restrictions

[MikeFM]

Still, plenty of problems exist that can be attacked that don't need to send a lot of data back and forth quickly.

Re:PS3 Suggestion

[Anonymous Coward]

this would be good if Sony wasnt already planning to abandon the Cell processor with the next itiration of Play Station and go with a derivitive of Emotion. Currently its a low yeild chip that is well ahead of it's time. If you thought Xenos CPU is going to be hard to program for wait until you start development for Cell. While the GPU is a pretty generic PC chip, Cell is unlike anything you have ever seen. Using all of those in order only SPEs is going to be damn near impossible unless IBM and the others come out with some development tools a few generations beyond what you see today.

Mod parent down, FUD

[Troglodyt]

This is in fact not the "DRM the heck out of everything Sony" we are talking about, this is another part of Sony.
The part of Sony that has been providing Linux kits for the PS2 since 2002.

The console homebrew scene is rather big, and Sony and Microsoft can do nothing about it.

Re:PS3 Suggestion

[TheGSRGuy]

2.5" drives don't have to be slow. Most laptops ship with 5400rpm (or even worse, 4200rpm) drives. I paid to upgrade to a 7200RPM drive w/8MB cache in my Dell notebook. Huge speed jump. You can even get 2.5" drives with 16MB caches. That would offer a significant speed bost.

Frankly, I don't see why they couldn't just use flash memory instead...everyone's doing it these days.

Fail!

[IntergalacticWalrus]

"programming for the CBE is like programming for no processor you've ever met before"

Which is exactly why it will never take off.

Re:Fail!

[Anonymous Coward]

"programming for the CBE is like programming for no processor you've ever met before"

You're assuming the parent was correct. He/she is in fact incorrect. The development environment will do all this for you. you create the game the same way you would anyway~well almost, and do a little more to fully utilize the deistributed vector units etc. but thats not essential and not a big part of the problem. Also, there are many other appliations to the cell - far superior streaming etc. It's not just for the PS3. Do you really think Sony would just leave it all to the developers - unlikely they need to give developers an added incentive to chose this platform as well as the obvious incentive that it is going to be very powerful.

Which is exactly why it will never take off. I think it will it's just a question of how high it will (be allowed to) fly.

I remember the 1802, too

[Flying pig]

You had to do subroutine call and return in actual code. It wasn't until the 1805 that you got a very slow microcoded call and return and that you got to be able to load and save those registers to the stack without programming (RSXA and RLDX). The trouble with the 1802 was its microarchitecture was just too exposed to the programmer - like the PDP-8. I really don't want to go there again.

Another horrible early processor was the TMS9900, which pretended to have 16 16-bit registers but they were just mapped memory. And that too didn't have a proper subroutine call and return. It really wasn't better in the old days.

Re:PS3 Suggestion

[Anonymous Coward]

> 256 MB for the OS is not enough.

what planet do you come from?

There's only one OS that 256MB isn't enough for...

Re:PS3 Suggestion

[Anonymous Coward]

You are SO wrong! The GPU has access to the full 512 MiB of memory on the PS3. The 256 MiB Rambus part is speedier and therefore first choice. The 256 MiB og RD3RAM has badwith of 22.4 GiB/sek and is available to all components of the PS3 (GPU, Cell, lots of DMA : Bluetooth, 3 gigabit ethernet, USB 2.0, harddrive etc) - therefore not as fast during normal use ...

Won't work...

[SmurfButcher Bob]

cellular broadband coverage is spotty at best in my area, and the damned providers charge too much per minute for the airtime. :)

Re:PS3 Suggestion

[gabebear]

"Every PS3 hard drive is shipping with Linux onboard."

I sure hope that's true, but I'm pretty sketical. Sony makes butt loads of cash off the software sales for the PS2 so if Sony actually does give us Linux it's going to have some strings attached. For example, I very much doubt that Sony will give us access to the GPU.

What gives me the most hope for a relatively unencumbered PS3 Linux distro is the Blu-Ray format. All Blu-Ray players will have a Java layer for interactive crud, which should be enough for stupid little games( i.e. Tetris, Puzzle Bobble, Metal Slug ), Sony almost has to concede the the non-3D market.

I'm personally really excited about the BD-J stuff, and the homebrew scene that will grow up around it.