Re: Concerning shared flag

In my patch, you'll notice that there is no "capa" field. 
Instead I used 2 flag bits.  One to indicate that there is free
space to the right of the array (>=ptr+len) and one to indicate
there is space to the left of the array (<ptr).  I put the what
the exact number of free entries is in ptr[len] (for space to
the right) and ptr[-1] (for space to the left).  I can do this
since this would be normally don't care.  This allows
shift/unshift to be symmetrical with pop/push and random
inserts/deletes to operate toward the closest side (double
performance).  It also frees up "shared" for dedicated use so
that I could fix up the performance issues with sharing.

--- Christophe Poucet <[e-mail]> wrote:

> I have taken a different approach that works without changing
> the ruby
> interpreter although I'm not happy with the implementation as
> I have to add
> an extra VALUE field.
> 
> struct RVarArrayData {
>   long len;
>   long capa;
>   VALUE shared;
>   VARVALUE * ptr;
> };
> 
> If shared != Qnil then it is a shared one, otherwise it's not
> shared.  Had I
> been able to use the flag then the overhead would drop by 4
> bytes per object
> (given that shared and capa would then be in a union).  For
> the rest I keep
> the original sharing logic.  And then I will look at your
> patch and use this
> patch for vararray as well.
> 
> With regards to the gc being more generalized, one nice thing
> would be that
> it would no longer need to be specialized for Array and
> String instead just
> treat these like T_DATA (of course with the current
> implementation of Tdata
> this would mean that you'd have an extra pointer access, but
> I'm sure this
> is a separate problem that could be handled as well.)
> 
> With regards,
> Christophe
> 
> -----Original Message-----
> From: Eric Mahurin [mailto:[e-mail]] 
> Sent: Wednesday, October 05, 2005 6:03 PM
> To: [e-mail]
> Subject: Re: Concerning shared flag
> 
> Not sure if you are aware or not, there are some serious
> performance (run-time and memory) issues with element sharing
> in the current ruby.  Try any method that takes a small slice
> of a large array and then later (even after the small slice
> is
> GCed) modify the large array.  The modify will cause a copy
> of
> the large array and the small slice will continue to
> reference
> the original large array.  You can see how this could cause
> serious run-time and memory penalties.
> 
> I've done a patch to fix this plus do other speedups.  See
> the
> thread "another array patch - massive performance boosts".
> 
> I'd suggest you not do element sharing in your custom class
> until this is resolved.
> 
> I agree that it would be nice if the GC was more generalized
> to
> let the class handle these special cases (element sharing)
> instead of embedding this code in gc.c.
> 
> --- Christophe Poucet <[e-mail]> wrote:
> 
> > Hello,
> > 
> > I'm trying to build an object that behaves just like Array
> in
> > c. However
> > there seems to be one stumbling block. I looked at the
> > garbage collector and
> > there is no special case in T_DATA in case an object has
> the
> > flag shared. I
> > think there should be two different marking functions in
> case
> > an object has
> > the set and in the case it does not. That way I could
> design
> > something like
> > this:
> > struct RVarArrayData {
> > long len;
> > union {
> > long capa;
> > VALUE shared;
> > } aux;
> > VARVALUE * ptr;
> > };
> > 
> > However at the moment this is not a possibility.
> > 
> > With regards,
> > Christophe
> > 
> 
> 
> 
> 		
> __________________________________ 
> Yahoo! Mail - PC Magazine Editors' Choice 2005 
> http://mail.yahoo.com
> 
> 
> 



		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com