Comment by userbinator | Hacker News Reader

Comment by userbinator | Hacker News Reader

Parent Full thread

As someone who has watched the "RISC revolution" and the claims its proponents have been making since the 80s, I'm not so optimistic on what will happen. Initially it was all about increasing clock frequency to make up for increased instruction counts and decreased code density, but Intel's Netburst showed that this strategy was a dead end. Then the focus was on power efficiency, which is still a close battle today. I don't think it's a matter of budget; AMD has much less to spend than Intel, yet it makes x86 CPUs that are still quite competitive even if they're not as fast - the gap between them is nowhere near their differences in budget. It seems that things are more like "fast, cheap, power-efficient: pick two".

This related paper is an interesting read: http://research.cs.wisc.edu/vertical/papers/2013/isa-power-s...

I think x86 still has plenty of room for optimisation, and Intel are just doing it slowly according to market conditions. An open-source x86 core would be great - in fact, pre-MMX-level x86 is fully open, as all the patents on that have expired now.

I also lived through it, but I would say that RISC won in the end, just not exactly as its proponents thought.

x86 are no longer real CISC, as they moved the internal architecture to RISC, starting with the Pentium 4.

And all the other processors that matter are also RISC.

The real loosers were the VLIW proponents.

Sounds suspicious to claim victory while redefining terms. :)

I'm curious which processors that matter are all RISC. I mean, I realize there are a fair bit of chips out there. I wouldn't have thought many of them really fit the original RISC mold. Sure, they have less instructions than some of the old behemoths. But, that is a far cry from the aims of RISC.

There is also the rise in specialized processors. Combining that with the increased focus on consolidating everything into one chip, and much of the debate is just weird nowdays.

Aren't ARM and the majority of micro-controlers RISC?

I think that really depends on perspective. Calling micro-controllers RISC versus CISC sorta misses the point. They are of course reduced from general processors. Does that make them RISC, though?

Easy way to consider it, a GPU would probably not qualify as a RISC processor, but it also probably has fewer overall operations than a CISC processor. (Or, do they qualify nowdays?)

Now, ARM definitely is. It remains to be seen whether they can continue to be dominant once Intel enters the same arenas.

I've read arguments that CISC now has a speed advantage because its denser instruction encoding is more friendly on the cache. If true, then ARM's RISC instruction set would hold it back from ever competing with x86 on speed.

x86 doesn’t really have a dense instruction encoding. The old un-prefixed scalar instructions are dense, but they do much less work per instruction than SSE or AVX instructions, which have two or three byte prefixes (four with AVX-512). arm64 instructions are all four bytes, for comparison.

The upshot is that simple scalar code tends to be somewhat more compact on x86, and tuned vector code (likely to be found in perf-critical routines that are CPU-bound) tends to be somewhat more compact on arm.

More to the point, loop buffers and µop caches on the last couple generations of processors make encoding density mostly irrelevant to performance (though occasional pathological examples do still exist).

"More to the point, loop buffers and µop caches on the last couple generations of processors make encoding density mostly irrelevant to performance"

As in, the part where x86 processors get to fully enable the "operate as a RISC" processor mode.

From my experience certain applications, mainly server workloads, have a high instruction footprint. I-cache optimizations are necessary even on an x86 processor. So there might be some weight to this argument. I'd like to see the difference in behavior between the two architectures.

Since ARM11 (ARMv6), cores have been running on Thumb 2 (16-bit instructions) and only jumping into regular 32-bit instructions when necessary. Before that there was the Thumb instruction set which according to [0] was introduced in 1994.

This makes ARM (especially ARMv7 and newer) a mixed setup like x86.

[0] - https://en.wikipedia.org/wiki/ARM_architecture#Thumb

Thumb2 only became standard with ARMv6. There are a few ARMv6 cores which implemented Thumb2 (as opposed to Thumb1), but they aren't in many commonly used products. The ARM1176 for instance as used in the Raspberry Pi is Thumb1 only.

Granted.

I suppose my point is that ARM is going towards the same inbetween-ism that x86 has moved to.

I think the point is not so much that RISC-V is better than x86 or that RISC-V with the same budget would be better than x86, etc. The point is that since RISC-V so simple, that you can produce _your_own_ customized cpus with a very small budget. Like adding special instructions, a special memory hierarchy, a special on-chip-network, whatever. It certainly made sense for digital signal processing, graphics and networking. It may make sense for other domains too.

These custom chips have the potential to be much more power efficient (for their special class of applications) than off-the-shelf general purpose chips.

With RISC-V it will be easier to start your own CPU design...

That's largely it, but it's not just that it's simple; like Alpha, the RISC-V ISA has been carefully crafted to avoid choices that burdens implementations (be those simple or advanced).

A few examples of this (none of which are unique to RISC-V except in aggregation): no delayed-branch semantics, source and destination registers are always in fixed location (see then store vs. load encoding) and are always explicit, sign bits are immediate fields is always in the same location, etc.

In order to be as efficient as a more naïve RISC architecture, x86 has to be very optimized with an Intel-sized budget behind it. For a RISC core to be as performant as a modern x86, it has to become much more complex (and it starts to resemble an x86 core, without the x86 decoder in front of it).

Reply on news.ycombinator.com