“Risc V greatly underperforms” • Hacker News Board

Re: “Risc V greatly underperforms”

#181

Post by [deleted] » Thu, Dec 02, 2021, 10:21 PM UTC

adrian_b wrote: post #96

snvzz wrote: post #34

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…

I am sorry but saying that RISC-V is a winner in code density is beyond ridiculous. I am familiar with many tens of instruction sets, since the first computers with vacuum tubes until all the important instruction sets that are still in use, and there is no doubt that RISC-V requires more instructions and a larger code size than almost all of them, for doing any task. Even the hard-to-believe "research" results publi…

[deleted]

Re: “Risc V greatly underperforms”

#182

Post by oneplane » Thu, Dec 02, 2021, 10:22 PM UTC

All of the discussions about instruction sets and "mine is better than yours" or "anyone else could do better in a small amount of time" are useless considering those arguments, if true, haven't actually resulted in any free ISA being available broadly, embraced broadly and hardware implementing that ISA being available.

It doesn't matter how great something else could be in theory if it doesn't exist or doesn't meet the same scale and mindshare (or adoption).

Re: “Risc V greatly underperforms”

#183

Post by seoaeu » Thu, Dec 02, 2021, 10:23 PM UTC

jasonhansel wrote: post #175

theresistor wrote: post #102

Earlier quoted context omitted.

As someone who is an expert on ISA and CPU internals, this meme of "X86 has an internal RISC" is an over-simplification that obscures reality. Yes, it decodes instructions into micro-ops. No, micro-ops are not "quite close to the RISC-V ISA". Macro fusion definitely has a place in microarchitecture performance, especially when you have to deal with a legacy ISA. RISC-V makes the very unusual choice of depending on it…

Indeed. Also not an expert, but relying on macro-op fusion in hardware is tricky IIRC since different implementors will (likely) choose different macro-ops, resulting in strange performance differences between otherwise-identical chips. Of course, you could start documenting "official" macro-ops that implementations should support, but at that point you're pretty much inventing a new ISA...

RISC-V does document "official" macro-ops that implementations are encouraged to support.

Re: “Risc V greatly underperforms”

#184

Post by adrian_b » Thu, Dec 02, 2021, 10:24 PM UTC

crest wrote: post #106

classichasclass wrote: post #9

Earlier quoted context omitted.

