From: cross@spitfire.i.gajendra.net   
      
   In article ,   
   John Dallman  wrote:   
   >In article <10bslgs$qfk$1@reader2.panix.com>,   
   >cross@spitfire.i.gajendra.net (Dan Cross) wrote:   
   >   
   >> In terms of providing something roughly equivalent to a Cortex-A5,   
   >> RISC-V has been there for a while.  What's really lacking, however,   
   >> is a performance-competitive datacenter or desktop CPU.   
   >>   
   >> Some of the SiFive cores are ok, but they have a long way to go   
   >> to reach the performance levels of Ampere, Graviton, or Apple   
   >> Silicon, let alone AMD EPYC or Intel Emerald Rapids.   
   >   
   >Yup. I've ported my employer's product to, um, quite a lot of 32- and   
   >64-bit architectures over the past thirty years. It runs on servers,   
   >desktops and high-end mobile devices Five years ago, I was looking   
   >forward to doing a RISC-V port to Linux and/or Android before I retired.   
   >   
   >Then SiFive made job cuts and abandoned development of high-end   
   >general-purpose cores in October 2023. Since then, there doesn't seem to   
   >have been much in the way of performance advances in the RISC-V space.   
   >Ahead Computing was set up to offer that, but have gone rather quiet.   
   >MIPS switched to RISC-V, but have been acquired since then.   
   >   
   >I'm starting to become suspicious that the claims that it's hard to make   
   >very fast RISC-V cores are accurate.   
      
   I could see it go either way: it took quite some time for ARM64   
   to get to the point of adoption where we saw Graviton and Ampere   
   Altra.  So it may just be taking time: on the embedded side,   
   they hit the target of shipping a billion CPUs a year faster   
   than ARM did, but that's a different market.   
      
   On the other hand, everything you wrote is true, and it sure   
   seems like they're taking their sweet time about getting there,   
   which does make one wonder what's going on.   
      
   I've been told that the BOOM (Berkeley Out-of-Order Machine) was   
   quite zippy, so I don't think there are any architectural issues   
   making RV64 fast.  I know that they way they do optional   
   features gives folks a lot of pain, and basically requires hot   
   patching code at startup to cover the set of implemented   
   features on any given platform, if you want to run a generic   
   binary portable across different implementations, so that could   
   have something to do with it: otherwise you've got a lot of   
   branches and indirect jumps through thunks and similar things to   
   work around the differences, which will slow down baseline   
   execution.  Anyway, fragmentation is a real issue, and may be   
   hindering adoption.   
      
   There are definitely a few things I wish they had done   
   differently (I'm not a fan of the page table formats, page   
   frames are too small for the memory sizes we have now, and I   
   don't like SBI), and from a systems perspective, last time I   
   looked it felt a little immature; the mechanism for doing   
   uncached access to memory-mapped IO devices, for instance, based   
   on PMAs felt limited for a large system and felt like an extra   
   hoop to jump through versus encoding that in page tables and   
   having something like MTRRs for the physical side.  It's unclear   
   how well they support large numbers of hart contexts in the PLIC   
   architecture for MSIs, let alone MSI-X.   
      
   Also, the Chinese are pushing it pretty far, and things like the   
   Milk-V systems look pretty cool.  I suspect we'll see RV64 in   
   supercomputers relatively soon; whether those chips will be   
   readily available in the western markets remains to be seen.   
      
   	- Dan C.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)