5 ms·

Unfortunate to see a couple of comments here drive-by pulling out the “x% faster” stat whilst minimising the context. This is a big deal and it’s effectively a

Unfortunate to see a couple of comments here drive-by pulling out the “x% faster” stat whilst minimising the context. This is a big deal and it’s effectively a given that this’ll pave the way for further enhancements.

kragen 3y ago
maybe, maybe not. time will tell. ahead-of-time compilation is even better known for improving performance and yet perl's compile-to-c backend turned out to fail to do that
- pjmlp 3y ago
  Ahead-of-time compilation is a bad solution for dynamic languages, so that is an expected outcome for Perl. The base line should be how heavily dynamic languages like my favourite set, Smalltalk, Common Lisp, Dylan, SELF, NewtonScript, ended up gaining from JIT, versus the original interpreters, while being in the genesis of many relevant papers for JIT research.
  - kragen 3y ago
    when i wrote ur-scheme one of the surprising things i learned from it was that ahead-of-time compilation worked amazingly well for scheme. scheme is ruthlessly monomorphic but i was still doing a type check on every primitive argument i didn't realize they ever jitted newtonscript
    - pjmlp 3y ago
      NewtonScript 2.0 introduced a mechanism to manually JIT code, functions marked as native get compiled into machine code. Had the Newton not been canceled, probably there would be an evolution from that support. See "Compiling Functions for Speed" https://www.newted.org/download/manuals/NewtonToolkitUsersGuide.pdf https://www.newted.org/download/manuals/NewtonToolkitUsersGu...
      - kragen 3y ago
        this is great, thanks! but it sounds like it was an aot compiler, not a jit compiler; for example, it explains that a drawback of compiling functions to native code is that they use more memory, and that the compiler still produces bytecode for the functions it compiles natively, unless you suppress the bytecode compilation in project settings
        pjmlp 3y ago
        Yeah, I guess if one wants to go more technical, I see it as the first step of a JIT that didn't had the opportunity to evolve due to market decisions.
        kragen 3y ago
        i guess if they had, we would know whether a jit made newtonscript faster or slower, but they didn't, so we don't. what we do know is that an aot compiler sometimes made newtonscript faster (though maybe only if you added enough manifest static typing annotations to your source code) that seems closer to the opposite of what you were saying in the point on which we were in disagreement?
        pjmlp 3y ago
        I guess my recolection regarding NewtonScript wasn't correct, if you prefer that I put it like that, however I am quite certain in regards to the other languages in my list.
        kragen 3y ago
        i agree that the other languages gained a lot for sure maybe i should have said that up front! except maybe common lisp; all the implementations i know are interpreted or aot-compiled (sometimes an expression at a time, like sbcl), but maybe there's a jit-compiled one, and i bet it's great probably with enough work python could gain a similar amount. it's possible that work might get done. but it seems likely that it'll have to give up things like reference-counting, as smalltalk did (which most of the other languages never had)
  - lispm 3y ago
    JIT compilation is rare in Common Lisp. I wouldn't think that Dylan implementations used JIT compilation. Apple's Dylan IDE and compiler was implemented in Macintosh Common Lisp (MCL). MCL then was not a part of the Dylan runtime. I would think that Open Dylan (the Dylan implementation originally from Harlequin) can also generate LLVM bitcode, but I don't know if that one can be JIT executed. Possibly...
    - kragen 3y ago
      are there any cl implementations that use jit? there are a lot of cl implementations so i assumed there must be one
      - lispm 3y ago
        ABCL runs on the JVM. It generates JVM byte code, which then can be JIT compiled by the JVM. CLISP has a byte code machine, for which a JIT can be used. There might be others.
        kragen 3y ago
        thank you! i didn't know clisp had a jit compiler, and i certainly should have thought of abcl, and also you mentioned them in your other comment in https://news.ycombinator.com/item?id=38933091 https://news.ycombinator.com/item?id=38933091 how much of a performance boost does abcl get from the hotspot jit compared to, say, interpreted clisp
        lispm 3y ago
        I have not made any performance comparison.
