Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 19 June 2018 at 16:12, INADA Naoki wrote: > > On Tue, Jun 19, 2018 at 2:56 PM Jeroen Demeyer 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

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

2018-06-19 13:58 GMT+02:00 Jeroen Demeyer : > Personally, I think that you are exaggerating these issues. I'm not trying to convince you to abandon the idea. I would be happy to be able to use FASTCALL in more cases! I just tried to explain why I chose to abandon my idea. FASTCALL is cute on

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 19 June 2018 at 13:02, Nick Coghlan wrote: > On 19 June 2018 at 16:12, INADA Naoki wrote: > > > > On Tue, Jun 19, 2018 at 2:56 PM Jeroen Demeyer > wrote: > >> > >> On 2018-06-18 16:55, INADA Naoki wrote: > >> > Speeding up most python function and some bultin functions was very > >> >

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

That's why I suggested to add new benchmark. 2018年6月19日(火) 22:22 Ivan Levkivskyi : > On 19 June 2018 at 13:02, Nick Coghlan wrote: > >> On 19 June 2018 at 16:12, INADA Naoki wrote: >> > >> > On Tue, Jun 19, 2018 at 2:56 PM Jeroen Demeyer >> wrote: >> >> >> >> On 2018-06-18 16:55, INADA Naoki

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 19 June 2018 at 16:12, INADA Naoki wrote: > > On Tue, Jun 19, 2018 at 2:56 PM Jeroen Demeyer 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

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 2018-06-18 15:09, Victor Stinner wrote: There are multiple issues with tp_fastcall: Personally, I think that you are exaggerating these issues. Below, I'm writing the word FASTCALL to refer to tp_fastcall in your patch as well as my C call protocol in the PEP-in-progress. * ABI issue:

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On Mon, 18 Jun 2018 19:49:28 +0200 Stefan Behnel wrote: > Victor Stinner schrieb am 18.06.2018 um 15:09: > > I tried two options to add support for FASTCALL on calling an object: > > add a flag in tp_flags and reuse tp_call, or add a new tp_fastcall > > slot. I failed to implement correctly any

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On Tue, Jun 19, 2018 at 2:56 PM Jeroen Demeyer 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. > >

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

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

Victor Stinner schrieb am 18.06.2018 um 15:09: > I tried two options to add support for FASTCALL on calling an object: > add a flag in tp_flags and reuse tp_call, or add a new tp_fastcall > slot. I failed to implement correctly any of these two options. > > There are multiple issues with

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

Like Inada-san, I would like to see the implementation first. On Mon, Jun 18, 2018, 07:33 Jeroen Demeyer wrote: > On 2018-06-18 15:09, Victor Stinner wrote: > > 2) we implemented a lot of other optimizations which made calls faster > > without having to touch tp_call nor tp_fastcall. > > And

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On Mon, Jun 18, 2018 at 11:33 PM Jeroen Demeyer wrote: > On 2018-06-18 15:09, Victor Stinner wrote: > > 2) we implemented a lot of other optimizations which made calls faster > > without having to touch tp_call nor tp_fastcall. > > And that's a problem because these optimizations typically only

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 2018-06-18 15:09, Victor Stinner wrote: 2) we implemented a lot of other optimizations which made calls faster without having to touch tp_call nor tp_fastcall. And that's a problem because these optimizations typically only work for specific classes. My PEP wants to replace those by

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

Hi, I tried two options to add support for FASTCALL on calling an object: add a flag in tp_flags and reuse tp_call, or add a new tp_fastcall slot. I failed to implement correctly any of these two options. There are multiple issues with tp_fastcall: * ABI issue: it's possible to load a C

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

I didn't meant comparing tp_fastcall and your PEP. I just meant we need to compare complexity and benefit (performance), and we need reference implementation for comparing. On Mon, Jun 18, 2018 at 3:03 PM Jeroen Demeyer wrote: > On 2018-06-18 03:34, INADA Naoki wrote: > > Victor had tried to

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 2018-06-18 03:34, INADA Naoki wrote: Victor had tried to add `tp_fastcall` slot, but he suspended his effort because it's benefit is not enough for it's complexity. https://bugs.python.org/issue29259 I has a quick look at that patch and it's really orthogonal to what I'm proposing. I'm

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

Hi Jeroen. It's interesting, but I think we need reference implementation to compare it's benefit with it's complexity. Victor had tried to add `tp_fastcall` slot, but he suspended his effort because it's benefit is not enough for it's complexity. https://bugs.python.org/issue29259 I think if

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

> On 17 Jun 2018, at 16:31, Stefan Behnel wrote: > > Ronald Oussoren schrieb am 17.06.2018 um 14:50: >> Why did you add a tp_ccalloffset slot to the type with the actual >> information in instances instead of storing the information in a slot? > > If the configuration of the callable was in

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 2018-06-17 14:50, Ronald Oussoren wrote: This looks interesting. Why did you add a tp_ccalloffset slot to the type with the actual information in instances instead of storing the information in a slot? Think of built-in functions. Every built-in function is a different callable and calls

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

Ronald Oussoren schrieb am 17.06.2018 um 14:50: > Why did you add a tp_ccalloffset slot to the type with the actual information > in instances instead of storing the information in a slot? If the configuration of the callable was in the type, you would need a separate type for each kind of

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

