6 ms·

RISC-V is currently slow compared to modern CPUs

110 points by bhouston 2y ago

jl6 2y ago
Is it more that current RISC-V implementations are slow than the ISA being inherently slow?
- voxadam 2y ago
  The article addresses this question: "RISC-V implementations in the wild lack advanced features that modern CPUs rely on for speed, including sophisticated pipelining mechanisms, out-of-order execution capabilities, advanced branch prediction, and multi-tiered cache hierarchies. Most commercial RISC-V chips remain in-order processors, meaning they execute instructions sequentially rather than optimizing their order for performance. This architectural simplicity creates a fundamental performance ceiling that's difficult to overcome without significant architectural changes."
  - rwmj 2y ago
    This ignores two major server vendors, Rivos & Ventana (three if you include Qualcomm) who do have all those features.
    - bhouston 2y ago
      I am excited to see innovation come in this area. I wasn't saying that there won't be improvements or more innovation, just that the currently released chips are not performant.
    - Rochus 2y ago
      Are they included in https://browser.geekbench.com/search?q=RISC-V https://browser.geekbench.com/search?q=RISC-V? I dind't get any hits when searching e.g. for Rivos.
    - arp242 2y ago
      As I understand it, Rivos hasn't actually shipped anything; from https://www.rivosinc.com/technology https://www.rivosinc.com/technology: "Rivos has not yet revealed details of its products or technology publicly." Great that they're working on that, but when discussing the _current_ state of the RISC-V ecosystem, I think they can be safely ignored until such a time that they actually start shipping stuff. It seems Ventana has shipped the Veyron V1, but I'm having a hard time finding concrete information on that in a quick search (other than from Ventana themselves), so not entirely sure what the status of that is? Their V2 chip is planned for 2025.
  - jauntywundrkind 2y ago
    But these aren't Instruction Set Architecture (IS details. As mentioned in article, Berkeley's SonicBOOM is out of order. And you could certainly enhance the memory architecture with multi-level caches easily; the ISA is blind to this (consider how little x86 ISA has improved to tackle ever improving cache/memory strategies since i386). RISC-V is also extensible. So you can keep improving things! The incredibly awesome efficiency-foxused PULP group is working on a massive many-core research chip Occamy. It has huge vector processing units, many many many of them. Ok, so, promising. https://pulp-platform.org/occamy/ https://pulp-platform.org/occamy/ And they have their own extension, Semantic Streaming Registers, which add a very CISC-y set of instructions that combine real work and load/store (and incrementing the data pointer for the next loop), allowing DSP like performance in loops. Super super slick extension to massively increase the throughput, improve the ISA & reduce it's footprint in loops. https://arxiv.org/abs/1911.08356 https://arxiv.org/abs/1911.08356
  - bee_rider 2y ago
    That’s an odd match to the title. Who is thinking about RISC-V in 2024 without knowing that those features are typically missing? It is early days.
- pengaru 2y ago
  > Is it more that current RISC-V implementations are slow than the ISA being inherently slow? Obviously I'll defer to Jim Keller (dec alpha, amd zen, now tenstorrent..) https://www.youtube.com/watch?v=yTMRGERZrQE https://www.youtube.com/watch?v=yTMRGERZrQE
- CoastalCoder 2y ago
  I agree with your point. Some ISAs are more, or less, amenable to implementations that are fast for modern workloads. E.g., a really bad ISA could make SIMD ops, floating point math, prompt interrupt handling, 64-bit addressing, etc. really hard to make into a fast implementation. So based on the novelty of RISC-V, that's a plausible interpretation of the title.
  - phkahler 2y ago
    One of the things making x86 hard to implement is the flags register. Flags are set as a side effect of many instructions. I'd be really interested to see how Intel or AMD handle the flags in a modern processor. RISC-V gets rid of ISA defined flags entirely, so that problem goes away. In some cases the lack of flags can lead to slower software, but 99.9 percent won't miss them.
- goodpoint 2y ago
  Phrasing it as "RISC-V is slow" really reads like clickbait. It seems to imply that the ISA is inherently inefficient, while it's actually really good. Various low power rv64 CPUs are actually outperforming x86 when you compare them in terms of die area and energy usage.
