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>