On Thu, Nov 24, 2016 at 3:07 AM, serge guelton <sguelton@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