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

131–140 of 149 posts

Re: Addressing Criticism of RISC-V Microprocessors

#131

Post by ncmncm »

socialdemocrat wrote: post #53
ribit wrote: post #35

I have difficulty following the points the author is trying to make. - Even with instruction compression the type of code they present will take more space than, say, Aarch64. - The entire section on conditional execution doesn't make any sense. Conditional execution is bad, we know it, that's why modern ARM does not have conditional execution. Overall, author's insistence to compare RISC-V to practically obsolete AR…

Author here: I have tried to clarify this better in the update. The point is that I am talking about AArch32 and AArch64 in the article. Yes, everybody has been going away from conditional instructions, because they don't work well in Out-of-Order superscalar processors, and they are pointless when you got good branch predictors. HOWEVER, an argument in the ARM camp is that they are very useful when dealing with smal…

Conditional execution (CMOV) in modern x86 (or any modern target) enables 2x better sort performance specifically in places where branch prediction utterly fails because the input data is not predictable. If RISC-V lacks this capability (like Arm64?), then congratulations, RISC-V has closed off the possibility of a 2x performance improvement in important algorithms.

This is also a place where RISC-V displays an ABI choice that is nonsensical: a bit of historical awareness would have made the boolean "true" value ~0, or -1, as indeed it effectively is in AVX2 and GPUs.

Re: Addressing Criticism of RISC-V Microprocessors

#132

Post by ncmncm »

BirAdam wrote: post #43
nnx wrote: post #42

Earlier quoted context omitted.

> I recently heard Jim Keller explain why RISC-V has a bright future Would like to hear it too. Can you share a link?

Updated my response to include a link to the transcription. The audio/video is here: https://www.youtube.com/watch?v=AFVDZeg4RVY It’s actually important (if you’re not an engineer) to listen to the whole thing, because he drops knowledge all over the place.

Watching that was my best use of time in the past month.

I watched at 1.5x speed.

Re: Addressing Criticism of RISC-V Microprocessors

#133

Post by skavi »

brucehoult wrote: post #57
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.

This is really not a big deal with RISC-V's 2 instruction lengths and the encoding they use. If decoding 32 bytes of code (256 bits, somewhere between 8 and 16 instructions) You can figure out where all the actual instructions start (yes, even the 16th instruction) with 2 layers of LUT6. You can then use those outputs to mux two possible starting positions for 8 decoders that do 16 or 32 bit instructions, plus 8 deco…

What would one do if they had half an instruction falling off the end of that window? Save it then deal with it when you have the other half next cycle?

I’m assuming the decode window is aligned, but that may be a bad assumption.

Re: Addressing Criticism of RISC-V Microprocessors

#134

Post by ribit »

socialdemocrat wrote: post #53
ribit wrote: post #35

I have difficulty following the points the author is trying to make. - Even with instruction compression the type of code they present will take more space than, say, Aarch64. - The entire section on conditional execution doesn't make any sense. Conditional execution is bad, we know it, that's why modern ARM does not have conditional execution. Overall, author's insistence to compare RISC-V to practically obsolete AR…

Author here: I have tried to clarify this better in the update. The point is that I am talking about AArch32 and AArch64 in the article. Yes, everybody has been going away from conditional instructions, because they don't work well in Out-of-Order superscalar processors, and they are pointless when you got good branch predictors. HOWEVER, an argument in the ARM camp is that they are very useful when dealing with smal…

Thanks for replying, much appreciated. I admit that my interest primarily goes towards desktop application and my comment was made from that angle. Regarding conditional instructions on in-order microarchitecture: I neither have a strong opinion nor am I familiar with the discussion. Intuitively at least, conditional instructions do seem like a useful tool for simple in-order CPUs, but as you point out instruction fusion can be used to solve a lot of things. It’s a question of tradeoffs, and it is not obvious to me what cost these tradeoffs bring. It does seem that RISC-V will need to more heavily rely on operation fusion to achieve better performance and efficiency (as opposed to something like ARM where some patters are already “pre-fused” in the ISA). The time will tell. I don’t think that any of these are trivial.

Re: Addressing Criticism of RISC-V Microprocessors

#135

Post by ribit »

audunw wrote: post #49
ribit wrote: post #35

I have difficulty following the points the author is trying to make. - Even with instruction compression the type of code they present will take more space than, say, Aarch64. - The entire section on conditional execution doesn't make any sense. Conditional execution is bad, we know it, that's why modern ARM does not have conditional execution. Overall, author's insistence to compare RISC-V to practically obsolete AR…

