5 ms·

On the contrary, I wonder if we're likely to see a resurgence in RISC, as it comes into its own with extremely large numbers of cores. I don't think this Oracle

On the contrary, I wonder if we're likely to see a resurgence in RISC, as it comes into its own with extremely large numbers of cores. I don't think this Oracle chip is necessarily an indicator of that, but there are other signs indicating it could happen. What you are saying is very true. Or at least it was true, 20 years ago when RISC was supposed to be the next big thing and then it wasn't. But that landscape is finally starting to change. What's different now is that after dominating the server and desktop market through brute force, Intel hit a saturation point about 10 years ago and since then, clock speeds haven't increased much, nor have instructions per cycle, both of which were increasing so fast year-on-year through the 90s and early 2000s that nobody could keep up. Now even Intel have been forced to start scaling out horizontally by adding more cores: that's now virtually all that differentiates their fastest CPUs from their slowest. Because of this, developers are increasingly having to think more about writing concurrent code. Languages like Go, F#, Scala and Clojure are seeing a huge upsurge in popularity lately; it's not happenstance. Functional programming has been largely confined to AI and CS research since the 60s, but it's suddenly becoming popular with pragmatists for scalability. The thing is, once your code is no longer bound by single-threaded performance, it starts making sense to just add more cores if you can, especially if you can do so without a significant transistor cost. With x86, adding cores is expensive because each one is exceptionally complex, but RISC can be simpler, use fewer transistors and operate at lower wattage. Huge numbers of cores can also be exceptionally power efficient if each core can run in a low power mode until needed.

seunosewa 12y ago
The idea that once code is rewritten to take advantage ofother cores then more wimpy cores would be better than a few powerful cores is wrong. Most threaded code today can scale to a small number of cores (2, 4, 6) but can't scale to a ridiculously high number of cores (e.g. 32) due to various bottlenecks that are hard to remove. Also the simplicity of RISC cores vs X86 does not significantly affect chip cost since these days the vast majority of the space on a chip is taken up by on-chip caches (L1, L2, L3). The space taken up by instruction decoding circuits is really, really negligible next to that.
matthewmacleod 12y ago
Intel hit a saturation point about 10 years ago and since then, clock speeds haven't increased much, nor have instructions per cycle I don't think is quite true - have you looked at the results? The difference in single-thread performance between a P4 and a Core i7 at the same clock rate is mind-blowing. We're talking like 500% over 10 years. Yeah, single-thread performance improvement has slowed down, but it's still there.
userbinator 12y ago
With x86, adding cores is expensive because each one is exceptionally complex Not all that expensive... look at the Xeon Phi for example; it's not a main CPU, but it does contain 61 (no idea why it' not 64...) Pentium-level x86 cores with 16GB of RAM: http://www.amazon.com/Intel-Xeon-Phi-7120P-Coprocessor/dp/B00FKG9R2Q http://www.amazon.com/Intel-Xeon-Phi-7120P-Coprocessor/dp/B0... but RISC can be simpler, use fewer transistors and operate at lower wattage Fewer transistors in the core is offset by the need for more cache due to lower instruction density, and especially in a system with many cores, cache misses can be far more costly due to all the cores needing to be fed with code and data. Also, that Xeon Phi mentioned above has only 5B transistors with 61 cores whereas the 32-core Oracle chip has more than double that. Huge numbers of cores can also be exceptionally power efficient if each core can run in a low power mode until needed This is true, but the caches also consume a significant amount of power too - Intel's mobile CPUs have had dynamic cache sizing for several years now, where parts of the cache can be turned off to save power.

seunosewa 12y ago

The idea that once code is rewritten to take advantage ofother cores then more wimpy cores would be better than a few powerful cores is wrong. Most threaded code today can scale to a small number of cores (2, 4, 6) but can't scale to a ridiculously high number of cores (e.g. 32) due to various bottlenecks that are hard to remove. Also the simplicity of RISC cores vs X86 does not significantly affect chip cost since these days the vast majority of the space on a chip is taken up by on-chip caches (L1, L2, L3). The space taken up by instruction decoding circuits is really, really negligible next to that.

matthewmacleod 12y ago

Intel hit a saturation point about 10 years ago and since then, clock speeds haven't increased much, nor have instructions per cycle I don't think is quite true - have you looked at the results? The difference in single-thread performance between a P4 and a Core i7 at the same clock rate is mind-blowing. We're talking like 500% over 10 years. Yeah, single-thread performance improvement has slowed down, but it's still there.

userbinator 12y ago

With x86, adding cores is expensive because each one is exceptionally complex Not all that expensive... look at the Xeon Phi for example; it's not a main CPU, but it does contain 61 (no idea why it' not 64...) Pentium-level x86 cores with 16GB of RAM: http://www.amazon.com/Intel-Xeon-Phi-7120P-Coprocessor/dp/B00FKG9R2Q http://www.amazon.com/Intel-Xeon-Phi-7120P-Coprocessor/dp/B0... but RISC can be simpler, use fewer transistors and operate at lower wattage Fewer transistors in the core is offset by the need for more cache due to lower instruction density, and especially in a system with many cores, cache misses can be far more costly due to all the cores needing to be fed with code and data. Also, that Xeon Phi mentioned above has only 5B transistors with 61 cores whereas the 32-core Oracle chip has more than double that. Huge numbers of cores can also be exceptionally power efficient if each core can run in a low power mode until needed This is true, but the caches also consume a significant amount of power too - Intel's mobile CPUs have had dynamic cache sizing for several years now, where parts of the cache can be turned off to save power.