Re: [Python-Dev] Benchmarks why we need PEP 576/579/580

2018-07-21 Thread INADA Naoki
> > I am comparing calls through tp_call (A) versus optimized call paths > (B). I only need to assume that the speed improvements to (A) between > 2.7 and 3.7 are not bigger than the speed improvements to (B). > It's interesting... But I failed to build sage. It's build step is too different from

Re: [Python-Dev] Benchmarks why we need PEP 576/579/580

2018-07-21 Thread Steve Holden
On Sun, Jul 22, 2018 at 12:14 AM, Guido van Rossum wrote: > ​[...] > The new BDFL may be less demanding though. :=) > ​I sincerely hope not. regards Steve​ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/pyt

Re: [Python-Dev] Benchmarks why we need PEP 576/579/580

2018-07-21 Thread Guido van Rossum
The cost would be if we were to end up maintaining all that code and it wouldn’t make much difference. Jeroen was asked to provide benchmarks but only provided them for Python 2. The reasoning that not much has changed that could affect the benchmarks feels a bit optimistic, that’s all. The new BD

Re: [Python-Dev] Benchmarks why we need PEP 576/579/580

2018-07-21 Thread Stefan Behnel
Guido van Rossum schrieb am 21.07.2018 um 22:46: > Given the cost of a mistake here I recommend a higher standard. May I ask what you think the "cost of a mistake" is here? Jeroen has already implemented most of this, and is willing to provide essentially a shrink-wrapped implementation. He has s

Re: [Python-Dev] Benchmarks why we need PEP 576/579/580

2018-07-21 Thread Guido van Rossum
Given the cost of a mistake here I recommend a higher standard. But in the end it’s no longer my decision. On Sat, Jul 21, 2018 at 11:18 AM Jeroen Demeyer wrote: > On 2018-07-21 19:55, Guido van Rossum wrote: > > I don’t think we can safely assume Python 3.7 has the same performance, > > actuall

Re: [Python-Dev] Benchmarks why we need PEP 576/579/580

2018-07-21 Thread Jeroen Demeyer
On 2018-07-21 19:55, Guido van Rossum wrote: I don’t think we can safely assume Python 3.7 has the same performance, actually. A lot has changed. I'm not denying that some things have changed. Rather, I claim that those changes wouldn't invalidate the benchmarks. I am comparing calls through

Re: [Python-Dev] Benchmarks why we need PEP 576/579/580

2018-07-21 Thread Jeroen Demeyer
On 2018-07-21 19:07, INADA Naoki wrote: Good job. But I already +1 for adding support for extension callable type. Do you think this benchmark can be optimized more in future optimization which is possible by PEP 580, but not 576? I should clarify that the benchmark did not involve an implemen

Re: [Python-Dev] Benchmarks why we need PEP 576/579/580

2018-07-21 Thread Guido van Rossum
I don’t think we can safely assume Python 3.7 has the same performance, actually. A lot has changed. On Sat, Jul 21, 2018 at 10:10 AM INADA Naoki wrote: > On Sun, Jul 22, 2018 at 1:28 AM Jeroen Demeyer wrote: > > > > Hello, > > > > I finally managed to get some real-life benchmarks for why we n

Re: [Python-Dev] Benchmarks why we need PEP 576/579/580

2018-07-21 Thread INADA Naoki
On Sun, Jul 22, 2018 at 1:28 AM Jeroen Demeyer wrote: > > Hello, > > I finally managed to get some real-life benchmarks for why we need a > faster C calling protocol (see PEPs 576, 579, 580). Good job. But I already +1 for adding support for extension callable type. Do you think this benchmark c

[Python-Dev] Benchmarks why we need PEP 576/579/580

2018-07-21 Thread Jeroen Demeyer
Hello, I finally managed to get some real-life benchmarks for why we need a faster C calling protocol (see PEPs 576, 579, 580). I focused on the Cython compilation of SageMath. By default, a function in Cython is an instance of builtin_function_or_method (analogously, method_descriptor for a