Re: speeding up wrapper for "new" datatype

On 12 abr, 11:44, Tamas K Papp <tkp...@xxxxxxxxx> wrote:
Hi,

I was cleaning up code that interfaces to BLAS/LAPACK/UMFPack
libraries, and it occured to me that I could unify the interface for
various special matrices using CLOS.  The idea is that I create a
matrix class, and specialize that as needed, including dense matrices
which are really just wrappers around 2d arrays.

If possible, I would like dense-matrix element access to be (nearly)
as fast as aref, but I don't know how.  I thought of compiler macros,
but I can't think of an advantageous transformation.  As a general
issue, I am wondering if it is possible to make "new" datatypes as
fast as "native" ones.

I don't know if this is a great idea and to what extent this would
work, but you can do something more or less the way CFFI does it:

(define-compiler-macro mref (&whole whole matrix i j)
(or (mref-expand (get-declared-type-of-or-give-up matrix) matrix i
j)
whole))

(defgeneric mref-expand (matrix-type matrix i j)
(:method ((matrix-type t) matrix i j)
nil))

(defmethod mref-expand ((matrix-type (eql 'dense-matrix)) matrix i j)
`(aref (elements ,matrix) ,i ,j))

The problem would be to get the declared type of some element. There
is http://common-lisp.net/project/parse-declarations/ , but some outer
macro will need to get these declarations and pass them along.

An alternative is to use some implementation-dependant feature (SBCL's
deftransform seems to fit very well for this purpose, just look at a
couple of them from SBCL's source code and you would see how they
work).

I include some code snippets and benchmarks below, help is
appreciated, I am using SBCL but I am also interested in general
techniques - when I package this up as a library (eventually), I would
prefer if it was general to all implementations.

Thanks,

Tamas

.

Relevant Pages

  • speeding up wrapper for "new" datatype
    ... I was cleaning up code that interfaces to BLAS/LAPACK/UMFPack ... libraries, and it occured to me that I could unify the interface for ... various special matrices using CLOS. ... as fast as aref, ...
    (comp.lang.lisp)
  • Re: VB language extensions wishlist
    ... IDE or task-specific libraries ... Ability to define interfaces and classes separately. ... ' one strong ref, one weak ... One could access Public items in JunkStuff by using ... ...
    (microsoft.public.vb.general.discussion)
  • Re: Toward a 21st century Forth
    ... then to some extent their libraries are our libraries. ... see if the inefficiency justifies rewriting. ... interfaces, SQL -- this allows us to get on with the business of Forth. ... complex standards and complex interfaces are dominant ...
    (comp.lang.forth)
  • Re: A Collections Framework?
    ... s> In what way do CL generic functions and CLOS fail to be many times ... s> more powerful and better at expressing interfaces than Java ... You see, there are lots of wealthy companies which use Java, and they can afford to hire lots of programmers to write that framework for Java. ... It would be nice to have one, but isn't strictly required, as one can use lists, or hash tables, or FSet library, or one of btree libraries, or uses pieces of cl-contaniers which actually work, or write their own implementation. ...
    (comp.lang.lisp)
  • Re: speeding up wrapper for "new" datatype
    ... libraries, and it occured to me that I could unify the interface for ... various special matrices using CLOS. ... My basic idea is to define the interface, ... I'd like to unify). ...
    (comp.lang.lisp)