[Python-Dev] Re: Understanding why object defines rich comparison methods

2020-09-23 Thread Serhiy Storchaka 
23.09.20 03:05, Greg Ewing пише:
> On 23/09/20 12:20 am, Steven D'Aprano wrote:
>> Presumably back when rich comparisons were added, the choice would have
>> been:
>>
>> - add one tp_richcompare slot to support all six methods; or
>>
>> - add six slots, one for each individual dunder
>>
>> in which case the first option wastes much less space.
> 
> I don't know the exact reasons, but it might also have been
> because the implementations of the six dunders are usually
> very closely related, so having just one function to implement
> at the C level is a lot easier for most types.
> 
> Also remember that before tp_richcompare existed there was
> only tp_compare, which also handled all the comparisons, so
> tp_richcompare was likely seen as a generalisation of that.

And before dunders __eq__, __lt__, etc there was a single dunder __cmp__.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WYF3DROV3X7TRVUSJAIIHCTFHPO5F7RB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Tagged pointer experiment: need help to optimize

2020-09-23 Thread Ivan Levkivskyi 
On Wed, 23 Sep 2020 at 01:19, Guido van Rossum  wrote:

> On Tue, Sep 22, 2020 at 4:58 PM Greg Ewing 
> wrote:
>
>> What are you trying to achieve by using tagged pointers?
>>
>> It seems to me that in a dynamic environment like Python, tagged
>> pointer tricks are only ever going to reduce memory usage, not
>> make anything faster, and in fact can only make things slower
>> if applied everywhere.
>>
>
> Hm... mypyc (an experimental Python-to-C compiler bundled with mypy) uses
> tagged pointers to encode integers up to 63 bits. I think it's done for
> speed, and it's probably faster in part because it avoids slow memory
> accesses. But (a) I don't think there's overflow checking, and (b) mypyc is
> very careful that tagged integers are never passed to the CPython runtime
> (since mypyc apps link with an unmodified CPython runtime for data types,
> compatibility with extensions and pure Python code). Nevertheless I think
> it puts your blanket claim in some perspective.
>

FWIW mypyc does overflow checking, see  e.g.
https://github.com/python/mypy/blob/master/mypyc/lib-rt/CPy.h#L168, also
tagged pointers did bring some speed wins, not big however. My expectation
is that speed wins may be even more modest without static information that
mypyc has.

// offtopic below, sorry

In general, I think any significant perf wins will require some static info
given to the Python compiler. I was thinking a long while ago about
defining some kind of a standard protocol so that static type checkers can
optionally provide some info to the Python compiler (e.g. pre-annotated
ASTs and pre-annotated symbol tables), and having a lot of specialized
bytecodes. For example, if we know x is a list and y is an int, we can emit
a special byte code for x[y] that will call PyList_GetItem, and will fall
back to PyObject_GetItem in rare cases when type-checker didn't infer right
(or there were some Any involved). Another example is having special byte
codes for direct pointer access to instance attributes, etc. The main
downside of such ideas is it will take a lot of work to implement.

--
Ivan
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/AUVHLLTEARU6HGMEFPPA5Q744O33WHOH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Tagged pointer experiment: need help to optimize

2020-09-23 Thread Mark Shannon 



On 23/09/2020 9:47 am, Ivan Levkivskyi wrote:



On Wed, 23 Sep 2020 at 01:19, Guido van Rossum > wrote:


On Tue, Sep 22, 2020 at 4:58 PM Greg Ewing
mailto:greg.ew...@canterbury.ac.nz>>
wrote:

What are you trying to achieve by using tagged pointers?

It seems to me that in a dynamic environment like Python, tagged
pointer tricks are only ever going to reduce memory usage, not
make anything faster, and in fact can only make things slower
if applied everywhere.


Hm... mypyc (an experimental Python-to-C compiler bundled with mypy)
uses tagged pointers to encode integers up to 63 bits. I think it's
done for speed, and it's probably faster in part because it avoids
slow memory accesses. But (a) I don't think there's overflow
checking, and (b) mypyc is very careful that tagged integers are
never passed to the CPython runtime (since mypyc apps link with an
unmodified CPython runtime for data types, compatibility with
extensions and pure Python code). Nevertheless I think it puts your
blanket claim in some perspective.


