3 ms·

> PyPy manages to outperform CPython because although a C implementation should theoretically be faster, realistically the increased expressiveness of Python le

> PyPy manages to outperform CPython because although a C implementation should theoretically be faster, realistically the increased expressiveness of Python lets the PyPy devs opt into optimizations the CPython devs find out of reach. Pypy outperforms cpython for the simple reason that pypy is a jit where cpython is a basic bytecode interpreter. Anything else is icing on the cake. The only reason python seems slow as an implementation language is because it was traditionally slow; the reason it was traditionally slow is that cpython, the only major implementation, is slow. Common lisp, for instance, is similarly dynamic (moreso, in fact), also is also generally natively compiled by itself, and is quite performant.

spiffytech 6y ago
PyPy has a JIT because using Python as the implementation language made it simple to build a runtime generator instead of a single runtime implementation, so RPython (the underlying PyPy tech) can generate a JIT and non-JIT runtime from the same source code. Conversely, the CPython team doesn't have the resources to make a JIT runtime the bespoke way that's more typical for these projects. https://morepypy.blogspot.com/2011/04/tutorial-part-2-adding-jit.html https://morepypy.blogspot.com/2011/04/tutorial-part-2-adding...
- naniwaduni 6y ago
  CPython isn't a JIT because its goals as a portable reference implementation would be much harder to achieve with a JIT. To put it another way, there's a reason PyPy trails CPython language features on the scale of literal years. This is not explained by the affordances of the language they're written in! They're just projects with very different requirements which, on some platforms, happen to run a lot of similar-looking code.
  - ghostwriter 6y ago
    > there's a reason PyPy trails CPython language features on the scale of literal years. the reason is under-funding, and the lack of developers to the cause as a consequence, not the portability complexities of jit.
aidenn0 6y ago
Common Lisp (hereafter Lisp for concision) is differently dynamic, not strictly more dynamic. One quick example: standard-class objects in Lisp are mostly more dynamic than python objects[1] but structure-class objects are quite static, and compilers will use this to their advantage. On top of this, functions in python are in fact objects; in python you can do this just fine: def foo(): foo.bar = 3 def bar(): print(foo.bar) There are obviously other ways to accomplish this in lisp, but the fact that someone might do something like this can inhibit optimizations. If you read the Lisp specification you will see dozens of places where they allow for opting out of dynamism in ways that help the compiler optimize. Type declarations are one and the fact that a function defined in a single file is considered to have a fixed definition for the scope of the file is another. 1: It's not quite as easy to add new slots to Lisp standard-class instances on the fly as it is to python class instances, but it's doable, and Lisp, of course, supports class redefinition in a way that few other languages (including Python) do.

spiffytech 6y ago

PyPy has a JIT because using Python as the implementation language made it simple to build a runtime generator instead of a single runtime implementation, so RPython (the underlying PyPy tech) can generate a JIT and non-JIT runtime from the same source code. Conversely, the CPython team doesn't have the resources to make a JIT runtime the bespoke way that's more typical for these projects. https://morepypy.blogspot.com/2011/04/tutorial-part-2-adding-jit.html https://morepypy.blogspot.com/2011/04/tutorial-part-2-adding...

naniwaduni 6y ago
CPython isn't a JIT because its goals as a portable reference implementation would be much harder to achieve with a JIT. To put it another way, there's a reason PyPy trails CPython language features on the scale of literal years. This is not explained by the affordances of the language they're written in! They're just projects with very different requirements which, on some platforms, happen to run a lot of similar-looking code.
- ghostwriter 6y ago
  > there's a reason PyPy trails CPython language features on the scale of literal years. the reason is under-funding, and the lack of developers to the cause as a consequence, not the portability complexities of jit.

aidenn0 6y ago

Common Lisp (hereafter Lisp for concision) is differently dynamic, not strictly more dynamic. One quick example: standard-class objects in Lisp are mostly more dynamic than python objects[1] but structure-class objects are quite static, and compilers will use this to their advantage. On top of this, functions in python are in fact objects; in python you can do this just fine: def foo(): foo.bar = 3 def bar(): print(foo.bar) There are obviously other ways to accomplish this in lisp, but the fact that someone might do something like this can inhibit optimizations. If you read the Lisp specification you will see dozens of places where they allow for opting out of dynamism in ways that help the compiler optimize. Type declarations are one and the fact that a function defined in a single file is considered to have a fixed definition for the scope of the file is another. 1: It's not quite as easy to add new slots to Lisp standard-class instances on the fly as it is to python class instances, but it's doable, and Lisp, of course, supports class redefinition in a way that few other languages (including Python) do.