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

[amity]

The only possible downside expressed so far is the possibility of a slightly larger Python package

I'm not sure about that... I have personally seen -O3 introduce some VERY strange bugs in many programs.

[caligula]

There is a lot of use cases when benefits of python heavy outweights performance issue. Example : webrowser integration tests. Realistically speaking good selenium/playwright etc. bindings have 4 languages : Java, C#, Python and JS. There are some lesser known but often they are not well maintained and have problems.

Java, C# force you to write a ton of boiler plate, when you debug and make small change instead of instantly testing change you want it to recompile, rerun what takes time.

JS - let's be honest JS is not good language. And stuff like TS and some stuff still needs building step.

Python - you don't write boiler plate, you don't wait for things to build, entire ecosystem is simple and in my expierience dependency selenium requires less often updates than for java.

I am not doing integration tests for a while but when i asked any tester who did those and tried python always prefered python over competition. 99% of performance lies in webrowser itself that python doesn't affect.

Yes I know selenium and agree python works there. But that doesn't mean Python is the only suitable language for the job. Julia and Lua would perform much better if there was a similar framework available. When there's Java/JVM integration, you can use Kotlin, Scala, Clojure, Groovy, and other JVM languages as well. E.g. Kotlin and Groovy are better suited for scripting. Still there's the need for compilation.

Now if you think of Linux distros, Python is more often used for actual production apps, not for testing. Plugins for bigger applications, full GUI apps written in Python. Some of those make sense, some don't.

[CommunityMember]

I'm not sure about that... I have personally seen -O3 introduce some VERY strange bugs in many programs.

As mentioned in the proposal, Python itself uses -O3 for it's various CI/QA testing, so while it is very true every compiler version has it's own set of bugs, -O3 has been extensively tested with/by Python. While in the early days of gcc -O3 had some issues, it now is considered (by the gcc team) to be a good choice for most (as with any optimization, sometimes the code actually gets slower). Where -O3 is known to generate interesting results is where the code depends on a certain implementation of what is undefined behavior in C. Various code analysis tools (and gcc itself) now better report such undefined behavior cases allowing them to be fixed.

[kylew77]

1: Don't write python if you want performance

YEP! That is what I was taught in my BS in CS program. Prototype in Python or Perl then implement the final program in C. It just seems no one knows how to write C any more.

[and.elf]

YEP! That is what I was taught in my BS in CS program. Prototype in Python or Perl then implement the final program in C. It just seems no one knows how to write C any more.

They taught you wrong
Prototype in Python, release, profit.
And, C isn't all that great for everything. Sure you CAN do everything, but you really shouldn't. There is no point reimplementing internal tooling in c, for example

[Noitatsidem]

As mentioned in the proposal, Python itself uses -O3 for it's various CI/QA testing, so while it is very true every compiler version has it's own set of bugs, -O3 has been extensively tested with/by Python. While in the early days of gcc -O3 had some issues, it now is considered (by the gcc team) to be a good choice for most (as with any optimization, sometimes the code actually gets slower). Where -O3 is known to generate interesting results is where the code depends on a certain implementation of what is undefined behavior in C. Various code analysis tools (and gcc itself) now better report such undefined behavior cases allowing them to be fixed.

This is the correct answer. When -O3 generates buggy code, fix it! The gentoo policy of making bug reporters switch to -O2 made sense years ago, but not so much today.
That being said in recent versions of GCC auto-vectorization is on with -O2 so some of the gains that you used to get from -O3 are present in -O2 now.

[amity]

As mentioned in the proposal, Python itself uses -O3 for it's various CI/QA testing, so while it is very true every compiler version has it's own set of bugs, -O3 has been extensively tested with/by Python. While in the early days of gcc -O3 had some issues, it now is considered (by the gcc team) to be a good choice for most (as with any optimization, sometimes the code actually gets slower). Where -O3 is known to generate interesting results is where the code depends on a certain implementation of what is undefined behavior in C. Various code analysis tools (and gcc itself) now better report such undefined behavior cases allowing them to be fixed.

I understand what you're saying and I agree that *should* be the case, but I and some others have absolutely continued to see strange behavior with -O3 (outside of using undefined behavior) across several different projects even in newer gcc versions like 11/12/13...

[spicfoo]

I understand what you're saying and I agree that *should* be the case, but I and some others have absolutely continued to see strange behavior with -O3 (outside of using undefined behavior) across several different projects even in newer gcc versions like 11/12/13...

This is why enabling it when upstream already is testing it makes more sense than enabling it globally.

[SophiaS]

I hope that Mojo becomes more and more a superset of Python. It's amazing fast but still Alpha.

[rogerx]

1: Don't write python if you want performance

Yup. Use sh/bash. ;-)