[llvm-commits] [llvm jit adaptive-compilation] : Adaptive compilation framework x86 Patch

Xin Tong Utoronto x.tong at utoronto.ca
Wed Jul 6 09:31:32 PDT 2011


Before the adaptive compilation framework is added

lli –O0 Total Time is 1064.27 seconds

lli –O1  Total Time is 1401.42 seconds

lli –O2 Total Time is 1389.2 seconds

lli –O3 Total Time is 1391.49 seconds



After the adaptive compilation framework is added

lli -O0 Total Time is 1068.37s

lli -O1 Total Time is 1395.68s

lli -O2Total Time is 1394.81s

lli -O3 Total Time is 1395.76s

lli -adaptive-comp Total Time is 1119.23s


As you can see that the performance number before the adaptive compilation
framework is added is very close to the performance number after the
adaptive compilation framework is added. This makes senses, as when the
adaptive compilation framework is not enabled, the code executed for lli -O0
– O3 is almost the same as before.

I also compared the top 5 test cases for lli O1 – O3 && lli –adaptive-comp
after the adaptive compilation framework is added.

There are 417 test cases in the llvm-test suite. Here are the results for
top 5. Luckily the top 5 are the same for all the runs.





lli O0

lli O1

lli O2

lli O3

lli adaptive

MultiSource/Benchmarks/PAQ8p/paq8p

150.47

95.84

95.56

95.71

108.55

MultiSource/Applications/lemon/lemon

85.47

522.86

522.95

521.93

91.2

MultiSource/Benchmarks/mafft/pairlocalalign

52.97

30.03

29.92

30.33

50.65

SingleSource/Benchmarks/CoyoteBench/huffbench

50.62

40.55

40.76

40.78

46.63

MultiSource/Benchmarks/SciMark2-C/scimark2

29.04

29.15

28.94

29.02

29.33

% of Time Accounted For

%Time = 34.5%

%Time = 51.47 %

%Time = 51.48%

%Time = 51.42%

%Time = 29.16%



Progressions and regressions: Adaptive compilation performs better than O0
on paq8p, which implies there are easily identified hotspots in the program.
However, it is slower than O0 in all other 4 test cases. There might be
caused by the overhead of recompilation.  Adaptive compilation performs a
lot better than O1 , O2 and O3 in lemon, by looking into the lemon test
case, I found that Lemon forks a lots of processes 20 *  8 and each process
is doing a little bit of work. Because all of these processes inherit
command line options from their parents, they are all optimizing at the same
level.  The optimization starting at O1 takes significantly more time than
O0 in this case (about x3).  Therefore, most of the time is spent in
compiling rather than doing useful work.

>From the results above, it is easy to see that adaptive compilation does
offer some benefits in some programs, especially ones with easily
identifiable hotspots. It, however, suffers from recompilation overhead.
Currently, the recompilation in JIT happens synchronously, i.e. the
application waits for the compilation to finish. Next step is to implement
asynchronous compilation for adaptive compilation, i.e. Compilation Threads.






-- 
Kind Regards

Xin Tong



On Mon, Jul 4, 2011 at 2:44 PM, Xin Tong Utoronto <x.tong at utoronto.ca>wrote:

>
>
> Thanks
>
> Xin
>
>
> On Mon, Jul 4, 2011 at 2:16 PM, Eric Christopher <echristo at apple.com>wrote:
>
>>
>> On Jul 4, 2011, at 8:58 AM, Xin Tong Utoronto wrote:
>>
>> > The original numbers are the same as what are given here. As the lli -O0
>> - O3 is virtually the same as before if adaptive compilation is not enabled.
>>
>> "The same" isn't a number?
>>
>> So, that's giving total time to run the testsuite on x86 in seconds I
>> gather. How about individual tests? Any significant regressions?
>> Progressions? What were the top 10 of each?
>>
>
> Honestly I do not have the original numbers, I will launch a run now and
> post later today or tomorrow. Right, the total time is in seconds. I will
> report on progressions and regressions as well in the next post.
>
> -Xin
>
>>
>> -eric
>>
>
>
>
> --
> Kind Regards
>
> Xin Tong
>



-- 
Kind Regards

Xin Tong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20110706/0a7ce505/attachment.html>


More information about the llvm-commits mailing list