Eli,<br><br>Thanks for the info. It&#39;s all useful and I put some trivial comments in-line below.<br><br>Doug<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
* However, if you&#39;re doing a lot of work *inside* Scheme, then things<br>
can become very inefficient. For example, say that you want to loop<br>
over a floating point array and multiply all of the values by a<br>
given factor. What will happen in this case is: each time you read<br>
a value, you allocate a Scheme object for the fp number, multiplying<br>
that allocates a new one, then saving it copies the result back to<br>
the array, leaving the two allocated values to be GCed. (There are<br>
some JIT-level optimizations for fp numbers, I don&#39;t know if it can<br>
save one of these allocations in this case.)</blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">* Another point to consider is huge arrays -- if you expect to have<br>
such arrays, then it might be better to do the allocation explicitly<br>
outside of the GC -- using `malloc&#39; in &#39;raw mode. This will require<br>
registering finalizers to free them, but the benefits are:<br>
- You can have a huge array without worrying about the 3m GC that<br>
usually requires double the space that you&#39;re using.<br>
- Dealing with an external library that allocates an array becomes<br>
easy, since it&#39;s dealt with in the same way.<br>
- No issues with arrays moving around, for external code that keeps<br>
pointers to it. (I can imagine this being a real benefit if there<br>
are libraries that can use multiple cores and calling a callback<br>
function when the operation is done.)</blockquote><div><br>Some applications would use large arrays.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

* Finally, it sounds like it might be more convenient to use the<br>
`cvector&#39; representation from the foreign interface: this is very<br>
similar to the srfi-4 representation, except that the type is stored<br>
in the cvector rather than having a separate type for each kind of<br>
vector.</blockquote><div><br>I&#39;ll look into it. I already wrote a typed-vector abstraction on top of SFRI 4 (and normal Scheme vectors), so that isn&#39;t an issue for now.<br> <br></div>
</div><br>