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

341–350 of 365 posts

Re: “Risc V greatly underperforms”

#341

Post by FullyFunctional »

socialdemocrat wrote: post #288
amelius wrote: post #287

Earlier quoted context omitted.

Doesn't decompression imply that there is some extra latency?

No, it is just part of the regular instruction decoding. It is not like it is zip compressed. It is just 400 logic gates added to the decoder… which is nothing.

All the implementation I know of all does the same thing: they expand the compressed instruction into a non-compressed instruction. For all (most?), this required an additional stage in the decoder. So in that sense, supporting C mean a slight increase in the branch mispredict penalty, but the instruction itself takes the same path with the same latency regardless of it being compressed or not.

Completely aside, compressed instruction hurt in a completely different way: as specified RISC-V happily allows instructions to be split across two cache lines, which could be from two different pages even. THIS is a royal pain in the ass and rules out certain implementation tricks. Also, the variable length instructions means more stages before you can act on the stream, including for example rename them. However a key point here is that it isn't a per-instruction penalty, it a penalty paid for all instruction if the pipeline support any variable length instructions.

Re: “Risc V greatly underperforms”

#342

Post by ddingus »

panick21_ wrote: post #326
ddingus wrote: post #250

Earlier quoted context omitted.

>overall far more value in having it be unified. >[...] >If integer checking is really the be all end all and without it RISC-V can not be successful without it, it will be added and it will be pulled into all the profiles. If it is not actually that relevant then it wont. If it is very useful for some verticals and not others, it will be in those profiles and not in others. So which is it? Unified or something else?

The goal is that there is a unified core that runs the majority code. The majority of ecosystem and tooling works of a common base. Lots of code can be used in a way to be very universal. Some verticals that will be special like deep embedded will likely be different enough that it will be slightly different, but it still profits from all the work going into the overall ecosystem. RISC-V allows 'the market' to decide…

Again, I ask: Unified, or something else?

Having a "majority" isn't really different from what we have now, and it includes the downside of a more robust monoculture.

And to be clear here, I'm not anti RISC-V. I am very highly skeptical, given how frequently we see things like code size critics responded to with 'but it will be faster', which isn't really an answer,

The same thing happened here. Hand wavy "the market" and "orthogonal way" doesn't communicate anything meaningful, and or worth some clear downsides at present.

Finally, "the goal" is really "a goal or vision" as expressed by proponents. It's not really one in the objective sense.

Re: “Risc V greatly underperforms”

#343

Post by panick21_ »

ddingus wrote: post #342
panick21_ wrote: post #326

Earlier quoted context omitted.

The goal is that there is a unified core that runs the majority code. The majority of ecosystem and tooling works of a common base. Lots of code can be used in a way to be very universal. Some verticals that will be special like deep embedded will likely be different enough that it will be slightly different, but it still profits from all the work going into the overall ecosystem. RISC-V allows 'the market' to decide…

Again, I ask: Unified, or something else? Having a "majority" isn't really different from what we have now, and it includes the downside of a more robust monoculture. And to be clear here, I'm not anti RISC-V. I am very highly skeptical, given how frequently we see things like code size critics responded to with 'but it will be faster', which isn't really an answer, The same thing happened here. Hand wavy "the market…

Not having the definition being controlled by a company, being and open specification and the whole ecosystem and tooling from the ground up being designed around a fully modular instruction set with use-case specific profiles that can evolve independently is very different then what we have now.

> Finally, "the goal" is really "a goal or vision" as expressed by proponents. It's not really one in the objective sense.

No idea what that means.

I don't know if it will be faster, frankly I don't care if its slightly slower, even if I don't really think that will be the case. An open ISA allows for real open chips and finally making real progress in that direction in terms of openness.

Re: “Risc V greatly underperforms”

#344

Post by andrekandre »

bitwize wrote: post #31
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.

  > all those extra instructions to compute carry will blow the I$ faster
i think the idea is, as others have mentioned, the add/comp instructions are fused internally to a single instruction, so probably its not that bad for i$ as we might think?

Re: “Risc V greatly underperforms”

#345

Post by brucehoult »

adrian_b wrote: post #318
FullyFunctional wrote: post #263

Earlier quoted context omitted.

> The compressed encoding has good code density, but low speed. That's 100% nonsense. They have the same performance and in fact, some pipelines can get better performance because they fetch a fixed number of bytes and with compressed instructions, that means more instructions fetched. The rest of the argument falls apart resting on this fallacy.

They have the same performance only in low performance CPUs intended for embedded applications. If you want to use a RISC-V at a performance level good enough for being used in something like a mobile phone or a personal computer, you need to simultaneously decode at least 8 instructions per clock cycle and preferably much more, because to match 8 instructions of other CPUs you need at least 10 to 12 RISC-V instructi…

You're just making stuff up.

ARM doesn't have any cores that do 8 wide decode. Neither do Intel or AMD. Apple has, but Apple is not ARM and doesn't share their designs with ARM or ARM customers.

Cortex X-1 and X-1 have 5 wide decode. Cortex A78 and Neoverse N1 have 4 wide decode.

ARM uses compressed encoding in their 32 bit A-series CPUs, for example the Cortex A7, A15 and so on. The A15 is pretty fast, running at up to 2.5 GHz. It was used in phones such as the Galaxy S4 and Note 3 back before 64 bit became a selling point.

