Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Addressing Criticism of RISC-V Microprocessors

erik-engheim.medium.com

Post reply on HN
Print view View original

71–80 of 149 posts

Re: Addressing Criticism of RISC-V Microprocessors

#71

Post by KerrAvon »

avianes wrote: post #21
FullyFunctional wrote: post #13

Earlier quoted context omitted.

I am obviously aware and I'm here to tell you that the overhead of variable length instructions matters more. Arm agrees. M1 has a 192 KiB I$ btw. ADD: had RISC-V just disallowed instructions from spanning cache lines and disallowing jumping into the middle of instructions then almost all of the issues would have gone away. Sigh.

Variable instruction sizes have a cost, but with only 2 instruction sizes like current RISC-V that cost remains very low as long as we don't have to decode a very large number of instructions each cycle, and it gives a huge code density advantage.

Have the ARM AArch64 designers ever commented on this? They intentionally left out any kind of compressed instructions, and certainly Apple at least cares a lot about code size.

Re: Addressing Criticism of RISC-V Microprocessors

#72

Post by knorker »

damageboy wrote: post #69
FullyFunctional wrote: post #11

Earlier quoted context omitted.

EDIT: Hmm, I seem to have picked a bad example. Try this one: int get(int *base, unsigned index) {return base[index];} Arm64: update: ldr w0, [x0, w1, uxtw 2] ret RV64GC (vanilla): update: slli a5,a1,32 srli a1,a5,30 add a0,a0,a1 lw a0,0(a0) ret RV64GC+Zba: update: sh2add.uw a0,a1,a0 lw a0,0(a0) ret Arm64 is able to do some indexed loads in a single instruction that might take two in RISC-V w/Zba (and up to 4+ in reg…

Thank you for writing the obvious. Instruction Byte count is the wrong metric here 100%. Instruction Count (given reasonable decoding/timing constraints) is the thing to optimize for and indeed variable length encoding is very bad.

For those of us without the expertise, could you elaborate on why that is?

On the one hand we have byte count, with its obvious effect on cache space used. But to those of us who don't know, why is instruction count so important?

There's macro-op fusion, which admittedly would burn transistors that could be used for other things. Could you elaborate why it's not sufficient?

And then the fact that modern x86 does the opposite to macro-op fusion, by actually splitting up CISC instructions into micro-ops. Why is it so bad if they were more micro-ops to start with, if Intel chooses to do this?

Re: Addressing Criticism of RISC-V Microprocessors

#73

Post by [deleted] »

KerrAvon wrote: post #71
avianes wrote: post #21

Earlier quoted context omitted.

Variable instruction sizes have a cost, but with only 2 instruction sizes like current RISC-V that cost remains very low as long as we don't have to decode a very large number of instructions each cycle, and it gives a huge code density advantage.

Have the ARM AArch64 designers ever commented on this? They intentionally left out any kind of compressed instructions, and certainly Apple at least cares a lot about code size.

[deleted]

Re: Addressing Criticism of RISC-V Microprocessors

#74

Post by klelatti »

KerrAvon wrote: post #71
avianes wrote: post #21

Earlier quoted context omitted.

Variable instruction sizes have a cost, but with only 2 instruction sizes like current RISC-V that cost remains very low as long as we don't have to decode a very large number of instructions each cycle, and it gives a huge code density advantage.

Have the ARM AArch64 designers ever commented on this? They intentionally left out any kind of compressed instructions, and certainly Apple at least cares a lot about code size.

Try this at 34:30 - from Arm’s architecture lead Richard Grisenthwaite. Earlier he says that several leading micro architects think that mixing 16 bit and 32 bit instructions (Thumb2) was the worst thing that Arm ever did.

https://m.soundcloud.com/university-of-cambridge/a-history-o...

Re: Addressing Criticism of RISC-V Microprocessors

#75

Post by kortex »

albanread wrote: post #55

People should zoom right out and think about the whole RISC-V project. When our phones have billions of transistors, are we seriously supposed to believe that RISC philosophy still matters. Personally I greatly prefer the user programmable 68000 family of processors. The marketing of RISC-V is perhaps the most impressive thing about it. Each to their own, I can see why giant SSD manufacturers want to use a license fr…

Yeah, absolutely. Personally, when I zoom out, and look at the trends of engineering in general: simpler modular systems that compose well together vs bespoke solutions, RISC-V precisely follows the trend. Reduce global state. Make it easier (for humans and algos) to reason about control flow. Have a simple core with optional extensions. This all makes building multi-core solutions way simpler. We are fast running out of transistor density improvements. But we are getting way better at building coprocessors. There's clear value in "doing more simple things in parallel".

Re: Addressing Criticism of RISC-V Microprocessors

#76

Post by snek_case »

marcosdumay wrote: post #70
snek_case wrote: post #66

Earlier quoted context omitted.

Not only that, but CPUs have a maximum number of instructions they can dispatch per cycle (typically 4 or 6). Even in microbenchmarks, the difference there could show up.

The bottleneck on that is data interdependency of your algorithm. If you break it in 6 or 10 instructions, the data dependency stays the same. (Of course, you can add unnecessary dependency with a badly designer ISA. But it's not a necessary condition.)

There's still a limit to how many instructions you can decode and dispatch every cycle, even with zero dependencies. There's also definitely dependencies in the example where you're computing a memory address to access a value.

Re: Addressing Criticism of RISC-V Microprocessors

#77

Post by zozbot234 »

> Every 32-bit word in the instruction cache will contain either a 32-bit uncompressed instruction or two 16-bit compressed instructions. Thus everything lines up nicely.

This is not really accurate AIUI, since the RISC-V C extension allows 32-bit insns to be 16-bit aligned. (This would also happen if 48-bit insns were enabled by some other future extension). It's nonetheless a lot simpler than whatever x86 has to do, since insn length is given by a few well-defined bits in the insn word.

Re: Addressing Criticism of RISC-V Microprocessors

#78

Post by google234123 »

socialdemocrat wrote: post #65
IshKebab wrote: post #24

Dubious. How is "you have to use this magic combination of instructions that compress & execute well" better than having a dedicated instruction? Also no mention of the binary compatibility issues - which `-march` do you compile your code for? On x86 you have a choice of 3. For RISC-V as far as I can tell there are 96 valid targets.

Because dedicated instructions suck up valuable encoding space, and the more instructions you have, the more instruction you have which potentially become obsolete with new advances in microarchitecture. Not to mention that by sticking with simple single purpose instructions you make the CPU easier to teach to students. That is after all one of the goals of RISC-V in addition to creating a good ISA for industry. Have…

With every node shrinkage those legacy instructions take up less space

Re: Addressing Criticism of RISC-V Microprocessors

#79

Post by JonChesterfield »

avianes wrote: post #34
JonChesterfield wrote: post #31

Earlier quoted context omitted.

Iirc compressed instructions are the thing that costs 2 bits per 32 and was criticised as overfitted to naive compiler output. Am I thinking of something else?

Yes, but RISC-V still has a lot of encoding-space free and the benefit of C extension is huge. It's a trade-off. I don't think RISC-V is perfect or universal, but on this point they do a pretty good job compared to other ISAs

32 bit, 32 registers, three register code. So add r0 r1 r2 spends fifteen bits on identifying which register to use then another two on the compressed ISA. That's half the encoding space gone before identifying the op. Never thought I'd want fewer registers but here we are.

If the compressed extension is great in practice it might be a win. If the early criticism of overfit to gcc -O0 proves sound and in practice compilers don't emit it then it was an expensive experiment.

Post reply on HN