On Wed, 23 Sep 2020 at 11:42, Mark Shannon <m...@hotpy.org> wrote: > > > On 23/09/2020 9:47 am, Ivan Levkivskyi wrote: > > > > > > On Wed, 23 Sep 2020 at 01:19, Guido van Rossum <gu...@python.org > > <mailto:gu...@python.org>> wrote: > > > > On Tue, Sep 22, 2020 at 4:58 PM Greg Ewing > > <greg.ew...@canterbury.ac.nz <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/
