Announcement

Collapse
No announcement yet.

The Current State Of Pyston As An Open-Source, High Performance Python

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

  • The Current State Of Pyston As An Open-Source, High Performance Python

    Phoronix: The Current State Of Pyston As An Open-Source, High Performance Python

    A status update concerning the Dropbox-sponsored Pyston project was presented earlier this month...

    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 wonder what about PyPy the Dropbox folks decided was insufficient for their needs. That's just curiosity.

    I think it's clear that scripting languages, even JIT ones, can't quite match the raw performance of a good compiled language. At least not yet. But the work being done with Javascript is impressive - asm.js gets within a 3x factor of C on most benchmarks, and for mobile devices that's probably sufficient. I'm curious if in ten or twenty years every popular dynamic language - Python, Ruby, PHP, Perl, Scheme - will have at least one open source runtime that gives performance on par with the best Javascript implementations today.

    Comment


    • #3
      Originally posted by Michael_S View Post
      I wonder what about PyPy the Dropbox folks decided was insufficient for their needs. That's just curiosity.
      I seem to remember Pyston being suitable for Dropbox internal purposes before PyPy was, so it's probably just not wanting to upset the apple cart by changing from what they already know the quirks of.

      Originally posted by Michael_S View Post
      I think it's clear that scripting languages, even JIT ones, can't quite match the raw performance of a good compiled language. At least not yet. But the work being done with Javascript is impressive - asm.js gets within a 3x factor of C on most benchmarks, and for mobile devices that's probably sufficient.
      The whole point of asm.js is to restrict JavaScript to a subset that can be compiled ahead of time rather than JITed, so it's more akin to the RPython that PyPy itself is written in... and it seems to have been intended as a failed attempt to avoid the need for the WebAssembly spec currently in development.

      Comment


      • #4
        The thing with asm.js is that it's a "low-level subset" of regular JS meant as a compilation target. It doesn't actually help at all with running idiomatic JavaScript, it just lets you write C or C++ and run it in your browser with only a small performance penalty.

        Comment


        • #5
          Originally posted by Michael_S View Post
          ... think it's clear that scripting languages, even JIT ones, can't quite match the raw performance of a good compiled language
          Is it a question of pre-compiling? I thought that python|ruby kept compiled|opcode caches or everything to keep things fast? I thought it was a question of staticly typed languages, which are easier for a compiler to optimize?

          [disclaimer: I work almost exclusively in JIT languages, except for some personal Go projects]

          Comment


          • #6
            Originally posted by jaxxed View Post
            Is it a question of pre-compiling? I thought that python|ruby kept compiled|opcode caches or everything to keep things fast? I thought it was a question of staticly typed languages, which are easier for a compiler to optimize?
            I don't know about Ruby, but Python compiles to bytecode, rather than machine code. That bytecode still has to be interpreted at runtime.

            Comment


            • #7
              Originally posted by jaxxed View Post

              Is it a question of pre-compiling? I thought that python|ruby kept compiled|opcode caches or everything to keep things fast? I thought it was a question of staticly typed languages, which are easier for a compiler to optimize?
              Precompiling is fastest and relatively simple option on its own: in best case there is only program code, implementing desired program logic. And nothing else. Needless to say it works as fast as it could. Subject to compiler optimizations and instruction set though. E.g. if you'll tell compiler to use brand new AVX commands, program would just crash on older CPUs, which had no AVX commands, though most sophisticated programs like high profile video players are doing runtime CPU features detection to enable best possible codepaths, achieving best possible speed on particular system, because you can't have too much speed, etc.

              Though in case dynamic typing it could be hard to do, and if language can emit some extra code at runtime, it getting even more tricky. Interpretation is slow because program logic heavily mixed with interpreter code, which obviously takes some time to execute it and it actually takes MOST of cpu time. Not a big deal if these are text statements or bytecode. There is only one thing which is fast: feed opcodes to CPU and let it execute it directly. But machine code is rather low level, so mapping high level language to it could be quite a challenge. Jit is something in between of these approaches. I.e. idea is that most heavy code path could be optimized on the fly to be a native code, reaching speed more or less resembling that of compiled program. And JIT can also craft code using all commands system CPU supports, avoiding some issues of compiled programs. Disadvantage? Uhm, it can get rather big, rather complicated, and memory hogging is a hallmark of most JIT things, etc. And still, in case of dynamic languages, extra checks related to change of types can take a plenty of time (compared to pre-compiled program). In some cases it can be several times slower than compiled native code and it could be hard to do something about it, because you have to expect possible type changes everywhare and have to be ready to handle it. This implies plenty of extra code on the way.

              As for asm.js - this is really clusterfucked to my taste. Whatever, but JS is really shitty thing for intermediate representation of program. Something like LLVM IR would do like an order of magnitude better. So, first let's make square wheels, and then after getting idea ride seems to be bumpy, let's try to think what to do. And come out with idea we can dig road a bit, to match square wheel profile! Sure, just getting good wheel wouldn't be in Mozilla spirit. Their dumbass NIH syndrome paired with awful incompetence in many areas would kill them, IMHO.
              Last edited by SystemCrasher; 25 November 2015, 09:20 AM.

              Comment


              • #8
                Thanks for the responses and the discussion. I don't have anything to add.

                Comment


                • #9
                  Originally posted by SystemCrasher View Post
                  Sure, just getting good wheel wouldn't be in Mozilla spirit. Their dumbass NIH syndrome paired with awful incompetence in many areas would kill them, IMHO.
                  So I take it that you don't like Rust and the Servo project?

                  Comment


                  • #10
                    Originally posted by SystemCrasher View Post
                    As for asm.js - this is really clusterfucked to my taste. Whatever, but JS is really shitty thing for intermediate representation of program. Something like LLVM IR would do like an order of magnitude better. So, first let's make square wheels, and then after getting idea ride seems to be bumpy, let's try to think what to do. And come out with idea we can dig road a bit, to match square wheel profile! Sure, just getting good wheel wouldn't be in Mozilla spirit. Their dumbass NIH syndrome paired with awful incompetence in many areas would kill them, IMHO.
                    As far as I understand it, it was heel-dragging on allowing websites to be compiled beyond what a javascript prettifier could make comprehensible. Mozilla is now part of the collaborative effort to define WebAssembly. (A portable bytecode that, in current efforts, is poised to draw the best aspects of both Mozilla's asm.js and Google's PNaCL, the latter of which is derived from a subset of LLVM IR that's both portable and suited to being frozen into a standard that's stable into the indefinite future, unlike LLVM IR itself.)

                    Comment

                    Working...
                    X