On Wed, Apr 9, 2008 at 10:13 PM, Zach <elzacho@gmail.com> wrote:
To tell you the truth, I never looked closely enough at views to figure what it would take to make them work. It may be trivial, or it may be impossible.
Yeah, I now believe my suspicions to be correct, at least as of a year and half ago. Maybe there have been some advances as CLISP seems to support the needed feature and I'd bet the C friendly ECL and GCL both do as well, still no idea on SBCL.
One thing to keep in mind is that I am rewriting what I call "data" (matrix, vectors, etc.) to use Tamas Papp's foreign-friendly arrays. On SBCL, this will mean that the CL array and the C array will be one and the same (no copying).
Hmmm... that sounds good, still not sure how Tamas' FFAs would work. I was preparing to suggest the *other* route that Tamas mentions on his page, basically using the GSL data structures thinly wrapped in a Lisp object (to tie it into the GC). I guess both have their pros and cons.
I'm not sure what that is, I guess I'll have to re-read his page. I do remember him mentioning another approach used by rif for blapack, and that is don't-copy-unless-necessary. I think my design will be the best of both worlds: on SBCL it will use the native array, but the usage is such that on non-SBCL platforms, there won't be any copying unless necessary. So chained foreign calculations will stay on the foreign side. This will be much like it is now with the #'cl-invalidate function that merely marks the CL copy to be bad but doesn't copy it back until #'data requests the data on the CL side.
BTW, I have one question, purely out of curiosity. Even if you use an FFA, GSL is going to expect data in the format the GSL developers designed, e.g.: 00 01 02 03 XX XX XX XX 10 11 12 13 XX XX XX XX 20 21 22 23 XX XX XX XX Which means that either the Lisp array will have extra junk to carry around, and hence new matrix operations will need to be defined, or some C side trickery must be performed to translate it, which is what we are trying to avoid, right? How do you deal with this (or plan to)?
I use the necessary GSL structures currently (see e.g. gsl-vector-c). These have a data pointer. Currently, that points to space allocated by GSL through the generic function #'alloc (which ultimately calls something like gsl_vector_alloc). The use of the GSL structure will continue, but FFA will assign the pointer to the C array. If using SBCL, that pointer will actually be to the Lisp data but it will work as the C array due to the foresight of the SBCL designers. (I'm assuming by "extra junk" here you mean the parts of the GSL structs that aren't the array itself.) Liam