On 23/09/2020 12:46 pm, Ivan Levkivskyi wrote:
On Wed, 23 Sep 2020 at 11:42, Mark Shannon <m...@hotpy.org
<mailto: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>
> <mailto: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>
<mailto: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.
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/
