Hacker News Reader

Comment by Vt71fcAqt7 | Hacker News Reader

>First it’s likely to be a sign that CPU ISAs are, to some extent, done.

I think this is not only correct but in a way almost obvious. Now that RISC has decidedly won out over CISC, well, what does RISC imply? To reduce the number of instructions to the minimum (or more accuratly to min/max the number). What we are left with are ISAs with few total instructions. This basically limits how much room there is for improvement, and the core instructions do not really change across modern RISC ISAs. In result, the best feature of RISC-V is not any technical feature but it's licensing features. If it gains mass adoption, nobody will ever switch to anything else because the ISA isn't the bottle neck of CPU performance anymore. A potential new ISA would have to have a different market such as GPU or ML to succeed.

View on HN

> Now that RISC has decidedly won out over CISC

Has it? The modern "RISC" designs out there in the wild include a lot of pretty specialized instructions.

I would agree load/store has won over instructions with memory side effects common to many CISC setups. Keeping side effects to a minimum to improve out of order and speculative execution has been a key goal of most modern ISAs, but keeping instruction count to a bare minimum has not. CPUs have landed in a space between RISC and CISC where simplified and reduced instruction count is certainly a goal, but the ISA will happily toss in a specialized instruction where significant speedup can be achieved.

Judging from the number of instructions in all its necessary extensions, RISC-V is RISC in name only. ARM ("Acorn RISC Machine") instructions are as absurdly many as x86's, which does not even pretend to be RISC. So it is silly to say RISC has won.

When you see RISC replace it in your head with "load/store architecture".

Like when you look at the SIMD implementations on x86 "CISC" machines they're all load/store based instead of register/memory based like on the scalar and x87 implementations.

This is what people mean when they say RISC has won.

The practical definition that came through from reading Computer Architecture: A Quantitative Approach by the two people who did most to make RISC happen (Hennessy at Stanford and Patterson at Berkeley) had to do with this formula.

work/second = work/instruction * instructions/cycle * cycles/second

The "reduction" in RISC was in work (and complexity) per instruction, enabling even greater gains in the other two factors. I'm well aware that this isn't the official definition, but IMO it's the perspective that has held up best through all the intervening years. Load/store is certainly part of that. So are orthogonal instruction and register sets, exposed pipelines, software TLBs, etc. We've gotten away from some of those things nowadays, but in the early days they were necessary to drive performance despite lower work per instruction.

> exposed pipelines

Oh boy. Good old branch delay slots on the earlier MIPS architectures.

Branch and load delays on the MC88K. I was working at Encore then, doing things like writing exception handlers and optimizing bcopy/memcpy. I actually enjoyed the puzzle-like aspect of it, but I totally got why others weren't into it.

>ARM ("Acorn RISC Machine") instructions are as absurdly many as x86's

Can you give the number of x86_64, ARM64 and RISC-V instructions? I didn't think ARM64 had 1000s of instructions.

RISC has nothing to do with instruction counts. Think of it as a "set of reduced instructions", not a "reduced set of instructions". It's the fact that every instruction only does something "simple" which you can directly implement in hardware that matters here.

In case it's still not obvious: PowerPC is obviously a RISC ISA, but it has just as many instructions as some CISC ISAs out there. Meanwhile PDP-8 has 8 instructions, but it's clearly a CISC ISA.

I think "do something simple" is going to get phased out and replaced by "do something useful" over time.

Consider if you want to load a 64-bit immediate into a register under the current RISC-V spec. Takes so many instructions that it's easier to just load a constant from memory, despite memory access being much slower.

    lui r1, 0x01234
    lui r2, 0x89ABC
    addi r1, 0x567
    addi r2, 0xDEF
    shl r1, 32
    or r1, r2

24-bytes, 6 instruction cycles and 2 registers.

In x86_64:

    movabs rax, 0x0123456789ABCDEF

11-bytes, 1 instruction cycle, 1 register.

How many uOps is that instruction in x86_64?

Note that while the performance effect of L1I cache misses is negligible, the complex x86-64 decoder may not be. Some SPECpu2017 have front-end problems due to the x86-64 decoder.

`MOV Rq, Iq` takes one uop with a throughput of up to four(!) per cycle on some ISAs: https://uops.info/html-instr/MOV_R64_I64.html

That's only for a fully general 64-bit value though. Most constants in practical use can be loaded/recomputed a lot more easily.

Practical use is double-precision floating-point constants, preprocessor generated bit-flags, high-bits pointer tagging in dynamic languages, etc. Having to read them from memory or expend multiple cycles to materialize them into a register defeats the point on even having them constant.

This is a red herring and considering that RISC-V binaries are generally the same size or smaller than x86, there are certainly code sequences where RISC-V is much smaller for the same code.

Another interesting metric is that x86 average instruction length is 4.25 bytes[0] which further implies that x86 instructions are only getting longer as time goes by. Meanwhile, RISC-V should continue to get more dense as new instructions are added.

[0] https://aakshintala.com/papers/instrpop-systor19.pdf

Reply on news.ycombinator.com