FWIW mypyc does overflow checking, see  e.g. 
https://github.com/python/mypy/blob/master/mypyc/lib-rt/CPy.h#L168, also 
tagged pointers did bring some speed wins, not big however. My 
expectation is that speed wins may be even more modest without static 
information that mypyc has.


// offtopic below, sorry

In general, I think any significant perf wins will require some static 
info given to the Python compiler. I was thinking a long while ago about 
defining some kind of a standard protocol so that static type checkers 
can optionally provide some info to the Python compiler (e.g. 
pre-annotated ASTs and pre-annotated symbol tables), and having a lot of 
specialized bytecodes. For example, if we know x is a list and y is an 
int, we can emit a special byte code for x[y] that will call 
PyList_GetItem, and will fall back to PyObject_GetItem in rare cases 
when type-checker didn't infer right (or there were some Any involved). 
Another example is having special byte codes for direct pointer access 
to instance attributes, etc. The main downside of such ideas is it will 
take a lot of work to implement.


Performance improvements do not need static annotations, otherwise PyPy, 
V8 and luajit wouldn't exist.

Even HotSpot was originally based on a VM for SmallTalk.

Cheers,
Mark.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3IVT65X5QRU4KKKST5SIAXVK6IV4MJXG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Tagged pointer experiment: need help to optimize

2020-09-23 Thread Victor Stinner 
Le mer. 23 sept. 2020 à 10:48, Ivan Levkivskyi  a écrit :
> // offtopic below, sorry
>
> In general, I think any significant perf wins will require some static info 
> given to the Python compiler. I was thinking a long while ago about defining 
> some kind of a standard protocol so that static type checkers can optionally 
> provide some info to the Python compiler (e.g. pre-annotated ASTs and 
> pre-annotated symbol tables), and having a lot of specialized bytecodes. For 
> example, if we know x is a list and y is an int, we can emit a special byte 
> code for x[y] that will call PyList_GetItem, and will fall back to 
> PyObject_GetItem in rare cases when type-checker didn't infer right (or there 
> were some Any involved). Another example is having special byte codes for 
> direct pointer access to instance attributes, etc. The main downside of such 
> ideas is it will take a lot of work to implement.

Specializing code was the root idea of my old FAT Python project:
https://faster-cpython.readthedocs.io/fat_python.html

I proposed https://www.python.org/dev/peps/pep-0510/ "Specialize
functions with guards". Guards are mostly on function arguments, but
can also be on namespaces, builtin functions, etc.

The https://github.com/vstinner/fatoptimizer project was an
implementation of optimizations based on this design. See the
documentation:

https://github.com/vstinner/fatoptimizer/blob/master/doc/optimizations.rst

I failed to implement optimizations which showed significant speedup
on real code, and guards were not free in terms of performance. I gave
up on this project.

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3FKHSIQGKQASSDNFT6WXTBWJDZSODKCR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Tagged pointer experiment: need help to optimize

2020-09-23 Thread Ivan Levkivskyi 
On Wed, 23 Sep 2020 at 11:42, Mark Shannon  wrote:

