71–80 of 365 posts
TL;DR RISC-V doesn't have add with carry. I'm not a fan of the RISC-V design but the presence or absence of this instruction doesn't make it a terrible architecture.
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 n…
So how would you suggest re-writing their example in less than 6 instructions for RISC-V? X86/arm both have instructions that include the carry operation for long additions, and only require 2 instructions.
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).
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 move on.
The big pain points in perf optimization for JS is objects and their representation, functions and their various type-specializations.
Another factor is that JS impls use int32s as their internal integer representation, so there should be some relatively straightforward approach involving lifting to int64s and testing the high half for overflow.
Still kind of cumbersome.
There are similar issues in existing ISAs. NaN-boxing for example uses high bits to store type info for boxed values. Unboxing boxed values on amd64 involves loading an 8-byte constant into a free register and then using that to mask out the type. The register usage is mandatory because you can't use 64-bit values as immediates.
I remember trying to reduce code size and improve perf (and save a scratch register) by turning that into a left-shift right-shift sequence involving no constants, but that led to the code executing measurably slower as it introduced data dependencies.
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/...
https://www2.eecs.berkeley.edu/Pubs/TechRpts/2016/EECS-2016-...
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 n…
So how would you suggest re-writing their example in less than 6 instructions for RISC-V? X86/arm both have instructions that include the carry operation for long additions, and only require 2 instructions.
https://en.wikipedia.org/wiki/Reduced_instruction_set_comput...
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 n…
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 there's a heavy burden of proof to demonstrate that making the contrary decisions in many cases was the right call.
> 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.
This doesn't seem to be true when you actually do an apples-to-apples comparison.
Taking as an example the build of Bash in Debian Sid (https://packages.debian.org/sid/shells/bash). I chose this because I'm pretty confident there's no functional or build-dependency difference that will be relevant here. Other examples like the Linux kernel are harder to compare because the code in question is different across architectures. I saw the same trend in the GCC package, so it's not an isolated example.
riscv64 installed size: 6,157.0 kB amd64 installed size: 6,450.0 kB arm64 installed size: 6,497.0 kB armhf installed size: 6,041.0 kB
RV64 is outperforming the other 64-bit architectures, but under-performing 32-bit ARM. This is consistent with expectations: amd64 has a size penalty due to REX bytes, arm64 got rid of compressed instructions to enable higher performance, and armhf (32-bit) has smaller constants embedded in the binary.
Compressed instructions definitely do work for making code smaller, and that's part of why arm32 has been very successful in the embedded space, and why that space hasn't been rushing to adopt arm64. For arm32, however, compressed instructions proved to be a limiting factor on high performance implementation, and arm64 moved away from them because of it. Maybe that's due to some particular limitations of arm32's compressed instructions that RISC-V compressed instructions won't suffer from, but that remains to be proven.
Earlier quoted context omitted.
So how would you suggest re-writing their example in less than 6 instructions for RISC-V? X86/arm both have instructions that include the carry operation for long additions, and only require 2 instructions.
Any != All. There is a difference between synthetic benchmarks and real world test cases.
The original title was "Risc V greatly underperforms", which seems like a far more defensible and less inflammatory claim than "Risc V is a terrible architecture", which was picked from the actual message but still isn't the title.
I almost skipped this thread because of the flamebait title. This is a debate over CPU instruction set performance details, nobody is going to die.
Earlier quoted context omitted.
Afaict that's only for operations the vector register file. Most of the complaints about the lack of addc/subc are around how they're heavily used in JITs for languages that want to speculatively optimize multi precision arthimetic into the integer register file for their regular integer ops. JavaScript, a lot of Lisps, the MLs all fit into that space.
Sure, but this email is in the context of GMP, which should be using the vector extension, no?
Edit: Another place you see this kind of arthimetic is crypto, but those specific use cases (Diffie Hellman, RSA, a few others) don't tend to be vectorized. You have one op you're trying to work through with large integers, and there's the carry dependency on each partial op. The carry depdent crypto algorithms aren't typically vectorisable.
Earlier quoted context omitted.
So how would you suggest re-writing their example in less than 6 instructions for RISC-V? X86/arm both have instructions that include the carry operation for long additions, and only require 2 instructions.
I don't even see the issue. RISC-V is supposed to be a RISC-type ISA. It's in the very name. That it takes more instructions when compared to a CISC-type ISA like x86 is completely normal. https://en.wikipedia.org/wiki/Reduced_instruction_set_comput...