4 ms·

I don't think it's true to say that Python's core developers are uninterested in performance. Speeding up Python is a hard problem. He mentions PyPy but even th

I don't think it's true to say that Python's core developers are uninterested in performance. Speeding up Python is a hard problem. He mentions PyPy but even that has only managed modest performance gains in some areas (and not without tradeoffs). He suggests JavaScript as a comparison but doesn't elaborate on how they're comparable beyond the superficial (they're both dynamic scripting languages). I get that he's frustrated with Python's performance but it would be really interesting to hear from someone who knows the technology involved rather than simple speculation.

civility 9y ago
If you neglect some of the metaclass stuff, which I believe most people do, then Python is nearly isomorphic to JavaScript. I think the comparison is very fair. I also believe the reason Python is unlikely to ever catch up to JavaScript is the same reason that CPython will always be the dominant implementation - They've exposed so much of the C internals, that everyone is bound to the actual slow and single threaded implementation. JavaScript implementations in web browsers can do lots of magic behind the curtains because the majority of users don't rely on the actual innards being consistent from release to release.
shakna 9y ago
Viper is an interesting approach on speeding up Python. It's developed for MicroPython, which does give them room for breaking changes, but has trade-offs. Arithmetic is much faster, but dictionary lookups take much longer compared to CPython. Viper is a code-emitter from a large subset of Python, and even allows for inline assembly. But it's only for a few architectures at the moment, like ARM and x86.
- cromat3 9y ago
  Viper is called Zerynth today: https://wiki.python.org/moin/Zerynth https://wiki.python.org/moin/Zerynth
  - shakna 9y ago
    They're similar, but not the same. Zerynth is a development suite. Notably, it makes use of a VM. Viper is just one of the code emitters buried inside the MicroPython source code, like here [0]. Notably, it produces native code, not bytecode for a VM. [0] https://github.com/micropython/micropython/blob/master/py/objfun.c#L417 https://github.com/micropython/micropython/blob/master/py/ob...
alphaalpha101 9y ago
Python is much more dynamic than Javascript. Python lets you inspect stack frames. Python's metaprogramming features exist, for a start, but are also widely used. Javascript is a pretty static-feeling language when you come from Python. Most of its 'dynamic' nature can be captured by Typescript's type system i.e. basically returning different types from functions depending on which constant values you pass in. This sort of thing: declare function foo(x: 'type1'): Type1; declare function foo(x: 'type2'): Type2; Python is dynamic on a whole 'nother level.
pjmlp 9y ago
Common Lisp, Dylan and Smalltalk are as dynamic as Python, yet they all enjoy of good quality native code compilers (AOT/JIT).
- klibertp 9y ago
  To be honest, Dylan is not exactly alive anymore. CL and Smalltalk still have commercial vendors providing implementations, Dylan has currently two implementations, but one of those (Gwydion) is completely neglected and the other (OpenDylan) has maybe 5 developers working on it in their spare time. It's a shame because even with its verbose syntax Dylan is a nice language, with a module system, with object system based on multimethods, with hygienic macros and, as you noted, an AOT compiler. It could be huge. We could have ended with Dylan in the place of Java and we'd be better off with that. I consider Dylan one of the biggest missed opportunities in PL space.
  - pjmlp 9y ago
    True, but they all provide real life examples of what it possible in terms of compilation. On Dylan's case, the team even decided to implement their own OS as last milestone, although the decision had already fallen for using C++ instead. So this all Ruby and Python are slow because they are dynamic, isn't exactly how things went in other equally dynamic languages. Python JITs just need a bit more love.
Animats 9y ago
Python's little tin god really likes his CPython implementation being the One True Python. Python does the things that are easy to do in an interpreter where everything is a dictionary, and avoids things which are hard to do in that environment. In Python, you can store into any variable in any thread from any other thread. You can replace code being executed in another thread. Even Javascript doesn't let you do that. This functionality is very rarely used, and makes it really hard to optimize Python. (And no, calling C whenever you need to go fast is not a solution. Calling C from Python is risky; you have to maintain all the invariants of the Python system, manually incrementing and decrementing reference counts, and be very careful about not assuming things don't change in the data structures you're looking at. This is not trivial.) A generation ago, Pascal had the same problem. Wirth had an elegant recursive-descent compiler that didn't optimize. He insisted it be the One True Compiler, and managed to get the ISO standard for Pascal to reflect that. The decline of Pascal followed, although Turbo Pascal for DOS, a much more powerful dialect, had a good run, and Delphi still lives on.
- orf 9y ago
  > Python's little tin god really likes his CPython implementation being the One True Python. No, he likes it to be the reference implementation, as it both is and should be. It's simple for a reason. > This functionality is very rarely used It's used all the time by debuggers, and the underlying features that allow you to do this is one of the most core and intrinsic things in Python.