emmet 2y ago
> RISC-V is 25x slower than a top of the line Apple M-series chip I don't think anyone has put the kind of money into a RISC-V processor that Apple has in order to develop the 3nm M4. I was going to say it isn't an apples to apples comparison but I will restrain myself.
- sgerenser 2y ago
  True, but who is going to put in the money? It's not a foregone conclusion that RISC-V will get enough investment to ever be competitive with state-of-the-art Arm or x86 chips.
  - gjsman-1000 2y ago
    Well, the good news for RISC-V (I say this with half honesty, half sarcasm), is that most of the RISC-V investment is happening in America and China. Their access to venture capital, talented engineers, and a decent economy makes the UK (where ARM's fighting from) look like Mississippi backwaters. ARM is disadvantaged against RISC-V geographically, economically, and politically; and judging by their interest in scare tactics a few years ago, I think they know it. Perfect conditions for a possible quick erosion of their technological lead.
    - talldayo 2y ago
      There's also the fact that ARM has a total of like 2 architecture licensees, and everyone else has to use piss-slow Cortex designs. If there was competition happening between ARM cores it would be a more interesting story, but right now ISA has taken a backseat while OEMs fight over TSMC access.
      - gjsman-1000 2y ago
        > has a total of like 2 architecture licensees And that probably only happened because Apple co-founded ARM.
        2y ago
the_jeremy 2y ago
> I haven't see any single threaded scores about 150 and no multi-threaded scores higher than 1500. s/about/above, s/see/seen
- bhouston 2y ago
  Thx! fixed.
PreInternet01 2y ago
Nah, 'RISC-V is slow' is not exactly an uncommon sentiment: see, e.g., https://news.ycombinator.com/item?id=41920766 https://news.ycombinator.com/item?id=41920766 Not surprising, since the few physical RISC-V implementations that are available under-perform a decade-old Raspi by a significant margin, and that platform is not a rocket-ship to begin with.
- deleted 2y ago
  [deleted]
- dagmx 2y ago
  You linked to the authors own comment fwiw
  - PreInternet01 2y ago
    Oops. Well, since recursive acronyms are widely-accepted in our industry as well, I'll just leave that one up.
- tredre3 2y ago
  You are out of date if you think there's no currently available commercial risc-v cores that can outperform the decade old raspberry pi 1 B+. Frankly, a 30 years old pentium 2 could outperform the first raspberry pi. It's a very low bar. And risc-v has crossed it many many years ago.
VyseofArcadia 2y ago
> ARM began in low-power embedded systems, initially facing similar performance limitations. No it didn't. ARM began on Acorn desktop computers, the Acorn Archimedes. ARM originally stood for Acorn RISC Machine.
- bhouston 2y ago
  Author here: I was intending to refer to where ARM got first got traction in the market.
  - NikkiA 2y ago
    Even there, they gained traction in STBs first, which weren't particularly 'low power', although they were embedded.
- f1shy 2y ago
  I was once in a congress, where one of the first developers of ARM was there and told the history of the company. And I perspicuously remember he saying "at the beginning was all about money, every little transistor was important, every transistor less, was a cheaper system. The same savings in money where the key to later be able to do low power processors, because is basically the same optimization" So sorry, but I have to partly disagree, they did. Edit: Interesting... sharing what the designer of the first ARM core said leads to downvoting in HN...HN is a very different place as it used to be...
  - undersuit 2y ago
    This is RISC versus CISC again. ARM1's 25k transistors beat the CISCy Intel 80286's 134k transistors. Transistors had a cost at micrometer lithography sizes.
  - VyseofArcadia 2y ago
    This is true, but it's coincidence. He didn't say they started out with the goal of a low-power processor. He's saying that they optimized for low-cost, and luckily that led to later success in low-power.
talldayo 2y ago
> Today, ARM's success has contributed to Intel's market plateau I don't buy this? ARM is applied in embedded devices or mobile hardware, neither of which Intel really "owned" in the first place. x86 is still the first-class datacenter option and I frankly don't see ARM taking it over on the desktop or server. The people with architectural licenses aren't interested in competing, which leaves Apple as really the only flexible customer, and we all know Apple was going to replace Intel eventually. So... Intel persists. And with DXVK running fine on RISC-V, I'm well within my right to say it's faster than I think: https://youtu.be/5UMUEM0gd34 https://youtu.be/5UMUEM0gd34 Honestly AMD has contributed more to Intel's demise than ARM ever did. When I read blog posts like this I really wonder how proximal the author actually is to the industry - it's an assertion that lacks evidence.
rwmj 2y ago
This is missing the two main server vendors who are taping out at the moment, Rivos and Ventana. Rivos at least are targeting the highest end performance.
- ta988 2y ago
  are there benchmarks?
  - rwmj 2y ago
    If you sign an NDA with them, I guess. Eventually you'll be able to buy the chips & benchmark them yourself.
    - kergonath 2y ago
      So, eventually we’ll be able to say that these chips are actually available. But right now, they are not proof of anything.
- classichasclass 2y ago
  Yes, but "taping out" is still a ways from "actually exists and you can bench it."
  - rwmj 2y ago
    The claim in the article is that RISC-V is somehow inherently unable to compete with Arm because of all sorts of missing architectural features. Yet there are server vendors who have those architectural features already and will make chips available fairly soon. The claim in the article is just wrong.
kibwen 2y ago
> Those that say that RISC-V is a viable replacement for x86 or ARM in the near term are kidding themselves. I strongly disagree with how this frames the conversation. For most applications our desktop machines could be 10x faster if application programmers were incentivized to care about performance. I'd happily take a 2.5x slowdown for cheaper, simpler, non-proprietary hardware. And that leads into the next point: > RISC-V implementations in the wild lack advanced features that modern CPUs rely on for speed, including sophisticated pipelining mechanisms, out-of-order execution capabilities, advanced branch prediction, and multi-tiered cache hierarchies. Most commercial RISC-V chips remain in-order processors, meaning they execute instructions sequentially rather than optimizing their order for performance. Get your pitchforks out, because I consider this a feature. Spectre should have been a wakeup call that these performance optimizations are incompatible with secure computing. "Look how much faster our new minivan careens off the nearest cliff and explodes in midair!" is not the selling point people seem to think it is. I'm eagerly awaiting a RISC-V mainboard for the Framework for this reason. If I want performance, I'll use a burner PC. If I want security, I want a CPU design where it's actually tractable to make it secure.
- gjsman-1000 2y ago
  > non-proprietary hardware RISC-V does not guarantee that the CPU core designs are open-source, that the chip designs are open-source, that your computer doesn't use Secure Boot, that your computer doesn't have proprietary drivers, or that your computer doesn't use DRM at the hardware level. It's only an instruction set. A good first step, but only that. Don't get people's hopes up.
- stackskipton 2y ago
  >I strongly disagree with how this frames the conversation. For most applications our desktop machines could be 10x faster if application programmers were incentivized to care about performance. But they are not going to be. Google and Slack is going to chomp RAM and burn my CPU cycles and my desire to use RISC-V isn't going to change their behavior. If you want people to use your hardware, you have to meet them where they are.
- rangestransform 2y ago
dagmx 2y ago
I very much agree with you, and I think you’ll hit the hornets nest on this one unfortunately. I’m all for more architectures but RISC-V has an absurd fandom behind it now. It feels like the fandom behind Linux on the home desktop or Vulkan (which makes sense given the open nature) in the way that they’re trying to manifest its success as reality by just saying that it’ll inevitably be used, while ignoring the hurdles in the way. That’s not to say those aren’t successes when used , but I often feel the comments that put them on the pedestal don’t acknowledge the immense delta between today and their imagined future, and have very little interest when it’s pointed out. For all three it comes down to Software Compatibility and experience of use. And the proponents seem to have a “the underlying tech is built and people will flock to it when they open their eyes”, but the first part in fixing the software compatibility gulf is acknowledging it exists and actioning that. FOSS isn’t alone here, Apple does the same mistake with desktop gaming and Microsoft with almost any physical product they release that’s not running windows. I really do hope that more open platforms and technologies happen, but I feel like the people who unabashedly push them without acknowledging how it needs to happen are doing them a disservice.
- giantrobot 2y ago
  > I’m all for more architectures but RISC-V has an absurd fandom behind it now. I don't understand what the fandom thinks they're going to get out of RISC-V "winning". You're not going to be able to download a new CPU like you can a new Linux kernel. An open source CPU core is useless without a factory to manufacture it. There's not going to be a GNU equivalent to semiconductor manufacturing. The baseline cost to build a factory is billions of dollars. You also can't just slap any design on any manufacturing node or chemistry. There's a lot work to get a chip design working on a particular node. A CPU is a very small part of a functional computing device. It's some magical thinking to assume just because a device was built on an open source CPU core that somehow the overall system will somehow be more open. Most of the stuff people bitch about being binary blobs will remain binary blobs will remain so even with a RISC-V CPU core. Anything with a radio will remain a black box for regulatory reasons, even if the baseband core is a RISC-V chip. GPUs will remain black boxes only accessible via their drivers' interface. Peripheral controllers covered by patent pools or branding licenses won't cease to be covered even if the controllers are RISC-V.
deleted 2y ago
[deleted]
camel-cdr 2y ago
Meanwhile, I ran right now git clone an open-source high performance out-of-order RISC-V implementation simulate the RTL, and have it out perform my current destop cpu (Zen1) on a per cycle basis: https://camel-cdr.github.io/rvv-bench-results/articles/xperm4-utf8-validation.html https://camel-cdr.github.io/rvv-bench-results/articles/xperm... (scroll to bottom and compare scalar performance between Ryzen 1600x and XiangShanV3) You may notice that while scalar is faster, the vector performance is slower, this is because their vector implementation is still quite new, and they are still missing a few optimizations. XiangShan repo: https://github.com/OpenXiangShan/XiangShan https://github.com/OpenXiangShan/XiangShan More micro architectural details: https://www.servethehome.com/xiangshan-high-performance-risc-v-processors-at-hot-chips-2024/ https://www.servethehome.com/xiangshan-high-performance-risc... BTW, XiangShanV2 has already been taped out and will be available in an laptop in the future: https://milkv.io/ruyibook https://milkv.io/ruyibook
- adrian_b 2y ago
  If what you say is correct about the comparison with Zen 1, you should keep in mind that Zen 1 (of which I also still have one) has an IPC equivalent with that of Intel Broadwell, a CPU launched in 2014, i.e. 10 years ago. (In the following years AMD has reduced then eliminated their initial handicap of 3 years, with Zen 2 matching Skylake in IPC, and then from Zen 3 until now they have always matched in IPC the best contemporaneous Intel cores.) So even such an unusually fast RISC-V core has 10 years of handicap to recover until being able to match modern CPU cores, like the Apple and Qualcomm Arm cores or like the current AMD and Intel cores. Moreover, unless your RTL simulation includes cache memories and slow DRAM memory, the simulated IPC will be far too optimistic. In any real CPU the IPC is diminished a few times from its ideal values by the cache misses that stall the CPU until data is loaded from the main memory.
  - phkahler 2y ago
    >> If what you say is correct about the comparison with Zen 1, you should keep in mind that Zen 1 (of which I also still have one) has an IPC equivalent with that of Intel Broadwell, a CPU launched in 2014, i.e. 10 years ago. So I just upgraded my Zen1+ processor (2400G) to a Zen3 (5700G) which doubled the core count and upped single core performance by about 50 percent. My favorite benchmark runs 3x as fast. Now Zen5 AFAICT is not more than 2x the performance of Zen3. So per-core the state of the art AMD is maybe 3x that of Zen1. In the last 10+ years the only significant jump due to an advanced node was with the switch to EUV lithography (TSMC 7nm) and that jump was included between Zen1 and Zen3. All the other node advancements seem to be 10-15 percent performance with new CPUs getting a modest IPC increase on top of that. If there really is a RISC-V chip with Zen1 performance that's really quite good and I'd be happy to have it. Not sure what node it's on either, so there's probably room to "buy" more performance.
mrpippy 2y ago
> Through years of architectural improvements and ecosystem development, ARM gradually expanded into mobile devices, then servers, and now even high-performance desktop systems Also, a complete re-boot of the ISA with AArch64. This is a mostly-uninformed theory, but I'd love to hear thoughts on it: AArch64 was a substantial break from AArch32, with lots of design changes intended to ease superscalar OoO implementations. Conditional execution mostly gone, Thumb gone, PC no longer a GPR, etc. Clearly, AArch64 has excelled for this. There are even rumors that Apple basically commissioned AArch64 for the types of cores they wanted to build: https://news.ycombinator.com/item?id=31368489 https://news.ycombinator.com/item?id=31368489 RISC-V is quite similar to MIPS, an ISA which hasn't had a high-performance leading-edge implementation in 20+ years (dating back to SGI's last parts). Will this heritage make it harder to build high-performance OoO implementations? Does RISC-V need an AArch64-style reboot? Maybe this can be mostly done through extensions?
- bhouston 2y ago
  That is a really good question. I wish we had Jim Kelly here to answer that. :)
  - tromp 2y ago
    Or Jim Keller even:-)
