In article <······················@ptolemy-ethernet.arc.nasa.gov> ······@kronos.arc.nasa.gov (Chuck Fry ) writes:
> From: ······@kronos.arc.nasa.gov (Chuck Fry )
> Newsgroups: comp.lang.lisp
...
> When you are trying hard to squeeze cycles out of an inner loop, that
> ~100 ns per indirection [due to following pointers not in memory
> cache] starts to add up. Caching can help somewhat,
> but only for the most frequently referenced routines.
I would think that after one trip through the inner loop all of the
relevant routines would be in the cache (given enough space). If there
isn't enough space in cache for all of the relevant routines, then it
doesn't seem likely that a static dispatch will help either.
I think this analysis only applies to cases where adding the dispatch
code to the executing code causes the cache to overflow...
> Like it or not, the implications for Lisp aficionados are obvious.
> Modern processors work fastest when memory references are minimized,
> and when the remaining memory references are primarily in linear order
> to maximize cache hits. C++ has a performance edge on CLOS in this
> respect.
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu