The Engineers Who Created Cell
- Thread starter one
- Start date
version said:
The amount of cache and average miss latency need not grow proportionally with the number of cores since not all cores will be missing their caches at the same time. The worst case latency of course increases proportionally but worst case will be statistically rare. With games, you don't need to plan for worst case--if the game frames out once every 30 seconds, so what?
The advantage with cache vs dumb local store is that it makes your game design much more robust against changes in assumptions about data size and access patterns. With a dumb local store, you have to explicitly overlay data into the local store, and planning for that can be difficult and will make it very hard for you to know whether you're making optimal use of system bandwidth. If your assumptions change, as they are bound to, you'll have to redesign. With a cache, you can more easily iteratively design, profile, optimize, and rework where necessary. This sounds like sloppy engineering, but, in practice, works much better than a front-heavy workflow.
Unfortunately on many existing architectures that is "only" true so long as you don't give a flying f$$$ about performance.
Current generation of consoles is a great example of how cache architectures can still be incredibly sensitive to data sizes and access patterns, and designing your application without paying close attention to those issues will literally grind the system to a halt.
Problem is compounded by the fact that optimizing for cache-coherency has no "exact" solution, you're often reduced to things like packing your data structures tighter and just "hoping" it will amount to better performance (it usually does, but the actual effects are unpredictable at best - thanks to the way cache behaves).
And fact of the matter is that the PPC cores in new consoles are not making this problem go away - it may even grow worse in some ways.
I get a very diffrent story from reading the first page of this thread. eg.xbdestroya said:
The three cam e together. IBM proposed one solution. Toshiba another. One Sony guy went with IBM's idea, one didn't. Disagreements were overcome through compromise.
I think the main reason Cell is termed 'IBM's Cell chip' is because the bulk of work and design and implementation was done by IBM engineers, but I also don't know if I've heard that term. It's known to me inarticles as STI's Cell.
It looks like XeCPU is more akin to what IBM wanted for Cell so it'll look like next-gen consoles offer a chance for both approaches to be evaluated.
3roxor said:
Obviously, it's not like they're going to downplay Cell. It's also their creation.
What will happen will be a showdown of to different approaches, both of which IBM helped creating. From IBM side, they're both good.
It's down to Sony/Toshiba and MS now to downplay their competitors and bore us to death with "proof" that each approach is the best, which is something that started already and will probably carry on for a long time.
If you read the first post in this thread, when the groups first sat around the table IBM, suggested multiple cores, no SPUs, and Toshiba suggested all SPUs, no main cores. As such, XeCPU being all PPC cores seems similar to IBM's take on Cell when first considered. This doesn't mean they want to push XeCPU as an alternative to Cell, as they have a vested interest in the whole technology as part of a group effort even if they still think their original design would outperform the current Cell design. IBM may even have changed their minds and believe the current Cell structure is better at what it's supposed to do then their original idea.
Would it be wrong to say that with the new XCPU IBM gets paid for 3 cores instead of Cell's 1. I think it's not surprising that they'd go for the 3 cores solution, instead of 1 core+SPEs one if that's the case.
Fafalada said:
Programming is the art of managing memory.
At least in high-performance systems, but it has been increasingly true for general purpose CPUs for a long time as well, if you do anything where performance is critical. And it should be bleeding obvious why, when you compare the core throughput capabilities with the memory subsystems that are supposed to feed them. Cache simply reduces the penalty for programmers who chooses to ignore the last two/three decades or so of hardware development, and stick to programming as it is still taught in schools, which is strongly tied to minimizing cost of support which is the critical parameter for clerical applications.
Software that needs to extract a high percentage of the capabilities of the hardware is a different kettle of fish entirely. It always has been. And yes, that means that you have to have a good awareness of the underlying hardware, and yes it means that your code will have (manageable) portability issues. So what? That's the price you've always had to pay for performance, but the performance benefits from prioritizing that way is very large indeed. For scientific codes, that get ported to tons of different hardware over the course of decades, this is obviously a bit of headache but is also par for the course. For games on consoles, explicitly taking the underlying memory hardware architecture into account will bring huge performance benefits as well, and without most of the porting complications that apply to scientific codes.
It really is difficult to feel much sympathy for programmers that choose to whine about having to change their coding habits to fit the underlying reality of their tool, and without appreciating what their tool offers and can be made to yield. I really can't help feeling that they should stay in some other field of their craft, or change career entirely. The spectres of COBOL and PL1 programmers hover just behind the shoulders of todays PC c++ coders.
I don't know im IBM were looking for a new processor line to market. It could potentially be that IBM's design is better than the final Cell design maybe, but in such a case they would still toot Cell as it's going to feature in other equipment guarenteed, whereas a multicore CPU would have no more customers guarenteed with IBM erking Sony and Toshiba by pushing a rival.
Though IMO I think the parties settled on the best possible solution, bringing different philosophies and finding the happy midground.
London-boy : I would have thought IBM get paid for chips, not cores.
Though IMO I think the parties settled on the best possible solution, bringing different philosophies and finding the happy midground.
London-boy : I would have thought IBM get paid for chips, not cores.
Shifty Geezer said:
Obviously, but would they get paid more for a 3 PPC core chip or a 1 core one? Are the SPEs an IBM creation or a Sony/Toshiba one?
In the end, it doesn't matter, i can't wait to see how the 2 different approaches will handle the end result - the games.
I think the Cell technology is shared amongst STI, and purchasers of the chips will give an equal fee to IBM, Sony and Toshiba. It'd be crazy to pay one company more or less based on contribution - how could you measure such a thing? SPE use PPC ISA, so are they PPCs...?
The original Toshiba/SONY embodiment was a VLIW APU. IBM suggested that it be changed to a SIMD SPE which it did.
Correction Toshiba's orginal plan was the Force System which was comprised of many small/simple VLIW RISC cores with a main control core based on MIPS. IBM wanted multiple complex PPC cores with no control core. Engineers from SCE was in favor of the IBM proposal including a former NEC supercomputer engineer. KK however rejected the IBM proposal because it required too many pins which would be too expensive for their targeted budget. Former NEC engineer now working at SCE talked to IBM and IBM agreed with a PPC control core with many smaller simpler cores attached to it. The actual APU architecture was IBMs idea but Toshiba wanted these small cores to be VLIW. IBM convinced Toshiba to use SIMD instead of VLIW for the smaller cores.
So in summary STI created the APU/SPEs.
Well, we've all read the same excerpts posted by one, probably several times each, so we should all be on the same page, but we're just not and that's ok. 
I see what you're saying Shifty, but when I say Cell seems more Sony and Toshiba's brainchild, I say so because it's an architecture along the lines of what they expected to create when they went into it - whereas IBM was something of a holdout; granted IBM had an equal vote and got some of their ideas were adopted.
Also I have to question the logic that IBM did the majority of the engineering - these excerpts made it fairly apparent that Toshiba and Sony were highly involved throughout the entire process, with their own sizable contingent of engineers on premises in Austin and with Kutaragi with enough oversight to be able to scrap the entire design at one point.
As for what London Boy is saying when he refers to revenue from the cores, I don't think he is refering to manufacturing fees/revenues, but rather to possible licensing fees/revenues from the Power cores (Power being IBM IP afterall). In which case three is better than one, depending on the cost/licensing structure.
And my comment on 'IBM's Cell' was certainly not some thing I was just making up - truly in the American press, if nowhere else, that is how it is depicted. Since I'm in the US, it's what I deal with for the most part. Do a Google search for 'IBM's Cell' and you will find countless exemplars of this.
I see what you're saying Shifty, but when I say Cell seems more Sony and Toshiba's brainchild, I say so because it's an architecture along the lines of what they expected to create when they went into it - whereas IBM was something of a holdout; granted IBM had an equal vote and got some of their ideas were adopted.
Also I have to question the logic that IBM did the majority of the engineering - these excerpts made it fairly apparent that Toshiba and Sony were highly involved throughout the entire process, with their own sizable contingent of engineers on premises in Austin and with Kutaragi with enough oversight to be able to scrap the entire design at one point.
As for what London Boy is saying when he refers to revenue from the cores, I don't think he is refering to manufacturing fees/revenues, but rather to possible licensing fees/revenues from the Power cores (Power being IBM IP afterall). In which case three is better than one, depending on the cost/licensing structure.
And my comment on 'IBM's Cell' was certainly not some thing I was just making up - truly in the American press, if nowhere else, that is how it is depicted. Since I'm in the US, it's what I deal with for the most part.
Do a Google search for 'IBM's Cell' and you will find countless exemplars of this.