

Caches and Lisp: faster list processing via auto-rearranging memory (2003) [pdf] - luu
http://www.cs.berkeley.edu/~fateman/papers/cachelisp.pdf

======
zvrba
In section 4 they found that traversing an organized list is FASTER than
traversing an array of the same size when both fit into the L1 cache. I find
this highly implausible [0] because 1) traversing a list needs more
instructions, 2) both L1 and L2 cache miss numbers are smaller for the array.
The authors provide no explanation for the result either.

[0] I believe they got these numbers, but they should have dug more into the
cause instead of accepting the conclusion at face value. Given this is a LISP
benchmark, maybe array bounds checks are costly? Maybe a different result
would have been obtained had they instructed the compiler to generate unsafe
code?

~~~
diroussel
It's to do with branch prediction.

[http://stackoverflow.com/questions/11227809/why-is-
processin...](http://stackoverflow.com/questions/11227809/why-is-processing-a-
sorted-array-faster-than-an-unsorted-array)

~~~
davidshepherd7
Seems unlikely: in the experiments here the lists are not sorted in the sense
of the stack overflow question (i.e. they are not in numerical or alphabetical
order). They are sorted (in memory) by their index in the linked list. By
definition the array is already in this order.

Unless I've missed something?

------
gsg
Interesting that it doesn't mention CDR-coding - I guess that's considered
competitive only with hardware support. There's been some work by Appel on
trying to improve performance by unrolling (in his case, immutable) cons
lists, too.

------
joe_the_user
A fascinating idea.

I haven't digest the entire paper yet.

I am wondering already whether this idea would be combined with the schemes
which yield cache-oblivious algorithms.

