[Python-ideas] Why CPython is still behind in performance for some widely used patterns ?

[Stephan Houben]

Hi all,

I would like to remark that, in my opinion, the question of CPython's
performance cannot
be decoupled from the extremely wide selection of packages which provide
optimized
code for almost any imaginable task.

For example: Javascript may be faster than (C)Python on simple benchmarks,
but
as soon as the task is somewhat amenable to scypi, and I can use scipy in
Python,
the resulting performance will completely cream Javascript in a way that
isn't funny anymore.
And scipy is just an example, there are tons of such libraries for all
kinds of tasks

I am not aware of any language ecosystem with a similar wide scope of
packages;
at least Java and Node both fall short. (Node may have more packages by
number
but the quality is definitely less and there is tons of overlap).

Stephan

2018-01-27 7:42 GMT+01:00 Nick Coghlan <ncoghlan at gmail.com>:

> On 27 January 2018 at 07:35, Pau Freixes <pfreixes at gmail.com> wrote:
>
>> This could be considered an unimportant thing, but its more relevant
>> than someone could expect, at least IMHO. If the default code that you
>> can write in a language is by default slow and exists an alternative
>> to make it faster, this language is doing something wrong.
>>
>
> Not really, as we've seen with the relatively slow adoption of PyPy over
> the past several years.
>
> 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.
>
> 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.
>
> 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.
>
> Cheers,
> Nick.
>
> P.S. You may find https://www.curiousefficiency.
> org/posts/2015/10/languages-to-improve-your-python.html#
> broadening-our-horizons 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, https://www.curiousefficiency.
> org/posts/2017/10/considering-pythons-target-audience.html 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)
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180127/b5dc297f/attachment.html>