On 2/5/20 10:34 AM, Martin Liška wrote:
On 2/5/20 7:21 AM, Nicholas Krause wrote:
Greetings Martin,
I won't be applied but it was good to see you at least got some
possible ideas out of
my research from the make parts. Two questions as related to GSoC, in
terms of
long term planning for my work:
Hello.
1. *Implement something similar to Clang's/-ftime-trace/*is in my
view the most important project
for GCC multi-threading as having a real profiler in gcc proper is
the biggest bottleneck.
Here I would definitely recommend perf which can identify bottleneck,
as well as locking issues
and so on.
Perf is fine but because of the complexity of GCC it does not need great
data outside
of how much time times take and even them its not great. Basically I've
only found
out that functions and certain core data structures are used. Its a
little hard to explain
but its a issue that the GSoC student from last semester was/is running
into as well.
Basically more fine grained internal data is required then perf seems
able to give.
One example is figuring out the size of SSA nodes to figure out the best
ideas in
terms of making the dominantor trees multi-threaded safe/aware. The
other would
be that it states the garbage collector is using only 5% of the time on
a machine
with over 100GB of ram. However it does not take into account all of the
functions
that interact with the garbage collector through GTY() in that percent.
Finding
shared state and having heuristics is a real thorn without it. Is the
goal just to support it as a
feature similar to Clang or is this intended to be a real profiler,
as it seems so?
My intention was to do the same what clang does. The format is quite
generic and can be easily
extended to support more.
That's fine and expected as long as we can extend it out. The bigger
concern was if we were
unable to.
2.*Create a general jobserver client/server library *If its planning
to be a library then your
probably hooking it into the frontends for C/C++. Not sure who the
maintainer for that is
but is he aware of the possible changes? It may be good to either
have him as another
mentor or someone to ask about the frontend parts unless you or
Martin Liska have
that knowledge.
No, first consumer of that should be LTO WPA which runs parallel LTO
LTRANS during linking.
I'm not targeting any hooking into FEs.
That's fine if you want to do LTO first. Didn't know that was the
intended first goal.
P.S. Please CC me next time if you speak about me ;)
Sorry about that and will do it the future,
Nick
Thanks,
Martin
Regards and good luck with GSoC,
Nick**
