cross-posted from: https://lemmy.world/post/49514337
Their compatibility list notes 75.33% are Playable, 22.93% can go in-game but not be finished and only 1.69% can’t get past the intro.
cross-posted from: https://lemmy.world/post/49514337
Their compatibility list notes 75.33% are Playable, 22.93% can go in-game but not be finished and only 1.69% can’t get past the intro.
I guess you could say the Cell was as an 8-core CPU (well, 9, if you include the PowerPC in the middle) at a time when such things were unheard of, at least in the consumer space. So the theoretical performance if you could max out all those cores was through the roof. I have no doubt that’s what drew Sony to them for their next gen console.
But whereas all the cores of a modern 8-core chip can access the same RAM, in the Cell, only the PowerPC could access the main memory and each core had its own dedicated internal RAM, meaning you had to load both code and data into all the cores laboriously yourself using asynchronous DMA requests before executing the code, and then sync the results back using more DMA. It was a bit like GPU programming, I suppose, though within the cores, it felt more like a CPU in terms of the instruction set and what not, so kind of a hybrid approach I guess?
That sounds like something that might have made it easier to emulate, since on x64 the memory management could be simplified. Though that kind of cache control can lead to very high performance if the working set of data fits into that cache that x64 might have trouble keeping up with.
Yeah, you know, that’s a good way of looking at it. It’s like each core could only access its own cache memory, and all the syncing to main RAM had to be done painstakingly in software. That would be a hardware function in any modern architecture. I can’t remember how big the caches were. I think they were bigger than a typical L1 at least, but not huge.
Anyway, it was not too horrible if you were just walking through an array sequentially applying some operation to it, but when you had to jump around memory, it became an absolute nightmare! Uuuugh…it’s all coming back to me now why we got nowhere with it.
That central core must have gotten really busy managing the memory if several cores were each jumping around a lot. Did it have to do other things also or was it just fulfilling memory requests?
Oh yeah! I mean to be fair, it was a full-fledged PowerPC single core in its own right. I’m pretty sure that generation had AltiVec (simd instructions), so you could theoretically do some number-crunching on it as well, but it had plenty to do already with managing memory I/O. And actually also network I/O for us, since I worked a bit on trying to combine the resources of more than one blade. But man, it just devolved into a giant mess in the end! I think I still have some PTSD from it :P
Were you generating dynamic instructions based on what the cores were doing or was it all statically programmed such that the PowerPC core had to be running very specific code that went along with the specific code running on each worker core?
That first one might have been very scalable, though I have a feeling either one would be a nightmare to actually write and hell to debug.
Fascinating insight.
Don’t remember where I’ve read this but supposedly SONY wanted it to be part of their geometry engine, but ultimately had to cut down the costs and use Nvidia GPU instead. So maybe that analogy isn’t that far off