> On 17 Jun 2018, at 11:00, Jeroen Demeyer wrote: > > Hello, > > I have been working on a slightly different PEP to use a new type slot > tp_ccalloffset instead the base_function base class. You can see the work in > progress here: > > https://github.com/jdemeyer/PEP-ccall > > By

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 17 June 2018 at 19:00, Jeroen Demeyer wrote: > Hello, > > I have been working on a slightly different PEP to use a new type slot > tp_ccalloffset instead the base_function base class. You can see the work in > progress here: > > https://github.com/jdemeyer/PEP-ccall > > By creating a new

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

Hello, I have been working on a slightly different PEP to use a new type slot tp_ccalloffset instead the base_function base class. You can see the work in progress here: https://github.com/jdemeyer/PEP-ccall By creating a new protocol that each class can implement, there is a full

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

Having had some time to let this settle for a bit, I hope it doesn't get abandoned just because it was to complicated to come to a conclusion. I'd like to attempt to summarize the main ideas as follows. 1) Currently the "fast call" optimization is implemented by by checking explicitly for a set

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 2018-05-19 15:29, Nick Coghlan wrote: That's not how code reviews work, as their complexity is governed by the number of lines changed (added/removed/modified), not just the number of lines that are left at the end. Of course, you are right. I didn't mean literally that only the end result

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 17 May 2018 at 06:34, Jeroen Demeyer wrote: > On 2018-05-16 17:31, Petr Viktorin wrote: > >> The larger a change is, the harder it is to understand >> > > I already disagree here... > > I'm afraid that you are still confusing the largeness of the *change* with > the

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 2018-05-16 17:31, Petr Viktorin wrote: Less disruptive changes tend to have a better backwards compatibility story. A less intertwined change makes it easier to revert just a single part, in case that becomes necessary. I'll just repeat what I said in a different post on this thread: we can

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 2018-05-16 17:31, Petr Viktorin wrote: The larger a change is, the harder it is to understand I already disagree here... I'm afraid that you are still confusing the largeness of the *change* with the complexity of the *result* after the change was implemented. A change that *removes*

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

Petr Viktorin schrieb am 15.05.2018 um 18:36: > On 05/15/18 05:15, Jeroen Demeyer wrote: >> An important note is that it was never my goal to create a minimal PEP. I >> did not aim for changing as little as possible. I was thinking: we are >> changing functions, what would be the best way to

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 05/15/18 17:55, Jeroen Demeyer wrote: On 2018-05-15 18:36, Petr Viktorin wrote: Naturally, large-scale changes have less of a chance there. Does it really matter that much how large the change is? I think you are focusing too much on the change instead of the end result. As I said in my

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 2018-05-15 18:36, Petr Viktorin wrote: Naturally, large-scale changes have less of a chance there. Does it really matter that much how large the change is? I think you are focusing too much on the change instead of the end result. As I said in my previous post, I could certainly make

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 2018-05-15 18:36, Petr Viktorin wrote: What is your ultimate use case? (I'll just answer this one question now and reply to the more technical comments in another thread) My ultimate use case is being able to implement functions and methods which are (A) equally fast as the existing

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 05/15/18 05:15, Jeroen Demeyer wrote: On 2018-05-14 19:56, Petr Viktorin wrote: It does quite a lot of things, and the changes are all intertwined, which will make it hard to get reviewed and accepted. The problem is that many things *are* already intertwined currently. You cannot deal

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 2018-05-14 22:38, Petr Viktorin wrote: Why are these flags added? I made a minor edit to the PEP to remove those flags: https://github.com/python/peps/pull/649 ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 2018-05-14 19:56, Petr Viktorin wrote: It does quite a lot of things, and the changes are all intertwined, which will make it hard to get reviewed and accepted. The problem is that many things *are* already intertwined currently. You cannot deal with functions without involving methods for

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 2018-05-14 22:38, Petr Viktorin wrote: Why are these flags added? They aren't free – the space of available flags is not infinite. If something (Cython?) needs eight of them, it would be nice to mention the use case, at least as an example. What should Python do with a m_methods entry that

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 05/05/18 04:55, Jeroen Demeyer wrote: Hello all, I have updated PEP 575 in response to some posts on this mailing list and to some discussions in person with the core Cython developers. See https://www.python.org/dev/peps/pep-0575/ The main differences with respect to the previous version

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 05/05/18 04:55, Jeroen Demeyer wrote: Hello all, I have updated PEP 575 in response to some posts on this mailing list and to some discussions in person with the core Cython developers. See https://www.python.org/dev/peps/pep-0575/ The main differences with respect to the previous version

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update: limit?

On Tue, 8 May 2018, 16:33 Jeroen Demeyer, wrote: > On 2018-05-06 09:35, Nick Coghlan wrote: > > Thanks for this update Jeroen! If it doesn't come up otherwise, I'll try > > to claim one of the lightning talk slots at the Language Summit to > > discuss this with folks in

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 2018-05-06 09:35, Nick Coghlan wrote: Thanks for this update Jeroen! If it doesn't come up otherwise, I'll try to claim one of the lightning talk slots at the Language Summit to discuss this with folks in person :) Sounds great! I'd love to hear what people think. As an example of how the

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 5 May 2018 at 18:55, Jeroen Demeyer wrote: > Hello all, > > I have updated PEP 575 in response to some posts on this mailing list and > to some discussions in person with the core Cython developers. > See https://www.python.org/dev/peps/pep-0575/ > > The main differences