Re: GETF Speedup?
"Tim Bradshaw (as tfb at cley dot com)" <[email protected]>
| Newsgroups | gmane.lisp.lispworks.general |
|---|---|
| Message-ID | <[email protected]> |
On 11 Oct 2025, at 17:21, Tim Bradshaw <[email protected]> wrote: > > All things being equal I'd expect a copying GC to improve locality for lists: once its found the head of the list is live it will walk down it and copy it, presumably to locations very close to each other. And this turns out to be true. I wrote a little function called 'sequentialness' which tells you how sequential a list is, using object-address for the conses. 1 means 'completely', 0 means 'not at all'. > (sequentialness (make-list 100)) 1 99 t (The second value is how many pointers it followed, the third is whether the previous two make sense, as you can call it on non-list objects.) Given a function make-blubby-list which makes an n-element list doing a bunch of spurious consing in between each element, you can see that these lists are not at all sequential: > (sequentialness (make-blubby-list 100)) 0 99 t And now we can write this: (defun test-blubby (n) (let ((l (make-blubby-list n))) (values (sequentialness l) (progn (gc-generation 0) (sequentialness l))))) And > (test-blubby 100) 0 65/99 > (test-blubby 10000) 0 9965/9999 I don't understand why the list is not completely sequential, even for small lists: my guess is something to do with the way the GC works. Obviously the whole thing depends on fine details of the memory-management system. --tim _______________________________________________ Lisp Hug - the mailing list for LispWorks users [email protected] http://www.lispworks.com/support/lisp-hug.html