[Python-ideas] Add specialized bytecode with guards to functions

[Brett Cannon]

On Wed, 21 Oct 2015 at 14:20 Victor Stinner <victor.stinner at gmail.com>
wrote:

> 2015-10-21 23:03 GMT+02:00 Antoine Pitrou <antoine at python.org>:
> > I think adding a version number to dicts would be a very cheap change
> > and would potentially help several CPython-based projects (including
> > perhaps Numba some day, though nowadays it wouldn't benefit).
>
> I tried to leave the dict type unchanged (it's not true in the PoC
> right now, but I'm working on fixing this). Currently, the versionned
> dictionary type (fat.verdict) is only used when Python starts in FAT
> mode and only in a few places: module, class and instance
> dictionaries. I'm not sure that it's worth to add the versionning
> feature to the base dict type. It uses a little bit more memory, and
> IMHO the dict type is already heavy in term of memory usage (compared
> to a compact C array).
>

I'm not sure if Antoine was truly proposing adding version number support
to all dicts, but I know I wasn't. I would propose creating a dict subclass
and use it in exactly the places you outlined, Victor: modules, classes,
and instance dictionaries (and I would honestly be fine with doing it
piecemeal in that order until we have experience as to how truly dynamic
people treat instances compared to modules and classes). I would start with
a global counter for every time __setitem__() is successful and see where
that gets us (both in terms of performance and optimizations).


>
> I'm trying to keep all FAT features optional to be able to easily
> compare performances, but also ensure that the FAT mode can be added
> to CPython without hurting performances (CPU and memory) when it's
> disabled.
>
> > However, I would also like to challenge the idea that an accelerator
> > has to be 100% compatible. If your API is opt-in (which Numba's is),
> > then you can happily relax some constraints (provided it is documented)
> > in exchange for much faster code. Our experience with Numba is that
> > nobody cares if you can't monkeypatch the len() builtin, for example.
>
> Sure, it will be possible to skip some guards if you know that
> builtins are never monkey-patched, that a module variable is constant,
> that a class will never be modified, etc. This will reduce even more
> the cost of guards (especially when all guards are skipped :-)).
>
> But I prefer to start with something that doesn't change the Python
> semantic at all, and then provide opt-in options to give more freedom
> to the optimizer.
>

I agree that not all optimizations/accelerators need to be 100% compatible.
Numba is in a certain kind of position, though, in that it is applied at
the function/method level while what Victor and I are working on applies to
all code. So it's just differing levels of granularity which influences how
much one feels like they can break the rules in the name of performance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20151022/ff8751e9/attachment.html>