>
>
> On 23/09/2020 9:47 am, Ivan Levkivskyi wrote:
> >
> >
> > On Wed, 23 Sep 2020 at 01:19, Guido van Rossum  > > wrote:
> >
> > On Tue, Sep 22, 2020 at 4:58 PM Greg Ewing
> > mailto:greg.ew...@canterbury.ac.nz>>
> > wrote:
> >
> > What are you trying to achieve by using tagged pointers?
> >
> > It seems to me that in a dynamic environment like Python, tagged
> > pointer tricks are only ever going to reduce memory usage, not
> > make anything faster, and in fact can only make things slower
> > if applied everywhere.
> >
> >
> > Hm... mypyc (an experimental Python-to-C compiler bundled with mypy)
> > uses tagged pointers to encode integers up to 63 bits. I think it's
> > done for speed, and it's probably faster in part because it avoids
> > slow memory accesses. But (a) I don't think there's overflow
> > checking, and (b) mypyc is very careful that tagged integers are
> > never passed to the CPython runtime (since mypyc apps link with an
> > unmodified CPython runtime for data types, compatibility with
> > extensions and pure Python code). Nevertheless I think it puts your
> > blanket claim in some perspective.
> >
> >
> > FWIW mypyc does overflow checking, see  e.g.
> > https://github.com/python/mypy/blob/master/mypyc/lib-rt/CPy.h#L168,
> also
> > tagged pointers did bring some speed wins, not big however. My
> > expectation is that speed wins may be even more modest without static
> > information that mypyc has.
> >
> > // offtopic below, sorry
> >
> > In general, I think any significant perf wins will require some static
> > info given to the Python compiler. I was thinking a long while ago about
> > defining some kind of a standard protocol so that static type checkers
> > can optionally provide some info to the Python compiler (e.g.
> > pre-annotated ASTs and pre-annotated symbol tables), and having a lot of
> > specialized bytecodes. For example, if we know x is a list and y is an
> > int, we can emit a special byte code for x[y] that will call
> > PyList_GetItem, and will fall back to PyObject_GetItem in rare cases
> > when type-checker didn't infer right (or there were some Any involved).
> > Another example is having special byte codes for direct pointer access
> > to instance attributes, etc. The main downside of such ideas is it will
> > take a lot of work to implement.
>
> Performance improvements do not need static annotations, otherwise PyPy,
> V8 and luajit wouldn't exist.
> Even HotSpot was originally based on a VM for SmallTalk.
>

Sure, but JIT optimizations assume there are some "hot spots" in the code
where e.g. a function is called in a loop, so that type information can be
gathered and re-used.
The problem is that in my experience there are many applications where this
is not the case: there are no major hot spots. For such applications JITs
will not be efficient,
while static annotations will work.

Another thing is that making CPython itself JITted may be even harder than
adding some (opt-in) static based optimizations, but
I am clearly biased here.

Actually what would be really cool is having both: i.e. have a JIT that
would use static annotations to speed-up the warmup significantly.
I don't know if anyone tried something like this, but it doesn't sound
impossible.

--
Ivan
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JKF6LKGZL6S46B43HH3SADXKK26XGSKU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Tagged pointer experiment: need help to optimize

2020-09-23 Thread Victor Stinner 
Le mer. 23 sept. 2020 à 13:49, Ivan Levkivskyi  a écrit :
> Sure, but JIT optimizations assume there are some "hot spots" in the code 
> where e.g. a function is called in a loop, so that type information can be 
> gathered and re-used.
> The problem is that in my experience there are many applications where this 
> is not the case: there are no major hot spots. For such applications JITs 
> will not be efficient,
> while static annotations will work.
>
> Another thing is that making CPython itself JITted may be even harder than 
> adding some (opt-in) static based optimizations, but
> I am clearly biased here.

CPython has a JIT compiler since Python 3.8 :-)

When a code object is executed more than 1024 times, a cache is
created for LOAD_GLOBAL instructions.

The What's New in Python 3.8 entry says that LOAD_GLOBAL "is about 40%
faster now":
https://docs.python.org/dev/whatsnew/3.8.html#optimizations

Victor
-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/EMBQQYCWRU53LAB25NBX6BUXRV3XU6ZT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

2020-09-23 Thread Jens Gåsemyr Magnus via Python-Dev 
It would be fantastic if these were expressions rather than statements. Imagine 
being able to write things like:

```python
@memoized
def fibonacci(n):
match n:
case 0:
(return/yield?) 0
case 1:
1
case _:
fibonacci(n - 2) + fibonacci(n - 1)
```

Obviously this could be written easily with an if statement, and might not be 
the best example. But I’ve often encountered situations where I wish I had 
semantics like this.


Jens


