4 ms·

Is it just me who sees a large chunk of these as flaws in the Python implementation as opposed to the Python language? Dynamic typing can often be optimized at

Is it just me who sees a large chunk of these as flaws in the Python implementation as opposed to the Python language? Dynamic typing can often be optimized at the compilation stage - and yes, Python has a compilation stage - this particular example is basic type inference, for example. Even more complex examples can be optimized by emitting specialized versions for the types that the compiler can see it will be called with. Effectively emitting specialized versions of specific nodes in the control flow graph.

dagw 12y ago
Is it just me who sees a large chunk of these as flaws in the Python implementation as opposed to the Python language? There are a number of design decision in python language that makes it inherently hard to write a fast python implementation.
- Animats 12y ago
  Ah, the right answer! There are lots of languages where variables are dynamically typed that can be compiled and optimized with a JIT compiler. In Python, though, any code can mess with any data, using "setattr". You can find all the variables in another module and mess with them at run time, using their names as strings. At compile time, the compiler can't detect that's going to happen. This is sometimes called the Guido von Rossum Memorial Boat Anchor. So Python implementations usually have to assume the worst case. Google's attempt at a faster, compatible Python, "Unladen Swallow", was an embarrassing failure. PyPy manages to get past that, but at a huge cost in JIT compiler complexity. After 12 years of work, PyPy is finally shipping stable versions and starting to get some use. It's been all uphill for the PyPy developers, though. It's kind of sad. Python never achieved its full potential because of the speed problem. Google ended up developing Go because Python was too slow.
  - adamtj 12y ago
    How is python substantially different from javascript in this case? Google has a crazy fast javascript JIT compiler, even though javascript has something equivalent to python's setattr().
    - masklinn 12y ago
      > even though javascript has something equivalent to python's setattr(). Python provides significantly more hooks into the behaviour of arbitrary objects, and arguably provides more flexibility than JS. Here are a few notes from Mike Pall (LuaJIT) on Python features making a straight interpreter slower, and the language harder to optimise (JIT tightly): http://lua-users.org/lists/lua-l/2004-11/msg00083.html http://lua-users.org/lists/lua-l/2004-11/msg00083.html Animats is full of shit, the ability to add arbitrary "static" attributes to existing objects is really not the main problem.
  - nostrademons 12y ago
    Google ended up developing Go because C++ was too hard to use, not because Python was too slow. The initial target market for Go was C++ programmers - it's only once it was exposed to the Internet that they found out there were more Python programmers interested in a faster Python than C++ programmers interested in an easier C++.
- masklinn 12y ago
  He said "a large number of" though, not "all".
shanemhansen 12y ago
You are technically correct. A Sufficiently Smart Compiler(TM) could theoretically optimize python code. However certain language features can be inherently difficult to optimize. Most of it's over my head, but headius has written some great articles as part of his experience of implementing ruby on the jvm. http://blog.headius.com/2012/09/avoiding-hash-lookups-in-ruby.html http://blog.headius.com/2012/09/avoiding-hash-lookups-in-rub...

dagw 12y ago

Is it just me who sees a large chunk of these as flaws in the Python implementation as opposed to the Python language? There are a number of design decision in python language that makes it inherently hard to write a fast python implementation.

Animats 12y ago
Ah, the right answer! There are lots of languages where variables are dynamically typed that can be compiled and optimized with a JIT compiler. In Python, though, any code can mess with any data, using "setattr". You can find all the variables in another module and mess with them at run time, using their names as strings. At compile time, the compiler can't detect that's going to happen. This is sometimes called the Guido von Rossum Memorial Boat Anchor. So Python implementations usually have to assume the worst case. Google's attempt at a faster, compatible Python, "Unladen Swallow", was an embarrassing failure. PyPy manages to get past that, but at a huge cost in JIT compiler complexity. After 12 years of work, PyPy is finally shipping stable versions and starting to get some use. It's been all uphill for the PyPy developers, though. It's kind of sad. Python never achieved its full potential because of the speed problem. Google ended up developing Go because Python was too slow.
- adamtj 12y ago
  How is python substantially different from javascript in this case? Google has a crazy fast javascript JIT compiler, even though javascript has something equivalent to python's setattr().
  - masklinn 12y ago
    > even though javascript has something equivalent to python's setattr(). Python provides significantly more hooks into the behaviour of arbitrary objects, and arguably provides more flexibility than JS. Here are a few notes from Mike Pall (LuaJIT) on Python features making a straight interpreter slower, and the language harder to optimise (JIT tightly): http://lua-users.org/lists/lua-l/2004-11/msg00083.html http://lua-users.org/lists/lua-l/2004-11/msg00083.html Animats is full of shit, the ability to add arbitrary "static" attributes to existing objects is really not the main problem.
- nostrademons 12y ago
  Google ended up developing Go because C++ was too hard to use, not because Python was too slow. The initial target market for Go was C++ programmers - it's only once it was exposed to the Internet that they found out there were more Python programmers interested in a faster Python than C++ programmers interested in an easier C++.
masklinn 12y ago
He said "a large number of" though, not "all".

shanemhansen 12y ago

You are technically correct. A Sufficiently Smart Compiler(TM) could theoretically optimize python code. However certain language features can be inherently difficult to optimize. Most of it's over my head, but headius has written some great articles as part of his experience of implementing ruby on the jvm. http://blog.headius.com/2012/09/avoiding-hash-lookups-in-ruby.html http://blog.headius.com/2012/09/avoiding-hash-lookups-in-rub...