[plt-scheme] More PLT Scheme as an Alternative to Matlab

From: Doug Williams (m.douglas.williams at gmail.com)
Date: Thu Aug 13 23:24:34 EDT 2009

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>

Posted on the users mailing list.