3 ms·

Python is just too dynamic, and users do make use of it. There are JavaScript constructs that JITs give up upon, such as “with” - and this has steered JS progra

Python is just too dynamic, and users do make use of it. There are JavaScript constructs that JITs give up upon, such as “with” - and this has steered JS programmers to avoid those constructs. Unfortunately, there is no Python subset people can stick to as such. But you can use e.g. TransCrypt to compile Python to JavaScript; the docs tell you about an efficient subset. It should be possible to build an efficient Python JIT for such a subset (and you sort of have one already through TransCrypt and JS)

pjmlp 5y ago
Smalltalk, remap all instances of a into b across the complete image, no matter where they are being used or which classes they actually are instances of. a become: b It is a myth that only Python enjoys such dynamic capabilities, it happens to be a convenient excuse.
- beagle3 5y ago
  It's a lot more than an excuse; The simplest "a.b" has to check a lot of places before it gives an answer, and each of these needs its own in-line cache. Indeed, there have been experimental compilers for Python that gave much improved speeds for subsets that drop the ultra dynamic constructs (and usually a lot more dynamism and features to achieve that speed). And the fact that there are languages as dynamic as Python is not as important as how it is implemented through the language; Lua is about as dynamic as Python, but with effects that are much more local in general. IIRC Mike Pall (of LuaJIT fame) said that Lua was almost optimal for JITting, JS is sort-of-ok if you ignore some things, but Python is beyond hope -- and I tend to think he knows what he's talking about, given that his hobby, one-man-show LuaJIT handily beat all well-funded-with-tens-of-employees JS engines for a very long time (maybe still does). I wonder how good the SmallTalk JITs really are by today's standards, in the presence of e.g. "become:". The fact that's it is there, and supported, doesn't mean it's in common use, or supported efficiently -- just like JavaScript's "with".
  - pjmlp 5y ago
    In a sense it is, because in those communities the approach has been, "it is hard but we will solve it sooner or later", whereas in the Python world, PyPy seems to be the only approach that has embraced this culture, whereas everyone else takes the path "it is hard, Python cannot be made fast because it is dynamic".
    - beagle3 5y ago
      That’s not been my impression. On the contrary - there have been very many unsuccessful attempts (Unladen swallow, Pyston, Nuitka, cython-for-plain-python, a few more I can’t recall right now); they all tried to maintain compatibility (complete language and binary api), and all delivered very meager speedups. Those that focused on a subset (numba, shedskin, rpython) were actually able to deliver significant speedups. Even PyPy dropped binary compatibility. The odd one out is Psyco, the precursor to PyPy. Perfect compatibility with non trivial speedup - but was considered a dead end by its authors, and that’s why they started PyPy
- igouy 5y ago
  I wouldn't have thought `become:` was an example that distinguished a dynamic programming language from others. Where have you seen it used as an example in that way?
  - pjmlp 5y ago
    It doesn't distinguish per se, it is rather a good example of something that a dynamic language can make that in a single call makes invalid all assumptions that JIT might have gathered until that point. As for become: usefulness, Gilad Bracha explains it better than ever will, https://gbracha.blogspot.com/2009/07/miracle-of-become.html https://gbracha.blogspot.com/2009/07/miracle-of-become.html
    - beagle3 5y ago
      He does not address JIT efficiency here. A likely implementation is just “lets drop all assumptions related to the type of A”. It would work, but frequent use would kill performance. Python has all the issues that “become” has, with hundreds of “assumptions might have changed” points along common execution paths. Liajit, for example, hoists everything it can outside of loops rather quickly, because it knows the cases “become” or Python equivalent can happen, and they are rare and uncommon in idiomatic Lua code.

pjmlp 5y ago

Smalltalk, remap all instances of a into b across the complete image, no matter where they are being used or which classes they actually are instances of. a become: b It is a myth that only Python enjoys such dynamic capabilities, it happens to be a convenient excuse.

beagle3 5y ago
It's a lot more than an excuse; The simplest "a.b" has to check a lot of places before it gives an answer, and each of these needs its own in-line cache. Indeed, there have been experimental compilers for Python that gave much improved speeds for subsets that drop the ultra dynamic constructs (and usually a lot more dynamism and features to achieve that speed). And the fact that there are languages as dynamic as Python is not as important as how it is implemented through the language; Lua is about as dynamic as Python, but with effects that are much more local in general. IIRC Mike Pall (of LuaJIT fame) said that Lua was almost optimal for JITting, JS is sort-of-ok if you ignore some things, but Python is beyond hope -- and I tend to think he knows what he's talking about, given that his hobby, one-man-show LuaJIT handily beat all well-funded-with-tens-of-employees JS engines for a very long time (maybe still does). I wonder how good the SmallTalk JITs really are by today's standards, in the presence of e.g. "become:". The fact that's it is there, and supported, doesn't mean it's in common use, or supported efficiently -- just like JavaScript's "with".
- pjmlp 5y ago
  In a sense it is, because in those communities the approach has been, "it is hard but we will solve it sooner or later", whereas in the Python world, PyPy seems to be the only approach that has embraced this culture, whereas everyone else takes the path "it is hard, Python cannot be made fast because it is dynamic".
  - beagle3 5y ago
    That’s not been my impression. On the contrary - there have been very many unsuccessful attempts (Unladen swallow, Pyston, Nuitka, cython-for-plain-python, a few more I can’t recall right now); they all tried to maintain compatibility (complete language and binary api), and all delivered very meager speedups. Those that focused on a subset (numba, shedskin, rpython) were actually able to deliver significant speedups. Even PyPy dropped binary compatibility. The odd one out is Psyco, the precursor to PyPy. Perfect compatibility with non trivial speedup - but was considered a dead end by its authors, and that’s why they started PyPy
igouy 5y ago
I wouldn't have thought `become:` was an example that distinguished a dynamic programming language from others. Where have you seen it used as an example in that way?
- pjmlp 5y ago
  It doesn't distinguish per se, it is rather a good example of something that a dynamic language can make that in a single call makes invalid all assumptions that JIT might have gathered until that point. As for become: usefulness, Gilad Bracha explains it better than ever will, https://gbracha.blogspot.com/2009/07/miracle-of-become.html https://gbracha.blogspot.com/2009/07/miracle-of-become.html
  - beagle3 5y ago
    He does not address JIT efficiency here. A likely implementation is just “lets drop all assumptions related to the type of A”. It would work, but frequent use would kill performance. Python has all the issues that “become” has, with hundreds of “assumptions might have changed” points along common execution paths. Liajit, for example, hoists everything it can outside of loops rather quickly, because it knows the cases “become” or Python equivalent can happen, and they are rare and uncommon in idiomatic Lua code.