[MLton-devel] first benchmarks with generational gc

[Stephen Weeks]

> Was nucleic spending that much time in GC before?

Below is the gc-summary for nucleic compiled by 20020728 and my
working version (-generational {false,true}).  They show that the
answer to your question is a clear no, although the generational gc
does cut the bytes copied and gc time almost in half.  I just reran
the nucleic benchmark and got the same 0.6 ratio.  The only thing I
can think of is double alignment.  Blech.


% time z @MLton gc-summary --
max semispace size(bytes): 389,120
max stack size(bytes): 1,888
GC time(ms): 520 (11.4%)
maxPause(ms): 10
number of copying GCs: 5,102
number of mark compact GCs: 0
number of LCs: 0
bytes allocated: 797,116,840
bytes copied: 185,049,804
bytes mark-compacted: 0
max bytes live: 56,080

real	0m4.614s
user	0m4.510s
sys	0m0.040s

% time z @MLton gc-summary --
max semispace size(bytes): 327,680
max stack size(bytes): 1,888
GC time(ms): 640 (13.9%)
maxPause(ms): 10
number of minor GCs: 0
number of copying GCs: 5,114
number of mark compact GCs: 0
bytes allocated: 981,925,420
bytes copied (minor): 0
bytes copied (major): 184,407,340
bytes mark-compacted: 0
max bytes live: 56,420

real	0m5.909s
user	0m4.490s
sys	0m0.100s

% time z @MLton gc-summary --
max semispace size(bytes): 471,040
max stack size(bytes): 1,888
GC time(ms): 340 (7.8%)
maxPause(ms): 10
number of minor GCs: 9,124
number of copying GCs: 913
number of mark compact GCs: 0
bytes allocated: 981,553,504
bytes copied (minor): 43,643,056
bytes copied (major): 32,937,148
bytes mark-compacted: 0
max bytes live: 57,360

real	0m4.592s
user	0m4.330s
sys	0m0.020s


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel