[Openmcl-devel] Quick HW question...

[Jon Anthony]

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.

/Jon


> 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.
> 
> -SS
> 
> 
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel