Re: [Python-Dev] PEP 575 (Unifying function/method classes) update
On 2018-06-18 16:55, INADA Naoki wrote:
Speeding up most python function and some bultin functions was very significant. But I doubt making some 3rd party call 20% faster can make real applications significant faster.
These two sentences are almost contradictory. I find it strange to claim that a given optimization was "very significant" in specific cases while saying that the same optimization won't matter in other cases. People *have* done benchmarks for actual code and this is causing actual slow-downs of around 20% in actual applications. That is the main reason why I am trying to push this PEP (or PEP 575 which solves the same problem in a different way). Jeroen.
On Tue, Jun 19, 2018 at 2:56 PM Jeroen Demeyer <J.Demeyer@ugent.be> wrote:
On 2018-06-18 16:55, INADA Naoki wrote:
Speeding up most python function and some bultin functions was very significant. But I doubt making some 3rd party call 20% faster can make real applications significant faster.
These two sentences are almost contradictory. I find it strange to claim that a given optimization was "very significant" in specific cases while saying that the same optimization won't matter in other cases.
It's not contradictory because there is basis: In most real world Python application, number of calling Python methods or bulitin functions are much more than other calls. For example, optimization for bulitin `tp_init` or `tp_new` by FASTCALL was rejected because it's implementation is complex and it's performance gain is not significant enough on macro benchmarks. And I doubt number of 3rd party calls are much more than calling builtin tp_init or tp_new. Of course, current benchmark suite [1] doesn't cover all types of real world Python application. You can create pull request which add benchmark for real world application which depends on massive 3rd party calls. [1] https://github.com/python/performance Regards, -- INADA Naoki <songofacandy@gmail.com>
On 19 June 2018 at 16:12, INADA Naoki <songofacandy@gmail.com> wrote:
On Tue, Jun 19, 2018 at 2:56 PM Jeroen Demeyer <J.Demeyer@ugent.be> wrote:
On 2018-06-18 16:55, INADA Naoki wrote:
Speeding up most python function and some bultin functions was very significant. But I doubt making some 3rd party call 20% faster can make real applications significant faster.
These two sentences are almost contradictory. I find it strange to claim that a given optimization was "very significant" in specific cases while saying that the same optimization won't matter in other cases.
It's not contradictory because there is basis:
In most real world Python application, number of calling Python methods or bulitin functions are much more than other calls.
For example, optimization for bulitin `tp_init` or `tp_new` by FASTCALL was rejected because it's implementation is complex and it's performance gain is not significant enough on macro benchmarks.
And I doubt number of 3rd party calls are much more than calling builtin tp_init or tp_new.
I don't think this assumption is correct, as scientific Python software spends a lot of time calling other components in the scientific Python stack, and bypassing the core language runtime entirely. However, they're using the CPython C API's function calling abstractions to do it, and those are currently expensive (frustratingly so, when the caller, the callee, *and* the interpreter implementation defining the call abstraction layer are all implemented in C). Hence Jeroen's PEPs to make the FASTCALL API a generally available one. That's quite different from the situation with object constructors, where a whole lot of applications will get to the point of having a relatively stable working set of objects, and then see the rate of object creation slow down markedly. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 19 June 2018 at 13:02, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 19 June 2018 at 16:12, INADA Naoki <songofacandy@gmail.com> wrote:
On Tue, Jun 19, 2018 at 2:56 PM Jeroen Demeyer <J.Demeyer@ugent.be>
wrote:
On 2018-06-18 16:55, INADA Naoki wrote:
Speeding up most python function and some bultin functions was very significant. But I doubt making some 3rd party call 20% faster can make real applications significant faster.
These two sentences are almost contradictory. I find it strange to claim that a given optimization was "very significant" in specific cases while saying that the same optimization won't matter in other cases.
It's not contradictory because there is basis:
In most real world Python application, number of calling Python methods or bulitin functions are much more than other calls.
For example, optimization for bulitin `tp_init` or `tp_new` by FASTCALL was rejected because it's implementation is complex and it's performance gain is not significant enough on macro benchmarks.
And I doubt number of 3rd party calls are much more than calling builtin tp_init or tp_new.
I don't think this assumption is correct, as scientific Python software spends a lot of time calling other components in the scientific Python stack, and bypassing the core language runtime entirely.
A recent Python survey by PSF/JetBrains shows that almost half of current Python users are using it for data science/ML/etc. For all these people most of the time is spent on calling C functions in extensions. -- Ivan
That's why I suggested to add new benchmark. 2018年6月19日(火) 22:22 Ivan Levkivskyi <levkivskyi@gmail.com>:
On 19 June 2018 at 13:02, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 19 June 2018 at 16:12, INADA Naoki <songofacandy@gmail.com> wrote:
On Tue, Jun 19, 2018 at 2:56 PM Jeroen Demeyer <J.Demeyer@ugent.be>
wrote:
On 2018-06-18 16:55, INADA Naoki wrote:
Speeding up most python function and some bultin functions was very significant. But I doubt making some 3rd party call 20% faster can make real applications significant faster.
These two sentences are almost contradictory. I find it strange to
claim
that a given optimization was "very significant" in specific cases while saying that the same optimization won't matter in other cases.
It's not contradictory because there is basis:
In most real world Python application, number of calling Python methods or bulitin functions are much more than other calls.
For example, optimization for bulitin `tp_init` or `tp_new` by FASTCALL was rejected because it's implementation is complex and it's performance gain is not significant enough on macro benchmarks.
And I doubt number of 3rd party calls are much more than calling builtin tp_init or tp_new.
I don't think this assumption is correct, as scientific Python software spends a lot of time calling other components in the scientific Python stack, and bypassing the core language runtime entirely.
A recent Python survey by PSF/JetBrains shows that almost half of current Python users are using it for data science/ML/etc. For all these people most of the time is spent on calling C functions in extensions.
-- Ivan
On 19 June 2018 at 16:12, INADA Naoki <songofacandy@gmail.com> wrote:
On Tue, Jun 19, 2018 at 2:56 PM Jeroen Demeyer <J.Demeyer@ugent.be> wrote:
On 2018-06-18 16:55, INADA Naoki wrote:
Speeding up most python function and some bultin functions was very significant. But I doubt making some 3rd party call 20% faster can make real applications significant faster.
These two sentences are almost contradictory. I find it strange to claim that a given optimization was "very significant" in specific cases while saying that the same optimization won't matter in other cases.
It's not contradictory because there is basis:
In most real world Python application, number of calling Python methods or bulitin functions are much more than other calls.
For example, optimization for bulitin `tp_init` or `tp_new` by FASTCALL was rejected because it's implementation is complex and it's performance gain is not significant enough on macro benchmarks.
And I doubt number of 3rd party calls are much more than calling builtin tp_init or tp_new.
I was going to ask a question here about JSON parsing micro-benchmarks, but then I went back and re-read https://blog.sentry.io/2016/10/19/fixing-python-performance-with-rust.html and realised that the main problem discussed in that article was the *memory* overhead of creating full Python object instances, not the runtime cost of instantiating those objects. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (4)
-
INADA Naoki -
Ivan Levkivskyi -
Jeroen Demeyer -
Nick Coghlan