loeg 9y ago
PyPy achieves huge performance gains in most long-running code. I don't know what you mean by modest. The main hurdle is slightly longer start-up times while the JIT warms up (comparable to Java). http://speed.pypy.org/ http://speed.pypy.org/

civility 9y ago

If you neglect some of the metaclass stuff, which I believe most people do, then Python is nearly isomorphic to JavaScript. I think the comparison is very fair. I also believe the reason Python is unlikely to ever catch up to JavaScript is the same reason that CPython will always be the dominant implementation - They've exposed so much of the C internals, that everyone is bound to the actual slow and single threaded implementation. JavaScript implementations in web browsers can do lots of magic behind the curtains because the majority of users don't rely on the actual innards being consistent from release to release.

shakna 9y ago

Viper is an interesting approach on speeding up Python. It's developed for MicroPython, which does give them room for breaking changes, but has trade-offs. Arithmetic is much faster, but dictionary lookups take much longer compared to CPython. Viper is a code-emitter from a large subset of Python, and even allows for inline assembly. But it's only for a few architectures at the moment, like ARM and x86.

cromat3 9y ago
Viper is called Zerynth today: https://wiki.python.org/moin/Zerynth https://wiki.python.org/moin/Zerynth
- shakna 9y ago
  They're similar, but not the same. Zerynth is a development suite. Notably, it makes use of a VM. Viper is just one of the code emitters buried inside the MicroPython source code, like here [0]. Notably, it produces native code, not bytecode for a VM. [0] https://github.com/micropython/micropython/blob/master/py/objfun.c#L417 https://github.com/micropython/micropython/blob/master/py/ob...

alphaalpha101 9y ago

Python is much more dynamic than Javascript. Python lets you inspect stack frames. Python's metaprogramming features exist, for a start, but are also widely used. Javascript is a pretty static-feeling language when you come from Python. Most of its 'dynamic' nature can be captured by Typescript's type system i.e. basically returning different types from functions depending on which constant values you pass in. This sort of thing: declare function foo(x: 'type1'): Type1; declare function foo(x: 'type2'): Type2; Python is dynamic on a whole 'nother level.

pjmlp 9y ago

Common Lisp, Dylan and Smalltalk are as dynamic as Python, yet they all enjoy of good quality native code compilers (AOT/JIT).

klibertp 9y ago
To be honest, Dylan is not exactly alive anymore. CL and Smalltalk still have commercial vendors providing implementations, Dylan has currently two implementations, but one of those (Gwydion) is completely neglected and the other (OpenDylan) has maybe 5 developers working on it in their spare time. It's a shame because even with its verbose syntax Dylan is a nice language, with a module system, with object system based on multimethods, with hygienic macros and, as you noted, an AOT compiler. It could be huge. We could have ended with Dylan in the place of Java and we'd be better off with that. I consider Dylan one of the biggest missed opportunities in PL space.
- pjmlp 9y ago
  True, but they all provide real life examples of what it possible in terms of compilation. On Dylan's case, the team even decided to implement their own OS as last milestone, although the decision had already fallen for using C++ instead. So this all Ruby and Python are slow because they are dynamic, isn't exactly how things went in other equally dynamic languages. Python JITs just need a bit more love.

Animats 9y ago

Python's little tin god really likes his CPython implementation being the One True Python. Python does the things that are easy to do in an interpreter where everything is a dictionary, and avoids things which are hard to do in that environment. In Python, you can store into any variable in any thread from any other thread. You can replace code being executed in another thread. Even Javascript doesn't let you do that. This functionality is very rarely used, and makes it really hard to optimize Python. (And no, calling C whenever you need to go fast is not a solution. Calling C from Python is risky; you have to maintain all the invariants of the Python system, manually incrementing and decrementing reference counts, and be very careful about not assuming things don't change in the data structures you're looking at. This is not trivial.) A generation ago, Pascal had the same problem. Wirth had an elegant recursive-descent compiler that didn't optimize. He insisted it be the One True Compiler, and managed to get the ISO standard for Pascal to reflect that. The decline of Pascal followed, although Turbo Pascal for DOS, a much more powerful dialect, had a good run, and Delphi still lives on.

orf 9y ago
> Python's little tin god really likes his CPython implementation being the One True Python. No, he likes it to be the reference implementation, as it both is and should be. It's simple for a reason. > This functionality is very rarely used It's used all the time by debuggers, and the underlying features that allow you to do this is one of the most core and intrinsic things in Python.

loeg 9y ago

PyPy achieves huge performance gains in most long-running code. I don't know what you mean by modest. The main hurdle is slightly longer start-up times while the JIT warms up (comparable to Java). http://speed.pypy.org/ http://speed.pypy.org/