---
The information contained in this message may be CONFIDENTIAL and is
intended for the addressee only. Any unauthorized use, dissemination of the
information or copying of this message is prohibited. If you are not the
addressee, please notify the sender immediately by return e-mail and delete
this message.
Thank you
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PLPOHR623XNAT4ZEQGSRFDKUBTK3PWVK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Tagged pointer experiment: need help to optimize

2020-09-23 Thread Mark Shannon 



On 23/09/2020 12:46 pm, Ivan Levkivskyi wrote:
On Wed, 23 Sep 2020 at 11:42, Mark Shannon > wrote:




On 23/09/2020 9:47 am, Ivan Levkivskyi wrote:
 >
 >
 > On Wed, 23 Sep 2020 at 01:19, Guido van Rossum mailto:gu...@python.org>
 > >> wrote:
 >
 >     On Tue, Sep 22, 2020 at 4:58 PM Greg Ewing
 >     mailto:greg.ew...@canterbury.ac.nz>
>>
 >     wrote:
 >
 >         What are you trying to achieve by using tagged pointers?
 >
 >         It seems to me that in a dynamic environment like Python,
tagged
 >         pointer tricks are only ever going to reduce memory
usage, not
 >         make anything faster, and in fact can only make things slower
 >         if applied everywhere.
 >
 >
 >     Hm... mypyc (an experimental Python-to-C compiler bundled
with mypy)
 >     uses tagged pointers to encode integers up to 63 bits. I
think it's
 >     done for speed, and it's probably faster in part because it
avoids
 >     slow memory accesses. But (a) I don't think there's overflow
 >     checking, and (b) mypyc is very careful that tagged integers are
 >     never passed to the CPython runtime (since mypyc apps link
with an
 >     unmodified CPython runtime for data types, compatibility with
 >     extensions and pure Python code). Nevertheless I think it
puts your
 >     blanket claim in some perspective.
 >
 >
 > FWIW mypyc does overflow checking, see  e.g.
 >
https://github.com/python/mypy/blob/master/mypyc/lib-rt/CPy.h#L168,
also
 > tagged pointers did bring some speed wins, not big however. My
 > expectation is that speed wins may be even more modest without
static
 > information that mypyc has.
 >
 > // offtopic below, sorry
 >
 > In general, I think any significant perf wins will require some
static
 > info given to the Python compiler. I was thinking a long while
ago about
 > defining some kind of a standard protocol so that static type
checkers
 > can optionally provide some info to the Python compiler (e.g.
 > pre-annotated ASTs and pre-annotated symbol tables), and having a
lot of
 > specialized bytecodes. For example, if we know x is a list and y
is an
 > int, we can emit a special byte code for x[y] that will call
 > PyList_GetItem, and will fall back to PyObject_GetItem in rare cases
 > when type-checker didn't infer right (or there were some Any
involved).
 > Another example is having special byte codes for direct pointer
access
 > to instance attributes, etc. The main downside of such ideas is
it will
 > take a lot of work to implement.

Performance improvements do not need static annotations, otherwise
PyPy,
V8 and luajit wouldn't exist.
Even HotSpot was originally based on a VM for SmallTalk.


Sure, but JIT optimizations assume there are some "hot spots" in the 
code where e.g. a function is called in a loop, so that type information 
can be gathered and re-used.
The problem is that in my experience there are many applications where 
this is not the case: there are no major hot spots. For such 
applications JITs will not be efficient,

while static annotations will work.


If an application has no hot code, then it will just terminate quickly 
and not need optimizing.

Even a slow interpreter like CPython can execute millions of LOC per second.



Another thing is that making CPython itself JITted may be even harder 
than adding some (opt-in) static based optimizations, but

I am clearly biased here.

Actually what would be really cool is having both: i.e. have a JIT that 
would use static annotations to speed-up the warmup significantly.
I don't know if anyone tried something like this, but it doesn't sound 
impossible.


Not impossible, just not worthwhile.

Cheers,
Mark.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VBDHTTKK4I26XG6VIR2TWCOD6AA4EDUD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: unable to create PR on github

