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

221–230 of 365 posts

Re: “Risc V greatly underperforms”

#221

Post by hajile »

zamadatix wrote: post #206
hajile wrote: post #171

Earlier quoted context omitted.

It's not too surprising. Load, store, move, add, subtract, shift, branch, jump. These are definitely the most common instructions used. Put it side-by-side with Thumb and it also looks pretty similar (thumb has a multiply instruction IIRC). Put it side-by-side with short x86 instructions accounting for the outdated ones and the list is pretty similar (down to having 8 registers). All in all, when old and new instruct…

It was more a question of the way it was handled (i.e. it's not a different mode and can be mixed) than what the opcode list looked like.

Mode switching bloats the instruction count by shifting in and out. RISC-V does well here.

If there's a criticism, it's that the two bytes on 32-bit instructions mean the total instruction range is MUCH smaller overall until you switch to 48-bit instructions which are then much bigger.

Re: “Risc V greatly underperforms”

#222

Post by brucehoult »

brandmeyer wrote: post #199
zamadatix wrote: post #108

Earlier quoted context omitted.

> Except for this good feature, the rest of the ISA is full of bad features What are your thoughts on the way RISC V handled the compressed instructions subset?

It only addresses a subset of the available registers. Small revisions in a function which change the number of live variables will suddenly and dramatically change the compressibility of the instructions. Higher-level languages rely heavily on inlining to reduce their abstraction penalty. Profiles which were taken from the Linux kernel and (checks notes...) Drystone are not representative of code from higher-level l…

This is just rubbish.

Small revisions to a function that increase the number of live variables to more than the set that are covered by the C extension mean that reference to THAT VARIABLE ONLY have to use a full size instruction. There is nothing sudden or dramatic.

Note that a number of a C instructions can in fact use all 32 registers. This includes stack pointer-relative loads and stores, load immediate ({-32..+31}), load upper immediate (4096 * {-32..+31}, add immediate and add immediate word ({-32..+31}), shift left logical immediate, register to register add, and register move.

It's certainly possible that another compressed encoding might do better using fewer opcode, and I've seen the suggestions. The main thing wrong with the standard one in my opinion is that it gives too much prominence to floating point code, having been developed to optimise for SPEC including SPECFP (no, not the Linux kernel or Dhrystone ... I have no idea where you got that from).

But anyway it does well, and the opcode space used is not excessive. If anything it's TOO SMALL. Thumb2 gets marginally better code size while using 7/8ths of the opcode space for the 16 bit instructions instead of RISC-V's 3/4.

Re: “Risc V greatly underperforms”

#223

Post by The_rationalist »

plorkyeran wrote: post #144
lvh wrote: post #122

Earlier quoted context omitted.

An FPGA can be reprogrammed, and we do really do this for standards with better longevity than video standards (e.g. cryptographic ones like AES and SHA). For standards like video codecs, we just use GPUs instead, which I assume is what OP had in mind for "specialized hardware" (specialization can still be pretty general :-)).

Hardware video decoding is done by a single-purpose chip on the graphics card (or dedicated hardware inside the GPU), not via software running on the GPU. Adding support for a new video codec requires buying a new video card which supports that codec.

While this is true (GPUs have embedded video ASICs), are there software GPU decoders for video codecs that outperform CPU decoders (and do not use the hardcoded GPU ASICs)? This would allow newer codecs to become mainstream more quickly vs the inertia of needing to buy a new GPU.

Re: “Risc V greatly underperforms”

#224

Post by wott »

voz_ wrote: post #174
audunw wrote: post #133

Earlier quoted context omitted.

> I am sorry but saying that RISC-V is a winner in code density is beyond ridiculous. You have no idea what you're talking about. I've worked on designs with both ARM and RISC-V cores. The RISC-V code outperforms the ARM core, with smaller gate count, and has similar or higher code density in real world code, depending on the extensions supported. The only way you get much lower code density is without the C extensio…

Textbook example of the kind of hostility and close-mindedness that is creeping into our beloved site. Why are we dick measuring? why are we comparing experience like this? so much "I" "I" "I"... I have no horse in the technical race here, but I certainly am put off from reading what should be an intellectually stimulating discussion by the nature of replies like this.

Somehow I find it refreshing to see flamewars about ISAs, for I hadn't seen any in the last 15 years (at least). It makes me feel young again. :-)

Re: “Risc V greatly underperforms”

#225

Post by brucehoult »

lonjil wrote: post #176
Dylan16807 wrote: post #164

Earlier quoted context omitted.

Oh, you meant thumb and thumb-2.

"thumb-2" isn't really a thing. It's just an informal name from when more instructions were being added to thumb. it's still just thumb.

Thumb2 is a thing. Thumb is purely 16 bit instructions. Thumb2 is a mix of 16 bit and 32 bit instructions.

As an illustrative example, in Thumb when the programmer writes "BL " or "BX " the assembler creates two undocumented 16 bit instructions next to each other which together have the desired effect. If you create those instructions yourself using e.g. .half directives (or if you're writing a JIT or compiler) then you can actually put other instructions between them, as long as you don't disturb the link register.

In Thumb2 the bit patterns for BL and BX are the same, but they are an ACTUAL 32 bit instruction which can't be split up like it can in Thumb.

Re: “Risc V greatly underperforms”

#226

Post by kccqzy »

Taniwha wrote: post #151
masklinn wrote: post #130

Earlier quoted context omitted.

For generalised signed addition, the overhead is 3 instructions per addition . It can be one in specific contexts where more is known about the operands (e.g. addition of immediates). It’s always 1 in x64/ARM64 as they have built-in support for overflow.

you have to include the branch instruction too in any comparison

In x86 it is still one instruction: jc or jo after an addition.

Re: “Risc V greatly underperforms”

#227

Post by tomxor »

> Let's look at some examples (7 instructions vs 2 vs 2)

Isn't this the classic RISC vs CISC problem?

Comparing x86/ARM to RISC-V feels like Apples to Grains of Rice.

If RISC-V was born out of a need for an open source embedded ISA, would the ISA not need to remain very RISC-like to accommodate implementations with fewer available transistors... Or is this an outdated assumption?

Re: “Risc V greatly underperforms”

#228

Post by brucehoult »

lonjil wrote: post #152
akiselev wrote: post #119

Earlier quoted context omitted.

> RISC-V is in fact the outlier among ISAs in many of these design decisions, so there's a heavy burden of proof to demonstrate that making the contrary decisions in many cases was the right call. Genuinely asking, why ? Do we think RISC-V should, or even could , try to compete against the AMD/Intel/ARM behemoths on their playing field? Obviously ISAs are a low level detail and far removed from the end product, but i…

> Genuinely asking, why? Do we think RISC-V should, or even could, try to compete against the AMD/Intel/ARM behemoths on their playing field? Well, it's exactly what many RISC-V folks are trying to do. There's news about a new high performance RISC-V core on the HN front page right now! > but it feels like the architectural decisions we are "stuck with" today are inextricably intertwined with their contemporary marke…

I agree that arm64 and RISC-V designers had basically the same hindsight and market conditions to refer to -- and they made a lot of very similar decisions.

But arm64 does seem constrained by compatibility with arm32 -- at least in that they until now (ten years later) usually have to share an execution pipeline and register set.

Is it really conceivable that the arm64 designers had free rein to make the choice whether to use condition codes or not on a purely technical basis? I don't think so. Even if they thought -- as all other designers of ISAs intended for high performance since 1990 have (Alpha, Itanium, RISC-V) -- that it's better not to use condition codes, I don't think they would have been free to make that choice.

The same goes for whether to expose instructions using the "free" shift on the 2nd ALU input. It's not really free -- it's paid for with a longer clock cycle or an extra pipeline stage or splitting instructions into uops. And since it was there for 32 bit they might as well use it in 64 bit as well. And the same for the complex addressing modes.

Re: “Risc V greatly underperforms”

#229

Post by brucehoult »

User23 wrote: post #198
snvzz wrote: post #113

Earlier quoted context omitted.

Larger caches, as seen in Apple's M1 L1, are one of many tools to deal with bad code density. RISC-V might, at first glance, look similar to MIPS, but it leads in code density among the 64 bit architectures.

> [RISC-V] leads in code density among the 64 bit architectures. You keep baldly asserting this in virtually all of your very many replies here, with a vague appeal to your own authority, but you haven't shown anything. Given that the submission is precisely an example of bad code density, if you're really here in the service of intellectual curiosity then please show instead of just telling.

No argument from authority is needed.

Anyone is free to download the disk images for a large body of software such as the same versions of Ubuntu or Fedora, and compare the binary sizes -- using the "text" output from "size" command, not raw disk files as there are also things such as debugging info in there.

Here's an example, using (ironically) the GMP library itself.

https://news.ycombinator.com/item?id=29423324

Here we see riscv64 significantly smaller than the other 64 bit ISAs aarch64 (28.1%) and x86_64 (36.5%), and beaten by a smaller margin by 32 bit ARM Thumb2 (-17.0%)

Anyone can check the sizes of bash, perl, emacs ... whatever they want ... themselves, without relying on the word of anyone here.

Re: “Risc V greatly underperforms”

#230

Post by nocat »

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…

What are the particularly good design features of SuperH? (As compared to, say, MIPS?)

What sticks in my mind from my limited exposure to SuperH is that there's no load immediate instruction, so you have to do a PC-relative load instead. It was clearly optimized for compiled rather than handwritten code!

Post reply on HN