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

311–320 of 365 posts

Re: “Risc V greatly underperforms”

#311

Post by imtringued »

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…

Let's assume you are right. In 5 years the organization behind RISC-V apologizes and introduces a "bignum" extension. That doesn't sound too bad.

Re: “Risc V greatly underperforms”

#312

Post by imtringued »

anarazel wrote: post #39
Buttons840 wrote: post #36

Earlier quoted context omitted.

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.

Obtaining the carry bit does not involve branches though. Overflow checking probably does.

Re: “Risc V greatly underperforms”

#313

Post by dlsa »

adrian_b wrote: post #188
dlsa wrote: post #156

I noticed high and low in there so those code snippets look like 32 bit code, at least to me. Is that even a fair comparison given the arm and x86 versions used as examples of "better" were 64 bit? If we're really comparing 32 and 64 and complaining that 32 bit uses more instructions than 64, perhaps we should dig out the 4 bit processors and really sharpen the pitchforks. Alternatively, we could simply not. Comparin…

The comparison is completely fair, because on RISC-V there is no better way to generate the carries required for computations with large integers. You cannot generate a carry with a 64-bit addition, because it is lost and you cannot store it. You should take into account that the libgmp authors have a huge amount of experience in implementing operations with large integers on a very large number of CPU architectures,…

So the 32 bit code and the 64 bit code is equally inefficient in your opinion?

Re: “Risc V greatly underperforms”

#314

Post by DeathArrow »

socialdemocrat wrote: post #195

RISC V is an opinionated architecture and that is always going to get some people fired up. Any technology that aims for simplicity has to make hard choices and trade offs. It isn’t hard to complain about missing instructions when there are less than 100 of them. Meanwhile nobody will complain about ARM64 missing instructions because it had about 1000 of them. Therein lies the problem. Nobody ever goes out guns blazi…

I remember Jim Keller saying that for every ISA just 7 or 8 instructions are important and they are used for like 99% of the code. Load, store and the like.

Re: “Risc V greatly underperforms”

#315

Post by [deleted] »

titzer wrote: post #296
aidenn0 wrote: post #281

Earlier quoted context omitted.

Common Lisp will often have auxiliary return values that are often not needed (e.g. the mathematical floor function returns the remainder as a second value). Unused extra values are silently discarded. So you can do, for example (+ (floor x y) z) without worrying about the second value to floor. A lisp compiler for a register machine will usually return the first N values in registers (for some small value of N), so…

Return values are pushed onto the Wasm operand stack in left-to-right order. Engines use registers for params/returns up to a point in optimized code and then spill to the stack. So at the call site you can just drop the return values you don't want and should end up with machine code that does exactly what you want.

[deleted]

Re: “Risc V greatly underperforms”

#317

Post by michaelt »

bArray wrote: post #244

> I believe that an average computer science student could come up with a better instruction set that Risc V in a single term project. When you hear the " could make a better in " - call them out. Do it. The world will not shun a better open license ISA. We even have some pretty awesome FPGA boards these days that would allow you to prototype your own ISA at home. In terms of the market - now is an exceptionally grea…

> Do it. The world will not shun a better open license ISA.

When you use a CPU architecture you don't just get an ISA.

You also get compilers and debuggers. Ready-to-run Linux images. JIT compilers for JavaScript and Java. Debian repos and Python wheels with binaries.

And you get CPUs with all the most complex features. Instruction re-ordering, branch prediction, multiple cores, multi-level caches, dynamic frequency and voltage control. You want an onboard GPU, with hardware 4k h264 encoding and decoding? No problem.

And you get a wealth of community knowledge - there are forum posts and StackOverflow questions where people might have encountered your problems before. If you're hiring, there are loads of engineers who've done a bit of stuff with that architecture before. And of course vendors actually making the silicon!

I've seen ISAs documented with a single sheet of A4 paper. The difficult part in having a successful CPU architecture is all the other stuff :)

Re: “Risc V greatly underperforms”

#318

Post by adrian_b »

FullyFunctional wrote: post #263
adrian_b wrote: post #239

Earlier quoted context omitted.

The compressed encoding has good code density, but low speed. The compressed RISC-V encoding must be compared with the ARMv8-M encoding not with the ARMv8-A. The base 32-bit RISC-V encoding may be compared with the ARMv8-A, because only it can have comparable performance. All the comparisons where RISC-V has better code density compare the compressed encoding with the 32-bit ARMv8-A. This is a classical example of ap…

> 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 instructions and sometimes much more.

Nobody has succeeded to simultaneously decode a significant number of compressed RISC-V instructions and it is unlikely that anyone would attempt this, because the cost in area and power of a decoder able to do this is much larger than the cost of a decoder for simultaneous decoding of fixed-length instructions.

This is the reason why also ARM uses a compressed encoding in their -M CPUs for embedded applications but a 32-bit fixed-length encoding in their -A CPUs for applications where more than 1 watt per core is available and high performance is needed.

Re: “Risc V greatly underperforms”

#320

Post by avianes »

imtringued wrote: post #299
avianes wrote: post #186

Earlier quoted context omitted.

I see that you are pretty active here in debunking anti-RISC-V attacks, thanks for that! There are a bunch of poor criticisms about RISC-V. > This is something you've been told elsewhere in the discussion, but that you chose to ignore, for reasons unknown. I would call it RISC-V bashing. Everyone loves to hate RISC-V, probably because it's new and heavily hyped. It is really common to see irrelevant and uninformed cr…

The more I think about CPU implementations the more I think that what RISC-V is doing isn't as bad as many people think. Everyone is going "more instructions = worse". But the truth is that if you can build a CPU that fetches an infinite number of instructions per cycle, your biggest bottleneck isn't going to be the number of instructions, it's going to be unpredicted branches, jumps and function calls because fetchi…

> But the truth is that if you can build a CPU that fetches an infinite number of instructions per cycle, your biggest bottleneck isn't going to be the number of instructions, it's going to be unpredicted branches

Note that: Within Superscalar processors a group of instructions that are decoded at the same cycle is called a decoding group.

Branching is a problem, but the branch predictors do an excellent job. (especially for function calls which are very well predicted by the RAS [Return Address Stack]) But the biggest bottleneck to fetch a large instruction group is decoding.

Especially the instruction size decoding. An ISA like RISC-V or ARM that drastically reduces the possible instruction sizes is a big advantage to decode large instruction groups.

And dependencies between instructions within the decoding group is also a concern. For example, register renaming will quickly require several cycles (several stages) when the decoding group scales up. RISC-V also addresses this since the register indexes are easily decoded earlier and the number of registers used can also be quickly decoded.

And you're right, these are topics that are rarely addressed by RISC-V detractors.

Post reply on HN