11 ms·
A Big Week for RISC-V
- miohtama 5y ago> It’s a tradeoff: With RISC-V you get innovation, you can create new extensions, but you lost software compatibility. And more importantly, you lose the guarantee of software compatibility,” he said. Arm’s founders made “that a key tenet, and that will serve us well going forward. I’m confident of that.” How long does it take until we have server-side Ubuntu Linux and staple applications like PostgreSQL humming nicely on RISC-V? It does not matter if RISC-V has less ported software today, as long as there is clear roadmap when this advantage of ARM will be gone.
- MaKey 5y agoIf everyone implements their own custom extensions, you would have to compile your software for each RISC-V device. To be able to do that, the compiler needs to support those extensions. I think that is what was meant with "you lost software compatibility". Edit: I am mistaken, thanks everyone for educating me.
- geokon 5y agoI find it hard to believe there is no way to probe for extensions and provide a fallback It's a problem that already exists right now. If you compile code on a machine with SSE or AVX and run it on an old Pentium, does it crash? I had a fun bug once running ARM code that had some NEON in it and it would crashed on Scaleway's VPS bc their servers ran chips that didn't have NEON implemented
- rwmj 5y agoThis is the standard FUD spread around by Arm apologists. Of course you can detect RISC-V extensions at both compile and run time. In fact it's the first widespread ISA that was designed with extension in mind (so for example there's a uniform way to find instruction boundaries even if you do not know how to fully interpret an extension). This is in stark contrast to x86 where extensions are basically hacks piled on hacks.
- MaKey 5y agoSorry, my post was not intended to be FUD. I tried to follow the original claim but apparently placed too much merit in it.
- saagarjha 5y ago> so for example there's a uniform way to find instruction boundaries even if you do not know how to fully interpret an extension This doesn’t make sense, though. If you have something in your instruction stream that you don’t understand, it would be insane to do anything but fault immediately, unless the instruction is some sort of optional feature such as a hint or security mechanism where there is no real behavior associated with it. I mean ARM has this “capability” too by virtue of a fixed length instruction set but it doesn’t do anything with this like you’re describing.
- ori_b 5y ago> If you compile code on a machine with SSE or AVX and run it on an old Pentium, does it crash? Yes. Or it leaves them unused on the machine with avx. For short runs of instructions, the overhead of fallback selection is larger than the overhead of using the least common denominator. For large functions, fallback selection is done by selecting specific functions after benchmarking.
- rjsw 5y agoPlenty of open source packages probe for extensions when built for either X86_64 or ARM, then call fallback code if the extension isn't there. Things like OpenJDK, pixman, nss, ffmpeg.
- vbezhenar 5y agoIntel CPUs have plenty of optional extensions. Basically you're building two versions of machine code and choose correct one at runtime.
- MaKey 5y agoHow would that work if you have a hundred custom extensions?
- rwmj 5y agoApparently it works fine: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d
- MaKey 5y agoI wasn't aware that we already have so many extensions. But doesn't the binary get more bloated the more extensions you have?
- dzaima 5y agoIn practice, at least C compilers don't automatically generate code for multiple extensions, so you get the performance of the base ISA by default. This does indeed mean that every C program for x86-64 that isn't compiled with a specific target architecture just won't ever use AVX/AVX2/AVX-512/any other extension. There is the idea of profiles, i.e. a single nice name for a group of extensions so that there's something one could provide a precompiled binary for, but I don't know what, if any, are RISC-V's plans for that.
- makapuf 5y agoIsn't it the same with some ARM vendors ? Of course, a random foundry can't, but what's preventing Apple from including specific instructions on their core (not that it would make sense) or a specific coprocessor that may or may not be integrated ?
- saagarjha 5y agoApple does ship custom instructions on their code but does not expose it to third parties: their external compilers will not generate those instructions, and they remain in the kernel and system libraries where they can be hidden behind APIs without being directly exposed.
- deleted 5y ago[deleted]
- fake-name 5y agoSomething something gentoo is eating the world.
- makapuf 5y agoYou could say the same with ARM wrt intel.
- rwmj 5y agoThe Arm guy is talking nonsense as you'd expect. Fedora & the vast majority of packages have been ported to RISC-V since 2016/2017. Debian about a year later. I just started a PostgreSQL server on one of my (four) RISC-V machines here: ● postgresql.service - PostgreSQL database server Loaded: loaded (/usr/lib/systemd/system/postgresql.service; disabled; vend> Active: active (running) since Sun 2022-02-13 06:56:50 EST; 1s ago Process: 1861715 ExecStartPre=/usr/libexec/postgresql-check-db-dir postgres> Main PID: 1861722 (postmaster) Tasks: 8 (limit: 9510) Memory: 15.6M CPU: 262ms CGroup: /system.slice/postgresql.service ├─1861722 /usr/bin/postmaster -D /var/lib/pgsql/data ├─1861746 postgres: logger ├─1861752 postgres: checkpointer ├─1861753 postgres: background writer ├─1861754 postgres: walwriter ├─1861755 postgres: autovacuum launcher ├─1861756 postgres: stats collector └─1861757 postgres: logical replication launcher Feb 13 06:56:50 five systemd[1]: Starting PostgreSQL database > Feb 13 06:56:50 five postmaster[1861722]: 2022-02-13 06:56:50.> Feb 13 06:56:50 five postmaster[1861722]: 2022-02-13 06:56:50.> Feb 13 06:56:50 five postmaster[1861722]: 2022-02-13 06:56:50.> Feb 13 06:56:50 five postmaster[1861722]: 2022-02-13 06:56:50.> The biggest problem I had was remembering the name of the Fedora PostgreSQL package and that I had to initdb before starting the service. If the Arm CEO really believes software compatibility/availability is Arm's moat then I'm afraid he's in for a big shock.
- MaKey 5y agoWhich RISC-V machines do you have?
- geokon 5y agoWhile Intel is talking and investing the Chinese are already putting out chips and boards https://www.cnx-software.com/2022/02/13/arm-or-risc-v-mangopi-mq-tiny-4x4cm-linux-board-with-wifi/ https://www.cnx-software.com/2022/02/13/arm-or-risc-v-mangop... https://www.cnx-software.com/2021/12/30/sipeed-lichee-rv-risc-v-module-gets-5-carrier-board-with-hdmi-and-usb-ports-optional-wifi/ https://www.cnx-software.com/2021/12/30/sipeed-lichee-rv-ris... There are also the expensive dev boards from SiFive as well as the softcores from zepan. I think Alibaba and Rockchip will be available soon as well Jean-Luc's website is great for tracking this space: https://www.cnx-software.com/news/risc-v/ https://www.cnx-software.com/news/risc-v/
- trasz 5y agoNot Linux, but riscv64 FreeBSD works quite well.
- snvzz 5y agoSo does the RISC-V Haiku port.
- throw0101a 5y ago* https://wiki.freebsd.org/riscv https://wiki.freebsd.org/riscv * https://papers.freebsd.org/2019/fosdem/bennett-riscv_llvm/ https://papers.freebsd.org/2019/fosdem/bennett-riscv_llvm/
- upofadown 5y agoOpenBSD has some support with 7.0: * https://www.openbsd.org/riscv64.html https://www.openbsd.org/riscv64.html
- londons_explore 5y agoARM also has a good chunk of compatibility issues... There are plenty of times I've had ARM7 vs NEON vs thumb vs big endian/little endian issues... Even today, getting random debian packages running on a raspberry pi, I've hit issues of SIGILL due to packages being compiled with the wrong compiler for my CPU...
- goodpoint 5y ago> How long does it take until we have server-side Ubuntu Linux Debian is almost entirely ported to RISC-V and it's been the biggest early adopter. 96% of the packages are ported: https://wiki.debian.org/RISC-V#Progress https://wiki.debian.org/RISC-V#Progress What is missing is powerful and inexpensive CPUs. (Easier said than done)
- ido 5y agoMaybe this is naive - but why is software compatibility so important for servers (that mostly run open source software, like psql)? I assume none of it is written in ARM/x86 assembly language and all of it in higher level languages like c/c++/python/java/js/etc that can be compiled/run on RISC-V?
- pid-1 5y agoWhen rpi was a new thing writing Python in it was a pain in the ass. You had to compile a lot of stuff from source, which was a huge time sink. To this day writing ARM lambdas on AWS has its own gotchas. Idk, I think their CEO has a point, it's just that it might be a short lived one given how much money Chinese companies are throwing at risc V.
- NelsonMinar 5y agoOld timers remember when "compiling open source C code to this other platform" was a real chore. Ever run the old school GNU configure and watched the giant stream of compatibility tests for weird architectures that go by? It's for a reason, one nearly forgotten in our current amd64 monoculture. The good news is even if the CPU is weird the C compiler is likely to be clang and the OS is likely to be some Linux/glibc variant. A lot of the old porting challenges had to do with OS and compiler differences.
- stefan_ 5y agoThis is just the peak of irony from the guys that couldn't be bothered to copy ACPI for 30 years plus requiring anything running on ARM to set up a bespoke firmware build. That's before you get into all the hard/soft-float, thumb, non-thumb mess and toolchains targeting ARMv6jwzufgka.
- mnd999 5y agoI honestly done understand they hype around RISC-V, it’s seems like reinventing the wheel. Sure it’s open, but so is OpenPower; and that’s a lot more mature with better software support. I’m sure it’s not the only one either. Everything new is old I guess. Edit: Tesla lies in their marketing, the industry is sexist, Rust is overhyped, Wayland still isn't very usable. If I'm gonna get downvotes, I might as well go big.
- boondaburrah 5y agoI mean you're right, but OpenPower showed up late to the game, after the RISC-V hype train was already going, almost as if IBM wanted to derail it. (More likely IBM saw RISC-V prove that it was viable and wanted people to be using Power instead. (So not so much derail it as derail it and put me on the rails instead))
- throw0101a 5y agoSPARC has been open for decades: * https://sparc.org https://sparc.org There have been non-Sun/Oracle CPUs available since the 1990s. Fujitsu sells entire product lines on them (and there's a Top 500 cluster built around SPARC.) This also included the 'BIOS' (IEEE 1275-1994): * https://en.wikipedia.org/wiki/Open_Firmware https://en.wikipedia.org/wiki/Open_Firmware And accessory bus (IEEE 1496-1993): * https://en.wikipedia.org/wiki/SBus https://en.wikipedia.org/wiki/SBus
- audunw 5y agoI dont think SPARC is a very good ISA. Before RISC-V there was also OpenRISC, which early on had some of the same traction as RISC-V in the open source community. But both SPARC and OpenRISC has branch delay slots, which was, if I remember correctly, one of the things the designers of RISC-V wanted to avoid to have a more scalable ISA. Branch delay slots are supposedly a big issue when designing high end superscalar cores. RISC-V is very well thought out when it comes to scaling from the smaller MCU cores to the largest supercomputer CPUs. With a coming revision the code density with the compressed extension is even better than ARM Thumb, while being better designed than Thumb (no mode switching)
- unwind 5y ago> Not unexpectedly, Nvidia this week pulled the plug on its bid to buy RISC-V competitor Arm after the $66 million deal was scuppered by regulators in multiple jurisdictions. Million, really? Off by a factor of 1,000?
- foobiekr 5y ago"RISC-V competitor" At this moment, the relevant information about Arm is that it competes with x86. RISC-V is no more relevant than Elbrus, though obviously that's going to change.
- FullyFunctional 5y agoThis statement doesn't appear grounded in facts. Arm was clearly concerned with RISC-V _years_ ago and the competition from RISC-V is far more severe today. I don't claim that Arm will go away anytime soon, but RISC-V is a viable alternative especially in the embedded realm and that will be used for pricing pressure. Long-term, I suspect economics will play out as they always do in the tech sector.
- ramshanker 5y agoSometimes, I wonder, what if Jim Keller decided to take on RISC-V and delivered an open source implementation, which is as good as current x86 or ARM hardware. People / companies would move swiftly I guess.
- abdullin 5y agoJim Keller is building RISC-V Ascalon processor at Tenstorrent right now. https://youtu.be/KOHQQyAKY14 https://youtu.be/KOHQQyAKY14 If I recall correctly, some things were planned to be open sourced.
- hajile 5y agoIt's a 6-issue design supposedly, so it should be about as wide as the ARM X1/X2 chips. If they open source this design, it could be very interesting for ARM moving forward.
- IMSAI8080 5y agoRISC-V is going to bite at the low end embedded market where pennies matter, but it'll be a while before it eats into ARM at the mid to high end. ARM is offering non-discriminatory licenses at unit prices that are largely an irrelevance on the retail cost of a mobile phone or laptop. So it's going to take a long time to convince manufacturers that they want a non-compatible chip versus a few cents extra to get the well known one with all the support.
- gorgoiler 5y agoCould you quantify it a bit more precisely: how much of that $1000-per-phone goes to ARM?
- IMSAI8080 5y agoNot easily as their terms are private, but you can tell it's not a huge slice. Fairly well every phone and all manner of other devices uses an ARM but I'm googling their royalty revenues at $1.3 billion dollars annually. So that's not much per device shipped. Stuff you hear suggests maybe they get 1% on the sale price of a CPU. Note that's the CPU price, not the phone. The CPU in a phone might cost e.g. $20 so they maybe get 20 cents off that. I expect they have other revenues from design assistance and support etc but those costs would apply to a RISC-V device also.
- sudosysgen 5y agoA high end Snapdragon CPU is maybe 70$. It's unlikely they're making more than a dollar or two on a 1000$ phone.
- gumby 5y agoEverything is confidential, but you can get an idea. Arm's revenue on a phone CPU likely pennies, or at the highest end a buck. They just make it up in volume. The interesting point is how. First, you can see from a recent HN post that an electric toothbrush contains a 32-bit ARM CPU. If you've built any hardware you'll know that your BOM is king, and you try to squeeze that on the back of your OEMs. So Philips isn't paying much for that CPU and the CPU vendor (who could be Philips) would choose a different CPU if the royalty payment was too high. By taking a tiny bite out of a huge number of parts ARM both spreads out its risk (the parts are ubiquitous) and starves the market of oxygen: there just isn't enough revenue for many or any competitors to get started. They'd have to lose money for years, or even decades, to get to the break even point. And don't forget what ubiquity means: that phone doesn't have an ARM CPU: there is ARM logic in all sorts of devices inside the phone, from the baseband processor to probably integrated logic in the camera (even if the CPU has ISP logic) to USB PHYs to who knows what. With a few pennies or less on each one. Those headline CPUs may have the highest royalty rate for all we know. The real question is why Apple uses ARM. Yes they have a longstanding history back to the founding of ARM but they are masters of cutting their BOM. They have an architectural license, and have their own microarchitecture. They make their own toolchain soup to nuts. They don't have to worry about compatibility with anyone outside their ecosystem. So why bother to pay anything to ARM? I've been asking around and the best (and consensus) theory I've been able to get is patents. That architectural license would presumably contain rights to all of ARM's patents. If that theory is correct, that's a huge threat to RISC V. I doubt ARM would ue, or even threaten to sue any RISC V user now: they'd look like Goliath beating up David. But once RISC V starts to get noticeable traction, and especially if ARM is a public company, patent licensing will start to matter. Their smartest strategy would be to pull a Microsoft and force companies to simply pay ARM a royalty for every RISC V they ship. Note: I'm a fan of the RISC V and not particularly a fan of ARM. But I recognize that ARM has played the long game quite well.
- klelatti 5y agoIt should be clear what is happening here. Intel sees Arm as a competitive threat in its high margin desktop and server cpu business. Supporting RISC-V as an Arm competitor at the low end weakens Arm and lessens that competitive threat.
- marcosdumay 5y agoIs it better to poke or not to poke a bear? I guess it depends on the bear being awake and what you poke it with. A move like that could just as easily push ARM to go all in on servers and desktops and harm Intel even more.
- klelatti 5y agoMore like the bear poking a sheep in this case! Seriously though the key issue now is does Arm have resources to invest in better designs - weaken cashflow and that’s in doubt.
- marcosdumay 5y agoWell, it ARM is harmless, than Intel has no reason to fear them and place them explicitly on their strategy.
- jl2718 5y agoI think the key enabler for architecture diversity will be a jit-based OS kernel. Interpreters are an N-to-N problem, and build systems often fail. IR distributions seem most robust.
- hajile 5y agohttps://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- _448 5y agoI hope this not an "embrace, extend and extinguish" strategy. If the ARM and Nvidia deal had gone through, it would have been a major headache for Intel. Now that is off, Intel has less things to worry about on the architecture front apart from RISC-V.
- hajile 5y agoThe ISA is moving toward being a commodity and nothing is going to stop that. Intel has more money to put into chip design. They already have all the IP and patents for the non-RISCV parts of the chip and chipset. They could literally design a drop-in replacement in their current motherboards and go straight to market years before all this stuff gets tested and shipped by the competition. Just as important, they have the business connections and reputation of delivering. Those may be less tangible, but the best chip in the world doesn't mean anything if you can't move it to customers. They seem very strongly positioned even if they never have any input into the ISA itself.
- jabl 5y agoThey have an even stronger position in x86, where they are the dominant player in a duopoly, with new entrants denied access. So yes, they might be interested in helping RISC-V in order to hurt Arm on the low end, but I'm sure they're not looking forward to RV eating a chunk of the x86 market.
- hajile 5y agoThey are getting stomped by ARM on the high-end too. X2 is quite a bit faster per clock than every x86 (except maybe golden cove). It's only a matter of time before these start flowing into the high-end market and disrupt. Jim Keller is currently overseeing a 6-issue RISC-V core (same width as Intel's latest/greatest golden cove chip) that will allegedly be open-sourced too. This is a very dangerous situation for them. It seems better to milk x86 for all it's worth while leveraging RISC-V for all it's worth. If they can offer custom x86 compatibility with their RISC-V designs, that's just one more way to ensure they cut out the rest of the market and keep their lead.
- justahuman74 5y agoRISC-V will win because there will be intense competition to be the best cpu core IP for any given market segment. Whereas ARM & x86 each have only a couple of companies competing with each other once you're fully committed to using them.
- klelatti 5y agoThere are 15 firms with Arm architecture licenses almost all designing 64 bit cores - seems quite competitive to me.
- snvzz 5y ago>seems quite competitive to me. Not very competitive when the only company that can license ARM cores to third parties is ARM itself.
- klelatti 5y agoThe real money is in SoCs or end user devices not processor IP. Thus that’s where the resources to build the best cores will tend to go. If you had a second Arm selling licensed cores against Arm v1 would competition result in better cores? Maybe but it’s equally likely that it would make it harder for either company to compete for talent against Apple and Qualcomm.