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

“Risc V greatly underperforms”

gmplib.org

Post reply on HN
Print view View original

31–40 of 365 posts

Re: “Risc V greatly underperforms”

#31

Post by bitwize »

Taniwha wrote: post #3

So this is one tiny corner of the ISA, not something that makes ALL instruction sequences longer - essentially RISCV has no condition codes (they're a bit of an architectural nightmare for everyone doing any more than the simplest CPUs, they make every instruction potentially have dependencies or anti-dependencies with every other). It's a trade off - and the one that's been made is one that makes it possible to make…

It's not a tiny corner. People do arithmetic with carry all the time. Arbitrary precision arithmetic is more common than you think. Congratulations, RISC-V, you've not only slowed down every bignum implementation in existence, all those extra instructions to compute carry will blow the I$ faster, potentially slowing down any code that relies on a bignum implementation as well.

Re: “Risc V greatly underperforms”

#32

Post by AlotOfReading »

okl wrote: post #14

Few years ago, I designed my own ISA. In that time I investigated design decisions in lots of ISAs and compared them. There was nothing in the RISC-V instruction set that stood out to me, like for example, the SuperH instruction set, which is remarkably well designed. Edit: Don't get me wrong, I don't think RISC-V is "garbage" or anything like that. I just think it could have been better. But of course, most of an ar…

My memories of SuperH are a bit different. Yeah, it's cleaner than ARM, but the delay slots, hardware division, and the tiny register file among others made life unnecessarily difficult. A lot of those design decisions didn't hold up well over time.

Re: “Risc V greatly underperforms”

#33

Post by okl »

Teknoman117 wrote: post #17

A bit of a computer history question: I have never looked at the ISA of the Alpha (referenced in post), but RISC V has always struck me as being nearly identical to (early) MIPS, just without the HI and LO registers for multiply results and the addition of variable length instruction support, even if the core ISA doesn't use them. MIPS didn't have a flag register either and depended on a dedicated zero register and s…

I bet this article on RISC-V's genealogy is interesting for you: https://live-risc-v.pantheonsite.io/wp-content/uploads/2016/...

Re: “Risc V greatly underperforms”

#34

Post by snvzz »

I don't think they even tried to read the ISA spec documents. If they did, they would have found that the rationale for most of these decisions is solid: Evidence was considered, all the factors were weighted, and decisions were made accordingly.

But ultimately, the gist of their argument is this:

>Any task will require more Risc V instructions that any contemporary instruction set.

Which is easy to verify as utter nonsense. There's not even a need to look at the research, which shows RISC-V as the clear winner in code density. It is enough to grab any Linux distribution that supports RISC-V and look at the size of the binaries across architectures.

Re: “Risc V greatly underperforms”

#35

Post by panick21_ »

theresistor wrote: post #4
jpfr wrote: post #2

The idea is to use the compressed instruction extension. Then two adjacent instructions can be handled like a single “fat” instruction with a special case implementation. That allows more flexibility for CPU designs to optimize transistor count vs speed vs energy consumption. This guy clearly did not look at the stated rationale for the design decisions of RISC-V.

Compressed instructions and macro-fusion aren't magical solutions. It's not always possible to convince the compiler to generate the magical sequence required, and it actually makes high-performance implementations (wide superscalar) more difficult thanks to the variable width decoding. Beyond that, compressed instructions are not a 1:1 substitute for more complex instructions, because a pair of compressed instructio…

Part of the idea is to create standard ways to do certain things and then hope compiler writers generation code according to that. That will allow more chip designers to take advantage of those if they want to.

They spent a lot of time and effort on making sure the decoding pretty good and useful for high performance implementations.

RISC-V is designed for very small and very large system. At some point some tradeoffs need to be made but these are very reasonable and most of the time no a huge problem.

For the really specialized cases where you simply can't live with those extra instruction, those will be added to the standard and then some profiles will include them and others not. If those instructions are really as vital as those that want them claim, they will find their way into many profiles.

Saying RISC-V is 'terrible' because of those choices is not fair way of evaluating it.

Re: “Risc V greatly underperforms”

#36

Post by Buttons840 »

alerighi wrote: post #30
jpfr wrote: post #2

The idea is to use the compressed instruction extension. Then two adjacent instructions can be handled like a single “fat” instruction with a special case implementation. That allows more flexibility for CPU designs to optimize transistor count vs speed vs energy consumption. This guy clearly did not look at the stated rationale for the design decisions of RISC-V.

Even if you do so, the program size is still bigger, and it consumes more disk, RAM and most importantly cache space. Wasting cache for having multiple instructions when on another architecture it's done by only one doesn't make particular sense to me. Also, it's said that x86 is bad because the instructions are then reorganized and translated inside the CPU. But it seems that you are proposing the same, the CPU that…

How many cache misses are for program instructions, versus data misses?

Re: “Risc V greatly underperforms”

#37

Post by okl »

chillingeffect wrote: post #20
sosodev wrote: post #12

Why do these half baked slam pieces always make it to the top of HN?

if for no other reason than to quickly formulate counterarguments. Next time at some meeting or other get together, if someone pipes up with an anti-RISC comment, most people won't be able to quickly refute it. But having had this discussion here, we're inocculated and able to respond with intelligence and experience.

That sounds like you make up your mind first, then look for arguments that support your position. I'd rather see the arguments before I come to conclusions.

Re: “Risc V greatly underperforms”

#38

Post by Koffiepoeder »

CalChris wrote: post #26

TL;DR My code snippet results in bloated code for RISC-V RV64I. I'm not sure how bloated it is. All of those instructions will compress [1]. [1] https://riscv.org/wp-content/uploads/2015/05/riscv-compresse... It's slower on RISC-V but not a lot on a superscalar. The x86 and ARMv8 snippets have 2 cycles of latency. The RISC-V has 4 cycles of latency. 1. add t0, a4, a6 add t1, a5, a7 2. sltu t6, t0, a4 sltu t2, t1, a5…

CPU performance increases nowadays often are measured in single digit percentages because the margins became so thin. Doubling the cycles is a 100% increase. You can call that not so bloated, but I think many people would beg to differ.

On the other hand I take this article with a grain of salt anyhow, since it only discusses a single example. I think we would need a lot more optimized assembly snippet comparisons to make meaningful conclusions (and even then there could be authored selection bias).

Re: “Risc V greatly underperforms”

#39

Post by anarazel »

Buttons840 wrote: post #36
alerighi wrote: post #30

Earlier quoted context omitted.

Even if you do so, the program size is still bigger, and it consumes more disk, RAM and most importantly cache space. Wasting cache for having multiple instructions when on another architecture it's done by only one doesn't make particular sense to me. Also, it's said that x86 is bad because the instructions are then reorganized and translated inside the CPU. But it seems that you are proposing the same, the CPU that…

How many cache misses are for program instructions, versus data misses?

IME icache misses are a frequent bottleneck. There's plenty code where all the time is spent in one tight inner loop and thus the icache is not a constraint, but there's also a lot of cases with a much flatter profile. Where icache misses suddenly become a serious constraint.
Post reply on HN