Why do you list code density as a potential disadvantage? With changes to the ISA that has already been approved, RISC-V will have the best code density of any significant ISA in real-world code. The article touched on this briefly so it's odd that you would claim this without a source for the claim. I know there's some outdated benchmarks where it's slightly worse than Thumb for instance. But then Thumb isn't releva…

No, you are right. It’s just frustrating that there is almost no information on this topic. The only data I was able to find is a very short paper from 2017 that compares code density for some simple use cases. The results suggest that Aarch64 and compressed RISC-V are in the same ballpark. I would like to see this looked at over larger and more complex code bases.

Re: Addressing Criticism of RISC-V Microprocessors

#136

Post by ribit »

socialdemocrat wrote: post #60
ribit wrote: post #35

I have difficulty following the points the author is trying to make. - Even with instruction compression the type of code they present will take more space than, say, Aarch64. - The entire section on conditional execution doesn't make any sense. Conditional execution is bad, we know it, that's why modern ARM does not have conditional execution. Overall, author's insistence to compare RISC-V to practically obsolete AR…

> And that bit about GPUs and how they are not good for vector processing... not even sure how to comment on it. Also, at the end of the day, specialised devices will vastly outperform any general-purpose CPU solution. That's why we see, say, Apple M1 matrix accelerators delivering matmul performance on par with workstation CPU solutions, despite using a fraction of power. Of course CPUs are good for vector processin…

ET-minion can complete with GPUs because it is essentially a GPU. Most GPUs are in-order RISC machines with very wide SIMD ALUs and huge register banks. Whether it runs RISC-V or some proprietary ISA doesn’t really matter. How you build things does. And anyway, RISC-V vector ISA seems to be closely inspired by GPU ISAs to begin with.

Regarding SIMD: maybe you are right. I don’t know. Performance of RISC-V vectors here is an unknown factor. If VSETVL is zero-cost and the CPU can rename vector partitions without added latency, sure. But I remain skeptical until proven otherwise. The very design of RISC-V vector stuff screams amortized processing of large data blocks, not flexible low-latency operations on small data blocks. And notably, I could not find basic SIMD shuffle/interleave operations in the spec. That’s perfectly fine for large data vectors where you can work with multiple instruction, data-parallel vector registers and blends, but it would kill performance for many algorithms that work on limited number of lanes.

Re: Addressing Criticism of RISC-V Microprocessors

#137

Post by ansible »

google234123 wrote: post #129
bigcheesegs wrote: post #109

Earlier quoted context omitted.

Encoding space, not die space.

Encoding space is almost infinite on intel though.

> Encoding space is almost infinite on Intel though.

Yes... if you willing to tolerate ever more complex and slow instruction decoding. This is a very bad tradeoff.

Re: Addressing Criticism of RISC-V Microprocessors

#138

Post by jhgb »

> In RISC-V the equivalent would require a whole 3 different instructions

I'm surprised that it wasn't pointed out that this should probably be eliminated by a compiler transformation. Rather than loading from r0+r1<<2 and incrementing r1 by one every loop iteration, surely it might be possible to load from just r0 and increment it by 4 every loop iteration?

Re: Addressing Criticism of RISC-V Microprocessors

#139

Post by wmanley »

socialdemocrat wrote: post #121
wmanley wrote: post #100

Earlier quoted context omitted.

Things get locked in not by standards, but by usage. If your software depends on particular instructions being present you’re not going to buy a processor that has superseded those instructions, even if the new instructions conform to a theoretically cleaner design. Everything being an extension (and thus removable) is a strength in some specific circumstances, but is a weakness in most.

That doesn't make any sense. Because RISC-V has kept instructions to such a bare minimum, there will be very little you will be dependent on and which new designs have to take into account. What you describe is a problem for x86 and ARM not for RISC-V. You got it all in reverse. General-purpose CPUs for desktop computers and such will not be willy nilly adding extensions. They will standardize on something like RV64G…

> Are you worried that the processor in your keyboard or mouse isn't backwards compatible with the processor you used in your previous mouse or keyboard?

No, but the keyboard manufacturer might be, as might the people who are writing and optimising compilers targetting that CPU.

Re: Addressing Criticism of RISC-V Microprocessors

#140

Post by panick21_ »

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…

> RISC philosophy still matters

What matters is not 'RISC philosophy' but that it is an Open Standard that allows for Open implementation.

Post reply on HN