2020-09-23 Thread Mats Wichmann 
On 9/22/20 1:20 AM, Antoine Pitrou wrote:
> On Mon, 21 Sep 2020 20:56:18 -0700
> Ethan Furman  wrote:
>> And even more data:
>>
>> I added a body to the PR I was originally having trouble with:
>>button stayed gray
>>
>> I went away for a while, say 5 - 10 minutes, and when I went back to 
>> that screen the button was green.  I created the PR.
> 
> Recently, I had to add a body text to create a PR (on another repo),
> otherwise the button would be grayed out.  So that seems to be the
> reason.

I've had the same with the title... github has some heuristic about when
a PR is ready to proceed with, which includes certain fields plus maybe
requirements a project may have imposed, and in what's probably a
gigabyte of hairy javascript, it appears to be confusable.

The commandline client (gh pr create ) might avoid some of that mess?

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/SV3DPIZCXPRLTA67PRIIPWU7KHFGKQZT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Tagged pointer experiment: need help to optimize

2020-09-23 Thread Antoine Pitrou 
On Tue, 22 Sep 2020 17:11:40 -0700
Guido van Rossum  wrote:

> On Tue, Sep 22, 2020 at 4:58 PM Greg Ewing 
> wrote:
> 
> > What are you trying to achieve by using tagged pointers?
> >
> > It seems to me that in a dynamic environment like Python, tagged
> > pointer tricks are only ever going to reduce memory usage, not
> > make anything faster, and in fact can only make things slower
> > if applied everywhere.
> >  
> 
> Hm... mypyc (an experimental Python-to-C compiler bundled with mypy) uses
> tagged pointers to encode integers up to 63 bits. I think it's done for
> speed, and it's probably faster in part because it avoids slow memory
> accesses.

Certainly.  But I suspect the statically-typed aspect of mypyc helps it
avoid systematic condition checks when accessing those tagged pointers.
Which is not the case in a dynamically-typed setting such as Victor's
PR.

(however, tagged pointers + a runtime specializer could perhaps show
more benefits than the current PR)

Regards

Antoine.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/E365MSXHKQD6AE3L7WZ72BLR3LESXK7C/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Tagged pointer experiment: need help to optimize

2020-09-23 Thread Antoine Pitrou 
On Wed, 23 Sep 2020 12:46:25 +0100
Ivan Levkivskyi  wrote:
> 
> Another thing is that making CPython itself JITted may be even harder than
> adding some (opt-in) static based optimizations, but
> I am clearly biased here.
> 
> Actually what would be really cool is having both: i.e. have a JIT that
> would use static annotations to speed-up the warmup significantly.

Numba allows you to specify the signature of a function (i.e. the
concrete argument types it accepts).  That said, the goal is not to
speed up any warmup phase, but to override type inference when it
doesn't produce the desired results.

Regards

Antoine.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/TKKUNEBFVRDOIZSKNZFZIO6M22SZVGRS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Understanding why object defines rich comparison methods

2020-09-23 Thread Jeff Allen 

On 22/09/2020 12:13, Serhiy Storchaka wrote:

Because object.__eq__ and object.__ne__ exist.


I didn't quite get the logic of this. In case anyone (not Steven) is 
still puzzled as I was, I think one could say: ... because 
tp_richcompare is filled, *so that* object.__eq__ and object.__ne__ will 
exist to support default (identity) object comparison.


And then __lt__, etc. get defined because, as Serhiy says,  ...


If you define slot
tp_richcompare in C, it is exposed as 6 methods __eq__, __ne__, __lt__,
__le__, __gt__ and __ge__.


By "exposed" we mean each descriptor (PyWrapperDescrObject) points to a 
different C function (generated by the RICHCMP_WRAPPER macro). The 
function summons the tp_richcompare slot function in the left object's 
type, with arguments (left, right, op).


Simple (not).

Jeff Allen

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XANM3QX3I6VHOEGVPMGIU4MMJHKJGYKA/
Code of Conduct: http://python.org/psf/codeofconduct/