5 ms·

I'm not sure if it's an exact fit, but dropbox used to have pyston: https://github.com/dropbox/pyston https://github.com/dropbox/pyston The blog posts by Kevin

by tony 7y ago

I'm not sure if it's an exact fit, but dropbox used to have pyston: https://github.com/dropbox/pyston https://github.com/dropbox/pyston The blog posts by Kevin Modzelewski went into the internals: https://blog.pyston.org/ https://blog.pyston.org/ Also by the same person, a good article on Python's performance: http://blog.kevmod.com/2016/07/why-is-python-slow/ http://blog.kevmod.com/2016/07/why-is-python-slow/ As a side comment: On the subject of type inference, I really come to like python's type hints. I don't use mypy itself yet, but already had a habit of adding types in docstrings, and like it when I can add a clue that a signature/return is dealing with a something that's not a basic type. There are some nice little things out there for advanced typing, being added now and then: - TypedDict and Literal: https://github.com/python/typing/blob/master/typing_extensions/README.rst https://github.com/python/typing/blob/master/typing_extensio... (TypedDict was accepted in PEP 589[1]) - NamedTuple had variable annotation added in Python 3.6: https://www.python.org/dev/peps/pep-0526/ https://www.python.org/dev/peps/pep-0526/ I wonder if typings are added to a codebase, we could give LLVM one more shot. It'd be pretty crazy to build able to build a large graphql server and build it into a statically linked binary like golang. [1] https://www.python.org/dev/peps/pep-0589/ https://www.python.org/dev/peps/pep-0589/

pjmlp 7y ago
It would already be nice if it was Julia LLVM JIT style. Many of the "why Python is slow" articles usually hand wave the fact that other languages, just as dynamic, like Common Lisp and Smalltalk, have quite capable JIT compilers. So it is a matter of having enough resources to throw at it. Maybe PyPy and Numba are as good as it gets, unless some big corporation is willing to spend big bucks into improving Python's JITs.
- marmaduke 7y ago
  > unless some big corporation is willing to spend big bucks It seems like the outcome of the Unladen Swallow project was that there was no point to JIT generally because the language semantics prevent the sort of accelerations possible in other languages. (I'm aware of how PyPy and Numba are successful exceptions.)
  - jashmatthews 7y ago
    LLVM just isn't that good for a JIT compiler: http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospective.html http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospect... Azul made it work for Java with what they said was ~20 man years of work.
- heisig 7y ago
  Let me chip in here to clarify some things. > other languages, just as dynamic, like Common Lisp and Smalltalk, have quite capable JIT compilers. Common Lisp implementations don't need a JIT compiler to be fast. In fact, most of them don't use JIT compilation at all. What makes Common Lisp implementations (especially SBCL) so fast is a combination of sophisticated static analysis, optional type declarations, and the fact that Common Lisp has been carefully designed to allow for high performance. I cannot stress how important the last point is. The Common Lisp standard is a contract between the programmer and the compiler writer that allows the former to write portable programs, yet gives the latter enough freedom to optimize. In contrast, the language "standard" of Python doesn't clarify what portable programs may rely on. Instead, programmers tend to rely on the specific behavior of CPython. And reproducing the exact behavior of CPython is much harder than implementing a carefully designed standard. > So it is a matter of having enough resources to throw at it. No amount of resources can heal the design decisions of Python. The only way to get Python fast is by going through a painful standardization effort and by breaking some existing code. And I don't see that happening anytime soon. (Python 4 anyone?)
  - pjmlp 7y ago
    Fair enough that relying in CPython specific behaviour might be an issue. Although stuff like dictionary ordering, GC implementation, or GIL shouldn't impact JIT implementation. However going back to Smalltalk, which you didn't mention, not only it is as dynamic as Python, at any given moment can the image change its contents, and via messages like becomes: an object completely changes its internal structure.
    - scroot 7y ago
      > not only it is as dynamic as Python, at any given moment can the image change its contents, and via messages like becomes: an object completely changes its internal structure. Another thing: in Smalltalk the idea of a "stack frame" is actually encapsulated in an object called Context, and you can always inspect the current context. It's just an object like everything else in the system. I don't think Python has something like that, but I could be mistaken.
- kmod 7y ago
  They're really in a different league. My favorite example is the ad-hoc stack analysis that Python lets you do -- and not just of the current stack, but of already-exited stack frames! This is free in CPython but prevents sizable performance gains from JITs (I don't remember the exact numbers, but I think it was multiple percent).
