[Mono-devel-list] RAPGO Proposal
Willibald.Krenn at gmx.at
Wed Dec 1 10:23:07 EST 2004
Paolo Molaro schrieb:
> On 11/29/04 Willibald Krenn wrote:
>>Paolo Molaro schrieb:
>>>Described in the summit notes: the code is not in cvs yet.
>>Any idea when this code will hit cvs? (I was aware of the notes, but
>>that doesn't show me how it is done, etc. ..)
> As soon as it's ready.
Ok - standard answer. Could you possibly post a small message on this
list, when you've checked it in? Would be very much appreciated... Thanks.
> A lot, note you'll need atomic counters to be thread safe etc.
Yes, that's the crux. On non-smp machines it would be marvellous if
there were some process-shared register set, so you'd just have to
inc/dec one register.. :-)
> Well, there are two ways to deal with branches here:
> *) sampling the ip will find that the basic blocks executed will have samples
> (or many more samples), while the not taken branch will end up in basic blocks
> that don't have or have few hits.
Yes, but you need to be careful in choosing the sampling frq. (AFAIK it
should also be kinda random, to improve measurements) in order to narrow
the error-margin and get usable results.
Plus: Too much sampling data will slow down calculations too, so some
careful design has to be made here.
I'd prefer to instrument one method at once for optimizations like
this.. (But that's just a feeling, of course I can be wrong)
> *) using the performance counters in modern processors may provide the info
I'll look into this a bit more, but AFAIK performance counters are
somewhat limited (in size and number) and you need a patched Linux
kernel in order to get process-only perfctrs. (There are some other
issues as well, IIRC; privileged instructions?)
At last you get unwanted side-effects with other profilers when using
perfctrs for your own measurements if the kernel doesn't know how to
'share' these counters.
BTW: For interrup-on-overflow you certainly need a kernel module.
> As for access patterns, the second solution may help as well. I agree
> for some things some embedded code may need to be emitted: it's just that
> in general I think we should avoid it.
I guess it's like in economy: Only if the possible achievable benefit
outreaches the investment, it should be considered to be done at all.
(And perhaps only one method per thread at once, or so)
BTW, there is people who did already
> that sort of optimization with mono (optimizing the code based on the
> access patterns to arrays): I don't know if the paper has been already
> published, though.
That's news to me.. Any idea of the title/who did it?
>>AFAIK the peephole optimizer works on a small set of opcodes. So adding
>>a peephole pass would still be possible.. But of course you end up
>>having a small memory buffer for it and touching each opcode twice again..
> Yes, and thus make the code unreadable and unmaintainable which we don't
> want to do.
Mono already has enough code like this in it's code base...
(e.g. Macros that implicitely assume to be placed in some special block
of code, field names that have misleading names, files that are stuffed
up with all sorts of functions, directories cluttered with files that
belong to different libraries...)
> The 'basic set' as you call it is:
> $ ls -s /usr/lib/libstdc++.so.5.0.7
> 728 /usr/lib/libstdc++.so.5.0.7
> That's in kilobytes.
Well, on desktop computers that doesn't do much. (And as it's on disk in
any case on these machines, only free-RAM would 'suffer'.)
> It also forces mono to depend on the C++ ABI, so it breaks each time
> the C++ ABI changes. So it's a lot of baggage for very little benefit.
As I know habits of Linux developers a little bit by now, I would say
that's a very valid point. :-)
>>Doesn't like that, but'll stick to it.
> Note: if you prefer writing the code in C++ for your thesis it's fine,
> it's just that we can't add it to the main tree.
That would not be very constructive, would it? No, I'll do some sort of
objective C. Virtual methods are gonna be fun:
#define NonPolyMethodCall(c,a,b, ...) c##b (a, ##__VA_ARGS__)
#define AnObjectMethodCall(a,b, ...) NonPolyMethodCall(AnObject_,a,b,
#define VirtualMethodCall(a,b, ...) ((a)->b)(a, ##__VA_ARGS__)
Would that be ok?
More information about the Mono-devel-list