New branch for STL Advisor

[Silvius Rus]

Benjamin Kosnik wrote:
> Hi Silvius Rus and Lixia Liu! Thanks for posting this, asking for
> advice, and being willing to help improve libstdc++!
>
>   
>> Goal:  Give performance improvement advice based on analysis of
>> dynamic STL usage.
>>     
>
> Your project sounds intriguing, and something that could potentially be
> useful for GNU C++ users. I look forward to seeing how your work
> progresses, and encourage you to start a gcc branch to house your work
> in progress. Progress can be evaluated at the next stage 1 window, to
> see if things are solid enough to merge in to the trunk.
>
>   

Thank you for the review and positive feedback.  We will create the 
branch immediately.

>> Method:  Instrumentation calls in libstdc++-v3/include/debug/*,
>> runtime support library in libstdc++-v3/libstladvisor, trace
>> analysis/report tool in libstdc++-v3/stladvisor.
>>     
>
> I would like to see a bit more detail on your methodology, and
> encourage you to immediately start working on user documentation and a
> test strategy before you get too far along with anything else.
>
> For documentation, you'll need something similar to:
>
> http://gcc.gnu.org/onlinedocs/libstdc++/manual/debug_mode.html
> http://gcc.gnu.org/onlinedocs/libstdc++/manual/parallel_mode.html
>
> In particular, design. The using bits seem pretty straightforward. It
> would be nice if you could provide some detail in terms of scope (what
> are the algorithms or data structures you intend to instrument),
> and how this fits into the existing debug mode functionality. Do you
> need the debug mode functionality, or are just piggy-backing off this
> existing structure? It seems to me like you might want to provide a
> third level of debug mode macro, in addition to the _GLIBCXX_DEBUG and
> _GLIBCXX_DEBUG_PEDANTIC, maybe something like _GLIBCXX_DEBUG_PROFILE.
> However, if this is not the way you wish to proceed, and the intention
> is to be separate from debug mode, I would suggest
> using a new directory hierarchy and naming convention, one that is more
> descriptive to what you are attempting than "advisor". Perhaps
> include/profile? _GLIBCXX_PROFILE? Etc etc. In any case, please explain
> a bit more as to how this relates to debug mode. 
>
>   

I would go for cleaner at this point, so we will develop a profile_mode 
at the same level as debug_mode and parallel_mode.

> How do you intend to test this functionality?
>
> Do you intend for this functionality to work on all, some, or most
> platforms? What are the portability concerns or issues? 
>
>   

As advised, we will start by documenting the design in more detail and 
send it out once it is ready for review.

>> There are other STL usage patterns that can be recognized and
>> reported to the application programmer.
>>     
>
> Again, scope. It would be great to provide an initial list so we know
> what is being attempted. Feel free to mark some of them as stretch
> goals, or things that will not be attempted immediately. 
>
>   

They will be included with the initial design document and will be sent 
for review shortly.

>> The effect of our instrumentation is a meaningful trace of the
>> behavior of containers, algorithms and iterators, and their
>> interaction.  This abstraction level is above what normal profiling
>> tools can offer.  If we used normal profiling tools, we would have to
>> reverse engineer the trace to get to this level of abstraction.  Let
>> me know if you want me to go into more detail.
>>     
>
> More detail, please.
>
>   

Will do.

>> Design
>> ======
>>
>> The usage model is intended to be similar to -fprofile-generate and 
>> -fprofile-use.
>>
>> 1. Compiler driver
>> Build with instrumentation: gcc -fstl-advisor=instrument:all foo.cc.  
>> The effect on the compiler is simply "|-D_GLIBCXX_DEBUG 
>> |-D_GLIBCXX_ADVISOR".  The effect on the linker is "-lstladvisor".
>>     
>
> Seems fine.
>
>   
>> Run program: ./a.out.
>>     
>
> OK.
>
>   
>> Produce advisory report: gcc -fstl-advisor=use:advise.
>>     
>
> What other valid input do you anticipate -fstl-advisor having?
>
>   

I hope that some of the profiling information could be picked up by the 
compiler.  This is not our immediate goal though, so for now I just want 
to leave the door open for it.

> best,
> benjamin
>   

To sum it up:  We will create the branch, write the design doc and send 
it for review ASAP.  Development will be separated from the debug mode.

Thank you,
Silvius