6 ms·

Sounds like you're looking for a Sufficiently Smart Compiler[0]. James Hague has a good piece on why this might not be so desirable[1]. One of the reasons I'm

Sounds like you're looking for a Sufficiently Smart Compiler[0]. James Hague has a good piece on why this might not be so desirable[1]. One of the reasons I'm fond of Python is that, while there is a tradeoff between flexibility and performance, it gives you the means to sacrifice flexibility to aid you in improving performance -- once you've identified what (if any) actual performance bottlenecks you face. [0] http://c2.com/cgi/wiki?SufficientlySmartCompiler http://c2.com/cgi/wiki?SufficientlySmartCompiler [1] http://prog21.dadgum.com/40.html http://prog21.dadgum.com/40.html

rjh29 14y ago
Well, there's PyPy, which is on average 5.7 times faster than CPython. So these optimisations are definitely possible, not hypothetical.
- apendleton 14y ago
  Actually, my experience with PyPy, while generally positive, has exhibited many of the characteristics that article talks about in terms of downsides to "sufficiently-smart compilers." It's almost always much faster than cpython, but how much faster is highly variable, and not especially predictably so; seemingly-insignificant changes can have large and unexpected performance implications, and it's difficult as a developer to have the proper mental model to figure out what's actually going on. In CPython land, Python is slower, but performs predictably, and if you want to speed it up you write C, which is much faster, and also performs predictably, though it takes some developer effort. In PyPy, you get some of the speed of C without the effort, but without the predictability either.
  - jrockway 14y ago
    C is also unpredictable: see the article from a couple days ago entitled "Why does my function run faster when the input array is sorted?" (The answer was: branch prediction.)
    - to3m 14y ago
      I'm not sure that counts in the same way. You would have the branch prediction issue even if you program in assembly language and have precise control over the instructions the computer executes.
Peaker 14y ago
Optimizing away getter/setter calls and function call overhead in general is well within the reach of current compilers.
- tjgq 14y ago
  In general, function calls cannot be inlined by the Python compiler because (almost) any function name may be re-bound to a different object at run time. A very smart compiler could probably attempt to prove that no such modification can occur at run time throughout the whole program; but this is much harder than simply deciding whether inlining a given call is worth it or not.
  - cma 14y ago
    V8 handles them w minimal overhead in JavaScript.
    - pjscott 14y ago
      And more to the point, PyPy can do Python inlining with its tracing JIT. The method, in both cases, is similar: find some type assumptions that are useful and usually true, generate code under those assumptions, and fall back on more generic code if they're ever false.
dmorgan 14y ago
>Sounds like you're looking for a Sufficiently Smart Compiler[0]. James Hague has a good piece on why this might not be so desirable[1]. So, sounds like he's looking for something like v8. if v8 can be 10-30 times faster than Python, for an equal or even more dynamic language, I don't see why Python should need to manual tune the things Guido describes in order to get some speed.

rjh29 14y ago

Well, there's PyPy, which is on average 5.7 times faster than CPython. So these optimisations are definitely possible, not hypothetical.

apendleton 14y ago
Actually, my experience with PyPy, while generally positive, has exhibited many of the characteristics that article talks about in terms of downsides to "sufficiently-smart compilers." It's almost always much faster than cpython, but how much faster is highly variable, and not especially predictably so; seemingly-insignificant changes can have large and unexpected performance implications, and it's difficult as a developer to have the proper mental model to figure out what's actually going on. In CPython land, Python is slower, but performs predictably, and if you want to speed it up you write C, which is much faster, and also performs predictably, though it takes some developer effort. In PyPy, you get some of the speed of C without the effort, but without the predictability either.
- jrockway 14y ago
  C is also unpredictable: see the article from a couple days ago entitled "Why does my function run faster when the input array is sorted?" (The answer was: branch prediction.)
  - to3m 14y ago
    I'm not sure that counts in the same way. You would have the branch prediction issue even if you program in assembly language and have precise control over the instructions the computer executes.

Peaker 14y ago

Optimizing away getter/setter calls and function call overhead in general is well within the reach of current compilers.

tjgq 14y ago
In general, function calls cannot be inlined by the Python compiler because (almost) any function name may be re-bound to a different object at run time. A very smart compiler could probably attempt to prove that no such modification can occur at run time throughout the whole program; but this is much harder than simply deciding whether inlining a given call is worth it or not.
- cma 14y ago
  V8 handles them w minimal overhead in JavaScript.
  - pjscott 14y ago
    And more to the point, PyPy can do Python inlining with its tracing JIT. The method, in both cases, is similar: find some type assumptions that are useful and usually true, generate code under those assumptions, and fall back on more generic code if they're ever false.

dmorgan 14y ago

>Sounds like you're looking for a Sufficiently Smart Compiler[0]. James Hague has a good piece on why this might not be so desirable[1]. So, sounds like he's looking for something like v8. if v8 can be 10-30 times faster than Python, for an equal or even more dynamic language, I don't see why Python should need to manual tune the things Guido describes in order to get some speed.