Christopher Celio, Palmer Dabbelt, David A. Patterson, Krste Asanović
2016 · arXiv
This report makes the case that a well-designed Reduced Instruction Set Computer (RISC) can match, and even exceed, the performance and code density of existing commercial Complex Instruction Set Computers (CISC) while maintaining the simplicity and cost-effectiveness that underpins the original RISC goals. We begin by comparing the dynamic instruction counts and dynamic instruction bytes fetched for the popular proprietary ARMv7, ARMv8, IA-32, and x86-64 Instruction Set Architectures (ISAs) against the free and open RISC-V RV64G and RV64GC ISAs when running the SPEC CINT2006 benchmark suite. RISC-V was designed as a very small ISA to support a wide range of implementations, and has a less mature compiler toolchain. However, we observe that on SPEC CINT2006 RV64G executes on average 16% more instructions than x86-64, 3% more instructions than IA-32, 9% more instructions than ARMv8, but 4% fewer instructions than ARMv7. CISC x86 implementations break up complex instructions into smaller internal RISC-like micro-ops, and the RV64G instruction count is within 2% of the x86-64 retired micro-op count. RV64GC, the compressed variant of RV64G, is the densest ISA studied, fetching 8% fewer dynamic instruction bytes than x86-64. We observed that much of the increased RISC-V instruction count is due to a small set of common multi-instruction idioms. Exploiting this fact, the RV64G and RV64GC effective instruction count can be reduced by 5.4% on average by leveraging macro-op fusion. Combining the compressed RISC-V ISA extension with macro-op fusion provides both the densest ISA and the fewest dynamic operations retired per program, reducing the motivation to add more instructions to the ISA. This approach retains a single simple ISA suitable for both low-end and high-end implementations, where high-end implementations can boost performance through microarchitectural techniques.
Metadata: arXiv. Abstracts retain their original authors’ rights.
Original HN comments, with labels from simple text rules. A label describes the whole comment and may miss context or irony. Read the discussion to make up your own mind. About the labels
11 selected excerpts · 11 total mentions
The ISA spec itself suggests one fusion - that of mul and mulh (lower and upper halves of n-bit * n-bit -> 2n-bit product). The only other source I know of was this 2016 paper that suggested specific macro fusions. https://arxiv.org/abs/1607.02318 This predates the B extension so some of those fusions are dedicated instructions now, but I suppose Xiangshan still implements them for the sake of software that was not compiled with B enabled.
https://arxiv.org/abs/1607.02318 is a widely cited paper that argues that simple and orthogonal ISA's are preferable, as fusion can fix up those common cases like more complicated addressing modes that other ISA's have in the base ISA.
Hmm, not even the Allwinner D1 or the SiFive P650? In https://news.ycombinator.com/item?id=29423006 Bruce Hoult says SiFive has been doing macro-op fusion in one case since the 7-series, and I think he's the one that implemented it. In https://news.ycombinator.com/item?id=29444322 "ruslan" links the original macro-op fusion stuff from 02016: https://riscv.org/wp-content/uploads/2016/07/Tue1130celio-fu... and https://arxiv.org/abs/1607.02318. Surprisingly, those present "shootout" results that are really just "effective dynamic instruction" counts and "dynamic byte" counts, ending in a "design proposal"; they don't seem to have simulated macro-op fusion at RTL level, much less in an FPGA or a MOSIS run.
That's true if you take the strict textbook definition of "RISC" and "CISC" but everyone has been saying for 10+ years that really isn't how things work anymore. ARM has pulled a lot of the "useful goodies" out of CISC ISAs and CISC ISAs have gone to RISC micro-ops internally on a lot of things. And x86-64 is really not all that dense anyway either. Also, a huge amount of instructions end up being used very little, there are a few "hotspot" instructions that make up a huge percent of actual instructions executed. https://arxiv.org/pdf/1607.02318.pdf Measured code density on SPEC2006, ARMv8 has geomean 6% more instructions, and geomean 12% higher code size. But Apple…
designs use 4x the decoders-per-thread in their Performance Cores compared to Intel (8 decoders for 1 thread for Apple, vs 4 decoders for 2 threads for Intel). Apple's designs are targeting much, much higher decode performance even considering the lower density of ARM (4/1.06 = 3.77x as much "normalized decode performance per thread"). Which shouldn't be surprising as their IPC is around 3x of modern x86 processors as well according to Anandtech's work on M1. They aren't magic, the code runs about the same on their processors too, they're just designed for much wider layouts than x86 and using super deep re-ordering to get that performance into a single thread.
Risc-V, 64 bit w/ compressed instructions (strict subset of 32 bit instrs, freely intermix-able) is beating x86_64 right now in static and dynamic code size without vector extensions or anything fancy. With a few simple macro-op fusion pairs, it also comes right up to x86_64 in dynamic uOp count. https://arxiv.org/pdf/1607.02318.pdf
> Great question. I just so happen to have written a tech report on this very topic! https://arxiv.org/abs/1607.02318 . > Basically, performance should be identical between ARMv8 and RISC-V, given the RISC-V core implements macro-op fusion to combine things like pair loads together. Yeah, I drew my conclusions from your papers. :- ) I really should diversify my sources, I bring nothing to this exchange.
The ISA is going to have close to zero impact on a processor's performance. I actually wrote up another tech report on this topic (https://arxiv.org/abs/1607.02318). In short, you can rely on macro-op fusion to dynamically fuse some idioms that show up as instructions in other ISAs, like load-pair.
I think RISC-V is showing that RISC ISAs can still compete in this space: https://arxiv.org/pdf/1607.02318v1.pdf. RISC-V has extensibility of the ISA as a core feature, allowing for special-purpose accelerators and coprocessors as needed.
I guess the "even more important" thing you're thinking of is https://arxiv.org/abs/1607.02318 ? So with RISC-V GC + macro fusion of a few common idioms you get slightly less micro-ops than x86-64, armv7, or armv8. That being said, for high-performance cores such as Skylake, POWER9, or the latest aarch64 server cores the ISA probably doesn't matter that much.
> Chris, I worked hard to get you on that pedestal, don't go jumping off. ;- ) O:-) > ARM[v7] maybe does a little bit more per instruction, what with those conditions and 14+ character non-mnemonic mnemonics; but ultimately instruction counts should be pretty close, right? Great question. I just so happen to have written a tech report on this very topic! https://arxiv.org/abs/1607.02318 Basically, performance should be identical between ARMv8 and RISC-V, given the RISC-V core implements macro-op fusion to combine things like pair loads together.
I'd like to know what the problem was with ARM's ISA that presented problems for superscalar. Load/store multiple, for starters. Even just load-pair-increment-address is a pain as it requires 3 write ports. https://arxiv.org/pdf/1607.02318.pdf
More from the same topics.
Haoran Xu, Fredrik Kjolstad
Fast compilation is important when compilation occurs at runtime, such as query compilers in modern database systems and WebAssembly virtual machines in modern browsers.
Scott Aaronson
In honor of Alan Turing's hundredth birthday, I unwisely set out some thoughts about one of Turing's obsessions throughout his life, the question of physics and free will.
Tamara M. Davis, Charles H. Lineweaver
We use standard general relativity to illustrate and clarify several common misconceptions about the expansion of the Universe.
Ross Mcilroy, Jaroslav Sevcik, Tobias Tebbi +2
The recent discovery of the Spectre and Meltdown attacks represents a watershed moment not just for the field of Computer Security, but also of Programming Languages.