Live data from Hacker News

RISC-V is now officially supported by CPython

blog.python.org

51–60 of 76 posts

Re: RISC-V is now officially supported by CPython

#51
post #29
post #28

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.

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.

Re: RISC-V is now officially supported by CPython

#52

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…

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?

Re: RISC-V is now officially supported by CPython

#53
post #28

Earlier quoted context omitted.

RISC-V fragmentation bites again...

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…

[deleted]

Re: RISC-V is now officially supported by CPython

#54
post #29
post #28

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.

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 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.

Re: RISC-V is now officially supported by CPython

#55

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.

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.

Re: RISC-V is now officially supported by CPython

#56
post #52

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…

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?

Vector extensions are the biggest gap. That is going to make a pretty big difference for some stuff.

Re: RISC-V is now officially supported by CPython

#57

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,…

So is 32bit out of scope? ESP32 devices are increasingly RISC-V but 32bit.

Re: RISC-V is now officially supported by CPython

#58

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…

RISC-V fragmentation bites again...

> RISC-V fragmentation bites again...

Wrong.

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.

Check back in 2 years.

Re: RISC-V is now officially supported by CPython

#59

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,…

So is 32bit out of scope? ESP32 devices are increasingly RISC-V but 32bit.

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.

Re: RISC-V is now officially supported by CPython

#60

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,…

[dead]
Post reply on HN