>[boxed values...] The dynamic typing means that there are a lot more steps involved with any operation. This is a primary reason that Python is slow compared to C for operations on numerical data.<p>Not exactly. Setting typecodes and vals doesn’t slow things down by many orders of magnitude. The main reason python is relatively slow is that there is no practical way to reason about what parts of program may be optimized out or leveled down to native datatypes and then restructured in a very efficient way. This is what optimizing/jit compilers do to achieve much performance; this one is the source of x100, not unboxing on its own. Technically, tracing jit that doesn’t care if you’re writing in static or dynamic, strict or duck typing can be done for any language, but (afaik) python is not very jit-friendly in general.
Julia is all three, yet it's fast (allowing for jit, which in Julia is a one time cost). It's worth noting that those properties themselves are not what's critical, so much as designing around it and allowing for fast paths through critical code (locking down the dynamic types, first class array datatypes with packed forms)...
Python is optimized for small programs being easy and quick (and pleasant) to write.<p>Every other use case it fails in some way. For being slow. For lacking static typing. For lacking compilation. For having a GIL. etc.
I believe this article [0] (previous discussion [1]) from one of pyston's authors gives a <i>much</i> better overview of why python is slow.<p>[0] <a href="http://blog.kevmod.com/2016/07/why-is-python-slow/" rel="nofollow">http://blog.kevmod.com/2016/07/why-is-python-slow/</a>
[1] <a href="https://news.ycombinator.com/item?id=12025309" rel="nofollow">https://news.ycombinator.com/item?id=12025309</a>
Although I use and enjoy Python for some purposes, I can't help by see all the effort gone into improving Python performance (including Pypy, Cython, rewriting code in C, etc) as fixing a self-inflicted wound. Why are we using a language whose semantics make it very difficult to execute quickly?
From the article: "Dynamic typing makes Python easier to use than C." The author gives no justification for this claim. Do any language experts care to comment?
I thought this was pretty neat<p><pre><code> # WARNNG: never do this!
id113 = id(113)
iptr = IntStruct.from_address(id113)
iptr.ob_digit = 4 # now Python's 113 contains a 4!
113 == 4
</code></pre>
And now since the proper value 113 doesn't exist you have to resort to the binary representation on your system to revert back to normal behavior<p><pre><code> ctypes.cast(id113, ctypes.POINTER(ctypes.c_char))[3 * 8] = b'\x71'</code></pre>
I agree with this article. In practice, when writing number-crunching code in Python versus Java, I found that Python is usually 10 to 30× slower than Java, sometimes even 100× slower. See: <a href="https://www.nayuki.io/page/project-euler-solutions#benchmark-timings" rel="nofollow">https://www.nayuki.io/page/project-euler-solutions#benchmark...</a>
And yet there are entire industries built on the back of it. Everytime you see a a movie there'll be some Python code somehow responsible for the pixels you're seeing on the big screen.
How compatible are existing python libraries with pypy, and is the official python taking clues from pypy? Is there more work to do to make pypy even faster?
Except it isn't really. Yes, Python is incredibly slow for day to day stuff, but the sheer amount of easy to use numerical libraries (numpy, scipy, scikit-learn, tensorflow, keras, opencv, just to name a few) make it one of the fastest out there for numerical computation. I tried doing some numerical heavy stuff on the JVM (with Java and Clojure) and it fights you every step of the way ... and that has static typing and all the things the article mentions. Of course, Python derives that functionality from C and Fortran … but just having that interop at your fingertips is magical in terms of productivity. I still get nightmares from working with the JNI.
> Python being a dynamically typed, interpreted language<p>'CPython' is the defining implementation of the dynamically typed language 'Python' using a byte-code VM (and no jit compiler).<p><pre><code> bash-3.2$ time /tmp/bench.py
5000000050000000
real 0m19.763s
user 0m15.015s
sys 0m4.309s
</code></pre>
'SBCL' is an implementation of the dynamically typed language 'Common Lisp' using a native code compiler.<p><pre><code> bash-3.2$ time /tmp/bench.lisp
5000000050000000
real 0m0.319s
user 0m0.294s
sys 0m0.017s
</code></pre>
The unoptimized code is roughly 65 times faster in SBCL compared to CPython - including startup time.