3 ms·

There are quite a few python JITs over the years - Psyco -> PyPy, unladen swallow, pyston, numba ; that's in addition to Python2C, ShedSkin and Nuitka (and even

by beagle3 10y ago

There are quite a few python JITs over the years - Psyco -> PyPy, unladen swallow, pyston, numba ; that's in addition to Python2C, ShedSkin and Nuitka (and even Cython) which are AOT by way of C. And yet, none emerges as a general clear choice. I have the feeling this is because python is too dynamic making this a sysiphean effort. I urge designers of future dynamic languages to study Lua and LuaJIT if you want your language to not inhibit JIT development.

mhneu 10y ago
You are right, the difficulties are in Python's design. See the Pyston blog "Why is Python slow". http://blog.kevmod.com/2016/07/why-is-python-slow/ http://blog.kevmod.com/2016/07/why-is-python-slow/ That said, the Pyston guys knew what the problems were (dynamism in C runtime) and were making progress. This was the future of fast Python - JIT experts optimizing the runtime and feeding code and ideas back to CPython. I think we will look back at this Pyston announcement as the turning point where people gave up on Python speed.
- coldtea 10y ago
  >You are right, the difficulties are in Python's design. Not anymore than there were in Javascript's design -- which is as, if not more, dynamic. It's just lack of funding. PyPy managed to get much faster than CPython, but doesn't have the funding or the blessing of being official (Javascript doesn't need it, since there were always multiple implementations).
  - beagle3 10y ago
    Javascript does have it easier by virtue of being single threaded, with no overloading and with a single numeric type. In the python version of this loop: for x in range(1000): sum = sum + math.sin(x) The global "math" and "math.sin" can be changed by another thread at any point. Javascript guarantees that this cannot happen. Also, what constructs of Javascript are more dynamic than python? I can only think of "eval" and "with", both of which the JavaScript JIT decline to compile and interpret instead.
stcredzero 10y ago
I urge designers of future dynamic languages to study Lua and LuaJIT if you want your language to not inhibit JIT development. Agreed. Also Smalltalk's memory model was a lot easier to optimize than languages like Python and Ruby. (Java inherited some of that.) Not having syntactic sugar makes optimization easier. In addition, language designers need to make parser tools easy to make and robust.

by beagle3 10y ago

mhneu 10y ago

You are right, the difficulties are in Python's design. See the Pyston blog "Why is Python slow". http://blog.kevmod.com/2016/07/why-is-python-slow/ http://blog.kevmod.com/2016/07/why-is-python-slow/ That said, the Pyston guys knew what the problems were (dynamism in C runtime) and were making progress. This was the future of fast Python - JIT experts optimizing the runtime and feeding code and ideas back to CPython. I think we will look back at this Pyston announcement as the turning point where people gave up on Python speed.

coldtea 10y ago
>You are right, the difficulties are in Python's design. Not anymore than there were in Javascript's design -- which is as, if not more, dynamic. It's just lack of funding. PyPy managed to get much faster than CPython, but doesn't have the funding or the blessing of being official (Javascript doesn't need it, since there were always multiple implementations).
- beagle3 10y ago
  Javascript does have it easier by virtue of being single threaded, with no overloading and with a single numeric type. In the python version of this loop: for x in range(1000): sum = sum + math.sin(x) The global "math" and "math.sin" can be changed by another thread at any point. Javascript guarantees that this cannot happen. Also, what constructs of Javascript are more dynamic than python? I can only think of "eval" and "with", both of which the JavaScript JIT decline to compile and interpret instead.

stcredzero 10y ago

I urge designers of future dynamic languages to study Lua and LuaJIT if you want your language to not inhibit JIT development. Agreed. Also Smalltalk's memory model was a lot easier to optimize than languages like Python and Ruby. (Java inherited some of that.) Not having syntactic sugar makes optimization easier. In addition, language designers need to make parser tools easy to make and robust.