[Mono-devel-list] RAPGO Proposal

[Paolo Molaro]

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.

> Don't think so (some wrapper around the method to do the countings for 
> should be sufficient - along some modifications in ...throw), but I 
> agree that counting decreases runtime performance. (Although I've no 
> clue by what order of magnitude)

A lot, note you'll need atomic counters to be thread safe etc.

> Depends on what you want to do. More expensive optimizations may also 
> need other information than call-graph and invocation %.
> 
> I'm thinking of branches (taken,not taken), memory access patterns and 

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.
*) using the performance counters in modern processors may provide the info
directly

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

> I meant the initial codegen would be faster. Later on the emitted code 

The peephole and memcpy pass is very fast, there is no point in avoiding 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.
 
> course I wasn't talking about bells and whistles C++, just the basic 
> set: objects and possibly exceptions. And of course none of all this in 

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

> >Anyway, no C++ code in the runtime.
> >Thanks.
> 
> 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.

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better