the Cell processor in the PS3 was not terrible in the PS3 and I doubt you ever worked on it. So talk about 'not the best-researched'. You can find many people singing it's praises, including me.
Haha! I've spent months tuning code to run on the Cell, and I despise that thing.
Sony gave you 6 of the 8 SPE cores to use (I think they reserved two, but it's been ages). They are indeed very fast, however, they have no cache coherent access to main RAM and only 256k of memory for each element. So, you have to meticulously write DMA scheduling code to keep them fed. If you're a simpleton like me, you double buffer your SPE memory, cutting in in half, so 128k to work with, 128k for paging into, and you hope to be done paging before it's needed. Latency to memory is on the order of 2,000 cycles to first byte, but then they arrive fast.
So, what you do is decompose your problem into data streams that can be cruched through, but in such a way that you minimize the need to randomly access much memory. It's often cheaper to recompute things locally than to fetch them from RAM. Random access into your RAM is pointless, so you have to marshal all your input into DMA buffers, do some work, marshal all your output into other DMA buffers, and send back to host CPU.
Anyhow, I got this working. Meshes were being skinned at very high rate, but it was very frustrating. The PPE was really slow, so you had to offload as much as you could to those SPE's. But hey, I may be complaining, but it sure beats dealing with the "Emotion Engine" on the PS2. I can tell you which emotion that engine brings up.
In the early years, the SPUs were not all functional due to the fabbing process. The ones that had all 8 functional ended up in servers, and the ones with about 6 ended up in PS3s. This still happens all the time with clock speeds, and core counts on modern processors today. I’m sure the fabrication process improved over time, but they disabled the 2 cores to maintain backwards compatibility.
Unrelated: Every time I’m reminded about Cell I’m reminded of the OtherOS fiasco. I purchased a PS3 for the processor solely and I was very upset when I only got a $2 check for it. I never cashed it.
I still have a launch-edition PS3 on firmware 1.01 that I got on launch day (wife and I were fortunate enough to be able to buy two and stash one). I've lost all kinds of stuff in moves and etc. since, but that thing will have to be pried from my cold dead hands.
Sounds like you learned a lot and are a better programmer from it. Pretty much everything hasn't changed and you can either hope Moore's law bails you out somehow or you can take what you have learned and apply that to the reality of whatever hardware you happen to be optimizing, CPU or GPU. Sorry it's painful but to eke out max performance it's going to be hard at times.
For every person singing it's praises, there are dozens of game developers who were singing with gladness when it was gone. The PS3 devs I've spoken with (you aside) universally hated the platform and spoke of how much more dev time it took to launch games on the platform to achieve mediocre results.
If the chip were so wonderful to work on, then it would still be in use today as the theoretical performance per area beats everything else by a wide margin.
Roadrunner was built in 2008. It would still be just barely off the top 500 list in 2021, but was decommissioned just FIVE years later in 2013. Its x86 replacement was already underway in 2010 TWO years after its launch.
I'm glad you got to work with the architecture you loved for so many years, but I think the rest of the world disagrees with your assessment.
It probably was spectacular once you knew how to work with it. Like the Atari Jaguar though, getting the performance needed out of such a highly parallel architecture took a lot of time and investment. With cross-platform games really taking off during that time, it was a strategic mistake IMO.
That's an enthralling tale, but perhaps you could share why you feel it deserved praise-singing to begin with, and also what titles you worked on, considering many developers were complaining about it when it was current console architecture, and you don't even need to do much of a Google Search to find people bitching about it.
Seriously? You can find people bitching about anything on Google Search. The fact is most people just weren't prepared for multi-core data oriented programming in 2006.
> You can find many people singing it's praises, including me.
Until today, I’ve never once seen someone “singing it’s praises” that’s actually written code for one. At best, they’d curse it under their breath while saying it had its benefits. Usually however it was a full throated rant about how bad the experience was.
It was surprisingly useful for some high performance computing niches. It was in a weird time. FPGAs were available but weren’t as performant as they are today. GPUs were around but not nearly as powerful or flexible given some workloads.
Every single one of them came out a better coder. They might have been dragged kicking and screaming to the multi-core but they would've had to get there in the end.
IDK - I guess most experienced low level coders hate computers, it doesn't matter what the CPU. People are lazy. I understand that it was hard but it doesn't make it a WORST CPU EVER MADE
Sony gave you 6 of the 8 SPE cores to use (I think they reserved two, but it's been ages). They are indeed very fast, however, they have no cache coherent access to main RAM and only 256k of memory for each element. So, you have to meticulously write DMA scheduling code to keep them fed. If you're a simpleton like me, you double buffer your SPE memory, cutting in in half, so 128k to work with, 128k for paging into, and you hope to be done paging before it's needed. Latency to memory is on the order of 2,000 cycles to first byte, but then they arrive fast.
So, what you do is decompose your problem into data streams that can be cruched through, but in such a way that you minimize the need to randomly access much memory. It's often cheaper to recompute things locally than to fetch them from RAM. Random access into your RAM is pointless, so you have to marshal all your input into DMA buffers, do some work, marshal all your output into other DMA buffers, and send back to host CPU.
Anyhow, I got this working. Meshes were being skinned at very high rate, but it was very frustrating. The PPE was really slow, so you had to offload as much as you could to those SPE's. But hey, I may be complaining, but it sure beats dealing with the "Emotion Engine" on the PS2. I can tell you which emotion that engine brings up.