On Tue, Dec 01, 2009 at 10:22:43AM -0800, chromatic wrote:
> On Tuesday 01 December 2009 at 10:06, Patrick R wrote:
> > While I agree it will be useful to make the compilation process
> > more efficient, my underlying point is that with the current GC
> > any modest-sized data structure that exists at runtime appears
> > to incur an unacceptable runtime cost (and this would include
> > data structures created in applications as well).
>
> I don't believe it's the cost of those data structures created for NQP. I
> believe instead it's the cost of the data structures created for PCC.
>
> Those are short-lived, mostly-garbage headers that we currently can't reclaim
> without a full stop the world mark and sweep run.
My testing -- which may be based on a flawed understanding on my part --
doesn't seem to support this conclusion. For this analysis I tend
to group the gc-ables into two groups: those created during compilation
of fib.nqp, and those created during the runtime of fib.nqp .
The first GC run that occurs during the runtime of fib.nqp ought
to catch all of the short-lived PCC structures that are in the first
group... leaving only long-lived PMCs. Any PCC structures that get
created after runtime begins should be the same for both the .nqp
and generated-.pir versions of the program, thus any observed
differences in execution time would seem to have to be due to
long-lived gc-ables remaining from the compilation process.
I wrote a short test to check this hypothesis -- at the beginning
of fib.nqp execution I force a GC run (to clear up any "mostly-garbage
headers" left over from compilation), and then time the resulting
execution:
$ cat fib-4.nqp
pir::say(pir::time__N);
Q:PIR {
sweep 1
$P0 = getinterp
$P0.'run_gc'()
};
pir::say(pir::time__N);
sub fib($n) {
($n < 2) ?? $n !! fib($n-1) + fib($n-2);
}
my $N := 28;
pir::say("fib($N) = " ~ fib($N));
pir::say(pir::time__N);
$ ./parrot-nqp fib-4.nqp
1259694448.26969
1259694448.28342
fib(28) = 317811
1259694469.60673
As you can see, execution time after a forced GC run at the beginning
is still about 21 seconds (69.60673 - 48.28342). Running the .pir
version of the above takes about 9.6 seconds. This tells me that
it must be the long-lived gc-ables that are making the difference
in execution time, and not the short-lived structures resulting
from PCC.
Pm
P.S.: Further analysis reveals that many of our "short-lived"
PCC structures may in fact end up being long-lived. But the original
point remains that it appears to be GC that is significantly slowing
things down during runtime.
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
