31–40 of 76 posts
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.
Earlier quoted context omitted.
RISC-V fragmentation bites again...
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 pro…
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.
Earlier quoted context omitted.
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…
For AP cores where Python actually runs it’s just “arm8” and pick your incremental version on top.
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?
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.
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 wi…
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.
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 wi…
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,…
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.
We've seen test failures like https://github.com/python/cpython/issues/151040
And perf support needs to be tested and merged https://github.com/python/cpython/issues/121201
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.
Earlier quoted context omitted.
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,…
You can just use QEMU. It has RVA23 support and is probably still faster and easier than using actual machines.
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 wi…
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,…
Earlier quoted context omitted.
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…
For AP cores where Python actually runs it’s just “arm8” and pick your incremental version on top.