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

201–210 of 365 posts

Re: “Risc V greatly underperforms”

#201

Post by adrian_b »

Dylan16807 wrote: post #138
yjftsjthsd-h wrote: post #46

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 would say that "underperforms" is indefensible from such a simple analysis that doesn't touch IPC. "Terrible" is at least openly an opinion.

The IPC was discussed.

It does not matter much, because there is a sequence of dependent instructions, which cannot be executed in parallel, regardless which is the maximum IPC of a RISC-V CPU.

The opinions from those messages matter, because they belong to experts in implementing operations with large integers on a lot of different CPU architectures, with high performance proven during decades of ubiquitous use of their code. They have certainly a better track record than any RISC-V designer.

Re: “Risc V greatly underperforms”

#202

Post by veltas »

SavantIdiot wrote: post #48

A bit off topic, but when did a DWORD implicitly become 64bits?

Lots of ISAs consider 32-bit to be a 'word'. And now they have the same problem that Intel already encountered that it's easier to start referring to a new larger native word size as a 'double-word' and the cycle continues...

Re: “Risc V greatly underperforms”

#203

Post by zik »

dragontamer wrote: post #52

Hmmm... I think this argument is solid. Albeit biased from GMP's perspective, but bignums are used all the time in RSA / ECC, and probably other common tasks, so maybe its important enough to analyze at this level. 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 instructio…

GMP is basically a worst-case example since it uses a lot of overflow. The RISC-V architecture has been extensively studies and for most cases it's a little more dense than (say) ARM when compared like-for-like.

Re: “Risc V greatly underperforms”

#204

Post by pcwalton »

monocasa wrote: post #79
pcwalton wrote: post #66

Earlier quoted context omitted.

Sure, but this email is in the context of GMP, which should be using the vector extension, no?

I don't think so; most of the users I know of for the integer side of GMP are compilers/runtimes. An apt rdepends on the gmp packages in Ubuntu only shows stuff like ocaml, and I know gcc vendors it. 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 intege…

I'm a bit confused. First, JavaScript doesn't use bignum arithmetic much. JS Numbers are doubles. JavaScript JITs do speculatively use integers where possible, but this workload doesn't need add-with-carry, just efficient overflow detection (which is a problem with RISC-V, but not the problem we're discussing here). It could be a problem for Lisp and ML, but these are hardly common languages.

And as for crypto, couldn't you use the vector registers to do scalar ops?

Re: “Risc V greatly underperforms”

#205

Post by sophacles »

rbanffy wrote: post #93
ksec wrote: post #68

The unwritten rule of HN: You do not criticise The Rusted Holy Grail and the Riscy Silver Bullet.

Or, if you do, you'd better be absolutely right, or people will tear your argument to shreds.

It's a sad state - who wants to have their random inaccurate theory debunked by facts? Imagination land is way, way more fun.

Re: “Risc V greatly underperforms”

#206

Post by zamadatix »

hajile wrote: post #171
zamadatix wrote: post #108

Earlier quoted context omitted.

> Except for this good feature, the rest of the ISA is full of bad features What are your thoughts on the way RISC V handled the compressed instructions subset?

It's not too surprising. Load, store, move, add, subtract, shift, branch, jump. These are definitely the most common instructions used. Put it side-by-side with Thumb and it also looks pretty similar (thumb has a multiply instruction IIRC). Put it side-by-side with short x86 instructions accounting for the outdated ones and the list is pretty similar (down to having 8 registers). All in all, when old and new instruct…

It was more a question of the way it was handled (i.e. it's not a different mode and can be mixed) than what the opcode list looked like.

Re: “Risc V greatly underperforms”

#207

Post by monocasa »

pcwalton wrote: post #204
monocasa wrote: post #79

Earlier quoted context omitted.

I don't think so; most of the users I know of for the integer side of GMP are compilers/runtimes. An apt rdepends on the gmp packages in Ubuntu only shows stuff like ocaml, and I know gcc vendors it. 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 intege…

I'm a bit confused. First, JavaScript doesn't use bignum arithmetic much. JS Numbers are doubles. JavaScript JITs do speculatively use integers where possible, but this workload doesn't need add-with-carry, just efficient overflow detection (which is a problem with RISC-V, but not the problem we're discussing here). It could be a problem for Lisp and ML, but these are hardly common languages. And as for crypto, could…

JS numbers speculatively using integers in practice rely on the carry flag for cheap overflow bailout checks. Maybe if the overflow check didn't have the same problem, they'd look at that instead, but I don't see why they should have to switch if it doesn't gain them anything.

And there's tons of reasons why using one lane of vector units as scalar ops is an issue. Power, lack of ubiquitous vector units, their pipeline is commonly decoupled from the integer unit making branches goofy, etc.

Re: “Risc V greatly underperforms”

#209

Post by Taniwha »

brucehoult wrote: post #187
bpye wrote: post #169

Earlier quoted context omitted.

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.

The E version only has half as many registers

Re: “Risc V greatly underperforms”

#210

Post by bubblethink »

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…

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

Wait, if we are talking about actual ISA instructions, why is it hard to believe that RISC-V would have more of them ? The argument in favor of RISC is to simplify the frontend because even for a complex ISA like x86, the instructions will get converted to many micro-ops. In terms of actual ISA instructions, it seems quite reasonable that x86 would have fewer of those (at the cost of frontend complexity).

Post reply on HN