On Sat, Jul 21, 2018 at 6:30 PM 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).
>
> I focused on the Cython compilation of SageMath. By default, a function
> in Cython is an instance of
On 2018-07-23 12:13, Antoine Pitrou wrote:
IMHO the main point of discussion should be judging the solution
you are proposing
Yes please. I would very much welcome a discussion about the actual
content of the PEP instead of meta-discussions like how complicated it is.
___
On Sun, Jul 22, 2018 at 7:42 PM Jeroen Demeyer wrote:
>
> On 2018-07-22 08:27, INADA Naoki wrote:
> > It's interesting... But I failed to build sage.
>
> What went wrong?
>
I can't install Sage into my virtual environment, so I can't run
> python -m timeit -s "from sage.all import MatrixSpace, G
On 2018-07-23 00:28, Guido van Rossum wrote:
So does your implementation of the PEP result in a net increase or
decrease of the total lines of code?
12 files changed, 918 insertions(+), 704 deletions(-)
That's a net increase, so there is no obvious win here. Still, I have
various excuses for
On Mon, Jul 23, 2018 at 7:20 PM Antoine Pitrou wrote:
>
> Just for the record, personally I have no doubt that the problems are
> real. IMHO the main point of discussion should be judging the solution
> you are proposing (and thank you, really, for being persistent, since
> this isn't an easy dis
On 2018-07-23 01:54, Ivan Pozdeev via Python-Dev wrote:
All the material to discuss that we have in this thread is a single test
result that's impossible to reproduce and impossible to run in Py3.
I just posted that it can be reproduced on Python 3.7:
https://mail.python.org/pipermail/python-de
On Mon, 23 Jul 2018 11:51:41 +0200
Jeroen Demeyer wrote:
> I did exactly the same benchmark again with Python 3.7 and the results
> are similar. I'm copying and editing the original post for completeness:
>
> [...]
>
> I hope that this finally shows that the problems mentioned in PEP 579
> are
I did exactly the same benchmark again with Python 3.7 and the results
are similar. I'm copying and editing the original post for completeness:
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 compil
I think it'll benefit all to keep the discussion objective, or at least
"good subjective"
(https://stackoverflow.blog/2010/09/29/good-subjective-bad-subjective/).
Laments or mutual accusations are only wasting everyone's time,
including the writers.
It's strange that even Guido jumped on the ba
On Sun, Jul 22, 2018 at 1:11 PM, Jeroen Demeyer wrote:
> On 2018-07-22 14:52, Stefan Behnel wrote:
>
>> Someone has to maintain the *existing* code
>> base and help newcomers to get into it and understand it.
>>
>
> This is an important point that people seem to be overlooking. The
> complexity a
On Sun, 22 Jul 2018 22:54:24 +0200
Jeroen Demeyer wrote:
>
> > - more importantly, issue26110 is entirely internal changes, while you
> >are proposing to add a new protocol (which is like a new API)
>
> Just to make sure I understand you: your point is that it's
> automatically more compl
Jeroen Demeyer schrieb am 22.07.2018 um 22:54:
> On 2018-07-22 22:32, Antoine Pitrou wrote:
>> - more importantly, issue26110 is entirely internal changes, while you
>> are proposing to add a new protocol (which is like a new API)
>
> Just to make sure I understand you: your point is that it's
On 2018-07-22 22:32, Antoine Pitrou wrote:
Two things:
- the issue26110 changes are not very large, it's just two additional
opcodes and a bit of support code
I didn't mean to compare PEP 580 to that specific issue, it was just an
example. Even if issue26110 is small, the total complexity a
On Sun, 22 Jul 2018 22:11:25 +0200
Jeroen Demeyer wrote:
> On 2018-07-22 14:52, Stefan Behnel wrote:
> > Someone has to maintain the *existing* code
> > base and help newcomers to get into it and understand it.
>
> This is an important point that people seem to be overlooking. The
> complexity
On 2018-07-22 14:52, Stefan Behnel wrote:
Someone has to maintain the *existing* code
base and help newcomers to get into it and understand it.
This is an important point that people seem to be overlooking. The
complexity and maintenance burden of PEP 580 should be compared to the
status-quo.
On 2018-07-22 18:14, Guido van Rossum wrote:
Sorry I don't have better news.
I don't consider that particularly bad news (but not good news either).
I feel like the status on PEP 580 isn't anywhere near accepted anyway.
I just hope that Python development won't stall completely. Even if no
OK, I believe you, I was just referring to the relative irreproducibility
of Jeroen's results (see INADA Naoki's problems).
My main point is actually that until the Python core devs have elected a
new BDFL or come up with some other process for accepting PEPs, no action
will be taken on this PEP -
Guido van Rossum schrieb am 22.07.2018 um 01:14:
> The cost would be if we were to end up maintaining all that code and it
> wouldn’t make much difference.
Well, this is exactly my point. Someone has to maintain the *existing* code
base and help newcomers to get into it and understand it. This is
On 2018-07-22 01:14, Guido van Rossum wrote:
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 micro-benchmarks showed a clear difference on Python 3.8 (git
On 2018-07-22 08:27, INADA Naoki wrote:
It's interesting... But I failed to build sage.
What went wrong?
It's build step is
too different from
normal Python package.
That's true because Sage considers itself a distribution rather than a
package. But it's possible to pick the distribution a
>
> 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
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
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
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
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
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
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
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
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
29 matches
Mail list logo
