Announcement

Collapse
No announcement yet.

LPython 0.21 Released For Alpha-Stage Python AOT Compiler

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

  • LPython 0.21 Released For Alpha-Stage Python AOT Compiler

    Phoronix: LPython 0.21 Released For Alpha-Stage Python AOT Compiler

    As the first new release since last September, LPython 0.21 has been released for this alpha-stage Python ahead-of-time compiler written in C++. LPython remains focused on providing "the best possible performance" especially for numerical use-cases, cross-platform compatibility, and hopes to be able to eventually transform Python code over to C++ and Fortran or other languages...

    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 really do wonder how many people/orgs/projects really do use anything other than the standard CPython (and how often). Projects like these seem to be a good exercise on paper, but what traction do they really have?

    Comment


    • #3
      Originally posted by raystriker View Post
      I really do wonder how many people/orgs/projects really do use anything other than the standard CPython (and how often). Projects like these seem to be a good exercise on paper, but what traction do they really have?
      Yes organizations do and that's why they continue funding it but CPython is naturally the dominant implementation and at the moment, there is a Microsoft team working on improving performance there as well which will likely make some of the alternative implementations obsolete.

      Comment


      • #4
        Originally posted by raystriker View Post
        what traction do they really have?
        2 of the defining features of Python (and an attraction in many cases) are also "sometimes" 2 of the biggest flaws: a) lack of strict Typing and b) the interpreted nature (slower execution, less typing, deployment and dependency; just to name a few) . I'm not saying Python is bad, it's one of my most used and loved tools. But any attempt to alleviate these issues as an optional way is always welcome. Imagine you have the same Python script and can use it in a compatible way with such a compiler.

        Note, there exists a true CPython compiler with Nuitka. But it lacks Typing. From what I read LPython uses the existing Type Annotation and should be compatible. It seems to me as if Nuitka with additional check with MyPy is similar to LPython (in terms of Typing), but LPython does it at runtime?

        Comment


        • #5
          Nuitka is great to deploy to windows without having to install Python.

          Comment


          • #6
            Originally posted by raystriker View Post
            I really do wonder how many people/orgs/projects really do use anything other than the standard CPython (and how often). Projects like these seem to be a good exercise on paper, but what traction do they really have?
            I wouldn't worry too much about it. Sometimes developers tackle a project just to learn. That project may be a toy, but we still end up with better developers at the end.

            In particular, this kind of projects seem pretty pointless in a microservices world: develop fast using Python, see where your bottlenecks are, rewrite that in the performant language of your choice. But yes, not everything is a microservice.

            Comment


            • #7
              Originally posted by bug77 View Post

              In particular, this kind of projects seem pretty pointless in a microservices world: develop fast using Python, see where your bottlenecks are, rewrite that in the performant language of your choice. But yes, not everything is a microservice.
              Most things aren't and some like Amazon Prime discovered that microservices are inefficient for their purpose as well. Plenty of large applications like PyTorch continue to be developed in Python and hence performance will continue to matter.

              Comment


              • #8
                The problem with Python's performance is not the interpreter (this is essentially an O(1) lag) but its encouragement to use wrong data structures (strings+hash maps for everything) and algorithms. This is elevated because Python is "easy", so most of Python code was and will be written either by shitty programmers, or good programmers in a sloppy mode. Even if there is something done well and/or offloaded to some better language, it is likely to be buried in some hopeless glue code.

                Comment


                • #9
                  And the next Python implementation.

                  - PyPy (Python written in Pythgon)
                  - Jython (Python for the JVM)
                  - IronPython (Python for .net)
                  - CPython (I think the original Python written in C)
                  - LPython (written in C++ and is faster)
                  - RustPython (written in Rust)
                  - MicroPython (for micro controllers)
                  - Brython (compiles to Javascript)
                  - Sculpt (compiles to Javascript)
                  - Pyodide (compiles to WASM)
                  - Pyscript (compiles to WASM)
                  - RPython
                  - Cython (mostly compatible to Python, but faster)
                  - Pytson (also mostly compatible to Python and fast)
                  - ... etc.

                  I think CPython is the reference implementation.
                  And all the other Python implementations are different compatible to it.
                  And all are implementing different Python versions.

                  Comment

                  Working...
                  X