m_ke 7y ago
You should check out mypyc https://github.com/python/mypy/tree/master/mypyc https://github.com/python/mypy/tree/master/mypyc and this new recent issue that mentions targeting LLVM or other targets https://github.com/python/mypy/issues/8373 https://github.com/python/mypy/issues/8373 https://github.com/mypyc/mypyc/issues/709 https://github.com/mypyc/mypyc/issues/709
- ianandrich 7y ago
  This looks awesome. Have you used it for anything yet?

by tony 7y ago

pjmlp 7y ago

It would already be nice if it was Julia LLVM JIT style. Many of the "why Python is slow" articles usually hand wave the fact that other languages, just as dynamic, like Common Lisp and Smalltalk, have quite capable JIT compilers. So it is a matter of having enough resources to throw at it. Maybe PyPy and Numba are as good as it gets, unless some big corporation is willing to spend big bucks into improving Python's JITs.

marmaduke 7y ago
> unless some big corporation is willing to spend big bucks It seems like the outcome of the Unladen Swallow project was that there was no point to JIT generally because the language semantics prevent the sort of accelerations possible in other languages. (I'm aware of how PyPy and Numba are successful exceptions.)
- jashmatthews 7y ago
  LLVM just isn't that good for a JIT compiler: http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospective.html http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospect... Azul made it work for Java with what they said was ~20 man years of work.
heisig 7y ago
Let me chip in here to clarify some things. > other languages, just as dynamic, like Common Lisp and Smalltalk, have quite capable JIT compilers. Common Lisp implementations don't need a JIT compiler to be fast. In fact, most of them don't use JIT compilation at all. What makes Common Lisp implementations (especially SBCL) so fast is a combination of sophisticated static analysis, optional type declarations, and the fact that Common Lisp has been carefully designed to allow for high performance. I cannot stress how important the last point is. The Common Lisp standard is a contract between the programmer and the compiler writer that allows the former to write portable programs, yet gives the latter enough freedom to optimize. In contrast, the language "standard" of Python doesn't clarify what portable programs may rely on. Instead, programmers tend to rely on the specific behavior of CPython. And reproducing the exact behavior of CPython is much harder than implementing a carefully designed standard. > So it is a matter of having enough resources to throw at it. No amount of resources can heal the design decisions of Python. The only way to get Python fast is by going through a painful standardization effort and by breaking some existing code. And I don't see that happening anytime soon. (Python 4 anyone?)
- pjmlp 7y ago
  Fair enough that relying in CPython specific behaviour might be an issue. Although stuff like dictionary ordering, GC implementation, or GIL shouldn't impact JIT implementation. However going back to Smalltalk, which you didn't mention, not only it is as dynamic as Python, at any given moment can the image change its contents, and via messages like becomes: an object completely changes its internal structure.
  - scroot 7y ago
    > not only it is as dynamic as Python, at any given moment can the image change its contents, and via messages like becomes: an object completely changes its internal structure. Another thing: in Smalltalk the idea of a "stack frame" is actually encapsulated in an object called Context, and you can always inspect the current context. It's just an object like everything else in the system. I don't think Python has something like that, but I could be mistaken.
kmod 7y ago
They're really in a different league. My favorite example is the ad-hoc stack analysis that Python lets you do -- and not just of the current stack, but of already-exited stack frames! This is free in CPython but prevents sizable performance gains from JITs (I don't remember the exact numbers, but I think it was multiple percent).

m_ke 7y ago

You should check out mypyc https://github.com/python/mypy/tree/master/mypyc https://github.com/python/mypy/tree/master/mypyc and this new recent issue that mentions targeting LLVM or other targets https://github.com/python/mypy/issues/8373 https://github.com/python/mypy/issues/8373 https://github.com/mypyc/mypyc/issues/709 https://github.com/mypyc/mypyc/issues/709

ianandrich 7y ago
This looks awesome. Have you used it for anything yet?