Prev: Free will
Next: ECL+Windows+MinGW32
From: Alberto Riva on 17 May 2010 14:17 On 05/17/2010 10:40 AM, Tamas K Papp wrote: > Hi everyone, > > Soon I will undertake a rewrite of my LLA library (which is a LAPACK > layer for Lisp, with lots of nice semantic sugar). The rewrite should > be row-major (instead of column-major, LAPACK handles both just fine), > and use mostly CL arrays. For this I would like to rely on the > following assumption: if your implementation is serious about numerical > work, it will support certain array element types. If it doesn't, > that's fine, arrays will be checked for actual element type before > being passed to LAPACK. So it should work on all implementations, use > native Lisp arrays, still be blazing fast on SBCL and similar > implementations, and a bit slower but fully functional on CLISP etc. > > I wonder if people could help me by sending the output of the > following form for various implementations. Ideally, I would like to > collect both 32/64 bit versions, but if you can send only one, that's > great too. Both free and commercial implementations would interest me. > > Also, if you can, please tell me if your implementation supports pinned > arrays (ie arrays which can be pinned at a particular memory address and > manipulated by foreign routines). Obviously I couldn't write a function > to check that :-) > > (flet ((check-upgraded (type) > (let ((upgraded (upgraded-array-element-type type))) > (format t "~A is upgraded to ~A~%" > type > (if (equal type upgraded) > "itself" > upgraded))))) > (format t "~2&~A (~A) on ~A (~A)~2%" > (lisp-implementation-type) (lisp-implementation-version) > (machine-type) (machine-version)) > (map nil #'check-upgraded '(single-float double-float > (complex single-float) (complex double-float) > (signed-byte 32) (signed-byte 64)))) International Allegro CL Enterprise Edition (8.2 [Linux (x86)] (Jan 25, 2010 14:48)) on x86 (i686) SINGLE-FLOAT is upgraded to itself DOUBLE-FLOAT is upgraded to itself (COMPLEX SINGLE-FLOAT) is upgraded to itself (COMPLEX DOUBLE-FLOAT) is upgraded to itself (SIGNED-BYTE 32) is upgraded to itself (SIGNED-BYTE 64) is upgraded to T International Allegro CL Enterprise Edition (8.2 [64-bit Linux (x86-64)] (Apr 28, 2010 16:35)) on 64-bit x86-64 (x86_64) SINGLE-FLOAT is upgraded to itself DOUBLE-FLOAT is upgraded to itself (COMPLEX SINGLE-FLOAT) is upgraded to itself (COMPLEX DOUBLE-FLOAT) is upgraded to itself (SIGNED-BYTE 32) is upgraded to itself (SIGNED-BYTE 64) is upgraded to itself Alberto
From: Thomas A. Russ on 17 May 2010 14:19 CMU Common Lisp 19e (19E), running on cowabunga.isi.edu With core: /opt/local/cmucl-19e/lib/cmucl/lib/lisp.core Dumped on: Thu, 2008-05-01 17:38:02-07:00 on macmini See <http://www.cons.org/cmucl/> for support information. Loaded subsystems: Python 1.1, target Intel x86 CLOS based on Gerd's PCL 2004/04/14 03:32:47 CMU Common Lisp (19e (19E)) on X86 (X86) SINGLE-FLOAT is upgraded to itself DOUBLE-FLOAT is upgraded to itself (COMPLEX SINGLE-FLOAT) is upgraded to itself (COMPLEX DOUBLE-FLOAT) is upgraded to itself (SIGNED-BYTE 32) is upgraded to itself (SIGNED-BYTE 64) is upgraded to T CLISP (2.48 (2009-07-28) (built 3470077256) (memory 3470077469)) on I386 (I386) SINGLE-FLOAT is upgraded to T DOUBLE-FLOAT is upgraded to T (COMPLEX SINGLE-FLOAT) is upgraded to T (COMPLEX DOUBLE-FLOAT) is upgraded to T (SIGNED-BYTE 32) is upgraded to T (SIGNED-BYTE 64) is upgraded to T LispWorks Personal Edition (5.1.1) on x86 (486) SINGLE-FLOAT is upgraded to itself DOUBLE-FLOAT is upgraded to itself (COMPLEX SINGLE-FLOAT) is upgraded to T (COMPLEX DOUBLE-FLOAT) is upgraded to T (SIGNED-BYTE 32) is upgraded to itself (SIGNED-BYTE 64) is upgraded to T SBCL (1.0.35) on X86-64 (MacBookPro3,1) SINGLE-FLOAT is upgraded to itself DOUBLE-FLOAT is upgraded to itself (COMPLEX SINGLE-FLOAT) is upgraded to itself (COMPLEX DOUBLE-FLOAT) is upgraded to itself (SIGNED-BYTE 32) is upgraded to itself (SIGNED-BYTE 64) is upgraded to itself -- Thomas A. Russ, USC/Information Sciences Institute
From: Alan Malloy on 17 May 2010 18:59 Tamas K Papp wrote: > Hi everyone, > > Soon I will undertake a rewrite of my LLA library (which is a LAPACK > layer for Lisp, with lots of nice semantic sugar). The rewrite should > be row-major (instead of column-major, LAPACK handles both just fine), > and use mostly CL arrays. For this I would like to rely on the > following assumption: if your implementation is serious about numerical > work, it will support certain array element types. If it doesn't, > that's fine, arrays will be checked for actual element type before > being passed to LAPACK. So it should work on all implementations, use > native Lisp arrays, still be blazing fast on SBCL and similar > implementations, and a bit slower but fully functional on CLISP etc. > > I wonder if people could help me by sending the output of the > following form for various implementations. Ideally, I would like to > collect both 32/64 bit versions, but if you can send only one, that's > great too. Both free and commercial implementations would interest me. > > Also, if you can, please tell me if your implementation supports pinned > arrays (ie arrays which can be pinned at a particular memory address and > manipulated by foreign routines). Obviously I couldn't write a function > to check that :-) > > (flet ((check-upgraded (type) > (let ((upgraded (upgraded-array-element-type type))) > (format t "~A is upgraded to ~A~%" > type > (if (equal type upgraded) > "itself" > upgraded))))) > (format t "~2&~A (~A) on ~A (~A)~2%" > (lisp-implementation-type) (lisp-implementation-version) > (machine-type) (machine-version)) > (map nil #'check-upgraded '(single-float double-float > (complex single-float) (complex double-float) > (signed-byte 32) (signed-byte 64)))) > > Eg on SBCL on my machine, it looks like this: > > SBCL (1.0.38) on X86-64 (Intel(R) Core(TM)2 Duo CPU P8700 @ 2.53GHz) > > SINGLE-FLOAT is upgraded to itself > DOUBLE-FLOAT is upgraded to itself > (COMPLEX SINGLE-FLOAT) is upgraded to itself > (COMPLEX DOUBLE-FLOAT) is upgraded to itself > (SIGNED-BYTE 32) is upgraded to itself > (SIGNED-BYTE 64) is upgraded to itself > > Thanks, > > Tamas CLISP (2.44 (2008-02-02) (built on stnt067 [192.168.0.1])) on PC/386 (PC/?86) SINGLE-FLOAT is upgraded to T DOUBLE-FLOAT is upgraded to T (COMPLEX SINGLE-FLOAT) is upgraded to T (COMPLEX DOUBLE-FLOAT) is upgraded to T (SIGNED-BYTE 32) is upgraded to T (SIGNED-BYTE 64) is upgraded to T NIL -- Cheers, Alan (San Jose, California, USA)
From: Rob Warnock on 18 May 2010 21:13 Thomas A. Russ <tar(a)sevak.isi.edu> wrote: +--------------- | CMU Common Lisp (19e (19E)) on X86 (X86) | | SINGLE-FLOAT is upgraded to itself | DOUBLE-FLOAT is upgraded to itself | (COMPLEX SINGLE-FLOAT) is upgraded to itself | (COMPLEX DOUBLE-FLOAT) is upgraded to itself | (SIGNED-BYTE 32) is upgraded to itself | (SIGNED-BYTE 64) is upgraded to T +--------------- Ditto CMUCL-19f. AFAIK, the only way to get "pinned" arrays in CMUCL is to use "aliens", where the arrays are actually allocated via system "malloc()" and accessed from CL using CMUCL's "alien" FFI, see: http://common-lisp.net/project/cmucl/doc/cmu-user/aliens.html -Rob ----- Rob Warnock <rpw3(a)rpw3.org> 627 26th Avenue <URL:http://rpw3.org/> San Mateo, CA 94403 (650)572-2607
From: Raymond Toy on 18 May 2010 22:34
On 5/18/10 9:13 PM, Rob Warnock wrote: > Thomas A. Russ <tar(a)sevak.isi.edu> wrote: > +--------------- > | CMU Common Lisp (19e (19E)) on X86 (X86) > | > | SINGLE-FLOAT is upgraded to itself > | DOUBLE-FLOAT is upgraded to itself > | (COMPLEX SINGLE-FLOAT) is upgraded to itself > | (COMPLEX DOUBLE-FLOAT) is upgraded to itself > | (SIGNED-BYTE 32) is upgraded to itself > | (SIGNED-BYTE 64) is upgraded to T > +--------------- > > Ditto CMUCL-19f. > > AFAIK, the only way to get "pinned" arrays in CMUCL is to use "aliens", > where the arrays are actually allocated via system "malloc()" and > accessed from CL using CMUCL's "alien" FFI, see: > > http://common-lisp.net/project/cmucl/doc/cmu-user/aliens.html There is now some support for pinned arrays. They're still allocated via malloc, but GC knows about them and will GC them when they become garbage. This feature was added in the last couple of snapshots. To allocate such an array, use make-array with :allocation :malloc. I've done some testing with them and seem to work, but testing was limited. Ray |