Lets Talk About Something Diabolical: A PyPy Intro (David Beazley PyCon keynote)

http://pyvideo.org/video/659/keynote-david-beazley

by ctkrohn • 14 years ago

116 12 14 years ago

novalis• 14 years ago

That was great. PyPy looks like a great bytecode equivalent to what is happening with other languages and he does highlight this "disconnect" that is raised by new approaches that produce amazing results. He even got a async node joke in there, cracked me up.

binarycrusader• 14 years ago

This keynote was by far the highlight of PyCon for me. I hope to hear David speak again soon.

pan69• 14 years ago

I do nothing with Python and I couldn't care less about Python, but... I really enjoyed this video. Great talk!

ericflo• 14 years ago

I didn't get a chance to see this at PyCon, but wow, this video really helped me understand some of the fundamentals of PyPy. (For example, I had no idea it didn't have a parser, and instead only acts on the intermediate representation of Python bytecode.)

Also, David Beazley has a great way of making difficult concepts approachable.

Ingaz• 14 years ago

Can somebody explain the end of lecture?

Why Ruby and PyPy looks similar in this benchmark?

ctkrohn• 14 years ago

Yeah, he skipped over what might have been the most interesting part of the talk! I have a very cursory understanding of how the GIL works, so it would be nice to understand what's going on here.

Lozzer• 14 years ago

He referenced a previous talk about the GIL:

http://blip.tv/rupy-strongly-dynamic-conference/david-beazly...

krig• 14 years ago

The bug that caused Ruby to run slow on that benchmark turned out to be one that afflicted earlier versions of Python. It's a priority inversion problem related to the GIL.

GIL: The global interpreter lock, basically a single lock that threads running in Python or Ruby synchronize on frequently to sync up, which causes problems in multithreaded applications.

Priority inversion: I don't think I'm qualified to explain this clearly, so I'll defer to wikipedia: https://en.wikipedia.org/wiki/Priority_inversion

The later slide where he showed PyPy having terrible performance on a benchmark where the other two code bases worked fine was an unrelated problem.

His point was that whereas he was able to dig into the Ruby implementation and figure out why it was running slow, it was much harder to find the reason why PyPy was not performing as it should due to the implementation complexity.

It is basically tying back to the analogy of the VW versus the Porsche. He could often fix his VW using a pocket knife, which would be very difficult to do with a Porsche.

stefantalpalaru• 14 years ago

The RPython translation to C sounds a lot like what cython is already doing with a subset of Python. Are the PyPy guys reinventing the wheel here?

hogu• 14 years ago

Cython generates c based on the cpython api, you can only use it to build cpython extensions.

kingkilr• 14 years ago

I seriously doubt it, considering a) RPython is a strict subset of Python, operating on the in memory representation of Python objects and does aggressive type inference, whereas Cython adds additional features (and syntax) to the language and has it's own parser and no type inference (AFAIK), and b) RPython predates Cython, AFAIK.

fijal• 14 years ago

Cython is both differently defined and serves a different purpose. First of all, RPython is runnable, Cython is not. RPython has type inference, but more importantly, because it works from live objects, it has Python as a metaprogramming language. It's also much easier to extend than Cython.

Purpose wise cython is for optimizing pieces of code, rpython is for writing interpreters. RPython is quite faster than Cython, but it's also much more restricted, making it a bit unusable for the purpose of "just" speeding up pieces of code (you can't have PyObject equivalents).

Lets Talk About Something Diabolical: A PyPy Intro (David Beazley PyCon keynote)

Related Stories