diary at Telent Netowrks

Not a particularly good test, this, because I don't have an unmolested#

Sun, 21 Dec 2003 14:16:22 +0000

Not a particularly good test, this, because I don't have an unmolested SBCL binary for the same exact version as the one I'm hacking. But here are the numbers, anyway.

Before: an ordinary SBCL 0.8.6.16

Evaluation took: 20.432 seconds of real time 19.946968 seconds of user run time 0.079988 seconds of system run time 0 page faults and 4935680 bytes consed.

After: an unpurified 0.8.6.37, with some rather vicious cleanups in the allocation routines (which seem to have fixed the bug described earlier, but more testing will be required)

Evaluation took: 13.578 seconds of real time 13.35597 seconds of user run time 0.077988 seconds of system run time 0 page faults and 4096000 bytes consed.

Evaluation took: 12.49 seconds of real time 12.315128 seconds of user run time 0.057991 seconds of system run time [Run times include 12.37 seconds GC run time] 0 page faults and 0 bytes consed.

Um... um... About 35ms per GC, and give that that just returns it to CMUCL speeds, I rather suspect that it's all due to fixing the fragmentation bug and nothing to do with static space at all.

It should be noted that the stuff to remove fixups and trace tables has been disabled temporarily, until I find out why it's breaking things. Due to this and probably other reasons too, the dynamic space usage is around 47Mb, and the core is a quite rotund 92Mb. Yum.

The gencgc cleanups alluded to were the removal of most of the special-casing for large objects. There is now only one criterion for whether an object is handled as a large object, which is that its size exceeds largeobjectsize. If so, it will be allocated in its own region, which will not share any pages with any other region. It no longer matters whether you call gcalloclarge or gcquickalloc_large; the same thing happens in either case.

It's far too close to Christmas to commit any of this right now (wait for after 0.8.7) but before I do I'd like to find out whether the gencgc policy changes (and the fragmentation bug fix they make possible) have any effect on their own, or if this speedup is all due to the static space now only being 1456 bytes long.