51–60 of 365 posts
Why do these half baked slam pieces always make it to the top of HN?
Yeah. I'm not qualified to judge the quality of an instruction set, but this writer destroyed all credibility with me by claiming that an undergraduate could design a better architecture (than this enormous collective effort) in a term. It's right up there with claiming you could create Spotify in a weekend or whatever.
2-instructions to work with 64-bits, maybe 1 more instruction / macro-op for the compare-and-jump back up to a loop, and 1 more instruction for a loop counter of somekind?
So we're looking at ~4 instructions for 64-bits on ARM/x86, but ~9-instructions on RISC-V.
The loop will be performed in parallel in practice however due to Out-of-order / superscalar execution, so the discussion inside the post (2 instruction on x86 vs 7-instructions on RISC-V) probably is the closest to the truth.
----------
Question: is ~2-clock ticks per 64-bits really the ideal? I don't think so. It seems to me that bignum arithmetic is easily SIMD. Carries are NOT accounted for in x86 AVX or ARM NEON instructions, so x86, ARM, and RISC-V will probably be best.
I don't know exactly how to write a bignum addition loop in AVX off the top of my head. But I'd assume it'd be similar to the 7-instructions listed here, except... using 256-bit AVX-registers or 512-bit AVX512 registers.
So 7-instructions to perform 512-bits of bignum addition is 73-bits-per-clock cycle, far superior in speed to the 32-bits-per-clock cycle from add + adc (the 64-bit code with implicit condition codes).
AVX512 is uncommon, but AVX (256-bit) is common on x86 at least: leading to ~36-bits-per-clock tick.
----------
ARM has SVE, which is ambiguous (sometimes 128-bits, sometimes 512-bits). RISC-V has a bunch of competing vector instructions.
..........
Ultimately, I'm not convinced that the add + adc methodology here is best anymore for bignums. With a wide-enough vector, it seems more important to bring forth big 256-bit or 512-bit vector instructions for this use case?
EDIT: How many bits is the typical bignum? I think add+adc probably is best for 128, 256, or maybe even 512-bits. But moving up to 1024, 2048, or 4096 bits, SIMD might win out (hard to say without me writing code, but just a hunch).
2048-bit RSA is the common bignum, right? Any other bignums that are commonly used? EDIT2: Now that I think of it, addition isn't the common operation in RSA, but instead multiplication (and division which is based on multiplication).
Earlier quoted context omitted.
Interesting! From which perspective? Implementing the ISA, compiler or applications? Did you write machine language or compiled?
Mainly system level and higher, but a bit of all three, I suppose. I was helping reverse engineer a customized SH chip and ended up implementing a small VM and optimized system libraries/utilities afterwards. Most of the time was spent in assembly, with some machine code and C on either side.
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.
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).
They provide recommended insn sequences for overflow checking as commentary to the ISA specification, and this enables efficient implementation in hardware.
I would like to see some benchmarks of this efficient implementation in hardware, even simulated hardware, compared against conventional architectures.
Even for C, it's a recurring source of bugs and vulnerabilities that int overflow goes undetected. What we really need is an overflow trap like the one in IEEE floating point. RISC-V went the opposite direction.
Why do these half baked slam pieces always make it to the top of HN?
Yeah. I'm not qualified to judge the quality of an instruction set, but this writer destroyed all credibility with me by claiming that an undergraduate could design a better architecture (than this enormous collective effort) in a term. It's right up there with claiming you could create Spotify in a weekend or whatever.
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…
MIPS is classical RISC design that was not designed to be OoO-friendly at all and is simply designed for ease of straightforward pipelined implementation. The reason why it does not have flags probably simply comes down to the observation that you don't need flags for C.
TL;DR My code snippet results in bloated code for RISC-V RV64I. I'm not sure how bloated it is. All of those instructions will compress [1]. [1] https://riscv.org/wp-content/uploads/2015/05/riscv-compresse... It's slower on RISC-V but not a lot on a superscalar. The x86 and ARMv8 snippets have 2 cycles of latency. The RISC-V has 4 cycles of latency. 1. add t0, a4, a6 add t1, a5, a7 2. sltu t6, t0, a4 sltu t2, t1, a5…
CPU performance increases nowadays often are measured in single digit percentages because the margins became so thin. Doubling the cycles is a 100% increase. You can call that not so bloated, but I think many people would beg to differ. On the other hand I take this article with a grain of salt anyhow, since it only discusses a single example. I think we would need a lot more optimized assembly snippet comparisons to…
>"here's this snippet, it takes more instructions on RISC-V, thus RISC-V bad"
Is pretty much what it's saying. An actual argument about ISA design would weight the cost this has with the advantages of not having flags, provide a body of evidence and draw conclusions from it. But, of course, that would be much harder to do.
What's comparatively easy and they should have done, however, is to read the ISA specification. Alongside the decisions that were made, there's a rationale to support it. Most of these choices, particularly so the ones often quoted in FUD as controversial or bad, have a wealth of papers, backed by plentiful evidence, behind them.
I think talking about ISAs as better or worse than one another is often a bad idea for the same reason that arguing about whether C or Python is better is a bad idea. Different ISAs are used for different purposes. We can point to some specific things as almost always being bad in the modern world like branch delay slots or the way the C preprocessor works but even then for widely employed languages or ISAs there was…
Branch delay slots are an artifact of a simple pipeline without speculation. There's nothing inherently "bad" about them.