Several organisations are making wide RISC-V implementations. Most of them aren't disclosing what they are doing, but one has actually published details of how it's 4-8 wide RISC-V decoder works -- they decode 16 bytes of code at a time, which is 4 instructions if they are all 32 bit instructions, 8 instructions if they are all 16 bit instructions, somewhere between for a mix.

https://github.com/MoonbaseOtago/vroom

Everything is there, in the open, including the GPL licensed SystemVerilog source code. It's not complex. The decode scheme is modular and extensible to as wide as you want, with no increase in complexity, just slightly longer latency.

There are practical limits to how wide is useful not because you can't build it, but because most code has a branch every 5 or 6 instructions on average. You can build a 20-wide machine if you want -- it just won't be any faster because it doesn't fit most of the code you'll be executing.

Re: “Risc V greatly underperforms”

#346

Post by ddingus »

panick21_ wrote: post #343
ddingus wrote: post #342

Earlier quoted context omitted.

Again, I ask: Unified, or something else? Having a "majority" isn't really different from what we have now, and it includes the downside of a more robust monoculture. And to be clear here, I'm not anti RISC-V. I am very highly skeptical, given how frequently we see things like code size critics responded to with 'but it will be faster', which isn't really an answer, The same thing happened here. Hand wavy "the market…

Not having the definition being controlled by a company, being and open specification and the whole ecosystem and tooling from the ground up being designed around a fully modular instruction set with use-case specific profiles that can evolve independently is very different then what we have now. > Finally, "the goal" is really "a goal or vision" as expressed by proponents. It's not really one in the objective sense.…

I agree with the latter portion, and that's the part I like about RISC-V the most.

Just wish some of the choices were made differently. Open could be open and amazing. We are likely to get open with a bit of hobbling built in early on, and that makes me wonder.

This discussion is much improved over the initial, "unified, but..." one we started with.

Re: “Risc V greatly underperforms”

#347

Post by R0b0t1 »

kortex wrote: post #328
phkahler wrote: post #238

Earlier quoted context omitted.

>> But ultimately, the gist of their argument is this... Funny, I thought the whole thing was bitching that RISC V has no carry flag which obviously causes multi word arithmetic to take more instructions. The obvious workaround is to use half-words and use the upper half for carry. There may be better solutions, but at twice the number of instructions this "dumb" method is better than what the author did. Flags were…

So if I'm understanding this particular tussle correctly, carry flags are problematic for optimization because they create implicit mutable shared global state, which isn't necessarily reflected in the machine code. Risc-v basically says "lets make the implicit, explicit" and you have to essentially use registers to store the carry information when operating on bigints. Which for the current impl means chaining more…

There's more options than just a global carry flag, like a n+1th bit on each arithmetic register. Actually, that is how I assumed they would implement it.

Re: “Risc V greatly underperforms”

#348

Post by ansible »

imtringued wrote: post #307
ansible wrote: post #297

Earlier quoted context omitted.

> Any hardware adder provides almost for free the overflow detection output (at less than the cost of an extra bit, so less than 1/64 of a 64-bit adder). So anyone who thinks about an efficient hardware implementation would expose the overflow bit to the software. Ah, but where you do put that bit that you got for free? A condition codes register, global to the processor / core state? That worked terrific for single-…

I have no clue about flags but why not just store the flags with the register? Each register would have 32+r bits where r is the number of flags.

> I have no clue about flags but why not just store the flags with the register? Each register would have 32+r bits where r is the number of flags.

That sort of design can be done, but that just pushes the problem around. Let's look at the original ARM 64 bit code:

    adds  x12, x6, x10
    adcs  x13, x7, x11
The second add with carry uses the global carry bit, it isn't passed as an argument to the adcs instruction. So if you store the carry bit with the x12 register, you would then need to specify x12 in the adcs instruction on the next line. So you need a new instruction format for adcs that can specify four registers.

You could change the semantics, where the add instructions use one register as the source and the destination, like on x86-64, but that's a whole 'nother discussion on why that is and isn't done on various architectures.

Re: “Risc V greatly underperforms”

#349

Post by kragen »

amelius wrote: post #298
socialdemocrat wrote: post #288

Earlier quoted context omitted.

No, it is just part of the regular instruction decoding. It is not like it is zip compressed. It is just 400 logic gates added to the decoder… which is nothing.

Yes, but the logic signal needs to ripple through those gates, which takes time.

It potentially adds latency, but doesn't drop throughput.

Re: “Risc V greatly underperforms”

#350

Post by kragen »

adrian_b wrote: post #240
dragontamer wrote: post #110

Earlier quoted context omitted.

> The RISC-V ISA has only 1 good feature for code size, the combined compare-and-branch instructions. Because there typically is 1 branch for every 6 to 8 instructions, using 1 instruction instead of 2 saves a lot. Which isn't really a big advantage, because ARM and x86 macro-op fuse those instructions together. (That is, those 2-instructions are decoded and executed as 1x macro-op in practice). cmp /jnz on x86 is li…

The fusion influences only the speed, not the code size and the discussion was about the code size. For x86, cmp/jnz must be 5 bytes for short loops or 9 bytes for long loops, because the REX prefix is normally needed. x86 does not have address modes with auto-update, like ARM or POWER, so for a minimum number of instructions the loop counter must also be used as an index register, to eliminate the instructions for u…

I agree that this is about the code size, but you seem to be doing your back-of-the-envelope estimates based on RISC-V uncompressed instructions, which is a mistake and explains why your estimates came out with nonsense results like "code size larger than Intel/AMD".
Post reply on HN