On Sat, Feb 5, 2011 at 10:14 AM, Liam Healy <lhe...@common-lisp.net> wrote:
> 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. OK, will do. > 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? > I don't have any evidence off inefficiencies. (now that you mention it, I should try a similar calculation in fortran and c -- will report on that). The experiment was motivated by the fact that map-grid provides both the argument types and the required result type. I wanted to see if providing declarations to the element-function would improve performance. > > Liam > > > On Thu, Feb 3, 2011 at 12:34 PM, Mirko Vukovic <mirko.vuko...@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 > > > > > <#> <#> <#> <#>
_______________________________________________ GSLL-devel mailing list GSLL-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel