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

141–150 of 365 posts

Re: “Risc V greatly underperforms”

#141

Post by formerly_proven »

kannanvijayan wrote: post #73
sanxiyn wrote: post #6

Earlier quoted context omitted.

RISC-V designers optimized for C and found overflow flag isn't used much and got rid of it. It was the wrong choice: overflow flag is used a lot for JavaScript and any language with arbitrary precision integer (including GMP, the topic of OP).

It kind of chafed when I excitedly read the ISA docs and found that overflow testing was cumbersome. That said, I think it's less of an issue these days for JS implementors in particular. It might have mattered more back in the day when pure JS carried a lot of numeric compute load and there weren't other options. These days it's better to stow that compute code in wasm and get predictable reliable performance and mo…

> It kind of chafed when I excitedly read the ISA docs and found that overflow testing was cumbersome.

It just feels backwards to me to increase the cost of these checks in a time where we have realized that unchecked arithmetic is not a good idea in general.

Re: “Risc V greatly underperforms”

#142

Post by lonjil »

lottospm wrote: post #88
theresistor wrote: post #7

Earlier quoted context omitted.

This isn't an isolated case. RISC-V makes the same basic tradeoff (simplicity above all else) across the board. You can see this in the (lack of) addressing modes, compare-and-branch, etc. Where this really bites you is in workloads dominated by tight loops (image processing, cryptography, HPC, etc). While a microarchitecture may be more efficient thanks to simpler instructions (ignoring the added complexity of compr…

I'm not an expert on ISA and CPU internals, but an X86 instruction is not just "an instruction" anymore. Afaik, since the P6 arch Intel is using a fancy decoder to translate x86/-64 CISC into an internal RISC ISA (up to 4 u-ops per CISC instruction) and that internal ISA could be quite close to the RISC-V ISA for all I know. Instruction decoding and memory ordering can be a bit of nightmare on CISC ISAs and fewer mac…

Most commonly used x86_64 instructions decode to only 1 or 2 µops, thus often also just as "complex" as the original instructions.

Re: “Risc V greatly underperforms”

#143

Post by aidenn0 »

sanxiyn wrote: post #6
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…

RISC-V designers optimized for C and found overflow flag isn't used much and got rid of it. It was the wrong choice: overflow flag is used a lot for JavaScript and any language with arbitrary precision integer (including GMP, the topic of OP).

Over just the time I've been aware of things, there's been a constant positive feedback loop of "checked overflow isn't used by software, so CPU designers make it less performant" followed by "Checked overflow is less performant so software uses it less."

I wish there was a way out.

Language features are also often implemented at least partly because they can be done efficiently on the premiere hardware for the language. Then new hardware can make such features hard to implement.

WASM implemented return values in a way that was different from register hardware, and it makes efficient codegen of Common Lisp more challenging. This was brought to the attention of the committee while WASM was still in flux, and they (perhaps rightfully) decided CL was insufficiently important to change things.

I'm sure that people brought up the overflow situation to the RISC-V designers, and it was similarly dismissed. It's just unfortunate that legacy software is such a big driver of CPU features as that's a race towards lowest-common-denominator hardware.

Re: “Risc V greatly underperforms”

#144

Post by plorkyeran »

lvh wrote: post #122
vadfa wrote: post #85

Earlier quoted context omitted.

So when h266 or whatever comes out you can't watch video anymore because your cpu can't decode it in software even if it tried?

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.

Re: “Risc V greatly underperforms”

#145

Post by Dylan16807 »

lonjil wrote: post #129
snvzz wrote: post #120

Earlier quoted context omitted.

Your statement does not run counter to mine quoted. Thumb-2 is better designed than Thumb was, but it is still a separate CPU mode. And it got far less use than it deserved, because of this. It doesn't do everything, and switching has a significant cost. This cost is in contrast with RISC-V's C extension.

The ARMv8-M profile is Thumb-only, so on ARM microcontroller platforms there is no switching at all, and it does do everything, or at least everything you might want to do on a microcontroller, and has of course gotten a very large amount of use, considering how widely deployed those cores are.

Is thumb-only particularly good for density, compared to being able to mix instruction sizes?

Re: “Risc V greatly underperforms”

#146

Post by audunw »

