[Gsll-devel] Efficient access to externally generated double-float arrays?

[Liam Healy]

Forwarded on behalf of Sebastian Sturm:

Dear all,

I have been trying to use gsll for some numerical minimization.
Allocating the multi-dimensional-root-solver-fdf with scalarsp set to
false, I understand that I should provide functions f, df and fdf
which accept (pointers to) foreign-arrays (some point x in
configuration space, some output vector f(x) and the corresponding
Jacobian matrix J(x)) and store the corresponding results within these
arrays. Being a complete Lisp newbie, I've taken a ballistic approach
to optimization by liberally scattering type declarations and (the
double-float )'s throughout my code.

Still, if I use grid:gref to access the given arrays, my functions
have to do a lot of consing and, as a result, take a long time to
complete. If I replace the grid:gref calls by (aref )'s acting on lisp
arrays that have previously been set to (cl-array the-foreign-array),
consing is eliminated (using (speed 3) (safety 0) (debug 0)), provided
that I explicitly generate the foreign-arrays x, f(x) and J which are
then passed on to f and df. Passing these optimized functions to
multi-dimensional-root-solver-fdf, however, produces a crash (using
speed 3 safety 0 debug 0) or an error message (speed 0 safety 3 debug
3) indicating that the cl-array slot of the function arguments is nil.
It seems to me that this is default behaviour for arrays created
externally by libgsl. Is this true, and if yes, is there a way to
circumvent this? Or am I simply misusing grid:gref? I have attached a
fairly minimal example minimization-issue.lisp. Compiling this using
sbcl 1.0.43 (on Mac OS X) yields the following output:

"using grid:gref"
Evaluation took:
0.003 seconds of real time
0.003419 seconds of total run time (0.003216 user, 0.000203 system)
100.00% CPU
6,943,409 processor cycles
286,496 bytes consed


#m(-0.5397677311665408d0 -1.0671897833207353d0 -1.3289868354749306d0
-1.4592646132527087d0 -1.4992646132527088d0 -1.4592646132527087d0
-1.328986835474931d0 -1.0671897833207358d0 -0.5397677311665405d0)
"using aref"
Evaluation took:
0.000 seconds of real time
0.000010 seconds of total run time (0.000009 user, 0.000001 system)
100.00% CPU
15,158 processor cycles
0 bytes consed


#m(-0.5397677311665408d0 -1.0671897833207353d0 -1.3289868354749306d0
-1.4592646132527087d0 -1.4992646132527088d0 -1.4592646132527087d0
-1.328986835474931d0 -1.0671897833207358d0 -0.5397677311665405d0)

Best regards,
Sebastian Sturm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: minimization-issues.lisp
Type: application/octet-stream
Size: 5075 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/gsll-devel/attachments/20101008/a7996fc3/attachment.obj>