I've seen those notes too, and I'm not sure what they mean. It doesn't make sense to me that a double float should have to be within 2^63 unless perhaps it is trying to convert to a fixnum somewhere, which also seems odd. You might try asking on #lisp or the SBCL mailing list. Actually, I'm not sure what optimization to expect here, because I'm not sure how it might be compiling this inefficiently. What evidence do you have of inefficiency?
Liam
On Thu, Feb 3, 2011 at 12:34 PM, Mirko Vukovic mirko.vukovic@gmail.com wrote:
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
GSLL-devel mailing list GSLL-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel