Prev: Free will
Next: ECL+Windows+MinGW32
From: Tamas K Papp on 17 May 2010 10:40 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
From: vanekl on 17 May 2010 10:52 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 Clozure Common Lisp (Version 1.6-dev-r13687M-trunk (LinuxX8632)) on i686 (Intel(R) Pentium(R) 4 CPU 3.00GHz) 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 ;; don't know pinned array answer
From: Raffael Cavallaro on 17 May 2010 11:11 On 2010-05-17 10:40:18 -0400, Tamas K Papp said: > I wonder if people could help me by sending the output of the > following form for various implementations. 6 implementations follow: LispWorks (6.0.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 itself NIL Clozure Common Lisp (Version 1.6-dev-r13699M-trunk (DarwinX8632)) on i386 (MacBookPro5,5) 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 NIL Clozure Common Lisp (Version 1.6-dev-r13699M-trunk (DarwinX8664)) on i386 (MacBookPro5,5) 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 itself NIL ECL (10.3.1) on i386 (NIL) 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 INTEGER32 (SIGNED-BYTE 64) is upgraded to INTEGER64 NIL SBCL (1.0.36) on X86-64 (MacBookPro5,5) 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 NIL Armed Bear Common Lisp (0.13.0) on X86_64 (NIL) 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 warmest regards, Ralph -- Raffael Cavallaro
From: Willem Rein Oudshoorn on 17 May 2010 13:14 Clozure Common Lisp (Version 1.4-r13119 (DarwinPPC32)) on Power Macintosh (PowerBook6,5) 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 NIL
From: Pascal J. Bourguignon on 17 May 2010 14:03
Tamas K Papp <tkpapp(a)gmail.com> writes: > 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, clisp upgrades to T on all the machines I tested: [pjb(a)kuiper :0.0 ~]$ for host in galatea triton hubble kuiper voyager ; do scp script.lisp ${host}:/tmp/ ; ssh $host bash -c 'hostname ; uname -a ; unalias clisp 2>/dev/null || true ; clisp -q -norc -ansi -i /tmp/script.lisp -x "(quit)"' ; done script.lisp 100% 626 0.6KB/s 00:00 galatea.lan.informatimago.com Darwin galatea.lan.informatimago.com 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386 ;; Loading file /tmp/script.lisp ... CLISP (2.48 (2009-07-28) (built on galatea.local [10.0.2.1])) 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 ;; Loaded file /tmp/script.lisp script.lisp 100% 626 0.6KB/s 00:00 triton.lan.informatimago.com Darwin triton.lan.informatimago.com 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:57:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_PPC Power Macintosh ;; Loading file /tmp/script.lisp ... CLISP (2.48 (2009-07-28) (built on triton.wifi.informatimago.com [192.168.8.131])) on POWER MACINTOSH (POWER MACINTOSH) 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 ;; Loaded file /tmp/script.lisp script.lisp 100% 626 0.6KB/s 00:00 hubble Linux hubble 2.6.31-gentoo-r6-c8-bt-wc-sa #5 SMP PREEMPT Fri Jan 29 15:24:25 CET 2010 i686 AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ AuthenticAMD GNU/Linux ;; Loading file /tmp/script.lisp ... CLISP (2.48 (2009-07-28) (built on hubble.lan.informatimago.com [192.168.0.3])) on I686 (I686) 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 ;; Loaded file /tmp/script.lisp script.lisp 100% 626 0.6KB/s 00:00 kuiper Linux kuiper 2.6.32-xen-r1-nfs #5 SMP Sun May 16 15:09:51 CEST 2010 x86_64 Intel(R) Core(TM) i7 CPU 950 @ 3.07GHz GenuineIntel GNU/Linux ;; Loading file /tmp/script.lisp ... CLISP (2.47 (2008-10-23) (built 3483026614) (memory 3483026769)) on X86_64 (X86_64) 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 ;; Loaded file /tmp/script.lisp script.lisp 100% 626 0.6KB/s 00:00 voyager.informatimago.com Linux voyager.informatimago.com 2.6.8-3-k7-smp #1 SMP Tue Dec 5 22:36:44 UTC 2006 i686 GNU/Linux ;; Loading file /tmp/script.lisp ... CLISP (2.33.2 (2004-06-02) (built 3392849301) (memory 3392849373)) on I686 (I686) 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 ;; Loaded file /tmp/script.lisp [pjb(a)kuiper :0.0 ~]$ -- __Pascal Bourguignon__ http://www.informatimago.com/ |