3 ms·

I know people who have worked with the Intel 48-Core SCC (Single-Chip Cloud Computer). While I don't remember technical details it was very hard for them to bui

by derda 14y ago

I know people who have worked with the Intel 48-Core SCC (Single-Chip Cloud Computer). While I don't remember technical details it was very hard for them to build software that actually benefits from that many cores. If I remember correctly sharing data between the cores was a big bottleneck.

merijnv 14y ago
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.
wmf 14y ago
SCC was an experiment to see if people could program an intentionally "broken" multicore and not surprisingly they can't. There are plenty of apps that can use lots of cache-coherent cores, e.g. Postgres: http://rhaas.blogspot.com/2012/04/did-i-say-32-cores-how-about-64.html http://rhaas.blogspot.com/2012/04/did-i-say-32-cores-how-abo...

by derda 14y ago

merijnv 14y ago

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.

wmf 14y ago

SCC was an experiment to see if people could program an intentionally "broken" multicore and not surprisingly they can't. There are plenty of apps that can use lots of cache-coherent cores, e.g. Postgres: http://rhaas.blogspot.com/2012/04/did-i-say-32-cores-how-about-64.html http://rhaas.blogspot.com/2012/04/did-i-say-32-cores-how-abo...