From: Tunc S. <si...@ee...> - 2002-02-01 22:56:01
|
Hi Ray, Jefferson; I've played with Allegro 6.0 as follows (I asked it to explain the compilation of m.*!): (defmethod m.*! ((a real-matrix) (b real-matrix)) (let* ((nxm (number-of-elements b))) (declare (type fixnum nxm) (optimize (speed 3) (safety 0))) (dotimes (k nxm b) (declare (type fixnum k)) (let ((a-val (matrix-ref a k)) (b-val (matrix-ref b k))) (declare (type real-matrix-element-type a-val b-val) (:explain :calls :types :boxing)) (setf (matrix-ref b k) (* a-val b-val)))))) and here is what I get: ;;; Compiling file C:\usr\gigascale\shift\src\matlisp\src\mtimes.lisp ;Examining a (possibly unboxed) call to *_2OP with arguments: ; symeval A-VAL type (DOUBLE-FLOAT * *) ; symeval B-VAL type (DOUBLE-FLOAT * *) ; which returns a value of type (DOUBLE-FLOAT * *) ;Generating a DOUBLE-FLOAT box ;Examining a call to FUNCALL with arguments: ; call to CDR type KNOWN-FUNCTION ; symeval G16043 type (DOUBLE-FLOAT * *) ; symeval G16044 type #<STANDARD-CLASS REAL-MATRIX> ; symeval G16045 type (INTEGER -536870912 536870911) ; which returns a value of type T ;Examining a call to CDR with arguments: ; constant ((EVAL-WHEN-LOADED) SETF-METHOD-LOCATIVE (QUOTE MATRIX-REF) ...) type TRUE-LIST ; which returns a value of type KNOWN-FUNCTION ;;; Writing fasl file C:\usr\gigascale\shift\src\matlisp\bin\mtimes.fasl so my conclusion is that the MATRIX-REF used to access the variables is waaaaay more expensive than AREF. Insomuch that it has the overhead of a generic function dispatch and also a boxing of the results. This will explain the performance figures given by Jefferson, which I was able to duplicate (roughly on the same order) on my Windows 2000 pentium something machine. Now I quickly tried the following change and got a performance increase of exactly 10 fold (ie. from 1.7 seconds per call to .13 seconds) and the compiler is still saying that there is boxing. I don't know the Allegro flags very well, but it seems that the matlisp sources can be modified so that this performance problem disappears and there is no need to do m.*! in fortran. (disclaimer: I DIDN'T TEST IF THE FOLLOWING MODIFICATIONS GIVE CORRECT COMPUTATIONAL RESULTS OR ARE CONSISTENT WITH MATLISP CODING STANDARDS) (defmethod m.*! ((a real-matrix) (b real-matrix)) (let* ((nxm (number-of-elements b)) (aa (store a)) (bb (store b))) (declare (type fixnum nxm) (type (real-matrix-store-type (*)) aa bb) (optimize (speed 3) (safety 0))) (dotimes (k nxm b) (declare (type fixnum k)) (let ((a-val (aref aa k)) (b-val (aref bb k))) (declare (type real-matrix-element-type a-val b-val) (:explain :calls :types :boxing)) (setf (aref bb k) (* a-val b-val)))))) Good luck and keep this list posted on your results, I think a tested version of these changes should be checked in to the repository. -- Tunc ps. I don't know your terminology on covariance normalization. But it seems to me that it should be possible using matlisp functions. Jefferson Provost wrote: > > On 2/1/02 11:34 AM, "Raymond Toy" <to...@rt...> wrote: > > >>>>>> "Jefferson" == Jefferson Provost <jp...@cs...> writes: > > > > You are right. A peek at the generated code on Solaris seems to show > > that we are calling out to generic functions way too often and could > > be vastly optimized. > > > > I know with CMUCL, a Lisp version of m+ was almost as fast (< 5% > > slower?) than Fortran, so m.* should be as fast, even in Lisp. > > > > I'll look in to it soon. > > Thanks, though I'd be happy to just write the thing in fortran myself, but > I'm totally unfamiliar with the foreign function interfaces for Allegro and > CMUCL. > > Actually, I have another routine that I use a lot which I was hoping might > be in MATLISP, but which I couldn't find. I've had to write it myself (in > lisp) and it's slower than I'd like it to be. It's basically the > "covariance normalization" i.e. the normalization that turns a covariance > matrix into a correlation coefficients matrix. > > J. > > _______________________________________________ > Matlisp-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matlisp-users |