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
