Prev: How to a matrix from a file
Next: GUI stuff
From: Thibault Langlois on 20 May 2010 05:20
I thought that PRINC was more low-level than FORMAT thus more
efficient. Apparently I am wrong. Using SBCL i tried two versions of
the following method (switching commented lines) :

(defmethod octave-save ((a generic-matrix) (file pathname) &key
(octave-name "IMPORTEDDATA") &allow-other-keys)
(declare (optimize (speed 3) (space 0) (debug 0)))
(with-open-file (f file :direction :output :if-exists :supersede)
(write-octave-header f octave-name (rows a) (columns a))
(loop
with r = (rows a)
with c = (columns a)
for i fixnum below r
do (loop
for j fixnum below c
do
;; (princ (ref a i j) f) (princ " " f)
(format f "~F " (ref a i j))
)
(format f "~%")
;; (terpri f)
)))

I get with the FORMAT version:
Evaluation took:
31.526 seconds of real time
31.410000 seconds of total run time (30.340000 user, 1.070000
system)
[ Run times consist of 2.760 seconds GC time, and 28.650 seconds non-
GC time. ]
99.63% CPU
75,478,544,163 processor cycles
4,526,043,696 bytes consed

with the PRINC version I get:
Evaluation took:
42.817 seconds of real time
42.140000 seconds of total run time (40.980000 user, 1.160000
system)
[ Run times consist of 4.570 seconds GC time, and 37.570 seconds non-
GC time. ]
98.42% CPU
102,511,120,905 processor cycles
8,589,520,032 bytes consed

Almost twice as much conses ?!
Any comments ?

Thibault
From: joswig on 20 May 2010 06:02
On 20 Mai, 11:20, Thibault Langlois <thibault.langl...(a)gmail.com>
wrote:
> I thought that PRINC was more low-level than FORMAT thus more
> efficient. Apparently I am wrong. Using SBCL  i tried two versions of
> the following method (switching commented lines) :
>
> (defmethod octave-save ((a generic-matrix) (file pathname) &key
> (octave-name "IMPORTEDDATA") &allow-other-keys)
>   (declare (optimize (speed 3) (space 0) (debug 0)))
>   (with-open-file (f file :direction :output :if-exists :supersede)
>     (write-octave-header f octave-name (rows a) (columns a))
>     (loop
>          with r = (rows a)
>          with c = (columns a)
>          for i fixnum below r
>          do (loop
>                for j fixnum below c
>                do
>                 ;; (princ (ref a i j) f) (princ " " f)
>                  (format f "~F " (ref a i j))
>                  )
>          (format f "~%")
>          ;; (terpri f)
>          )))
>
> I get with the FORMAT version:
> Evaluation took:
>   31.526 seconds of real time
>   31.410000 seconds of total run time (30.340000 user, 1.070000
> system)
>   [ Run times consist of 2.760 seconds GC time, and 28.650 seconds non-
> GC time. ]
>   99.63% CPU
>   75,478,544,163 processor cycles
>   4,526,043,696 bytes consed
>
> with the PRINC version I get:
> Evaluation took:
>   42.817 seconds of real time
>   42.140000 seconds of total run time (40.980000 user, 1.160000
> system)
>   [ Run times consist of 4.570 seconds GC time, and 37.570 seconds non-
> GC time. ]
>   98.42% CPU
>   102,511,120,905 processor cycles
>   8,589,520,032 bytes consed
>
> Almost twice as much conses ?!
> Any comments ?
>
> Thibault

Btw., I wouldn't declare the optimization for the whole generic
function. See for example LOCALLY.

FORMAT has a fixed format string. A sophisticated implementation thus
can use a
compiler to generate optimized code (see also the function FORMATTER).
Basically this can be a floating point number output routine, followed
by output of a space.

PRINC usually is forced to use the generic output engine.

It may look differently for other implementations which are
'interpreting' format strings all the time...

From: Zach Beane on 20 May 2010 06:05
Thibault Langlois <thibault.langlois(a)gmail.com> writes:

> Almost twice as much conses ?!
> Any comments ?

How do the times look if you set *PRINT-PRETTY* to nil before timing?

Zach
From: fortunatus on 20 May 2010 09:51
On May 20, 6:02 am, "jos...(a)corporate-world.lisp.de" <jos...(a)lisp.de>
wrote:
> FORMAT has a fixed format string. A sophisticated implementation thus
> can use a
> compiler to generate optimized code (see also the function FORMATTER).

Try the experiment by passing a format string from a variable, SETQ
the variable at run time before the subroutine call...
From: Thibault Langlois on 20 May 2010 09:57
On May 20, 11:05 am, Zach Beane <x...(a)xach.com> wrote:
> Thibault Langlois <thibault.langl...(a)gmail.com> writes:
> > Almost twice as much conses ?!
> > Any comments ?
>
> How do the times look if you set *PRINT-PRETTY* to nil before timing?
>
> Zach

Well, that's interesting. The value of *print-pretty* has no influence
on the FORMAT version but when *pretty-print* is nil with the PRINC
version, it gets faster and cons less:

Evaluation took:
35.718 seconds of real time
34.950000 seconds of total run time (33.890000 user, 1.060000
system)
[ Run times consist of 2.910 seconds GC time, and 32.040 seconds non-
GC time. ]
97.85% CPU
85,516,211,448 processor cycles
5,059,116,064 bytes consed

Thibault
 | 
Pages: 1
Prev: How to a matrix from a file
Next: GUI stuff