<div dir="ltr"><div><div><div><div><div><div><div><div><div>Hi all,<br><br></div>I would like to remark that, in my opinion, the question of CPython's performance cannot<br></div>be decoupled from the extremely wide selection of packages which provide optimized<br></div>code for almost any imaginable task.<br><br></div>For example: Javascript may be faster than (C)Python on simple benchmarks, but <br></div>as soon as the task is somewhat amenable to scypi, and I can use scipy in Python,<br></div>the resulting performance will completely cream Javascript in a way that isn't funny anymore.<br></div>And scipy is just an example, there are tons of such libraries for all kinds of tasks<br><br></div>I am not aware of any language ecosystem with a similar wide scope of packages;<br></div><div>at least Java and Node both fall short. (Node may have more packages by number<br></div><div>but the quality is definitely less and there is tons of overlap).<br><br></div><div>Stephan<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-01-27 7:42 GMT+01:00 Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On 27 January 2018 at 07:35, Pau Freixes <span dir="ltr"><<a href="mailto:pfreixes@gmail.com" target="_blank">pfreixes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
This could be considered an unimportant thing, but its more relevant<br>
than someone could expect, at least IMHO. If the default code that you<br>
can write in a language is by default slow and exists an alternative<br>
to make it faster, this language is doing something wrong.<br></blockquote><div><br></div></span>Not really, as we've seen with the relatively slow adoption of PyPy over the past several years.</div><div class="gmail_quote"><br></div><div class="gmail_quote">CPython, as an implementation, emphasises C/C++ compatibility, and internal interpreter simplicity. That comes at a definite cost in runtime performance (especially where attribute access and function calls are concerned), but has also enabled an enormous orchestration ecosystem, originally around C/C++/FORTRAN components, but now increasingly around Rust components within the same process, as well as out-of-process Java, C#, and JavaScript components. In this usage model, if Python code becomes the throughput bottleneck, it's only because something has gone wrong at the system architecture level.<br></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">PyPy, by contrast, emphasises raw speed, sacrificing various aspects of CPython's C/C++ interoperability in order to attain it. It's absolutely the implementation you want to be using if your main concern is the performance of your Python code in general, and there aren't any obvious hotspots that could be more selectively accelerated.</div><div class="gmail_extra"><br></div><div class="gmail_extra">To date, the CPython model of "Use (C)Python to figure out what kind of problem you have, then rewrite your performance bottlenecks in a language more specifically tailored to that problem space" has proven relatively popular. There's likely still more we can do within CPython to make typical code faster without increasing the interpreter complexity too much (e.g. Yury's idea of introducing an implicit per-opcode result cache into the eval loop), but opt-in solutions that explicit give up some of Python's language level dynamism are always going to be able to do less work at runtime than typical Python code does.<br clear="all"></div><br><div class="gmail_extra">Cheers,</div><div class="gmail_extra">Nick.</div><div class="gmail_extra"><br></div><div class="gmail_extra">P.S. You may find <a href="https://www.curiousefficiency.org/posts/2015/10/languages-to-improve-your-python.html#broadening-our-horizons" target="_blank">https://www.curiousefficiency.<wbr>org/posts/2015/10/languages-<wbr>to-improve-your-python.html#<wbr>broadening-our-horizons</a> interesting in the context of considering some of the many factors other than raw speed that may influence people's choice of programming language. Similarly, <a href="https://www.curiousefficiency.org/posts/2017/10/considering-pythons-target-audience.html" target="_blank">https://www.curiousefficiency.<wbr>org/posts/2017/10/considering-<wbr>pythons-target-audience.html</a> provides some additional info on the scope of Python's use cases (for the vast majority of which, "How many requests per second can I serve in a naive loop in a CPU bound process?" isn't a particularly relevant characteristic)<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div class="gmail_extra"><br></div><div class="gmail_extra">-- <br><div class="m_-8698691299546884307gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></font></span></div>
<br>______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a><br>
<br></blockquote></div><br></div>