
Wrestling Python into LLVM Intermediate Representation (2019) [video] - tomrod
https://www.youtube.com/watch?v=99bqotoBKu4
======
tony
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_extensio...](https://github.com/python/typing/blob/master/typing_extensions/README.rst)
(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
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.

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

~~~
laurencerowe
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/sys.html#sys._getframe)

* [https://docs.python.org/3/library/inspect.html#the-interpret...](https://docs.python.org/3/library/inspect.html#the-interpreter-stack)

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

[https://fosdem.org/2020/schedule/event/llvm_python/](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."

------
wizzwizz4
Here are the slides from the talk:
[https://ep2016.europython.eu/media/conference/slides/wrestli...](https://ep2016.europython.eu/media/conference/slides/wrestling-
python-into-llvm-intermediate-representation.pdf)

------
superwayne
I think this is actually from PyCon Israel 2016 and was uploaded in 2019.

~~~
maxmcd
I think that's accurate. I think it's this repo:
[https://github.com/aherlihy/PythonLLVM](https://github.com/aherlihy/PythonLLVM)

Which hasn't been updated in 5 yrs :(

------
yhvh
Brutal editing

