[GSLL-devel] how to optimize grid mapping?

Mirko Vukovic mirko.vukovic at gmail.com
Thu Feb 3 17:34:15 UTC 2011


Hello,

I was wondering whether optimization can help grid-map's performance.  (But
I really have not done
much optimizing).  So, I timed the following two functions which map `sin'
over a really large grid:

(in-package :grid)

(defun optimized (arg)
  (grid:map-grid :source arg
        :element-function
        #'(lambda (arg)
        (declare
         (optimize (speed 3) (safety 0) (debug 0))
         (double-float arg))
        (the double-float (sin arg))))
  (values))

(defun unoptimized (arg)
  (grid:map-grid :source arg
        :element-function
        #'(lambda (arg)
        (sin arg)))
  (values))

(progn
  (defvar *arg* nil)
  (setf *arg* (grid:make-grid '((foreign-array 300000) double-float)
                  :initial-element 1d0))
  nil)

On 64bit linux & SBCL, compilation of the optimized routine generate the
following notes
that I don't understand:

; note: unable to avoid inline argument range check
; because the argument range (DOUBLE-FLOAT) was not within 2^63

;     #'(LAMBDA (GRID::ARG)
;         (DECLARE (OPTIMIZE (SPEED 3) (SAFETY 0) (DEBUG 0))
;                  (DOUBLE-FLOAT GRID::ARG))
;         (THE DOUBLE-FLOAT (SIN GRID::ARG)))
;
; note: doing float to pointer coercion (cost 13) to "<return value>"

Timing both routines gives very similar results:

GRID> (time (unoptimized *arg*))
Evaluation took:
  0.112 seconds of real time
  0.111983 seconds of total run time (0.110983 user, 0.001000 system)
  [ Run times consist of 0.004 seconds GC time, and 0.108 seconds non-GC
time. ]
  100.00% CPU
  335,890,827 processor cycles
  19,202,048 bytes consed

GRID> (time (optimized *arg*))
Evaluation took:
  0.113 seconds of real time
  0.112983 seconds of total run time (0.111983 user, 0.001000 system)
  [ Run times consist of 0.003 seconds GC time, and 0.110 seconds non-GC
time. ]
  100.00% CPU
  337,194,558 processor cycles
  19,202,032 bytes consed

Any ideas how to properly optimize the code?

Thanks,

Mirko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/gsll-devel/attachments/20110203/2ef147ab/attachment.html>


More information about the gsll-devel mailing list