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. <div class="gmail_quote">On Thu, Aug 13, 2009 at 9:35 PM, Robby Findler <<a href="mailto:robby@eecs.northwestern.edu">robby@eecs.northwestern.edu</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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 <div><div></div><div class="h5"> On Thu, Aug 13, 2009 at 10:24 PM, Doug Williams<<a href="mailto:m.douglas.williams@gmail.com">m.douglas.williams@gmail.com</a>> 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. > > > </div></div>> _________________________________________________ > For list-related administrative tasks: > <a href="http://list.cs.brown.edu/mailman/listinfo/plt-scheme" target="_blank">http://list.cs.brown.edu/mailman/listinfo/plt-scheme</a> > > </blockquote></div>