So do what Power does: most instructions that update the condition flags can do so optionally (except for instructions like stdcx. or cmpd where they're meaningless without it, and corner oddballs like andi.). For that matter, Power treats things like overflow and carry as separate from the condition register (they go in a special purpose register), so you can issue an instruction like addco. or just a regular add wi…

IIRC few Power(PC) cores really split the condition register nibbles into 8 renamable registers and while Power(PC) includes everything (including at least two spare kitchen sinks) only a few instructions can pick which condition register nibble to update. Most integer instructions can only update cr0 and floating point instructions cr1. On the other hand you can do nice hacks with the cornucopia of bitwise available…

On POWER, all the comparison instruction can store their result in any of the 8 sets of flags. The conditional branches can use any flag from any set.

The arithmetic instructions, e.g. addition or multiplication, do not encode a field for where to store the flags, so they use, like you said, an implicit destination, which is still different for integer and floating-point.

In large out-of-order CPUs, with flag register renaming, this is no longer so important, but in 1990, when POWER was introduced, the multiple sets of flags were a great advance, because they enabled the parallel execution of many instructions even in CPUs much simpler than today.

Besides POWER, the 64-bit ARMv8 also provides most of the 14 predicates that exist for a partial order relation. For some weird reason, the IEEE FP standard requires only 12 of the 14 predicates, so ARM implemented just those 12, even if they have 14 encodings, by using duplicate encodings for a pair of predicates.

I consider this stupid, because there would not have been any additional cost to gate correctly the missing predicate pair, even if it is indeed one that is only seldom needed (distinguishing between less-or-greater and equal-or-unordered).

Re: “Risc V greatly underperforms”

#185

Post by brutal_chaos_ » Thu, Dec 02, 2021, 10:25 PM UTC

volta83 wrote: post #166

jhallenworld wrote: post #136

What if the multi-precision code is written in C? You can detect carry of (a+b) in C branch-free with: ((a&b) | ((a|b) & ~(a+b))) >> 31 So 64-bit add in C is: f_low = a_low + b_low c_high = ((a_low & b_low) | ((a_low | b_low) & ~f_low)) >> 31 f_high = a_high + b_high + c_high So for RISC-V in gcc 8.2.0 with -O2 -S -c add a1,a3,a2 or a5,a3,a2 not a7,a1 and a5,a5,a7 and a3,a3,a2 or a5,a5,a3 srli a5,a5,31 add a4,a4,a6 a…

> RISC-V is faster.. I find it funny that you make the same pitfall than the author did. Faster on which CPU? The author doesn't measure on any CPU, so here there are dozens of people hypothesizing whether fusion happens or not, and what the impact is.

> Faster on which CPU?

Perhaps faster means fewer instructions in this instance? Considering number of instructions is what has been discussed.

Re: “Risc V greatly underperforms”

#186

Post by avianes » Thu, Dec 02, 2021, 10:31 PM UTC

snvzz wrote: post #139

adrian_b wrote: post #126

Earlier quoted context omitted.

Instruction fusion is the magical rescue invoked by all those who believe that the RISC-V ISA is well designed. Instruction fusion has no effect on code size, but only on execution speed. For example RISC-V has combined compare-and-branch instructions, while the Intel/AMD ISA does not have such instructions, but all Intel & AMD CPUs fuse the compare and branch instruction pairs. So there is no speed difference, but t…

>Unfortunately for RISC-V, this is the only example favorable for it, because for a large number of ARM or Intel/AMD instructions RISC-V needs a pair of instructions or even more instructions. Yet, as many pointed out to you already, RISC-V has the highest code density of all contemporary 64bit architectures. And aarch64, which you seem to like, is beyond bad. >but it is the only way available for RISC-V to match the…

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 criticism about RISC-V. The article, which seems to be enjoyed by the HN audience, literally says: "I believe that an average computer science student could come up with a better instruction set that Risc V in a single term project". How can anyone say such a thing about a collaborative project of more than 10 years, fed by many scientific works and projects and many companies in the industry?

I do not mean that RISC-V is perfect, there are some points which are source of debate (e.g. favoring a vector extension rather than the classic SIMD is a source of interesting discussion). But I would appreciate on HN to read better analysis and more interesting discussions.

Re: “Risc V greatly underperforms”

#187

Post by brucehoult » Thu, Dec 02, 2021, 10:31 PM UTC

bpye wrote: post #169

Taniwha wrote: post #123

Earlier quoted context omitted.

The main distinction is that the 16-bit RISCV-C ISA exactly maps to existing 32-bit RISCV instructions, its implementation only occurs in the decode pipe stage

The C extension is that, an extension. A RISC-V core with the C extension should still support the long encoding as well. There is no 16-bit variant specified, only 32, 64 and 128. There is an E version of the ISA with a reduced register set, but this is a separate thing.

You are mixing up integer register size and instruction length.

RISC-V has variants with 32 bit, 64 bit, or (not yet fully specified or implemented) 128 bit registers.

RISC-V has instructions of length 32 bits and, optionally but almost universally, 16 bit length.

Re: “Risc V greatly underperforms”

#188

Post by adrian_b » Thu, Dec 02, 2021, 10:34 PM UTC

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, i.e. on all architectures supported by gcc, and for most of those architectures libgmp has been the fastest during many years, or it still is the fastest.

Re: “Risc V greatly underperforms”

#189

Post by kelnos » Thu, Dec 02, 2021, 10:35 PM UTC

> My conclusion is that Risc V is a terrible architecture.

Kinda stopped reading here. It's a pretty arrogant hot take. I don't know this guy, maybe he's some sort of ISA expert. But it strains credulity that after all this time and work put into it, RISC-V is a "terrible architecture".

My expectation here is that RISC-V requires some inefficient instruction sequences in some corners somewhere (and one of these corners happens to be OP's pet use case), but by and large things are fine.

And even then, I don't think that's clear. You're not going to determine performance just by looking at a stream of instructions on modern CPUs. Hell, it's really hard to compare streams of instructions from different ISAs.

Re: “Risc V greatly underperforms”

#190

Post by panick21_ » Thu, Dec 02, 2021, 10:35 PM UTC

adrian_b wrote: post #147

api wrote: post #77

Earlier quoted context omitted.

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…

> 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.

This is non-sense. You can still do everything you need. Its just that in some cases the code size is a bit bigger or smaller.

And the difference with compressed instruction is not nearly as big, if you add fusion the difference is marginal.

So really its not a pathological case its 'its slightly worse' case and even that is hard to prove in the real world given the other benefit RISC-V brings that compensate.

And we can find 'slightly worse case' in the opposite direction if we would go looking for them.

If you gave 2 equal skilled teams 100M and told them to make the best possible personal computer chip, I would bet on the RISC-V team winning 90 times out of a 100.