Hacker News Reader

Comment by userbinator | Hacker News Reader

I like how they're adding hardware specifically to speed up databases, to a CPU based on a RISC core; it looks like there is a trend toward more CISC-like hardware, because designers have figured that operations that would've been done in software can be done faster with dedicated hardware.

My experience with using older SPARC servers for testing various things is that they're rather disappointing, both in terms of value and performance - "more cores" seems to be their guiding principle, and while this makes for impressive benchmark results and aggregate numbers, the speed of a single thread is pretty horrible; it's only in specific multithreaded applications that all the resources on the chip can be fully saturated. Meanwhile x86 servers cost far less and can handle different workloads better because per-clock, each core is several times faster.

View on HN

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.

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.

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.

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/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.

> My experience with using older SPARC servers for testing > various things is that they're rather disappointing, > both in terms of value and performance..

I vaguely recall a sparc running solaris that could hot-plug cpu and memory boards (as long as you kept at least one in). I could imagine some customers at the time found that useful.

"Lots" of enterprise systems can do stuff like that. E.g. IBM has systems that can do it as well.

Only by shutting down the partition and its os instance, last I heard. Not really much better than having separate physical boxes.

No, you can offline any CPU/memory board using svcadm and do that. No need to shut down the instance.

trend toward more CISC-like hardware, because designers have figured that operations that would've been done in software can be done faster with dedicated hardware.

And since clock speeds stagnated a decade and a half ago, but Moore's Law still allows more transistors to be packed onto a chip, adding dedicated hardware for specialized operations is about all designers can do.

It's not like we reached any sort of limitation on individual transistor switching speed, though. The problem is that you can't evolve a product line by removing features. You've always got some feature or instruction that is the limiting factor for clock speed; some longest chain of gates that need to settle on the output value before the next cycle. You might be able to shorten that chain by breaking up an operation into several instructions or by reducing the number of registers or addressing modes, but that breaks compatibility. On the other hand, anything that can be added without lengthening the critical path and can be powered down when not in use is fair game.

Individual transistors are getting faster, but wires are not. Wire performance has not been keeping up with the transistors since something like 90nm (2004), hence the "telescopic metal stack"

Clock speeds are in part chosen based on optimal path length (measured in gate count). The longer the path, the less is wasted on flop overhead. The shorter the path, the faster your clock and the more flop overhead. Features or instructions are not important to this equation, because you can break a feature into multiple stages divided by flops. So the fact that frequency has stayed about the same should tell you that path length (gates per cycle) has stayed about the same, which in turn means gates have probably stayed about the same speed for many years!

Next, let's not forget about the power/heat envelope. Modern transistors are mind-numbingly fast if you juice them with 5V, but 1kW CPUs are generally frowned upon these days. We continually squeak down the supply voltage to save power and meet the heat envelope.

Now, you might be thinking about all the extra transistors that are added to newer designs. "Forget about path length," you might say. "If we cut crap features and got rid of those extra transistors, we could afford the power cost of turning up the supply voltage, and get faster!" Alright, now you're thinking smart! But 90% of modern CPU area is spent on graphics and cache, not x87, MMX, and AVX512.

I could go on, but I cannot properly cover all the aspects in one comment...

Given Oracle's history in marketing vs technical competence, that's probably why they're adding it: people like how it sounds. And we'll probably never see any credible evaluation since they NDA all their customers.

From a real computer architecture standpoint the idea sounds pretty far fetched. (People in academia have been looking at FPGA and GPU acceleration in this domain for years. It's really a problem for which a CPU is a pretty good fit, with lots of branchy control flow etc.)

The SQL hardware sounds like a marketing trick.

Reply on news.ycombinator.com