Live data from Hacker News

“Risc V greatly underperforms”

gmplib.org

271–280 of 365 posts

Re: “Risc V greatly underperforms”

#271
Inside AI you have all these standard data sets (ImageNet, MNIST etc.) that act as a benchmark for how well an algorithm performs within a given area (character recognintion, image recognintion etc.).

Perhaps something similar is needed within ISAs / CPUs ? Say an OS kernel, a ZIP-algorithm, Mandelbrot, Fizz-buzz ... could measure code compactness but also performance and energy usage.

Re: “Risc V greatly underperforms”

#272
post #244

> I believe that an average computer science student could come up with a better instruction set that Risc V in a single term project. When you hear the " could make a better in " - call them out. Do it. The world will not shun a better open license ISA. We even have some pretty awesome FPGA boards these days that would allow you to prototype your own ISA at home. In terms of the market - now is an exceptionally grea…

Yeah. I don't have a dog in this fight... I don't have strong opinions either way, and this is one of those arguments that will be settled by reality after some time goes by.

But the author making an argument like that...

> I believe that an average computer science student could come up with a better instruction set that Risc V in a single term project.

Pretty much blew their credibility. It's obviously wrong, and a sensible, fair person wouldn't write it.

Re: “Risc V greatly underperforms”

#273
post #260

Earlier quoted context omitted.

Over just the time I've been aware of things, there's been a constant positive feedback loop of "checked overflow isn't used by software, so CPU designers make it less performant" followed by "Checked overflow is less performant so software uses it less." I wish there was a way out. Language features are also often implemented at least partly because they can be done efficiently on the premiere hardware for the langu…

> WASM implemented return values in a way that was different from register hardware, and it makes efficient codegen of Common Lisp more challenging. This was brought to the attention of the committee while WASM was still in flux, and they (perhaps rightfully) decided CL was insufficiently important to change things. Can you refresh my memory here? What exactly is different about Wasm return values than any other func…

Common Lisp supports multiple value returns, which C doesn't. Go sort of does, though.

Re: “Risc V greatly underperforms”

#274

Earlier quoted context omitted.

The CPU executes the two (or more) dependent instructions "as if" they were one, e.g., in 1 cycle. 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 instructi…

Do RISC-V specs document which instruction combinations they recommend be fused? Sounds like the fused instructions are an implementation detail that must be well-documented for compiler writers to know to emit the magic instruction combinations.

For this specific case, yes, the RISC-V ISA document recommends instruction sequences for checking for overflow-- that are both amenable to fusion and are relatively high performing on implementations that don't fuse.

Section 2.4, https://riscv.org/wp-content/uploads/2017/05/riscv-spec-v2.2...

Re: “Risc V greatly underperforms”

#275
post #16

Earlier quoted context omitted.

Compressed instructions and macro-fusion aren't magical solutions. It's not always possible to convince the compiler to generate the magical sequence required, and it actually makes high-performance implementations (wide superscalar) more difficult thanks to the variable width decoding. Beyond that, compressed instructions are not a 1:1 substitute for more complex instructions, because a pair of compressed instructio…

In the context of gmp, people write architecture-specific assembly for the inner loop anyway. Besides that, you raise good points on sources of complexity. I’m waiting for the benchmarks once such developments have been incorporated. Everything else is guesswork.

If they didn't implement those benchmarks (at least in simulation, like they benchmarked everything else) before releasing the spec, then they have nothing but handwaving and wishful thinking in saying this issue can be solved by op fusion. The reality is that they optimized for 1980s-style C programming without noticing that this isn't the 1980s any more.

Re: “Risc V greatly underperforms”

#276
post #189

> 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 corne…

> 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". Seems quite balanced with all the other replies here which claim it's the best architecture ever whenever anyone says anything about it. I don't think its vector extensions would be good fo…

> Seems quite balanced with all the other replies here which claim it's the best architecture ever whenever anyone says anything about it.

RISC-V is pretty good. Probably slightly better for some things than ARM, and slightly worse for others. It's open, which is awesome, and the instruction set lends itself to extensions which is nice (but possibly risks the ecosystem fragmenting). Building really high performance RISC-V designs looks like it's going to rely on slightly smarter instruction decoders than we've seen in the past for RISCs, but it doesn't look insurmountable.

Re: “Risc V greatly underperforms”

#277

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…

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

add+adc should still be 64 bits per cycle. adc doesn't just add the carry bit, it's an add instruction which includes the usual operands, plus the carry bit from the previous add or adc.

Re: “Risc V greatly underperforms”

#278
post #260

Earlier quoted context omitted.

> WASM implemented return values in a way that was different from register hardware, and it makes efficient codegen of Common Lisp more challenging. This was brought to the attention of the committee while WASM was still in flux, and they (perhaps rightfully) decided CL was insufficiently important to change things. Can you refresh my memory here? What exactly is different about Wasm return values than any other func…

Common Lisp supports multiple value returns, which C doesn't. Go sort of does, though.

Wasm supports multiple value returns.

Re: “Risc V greatly underperforms”

#279
post #53

Earlier quoted context omitted.

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.

Thanks for your insight.

It's not really too unusual of a vantage point. SH was clean in some ways, but delay slots are annoying for anything that speculatively executes (which sets a bit of a performance ceiling without a lot of complexity), and more registers are generally better.
Post reply on HN