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

If you were careful to allocate these big blobs in special places,
could you use the address itself as a tag (I think that's what the
bebob collectors do) and avoid the extra boxing?

Robby

On Thu, Aug 13, 2009 at 10:24 PM, Doug
Williams<m.douglas.williams at gmail.com> wrote:
> 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.
>
>
>
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
>