sanxiyn wrote: post #6
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…

RISC-V designers optimized for C and found overflow flag isn't used much and got rid of it. It was the wrong choice: overflow flag is used a lot for JavaScript and any language with arbitrary precision integer (including GMP, the topic of OP).

Which is exactly the right trade-off for embedded CPUs, where RISC-V is most popular right now.

If desktop/server-class RISC-V CPUs become more common, it's not unreasonable to think they'll add an extension that covers the needs of managed/higher-level languages like RISC-V.

Even for server-class CPUs you could argue that you absolutely want this extension to be optional, as you can design more efficient CPUs for datacenters/supercomputers where you know what kind of code you'll be running.

Re: “Risc V greatly underperforms”

#147

Post by adrian_b »

api wrote: post #77
vitno wrote: post #65

Earlier quoted context omitted.

Any != All. There is a difference between synthetic benchmarks and real world test cases.

So this person found a pathological case for the RISC-V instruction set?

This is not a pathological case, it is normal operation.

A computer is supposed to compute, but the RISC-V ISA does not provide everything that is needed for all the kinds of computations that exist.

The 2 most annoying missing features are the lack of support for multi-word operations, which are needed to compute with numbers larger than 64 bits, but also the lack of support for detecting overflow in the operations with standard-size integers.

If you either want larger integers or safe computations with normal integers, the number of RISC-V instructions needed for implementation is very large compared to any other ISA.

While there are people who do a lot of computations with large numbers, even the other users need such operations every day. Large number computations are needed at the establishment of any Internet connection, for the key exchange. For software developers, many compilers, e.g. gcc (which uses precisely libgmp), do computations with large numbers during compilation, for various kind of optimizations related to the handling of constants in the code, e.g. for sub-expression extraction or for operation complexity lowering.

So every time when some project is compiled, libgmp or other equivalent library for large numbers might be used, like also every time when you click on a new link in a browser.

So this case is not at all pathological, except in the vision of the RISC-V designers who omitted support for this case.

That was a good decision for an ISA intended only for teaching or for embedded computers, but it becomes a bad decision when someone wants to use RISC-V outside those domains, e.g. for general-purpose personal computers.

Re: “Risc V greatly underperforms”

#148

Post by justinpombrio »

adrian_b wrote: post #112
theresistor wrote: post #76

Earlier quoted context omitted.

> 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. It's perfectly possible to have read the spec and disagree with the rationale provided. RISC-V is in fact the outlier among ISAs in many of these design decisions, so ther…

The size of the files can be very misleading, because a large part of the files can be filled with various tables with additional information, with strings, with debugging information, with empty spaces left for alignment to page boundaries and so on. So the size of the installed files is not necessarily correlated with the code size. To compare the code sizes, you need tools like "size", "readelf" etc. and the data…

So (i) the research on RISC-V that shows it has dense code is bunk, and (ii) the fact that it compiles to a smaller binary is irrelevant, and (iii) it sounds like you're saying in advance that it might also have smaller code section sizes within the binary but that's irrelevant too.

And yet you're quite confident that RISC-V has poor code density. So you clearly have a source of knowledge that others don't. If it's a blog/article/research, could you share a link? If it's personal experimentation, you should write a blog post, I would totally read that.

Re: “Risc V greatly underperforms”

#149

Post by xondono »

Experimenting with RISC-V is one of those things I keep postponing.

For those are more versed, is this really a general problem?

I was under the impression that the real bottleneck is memory, and things like this would be fixed in real applications through out of order execution, and that it payed off having simpler instructions because compilers had more freedom to rearrange things.

Re: “Risc V greatly underperforms”

#150

Post by audunw »

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…

> and it actually makes high-performance implementations (wide superscalar) more difficult thanks to the variable width decoding.

More difficult than x86? We're talking about a damn simple variable width decoding here.

I could imagine RISC-V with C extension being more tricky than 64-bit ARM. Maybe.

> and again it complicates a high performance implementation.

But so much of the rationale behind the design of RISC-V is to simplify high performance implementation in other ways. So the big question is what the net effect is.

The other big question is if extensions will be added to optimise for desktop/server workloads by the time RISC-V CPUs penetrate that market significantly.

Post reply on HN