[Mono-devel-list] RAPGO Proposal

[Willibald Krenn]

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
> directly

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.

Yea :->
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, 
##__VA_ARGS__)
#define VirtualMethodCall(a,b, ...) ((a)->b)(a, ##__VA_ARGS__)

VirtualMethodCall(pMyObject,AMethod,params);
calls: (pMyObject->AMethod)(pMyObject,params);

AnObjectMethodCall(pMyObject,AnotherMethod,params);
calls: AnObject_AnotherMethod(pMyObject,params);


Would that be ok?


Thanks,
   Willi