You could generate tests that give you 100% line coverage but the real test is if the thousands of subscribing players have the same experience which doesn't have the same agent friendly testing feedback loop
What RISC-V extensions is this built for? There is a target triple of riscv64-unknown-linux-gnu listed so i assume the baseline RV64GC that the Linux kernel is built against.
It makes sense to be conservative with a new architecture but new high performance RISC-V cores such as from SiFive[1] are going to meet RVA23. That standard has vector and bit manipulation extensions that could be used to improve performance with a python interpreter. I guess more testing needs to be done to see if raising the bar is useful.
We (CPython) currently only have access to RV64GC machines to test on, and so that is the defacto target we can currently support.
Personally, I hope to see RVA23 become the baseline in the future. But that will depend on adoption.
On the packaging side of things, the platform tag is manylinux_X_Y_riscv64. So far that has meant RV64GC. So before we set a baseline of RVA23, we will need to see where the community lands.
For example x86_64 has v1, v2, v3 and v4 baselines, this tells you which instructions they support (e.g. v4 has AVX-512, v3 has AVX2, etc.).
RISC-V RVA22 and RVA23 aren't too different in this regard. Each one prescribes which extensions must be supported by the processor. I saw RV64GC mentioned, this is just a shortening of RV64IMAFDC, so I for baseline instructions, M for multiplication and division, A for atomic, F for floating point, D for double precision floating point and C for compressed instructions.
You can have a baseline E profile instead of I (less registers, some other features stripped), but I don't think we will ever see manufactured RV64E core, trough RV32EC cores exist.
Another aspect of the x86_64 architectural swamp is that Intel deliberately makes their optimized math libraries fail if run on a chip that is not 'INTEL INSIDE'. That block totally ignores cpu feature bits.
I've always wondered if virtualization software vendors made everything claim to be INTEL INSIDE, just to avoid this problem.
32 bit RISC-V is pretty much limited to microcontrollers. There's no serious projects to create a Linux capable RV32 machine. Only FPGA soft cores and QEMU.
There is micropython, but just from the description, it's a separate project entirely with the same syntax, etc.
CPython needs you to also be running an operating system. And while it might be theoretically possible to get a NoMMU Linux running on an ESP32, that's generally not very useful for practical applications compared to micropython or something that's actually designed for a microcontroller.
That's plausible. The bigger constraint to defaulting to RVA23 is that users are running on, and building all of their wheels targetting, RV64GC. So unless our users adopt RVA23, it would be unwise to switch.
Great point. But QEMU is no longer faster than real hardware for the latest RISC-V chips.
You are right though that QEMU is probably faster than anything only capable of RV64GC (lacking RVA23). So QEMU would probably be a great option for the CPython team.
I wonder how much this matters for python.
As long as the important dependencies like numpy runtime dispatch RVV, it should probably be fine.
Zba would probably give a small boost. Zbb gives a substantial boost to perf for applications that use clz/popc heavily, but I don't think that would apply to python.
It’s not like GC isn’t a massive part of RVA23 - those are the basic instructions that handle 80-90% of all uses (including most of what CPython needs).
I’m sure one could do some optimizations on RVA23, but is it really worth it?
People bring this up to every RISC-V discussion but the same could be said for ARM or x86. For which ARM instruction set is built? Does this ARM cpu support integer division instructions, does support arm and thumb instruction encoding, only arm, only thumb, does it have a floating point unit, does it have neon, does it have MMU. Those are still relevant questions for ARM cores.
On x86 situation is even crazier https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html . Some of the more recent CPUs list ~60 optional features. Even if you look just at generic common profiles you have i386, i486, i586, i686, x86-64, x86-64-v2, x86-64-v3, x86-64-v4. Just a single family of vector instructions has 6 different versions for example: SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2. I am not even going to try counting all the variations and optional instructions of AVX512.
On one hand this is an important topic, especially in contexts like which X86-64 profile are the software in Linux distro official repositories targeting.
At the same time no one is bothered by 20 cent ARM mcu not having instructions for atomic memory access, supervisor, SIMD or even floating point.
So if anything RISC-V instruction set optional feature sets are probably better structured and less fragmented (for now) than the current situation with ARM and x86.
If you'd limit yourself to cores implementing the Application profile of ARM (Armv8-A etc), you'd do the same and limit yourself to cores implementing the Application profile of RISC-V (RVA23 etc). In that case, you can assume vector instructions and everything else.
If you don't, you get the exact same kind of question with ARM as with RISC-V. Do you use NEON or with SVE? Or do you conservatively compile without vector instructions at all even though it could possibly result in speed-ups for some loops?
I don't think you're giving ARM credit for the ever growing pile of features which are always optional or optional only on some versions of the ISA.
For example, can you use FEAT_CSSC to improve code size and performance? Well, if the target is <v8.7, the answer is no. If it's v8.7 or v8.8, well, then it depends on whether your specific implementation has it. Only after v8.9 is it mandatory.
Targeting armv8a is the moral equivalent of targeting RV64GC insofar as it will run on any application class core. Targeting that, however, leaves a fair bit of useful ISA enhancements on the table, and so you tend not to want to do that if you can get away with it.
Micropython runs on tons of stuff and while it isnt capital-P Python, its close enough for doing a wide variety of embedded work without learning a new language/libraries/etc.
The same problem exists for x86. Is $program built for x86-64 with SSE2? AVX2? AVX512? (I chose those three because they are programmer-visible. Programmers have to use intrinsics to exploit those ISA extensions effectively.)
For RISC-V the questions to ask are similar: Is this built for RVA20? Or RVA23? (The big feature of RVA23 is the Vector extension, again something that is programmer-visible)
Embedded RISC-V programmers will have to ask a lot more questions. But for most programmers the whole fragmentation thing is simply a giant meme repeated ad nauseam.
Intel has done such a good job keeping AVX512 support away from reaching ubiquitous adoption, it's insane. There are so many useful instructions in AVX512 which are just missing from AVX/AVX2 that you can't assume exist, even on modern CPUs, because Intel can't get their shit together.
The core problem was tying instructions to bit width. But I'm actually surprised that they didn't add AVX512 support through double pumped 256-bit operations like AMD did for a while.
What fragmentation? Find me a 64 bit RISC-V chip you want to run Python on that will not execute an RV64GC binary.
The issue is not fragmentation but ecosystem maturity. The exact same situation exists for all chips.
In most x86-64 Linux distros, CPython will be compiled to target x86-64v2. This means it will not use, for example, any of the latest vector math extensions that the x86-64v4 chip you are probably running is capable of.
The reason distros target the older profile is that not everybody has the latest hardware. There is no difference conceptually between x86-64 and RISC-V.
The difference with RISC-V is that RV64GC is more primitive than x86-64v2 and so it hurts more. And fewer people have RVA23 capable chips than have x86-64v4 chips. RVA23 is the RISC-V profile that describes essentially equivalent capabilities to x86-64v4.
But there is less RISC-V hardware in the wild in general. So, there is less legacy baggage to carry forward. RISC-V will go mainstream on a more modern profile than other chips.
Ubuntu 26.04 and newer require RVA23 support. And all new application class RISC-V processors will support RVA23. It will not be long before this is the standard RISC-V profile. It will probably happen before the x86-64 world standardizes on x86-64v4 (or even v3). So your “fragmentation” will be a bigger deal on x86-64 than on RISC-V.
But, today, projects like CPython are still using RV64GC level hardware. So, that is what they target.
Most of us do not have any desktop or server class RISC-V hardware. When we do, it will be capable of RVA23. And CPython will probably target that profile. Fragmentation has nothing to do with it.
One could always build libraries which people can use if they need the more high-performance cores. There is not much in the CPython core that will benefit though.
They already picked out a interconnect standard it is called 100 Gigabit Ethernet. They can interoperate with multiple different vendors using the sfp28 ports on the switch. I bet they are even working on new programmable hardware for a next gen 200 Gigabit Ethernet fabric with oxide controlling the entire stack from hardware to software
No? The website has units available here[0] in the US. I think this article is old. There must have been a very small first shipment that got sold out before the next batch came in
If they reverse engineered the drivers then why do they need a virtual cpu and a Linux kernel to run them. Is this reverse engineering or just installing software in a weird environment?
Speaking of not just gluing stuff together with usb/ip could one make a virtual WebUSB host kernel module that could be used by the Linux kernel USB stack? They most likely would not want to do that because then all of the code would be GPL and would have to be shared with the public.
reply