- panick21_ 2y ago
  The people who did RISC-V knew about AArch64 and designed it with hit performance in mind. Almost no conditional execution, a compressed mode that does cause issues and actually improves performance, no branch delay slot, no condition codes, no register windows and so on. They have a whole book where they go threw each instruction and explain why they added it. Its not perfectly optimized only for high performance, but that was certainty a major factor. The architecture has been evaluated by people like Dave Ditzel and Jim Keller. The leader designer for Jim Kellers company worked on the M1. And they all seem to think that its a good design.
deleted 2y ago
[deleted]
rkagerer 2y ago
The article mentions out-of-order execution capabilities. How desirable is this vs. complexity introduced, and can similar benefits more cleanly be achieved at the compiler or software architecture level?
- Arnavion 2y ago
  The point of out-of-order execution is effectively to be able to run parallel computations that don't use the same underlying hardware, eg you can run an integer operation and a floating-point operation in parallel because they use different functional units, or even two integer operations in parallel if you have redundant integer functional units. Branch prediction / speculative execution then takes that further by making an assumption of which arm of the branch will be taken and executing the instructions in that arm too. When the instruction for the branch completes fully, and the prediction turned out to be correct, the processor continues as normal. If the prediction turned out to be wrong, the processor throws away the pending changes from the incorrectly speculated instructions and starts again from the correct branch arm. An in-order CPU waits for each instruction to finish before it processes the next one. There's no way to work around that in software. At best the hardware can insert latches into the ALU etc so that instructions take the smallest number of clock cycles that they need (eg multiply takes six cycles but add takes only one). The alternative is VLIW ISAs that rely on the compiler to encode multiple instructions that can execute in parallel into a single instruction. That didn't work out well in the past for general computing as demonstrated by Itanium etc, though it's still used for restricted domains like DSPs.
- cmpxchg8b 2y ago
  Ask the Itanium team how putting faith in software optimizations to overcome hardware issues saved their bacon.
arp242 2y ago
Another aspect is software optimisation. For example, last time I looked at ffmpeg there's tons more hand-crafted x86 assembly than hand-crafted ARM assembly (been a while, not sure what the current situation is). In general, ARM optimisation has caught up quite a bit, although still lags behind in some places. RISC-V still has some ways to do. For example, for Go: [/usr/lib/go]% (for f in **/*.s; print ${${(s:_:)f:t}[-1]}) | sort | uniq -c | sort -hr | head -n10 86 amd64.s 72 arm64.s 63 s390x.s 56 s 48 arm.s 47 386.s 35 riscv64.s 32 ppc64x.s 22 loong64.s 20 mips64x.s [/usr/lib/go]% wc -l **/*amd64.s | tail -n1 28801 total [/usr/lib/go]% wc -l **/*arm64.s | tail -n1 21956 total [/usr/lib/go]% wc -l **/*riscv64.s | tail -n1 7804 total Rough measurement of course, but at least some code paths for your RISC-V will be slower just because it's not optimised (yet).
bhouston 2y ago
This was the number 1 story on Hacker News for the first 25 minutes after I posted this, and then it dropped immediately to the second page. It seems that my first blog post submitted to Hacker News got de-promoted? That sucks.
- arp242 2y ago
  Lots of comments in a short time can trigger the "flamewar detector", which downranks a story. Also wouldn't be surprised if some of the extremely aggressive RISC-V fanboys I've seen around have flagged your post for your blasphemy against their Lord and Saviour of Chips, which also downranks the story. You can email HN about it to get a more detailed explanation if you want.
  - bhouston 2y ago
    Thanks for the suggestion! Apparently a mod had down weighted it, but they reconsidered after I emailed then! So thanks!
    - BenjiWiebe 2y ago
      I've emailed the mods several times, and always got a good (and quick) response. The mods here are awesome.
binary132 2y ago
IMHO comments and TFA are discussing the wrong question. It’s not really about what the best or fastest or most power efficient CPU or ISA is. I don’t know about anyone else but I fully grasp that RISC-V is slow. In the context of RISC-V, I am entirely and only interested in whether a free ISA can be developed which is adequate to be used for developing and operating software for the sake of decentralizing and unencumbering the long-term future of free computing. RISC-V seems possibly promising for that purpose. I would like to see the development of even modest graphics coprocessors using it.
- amelius 2y ago
  Yes, but this time let's not call them graphics coprocessors if we're going to use them for something else 99% of the time.
  - tmtvl 2y ago
    If they're gonna be doing processing of arrays of numbers we could call them Group Processing Units to keep the GPU shorthand.
  - binary132 2y ago
    but I don't want LLMs I just want some graphics is that really so much to ask
- freedomben 2y ago
  That is my interest in risc v as well. However, experience watching adoption has shown me that the vast majority of consumers couldn't give a crap less about the ideals that we care about. They will go with whatever is cheapest, fastest, or both. If we want risc v to win, which I very much do, then it will need to be at least competitive, if not superlative.
  - giantrobot 2y ago
    > If we want risc v to win, which I very much do, then it will need to be at least competitive, if not superlative. The whole RISC-V "winning" meme is so weird. What do you gain if RISC-V "wins"? Even with an open source CPU core you're not getting away from binary blobs. Any wireless baseband is going to be pretty much a sealed system for regulatory reasons. Manufacturers will still lock down firmwares. Attestation chains will still be required for security. HDCP won't magically open up. High performance is largely divorced from the ISA and more related to the low level chip design and process node/chemistry. If RISC-V were to "win", the decent chips will still be manufactured by TSMC. Existing chip designers won't commit mass seppuku, they'll just start working on RISC-V designs. Compiler toolchains will just target RISC-V. So to you what do you expect to change with RISC-V? Unless you've shorted ARM and just want them to go out of business there's no magic upside for you as an end user or even as a device designer. Maybe your next phone has a RISC-V cellular baseband? You're not going to be able to tweak the EIRP of the radio any more than you can today. ARM at the core of the baseband doesn't control that but the regulatory licensing.
amelius 2y ago
> RISC-V implementations in the wild lack advanced features that modern CPUs rely on for speed, including sophisticated pipelining mechanisms, out-of-order execution capabilities, advanced branch prediction, and multi-tiered cache hierarchies. Most commercial RISC-V chips remain in-order processors, meaning they execute instructions sequentially rather than optimizing their order for performance. This architectural simplicity creates a fundamental performance ceiling that's difficult to overcome without significant architectural changes. This is a bit surprising given that all these techniques have been in computer architecture textbooks since at least the 90s.
- undersuit 2y ago
  You don't need these tricks, you can always increase clocks and speed up memory interfaces. It was a lot harder for Intel to widen the memory interface of the P5 or increase the clocks sufficiently so they made it superscalar. RISC-V gets to take advantage of being produced in 2024 and absorbing all the clock speed and transistor advantages we get for free today because of 6 decades of transistor production.
  - amelius 2y ago
    But how do you explain the 25x performance gap then?
    - phkahler 2y ago
      It costs a lot of money to develop an advanced CPU and deploy on an advanced node. You need a market for the chips to justify that so it's a bit of chicken or egg problem. The gap is slowly closing and I'm looking forward to a RISC-V linux laptop in the next few years.
    - undersuit 2y ago
      RISC-V hasn't maxed out. A new 2.4Ghz clockspeed at 7nm(dev board actually 1.4Ghz) when my old Ryzen 7 5800X at 7nm gets 4.5Ghz. https://www.theregister.com/2024/04/09/sifive_riscv_hifive/ https://www.theregister.com/2024/04/09/sifive_riscv_hifive/
