[Mono-dev] Generic sharing: Good news, bad news, how to win big

[Rodrigo Kumpera]

Hey Mark,

On Mon, Apr 14, 2008 at 11:58 AM, Mark Probst <mark.probst at gmail.com> wrote:

> Hey Rodrigo!
>
> Thanks for the feedback!
>
> > Isn't possible or better to do RGCTX free'ing at GC time? It would be
> > simpler, the hardest
> > part would be guarding against parking threads inside RGCTX related
> code,
> > which can be done with
> >  some link time trickery and a lit of changes on stack scanning code.
>
> I'm not sure it would be simpler (to be honest I don't know how much
> work it would involve), plus it would involve the MonoObject overhead
> which is 8/16 bytes per RGCTX.
>

We don't need to add the MonoObject header. The idea is to use the fact that
all threads are stopped to collect unused rgctx. This would not need hazard
pointers
or any free code on the filling code. Since lookup is always done from a
trampoline
it would be a matter of stack scanning for it to map which free rgctx's
cannot be freed.

Anyway, this would only make sense if freeing is something that happens
enough to
justify the extra work.


>
> > In Madrid we discussed about using segfaults to trigger lazy filling of
> > rgctx, have you thought about using that?
>
> Not seriously.  My first concern was getting everything to work
> correctly, which it now does.  I'll concentrate on saving memory next,
> so that sharing generic code actually makes sense.  Performance was
> never an issue in my tests.
>
> > I remember that a major issue with the rgctx layout was that you need to
> > coordinate slot filling between a type and all it's parents to avoid
> > collisions. How would that work on your proposed schema?
>
> I would still do the bookkeeping for collision avoidance and then use
> the resulting slot number to uniquely identify the type information.
> Just think of it as a sparse array.
>
> > How about using a
> > pointer to the parent context? This would eliminate the whole issue,
> could
> > save some bytes for parents with fat rgctx and make even less likely to
> have
> > a large rgctx.
>
> No, that doesn't work in the general case, because the type arguments
> of the parent class might be different:
>
> class B<T> : C<X<T>>
>
> It would probably work in the special case where they are the same,
> but I don't know if it's worth to do that kind of optimization,
> especially since it makes the lookup code more complicated.  I'd like
> to keep the lookup code for the small RGCTX small so that we can do it
> in managed code (not inline, but in a trampoline).
>

I was thinking more about collections. Do interfaces have a rgctx too? It
could
make difference for IEnumerable<>, IComparable<> and similar; if it's the
case.

For super type only it would not make such a difference for
System.Collections.Generic that
have a very shallow inheritance tree. Mono.C5, on the other hand, uses a
deep tree.


>
> > One more thing, your stats miss something I guess it's important, how
> many
> > generic sharing failures each test suite has? This is important to see
> how
> > much further this could be improved if constrained and mixed
> > reference/valuetype sharing gets done.
>
> Yes, I don't have those stats yet, but they're on my TODO list.
>
> > It might too early to think about this, but do you have some speed
> results
> > for these tests?
>
> Yes.  At least on x86 there is no noticable speed difference between
> sharing and not sharing.  I also did mini-benchmarks for List`1 and
> Dictionary`2 and there was no speed difference either, in runs that
> lasted about 30 seconds.
>

I expected that for F# sharing would have saved some overall time since JIT
activity is a lot smaller.

By the way, talking about the F# case, generic sharing compiles 27% less
methods, but only reduces
the compiled code size by 6%. These numbers seen odd to me. Is generic code
really that
smaller than non-generic or is the added code for sharing support that
result on these numbers?

Rodrigo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20080414/6779faff/attachment.html