Fedora 41 Looks To "-O3" Optimizations For Its Python Build

[phoronix]

Phoronix: Fedora 41 Looks To "-O3" Optimizations For Its Python Build

A change proposal has been filed for building the CPython interpreter and the Python standard library using the "-O3" compiler optimization flag rather than Fedora's imposed default of the "-O2" optimization level. This is being sought in the name of greater Python performance on Fedora 41...

https://www.phoronix.com/news/Fedora-41-O3-Python-Proposal

[npwx]

Oh what revolutionary changes, using O3 for python builds. Unfortunately, still no subarch support, just the usual "update a bunch of packages". I'm close to the point of dropping Fedora for something else on my servers. It seems development has stalled.

[user1]

Oh what revolutionary changes, using O3 for python builds. Unfortunately, still no subarch support, just the usual "update a bunch of packages". I'm close to the point of dropping Fedora for something else on my servers. It seems development has stalled.

What still bothers me is how anyone thought it was acceptable to enable frame pointers since Fedora 38 for pretty much everything instead of making it opt-in. Like yeah, I get it, for some Gnome and Facebook devs it's very useful for profiling in order to achieve even greater performance gains in their software. That doesn't explain why was it enable for almost the entire Fedora repo and not just for those who ask it to be enabled for their packages. This way, you will get performance gains for a tiny minority of packages as a result of the ability to profile, but guess what? Nobody is going to do that for the rest of the packages in Fedora repo, so all of them are now potentially experiencing 1-2% performance drop (if not more). And probably no one is going to notice that unless they'll do comparison benchmarks (and I'm sure no one is going to do that either). You may think "oh 1-2% is not a big deal", but you probably haven't heard that even 1% of performance gain may be worth a year of work in GCC.

[spicfoo]

Oh what revolutionary changes, using O3 for python builds. Unfortunately, still no subarch support, just the usual "update a bunch of packages"

Looking at the Fedora 41 change proposals that has just started out, there is a bunch of changes that are significant including Dnf5, ostree native containers and web UI for the installer. Of course, a lot of distro changes will always be updating to the latest version of upstream releases. Not everything needs to "revolutionary". Incremental changes like a performance improvement are often what users are looking for.

[Myownfriend]

Is it actually a Python interpreter or is it just called that? Why not use a JIT compiler and get much greater performance gains? Are their no Python JIT compilers? I never got into Python.

[spicfoo]

Is it actually a Python interpreter or is it just called that? Why not use a JIT compiler and get much greater performance gains? Are their no Python JIT compilers? I never got into Python.

Python will have JIT compiler in the near future. Compilers and interpreters are more loosely used terms these days. While the JIT compiler does gain you performance, it is orthogonal and additive to the performance gains from build compiler options.

[Myownfriend]

Python will have JIT compiler in the near future. Compilers and interpreters are more loosely used terms these days. While the JIT compiler does gain you performance, it is orthogonal and additive to the performance gains from build compiler options.

Oh I know it's additive to the gains from static compilation but if you're looking for performance improvements with an interpreter, the obvious thing to do is to not use an interpreter if you have a JIT as an option. But if the JIT isn't ready yet then that makes sense.

[and.elf]

1: Don't write python if you want performance

[nanonyme]

What still bothers me is how anyone thought it was acceptable to enable frame pointers since Fedora 38 for pretty much everything instead of making it opt-in. Like yeah, I get it, for some Gnome and Facebook devs it's very useful for profiling in order to achieve even greater performance gains in their software. That doesn't explain why was it enable for almost the entire Fedora repo and not just for those who ask it to be enabled for their packages. This way, you will get performance gains for a tiny minority of packages as a result of the ability to profile, but guess what? Nobody is going to do that for the rest of the packages in Fedora repo, so all of them are now potentially experiencing 1-2% performance drop (if not more). And probably no one is going to notice that unless they'll do comparison benchmarks (and I'm sure no one is going to do that either). You may think "oh 1-2% is not a big deal", but you probably haven't heard that even 1% of performance gain may be worth a year of work in GCC.

Something to keep in mind the xz exploit was found through running xz with framepointers in valgrind in production.

[caligula]

Is it actually a Python interpreter or is it just called that? Why not use a JIT compiler and get much greater performance gains? Are their no Python JIT compilers? I never got into Python.

Python users are fucking idiots. At the moment it's one of the slowest languages out there outside legacy stuff like bash/sed/awk/m4/perl/tcl. Java, C#, JavaScript, PHP, Hack, Go, Dart, C/C++, Lua(jit), VB.Net, Pascal, and all the others are much faster. Ruby is another slow language (that is, the main implementation is).