Robert Boyer <[EMAIL PROTECTED]> writes: > Using Camm's cvs suggestion to get a Dec 14 2.7.0 GCL, things seem unchanged > between then and now in terms of the Nqthm proofs. These are both with > default MAXPAGES, ANSI. > > cvs -z9 -q co -d gcl -D 20051214 gcl > run-gbc time : 1975.380 secs > child run time : 147.250 secs > gbc time : 59.520 secs > > Tuesday 2.7.0 > run-gbc time : 2000.970 secs > child run time : 147.340 secs > gbc time : 62.230 secs > > This is good news, suggesting that rumors of a slowdown since December are > entirely false. Apologies for rumor mongering. But it creates a real > mystery for me. > > Running in 2.7.0 just a few days ago, but in a huge (170 mb) saved image with > very large ihs and vs stacks, I got 10% worse: > > run-gbc time : 2181.560 secs > child run time : 141.280 secs > gbc time : 94.930 secs > > So this supports Matt's position that size does matter, which I "disproved" > yesterday, at least for a big MAXPAGE. I'm a bit lost. How could simply > running in a saved image configured with with > > --enable-ihssize=2097152 \ > --enable-vssize=2097152 \ > --enable-maxpage=524288 \ > --enable-holediv=100 \ >
My guess is holediv, though if so the timing output should be improved. Try holediv=16. The default is 4, and you are using 4x the default maxpages. The gc time is up by 50%, supporting this hypothesis. However, to be material, this would have to mean that a substantial fraction of the actual gc overhead is being accumulated in the run-gbc time statistic, which at this point is just "idle speculation" :-). Take care, > cause a 10% slowdown? Or is this all some sort of "operator error" on my > part? Sorry for wasting your time. > > Bob > > > > > -- Camm Maguire [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gcl-devel
