Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • amity
    replied
    Originally posted by spicfoo View Post

    This is why enabling it when upstream already is testing it makes more sense than enabling it globally.
    Yes that might be acceptable for now, but my concern is that -O3 in general does seem to cause a higher number of problems than -O2 in general, and I don't think there is any guarantee that that will improve in future versions, but I'm happy to change my opinion if that turns out not to be the case, I guess we will see.

    Leave a comment:


  • rogerx
    replied
    Originally posted by and.elf View Post
    1: Don't write python if you want performance
    Yup. Use sh/bash. ;-)

    Leave a comment:


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

    Leave a comment:


  • spicfoo
    replied
    Originally posted by amity View Post

    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.

    Leave a comment:


  • amity
    replied
    Originally posted by CommunityMember View Post

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

    Leave a comment:


  • Noitatsidem
    replied
    Originally posted by CommunityMember View Post

    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.
    Last edited by Noitatsidem; 14 April 2024, 03:00 PM.

    Leave a comment:


  • and.elf
    replied
    Originally posted by kylew77 View Post

    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

    Leave a comment:


  • kylew77
    replied
    Originally posted by and.elf View Post
    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.

    Leave a comment:


  • CommunityMember
    replied
    Originally posted by amity View Post

    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.

    Leave a comment:


  • caligula
    replied
    Originally posted by piotrj3 View Post

    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.

    Leave a comment:

Working...
X