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.
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.
Oh I never got that far. It was all static. I supposed if I had kept plugging away it, I might’ve reinvented a 64-bit OpenCL eventually, but you have to understand the uphill climb it all was. Like I was shocked to discover at one point that while you could compile a 64-bit executable, the
malloclibrary function was still only 32-bit! I bitched about this to IBM tech support, and they said well you could write your ownmallocusingmmap. I mean yikes!