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

21–30 of 149 posts

Re: Addressing Criticism of RISC-V Microprocessors

#21

Post by avianes »

FullyFunctional wrote: post #13
saagarjha wrote: post #12

Earlier quoted context omitted.

> 25% fewer bytes has only very marginally impact on a high-performance implementation Instruction cache doesn't come for free, and is usually pretty small on most shipping processors. It's not a big deal for smaller benchmarks, but in real-world programs this can become a problem.

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.

Re: Addressing Criticism of RISC-V Microprocessors

#22

Post by [deleted] »

feanaro wrote: post #20
FullyFunctional wrote: post #9

Earlier quoted context omitted.

This comes up a lot and I'm sympathetic to your plea, really (I enjoy fantasizing about a different reality where CPUs weren't just "machines to run C programs"), but in computer architecture, what really matters for one application or a class of applications might not be important when viewed across millions of programs. The fact is that integer operations and floating point are two completely different beasts, so m…

> add t0, t1, t2 bltu t0, t1 How does this work? Isn't `bltu` simply a branch that is taken if `t0 EDIT: Ah, because the operands are `t1` and `t2`. `t0` is the result. Quack.

[deleted]

Re: Addressing Criticism of RISC-V Microprocessors

#24

Post by IshKebab »

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.

Re: Addressing Criticism of RISC-V Microprocessors

#27

Post by math-dev »

jfkimmes wrote: post #25

I get "To keep reading this story, get the free app or log in. (With Facebook or Google)" on mobile. No thanks, Medium. These dark patterns crop up everywhere lately...

That’s a shame…it was the most annoying thing about Quora to me.

As a Medium writer, I’m annoyed now! They already stopped paying me my ~0-10$ per month because I refused to beg everyone to get to their new minimum 100 followers requirement for getting paid.

Re: Addressing Criticism of RISC-V Microprocessors

#28

Post by avianes »

dontlaugh wrote: post #23

It’s nice to have an open ISA, don’t get me wrong. However, trade offs matter. Compressing instructions may improve density, but it makes them variable length. This is a big barrier to decoding in parallel, which is very important to high performance cores.

You are right but RISC-V variable instruction size is indeed a good trade-off.

Unlike x86 where instructions can range from 1 up to 15 byte, current RISC-V ISA only has 2 instruction sizes.

Today x86 decoding is limiting because we want to decode more than ~4 instructions each cycle, for RISC-V to cause same decoding difficulty it would probably be required to decode more than ~20 instructions each cycle

Re: Addressing Criticism of RISC-V Microprocessors

#30

Post by mhh__ »

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.

No. Firstly -march (or similar, e.g. -mcpu in LLVM land) should target a chip not individual instruction sets.

Secondly, AVX-512 alone has a handful of different extensions. There are a bunch of different SSE variants, and similarly instructions are still being added to the VEX prefix (normal AVX).

There is more potentially for getting it wrong with riscv but 64 bit implies a number of extensions too so it's too far off what amd64 originally meant for X86 (e.g. implies SSE2)

Post reply on HN