[Openmcl-devel] Quick HW question...
j-anthony at comcast.net
Tue Nov 16 20:10:41 UTC 2010
On Tue, 2010-11-16 at 11:30 -0700, Spires, Shannon V wrote:
> Matt wrote:
> > On modern x86, I've all but given up. I just write
> > naive and straightforward code, and assume (or hope) that
> > the hardware guys have optimized for that. In my experience,
> > measurements typically show that the difference in execution
> > time between "clever" and naive code is negligible.
> > Intel has an optimization guide (you should be able to
> > find it at http://www.intel.com/products/processor/manuals/).
> But how do you even write clever cache-aware code in Lisp? Lisp is a pointer-following language with garbage collection; Lisp data is a dynamic graph where the nodes point all over the place and are constantly moving around. A C program is more like one big node: Its data is all in one place and it doesn't move around. Modern cache architectures were built with C-like programs in mind; they're hell for Lisp.
This sounds off to me on a few counts: Typical C programs have loads of
(manual) allocated ("pointer data") and the RTS managers for this are
not necessarily good and can lead to a lot of fragmentation. Lisp (and
other expected GC languages) can and do bring all the live stuff
together in a smaller space (after collection). Compacting collectors
(CCL) should typically be even better at this as "old" live things never
need to move.
Both larger C and Lisp (and for that matter more or less anything else)
will have memory not all in "one place" but scattered all over VM.
Again due to GC, I would think it more usual for manual allocation
programs to have more locality issues.
> We either need to find a way to build uniform-speed memory (including the non-volatile variety) or move to something like Cray's XMT architecture if we want Lisp to run really fast.
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel