[Moose-dev] Re: [Pharo-dev] Spur Garbage collection takes 4 times more when loading MSE (WAS: mse loading looks slower :()

On Jan 24, 2016, at 9:33 PM, Eliot Miranda <eliot.miranda(a)gmail.com>

Hi Doru, On Sun, Jan 24, 2016 at 12:26 PM, Tudor Girba <tudor(a)tudorgirba.com>

Hi Eliot, Thanks for looking at this. Please let us know what support you need, or what kind of experiments we

What I want most of all is a test case that I can run on Mac. I'm

Cheers, Doru > On Jan 24, 2016, at 9:20 PM, Eliot Miranda <eliot.miranda(a)gmail.com>

> > Hi Vincent, > > I'll take a look early this week. There's clearly a bug; the Spur > GC is /not/ collecting those dictionaries :-( (thanks Stephan!). > Assuming the bug is fixed times should come down (see below). It may > be that the bug in Slang that I introduced in December has broken > things because I don't see these symptoms in my daily work (but I use > the most up-to-date VM version possible ;-) ). But I'm not in denial > and look forward to using MOOSE as a good stress case. > > I do want to say that the GC is not complete. Right now we have a > scavenger that works well, and a global GC that has a slow compaction > algorithm, and hence there are significant pauses. For example here's > what I see as typical in using SPur for VMMaker work: > > memory 160,432,128 bytes > old 153,658,624 bytes (95.8%) > young 4,838,224 bytes (3%) > used 127,009,928 bytes (79.2%) > free 28,126,456 bytes (17.5%) > GCs 7,265 (?? ms between GCs) > full 36 totalling 13,229 ms (0% uptime), avg 367.5 ms > incr 7,229 totalling 6,546 ms (0% uptime), avg 0.9 ms > tenures 3,589,063 (avg 0 GCs/tenure) > > (There's no uptime in the above stats because we're still > transitioning Squeak to the 64-bit clock and there are consequently > bugs in computing uptime). > > The plan is to add an incremental global GC so this work is broken up > into much smaller pieces. I don't want to see 700ms pauses in global > GC; one can't do game animation with that. So an incremental > mark-sweep is needed. There are two nice papers we're considering, > one from Lua and one for a truly concurrent collector. But time is > pressing, so if anyone out there knows GC and is interested in helping > this is a nicely self-contained project for which we'd love to have > volunteers. > > _,,,^..^,,,_ (phone) > >> On Jan 24, 2016, at 3:43 AM, Vincent BLONDEAU <

>> >> Hi, >> >> I made the benchmarks with the files you provided. I have more or

>> same magnitude: >> Version 504: 0:00:01:09.021 >> Version 1175: 0:00:02:37.507 >> >> However, by launching it in the time profiler (MooseModel new >> importFromMSEStream: (StandardFileStream readOnlyFileNamed: >> 'd:/ArgoUML-0-34.mse')), it takes >> 504: 1 min 55 >> 1175: 4 min 25 >> Well there is a delta... >> >> After investigation, the standard process has almost the same

>> secs for prespur and 140 secs for spur). >> But, there is a large difference in GC time: >> >> 504: not spur >> **Memory** >> old +144,822,000 bytes >> young -8,293,660 bytes >> used +136,528,340 bytes >> free -104,186,788 bytes >> >> **GCs** >> full 1 totalling 965ms (1.0% uptime), avg 965.0ms >> incr 3264 totalling 42,279ms (33.0% uptime), avg 13.0ms >> tenures 2,497 (avg 1 GCs/tenure) >> root table 0 overflows >> >> 1175: spur >> **Memory** >> old +0 bytes >> young +340,048 bytes >> used +340,048 bytes >> free -340,048 bytes >> **GCs** >> full 7 totalling 145,003ms (66.0% uptime), avg >> 20715.0ms >> incr 3288 totalling 30,912ms (14.0% uptime), avg 9.0ms >> tenures 7,146,505 (avg 0 GCs/tenure) >> root table 0 overflows >> >> Total GC time >> 504: 43 secs >> 1175: 176 secs >> >> See the performance reports attached. >> >> I let VM people take care of the issue ;) >> >> Cheers, >> Vincent >> >> -----Original Message----- >> From: moose-dev-bounces(a)list.inf.unibe.ch >> [mailto:moose-dev-bounces@list.inf.unibe.ch] On Behalf Of Tudor Girba >> Sent: dimanche 24 janvier 2016 09:08 >> To: Moose-related development >> Subject: [Moose-dev] Re: mse loading looks slower :( >> >> Hi, >> >> I am talking about the difference between Moose 6 images: >> - October 7: >> https://ci.inria.fr/moose/job/moose-6.0/504/artifact/moose-6.0.zip >> >> - yesterday: >> https://ci.inria.fr/moose/job/moose-6.0/1175/artifact/moose-6.0.zip >> >> Multiple things did change, but not in Moose. In the end, I would

>> understand where the slowness comes. Maybe it comes from Spur itself,

>> maybe it comes from somewhere else. >> >> Cheers, >> Doru >> >> >> >>>> On Jan 24, 2016, at 1:41 AM, Mariano Martinez Peck <

>>> wrote: >>> >>> Doru...just to be sure it is not a Pharo (image change), when you

>> before and after Spur, do you mean a Pharo 5.0 exactly (just before

>> and a Pharo JUST after it? Otherwise, the slowness may come from the >> difference between the 2 Pharos you are running. >>> >>> Cheers, >>> >>> On Sat, Jan 23, 2016 at 5:55 PM, Tudor Girba &lt;tudor(a)tudorgirba.com&gt;

>>> Hi, >>> >>> I am doing some performance testing of Moose with the Spur VM on Mac. >>> >>> I tried to load an MSE file with ArgoUML 0.34 and on my machine it

>> twice as slow with Spur than before: >>> - PreSpur: 0:00:01:07.272 >>> - Spur: 0:00:02:10.508 >>> >>> Here is the reference file: >>>

-- _,,,^..^,,,_ best, Eliot _______________________________________________ Moose-dev mailing list Moose-dev(a)list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev