Announcement

Collapse
No announcement yet.

Python 3.11 Performance Benchmarks Are Looking Fantastic

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

  • #11
    Originally posted by marios View Post
    Dear python,
    you are a slow scripting language. You are only getting improvements in performance because your baseline sucks. You are not fast. You will never be fast. You are suboptimal by design. Now do something useful and try to persuade anyone who cares about performance to use a compiled language instead of slow scripting languages. And stop trying to be fast, you will never be. Any attempt to optimise something suboptimal by design will result in something suboptimal by design. Accept your fate at last and stop tormenting us.
    I'm not sure what the problem is. Python runs on top of a runtime environment. What's wrong with improving the performance of that runtime?

    Comment


    • #12
      Originally posted by marios View Post
      Dear python,
      you are a slow scripting language. You are only getting improvements in performance because your baseline sucks. You are not fast. You will never be fast. You are suboptimal by design. Now do something useful and try to persuade anyone who cares about performance to use a compiled language instead of slow scripting languages. And stop trying to be fast, you will never be. Any attempt to optimise something suboptimal by design will result in something suboptimal by design. Accept your fate at last and stop tormenting us.
      Let me know when something other than Python or Java has memory-safe bindings to Qt's QWidget APIs. Until then, I'll be using Python... with some Rust if there's room for a clean frontend-backend separation.

      Likewise Django and its reusable apps over its alternatives.

      To paraphrase Steve Ballmer: Ecosystem Ecosystem Ecosystem Ecosystem

      Comment


      • #13
        Originally posted by marios View Post
        Dear python,
        you are a slow scripting language. You are only getting improvements in performance because your baseline sucks. You are not fast. You will never be fast. You are suboptimal by design. Now do something useful and try to persuade anyone who cares about performance to use a compiled language instead of slow scripting languages. And stop trying to be fast, you will never be. Any attempt to optimise something suboptimal by design will result in something suboptimal by design. Accept your fate at last and stop tormenting us.
        God forbid anyone ever spend any time optimizing anything! Everything should be 100%, entirely optimized and perfect from the get-go and if it's not, it's literally the worst garbage ever. Any attempts at optimizing or improving anything are harmful and offensive to you personally and must be avoided and anyone who dares to attempt such unspeakable acts should be taken behind the shed and shot!

        Comment


        • #14
          Originally posted by bug77 View Post

          I'm not sure what the problem is. Python runs on top of a runtime environment. What's wrong with improving the performance of that runtime?
          Don't bother, it's just someone who got confused and thought this was Slashdot, where you can be awfully inexact while remaining super smug because nobody knows better.

          Comment


          • #15
            Originally posted by bug77 View Post

            I'm not sure what the problem is. Python runs on top of a runtime environment. What's wrong with improving the performance of that runtime?
            The problem is that it will never be fast enough. It will always be orders of magnitude slower than C, C++, Rust etc. So the effort should go to porting python applications that suffer from poor performance to compiled languages instead.

            Comment


            • #16
              Originally posted by hax0r View Post
              I hope python 3.11 speeds up 'emerge' command on gentoo
              As a Gentoo user, I find their decision to use python for Portage the worst design decision they ever made.

              Comment


              • #17
                Originally posted by marios View Post
                The problem is that it will never be fast enough.
                Python is already fast enough for what it's supposed to do.

                Originally posted by marios View Post
                It will always be orders of magnitude slower than C, C++, Rust etc. So the effort should go to porting python applications that suffer from poor performance to compiled languages instead.
                No scripting languages will ever be as fast as properly compiled code. Are you suggesting interpreted languages should never receive performance optimizations?

                Comment


                • #18
                  Originally posted by bug77 View Post

                  Python is already fast enough for what it's supposed to do.
                  i agree, the problem here is that it is abused. It is supposed to be used for scripts, it is not used for performance critical applications as well (portage is an example for that).

                  Originally posted by bug77 View Post

                  No scripting languages will ever be as fast as properly compiled code. Are you suggesting interpreted languages should never receive performance optimizations?
                  Not quite. I suggest that people should avoid interpreted languages if performance might be an issue. But since effort on writing software is limited, it would be more beneficial to spend this effort on rewriting applications and libraries (and their APIs) in compiled languages than optimising interpreters.

                  Comment


                  • #19
                    Originally posted by marios View Post
                    I suggest that people should avoid interpreted languages if performance might be an issue. But since effort on writing software is limited, it would be more beneficial to spend this effort on rewriting applications and libraries (and their APIs) in compiled languages than optimising interpreters.
                    Why? If it works well enough, it works well enough.

                    Comment


                    • #20
                      Originally posted by marios View Post

                      it would be more beneficial to spend this effort on rewriting applications and libraries (and their APIs) in compiled languages than optimising interpreters.
                      By what logic? Are you under the impression that Python-devs are behind every single application and library written in Python? News-flash: Python-devs working on improving Python does not take anything away from any other developers, who are entirely free to do what they want -- it would, indeed, be possible for Python-devs to keep on optimizing Python while the developers of this or that application could be e.g. rewriting their application in some other language simultaneously.

                      Comment

                      Working...
                      X