On Fri, 2009-05-08 at 19:52 +0000, Tamas K Papp wrote:
On Thu, 07 May 2009 09:48:08 +0200, Stelian Ionescu wrote:
On Thu, 2009-05-07 at 11:00 +0900, John Fremlin wrote:
Stelian Ionescu stelian.ionescu-zeus@poste.it writes:
Attached is an implementation for SBCL. make-static-vector only allocates instances of (simple-array (unsigned-byte 8) (*)) but that can be extended to other unboxed arrays. The current sharable vector interface doesn't work very well because it doesn't allow me for instance to pin a list of vectors, but only a single vector at a time. Also, I'd prefer to avoid pinning at all given how it interferes with the GC.
Thanks Stelian!
This would be really useful as the pinning business with shareable-byte-vectors is a real nuisance.
If the current shareable-byte-vector interface is going to be reworked can I suggest that we allow (at least) simple-array single-float/double-float as well? Why not just allow all unboxed array
That can be easily done.
types the underlying Lisp supports? . . . Or a limited sensible subset?
I think that we should allow all types supported by the underlying implementation but specify in the docs that very few are portable: (probably, I haven't yet checked) only bit, [un]signed-byte-{8,16,32,64} and single-float are portable
Having portable unboxed C-sharable float arrays would be great for our numeric work.
Now we only need to see if the trick of "manually" creating unboxed arrays works on other implementations: CMUCL, CCL, Clisp, ECL, ... Allegro and Lispworks already support this with make-array's :ALLOCATION key arg
I should be very happy to make the Allegro CL interface.
Thanks. See if Allegro has native functions for bit-bashing, otherwise implement {fill,copy}-foreign-memory in terms of memset/memcpy.
Thanks Stefan,
Very neat work. This would indeed help a lot with numeric work.
Question: is the need to manually free the object a must? Could we perhaps have an argument to make-static-vector that tells it to register a finalizer when needed?
Yes. Given that SBCL has a conservative GC on x86 and x86_64 you have no guarantee that a finalizer will ever be executed. Also, I'm not sure how it would interact with the fact that the entire array(contents and header) is allocated in foreign memory. It's better not to risk and if some day we'll be sure that it's unnecessary on all implementations, we could safely deprecate free-static-vector and use finalizers.