Announcement

Collapse
No announcement yet.

LPython 0.22 Released For Ahead-Of-Time Compiler For Python

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

  • LPython 0.22 Released For Ahead-Of-Time Compiler For Python

    Phoronix: LPython 0.22 Released For Ahead-Of-Time Compiler For Python

    LPython is an in-development open-source project aiming to be a very fast Python compiler with multiple back-ends. Released this week was LPython 0.22 as the latest step in this crusade...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I recall hearing years ago that Python couldn't be compiled because it was too dynamic. I wonder how true that was, or if this compiler had to invent some new compilation methods, or had to make any sacrifices. I also wonder how it holds up to native binary libraries like numpy which are notoriously tied into cpython.

    Comment


    • #3
      Python is so slow that nobody wants to stick with CPython it seems...

      Comment


      • #4
        Originally posted by rmfx View Post
        Python is so slow that nobody wants to stick with CPython it seems...
        It's still single threaded. That's really why, even if you implement perfect threading it still issues each thread one at a time to the interpreter.

        Comment


        • #5
          Originally posted by Ironmask View Post
          I recall hearing years ago that Python couldn't be compiled because it was too dynamic. I wonder how true that was, or if this compiler had to invent some new compilation methods, or had to make any sacrifices. I also wonder how it holds up to native binary libraries like numpy which are notoriously tied into cpython.
          I don't know if dynamic is the right word, more like it doesn't have the means to be coherent. If you try to do things in parallel you can run into situations where one thread can modify data before another thread can deal with it. It's the reason why each thread gets issued to the interpreter one at a time only. Even if you do perfect threading the language itself can't.

          Comment


          • #6
            Originally posted by duby229 View Post

            I don't know if dynamic is the right word, more like it doesn't have the means to be coherent. If you try to do things in parallel you can run into situations where one thread can modify data before another thread can deal with it. It's the reason why each thread gets issued to the interpreter one at a time only. Even if you do perfect threading the language itself can't.
            Isn't this why everyone uses some third-party event loop or punts everything to a compiled module written in Rust or C which can do threading properly independent of the interpreter?

            I don't think Python has ever had a good story here.

            Comment


            • #7
              Originally posted by ahrs View Post

              Isn't this why everyone uses some third-party event loop or punts everything to a compiled module written in Rust or C which can do threading properly independent of the interpreter?

              I don't think Python has ever had a good story here.
              Yeah, it's why all the number crunching stuff is in C.

              And while the GIL sucks and is one of the many shining examples of how utterly inept the people who designed the language are, I do have the point out that I/O operations are async which is where the largest bottleneck would be for most programs. Most programs are fine with being single-threaded once waiting for I/O is out of the way, so Python actually rarely has an issue here. The only issue is the async runtime absolutely sucks and is miserable to deal with, worst async experience I've ever had, and yes that includes Rust.

              Comment


              • #8
                Originally posted by Ironmask View Post

                Yeah, it's why all the number crunching stuff is in C.

                And while the GIL sucks and is one of the many shining examples of how utterly inept the people who designed the language are, I do have the point out that I/O operations are async which is where the largest bottleneck would be for most programs. Most programs are fine with being single-threaded once waiting for I/O is out of the way, so Python actually rarely has an issue here. The only issue is the async runtime absolutely sucks and is miserable to deal with, worst async experience I've ever had, and yes that includes Rust.
                That's pretty much what makes it a great shell or script interpreter. But I wouldn't implement libs or apps with it.

                Comment


                • #9
                  Originally posted by Ironmask View Post
                  I recall hearing years ago that Python couldn't be compiled because it was too dynamic. I wonder how true that was, or if this compiler had to invent some new compilation methods, or had to make any sacrifices.
                  Well, it needs to be typed, for starters. Otherwise it cannot optimise much. Years ago, type annotated python code was not really a thing.

                  Comment


                  • #10
                    Originally posted by rmfx View Post
                    Python is so slow that nobody wants to stick with CPython it seems...
                    Not really, Python isn't the fastest but for most stuff you don't need extreme performance. Sure you wouldn't write a database server to hundreds of thousands transactions in Python, but for small scripts and applications Python is fast enough.

                    The problem with Python is that you cannot do top-level awaits, you have to specify an async runtime, urllib sucks, it doesn't come with any decent HTTP client, you cannot deserialize JSON to a class, the standard library isn't even type hinted, and type hinting sucks in Python.

                    Originally posted by Ironmask View Post
                    And while the GIL sucks and is one of the many shining examples of how utterly inept the people who designed the language are, I do have the point out that I/O operations are async which is where the largest bottleneck would be for most programs. Most programs are fine with being single-threaded once waiting for I/O is out of the way, so Python actually rarely has an issue here. The only issue is the async runtime absolutely sucks and is miserable to deal with, worst async experience I've ever had, and yes that includes Rust.
                    Well, for a long time the Linux kernel had something similar to the GIL called the Big Kernel Lock (BKL).
                    In PHP and JavaScript they type juggle when doing comparisons so in some applications you authenticate using the token "true" as it will type cast that into the boolean value true.

                    I agree async in Python is not so good (there is no top-level await) at least it has async, unlike PHP.

                    For all the problems with Python (and there are many), in my opinion it is still nicer than Perl, Raku, Tcl, and Ruby.
                    GIL might suboptimal but there are plenty of other programming languages which have plenty of weirdness and stupid design decisions and inept developers.

                    Comment

                    Working...
                    X