camel-cdr 2y ago
One thing to keep in mind when looking at geekbench is that it's lacking Vector/SIMD optimizations for RISC-V. Most current processor lack RVV support as well, but it makes the comparison a bit meaningless. Geekbench also probably doesn't enable extension besides rv64gc, so no bitmanip extensions. Let's take two very similar cores, the SiFive P550 @1.4GHz and a Cortex-A72 @1.5GHz: https://browser.geekbench.com/v6/cpu/compare/123?baseline=7469319 https://browser.geekbench.com/v6/cpu/compare/123?baseline=74... Notice that the A72 is a lot faster in some of the benchmarks. Looking at the manual suggests that all of them are to a varying degree SIMD optimized for arm Neon: https://www.geekbench.com/doc/geekbench6-benchmark-internals.pdf https://www.geekbench.com/doc/geekbench6-benchmark-internals... The most ISA agnostic benchmark you can compare is the clang one, as it just compiles clang, which doesn't benefit much from dedicated instructions that aren't enabled for RISC-V. Notice how there the P550 outperforms the A72. --- That compared un-optimized code, but let's compare hand optimized ARM Neon vs hand optimized RISC-V RVV: This time I'm comparing a Cortex-A72 with the SpacemiT X60: * Cortex-A55: in order 1.8GHz, dual issue neon (two 128-bit execution units) * SpacemiT X60: in order 1.6GHz. Has RVV with 256-bit vectors, but two 128-bit execution units with a weird layout: only EX1: shift, bitwise, compare, mask-ops, merge, gather, compress EX1&EX2: int/float arithmetic, including mul&div The cores should be quite comparable, although the A55 is in a lot better SOC (my phone) than the X60 core and should be slightly faster, all else equal. The hand optimized code is from simdutf and the gnuradio kernel library, which I ported both to RVV: gnuradio kernels A55 Neon vs X60 RVV i16c mul: 674 vs 634 ms i16c dot: 361 vs 415 ms f32c conj dot: 1043 vs 900 ms rotator2: 763 vs 918 ms min index u32: 404 vs 156 ms f32 interleave: 308 vs 742 ms f32 log2: 1208 vs 789 ms f32 sin: 2155 vs 2152 ms f32 tan: 2962 vs 3152 ms f32 stddev&mean: 609 vs 277 ms f32 poly sum: 667 vs 266 ms u8 conv k2: 10413 bs 7523 ms simdutf: utf8 to utf16 utf16 to utf8 Neon A55 vs RVV X60 Neon A55 vs RVV X60 arabic.utf8.txt 0.25 vs 0.34 b/c 0.66 vs 0.95 b/c chinese.utf8.txt 0.23 vs 0.28 b/c 0.51 vs 0.56 b/c czech.utf8.txt 0.21 vs 0.35 b/c 0.67 vs 0.90 b/c english.utf8.txt 0.81 vs 0.85 b/c 1.14 vs 1.63 b/c esperanto.utf8.txt 0.34 vs 0.45 b/c 0.91 vs 1.12 b/c french.utf8.txt 0.28 vs 0.35 b/c 0.86 vs 0.98 b/c german.utf8.txt 0.35 vs 0.41 b/c 0.94 vs 1.10 b/c greek.utf8.txt 0.24 vs 0.37 b/c 0.64 vs 1.03 b/c hebrew.utf8.txt 0.21 vs 0.33 b/c 0.58 vs 0.92 b/c hindi.utf8.txt 0.24 vs 0.29 b/c 0.48 vs 0.57 b/c japanese.utf8.txt 0.23 vs 0.29 b/c 0.49 vs 0.57 b/c korean.utf8.txt 0.21 vs 0.28 b/c 0.47 vs 0.55 b/c persan.utf8.txt 0.23 vs 0.33 b/c 0.60 vs 0.80 b/c portuguese.utf8.txt 0.29 vs 0.36 b/c 0.88 vs 1.02 b/c russian.utf8.txt 0.23 vs 0.31 b/c 0.60 vs 0.84 b/c thai.utf8.txt 0.29 vs 0.30 b/c 0.52 vs 0.60 b/c turkish.utf8.txt 0.25 vs 0.38 b/c 0.73 vs 0.99 b/c vietnamese.utf8.txt 0.18 vs 0.28 b/c 0.46 vs 0.54 b/c Note: b/c is bytes/cycle, so bigger is better As you can see the performance is very competitive between processors of a similar design point.
newpavlov 2y ago
I was very enthusiastic about RISC-V once upon a time, but after I encountered a number of its "quirks" (e.g. see https://www.reddit.com/r/RISCV/comments/1frrai9 https://www.reddit.com/r/RISCV/comments/1frrai9) my enthusiasm has significantly cooled down. And dealing with RISC-V fanboys and lukewarm reaction from ISA maintainers regarding raised issues certainly has not helped. It looks like everyone is fine with the pile of hacks like runtime measurement of misaligned op performance implemented in Linux. Seriously? And I only scratched the surface, who knows what else lurks in the deeper reaches of the ISA spec... So even after modern CPU features like OoO execution are implemented in hardware, I absolutely will not be surprised that RISC-V hardware will be slow on certain workloads without extensive software tuning. And let's be honest, most software developers will not bother to implement RISC-V-specific paths. I still wish for RISC-V to be successful and to displace the market dominance of x86 and ARM, but I think in the end it will be Linux of the hardware world. A great advancement, created just in the right time, which eventually becomes a roadblock for further development of alternatives saddled with a lot of tech debt.
- fuhsnn 2y ago
  I'm porting a small C compiler to 64-bit RISC-V and just learned a quirk that uint32_t is represented in-register as sign extended to 64-bit. Without Zba extension the compiler has to insert a bit-clearing sequence every time the value is used for operations that cannot be agnostic in two's complement. The quirk has enough impact on benchmark scores, SiFive typedef'ed an u32 type to i32 in their Coremark repo[1]. The Coremark team later updated their rule to address this trick[2]. [1] https://github.com/sifive/benchmark-coremark/blob/4486de1f0afe9d6c1fa8dd63743e5751286f3d2f/linux64/core_portme.h#L102 https://github.com/sifive/benchmark-coremark/blob/4486de1f0a... [2] https://github.com/riscv/riscv-isa-manual/issues/353 https://github.com/riscv/riscv-isa-manual/issues/353
  - camel-cdr 2y ago
    Interesting, although using u32 for indices was always a problem for x86 as well, because you can't directly use it without extension in the more complex addressing modes. Why can't programmers use size_t for indices?
xyst 2y ago
The thinly veiled threats of switching to RISC-V are unfounded and a mere bluff. ARM can get Qualcomm to bend so easily, just wonder if they have the stomach and wallet to do so.
johnklos 2y ago
Geekbench really should not be used to compare CPUs like this. Geekbench seems to be geared towards comparing mainstream machines / devices with other mainstream machines / devices. There are many, many applications for which performance isn't as important as cost and/or power draw. For instance, these days it can be cheaper to run an additional microcontroller close to where it's needed than it is to fabricate a wiring harness to bring sensor data all the way to a centralized location. RISC-V excels here. It's a mature enough ecosystem that people can compile whatever software they want and run it without fuss on RISC-V. Nobody is going to buy a RISC-V laptop with a full GUI and be disappointed when it doesn't perform like a MacBook. So if I can buy a small SBC with two ethernets and a few RISC-V cores that takes few enough watts they can be counted on a single hand for a handful of dollars so that I can make a hardware VPN device, and I can download and compile most software on it, that interests me. Processors like Intel's N200 have their uses and definitely more performant than RISC-V, but take way too much power and therefore generate way too much heat. So why would I even bother comparing? They're in different leagues.
jauntywundrkind 2y ago
The timing of this post coming mere hours after industry giant Microchip introduces a monster of a chip is relishable: > The integrated 240Gb/s [Ed: 30GB/s] TSN-enabled Ethernet switch is far from the chips' only feature: the PIC64HX has no fewer than eight 64-bit SiFive Intelligence X280 RISC-V cores, https://www.hackster.io/news/microchip-unveils-the-high-performance-eight-core-risc-v-pic64hx-processor-family-91346e3e3039.amp https://www.hackster.io/news/microchip-unveils-the-high-perf... Actual speed of those X280's is TBD, but this seems like a huge bump in what's on the risc-v market. Most of the chips we've been looking at are the open sourced C906, a not particularly fancy early core, open sourced in 2021. It wasn't even the highest offering in that release! https://riscv.org/news/2021/10/alibaba-open-sources-four-risc-v-cores-xuantie-e902-e906-c906-and-c910-jean-luc-aufranc-cnx-software/ https://riscv.org/news/2021/10/alibaba-open-sources-four-ris... Google talked about using the X280 two years ago, and what they were able to get from it's vector unit, https://www.sifive.com/blog/sifive-intelligence-x280-as-ai-compute-host-google https://www.sifive.com/blog/sifive-intelligence-x280-as-ai-c...
- camel-cdr 2y ago
  Keep in mind that the 8 cores run at 1GHz, and have a simple simple scalar exexution, from the product page: - 5.75 CoreMarks/MHz - 3.25 DMIPS/MHz - 4.6 SpecINT2k6/GHz This SOC is mostly interesting for the 512 wide (probably single 512 vector issue) vector extension support. If the price is right this might usable as a nice little low power number cruncher. The lockstep mode is also interesting for industry uses. While possible, it's certainly nothing you'd want to run a desktop on.

110 points by bhouston 2y ago

jl6 2y ago

Is it more that current RISC-V implementations are slow than the ISA being inherently slow?

voxadam 2y ago
The article addresses this question: "RISC-V implementations in the wild lack advanced features that modern CPUs rely on for speed, including sophisticated pipelining mechanisms, out-of-order execution capabilities, advanced branch prediction, and multi-tiered cache hierarchies. Most commercial RISC-V chips remain in-order processors, meaning they execute instructions sequentially rather than optimizing their order for performance. This architectural simplicity creates a fundamental performance ceiling that's difficult to overcome without significant architectural changes."
- rwmj 2y ago
  This ignores two major server vendors, Rivos & Ventana (three if you include Qualcomm) who do have all those features.
  - bhouston 2y ago
    I am excited to see innovation come in this area. I wasn't saying that there won't be improvements or more innovation, just that the currently released chips are not performant.
  - Rochus 2y ago
    Are they included in https://browser.geekbench.com/search?q=RISC-V https://browser.geekbench.com/search?q=RISC-V? I dind't get any hits when searching e.g. for Rivos.
  - arp242 2y ago
    As I understand it, Rivos hasn't actually shipped anything; from https://www.rivosinc.com/technology https://www.rivosinc.com/technology: "Rivos has not yet revealed details of its products or technology publicly." Great that they're working on that, but when discussing the _current_ state of the RISC-V ecosystem, I think they can be safely ignored until such a time that they actually start shipping stuff. It seems Ventana has shipped the Veyron V1, but I'm having a hard time finding concrete information on that in a quick search (other than from Ventana themselves), so not entirely sure what the status of that is? Their V2 chip is planned for 2025.
- jauntywundrkind 2y ago
  But these aren't Instruction Set Architecture (IS details. As mentioned in article, Berkeley's SonicBOOM is out of order. And you could certainly enhance the memory architecture with multi-level caches easily; the ISA is blind to this (consider how little x86 ISA has improved to tackle ever improving cache/memory strategies since i386). RISC-V is also extensible. So you can keep improving things! The incredibly awesome efficiency-foxused PULP group is working on a massive many-core research chip Occamy. It has huge vector processing units, many many many of them. Ok, so, promising. https://pulp-platform.org/occamy/ https://pulp-platform.org/occamy/ And they have their own extension, Semantic Streaming Registers, which add a very CISC-y set of instructions that combine real work and load/store (and incrementing the data pointer for the next loop), allowing DSP like performance in loops. Super super slick extension to massively increase the throughput, improve the ISA & reduce it's footprint in loops. https://arxiv.org/abs/1911.08356 https://arxiv.org/abs/1911.08356
- bee_rider 2y ago
  That’s an odd match to the title. Who is thinking about RISC-V in 2024 without knowing that those features are typically missing? It is early days.
pengaru 2y ago
> Is it more that current RISC-V implementations are slow than the ISA being inherently slow? Obviously I'll defer to Jim Keller (dec alpha, amd zen, now tenstorrent..) https://www.youtube.com/watch?v=yTMRGERZrQE https://www.youtube.com/watch?v=yTMRGERZrQE
CoastalCoder 2y ago
I agree with your point. Some ISAs are more, or less, amenable to implementations that are fast for modern workloads. E.g., a really bad ISA could make SIMD ops, floating point math, prompt interrupt handling, 64-bit addressing, etc. really hard to make into a fast implementation. So based on the novelty of RISC-V, that's a plausible interpretation of the title.
- phkahler 2y ago
  One of the things making x86 hard to implement is the flags register. Flags are set as a side effect of many instructions. I'd be really interested to see how Intel or AMD handle the flags in a modern processor. RISC-V gets rid of ISA defined flags entirely, so that problem goes away. In some cases the lack of flags can lead to slower software, but 99.9 percent won't miss them.
goodpoint 2y ago
Phrasing it as "RISC-V is slow" really reads like clickbait. It seems to imply that the ISA is inherently inefficient, while it's actually really good. Various low power rv64 CPUs are actually outperforming x86 when you compare them in terms of die area and energy usage.

emmet 2y ago

> RISC-V is 25x slower than a top of the line Apple M-series chip I don't think anyone has put the kind of money into a RISC-V processor that Apple has in order to develop the 3nm M4. I was going to say it isn't an apples to apples comparison but I will restrain myself.

sgerenser 2y ago
True, but who is going to put in the money? It's not a foregone conclusion that RISC-V will get enough investment to ever be competitive with state-of-the-art Arm or x86 chips.
- gjsman-1000 2y ago
  Well, the good news for RISC-V (I say this with half honesty, half sarcasm), is that most of the RISC-V investment is happening in America and China. Their access to venture capital, talented engineers, and a decent economy makes the UK (where ARM's fighting from) look like Mississippi backwaters. ARM is disadvantaged against RISC-V geographically, economically, and politically; and judging by their interest in scare tactics a few years ago, I think they know it. Perfect conditions for a possible quick erosion of their technological lead.
  - talldayo 2y ago
    There's also the fact that ARM has a total of like 2 architecture licensees, and everyone else has to use piss-slow Cortex designs. If there was competition happening between ARM cores it would be a more interesting story, but right now ISA has taken a backseat while OEMs fight over TSMC access.
    - gjsman-1000 2y ago
      > has a total of like 2 architecture licensees And that probably only happened because Apple co-founded ARM.
      - 2y ago

the_jeremy 2y ago

> I haven't see any single threaded scores about 150 and no multi-threaded scores higher than 1500. s/about/above, s/see/seen

bhouston 2y ago
Thx! fixed.

PreInternet01 2y ago

Nah, 'RISC-V is slow' is not exactly an uncommon sentiment: see, e.g., https://news.ycombinator.com/item?id=41920766 https://news.ycombinator.com/item?id=41920766 Not surprising, since the few physical RISC-V implementations that are available under-perform a decade-old Raspi by a significant margin, and that platform is not a rocket-ship to begin with.

deleted 2y ago
[deleted]
dagmx 2y ago
You linked to the authors own comment fwiw
- PreInternet01 2y ago
  Oops. Well, since recursive acronyms are widely-accepted in our industry as well, I'll just leave that one up.
tredre3 2y ago
You are out of date if you think there's no currently available commercial risc-v cores that can outperform the decade old raspberry pi 1 B+. Frankly, a 30 years old pentium 2 could outperform the first raspberry pi. It's a very low bar. And risc-v has crossed it many many years ago.

VyseofArcadia 2y ago

> ARM began in low-power embedded systems, initially facing similar performance limitations. No it didn't. ARM began on Acorn desktop computers, the Acorn Archimedes. ARM originally stood for Acorn RISC Machine.

bhouston 2y ago
Author here: I was intending to refer to where ARM got first got traction in the market.
- NikkiA 2y ago
  Even there, they gained traction in STBs first, which weren't particularly 'low power', although they were embedded.
f1shy 2y ago
I was once in a congress, where one of the first developers of ARM was there and told the history of the company. And I perspicuously remember he saying "at the beginning was all about money, every little transistor was important, every transistor less, was a cheaper system. The same savings in money where the key to later be able to do low power processors, because is basically the same optimization" So sorry, but I have to partly disagree, they did. Edit: Interesting... sharing what the designer of the first ARM core said leads to downvoting in HN...HN is a very different place as it used to be...
- undersuit 2y ago
  This is RISC versus CISC again. ARM1's 25k transistors beat the CISCy Intel 80286's 134k transistors. Transistors had a cost at micrometer lithography sizes.
- VyseofArcadia 2y ago
  This is true, but it's coincidence. He didn't say they started out with the goal of a low-power processor. He's saying that they optimized for low-cost, and luckily that led to later success in low-power.

talldayo 2y ago

> Today, ARM's success has contributed to Intel's market plateau I don't buy this? ARM is applied in embedded devices or mobile hardware, neither of which Intel really "owned" in the first place. x86 is still the first-class datacenter option and I frankly don't see ARM taking it over on the desktop or server. The people with architectural licenses aren't interested in competing, which leaves Apple as really the only flexible customer, and we all know Apple was going to replace Intel eventually. So... Intel persists. And with DXVK running fine on RISC-V, I'm well within my right to say it's faster than I think: https://youtu.be/5UMUEM0gd34 https://youtu.be/5UMUEM0gd34 Honestly AMD has contributed more to Intel's demise than ARM ever did. When I read blog posts like this I really wonder how proximal the author actually is to the industry - it's an assertion that lacks evidence.

rwmj 2y ago

This is missing the two main server vendors who are taping out at the moment, Rivos and Ventana. Rivos at least are targeting the highest end performance.

ta988 2y ago
are there benchmarks?
- rwmj 2y ago
  If you sign an NDA with them, I guess. Eventually you'll be able to buy the chips & benchmark them yourself.
  - kergonath 2y ago
    So, eventually we’ll be able to say that these chips are actually available. But right now, they are not proof of anything.
classichasclass 2y ago
Yes, but "taping out" is still a ways from "actually exists and you can bench it."
- rwmj 2y ago
  The claim in the article is that RISC-V is somehow inherently unable to compete with Arm because of all sorts of missing architectural features. Yet there are server vendors who have those architectural features already and will make chips available fairly soon. The claim in the article is just wrong.

kibwen 2y ago

> Those that say that RISC-V is a viable replacement for x86 or ARM in the near term are kidding themselves. I strongly disagree with how this frames the conversation. For most applications our desktop machines could be 10x faster if application programmers were incentivized to care about performance. I'd happily take a 2.5x slowdown for cheaper, simpler, non-proprietary hardware. And that leads into the next point: > RISC-V implementations in the wild lack advanced features that modern CPUs rely on for speed, including sophisticated pipelining mechanisms, out-of-order execution capabilities, advanced branch prediction, and multi-tiered cache hierarchies. Most commercial RISC-V chips remain in-order processors, meaning they execute instructions sequentially rather than optimizing their order for performance. Get your pitchforks out, because I consider this a feature. Spectre should have been a wakeup call that these performance optimizations are incompatible with secure computing. "Look how much faster our new minivan careens off the nearest cliff and explodes in midair!" is not the selling point people seem to think it is. I'm eagerly awaiting a RISC-V mainboard for the Framework for this reason. If I want performance, I'll use a burner PC. If I want security, I want a CPU design where it's actually tractable to make it secure.

gjsman-1000 2y ago
> non-proprietary hardware RISC-V does not guarantee that the CPU core designs are open-source, that the chip designs are open-source, that your computer doesn't use Secure Boot, that your computer doesn't have proprietary drivers, or that your computer doesn't use DRM at the hardware level. It's only an instruction set. A good first step, but only that. Don't get people's hopes up.
stackskipton 2y ago
>I strongly disagree with how this frames the conversation. For most applications our desktop machines could be 10x faster if application programmers were incentivized to care about performance. But they are not going to be. Google and Slack is going to chomp RAM and burn my CPU cycles and my desire to use RISC-V isn't going to change their behavior. If you want people to use your hardware, you have to meet them where they are.
rangestransform 2y ago

dagmx 2y ago

I very much agree with you, and I think you’ll hit the hornets nest on this one unfortunately. I’m all for more architectures but RISC-V has an absurd fandom behind it now. It feels like the fandom behind Linux on the home desktop or Vulkan (which makes sense given the open nature) in the way that they’re trying to manifest its success as reality by just saying that it’ll inevitably be used, while ignoring the hurdles in the way. That’s not to say those aren’t successes when used , but I often feel the comments that put them on the pedestal don’t acknowledge the immense delta between today and their imagined future, and have very little interest when it’s pointed out. For all three it comes down to Software Compatibility and experience of use. And the proponents seem to have a “the underlying tech is built and people will flock to it when they open their eyes”, but the first part in fixing the software compatibility gulf is acknowledging it exists and actioning that. FOSS isn’t alone here, Apple does the same mistake with desktop gaming and Microsoft with almost any physical product they release that’s not running windows. I really do hope that more open platforms and technologies happen, but I feel like the people who unabashedly push them without acknowledging how it needs to happen are doing them a disservice.

giantrobot 2y ago
> I’m all for more architectures but RISC-V has an absurd fandom behind it now. I don't understand what the fandom thinks they're going to get out of RISC-V "winning". You're not going to be able to download a new CPU like you can a new Linux kernel. An open source CPU core is useless without a factory to manufacture it. There's not going to be a GNU equivalent to semiconductor manufacturing. The baseline cost to build a factory is billions of dollars. You also can't just slap any design on any manufacturing node or chemistry. There's a lot work to get a chip design working on a particular node. A CPU is a very small part of a functional computing device. It's some magical thinking to assume just because a device was built on an open source CPU core that somehow the overall system will somehow be more open. Most of the stuff people bitch about being binary blobs will remain binary blobs will remain so even with a RISC-V CPU core. Anything with a radio will remain a black box for regulatory reasons, even if the baseband core is a RISC-V chip. GPUs will remain black boxes only accessible via their drivers' interface. Peripheral controllers covered by patent pools or branding licenses won't cease to be covered even if the controllers are RISC-V.

deleted 2y ago

[deleted]

camel-cdr 2y ago

Meanwhile, I ran right now git clone an open-source high performance out-of-order RISC-V implementation simulate the RTL, and have it out perform my current destop cpu (Zen1) on a per cycle basis: https://camel-cdr.github.io/rvv-bench-results/articles/xperm4-utf8-validation.html https://camel-cdr.github.io/rvv-bench-results/articles/xperm... (scroll to bottom and compare scalar performance between Ryzen 1600x and XiangShanV3) You may notice that while scalar is faster, the vector performance is slower, this is because their vector implementation is still quite new, and they are still missing a few optimizations. XiangShan repo: https://github.com/OpenXiangShan/XiangShan https://github.com/OpenXiangShan/XiangShan More micro architectural details: https://www.servethehome.com/xiangshan-high-performance-risc-v-processors-at-hot-chips-2024/ https://www.servethehome.com/xiangshan-high-performance-risc... BTW, XiangShanV2 has already been taped out and will be available in an laptop in the future: https://milkv.io/ruyibook https://milkv.io/ruyibook

adrian_b 2y ago
If what you say is correct about the comparison with Zen 1, you should keep in mind that Zen 1 (of which I also still have one) has an IPC equivalent with that of Intel Broadwell, a CPU launched in 2014, i.e. 10 years ago. (In the following years AMD has reduced then eliminated their initial handicap of 3 years, with Zen 2 matching Skylake in IPC, and then from Zen 3 until now they have always matched in IPC the best contemporaneous Intel cores.) So even such an unusually fast RISC-V core has 10 years of handicap to recover until being able to match modern CPU cores, like the Apple and Qualcomm Arm cores or like the current AMD and Intel cores. Moreover, unless your RTL simulation includes cache memories and slow DRAM memory, the simulated IPC will be far too optimistic. In any real CPU the IPC is diminished a few times from its ideal values by the cache misses that stall the CPU until data is loaded from the main memory.
- phkahler 2y ago
  >> If what you say is correct about the comparison with Zen 1, you should keep in mind that Zen 1 (of which I also still have one) has an IPC equivalent with that of Intel Broadwell, a CPU launched in 2014, i.e. 10 years ago. So I just upgraded my Zen1+ processor (2400G) to a Zen3 (5700G) which doubled the core count and upped single core performance by about 50 percent. My favorite benchmark runs 3x as fast. Now Zen5 AFAICT is not more than 2x the performance of Zen3. So per-core the state of the art AMD is maybe 3x that of Zen1. In the last 10+ years the only significant jump due to an advanced node was with the switch to EUV lithography (TSMC 7nm) and that jump was included between Zen1 and Zen3. All the other node advancements seem to be 10-15 percent performance with new CPUs getting a modest IPC increase on top of that. If there really is a RISC-V chip with Zen1 performance that's really quite good and I'd be happy to have it. Not sure what node it's on either, so there's probably room to "buy" more performance.

mrpippy 2y ago

> Through years of architectural improvements and ecosystem development, ARM gradually expanded into mobile devices, then servers, and now even high-performance desktop systems Also, a complete re-boot of the ISA with AArch64. This is a mostly-uninformed theory, but I'd love to hear thoughts on it: AArch64 was a substantial break from AArch32, with lots of design changes intended to ease superscalar OoO implementations. Conditional execution mostly gone, Thumb gone, PC no longer a GPR, etc. Clearly, AArch64 has excelled for this. There are even rumors that Apple basically commissioned AArch64 for the types of cores they wanted to build: https://news.ycombinator.com/item?id=31368489 https://news.ycombinator.com/item?id=31368489 RISC-V is quite similar to MIPS, an ISA which hasn't had a high-performance leading-edge implementation in 20+ years (dating back to SGI's last parts). Will this heritage make it harder to build high-performance OoO implementations? Does RISC-V need an AArch64-style reboot? Maybe this can be mostly done through extensions?

bhouston 2y ago
That is a really good question. I wish we had Jim Kelly here to answer that. :)
- tromp 2y ago
  Or Jim Keller even:-)
panick21_ 2y ago
The people who did RISC-V knew about AArch64 and designed it with hit performance in mind. Almost no conditional execution, a compressed mode that does cause issues and actually improves performance, no branch delay slot, no condition codes, no register windows and so on. They have a whole book where they go threw each instruction and explain why they added it. Its not perfectly optimized only for high performance, but that was certainty a major factor. The architecture has been evaluated by people like Dave Ditzel and Jim Keller. The leader designer for Jim Kellers company worked on the M1. And they all seem to think that its a good design.

deleted 2y ago

[deleted]

rkagerer 2y ago

The article mentions out-of-order execution capabilities. How desirable is this vs. complexity introduced, and can similar benefits more cleanly be achieved at the compiler or software architecture level?

Arnavion 2y ago
The point of out-of-order execution is effectively to be able to run parallel computations that don't use the same underlying hardware, eg you can run an integer operation and a floating-point operation in parallel because they use different functional units, or even two integer operations in parallel if you have redundant integer functional units. Branch prediction / speculative execution then takes that further by making an assumption of which arm of the branch will be taken and executing the instructions in that arm too. When the instruction for the branch completes fully, and the prediction turned out to be correct, the processor continues as normal. If the prediction turned out to be wrong, the processor throws away the pending changes from the incorrectly speculated instructions and starts again from the correct branch arm. An in-order CPU waits for each instruction to finish before it processes the next one. There's no way to work around that in software. At best the hardware can insert latches into the ALU etc so that instructions take the smallest number of clock cycles that they need (eg multiply takes six cycles but add takes only one). The alternative is VLIW ISAs that rely on the compiler to encode multiple instructions that can execute in parallel into a single instruction. That didn't work out well in the past for general computing as demonstrated by Itanium etc, though it's still used for restricted domains like DSPs.
cmpxchg8b 2y ago
Ask the Itanium team how putting faith in software optimizations to overcome hardware issues saved their bacon.

arp242 2y ago

Another aspect is software optimisation. For example, last time I looked at ffmpeg there's tons more hand-crafted x86 assembly than hand-crafted ARM assembly (been a while, not sure what the current situation is). In general, ARM optimisation has caught up quite a bit, although still lags behind in some places. RISC-V still has some ways to do. For example, for Go: [/usr/lib/go]% (for f in **/*.s; print ${${(s:_:)f:t}[-1]}) | sort | uniq -c | sort -hr | head -n10 86 amd64.s 72 arm64.s 63 s390x.s 56 s 48 arm.s 47 386.s 35 riscv64.s 32 ppc64x.s 22 loong64.s 20 mips64x.s [/usr/lib/go]% wc -l **/*amd64.s | tail -n1 28801 total [/usr/lib/go]% wc -l **/*arm64.s | tail -n1 21956 total [/usr/lib/go]% wc -l **/*riscv64.s | tail -n1 7804 total Rough measurement of course, but at least some code paths for your RISC-V will be slower just because it's not optimised (yet).

bhouston 2y ago

This was the number 1 story on Hacker News for the first 25 minutes after I posted this, and then it dropped immediately to the second page. It seems that my first blog post submitted to Hacker News got de-promoted? That sucks.

arp242 2y ago
Lots of comments in a short time can trigger the "flamewar detector", which downranks a story. Also wouldn't be surprised if some of the extremely aggressive RISC-V fanboys I've seen around have flagged your post for your blasphemy against their Lord and Saviour of Chips, which also downranks the story. You can email HN about it to get a more detailed explanation if you want.
- bhouston 2y ago
  Thanks for the suggestion! Apparently a mod had down weighted it, but they reconsidered after I emailed then! So thanks!
  - BenjiWiebe 2y ago
    I've emailed the mods several times, and always got a good (and quick) response. The mods here are awesome.

binary132 2y ago

IMHO comments and TFA are discussing the wrong question. It’s not really about what the best or fastest or most power efficient CPU or ISA is. I don’t know about anyone else but I fully grasp that RISC-V is slow. In the context of RISC-V, I am entirely and only interested in whether a free ISA can be developed which is adequate to be used for developing and operating software for the sake of decentralizing and unencumbering the long-term future of free computing. RISC-V seems possibly promising for that purpose. I would like to see the development of even modest graphics coprocessors using it.

amelius 2y ago
Yes, but this time let's not call them graphics coprocessors if we're going to use them for something else 99% of the time.
- tmtvl 2y ago
  If they're gonna be doing processing of arrays of numbers we could call them Group Processing Units to keep the GPU shorthand.
- binary132 2y ago
  but I don't want LLMs I just want some graphics is that really so much to ask
freedomben 2y ago
That is my interest in risc v as well. However, experience watching adoption has shown me that the vast majority of consumers couldn't give a crap less about the ideals that we care about. They will go with whatever is cheapest, fastest, or both. If we want risc v to win, which I very much do, then it will need to be at least competitive, if not superlative.
- giantrobot 2y ago
  > If we want risc v to win, which I very much do, then it will need to be at least competitive, if not superlative. The whole RISC-V "winning" meme is so weird. What do you gain if RISC-V "wins"? Even with an open source CPU core you're not getting away from binary blobs. Any wireless baseband is going to be pretty much a sealed system for regulatory reasons. Manufacturers will still lock down firmwares. Attestation chains will still be required for security. HDCP won't magically open up. High performance is largely divorced from the ISA and more related to the low level chip design and process node/chemistry. If RISC-V were to "win", the decent chips will still be manufactured by TSMC. Existing chip designers won't commit mass seppuku, they'll just start working on RISC-V designs. Compiler toolchains will just target RISC-V. So to you what do you expect to change with RISC-V? Unless you've shorted ARM and just want them to go out of business there's no magic upside for you as an end user or even as a device designer. Maybe your next phone has a RISC-V cellular baseband? You're not going to be able to tweak the EIRP of the radio any more than you can today. ARM at the core of the baseband doesn't control that but the regulatory licensing.

amelius 2y ago

> RISC-V implementations in the wild lack advanced features that modern CPUs rely on for speed, including sophisticated pipelining mechanisms, out-of-order execution capabilities, advanced branch prediction, and multi-tiered cache hierarchies. Most commercial RISC-V chips remain in-order processors, meaning they execute instructions sequentially rather than optimizing their order for performance. This architectural simplicity creates a fundamental performance ceiling that's difficult to overcome without significant architectural changes. This is a bit surprising given that all these techniques have been in computer architecture textbooks since at least the 90s.

undersuit 2y ago
You don't need these tricks, you can always increase clocks and speed up memory interfaces. It was a lot harder for Intel to widen the memory interface of the P5 or increase the clocks sufficiently so they made it superscalar. RISC-V gets to take advantage of being produced in 2024 and absorbing all the clock speed and transistor advantages we get for free today because of 6 decades of transistor production.
- amelius 2y ago
  But how do you explain the 25x performance gap then?
  - phkahler 2y ago
    It costs a lot of money to develop an advanced CPU and deploy on an advanced node. You need a market for the chips to justify that so it's a bit of chicken or egg problem. The gap is slowly closing and I'm looking forward to a RISC-V linux laptop in the next few years.
  - undersuit 2y ago
    RISC-V hasn't maxed out. A new 2.4Ghz clockspeed at 7nm(dev board actually 1.4Ghz) when my old Ryzen 7 5800X at 7nm gets 4.5Ghz. https://www.theregister.com/2024/04/09/sifive_riscv_hifive/ https://www.theregister.com/2024/04/09/sifive_riscv_hifive/

camel-cdr 2y ago

One thing to keep in mind when looking at geekbench is that it's lacking Vector/SIMD optimizations for RISC-V. Most current processor lack RVV support as well, but it makes the comparison a bit meaningless. Geekbench also probably doesn't enable extension besides rv64gc, so no bitmanip extensions. Let's take two very similar cores, the SiFive P550 @1.4GHz and a Cortex-A72 @1.5GHz: https://browser.geekbench.com/v6/cpu/compare/123?baseline=7469319 https://browser.geekbench.com/v6/cpu/compare/123?baseline=74... Notice that the A72 is a lot faster in some of the benchmarks. Looking at the manual suggests that all of them are to a varying degree SIMD optimized for arm Neon: https://www.geekbench.com/doc/geekbench6-benchmark-internals.pdf https://www.geekbench.com/doc/geekbench6-benchmark-internals... The most ISA agnostic benchmark you can compare is the clang one, as it just compiles clang, which doesn't benefit much from dedicated instructions that aren't enabled for RISC-V. Notice how there the P550 outperforms the A72. --- That compared un-optimized code, but let's compare hand optimized ARM Neon vs hand optimized RISC-V RVV: This time I'm comparing a Cortex-A72 with the SpacemiT X60: * Cortex-A55: in order 1.8GHz, dual issue neon (two 128-bit execution units) * SpacemiT X60: in order 1.6GHz. Has RVV with 256-bit vectors, but two 128-bit execution units with a weird layout: only EX1: shift, bitwise, compare, mask-ops, merge, gather, compress EX1&EX2: int/float arithmetic, including mul&div The cores should be quite comparable, although the A55 is in a lot better SOC (my phone) than the X60 core and should be slightly faster, all else equal. The hand optimized code is from simdutf and the gnuradio kernel library, which I ported both to RVV: gnuradio kernels A55 Neon vs X60 RVV i16c mul: 674 vs 634 ms i16c dot: 361 vs 415 ms f32c conj dot: 1043 vs 900 ms rotator2: 763 vs 918 ms min index u32: 404 vs 156 ms f32 interleave: 308 vs 742 ms f32 log2: 1208 vs 789 ms f32 sin: 2155 vs 2152 ms f32 tan: 2962 vs 3152 ms f32 stddev&mean: 609 vs 277 ms f32 poly sum: 667 vs 266 ms u8 conv k2: 10413 bs 7523 ms simdutf: utf8 to utf16 utf16 to utf8 Neon A55 vs RVV X60 Neon A55 vs RVV X60 arabic.utf8.txt 0.25 vs 0.34 b/c 0.66 vs 0.95 b/c chinese.utf8.txt 0.23 vs 0.28 b/c 0.51 vs 0.56 b/c czech.utf8.txt 0.21 vs 0.35 b/c 0.67 vs 0.90 b/c english.utf8.txt 0.81 vs 0.85 b/c 1.14 vs 1.63 b/c esperanto.utf8.txt 0.34 vs 0.45 b/c 0.91 vs 1.12 b/c french.utf8.txt 0.28 vs 0.35 b/c 0.86 vs 0.98 b/c german.utf8.txt 0.35 vs 0.41 b/c 0.94 vs 1.10 b/c greek.utf8.txt 0.24 vs 0.37 b/c 0.64 vs 1.03 b/c hebrew.utf8.txt 0.21 vs 0.33 b/c 0.58 vs 0.92 b/c hindi.utf8.txt 0.24 vs 0.29 b/c 0.48 vs 0.57 b/c japanese.utf8.txt 0.23 vs 0.29 b/c 0.49 vs 0.57 b/c korean.utf8.txt 0.21 vs 0.28 b/c 0.47 vs 0.55 b/c persan.utf8.txt 0.23 vs 0.33 b/c 0.60 vs 0.80 b/c portuguese.utf8.txt 0.29 vs 0.36 b/c 0.88 vs 1.02 b/c russian.utf8.txt 0.23 vs 0.31 b/c 0.60 vs 0.84 b/c thai.utf8.txt 0.29 vs 0.30 b/c 0.52 vs 0.60 b/c turkish.utf8.txt 0.25 vs 0.38 b/c 0.73 vs 0.99 b/c vietnamese.utf8.txt 0.18 vs 0.28 b/c 0.46 vs 0.54 b/c Note: b/c is bytes/cycle, so bigger is better As you can see the performance is very competitive between processors of a similar design point.

newpavlov 2y ago

I was very enthusiastic about RISC-V once upon a time, but after I encountered a number of its "quirks" (e.g. see https://www.reddit.com/r/RISCV/comments/1frrai9 https://www.reddit.com/r/RISCV/comments/1frrai9) my enthusiasm has significantly cooled down. And dealing with RISC-V fanboys and lukewarm reaction from ISA maintainers regarding raised issues certainly has not helped. It looks like everyone is fine with the pile of hacks like runtime measurement of misaligned op performance implemented in Linux. Seriously? And I only scratched the surface, who knows what else lurks in the deeper reaches of the ISA spec... So even after modern CPU features like OoO execution are implemented in hardware, I absolutely will not be surprised that RISC-V hardware will be slow on certain workloads without extensive software tuning. And let's be honest, most software developers will not bother to implement RISC-V-specific paths. I still wish for RISC-V to be successful and to displace the market dominance of x86 and ARM, but I think in the end it will be Linux of the hardware world. A great advancement, created just in the right time, which eventually becomes a roadblock for further development of alternatives saddled with a lot of tech debt.

fuhsnn 2y ago
I'm porting a small C compiler to 64-bit RISC-V and just learned a quirk that uint32_t is represented in-register as sign extended to 64-bit. Without Zba extension the compiler has to insert a bit-clearing sequence every time the value is used for operations that cannot be agnostic in two's complement. The quirk has enough impact on benchmark scores, SiFive typedef'ed an u32 type to i32 in their Coremark repo[1]. The Coremark team later updated their rule to address this trick[2]. [1] https://github.com/sifive/benchmark-coremark/blob/4486de1f0afe9d6c1fa8dd63743e5751286f3d2f/linux64/core_portme.h#L102 https://github.com/sifive/benchmark-coremark/blob/4486de1f0a... [2] https://github.com/riscv/riscv-isa-manual/issues/353 https://github.com/riscv/riscv-isa-manual/issues/353
- camel-cdr 2y ago
  Interesting, although using u32 for indices was always a problem for x86 as well, because you can't directly use it without extension in the more complex addressing modes. Why can't programmers use size_t for indices?

xyst 2y ago

The thinly veiled threats of switching to RISC-V are unfounded and a mere bluff. ARM can get Qualcomm to bend so easily, just wonder if they have the stomach and wallet to do so.

johnklos 2y ago

Geekbench really should not be used to compare CPUs like this. Geekbench seems to be geared towards comparing mainstream machines / devices with other mainstream machines / devices. There are many, many applications for which performance isn't as important as cost and/or power draw. For instance, these days it can be cheaper to run an additional microcontroller close to where it's needed than it is to fabricate a wiring harness to bring sensor data all the way to a centralized location. RISC-V excels here. It's a mature enough ecosystem that people can compile whatever software they want and run it without fuss on RISC-V. Nobody is going to buy a RISC-V laptop with a full GUI and be disappointed when it doesn't perform like a MacBook. So if I can buy a small SBC with two ethernets and a few RISC-V cores that takes few enough watts they can be counted on a single hand for a handful of dollars so that I can make a hardware VPN device, and I can download and compile most software on it, that interests me. Processors like Intel's N200 have their uses and definitely more performant than RISC-V, but take way too much power and therefore generate way too much heat. So why would I even bother comparing? They're in different leagues.

jauntywundrkind 2y ago

The timing of this post coming mere hours after industry giant Microchip introduces a monster of a chip is relishable: > The integrated 240Gb/s [Ed: 30GB/s] TSN-enabled Ethernet switch is far from the chips' only feature: the PIC64HX has no fewer than eight 64-bit SiFive Intelligence X280 RISC-V cores, https://www.hackster.io/news/microchip-unveils-the-high-performance-eight-core-risc-v-pic64hx-processor-family-91346e3e3039.amp https://www.hackster.io/news/microchip-unveils-the-high-perf... Actual speed of those X280's is TBD, but this seems like a huge bump in what's on the risc-v market. Most of the chips we've been looking at are the open sourced C906, a not particularly fancy early core, open sourced in 2021. It wasn't even the highest offering in that release! https://riscv.org/news/2021/10/alibaba-open-sources-four-risc-v-cores-xuantie-e902-e906-c906-and-c910-jean-luc-aufranc-cnx-software/ https://riscv.org/news/2021/10/alibaba-open-sources-four-ris... Google talked about using the X280 two years ago, and what they were able to get from it's vector unit, https://www.sifive.com/blog/sifive-intelligence-x280-as-ai-compute-host-google https://www.sifive.com/blog/sifive-intelligence-x280-as-ai-c...

camel-cdr 2y ago
Keep in mind that the 8 cores run at 1GHz, and have a simple simple scalar exexution, from the product page: - 5.75 CoreMarks/MHz - 3.25 DMIPS/MHz - 4.6 SpecINT2k6/GHz This SOC is mostly interesting for the 512 wide (probably single 512 vector issue) vector extension support. If the price is right this might usable as a nice little low power number cruncher. The lockstep mode is also interesting for industry uses. While possible, it's certainly nothing you'd want to run a desktop on.