[Openmcl-devel] OpenMCL future

[Christophe Rhodes]

On Wed, Sep 11, 2002 at 04:05:09PM -0600, Gary Byers wrote:
> > > - investigation where Altivec could be used to speed up the
> > >   Lisp kernel or compiled Lisp code
> >
> > I've been interested in this (well, coming from sbcl/x86-land, the
> > analogous question of how SSE can help SBCL :-), and the conclusion that
> > I came to was that first the compiler needs to understand loops
> > properly. I don't know offhand what understanding the OpenMCL compiler
> > has; the CMUCL/SBCL "Python" compiler doesn't do very much at all with
> > loops, sadly, so it might be quite some work.
> 
> One other complicating factor has to do with AltiVec's alignment constraints:
> it prefers data to be aligned on 128-bit boundaries, though there's a
> "vector permute" operation that allows it to deal with mis-aligned data.
> 
> Like most 32-bit lisps, OpenMCL only guarantees 64-bit alignment of heap
> allocated data (so something's 128-bit aligned about half the time, on
> average.)  The introduction of preemptively scheduled threads will mean
> that a GC could change the address (and alignment) of an object at
> virtually any time, which makes it hard to use AltiVec instructions on
> general, heap-allocated data.
> 
> There may be several ways around this; one attractive appproach is to
> wait until the problem disappears (PPC64, etc.), but that solution may
> not be entirely satisfactory.

Yes. The problem is roughly the same on the x86, in that there are
aligned- and unaligned- variants of instructions, with the unaligned
instructions working on any address but taking much longer to execute.

The particular problem I was looking at was optimizing
  (MAP-INTO X #'+ Y Z),
where X, Y, and Z were known to be of type
  (SIMPLE-ARRAY (UNSIGNED-BYTE 32) (*));
a brute-force attack on the problem (essentially, in SBCL's terminology,
writing a VECTOR-+/UNSIGNED-32 V[irtual] OP[eration]) got to the same
order of magnitude in speed, but as you've pointed out I was constrained
to use the unaligned instructions.

There might be (slightly suboptimal) ways to hack at the allocator and
the garbage collector to tell it always to align the data vector of
VECTOR and ARRAY objects in SBCL's case, though I wouldn't particularly
want to do it; I guess if there were a need something similar could be
done on OpenMCL's equivalents, but it's not an entirely satisfactory
solution, I guess.

> > One thing I would be interested in is a slightly nebulous cooperation
> > between at the very least the "free" implementors
> 
> A few weeks ago, a colleague and I got ourselves fairly psyched about
> this sort of collaborative effort. I still think that it's a good idea,
> and wonder how best to proceed.

Oh, good. Well, it's something I've been wanting for a while; more
discussion generally stops me from making mistakes, if nothing else; I
know of interested parties on the CMUCL team also.

> CLOCC makes some effort to define a portable extension layer; though
> it's probably not as broad as one might like, it seems to me to be
> mostly at about the right depth.  I wonder if some or all of it would
> be a good starting point ?

It's probably a decent starting point in terms of the most obvious
functionality needed; I wouldn't hold out any great hopes for the design
of the interface, though; back in the "good old days" when I actually
wrote user-level programs in Lisp, they didn't make me feel terribly
warm and fuzzy about either their robustness or their usability. 

> I'm certainly interested in exploring this further, and if we get it
> off the ground, to committing time and effort to the process.  I think
> that it's worth remembering that language design is a hard problem, and
> even if we keep our aims fairly conservative it can be a time-consuming
> process (see X3J13 and similar efforts.)

Now, this is certainly true. I also am willing to spend time on this; I
really want to be happy with the results, too. 

Cheers,

Christophe
-- 
Jesus College, Cambridge, CB5 8BL                           +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/                  (defun pling-dollar 
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)

_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel