When we talk about compiled languages, we usually mean "compiled to machine code". It's wrong to put a non-JITed "compiled to bytecode" language in the same category as C/C++/Haskell/Rust/Nim/etc.
> Furthermore, CPython addresses these issues by being a simple, stable, and easily-auditable virtual machine.
> Each runtime has its own performance characteristics, and none of them are slow per se.
Unfortunately, they all are slow when compared to the most efficient language/compiler available on the same platform. And no hand waving will fix this. Nor the small and not so small differences that render non-CPython implementations unusable in practice. The only valid argument remaining is that not all programs are CPU bound, but how many Python programmers are willing to say "I can only write non CPU-bound software in this language"?
> Having cleared that up, here is a small selection of cases where Python has offered significant performance advantages:
> Using NumPy as an interface to Intel’s MKL SIMD
The fast parts of NumPy are written in C. Python doesn't get to claim any performance advantage here.
I doesn't, they are just comparing different algorithms.
> Disqus scales from 250 to 500 million users on the same 100 boxes
Yes, thanks to Varnish that caches those slow Django requests, according to the linked article. Can you guess what language is Varnish written in? In the mean time, Disqus has also moved its slow as hell services to Go: http://highscalability.com/blog/2014/5/7/update-on-disqus-it... (a case where a shitty compiler that produces machine code beats a bytecode VM by so much it isn't even funny).
> It would be easy to get side-tracked into the wide world of high-performance Python
This depends on what you're smoking.
> One would be hard pressed to find Python programmers concerned about garbage collection pauses or application startup time.
Not garbage collection pauses, but in more than one occasion, when doing data migrations with processing done in Python, I had to call gc.collect() manually each N iterations to keep memory usage under control.
> With strong platform and networking support, Python naturally lends itself to smart horizontal scalability, as manifested in systems like BitTorrent.
> The GIL makes it much easier to use OS threads or green threads (greenlets usually), and does not affect using multiple processes.
The devil is in the details. You can only run OS threads in parallel if only one of them is Python code. To parallelize multiple instances of Python code you need to start multiple instances of the Python interpreter. Or you can pretend that you don't really need parallelism after all and cycle green threads on the same core while bragging about millions of requests per... day.
> Here’s hoping that this post manages to extinguish a flame war [...]
When we talk about compiled languages, we usually mean "compiled to machine code". It's wrong to put a non-JITed "compiled to bytecode" language in the same category as C/C++/Haskell/Rust/Nim/etc.
> Furthermore, CPython addresses these issues by being a simple, stable, and easily-auditable virtual machine.
http://www.cvedetails.com/vulnerability-list/vendor_id-10210...
> Each runtime has its own performance characteristics, and none of them are slow per se.
Unfortunately, they all are slow when compared to the most efficient language/compiler available on the same platform. And no hand waving will fix this. Nor the small and not so small differences that render non-CPython implementations unusable in practice. The only valid argument remaining is that not all programs are CPU bound, but how many Python programmers are willing to say "I can only write non CPU-bound software in this language"?
> Having cleared that up, here is a small selection of cases where Python has offered significant performance advantages:
> Using NumPy as an interface to Intel’s MKL SIMD
The fast parts of NumPy are written in C. Python doesn't get to claim any performance advantage here.
> PyPy‘s JIT compilation achieves faster-than-C performance
I doesn't, they are just comparing different algorithms.
> Disqus scales from 250 to 500 million users on the same 100 boxes
Yes, thanks to Varnish that caches those slow Django requests, according to the linked article. Can you guess what language is Varnish written in? In the mean time, Disqus has also moved its slow as hell services to Go: http://highscalability.com/blog/2014/5/7/update-on-disqus-it... (a case where a shitty compiler that produces machine code beats a bytecode VM by so much it isn't even funny).
> It would be easy to get side-tracked into the wide world of high-performance Python
This depends on what you're smoking.
> One would be hard pressed to find Python programmers concerned about garbage collection pauses or application startup time.
Not garbage collection pauses, but in more than one occasion, when doing data migrations with processing done in Python, I had to call gc.collect() manually each N iterations to keep memory usage under control.
> With strong platform and networking support, Python naturally lends itself to smart horizontal scalability, as manifested in systems like BitTorrent.
The BitTorrent library of choice nowadays is http://www.libtorrent.org/ - written in C++.
> The GIL makes it much easier to use OS threads or green threads (greenlets usually), and does not affect using multiple processes.
The devil is in the details. You can only run OS threads in parallel if only one of them is Python code. To parallelize multiple instances of Python code you need to start multiple instances of the Python interpreter. Or you can pretend that you don't really need parallelism after all and cycle green threads on the same core while bragging about millions of requests per... day.
> Here’s hoping that this post manages to extinguish a flame war [...]
:-)