Eli,
Thanks for the info. It's all useful and I put some trivial comments in-line
below.
Doug
* However, if you're doing a lot of work *inside* Scheme, then things
> can become very inefficient. For example, say that you want to loop
> over a floating point array and multiply all of the values by a
> given factor. What will happen in this case is: each time you read
> a value, you allocate a Scheme object for the fp number, multiplying
> that allocates a new one, then saving it copies the result back to
> the array, leaving the two allocated values to be GCed. (There are
> some JIT-level optimizations for fp numbers, I don't know if it can
> save one of these allocations in this case.)
My plan would be to do the work inside of Scheme - at least for now. It
would be interesting to see if there are some JIT optimizations planned for
the future that could help.
> * Another point to consider is huge arrays -- if you expect to have
> such arrays, then it might be better to do the allocation explicitly
> outside of the GC -- using `malloc' in 'raw mode. This will require
> registering finalizers to free them, but the benefits are:
> - You can have a huge array without worrying about the 3m GC that
> usually requires double the space that you're using.
> - Dealing with an external library that allocates an array becomes
> easy, since it's dealt with in the same way.
> - No issues with arrays moving around, for external code that keeps
> pointers to it. (I can imagine this being a real benefit if there
> are libraries that can use multiple cores and calling a callback
> function when the operation is done.)
Some applications would use large arrays.
> * Finally, it sounds like it might be more convenient to use the
> `cvector' representation from the foreign interface: this is very
> similar to the srfi-4 representation, except that the type is stored
> in the cvector rather than having a separate type for each kind of
> vector.
I'll look into it. I already wrote a typed-vector abstraction on top of SFRI
4 (and normal Scheme vectors), so that isn't an issue for now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20090813/63f3d780/attachment.html>