From: Tamas K Papp on
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
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
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
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
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/
 |  Next  |  Last
Pages: 1 2 3
Prev: Free will
Next: ECL+Windows+MinGW32