harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cheng, BuQi (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-5584) [drlvm][jit][opt][performance] Inliner heuristics improvements: hotness and instance initializer bonuses
Date Sat, 11 Oct 2008 15:07:44 GMT

    [ https://issues.apache.org/jira/browse/HARMONY-5584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12638760#action_12638760
] 

Cheng, BuQi commented on HARMONY-5584:
--------------------------------------

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

> [drlvm][jit][opt][performance] Inliner heuristics improvements: hotness and instance
initializer bonuses
> --------------------------------------------------------------------------------------------------------
>
>                 Key: HARMONY-5584
>                 URL: https://issues.apache.org/jira/browse/HARMONY-5584
>             Project: Harmony
>          Issue Type: Improvement
>          Components: DRLVM
>         Environment: all
>            Reporter: Aleksey Shipilev
>            Assignee: Mikhail Fursov
>         Attachments: H5584-inliner-heuristics.patch, H5584-inliner-heuristics.patch
>
>
> During the profiling of Scimark2 [1] it was found that inliner misses the inline opportunities
for monte_carlo. 
> This is the code for hottest method:
> 	public static final double integrate(int Num_samples)
> 	{
> 		Random R = new Random(SEED);
> 		int under_curve = 0;
> 		for (int count=0; count<Num_samples; count++)
> 		{
> 			double x= R.nextDouble();
> 			double y= R.nextDouble();
> 			if ( x*x + y*y <= 1.0)
> 				 under_curve ++;
> 			
> 		}
> 		return ((double) under_curve / Num_samples) * 4.0;
> 	}
> Problems are:
>  1. nextDouble is not inlined
>  2. nextDouble is internally synchronized 
> Attached patch solves these two problems:
>  1. fixing hotness bonus calculation. This is the issue Random.nextDouble() hit on: this
method called in hot cycle and missing inline opportunity due to glitch in scaling function,
which should be more additive rather than multiplicative.
>  2. introducing instance initializer bonus. This helps to inline constructor with all
corresponding methods to help scalar replacement with scalarizing of R (and eliminating synchronization
too).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message