RISC-V is now officially supported by CPython

(blog.python.org)

268 points by lumpa5 days ago

10 comments

ironhaven12 hours ago
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.[1]<a href="https://www.sifive.com/cores/performance-p800" rel="nofollow">https://www.sifive.com/cores/performance-p800</a>
- emmatyping8 hours ago
 Speaking unofficially, opinions my own, etc.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.
 - ccgreg7 hours ago
 How is this different from x86_64 and aarch64? Or even the various Alpha and Mips64 chips.
 - Marcuss25 hours ago
 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.
 - cbm-vic-203 hours ago
 The E extension will probably only ever appear in softcores (FPGA) to reduce gate count.
 Marcuss23 hours ago
 CH32V003 has RV32EC core, for RV64, yes, there is no point.
 - IshKebab8 hours ago
 You can just use QEMU. It has RVA23 support and is probably still faster and easier than using actual machines.
 - emmatyping7 hours ago
 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.
- camel-cdr10 hours ago
 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.
- shash1 hour ago
 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?
- londons_explore10 hours ago
 RISC-V fragmentation bites again...
 - Karliss9 hours ago
 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 <a href="https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html" rel="nofollow">https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html</a> . 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.
 - tubs9 hours ago
 For AP cores where Python actually runs it’s just “arm8” and pick your incremental version on top.
 - sweetjuly16 minutes ago
 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.
 - mort968 hours ago
 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?
 - ac291 hour ago
 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.
 - shash7 hours ago
 For RISC-V that would functionally be RV64GC then. And you go incrementally from there as required.
 - orangeboats9 hours ago
 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.
 - mort968 hours ago
 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.
- whateverboat5 hours ago
 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.
throwaway815239 hours ago
CPython is written in C, did running it on Risc-V take more than a recompilation? Were there any surprises? Yes of course it needs testing and RISC-V in the CI stack, but I'd expect fairly smooth sailing.
- emmatyping8 hours ago
 In short, we haven't found many bugs, but it also wasn't just recompile on a new platform.We've seen test failures like <a href="https://github.com/python/cpython/issues/151040" rel="nofollow">https://github.com/python/cpython/issues/151040</a>And perf support needs to be tested and merged <a href="https://github.com/python/cpython/issues/121201" rel="nofollow">https://github.com/python/cpython/issues/121201</a>Overall though, fairly smooth sailing as you say.The reason RISC-V wasn't already supported is a mix of lacking hardware access for build bots and committers willing to pledge time to support it.
- shash7 hours ago
 We ran it 4 years ago (including numpy) and it wasn’t a massive uphill climb or anything. It’s gotten a little easier since then if anything.
- tyingq8 hours ago
 There is a Configure type subsystem, so you'll see stuff like this: <a href="https://github.com/python/cpython/pull/156277/changes#diff-49473dca262eeab3b4a43002adb08b4db31020d190caaad1594b47f1d5daa810" rel="nofollow">https://github.com/python/cpython/pull/156277/changes#diff-4...</a>
- tlk-228153 hours ago
 We ran python-3.14 on RISC-V before switching to C++ only. It compiled without any errors and all tests passed.I don't understand the significance of this announcement in the submission.
- rzulasf6 hours ago
 Yes, RISC-V usually compiles out of the box. They just need a new "milestone" so the corporations that hire the remaining mediocre core developers think they are doing something.It's the same with WASI integration. Two Junta members already commit to that failed project in order to show presence and activity.It is a cancel and buzzword driven project.
yyyk12 hours ago
Odd they still have i686-pc-windows-msvc as Tier 1 *. Even Microsoft doesn't have any supported 32bit Windows versions anymore, and C extension modules likely follow Linux (where Python doesn't have any no supported i686 triplets in any tier). It would be more modern to demote its Tier and promote aarch64 Windows or wasm32 instead to Tier 1.* <a href="https://peps.python.org/pep-0011/#tier-1" rel="nofollow">https://peps.python.org/pep-0011/#tier-1</a>
- woodruffw12 hours ago
 Python's tiering has to do with testability and availability thereof, not modernness. In the case of 32-bit Windows, the reason it's still testable is because Windows still ships a 32-bit userspace, even if Windows itself only supports x86-64.(From personal experience, testing Windows aarch64 is a massive PITA, even on GitHub Actions, which all common sense would indicate should have the best aarch64 Windows CI runner story.)
yjftsjthsd-h15 hours ago
> RISC-V is now officially supported by CPython as a tier 3 platform!That's significant, but tier 3 is still a caveat. Still allowed to break without blocking anything or being fixed as a priority.
- jmalicki15 hours ago
 Sure, but I had to look:Tier1: Windows x64/i686, Linux x64/ARM gcc, Darwin/ARMTier2: Linux x64/ARM w/ clang, Windows ARM, WASM, Darwin/x64Tier3 is a pretty low support level, but tiers 1 and 2 is a pretty short list of major commercial platforms. Also even for developers to fix, availability of e.g. RiscV machines in the cloud to reproduce and fix on is still somewhat limited.
 - zxexz12 hours ago
 Windows i686, tier 1, what? I’ll do some digging when I’m home but I feel the sudden need to understand this.
 - zxexz12 hours ago
 Oh, wow<a href="https://learn.microsoft.com/en-us/lifecycle/products/windows-10-iot-enterprise-ltsc-2021" rel="nofollow">https://learn.microsoft.com/en-us/lifecycle/products/windows...</a>
 - jmalicki11 hours ago
 Interestingly embedded 32 bit Linux is not tier 1 or 2 though :)
- phire14 hours ago
 Needs to start somewhere.Looks like the most important step towards tier two is mostly about proving the CI infrastructure is reliable (which takes time at tier 3), and have at least two core developers committed to fixing any issues (within 24 hours)
 - boredatoms14 hours ago
 Atleast CI-class hardware finally exists, with the sifive bigsky<a href="https://www.sifive.com/development-platforms/sifive-bigsky-sf-2u870-datacenter" rel="nofollow">https://www.sifive.com/development-platforms/sifive-bigsky-s...</a>
- digkls14 hours ago
 RISC-V is one of those experimental architectures that hardly anyone is actually using, isn't it?Tier 3, or no support at all, seems an appropriate designation.
 - boredatoms14 hours ago
 Not much on user facing OS, but billions of small controllers
 - yjftsjthsd-h13 hours ago
 I don't think CPython targets those, though; that seems more like a micropython thing?
Qem6 hours ago
Did they already test how the proposed jit fares on RISC-V?
greatgib10 hours ago
For quite some times I'm wondering how I could invest in RISC, or RISC related manufacturer but it looks like all companies are private.
- boredatoms3 hours ago
 Check out Hiive and make a bid if you want Sifive stockalso Andes is public
jartan20023 hours ago
[flagged]
fenestella13 hours ago
[dead]
scam-alt-human12 hours ago
[flagged]
- zopppo11 hours ago
  How is Python a dead language due to ML when it's the lingua franca of AI/ML between pytorch, pandas, numpy, langchain, litellm, vLLM, and a whole bunch of other libraries?
  - __patchbit__10 hours ago
    Unison.
gagan202010 hours ago
Can we do something about CPython Global Interpreter Lock (GIL)?
- bonzini10 hours ago
 Free threaded Python - optional but supported<a href="https://docs.python.org/3/howto/free-threading-python.html" rel="nofollow">https://docs.python.org/3/howto/free-threading-python.html</a>
 - gagan202010 hours ago
 I didn't know about that but it feels like Django async support.