Cell Architecture Explained 570
IdiotOnMyLeft writes "OSNews features an article written by Nicholas Blachford about the new processor developed by IBM and Sony for their Playstation 3 console. The article goes deep inside the Cell architecture and describes why it is a revolutionary step forwards in technology and until now, the most serious threat to x86. '5 dual core Opterons directly connected via HyperTransport should be able to achieve a similar level of performance in stream processing - as a single Cell. The PlayStation 3 is expected to have have 4 Cells.'"
So (Score:1, Interesting)
Also can it run linux?
Is it just me? (Score:3, Interesting)
http://www.blachford.info/computer/Cells/Cell_Dis
Make it look a little more like a HAL than a Cell?
Re:Compiler technology (Score:2, Interesting)
Program in a language that is referentially transparent [wikipedia.org].
...once you can assume that any function is able to be concurrently executed all you have to solve is the communication between processors/storage. The latency of current networking technologies makes this unpractical for general tasks, but this is less of a problem with a low-latency internal bus.
Time to drag those Haskell textbooks out of the closet and dust them off. ;)
Re:if it sounds too good to be true.. (Score:2, Interesting)
I don't remember Sony making any big statements about the Emotion Engine being a supercomputer. What I do remember, is that when they released the clock speed of their processor, people knew the relative power of the PS2. From what I see of the Cell architecture, I can guarantee that the Cell is much more powerful than any AMD and Intel processors.
It seems like you didn't read much into the technical aspect of the Cell architecture presented in the long write-up. From just looking at a simple top-level diagram of the Cell architecture, it is clearly shown that the Cell is much more powerful than any other processors currently available. A Cell contains a Processor Unit with 8 additional Processor Units, each with its own registers. The architecture is also a distributed computing network capable of splitting tasks and computations over a wide variety of home electronics. Each Cell product you buy, you are increasing your processing power of your household. In conclusion, yes, it would smoke a x86 counterpart.
Reason why IBM sold PC unit to China? (Score:2, Interesting)
Re:What always confused me (Score:2, Interesting)
Unfair comparison (Score:3, Interesting)
From TFA: "Existing GPUs can provide massive processing power when programmed properly, the difference is the Cell will be cheaper and several times faster."
Its supposed to do 250GFlops when? 2 years from now? Apparently the Geforce 6800 Ultra will do 40GFlops and thats today.... extrapolate with some doubling here and there it seems a lot more reasonable.
So the big thing is that it comes down to programming. It came up a few times in the article "Doing this will make it faster but will make for one hell of a time for the programmers" It may have a huge potential but may take a while to get everything efficiently as Sony would like. Reminds me of when the GF3 first came out and was beaten by the GF2U in some tests. IIRC it took a while for games to come out that took advantage of its programability. It'll be interesting to see how well the programmers can fair between now and Cell's release.
It needs some serious software to work! (Score:4, Interesting)
Also, let's not forget that developers will be unable to keep up, unless some highly sophisticated libraries and languages are made available. I really don't expect the majority of developers to be able to cope with massive parallelism from the beggining (not just 2x SMP or hyperthreading, this needs a totally different mindset).
To sum this up: the hardware will deliver, but the software is a critical unknown in the equation. I have faith in IBM
P.
Locked Up (Score:2, Interesting)
Fortunately, cell reading meant I hardly noticed the claim that hardware would compete with the x86 because, unlike the x86, cell computers need all their software written for the specific hardware.
I like how "hardware-specific" becomes "OS-independent". Great I can plug my HDTV into my G/Fs "electrically powered adult novelty device", and harness the extra computing power to find out we are really alone in the world. Of course, no firmware will stand in the way.
I'm also surprised that, in pandering to all the OS underdogs in the slashdot crowd (Great day for Apple, since they like G5s; Great day for Linux, since many obsessive-compulsive coders work on Linux projects anyway), he left out a true lightweight OS designed from the ground up for just this sort of multitasking: Amiga OS 4.0. To get something like this to actually work, you'll need more than iPod huggers, OSX preachers or Linux fans. You need genuine madwomen and madmen. You need AmigaOS.
Best of both worlds? (Score:1, Interesting)
Re:next please (Score:3, Interesting)
Re:OK, it's theoritically faster than PCs. So? (Score:2, Interesting)
Actually, the CPU speed has a lot to do with graphics speed. If you look at recent performance charts for nVidia's high end GPUs in SLI setups you will find that their performance levels off unless you run the absolutely highest resoultion with top filtering and antialias settings. In fact, the high end cards are still CPU limited at the highest settings for many but the most recent games. [Tom's Hardware Guide [tomshardware.com]]
In addition, programmers will always find things to do with additional CPU power. Ray traced occlusion culling to reduce the number of polygons sent to the GPU is one idea if you have extreme amounts of processing power just sitting around. That in turn would allow you to use extremely advanced pixel shaders as overdraw is almost eliminated. It would also allow you to add a few more polygons to every scene, knowing that most polygons are correctly culled.
Re:4.6 Ghz ? I don't belive it (Score:2, Interesting)
http://www.siliconvalley.com/mld/siliconvalley/103 23259.htm [siliconvalley.com]
IBM has made the Cell for servers and embedded applications. I don't know much about the author of the article, but the Cell will change computing.
Here's my analysis on why Apple will use the Cell http://www.siliconvalley.com/mld/siliconvalley/103 23259.htm [siliconvalley.com]
Re:OK, it's theoritically faster than PCs. So? (Score:2, Interesting)
So basically you'll have a fixed graphics core which isn't likely to change (since it hasn't for the last couple of years) and an extremely flexible and powerful array of shader units.
Wouldn't IBM design a JIT for Java for this thing? (Score:2, Interesting)
I don't know about you, but when I first heard about cell processors (and that fact that IBM was behind it), I immediately began speculating how IBM would exploit this architecture in their server market. This sounds like the sort of thing that will enable them to sell 256 processor monsters running AIX, DB2 and J2EE.
Even if designing to take advantage of this architecture is terribly difficult, just porting your webserver, database server, and transaction will solve the scalability issues for most Web/Client/Server applications.
Apple/IBM vs. Sony/IBM/Toshiba vs. IBM/Microsoft (Score:1, Interesting)
Sony and IBM (and Toshiba) are putting together some of the most esoteric hardware ever to be contained in a consumer computing device and in all cases IBM sits right in the middle of it. Is this cross-fire waiting to kill the giant, or is IBM counting on its size and contracts to protect it?
What happens when Apple says; "Hey! We want to play with CELL in our next generation hardware." Or Microsoft says; "Whats with giving Sony all the good hardware?"
Whats the potential of all these competetors sourcing silicon from IBM and ending up converging on a common, or nearly common architecture? Is this IBM carefully constructing a future monoply? Is it the beginning of the ability to run software from Microsoft, Sony, and Apple on a single (or nearly single) architecture?
Remember the IBM LongTrail CHRP/PREP development boards? A friend of mine who did some Web work for IBM was paid partialy with a dual processor PowerPC 604 development board that contained both an Apple ROM slot (used the beige G3 ROM) and full OpenFirmware (not the cripled version Apple implemented). Only the lack of well develped drivers for the peripheral hardware prevented it from running as a 100% compatible MacOS/WinNT/AIX (it was given to him with all three installed on the hard drive) machine. This sort of attempted hardware convergence is not a new route for IBM.
What do people out there think is going to happen? Are Sony and Microsoft far enough apart in thier long-term goals to keep working with IBM without stomping all over each other in the process? Where does Apple (or even Nintendo for that matter) fit into this? What rumors or conspiracies have people heard?
Re:Seeing is believing (Score:5, Interesting)
No, this sort of architecture is a general trend towards paralellization. It is smart, and it is known to work, and I would expect some bright Sparc wise people to chime in and say "u-huh" and some SGI wise people to chime in and say "I've seen some of this before." The OS people [dragonflybsd.org] are starting to move things in this direction, and I've heard that Darwin has had the asynchronous messaging type threading model for a while (RTFA: the article explicitly mentions Tiger's GPU leveraging techniques). If you have the head for it, try reading up on NUMA and compare that with SMP.
The math is simple. CPUs are CPUs, and anyone can make one that is the same speed as the competition, and if they do it second they can do it cheaper. The guy that can make 20 CPUs work like one CPU that does 20 times the work in a given time will win because he can always just throw more hardware at the problem. The SMP guys have to go back to the drawing board. In this case, the only way to beat-em is to join-em. Maybe doing the specific "Cell" computing design isn't it, but the ol' PC is dead. If these things start hitting the commodity price-points.
That's a big, fat IF. So, don't bet on it (yet), but it's even worse to ignore it.
x86, Apple etc Vs Cell my arse (Score:3, Interesting)
And this story is no different.
As many have noted, Sony did exactly this kind of hyping the last time around when the PS2, with its emotion engine, was supposed to be the future of all things computing. As everyone knows, the PS2 was a real pain to code for, and the actual performance was not better than the PC's of the day. The Cell will undoubtedly suffer from the same problems when it comes to coding real applications. Concurrency and parrallelism do not an easier coding experience make.
I have no doubt that this thing will be good, but I absolutely doubt that it will have much or any effect on the x86 world of computing. The G4 processor, when it came out with the Altivec SIMD processsor, which was apparently better than SSE at the time didn't turn Apple into the next Microsoft overnight either, did it?
So, I expect that the x86 world will continue to thrive and that Apple will stick some of these Cell processors, having as they do a PPC 970, aka G5, in their core, in some of their machines and will make the usual wild RDF claims about how hot it is while it will be used by only a small fraction of actual Mac developers in reality, the Mac having to maintain backward compatibility only slightly less then the x86 world does.
In other words, it'll be business as usual.
Re:if it sounds too good to be true.. (Score:3, Interesting)
At least it looks that way to me, and it's following their past business model of selling off consumer level production, like they did with hard drive manufacture to Hitachi. Whether that will be a very long term smooth move I have no idea, but in the short term it's actually making them money. Profit margins at low end retail are small, they want no part of that, too clunky for them. Fabbing the chips is a different story, they need to be able to have a place to build what they R & D, so in that sense its logical for them to do that,and get that aspect subsidised by licensing and direct sales (saves them research costs long run) but after that point it's just manufacturing vacuum cleaners or blenders, they don't want to, and that's all PCs are now, just another consumer appliance.
Re:Seeing is believing (Score:3, Interesting)
FTFA
Caches work by storing part of the memory the processor is working on, if you are working on a 1MB piece of data it is likely only a small fraction of this (perhaps a few hundred bytes) will be present in cache, there are kinds of cache design which can store more or even all the data but these are not used as they are too expensive or too slow.
APU local memory - no cache
To solve the complexity associated with cache design and to increase performance the Cell designers took the radical approach of not including any. Instead they used a series of local memories, there are 8 of these, 1 in each APU.
The APUs operate on registers which are read from or written to the local memory. This local memory can access main memory in blocks of 1024 bits but the APUs cannot act directly on main memory.
By not using a caching mechanism the designers have removed the need for a lot of the complexity which goes along with a cache.
This may sound like an inflexible system which will be complex to program and it most likely is but this system will deliver data to the APU registers at a phenomenal rate. If 2 registers can be moved per cycle to or from the local memory it will in it's first incarnation deliver 147 Gigabytes per second. That's for a single APU, the aggregate bandwidth for all local memories will be over a Terabyte per second - no CPU in the consumer market has a cache which will even get close to that figure. The APUs need to be fed with data and by using a local memory based design the Cell designers have provided plenty of it.
Ok, so regular memory is too slow, or too expensive (apparently caching is the main problem although what I remember from comp. arch. was that caching was a Good Thing). So then they abolish the cache.
Caching: CPU > cache (1 or 2) > main memory > HD
and then implement another system that is *completely different*
Non-Caching: APU > local memory > main memory
Now first off, how is it different? Secondly how does this improve the physical memory speed? Is the author claiming that a page fault is what we are avoiding here? If that's the case, then the problem is hard drives not solid state memory. But (again if what I learned in comp arch is correct), because there is a tendency for programs to run the same code over and over again, then (assuming you have a good algorithm) the time saved by caching is signifigant.
Anyone?
Re:Seeing is believing (Score:3, Interesting)
Caching: CPU > cache (1 or 2) > main memory > HD
and then implement another system that is *completely different*
Non-Caching: APU > local memory > main memory
Now first off, how is it different?
Let me take a vaguely educated guess.
Currently the cache managers in x86 CPUs "predict" what part of the memory space is needed. This prediction isn't always that good, and efforts to make programs hint to processor what to cache haven't worked good enough (or at least according to Cell CPU designers). So they force to program to operate in a 'small' memory space where data can be read in from a large RAM storage.
I don't know if it will actually help. To me it seems a bit like going back tot he 80268/80386 era with himem.drv under DOS so programs could acces higher memory regions by commanding the driver to swap in and out memory to the lower 640k.
But then, maybe Bill Gates -or whoever put up that quote in his name- was right, 640k RAM is enough for everyone (multiplied by the number of cores on dye..).
Think another way (Score:2, Interesting)
What these guys are trying to do is move the processor to the memory rather than the inverse. Having fast expensive caches near the processor is an attempt to get the memory closer to the proc. What has been happening of late is that lots and lots of on-chip transistors have been spent on the cache. The Cell architecture is a step in the other direction. They want to spend those transistors on processors instead of memory.
At the limit of this idea you would see something like a super-granulated architecture with a processor on each memory chip. Imagine a PC with 32/64/whatever cell processors *and* no classic "processor socket" on the motherboard, just some DIMM-like "cell" slots. Each proc would have exclusive access to the memory on its own chip and all would communicate via some sort of bus or fabric of links. So, instead of one mega proc with tens of millions of transistors(perhaps half would be cache) at 4GHz with a 400MHz x 32, 64, 128, whatever bit width memory bus you'd have maybe 64, 128, 256? simple ARM-like procs at 400MHz each with something like 400MBs or more available memory bandwidth per proc.
Of course the extreme limit would be to have millions of 1 bit processors, but I don't think that anyone is proposing that just yet. Things do get more and more neuron-like as you approach this limit, interesting eh?
Re:Seeing is believing (Score:3, Interesting)
1) It must be programmed differently. Instead of just accessing memory how you want, you must explicitly copy the part of memory you need at the moment. So, if your APU is acting as a vertex shader, you need to copy the shader code into the LS before you start processing. Essentially, the LS can give you the time savings of a cache, but you have to manage it yourself to get the benefits.
2) Since the LS isn't managed by the hardware, it doesn't need a lot of management hardware. You don't need cache tags, lookup hardware, hardware to manage misses, etc. This saves a lot of transistors.
3) A regular cache has to do some management on each access. It has to search the tags to find what cache line holds a given memory word, it has to perform write-back, etc. Since the LS doesn't need to do any of this, latency can be cut down.
4) Since the LS is addressed directly, and isn't mapped onto memory, there is no need for cache coherency protocols. A cache-coherent multi-processor system needs to communicate with it's peers to coordinate access to the cache. For example, when it writes to a memory location, it must notify all other processors caching that location that their copies are now invalid. The LS doesn't need to do any of this, and that cuts down on both management hardware and latency.
The APUs are stream processors. It is common for stream processors to not have a general memory cache. The geforce 3's vertex processor, for example, has enough cache to hold 18 vertices. The are not an LRU cache like a Pentium's, but a FIFO (much cheaper to manage), and are only used in certain circumstances. In comparison, the Cell's 128KB LS per PE is enormous!
Re:You're falling for the hype- hook, line, sinker (Score:1, Interesting)
It's worth noting that a whole lot of Japanese games use only shaded polygons. Even now, most console games use less textures than a PC game, and use algorithmic tricks instead. It took developers years to get their heads around the PS2's bizarre VPU design, but it turned out to be damn powerful in the end (it manages to stay reasonably competitive with the X-Box even though it's a full generation older and has half the RAM).
Hopefully the API will have a better translation job done this time. CLITIndex anyone?