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 ca
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 tiny
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
> >> > signif
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 w
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 ca
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: i
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 of
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.
>
> The
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
tha
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 tp_fastca
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 tha
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 w
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 somethi
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 extensio
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 a
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 prop
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 yo
> 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
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
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 calla
> 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 creating
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 protoc
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 decouplin
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 o
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
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 complexity of the *result*
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
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* compl
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 implem
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
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 less
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 bu
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 wit
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
https://mail.python.org/mailman/listin
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
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 ha
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
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
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 person :)
>
> Sounds great
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 n
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 with respect to the pr
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 are:
* "builtin_function" was renamed to
Hello all,
I have updated PEP 575 and its reference implementation. See
https://www.python.org/dev/peps/pep-0575/
The main differences with respect to the previous version are:
* METH_PASS_FUNCTION now passes the function *in addition* to self
(previously, it was passed *instead* of self).
*
43 matches
Mail list logo