151–160 of 365 posts
Earlier quoted context omitted.
Yeah but the code required for an overflow check is just one extra instruction (3 rather than 2)
For generalised signed addition, the overhead is 3 instructions per addition . It can be one in specific contexts where more is known about the operands (e.g. addition of immediates). It’s always 1 in x64/ARM64 as they have built-in support for overflow.
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…
> 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. Genuinely asking, why ? Do we think RISC-V should, or even could , try to compete against the AMD/Intel/ARM behemoths on their playing field? Obviously ISAs are a low level detail and far removed from the end product, but i…
Well, it's exactly what many RISC-V folks are trying to do. There's news about a new high performance RISC-V core on the HN front page right now!
> but it feels like the architectural decisions we are "stuck with" today are inextricably intertwined with their contemporary market conditions and historical happenstance. It feels like all the experimental architectures that lost to x86/ARM (including Intel's own) were simply too much too soon,
I just want to note that ARM64 was a mostly clean break from prior versions of ARM. Basically a clean slate design started in the late 2000s. It's a modern design built with the same hindsight and approximate market conditions available to the designers of RISC-V.
Earlier quoted context omitted.
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?
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.
So anyone who thinks about an efficient hardware implementation would expose the overflow bit to the software.
A hardware implementation that requires multiple additions to provide the complete result of a single addition can be called in many ways, but certainly not "efficient".
Few years ago, I designed my own ISA. In that time I investigated design decisions in lots of ISAs and compared them. There was nothing in the RISC-V instruction set that stood out to me, like for example, the SuperH instruction set, which is remarkably well designed. Edit: Don't get me wrong, I don't think RISC-V is "garbage" or anything like that. I just think it could have been better. But of course, most of an ar…
Not having anything that stands out is perhaps a good thing. Being "clever" with the ISA tends to bite you when implementing OoO superscalar cores.
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. Comparing apples to oranges doesn't really help.
From the article:
Let's look at some examples of how Risc V underperforms.
First, addition of a double-word integer with carry-out:
add t0, a4, a6 // add low words
sltu t6, t0, a4 // compute carry-out from low add
add t1, a5, a7 // add hi words
sltu t2, t1, a5 // compute carry-out from high add
add t4, t1, t6 // add carry to low result
sltu t3, t4, t1 // compute carry out from the carry add
add t6, t2, t3 // combine carries
Same for 64-bit arm:
adds x12, x6, x10
adcs x13, x7, x11
Same for 64-bit x86:
add %r8, %rax
adc %r9, %rdx
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.
I don't think there is anything preventing the processor to fuse those instructions into a single operation once they are decoded.
How does the instruction fusion work? It seems to be mentioned in the article and by a couple of other commenters.
The CPU has a frontend, which has a decoder, which is the part that "reads" the program instructions. When it "sees" certain pattern, like "instruction x to register r followed by instruction y consuming r", it can treat this "as if" it was a single instruction if the CPU has hardware for executing that single instruction (even if the ISA doesn't have a name for that instruction).
This allows the people that build the CPU to choose whether this is something they want to add hardware for. If they don't, this runs in e.g. 2 cycles, but if they do then it runs in 1. A server CPU might want to pay the cost of running it in 1 cycle, but a micro controller CPU might not.
Earlier quoted context omitted.
_For the purposes of implementing multi-word arithmetic_, which is Torbjörn's whole deal, it kind of does. (Also the actual post subject is "greatly underperforms").
It's meaningless to look at the code in absence an implementation and conclude anything about the performance. He doesn't know what the performance is. Having six instruction vs. two does not mean one is 3X faster than the other. It means nothing at all.
Earlier quoted context omitted.
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.
In fairness, this is Hacker News; flame wars^w^w respectful but intense debate over editors, operating systems, and, yes, ISA details, is somewhat expected. (Although, yes, I'm not sure that I would get too worked up about this particular detail; even if the stated claim is 100% true and unmitigated, it means some kinds of code will have potentially bigger binaries. I understand a math library person caring, I don't…
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...