<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">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>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">https://www.curiousefficiency.org/posts/2015/10/languages-to-improve-your-python.html#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">https://www.curiousefficiency.org/posts/2017/10/considering-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)<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">-- <br><div class="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>