harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Shipilev" <aleksey.shipi...@gmail.com>
Subject Re: [drlvm][jit][opt][performance] Inliner heuristics improvements: hotness and instance initializer bonuses
Date Sun, 12 Oct 2008 19:30:57 GMT
Hi, Buqi!

Let's revisit this patch. It was a half an year ago, so I can easily
miss something. So, the patch consists of two parts:

 1. hotness bonus fix. This is a bug in the inliner heuristic: the
bonus is purely multiplicative, which means if I have some very small,
but negative inline benefit for really hot method, then after applying
the hottness bonus, it will scale down to very big negative inline
benefit. That would effectively prevent this method from inlining,
which is obviously not the right thing.

 2. instance initializer fix. This one is the workaround of escape
analysis inefficiencies. Of course, the clean way to deal with issues
will surely be propagating escape analysis further. But I doubt that
such kind of patch is bearable for us to have in short time, any
Jitrino guru is avalable here?

And max inline constant is just changed to fit the inline tree with
all required methods. If your research shows that 800 is enough, then
you may use it, I have no objections against that. Could you please
try to extract hotness bonus fix, increase max inline constant to 800
and then run the SPECjvm2008 again?

Personally, I think that entire inliner logic must be revisited, as
the heuristic used was observed to have bad performance results for
this particular case, other benchmarks of SPECjvm2008 (at least serial
[1]), and some of Stefan Krause's benchmarks.

Thanks,
Aleksey.

[1] https://issues.apache.org/jira/browse/HARMONY-5719

On Sun, Oct 12, 2008 at 5:18 AM, bu qi cheng <buqi.cheng@gmail.com> wrote:
> Hi Aleksey:
>
>       For the performance data. We get following data. The version we used
> is the version I checked out in Augest, 4. We did not run startup.*.
> However, there is still many benchmarks failed to run(Not because of the
> patch). From these data we can find 800 is suitable for the
> MAX_INLINE_GROWTH_FACTOR_PROF. I am not sure what kind of data can be got in
> other benchmarks except SPECjvm2008. Can you give more information on why
> MAX_INLINE_GROWTH_FACTOR_PROF = 2000?
>
> CLEAN
> MAX_INLINE_GROWTH_FACTOR_PROF =800
> MAX_INLINE_GROWTH_FACTOR_PROF = 2000
>
>
> Clean 800 2000 800 2000
> crypto.aes 39.59 38.22 37.08 -3.46% -6.34%
> crypto.rsa 193.24 172.08 178.08 -10.95% -7.85%
> crypto.signverify 118.6 109.71 107.61 -7.50% -9.27%
> compiler.compiler 93.86 91.25 87.61 -2.78% -6.66%
> compiler.sunflow 139.63 123.64 136.65 -11.45% -2.13%
> scimark.fft.large 14.8 14.93 15.92 0.88% 7.57%
> scimark.sor.large 21.69 21.71 21.65 0.09% -0.18%
> scimark.sparse.large 12.86 12.88 12.85 0.16% -0.08%
> scimark.monte_carlo 298.17 977.29 1024.55 227.76% 243.61%
> derby 42.73 40.13 41.8 -6.08% -2.18%
> compress 117.23 111.12 110.12 -5.21% -6.07%
> xml.validation 81.17 82.15 80.75 1.21% -0.52%
> scimark.fft.small 931.98 931.98 903.96 0.00% -3.01%
> scimark.lu.small 842.59 831.09 841.83 -1.36% -0.09%
> scimark.sparse.small 70.95 65.5 70.7 -7.68% -0.35%
> serial 8.32 8 8.23 -3.85% -1.08%
>
> Another problem is that, as you mentioned that escape analysis directive
> inline is more suitable for the case. So I am wondering if it's suitable to
> commit the whole patch. Maybe, it's better that we only commit the
> adjustment of MAX_INLINE_GROWTH_FACTOR_PROF which will introduce about 30%
> performance improvement in monte_carlo. However, it will be a hard work if
> we re-desgin the optimizations of Harmony. One general consideration is
> trying to promote the basic analysises(such as the live range scope of
> objects-escape analysis, ..) in the front of the pipeline. What do you think
> of it?
>
> Thanks!
>
> Buqi
>

Mime
View raw message