[Try pronouncing that phrase fast!] Just for the heck of it, I instrumented one of the "Gabriel" benchmarks for Lisp -- the Boyer benchmark -- which operates solely on Lisp CONS cells, and never damages these cells using RPLACA/RPLACD. I wanted to see what the cache performance of an ideal LRU *data* cache would be for this benchmark, so I computed the statistics on the "move to front" behavior of the various CONS cells involved in this computation. The most important statistic is the so-called "stack distance" -- the number of positions between the current position on the LRU list and the front of the list. We can accumulate for each stack distance the number of times a "move to front" traverses that particular distance. If one runs a typical computation long enough, the sequence of these stack distances tends to fall off as n^(-beta), typically 1.3 < beta < 1.7 (note that beta=1 for Zipf). A higher beta means greater "locality": the cache is more effective; a lower beta means that the cache is less effective. Interestingly, the beta I measured for Boyer is ~1.2666, which places it below the normal range for programs studied by computer architects, and may explain some of the poor cache performance of Lisp on architectures not optimized for Lisp. BTW, my instrumented Boyer never does GC, because any garbage cells quickly get pushed out of the early cache levels and hence don't get in the way of the ongoing computation. (See also Jon L White's paper "GC Considered Harmful".) Now this assumption could be wrong: the whole point of "nurseries" and "generational GC's" is that the % of garbage is so high, that large numbers of tiny GC's can reclaim CONS cells *while they're still in the cache*, and thus avoid cluttering up the cache with dead cells. On the other hand, a "write-allocate" cache can also perform a CONS entirely within the cache, so the only downside of garbage is the cost of eventually writing the garbage back to backing store; since the write-back mechanism can be deeply pipelined, the effective cost of writing back garbage is overlapped and hence quite small. I'll also be comparing the behavior of this "classical" Boyer with the behavior of a "hash consed" Lisp memory, where it is always the case that (EQ (CONS x y) (CONS x y)), i.e., a "hash consed" Lisp "uniquizes" cons cells based upon their CAR&CDR contents. I want to see if hash consing produces a better beta. I'll also be measuring an *instruction cache* for a McCarthy-style Lisp interpreter to see what a beta for an instruction cache might look like.