- cube2222 3y ago
  > ahead-of-time compilation is even better known for improving performance Not necessarily, not for dynamic languages. With very dynamic languages you can make only very limited assumptions about e.g. function argument types, which lead you to compiled functions that have to handle any possible case. A JIT compiler can notice that the given function is almost always (or always) used to operate on a pair of integers, and do a vastly superior specialized compilation, with guards to fallback on the generic one. With extensive inlining, you can also deduplicate a lot of the guards.
  - kragen 3y ago
    yes, that is true. but aot compilers never make things slower than interpretation, and they can afford more expensive optimizations also, even mature jit compilers often only make limited improvements; jython has been stuck at near-parity with cpython's terrible performance for decades, for example, and while v8 was an enormous improvement over old spidermonkey and squirrelfish, after 15 years it's still stuck almost an order of magnitude slower than c https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/node-gcc.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... which is (handwaving) like maybe a factor of 2 or 3 slower than self typically when i can get something to work using numpy it's only about a factor of 5 slower than optimized c, purely interpretively, which is competitive with v8 in many cases. luajit, by contrast, is goddam alien technology from the future with respect to your int×int example, if an int×int specialization is actually vastly superior, for example because the operation you're applying is something like + or *, an aot compiler can also insert the guard and inline the single-instruction implementation, and it can also do extensive inlining and even specialization (though that's rare in aots and common in jits). it can insert the guards because if your monomorphic sends of + are always sending + to a rational instance or something, the performance gain from eliminating megamorphic dispatch is comparatively slight, and the performance loss from inserting a static hardcoded guess of integer math before the megamorphic dispatch is also comparatively slight, though nonzero this can fall down, of course, when your arithmetic operations are polymorphic over integer and floating-point, or over different types of integers; but it often works far better than it has any right to. in most code, most arithmetic and ordered comparison is integers, most array indexing is arrays, most conditionals are on booleans (and smalltalk actually hardcodes that in its bytecode compiler). this depends somewhat on your language design, of course; python using the same operator for indexing dicts, lists, and even strings hurts it here meanwhile, back in the stop-hitting-yourself-why-are-you-hitting-yourself department, fucking cpython is allocating its integers on the heap and motherfucking reference-counting them
pjmlp 3y ago
It is a very big deal, as it will finally shift the mentality regarding: - "C/C++/Fortran libs are Python" - "Python is too dynamic", while disregarding Smalltalk, Common Lisp, Dylan, SELF, NewtonScript JIT capabilities, all dynamic languages where anything can change at any given moment
- japanman185 3y ago
  Disregarding the fact that python is an awful programming language for anthing other than jupyter notebooks
  - pjmlp 3y ago
    Another one that hasn't seen UNIX scripting in shell languages or Perl, Apache modules, before Python came to be.
    - 0x457 3y ago
      I wrote tons of perl in my life. I would rather keep writing perl than touching python. Every time I see a nice utility and see that it's written in python - tab closed.
      - pjmlp 3y ago
        Perl code is nice to write, as long as we don't need to debug scripts written by someone else.
  - BossingAround 3y ago
    Facts are objective; "Python is awful" is your opinion.
  - moffkalast 3y ago
    Ah I'd say the exact opposite, python in general is pretty good but jupyter sucks because the syntax isn't compatible with regular python and I avoid it like the plague.
adonese 3y ago
is it any different or comparable to numba or pyjion? Not following python closely in recent years but I recount those two projects with huge potential
- drbaba 3y ago
  I don’t know Pyjion, but I have used Numba for real work. It’s a great package and can lead to massive speed-ups. However, last time I used it, it (1) didn’t work with many third-party libraries (e.g. SciPy was important for me), and (2) didn’t work with object-oriented code (all your @njit code had to be wrapped in functions without classes). Those two has limited for which projects I could adopt Numba in practice, despite loving it in the cases it worked. I don’t know what limitations the built-in Python JIT has, but hopefully it might be a more general JIT that works for all Python code.
  - bouchard 3y ago
    FWIW, I use numba's (experimental) jitclass pretty successfully in my projects. (Actually a monkey-patched version to be able to set njit arguments)
benrutter 3y ago
This is so true! A JIT compiler is a big deal for performance improvements, especially where it matters (in large repetitive loops). Anyone cynical about the potential a python JIT offers should take a look at pypy which has a 5x speed up over regular python, mainly though JIT operations: https://www.pypy.org/ https://www.pypy.org/
crabbone 3y ago
I don't see this as an enhancement. Not pursuing JIT or efficient compilation in general was a deliberate decision way back when Python made some kind of sense. It was the simplicity of implementation valued over performance gains that motivated this decision. The mantra Python programmers liked to repeat was that "the performance is good enough, and if you want to go fast, write in C and make a native module". And if you didn't like that, there was always Java. Today, Python is getting closer and closer to be "the crappy Java with worse syntax". Except we already have that: it's called Groovy.
- frakt0x90 3y ago
  What are you talking about? From what I can read here there is no syntax change. Just a framework for faster execution. Plus, Python's usecase has HEAVILY evolved over the last few years since it's now the defacto language for machine learning. It's great that the core devs are keeping up with the time. The language is definitely getting more complex syntactically, and I'm not a huge fan of some of those changes but it's no where near Java or C++ or anything else. You can still write simple Python with all of these changes.
  - crabbone 3y ago
    > What are you talking about? Read it again. It seems you were reading too fast. I'm talking about the future, not the change being discussed right now. > It's great that the core devs are keeping up with the time. You mistake the influence of Microsoft and their desire to sell features for progress. Python is actually regressing as a system. It's becoming worse, not better. But it's hard to see the gestalt of it if all you are looking for is the new features. > it's no where near Java That is true. Java is a much more simple and regular (not in the automata theory sense) language. Today, if you want a simpler language, you need to choose Java over Python (although neither is very simple, so, preferably, you need a third option). > You can still write simple Python I can also write simple C++ if I limit what I use from the language to a very small subset. This says nothing about the simplicity of the language...
deleted 3y ago
[deleted]

kragen 3y ago

maybe, maybe not. time will tell. ahead-of-time compilation is even better known for improving performance and yet perl's compile-to-c backend turned out to fail to do that

pjmlp 3y ago
Ahead-of-time compilation is a bad solution for dynamic languages, so that is an expected outcome for Perl. The base line should be how heavily dynamic languages like my favourite set, Smalltalk, Common Lisp, Dylan, SELF, NewtonScript, ended up gaining from JIT, versus the original interpreters, while being in the genesis of many relevant papers for JIT research.
- kragen 3y ago
  when i wrote ur-scheme one of the surprising things i learned from it was that ahead-of-time compilation worked amazingly well for scheme. scheme is ruthlessly monomorphic but i was still doing a type check on every primitive argument i didn't realize they ever jitted newtonscript
  - pjmlp 3y ago
    NewtonScript 2.0 introduced a mechanism to manually JIT code, functions marked as native get compiled into machine code. Had the Newton not been canceled, probably there would be an evolution from that support. See "Compiling Functions for Speed" https://www.newted.org/download/manuals/NewtonToolkitUsersGuide.pdf https://www.newted.org/download/manuals/NewtonToolkitUsersGu...
    - kragen 3y ago
      this is great, thanks! but it sounds like it was an aot compiler, not a jit compiler; for example, it explains that a drawback of compiling functions to native code is that they use more memory, and that the compiler still produces bytecode for the functions it compiles natively, unless you suppress the bytecode compilation in project settings
      - pjmlp 3y ago
        Yeah, I guess if one wants to go more technical, I see it as the first step of a JIT that didn't had the opportunity to evolve due to market decisions.
        kragen 3y ago
        i guess if they had, we would know whether a jit made newtonscript faster or slower, but they didn't, so we don't. what we do know is that an aot compiler sometimes made newtonscript faster (though maybe only if you added enough manifest static typing annotations to your source code) that seems closer to the opposite of what you were saying in the point on which we were in disagreement?
        pjmlp 3y ago
        I guess my recolection regarding NewtonScript wasn't correct, if you prefer that I put it like that, however I am quite certain in regards to the other languages in my list.
        kragen 3y ago
        i agree that the other languages gained a lot for sure maybe i should have said that up front! except maybe common lisp; all the implementations i know are interpreted or aot-compiled (sometimes an expression at a time, like sbcl), but maybe there's a jit-compiled one, and i bet it's great probably with enough work python could gain a similar amount. it's possible that work might get done. but it seems likely that it'll have to give up things like reference-counting, as smalltalk did (which most of the other languages never had)
- lispm 3y ago
  JIT compilation is rare in Common Lisp. I wouldn't think that Dylan implementations used JIT compilation. Apple's Dylan IDE and compiler was implemented in Macintosh Common Lisp (MCL). MCL then was not a part of the Dylan runtime. I would think that Open Dylan (the Dylan implementation originally from Harlequin) can also generate LLVM bitcode, but I don't know if that one can be JIT executed. Possibly...
  - kragen 3y ago
    are there any cl implementations that use jit? there are a lot of cl implementations so i assumed there must be one
    - lispm 3y ago
      ABCL runs on the JVM. It generates JVM byte code, which then can be JIT compiled by the JVM. CLISP has a byte code machine, for which a JIT can be used. There might be others.
      - kragen 3y ago
        thank you! i didn't know clisp had a jit compiler, and i certainly should have thought of abcl, and also you mentioned them in your other comment in https://news.ycombinator.com/item?id=38933091 https://news.ycombinator.com/item?id=38933091 how much of a performance boost does abcl get from the hotspot jit compared to, say, interpreted clisp
        lispm 3y ago
        I have not made any performance comparison.
cube2222 3y ago
> ahead-of-time compilation is even better known for improving performance Not necessarily, not for dynamic languages. With very dynamic languages you can make only very limited assumptions about e.g. function argument types, which lead you to compiled functions that have to handle any possible case. A JIT compiler can notice that the given function is almost always (or always) used to operate on a pair of integers, and do a vastly superior specialized compilation, with guards to fallback on the generic one. With extensive inlining, you can also deduplicate a lot of the guards.
- kragen 3y ago
  yes, that is true. but aot compilers never make things slower than interpretation, and they can afford more expensive optimizations also, even mature jit compilers often only make limited improvements; jython has been stuck at near-parity with cpython's terrible performance for decades, for example, and while v8 was an enormous improvement over old spidermonkey and squirrelfish, after 15 years it's still stuck almost an order of magnitude slower than c https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/node-gcc.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... which is (handwaving) like maybe a factor of 2 or 3 slower than self typically when i can get something to work using numpy it's only about a factor of 5 slower than optimized c, purely interpretively, which is competitive with v8 in many cases. luajit, by contrast, is goddam alien technology from the future with respect to your int×int example, if an int×int specialization is actually vastly superior, for example because the operation you're applying is something like + or *, an aot compiler can also insert the guard and inline the single-instruction implementation, and it can also do extensive inlining and even specialization (though that's rare in aots and common in jits). it can insert the guards because if your monomorphic sends of + are always sending + to a rational instance or something, the performance gain from eliminating megamorphic dispatch is comparatively slight, and the performance loss from inserting a static hardcoded guess of integer math before the megamorphic dispatch is also comparatively slight, though nonzero this can fall down, of course, when your arithmetic operations are polymorphic over integer and floating-point, or over different types of integers; but it often works far better than it has any right to. in most code, most arithmetic and ordered comparison is integers, most array indexing is arrays, most conditionals are on booleans (and smalltalk actually hardcodes that in its bytecode compiler). this depends somewhat on your language design, of course; python using the same operator for indexing dicts, lists, and even strings hurts it here meanwhile, back in the stop-hitting-yourself-why-are-you-hitting-yourself department, fucking cpython is allocating its integers on the heap and motherfucking reference-counting them

pjmlp 3y ago

It is a very big deal, as it will finally shift the mentality regarding: - "C/C++/Fortran libs are Python" - "Python is too dynamic", while disregarding Smalltalk, Common Lisp, Dylan, SELF, NewtonScript JIT capabilities, all dynamic languages where anything can change at any given moment

japanman185 3y ago
Disregarding the fact that python is an awful programming language for anthing other than jupyter notebooks
- pjmlp 3y ago
  Another one that hasn't seen UNIX scripting in shell languages or Perl, Apache modules, before Python came to be.
  - 0x457 3y ago
    I wrote tons of perl in my life. I would rather keep writing perl than touching python. Every time I see a nice utility and see that it's written in python - tab closed.
    - pjmlp 3y ago
      Perl code is nice to write, as long as we don't need to debug scripts written by someone else.
- BossingAround 3y ago
  Facts are objective; "Python is awful" is your opinion.
- moffkalast 3y ago
  Ah I'd say the exact opposite, python in general is pretty good but jupyter sucks because the syntax isn't compatible with regular python and I avoid it like the plague.

adonese 3y ago

is it any different or comparable to numba or pyjion? Not following python closely in recent years but I recount those two projects with huge potential

drbaba 3y ago
I don’t know Pyjion, but I have used Numba for real work. It’s a great package and can lead to massive speed-ups. However, last time I used it, it (1) didn’t work with many third-party libraries (e.g. SciPy was important for me), and (2) didn’t work with object-oriented code (all your @njit code had to be wrapped in functions without classes). Those two has limited for which projects I could adopt Numba in practice, despite loving it in the cases it worked. I don’t know what limitations the built-in Python JIT has, but hopefully it might be a more general JIT that works for all Python code.
- bouchard 3y ago
  FWIW, I use numba's (experimental) jitclass pretty successfully in my projects. (Actually a monkey-patched version to be able to set njit arguments)

benrutter 3y ago

This is so true! A JIT compiler is a big deal for performance improvements, especially where it matters (in large repetitive loops). Anyone cynical about the potential a python JIT offers should take a look at pypy which has a 5x speed up over regular python, mainly though JIT operations: https://www.pypy.org/ https://www.pypy.org/

crabbone 3y ago

I don't see this as an enhancement. Not pursuing JIT or efficient compilation in general was a deliberate decision way back when Python made some kind of sense. It was the simplicity of implementation valued over performance gains that motivated this decision. The mantra Python programmers liked to repeat was that "the performance is good enough, and if you want to go fast, write in C and make a native module". And if you didn't like that, there was always Java. Today, Python is getting closer and closer to be "the crappy Java with worse syntax". Except we already have that: it's called Groovy.

frakt0x90 3y ago
What are you talking about? From what I can read here there is no syntax change. Just a framework for faster execution. Plus, Python's usecase has HEAVILY evolved over the last few years since it's now the defacto language for machine learning. It's great that the core devs are keeping up with the time. The language is definitely getting more complex syntactically, and I'm not a huge fan of some of those changes but it's no where near Java or C++ or anything else. You can still write simple Python with all of these changes.
- crabbone 3y ago
  > What are you talking about? Read it again. It seems you were reading too fast. I'm talking about the future, not the change being discussed right now. > It's great that the core devs are keeping up with the time. You mistake the influence of Microsoft and their desire to sell features for progress. Python is actually regressing as a system. It's becoming worse, not better. But it's hard to see the gestalt of it if all you are looking for is the new features. > it's no where near Java That is true. Java is a much more simple and regular (not in the automata theory sense) language. Today, if you want a simpler language, you need to choose Java over Python (although neither is very simple, so, preferably, you need a third option). > You can still write simple Python I can also write simple C++ if I limit what I use from the language to a very small subset. This says nothing about the simplicity of the language...

deleted 3y ago

[deleted]