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

My question shouldn't be taken to mean that garbage collection would
be avoided. It would be a way to avoid copying the floats in and out
of the (current) mzscheme representation.

Robby

On Thu, Aug 13, 2009 at 10:47 PM, Doug
Williams<m.douglas.williams at gmail.com> wrote:
> Unfortunately, the automatic garbage collection is important because of the
> shared structure - slices, transposes, reshapes, etc. share the content
> vector with the parent. They should never be circular, so a reference count
> method might work. But, it may not worth it.
>
> At some point we would have to do the boxing to get results to/from Scheme
> code.
>
> On Thu, Aug 13, 2009 at 9:35 PM, Robby Findler <robby at eecs.northwestern.edu>
> wrote:
>>
>> 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
>> >
>> >
>
>