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

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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20090813/b216eca5/attachment.html>