By using this site, you agree to our Privacy Policy and our Terms of Use. Close
Wlakiz on 16 November 2012
Edit Thread
zarx said:
Wlakiz said:

... do you even know what you're talking about?

1. Cell uses RISC architecture, which was developed back in 1960, waaaay before your 'x86' instruction set. RISC is more efficient which is why its used for mobile devices and super computer. Flaws? You mean the inconvenience of having to write efficient code and have knowledge of memory management? Yeah, I know.. all the new grads come out knowing only Java, and have absolutely no idea what are pointers, stack or heap but news flash: Its not a flaw to design system that trade convenience for efficiency; hence all firmwares and hardware level code are written in C and not in Java or Python.

2. So what you're saying is that because someone built something for the next gen Civic, you should dump your Porsche for a Civic? Yes, I am comparing 'x86' to a civic because its 'common' and 'easy to use' whereas Cell is more like a Porsche, faster, more expensive and harder to use.

3. And why can't they 'piggy back off' that with new generation cell chips? The fact, they are already manufacturing Cell chips at 45nm and made commitment to reduce it to 32 nm back in 06. According to http://en.wikipedia.org/wiki/Cell_microprocessor_implementations:

"IBM could elect to partially redesign the chip to take advantage of additional silicon area in future revisions to make the size small. The Cell architecture already makes explicit provisions for the size of the local store to vary across implementations. A chip-level interface is available to the programmer to determine local store capacity, which is always an exact binary power. It would be feasible to double the local store to 512 KiB per SPU leaving the total die area devoted to the SPU processors roughly unchanged. In this scenario, the SPU area devoted to the local store would increase to 60% while other areas shrink by half. Going this route would reduce heat, and increase performance on memory intensive workloads, but without yielding IBM much if any reduction in cost of manufacture."

4. Where did this $500m come from? I didn't see it in their Q4 report that they spent that much on R&D on the new AMD chip. Again, they designed the Cell to be scalable in the first place. Jumping ship to R&D a conventional CPU, just waste the money and time used on Cell. They should maximize and push their technology to the limit before following the bandwagon of the new popular kid in town.

Do I know what I'm talking about? Probably about as much as you.


1. The problem with CELL is not RISC architecture it's SPEs with no hardware schedulers, in order execution etc. Dev time costs money writing code for the CELL takes longer than a traditional CPU, you can hand optomise every peice of code on an x86 CPU if you wanted too that is not an advantage of the CELL and the fact that you have too to get even decent performance is a flaw. Unless you have an unlimited budget easier is better than slightly faster execution, that is why game engines are written in high level languages like C++ instead of assembly even tho performance is worse. And most games have most of their high level logic written in a scripting language like Lua.

2. Your arguement was that engines are designed for CELL already, I pointed out that next gen engines are all designed on x86.

3. Because there is no next generation of CELL chips IBM stopped development... Next gen will likely start at 28nm not 32nm so that doesn't really help. PS3 is the only device still using the CELL.

4. AMD spend ~$1.5b on R&D every year, and they only release a new architecture every 4-5 years, even incremental upgrades like Piledriver cost a lot, that isn't counting the R&D that the Fab does for each new node. Tho I pulled $500m out of my ass. And all modern architectures are designed to be scalable but it still costs money to spin a new CPU even using the same architecture. Spinning a new CELL bassed CPU on a new manufacturing proccess would not be cheap to do. 

The CELL was a dead end, GPGPU replaced the need for the kind of high parallelism with lots of floating point performance on a CPU. And for everything else a x86 CPU runs circles around it. 


1. Again, you are mistaking flaw for performance/Convience trade off. IBM didn't 'forget' to add in branch prediction or OOE, they designed the SPE to have a sepcific purpose which is to do FP calculation fast. Their design choice made it possible for SPEs to complement the GPU's performance which allowed developers to push the graphics beyond the GPU's specs. Thanks to Cell's 8 years of production, most if not all developers have dedicated compilers and game engines designed to make optimization for them.  If a developer 5 years down the road have to start 'hand optimizing' their code to get their desired performance, then you just effectively created a cpu with useless/bloated features.

2. Your point is going off on a tangent. Most developers like to use their own engine to avoid paying licence fee and they have free control on what the engine does. That is why, even tho Unreal 3 Engine was avialible, only a select games used it. Developers already have engines built from last 8 years of PS3 development, continue using Cell will mean a much lower cost for the 'next gen'. 

3. Wrong, first, IBM already developed a scaled up version of Cell called PowerXCell 8i back in 08 that does 102 GFlops, Highest end of Core i7 Extreme edition is only at 90 Gflop and it consumes twice as much power. Second, the next gen is 22nm and how many chips are in 22nm? Unless they started devloping in parallel with Ivy bridge and Power8 chips, most likely start at 32nm for the next gen and go down to 22nm as they age.

4. Did you pull that $1.5b from your ass too? It takes 8-10years to create a new architecture from scratch, but its cheap to create scaled ones.. just look at corei7, it came out first then they scaled it down to make it affordable and that didn't take long.

 As someone who did CUDA programming, I can tell you that you know nothing about GPGPU. Cell IS a hybrid of GPU and a conventional CPU. In fact, the way you copy memory from the GPU cache for your 'task' is almost the exact way you would do it in Cell.