Hello.
And there is rakudo's build time excerts for "core.pm" test. All
builds were configured with "--makefile-timing --gen-parrot".
Rakudo 2011.01, Parrot 3.0 GC MS2:
time /home/bacek/src/rakudo-2011-01/parrot_install/bin/parrot
src/gen/perl6.pbc --target=pir --stagestats \
src/gen/core.pm > src/gen/core.pir
Stage 'parse': 161.006 sec
Stage 'past': 0.000 sec
Stage 'check_syntax': 0.000 sec
Stage 'post': 110.843 sec
Stage 'pir': 57.849 sec
321.17user 1.78system 5:29.99elapsed 97%CPU (0avgtext+0avgdata
1489120maxresident)k
0inputs+9728outputs (0major+113044minor)pagefaults 0swaps
Rakudo 2011.04, Parrot 3.3 GC GMS:
time /home/bacek/src/rakudo-2011-04/parrot_install/bin/parrot
src/gen/perl6.pbc --target=pir --stagestats \
src/gen/core.pm > src/gen/core.pir
Stage 'parse': 86.740 sec
Stage 'past': 0.000 sec
Stage 'check_syntax': 0.000 sec
Stage 'post': 49.433 sec
Stage 'pir': 31.842 sec
164.79user 0.97system 2:48.32elapsed 98%CPU (0avgtext+0avgdata
1460768maxresident)k
0inputs+10272outputs (0major+112445minor)pagefaults 0swaps
I'm running a spectest now, but initial checks are showing that at
least Rakudo's build time should be about 50% faster.
("make spectest" will definetely be comparision of apples to oranges.
There are plenty of failures on 2011.01 atm)
--
Bacek
On Tue, May 3, 2011 at 9:13 PM, Vasily Chekalkin <[email protected]> wrote:
> Hello.
>
> It's quite comprehensive investigation. But I have few comments/notes.
>
> 1. MS2 was landed way before 3.0. I don't remember exact dates but it
> doesn't really matter.
> 2. Yes, GMS consumes less memory than MS/MS2. Just because of nature of GenGC.
> 3. I'm still don't quite understand why Rakudo on 3.3 isn't faster
> than on 3.0. During dev/test phase I was using _current_ parrot with 2
> major test cases: a) ops2c --core; b) compile rakudo's core.pm. I just
> did quick check on my box.
>
> Parrot 3.0, GS MS2, fixed thresold of 1/8 of memory:
> $ /usr/bin/time ./ops2c --core
> ...
> # Ops parsed in 39.159 seconds.
> 44.68user 0.09system 0:45.06elapsed 99%CPU (0avgtext+0avgdata
> 166544maxresident)k
> 8inputs+1928outputs (0major+14734minor)pagefaults 0swaps
>
> Parrot 3.1, GC MS2, dynamic thresold:
> # Ops parsed in 40.399 seconds.
> 45.83user 0.26system 0:46.41elapsed 99%CPU (0avgtext+0avgdata
> 161872maxresident)k
> 8inputs+1920outputs (0major+14826minor)pagefaults 0swaps
>
> Parrot 3.3, GC GMS:
> $ /usr/bin/time ./ops2c --core
> ...
> # Ops parsed in 28.627 seconds.
> 31.52user 0.17system 0:32.37elapsed 97%CPU (0avgtext+0avgdata
> 304432maxresident)k
> 8inputs+1672outputs (0major+21459minor)pagefaults 0swaps
>
> Yes, adaptive triggering on MS2 is slightly slower. But GMS should be
> significantly faster.
>
> There is few major suspects:
> 1. My box has on 2 gigs of memory. May be GMS behave itself badly on
> bigger/smaller space.
> 2. There is some workload on rakudo's spectest which is not covered by
> building ops/core.pm. But it's kind of unlikely. Because when moritz++
> switched rakudo to GMS he reported 30% performance boost.
> 3. There is some "regression" in parrot which cause slowdown of
> rakudo's spectest.
> 4. There is some "regression" in rakudo which increased GC pressure.
>
> I will investigate more what can be root cause of such slowdown.
>
> --
> Bacek.
>
> On Sun, May 1, 2011 at 1:44 AM, Luben Karavelov <[email protected]> wrote:
>> Hello,
>>
>> Patric Michaud made some observations regarding parrot GC changes. The basic
>> findings are that parrot 3.0 with MS2 GC has the same execution time of
>> rakudo spectest as current parrot with GMS GC, current MS2 throughput is
>> worse compared to parrot 3.0. He was wondering if GMS is then better GC
>> than MS2.
>>
>> I think I know what causes the performance differences. Improved tri-colour
>> MS2 GC has landed in parrot 3.0. It did not have adaptive triggering that
>> the old MS GC had - it kicked out every 1/8 of system memory allocated (if
>> my memory serves me correctly). It wasted a lot of memory and had long
>> pauses. For example, on my system compiling rakudo used 700+ M.
>>
>> In parrot 3.1 Nick Wellnhofer have ported GC adaptive triggering system from
>> MS to MS2 GC core. It compiled rakudo in 400-500M but somewhat slower
>> because it kicked more frequently. It also had improved on interactive loads
>> - there were no long pauses.
>>
>> GMS also landed at the same time in master - it does not have adaptive
>> triggering - it kicks minor collection on every 1/100 of system memory
>> allocated. Older generation GC is started on 10 younger generation
>> collection. It has 8 generations. So it wastes a lot less memory - it could
>> compile rakudo in 256M of RAM and have further improved interactive
>> behavior. Parrot with GMS compiles Rakudo in the same time as MS2 without
>> adaptive triggering but in 1/2-1/3 of the memory.
>>
>> So, though execution times of GMS and MS2 (without adaptive triggering) are
>> similar, their other characteristics are quite different - GMS wastes a lot
>> less memory, has better interactive behavior etc.
>>
>> I have also ported adaptive triggering system to GMS but the performance was
>> the same as current GMS. It wasted a lot more memory (comparable to MS2 with
>> adaptive triggering). The current triggering system relies on the size of
>> the youngest generation, adaptive triggering system of MS2 depends on the
>> size of all allocated memory and complicates the things. Current GMS has
>> more uniform pauses than GMS with adaptive triggering. These are the causes
>> I have dropped this first experiment for adaptive triggering of GMS GC.
>>
>> GMS has some tunable parameters but every tuning is compromise. So it will
>> be best to pick some sane defaults (we are not far from them on my account)
>> and provide mechanism to change them with parrot options. My preliminary
>> experiments show that 3-4 generations in GMS are enough and there also a lot
>> other variables to tune - I have not done the extensive test in order to
>> change the current defaults.
>>
>> --
>> Luben Karavelov
>> _______________________________________________
>> http://lists.parrot.org/mailman/listinfo/parrot-dev
>>
>
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev