On Wed, 23 Sep 2020 at 01:19, Guido van Rossum <gu...@python.org> wrote:
> On Tue, Sep 22, 2020 at 4:58 PM Greg Ewing <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. -- 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/
