5 ms·

>It may be theoretically true, but in practice, as nice as Python may be to use, it has proved a very difficult language to speed up. I disagree with you. Pyth

>It may be theoretically true, but in practice, as nice as Python may be to use, it has proved a very difficult language to speed up. I disagree with you. Python isn't much harder to speed up than Lua and in some ways it's better behaved than JavaScript. Still, both of those languages enjoy implementations significantly faster than CPython. Really, it's not the semantics of the language which hold back Python's performance but rather the fact that extension modules are extremely tightly coupled with a particular interpreter implementation. Lua has a clean interface with C, JavaScript implementations generally force the outside world to use doubly indirect handles on objects. CPython, on the other hand, is shameless in flaunting its internals for the whole world to see. The only reason that PyPy has taken "multiple PhD-thesis level attacks" to near completion is because their approach is insanely ambitious. They didn't write a JIT. Instead they wrote a toolkit for partially evaluating interpreters on source files and generate native code by tracing an interpreter while it itself runs a program. It's nuts! It's amazing that PyPy works and the amount of effort is totally unsurprising. Had they gone a more traditional route, the whole thing could have been done in a year or two. They would, however, still face resistance from a Python community that wants to neither give up nor rewrite their PyObject-laced libraries.

enupten 13y ago
There is some truth here; even the militantly dynamic Common lisp has a blisteringly fast implementation (SBCL).
fijal 13y ago
I think you underestimate the complexity of Python language. Note that PyPy is not the only project that did that - remember psyco? There are reasons why after 3 years Armin said "I give up, let's do PyPy". It's not the "well behaved" part, this can be worked around, Python is simply more complex than Javascript or Lua and by complex I mean just bigger. All the extension modules that everyone naturally expects to be fast (even just the stdlib), descriptor protocol, crazy frame access semantics. That does make it very labour intensive to do the right thing. Look what happened to Unladen Swallow - they did not get anywhere really within a year. Several of PyPy optimizations that took forever to do are really new stuff, whether you do JIT by hand or generate it automatically.
- nostrademons 13y ago
  The last time I talked with the Unladen Swallow guys (a couple years ago), they were pretty clear that one of their main stumbling blocks was supporting the Python/C API, and wanting to have complete compatibility with C extension modules. While we can't really know how hard the task would've been if they'd lifted that requirement - it was baked into their design from an early stage - when I'd floated the idea of doing a from-the-ground-up LLVM-based implementation of Python, they seemed significantly more optimistic. It wouldn't be all that useful for most people, but it would've worked fine for my use case. Alas, it's doubtful that a Python implementation that sacrifices C extensions would get all that far with mainstream adopters, as so many useful libraries are done as C extensions.
  - fijal 13y ago
    They were optimistic at the beginning too (even with C extensions). How would it fill your usecase in a way that pypy does not?
    - nostrademons 13y ago
      We were looking for something easily embeddable, but all host modules were provided by the application, so there was no need for outside C extensions. And the set of libraries that was importable was restricted and coding styleguides banned advanced language features like metaprogramming, so we could afford to cut corners on corner cases of the language. "Decent" performance (i.e. more like Java than CPython) was a requirement, as was multithreading support and lack of a GIL, and RAM usage was also at a premium (which was probably the largest argument against PyPy...also, this was a couple years ago, when PyPy was not as mature).
MostAwesomeDude 13y ago
You are wrong. Python's object model is incredibly rich in ways that JavaScript and Lua don't even come close to touching. Let me list some things that you'll see in Python code that you're not gonna see in JS or Lua: * Objects that don't extend the object hierarchy (you don't have to extend from `object`) * Types that don't extend the type hierarchy (Python has full metaclassing) * Any object can elect to become callable; calls are almost message passes * Two different levels of message-passing method/attribute rewriting (__getattr__ and __getattribute__) * Descriptors, such as properties (no, real properties) are baked into the object model * The table of globals can be altered at any time, frustrating static analysis * The table of locals can be altered too! * The table of builtins can be altered!! (Is nothing sacred?) In addition, PyPy did not start out as a partial evaluator and meta-tracing JIT generator. What you're seeing is the result of about a decade of work and a half-dozen iterations. They started out with something much like the thing that you would expect to see, but just like every other Python JIT project, they learned that Python is complex and difficult to optimize. So, uh, you're wrong. Sorry.
- silverlake 13y ago
  is Python more complicated than Lisp or Scheme or Smalltalk or Self? All are dynamically typed and infinitely flexible.

enupten 13y ago

There is some truth here; even the militantly dynamic Common lisp has a blisteringly fast implementation (SBCL).

fijal 13y ago

I think you underestimate the complexity of Python language. Note that PyPy is not the only project that did that - remember psyco? There are reasons why after 3 years Armin said "I give up, let's do PyPy". It's not the "well behaved" part, this can be worked around, Python is simply more complex than Javascript or Lua and by complex I mean just bigger. All the extension modules that everyone naturally expects to be fast (even just the stdlib), descriptor protocol, crazy frame access semantics. That does make it very labour intensive to do the right thing. Look what happened to Unladen Swallow - they did not get anywhere really within a year. Several of PyPy optimizations that took forever to do are really new stuff, whether you do JIT by hand or generate it automatically.

nostrademons 13y ago
The last time I talked with the Unladen Swallow guys (a couple years ago), they were pretty clear that one of their main stumbling blocks was supporting the Python/C API, and wanting to have complete compatibility with C extension modules. While we can't really know how hard the task would've been if they'd lifted that requirement - it was baked into their design from an early stage - when I'd floated the idea of doing a from-the-ground-up LLVM-based implementation of Python, they seemed significantly more optimistic. It wouldn't be all that useful for most people, but it would've worked fine for my use case. Alas, it's doubtful that a Python implementation that sacrifices C extensions would get all that far with mainstream adopters, as so many useful libraries are done as C extensions.
- fijal 13y ago
  They were optimistic at the beginning too (even with C extensions). How would it fill your usecase in a way that pypy does not?
  - nostrademons 13y ago
    We were looking for something easily embeddable, but all host modules were provided by the application, so there was no need for outside C extensions. And the set of libraries that was importable was restricted and coding styleguides banned advanced language features like metaprogramming, so we could afford to cut corners on corner cases of the language. "Decent" performance (i.e. more like Java than CPython) was a requirement, as was multithreading support and lack of a GIL, and RAM usage was also at a premium (which was probably the largest argument against PyPy...also, this was a couple years ago, when PyPy was not as mature).

MostAwesomeDude 13y ago

You are wrong. Python's object model is incredibly rich in ways that JavaScript and Lua don't even come close to touching. Let me list some things that you'll see in Python code that you're not gonna see in JS or Lua: * Objects that don't extend the object hierarchy (you don't have to extend from `object`) * Types that don't extend the type hierarchy (Python has full metaclassing) * Any object can elect to become callable; calls are almost message passes * Two different levels of message-passing method/attribute rewriting (__getattr__ and __getattribute__) * Descriptors, such as properties (no, real properties) are baked into the object model * The table of globals can be altered at any time, frustrating static analysis * The table of locals can be altered too! * The table of builtins can be altered!! (Is nothing sacred?) In addition, PyPy did not start out as a partial evaluator and meta-tracing JIT generator. What you're seeing is the result of about a decade of work and a half-dozen iterations. They started out with something much like the thing that you would expect to see, but just like every other Python JIT project, they learned that Python is complex and difficult to optimize. So, uh, you're wrong. Sorry.

silverlake 13y ago
is Python more complicated than Lisp or Scheme or Smalltalk or Self? All are dynamically typed and infinitely flexible.