[GSLL-devel] how to optimize grid mapping?

Mirko Vukovic mirko.vukovic at gmail.com
Sat Feb 5 20:39:14 UTC 2011


On Sat, Feb 5, 2011 at 10:14 AM, Liam Healy <lhealy at 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.vukovic at 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 at common-lisp.net
> > http://common-lisp.net/cgi-bin/mailman/listinfo/gsll-devel
> >
> >
>

                                                  <#>              <#>
<#>       <#>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/gsll-devel/attachments/20110205/1825a651/attachment.html>


More information about the gsll-devel mailing list