Re:Why Python Is Slow: Looking Under the Hood (2014)
by amenod on Thursday July 07, 2016 @05:25PM
(#12052175)
It is easy to miss the point with such articles. OP touched upon it in chapter "So Why Use Python?". Raw speed, while sexy, is not a deciding factor in most cases - not everybody is working on HFT. And when it is important to be really fast, you can always write an extension in C (or Rust I imagine?) just for that single tight loop and get raw speed without sacrificing maintainability. Seriously, most bottlenecks (in other people's software of course ;) I came across were either due to bad architecture or unreadable code, which lead to not noticing that too much work was being done. So yeah, Python might be slower than alternatives (though I have a hard time believing that it is slower than Java), but it is fast enough.
[ Parent
| on HN ]
Re:Why Python Is Slow: Looking Under the Hood (2014)
by cwyers on Thursday July 07, 2016 @07:32PM
(#12052754)
Oh, the crippling sense of irony that comes from reading this comment after reading the front page post about Azul and the JVM, with a lot of technical details about how HFT firms use Java.
Re:Why Python Is Slow: Looking Under the Hood (2014)
by nitsujin on Thursday July 07, 2016 @05:48PM
(#12052283)
Are you kidding? Java is much, much faster than Python.
Re:Why Python Is Slow: Looking Under the Hood (2014)
by satysin on Thursday July 07, 2016 @06:06PM
(#12052373)
Java absolutely destroys Python when it comes to speed comparisons.
Re:Why Python Is Slow: Looking Under the Hood (2014)
by amelius on Thursday July 07, 2016 @05:34PM
(#12052224)
This might certainly be true for single threaded programs. For multithreaded programs, Python has a bottleneck known as the "Global Interpreter Lock" (or GIL), which is not so easily optimized away, unfortunately.
Re:Why Python Is Slow: Looking Under the Hood (2014)
by d0mine on Thursday July 07, 2016 @06:01PM
(#12052342)
GIL may and does get released in the interpreter (on I/O) and C extensions such as regex, lxml, numpy. Performance sensitive extensions may even use multiple CPU cores implicitly e.g., as numpy.dot() can do for large enough input without changing the code in any way.
Re:Why Python Is Slow: Looking Under the Hood (2014)
by retrogradeorbit on Friday July 08, 2016 @04:25AM
(#12054214)
Yes, leading to C extensions that are not thread safe and so can't be used in multi-threaded code at all. An example I'm familiar with is pylibmc.
Re:Why Python Is Slow: Looking Under the Hood (2014)
by d0mine on Sunday July 10, 2016 @03:47PM
(#12066970)
Wrong. GIL does NOT necessarily make your Python/C code thread-safe and in reverse releasing GIL does not prevent you from writing a thread-safe code.
Re:Why Python Is Slow: Looking Under the Hood (2014)
by amenod on Thursday July 07, 2016 @05:43PM
(#12052264)
True, though this is not the kind of speed this article was talking about. You can get around that limitation somewhat by using multiprocessing module.
I'm not saying Python is the best language of all, but dissecting Python bytecode is kind of missing the point. Python's strong point is its ease of use.
Re:Why Python Is Slow: Looking Under the Hood (2014)
by curried_haskell on Thursday July 07, 2016 @06:13PM
(#12052403)
The only reason people might think of Java as slow, is because of desktop applications like LibreOffice, IntelliJ, or Eclipse. Java on the server blows Python out of the water in terms of speed.
Re:Why Python Is Slow: Looking Under the Hood (2014)
by Narishma on Thursday July 07, 2016 @06:22PM
(#12052447)
AFAIK LibreOffice is written in C++, not Java.