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.
“Risc V greatly underperforms”
271–280 of 365 posts
Re: “Risc V greatly underperforms”
#272> 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…
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”
#273Earlier 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…
Re: “Risc V greatly underperforms”
#274Earlier 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.
Section 2.4, https://riscv.org/wp-content/uploads/2017/05/riscv-spec-v2.2...
Re: “Risc V greatly underperforms”
#275Earlier 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.
Re: “Risc V greatly underperforms”
#276> 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…
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”
#277Hmmm... 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…
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”
#278Earlier 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.
Re: “Risc V greatly underperforms”
#279Earlier 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.