Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Wrestling Python into LLVM Intermediate Representation (2019) [video]

youtube.com

Post reply on HN
Print view View original

11–20 of 20 posts

Re: Wrestling Python into LLVM Intermediate Representation (2019) [video]

#11

Post by m_ke »

tony wrote: post #4

I'm not sure if it's an exact fit, but dropbox used to have pyston: https://github.com/dropbox/pyston The blog posts by Kevin Modzelewski went into the internals: 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/ As a side comment: On the subject of type inference, I really come to like python's type hints. I don't use mypy its…

You should check out 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/mypyc/mypyc/issues/709

Re: Wrestling Python into LLVM Intermediate Representation (2019) [video]

#12

Post by CoAl2O4 »

There was a python+LLVM talk last weekend as FOSDEM too (video is up)

https://fosdem.org/2020/schedule/event/llvm_python/

"Python with LLVM has at least one decade of history. This session will be going to cover-up how python implementations tried to use LLVM such as CPython's Unladen Swallow branch (PEP 3146) or attempts from PyPy and why they failed. After that it will show what are the current python projects that use LLVM for speed, such as numba and python libraries for working with LLVM IR. In the end, it will mention about new ideas that would unite the powers of both LLVM and Python."

Re: Wrestling Python into LLVM Intermediate Representation (2019) [video]

#13

Post by pjmlp »

heisig wrote: post #10
pjmlp wrote: post #5

Earlier quoted context omitted.

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 J…

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…

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.

Re: Wrestling Python into LLVM Intermediate Representation (2019) [video]

#14

Post by ianandrich »

m_ke wrote: post #11
tony wrote: post #4

I'm not sure if it's an exact fit, but dropbox used to have pyston: https://github.com/dropbox/pyston The blog posts by Kevin Modzelewski went into the internals: 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/ As a side comment: On the subject of type inference, I really come to like python's type hints. I don't use mypy its…

You should check out 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/mypyc/mypyc/issues/709

This looks awesome. Have you used it for anything yet?

Re: Wrestling Python into LLVM Intermediate Representation (2019) [video]

#15

Post by scroot »

pjmlp wrote: post #13
heisig wrote: post #10

Earlier quoted context omitted.

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…

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.

> 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.

Re: Wrestling Python into LLVM Intermediate Representation (2019) [video]

#16

Post by laurencerowe »

scroot wrote: post #15
pjmlp wrote: post #13

Earlier quoted context omitted.

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.

> 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 som…

You can walk and inspect the stack using sys._getframe() forever or the more friendly stack function in the inspect module.

* https://docs.python.org/3/library/sys.html#sys._getframe

* https://docs.python.org/3/library/inspect.html#the-interpret...

Re: Wrestling Python into LLVM Intermediate Representation (2019) [video]

#17

Post by lispm »

heisig wrote: post #10
pjmlp wrote: post #5

Earlier quoted context omitted.

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 J…

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…

Right, JIT compilers in Common Lisp are mostly not known. There are only a few bytecode interpreters, where it could be used: CLISP, CMU CL with its bytecode interpreter, ...

Common Lisp has several execution modes and for compiled code: important are

1) AOT compiled, but fully safe with optional debug info: safety = 3 and debug = 2

2) AOT compiled, but fast and potentially unsafe with little debug infos: speed = 3, safety = 0, debug = 0

The usual goal is to be able to run much of the code in mode 1) and only compile portions in mode 2).

Thus much of the language is optimized around possible compilation. The language is very dynamic, but there is also a core, which is not object-oriented - thus potentially easier to compile to fast code.

Also incremental in-memory compilation in Common Lisp is AOT and not JIT.

Re: Wrestling Python into LLVM Intermediate Representation (2019) [video]

#18

Post by lispm »

pjmlp wrote: post #13
heisig wrote: post #10

Earlier quoted context omitted.

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…

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.

Common Lisp can also change the class of a CLOS object. Via CHANGE-CLASS:

http://www.lispworks.com/documentation/HyperSpec/Body/f_chg_...

But these are not the parts where Common Lisp will be fast...

Re: Wrestling Python into LLVM Intermediate Representation (2019) [video]

#19

Post by kazinator »

lispm wrote: post #18
pjmlp wrote: post #13

Earlier quoted context omitted.

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.

Common Lisp can also change the class of a CLOS object. Via CHANGE-CLASS: http://www.lispworks.com/documentation/HyperSpec/Body/f_chg_... But these are not the parts where Common Lisp will be fast...

SmallTalk's become: is a crazy-ass feature which walks the entire graph of reachable objects, and replaces all occurrences of one object with another. A becomes B by virtue of all known references to A being replaced with references to B.

Re: Wrestling Python into LLVM Intermediate Representation (2019) [video]

#20

Post by kmod »

pjmlp wrote: post #5
tony wrote: post #4

I'm not sure if it's an exact fit, but dropbox used to have pyston: https://github.com/dropbox/pyston The blog posts by Kevin Modzelewski went into the internals: 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/ As a side comment: On the subject of type inference, I really come to like python's type hints. I don't use mypy its…

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 J…

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).
Post reply on HN