[Speed] Analysis of a Python performance issue
Kevin Modzelewski
kmod at dropbox.com
Sat Nov 26 17:16:54 EST 2016
On Thu, Nov 24, 2016 at 3:07 AM, serge guelton <sguelton at quarkslab.com>
wrote:
> On Mon, Nov 21, 2016 at 03:26:19PM -0800, Kevin Modzelewski wrote:
> > Oh sorry I was unclear, yes this is for the pyston binary itself, and yes
> > PGO does a better job and I definitely think it should be used.
>
> That raised a second question: do you collect branch / hotness info
> during lower tier jitted code run, so as to improve performance of
> higher tiers ?
>
We don't (yet) do code placement optimizations. We should be getting some
basic amount of this, though, by our generated code being grouped by "tier
that compiled it" which is highly correlated with hotness.
>
> > Separately, we often use non-pgo builds for quick checks, so we also have
> > the system I described that makes our non-pgo build more reliable by
> using
> > the function ordering from the pgo build.
>
> ok. Are you just « putting hot stuff in the hot section » or did you try
> to specify an ordering to further improve locality? (I don't know if it's
> possible, it's mentionned in one of the paper)
>
We pull the function order from the PGO build and ask the non-pgo build to
use the same order, so it's up to whatever the C compiler did. Though to
keep things tractable we only do this for functions that have some
non-negligible hotness.
I think this does help with overall performance of the non-pgo build, but
our main goal was performance consistency.
>
> Thanks,
>
> Serge
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/speed/attachments/20161126/e4534d3e/attachment.html>
More information about the Speed
mailing list