Hi Eliot,
Thanks for looking at this.
Please let us know what support you need, or what kind of experiments we can do on our side.
Cheers, Doru
On Jan 24, 2016, at 9:20 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
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 vincent.blondeau@polytech-lille.net wrote:
Hi,
I made the benchmarks with the files you provided. I have more or less the 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 duration (120 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@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 like to understand where the slowness comes. Maybe it comes from Spur itself, but maybe it comes from somewhere else.
Cheers, Doru
On Jan 24, 2016, at 1:41 AM, Mariano Martinez Peck marianopeck@gmail.com
wrote:
Doru...just to be sure it is not a Pharo (image change), when you said
before and after Spur, do you mean a Pharo 5.0 exactly (just before Spur) 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 tudor@tudorgirba.com wrote: 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 loads
twice as slow with Spur than before:
- PreSpur: 0:00:01:07.272
- Spur: 0:00:02:10.508
Here is the reference file: https://dl.dropboxusercontent.com/u/18323746/Tmp/ArgoUML-0-34.mse.zip
And here is the script: [ MooseModel new importFromMSEStream: (StandardFileStream
readOnlyFileNamed:
(FileSystem workingDirectory / 'src' /'ArgoUML-0-34' / 'ArgoUML-0-34.mse') fullName).
] timeToRunDo you get the same?
Cheers, Doru
-- www.tudorgirba.com www.feenk.com
"Problem solving should be focused on describing the problem in a way that makes the solution obvious."
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- Mariano http://marianopeck.wordpress.com _______________________________________________ Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-- www.tudorgirba.com www.feenk.com
"What is more important: To be happy, or to make happy?"
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev <report504.txt> <report1175.txt>