I disagree, benefitting from 48 cores on the SCC would be easy, if the other (solvable) problems plaguing the SCC wouldn't get in the way. The bigger issues pla

I disagree, benefitting from 48 cores on the SCC would be easy, if the other (solvable) problems plaguing the SCC wouldn't get in the way. The bigger issues plaguing the SCC were: The use of old P54C core, while understandable from hardware point (design already existed, no need to validate/test) this decision has big consequences. The core can only support a single outstanding memory operation, crippling memory performance. Doubly so because it does not support out-of-order execution, meaning the core is stalled until memory requests finish. Furthermore, the lack of L2 cache consistency lets you experiment nicely with NUMA and the combination of reprogrammable lookup tables and more physical memory than address space (34 bit vs 32 bit) lets you do nice tricks to share/communicate data between cores with zero copying needed. Unfortunately (due to time/budget constraints) Intel didn't implement any programmable expiration/invalidation/flushing of the L2 cache. This means that any application wanting to use these tricks had no solution beyond reading in a full 256KB (with the proper striding to make sure you actually cache miss on all of those 256KB!) to flush the cache. Such a flush takes approximately 500k CPU cycles, almost guaranteed killing any performance gained from zero copy tricks. The fact that cores were 32bit is also extremely, as you quickly consume your entire address space when you start playing around with the above mentioned sort of memory shenanigans. There were some more fairly minor issues, but these are the ones that initially pop in my head.