[Music]
hello everyone and welcome back to the
gear order theater at linux confer you
2022. uh our next speaker is uh rude who
is a distinguished
engineer in the oracle linux and
virtualization organization at oracle
corporation where he works in the tools
team in this talk he's presenting an
overview of g for fng which is a next
generation profiling tool for linux uh
he is awake and here as you can see and
available to answer questions in chat
throughout the talk and at the end if
there is more to talk about but here is
the video
welcome to this presentation about
g-profangie the next generation gnu
profiling tool my name is root from the
pass and this is joint work with
vladimir zensef i will be presenting
today
we both work in the oracle linux
engineering and virtualization
organization and within that we're part
of the compilers and tool chain team and
both of us are deeply involved with g
profinji
and in this presentation would like to
show you what this tool is about so
after a brief introduction into into the
tool i want to show as many examples as
possible i'd like to show you how you
can use this tool to identify
bottlenecks in your application
so the examples are all result driven i
want to show you the kind of information
you can get i won't have a lot of time
to go into the details behind it but
again i want to show you the complete
overview of what you can do
with this tool
for those of you that like to learn more
we have a public repo and within that
there's a mini tutorial in tech info
format
at the end of this presentation i'd like
to say a couple of things about where we
would like to take this tool from here
for the outside world it all started at
august on august 11 2021 when we
submitted our code for review to the bin
utils community
we have been working on it for quite a
while of course but that was the the
time the first time that we went public
and asked for inclusion into bin utils
if you'd like those emails are all
archived you can you can check the
postings and you can check the
discussions that that followed
and to our great pleasure
on december 13 2021
um our software was in approved for
inclusion in into the bin neutrals
collection so in a future release you
will have
you will have this tool but again
there's already a repo you can download
and install the software today if you'd
like to do so
a little bit of history about g profinji
but i'll keep it really brief just to
put things into perspective
it all started with the oracle developer
studio performance analyzer and that was
a performance analysis tool that was
developed for over 20 years
in those years many internal and
external users have been using this tool
and often with pretty ugly real world
applications
the focus was on the spark processor
studio compilers and solar operating
system but there has been a linux
version an x86 linux version for over 10
years so we took this sourcetree as the
basis for g profinji
and we did a lot of work on it first of
all we created the standalone version on
linux so you can just install this this
profiling tool you don't need to install
all of the studio anymore it's a
standalone repo now
part of bin new tilts of course but
again we took it out of the studio
environment
we adapted the code to the to adhere to
the new coding standards
we changed the build process so that
it's compliant with the other bin
neutrals components
and we added a first port to arm so we
have support for i'm now very excited
about that
uh we also fixed several bugs and we
completely redesigned the user interface
so for those of you that are familiar
with the studio product uh you will find
similar things but certainly the the ui
has been completely changed
so what is g proven g
it it's a tool that collects and
displays application level performance
data that's what it does it's meant to
profile your application and we support
the following languages c c plus java
and scala
we do have full support for the gcc
compilers and we support various
processors from intel amd and arm
and
you can just you can use
user tool to profile on those processors
one of the key features of this tool is
that there's no need to recompile the
code you can
profile the binary as is and i will
demonstrate that both on the slides and
in the live demo
we also have full support for
multi-threading
applications parallelized to either with
posix threads openmp or java threads
they can all be profiled and as i will
show as well there's no need to do
anything different in the tool the tool
will automatically adapt to a
multi-threading environment
so how does it all work
well it's a it's a two-step approach
step one we collect the performance data
on the target executable you define the
job you run you're going to run it and
you run it under control of our tool and
while it's running it will collect the
data and in the next step you start
looking at the data you display the data
and do your analysis
and in in that analysis phase there's
information available at the function
source and disassembly level and we have
quite quite a number of views into the
data and in my experience what it means
is that already a single run can provide
a lot of insight
one of the things that makes life easier
certainly for me but i'm sure for other
people as well is scripting support
so in a completely automated way you can
generate your profiles and you can get
the information on your screen i use
that all the time
we also have filters so you can zoom in
on the area of interest
and that's very helpful too
and another really nice feature that we
have i think is really nice is
comparison of profiles when you think
about it profiling is about comparing
you have a good good run and you have a
bad run that's all of a sudden is slower
or you're looking at some performance
regression in a multi-threaded
application
you want to look at the good case versus
the bad case and see what's different
and we support that at the tool level so
you can compare profiles and and again
for that i have an example as well
a little bit of a comparison with g prof
um as sort of suggested by the name
we'd like to see this as the next
version of gproff in a way although
architecturally things are very very
different we hope that those people
using gproff today will switch over to
dprofing although both of them will
continue to exist
first of all gproff uses tracing
instrumentation you have to recompile
your code the compiler will insert
library calls to collect the data
we don't need that we use the sampling
so what we do we take the binary and and
we we run it as is and meanwhile we'll
sample the data and i'll have a slide on
that to explain that a little in a
little bit more detail
so with gproff you need to have access
to the source code you need to recompile
the code you don't have to do that in
our case you can essentially profile any
sort of binary
gproff has somewhat fallen behind in
terms of support for modern features and
weak pretty much up to speed for example
we support
profiling of shared libraries and
multi-threaded applications
gprov also has limited customization i
think while we have for example the
scripting commands and we have lots of
options to really tailor the environment
tailor what you want to profile
gprof does not have filters we have them
and once you get the hang of it you'll
find that they're very very powerful
very helpful
another big thing is is that you can't
compare profiles with gproff while we
can do that
and gproff does not have support for
event counters while we support event
counters so for example you can
you can monitor cache misses now to be
honest that's the footnote here
we're not up to speed on the most recent
processors we're working on that that's
work in progress but you can definitely
for a whole range of processors access
the event counters
so i now want to show you a little bit
what goes on under the hood it is a
simplification but hopefully it will
give you feel and help you understand
how we can do this
with your code without asking you to
recompile
the application
you run your program under control of
our tool and what we do at certain
intervals and by default and that's 10
milliseconds we stop the program when we
stop the program we record information
of interest things we'd like to know we
let go again and again by default 10
milliseconds later we stop it again
that sampling interval is by the way
that's one of the options you can you
can choose you can change it you can you
can put it to a longer sampling rate or
a shorter sampling rate depending on
your needs
so when the program is finished we have
an overview of where the time was spent
and that's the one of the things that we
we will show to you
of the things to be aware of and you may
ask yourself with sampling it's
statistical sampling if you run exactly
the same job again the numbers
will be slightly different but in my
experience the
deviation is really really small you can
just ignore it
this works really well in practice
so here's the command structure
all the commands start with g prof and g
so we make them unique in that way so
they start with g profit g then there's
some functionality whatever you want to
do
optionally a qualifier to further
specify what you want to do and
optionally options to that qualifier to
customize the behavior that's typically
how you use it
so examples are to collect performance
information you you do gproff and g
collect app to display the information
you do gprofng display text
we also have an archiving feature and
you just call it archive because we
don't need anything else at that level
so these are examples of the ui
we have
five commands currently supported
as i've just shown collect the
application level performance data
collect app
display the performance data in ascii
format
we can archive an experiment directory
so what we do we sort of package the
environment and that includes a shared
libraries your source code if you like
you can sort of customize that but we
sort of freeze make a snapshot of the
entire environment so you can always go
back and analyze that environment just
in case libraries on your system have
changed so
so you can completely archive an
experiment and
i wouldn't say replay but analyze the
data later even things even if things
have changed on your system
we have a simple tool it's currently
quite simple it displays the source and
disassembly interleaved and you give it
an object file that will show it
our plan is in the future that it will
show you more more information about
what the compiler has been doing to your
code so
uh maybe show you optimization messages
for example
a tool that's in progress and currently
doesn't do much is called display html
it it generates an html structure and it
allows you to analyze the performance
data in a browser and we're working hard
to finish that and have that available
relatively soon so that's called display
html
i now want to briefly talk about
two important concepts they're called
inclusive and exclusive metrics they're
not restricted to g profit ng it's part
of the sort of the profiling terminology
but i would like to explain them here
you'll also see them in the examples
a metric is something that you measure
that could be
cpu time
level one cache misses
number of branches branch instructions
executed whatever
so that's a metric when we look at the
inclusive value we include everything
underneath the caller so you have a
certain point in your call tree and you
count everything below that
so for example if it's the cpu time it
will give you the total time of that
function including calling other
functions
the opposite sort of metric is the
exclusive metric where we exclude
everything outside of the caller so
that's like the pure time or pure number
of cache misses you spent in that
function outside of calling order
functions
and both metrics have their value and
you can get them very easily with
gprofan g and i will show that here's a
little example
this is part of my call tree and these
are
in total five functions and i'm showing
the exclusive time here of what they
what they spend
and if i would make a table this is what
i would get so the orange function let's
call it function a
it's exclusive time is 10 that's the
number in the box but it's calling those
other functions and when you add up the
numbers you'll see that the total time
is 75 seconds
b is the gray one let's call it b
is what we call a leave function it's
not calling anything else the inclusive
and exclusive times are the same in both
case 20 seconds the same is true for the
for the pink one
function d
c is different that's the light blue one
c is calling something else
function e
so it's
exclusive time is five seconds but it's
calling something that takes 25 seconds
so the inclusive time of that one is 30.
and again in this way you can you can
navigate through the data the inclusive
time for example gives you the most
expensive path in your program and the
exclusive time will tell you how much
that particular function contributes to
that total
let's hide him for a demo i think i'd
like to show you a brief just few minute
demo how you use this tool and actually
i want to show you how easy it is to get
a basic profile on your screen so let's
get started and let's have the demo
and i want to show you how you can make
a profile for your own application using
g profinji my application is a simple
matrix vector algorithm parallelized
with basic threads and the way i run it
is i specify the matrix sizes the number
of rows and columns and the number of
threads that i want to use which is two
in this case
so the program runs as usual it ran to
completion all as well the question is
how do you make a profile out of that
well it's really easy
you run the program as before same
environment variable same settings
nothing changes the only thing you do is
you're going to run it under control of
gprofan g
you tell it what you want to do in this
case i want to collect performance
information on my application so gprofan
g collect app and then the way you run
your program
when you do that you'll see an extra
line creating experiment directory
test.one.er and a process id
the
test.one.er that's a regular linux
directory that has the internal
information for gprofng to to show you
the performance data
and that's clearly a default name if you
would run this again you would guess get
a test.2.er test.3 and so forth
and of course you can change that name
if you if you want by default we never
overwrite an experiment directory so
we'll keep on numbering but again you
can use your own own name for the
directory and that's what you use in
practice to give it a more meaningful
name
in any case we have our test.one.er and
now we can start doing the analysis so
we start graphing g again but this time
i want to display the information i want
to do so in ascii or text format and i
want to analyze the information in that
directory
and here's how you do that
now what happens when i use it the
command this way i get into an
interpreter mode in interactive mode i
can give commands
and i can sort of navigate my way but to
be honest i never use it this way so
i'll get out of that because the way i
like to use it and i would sort of
recommend you do with that as well is
you give the commands at the command
line
as you invoke g profanji so here what
i'm doing is i'm asking for the function
information i want to get the function
overview for that experiment and that's
how you do it
and this is what i get on my screen
and what we see we see that
the two columns the exclusive and
inclusive total cpu time with their
respective values and the name of the
function
the first line is
requires a little bit of explanation
that's called total you will always see
it
and that's generated by g profit g that
has the total value for that metric in
this case the total cpu time so what it
tells us that the total job took 1.691
seconds
and out of that
1.611 so pretty much almost everything
was taken by a function called mxv core
so if we ever want to do some
optimization mxv underscore core is the
one to to look at
so that's a very basic
but useful profile and
the steps i've been showing you are
really all that is needed to get it you
first you collect the performance
information using gprofanzcollect app
and then you display the information
using g preference e display text
and that's all that it takes
now there's a lot more to say about this
and there's a lot more information that
you can get out of even this simple
test.one.er directory and for that i'll
switch back to the slides and i'll show
you lots of examples of all the kinds of
information you can get so let's go back
to the slides now
well i hope you found the demo uh useful
i now want to show you some more
examples on the slides i just wanna
these um this is this is kind of showing
you all the kind of things you can do
but actually there's even more i don't
have time to cover that but these are
some of the most common things that you
may be interested in
so i want to show you how to get a basic
profile you just saw it in the demo but
i wanted to again cover that on the
slide because that's the very first step
that you need to do then you start
displaying the information at the
function source disassembly level you
can customize the data collection and
the displays i want to show you the
scripting i want to show the kind of
things you can do with a multi-threaded
application and i want to show you an
example of comparing profiles
you've just seen this in the demo but
let me let me just repeat it
if this is how you normally run your
program which is is the matrix vector
multiplication parallelized with posix
threads all you need to do to get your
profile is run your program
as before but under control of the
gprofng collect app command
so that starts collecting the the
application level performance data
and as you saw in the demo it will
create an experiment directory
um
i've talked about the naming there and
we see here clearly we did not have any
experiment before we did not specify the
experiment name so the default name is
test.1.er
and that will contain our performance
information
so the next step is to start analyzing
that information and although i i will
show
these commands um in a separate way you
can of course combine them on a command
line and get all that information with
one command you don't have to do those
individual
typing of these individual commands you
can concatenate those
those options in a way i just want to
say that because otherwise you you yeah
you may find it
inconvenient
so let's say i want to get a basic
function overview and all i need to do
is add the functions option it's
actually a command
to the gpro display text tool and i feed
it to the name of the experiment
directory test.1 or dr and this is what
i get on my screen again you've seen it
in the demo i just want to repeat it
here and i also want to mention again
this function called total that that is
created by the uh the gproff and g tool
and that's the total time or the total
metric i should say if it's cash misses
it will show you the total number of
misses so that's an artificially
generated function it's always on the
top because it includes everything
so that that gives the whole measurement
a reference so we can see what the total
time is in this case we see the
inclusive and exclusive times and we see
the distribution over the various parts
of the program
another kind of nice little feature is
the lines option that will show you the
what we call hot lines those are the
most time consuming lines so you can
very quickly see where is your time
spent and what we see in this case that
the two top lines are in mxv core line
36 and somewhat in line 37 but clearly
line 36 in file mxv dot c
is a very
very important one for the performance
usually as soon as you've seen the
functions and maybe you've used the
lines command to to tell you where the
time is spent at the source line level
you usually want to look at the source
and you use the source option for that
and i'm going to specify source and then
i need to specify my target function
which is in this case mxv core so that's
uh that's where i want to see the source
for
and that's what i get so i get the
source code
and it's it has the timings in the
the leftmost columns
and um to make life a little easier we
mark the most expensive one with the
double hash symbol the color coding is
mine by the way the red coloring that's
on your terminal will all be the same
color
but um what it what it shows is where
we're spending the time and those are
those two lines 36 and 37 we've already
seen
uh with the lines overview
so that's how easy it is to identify
where in the source are you spending a
lot of the time
you can go deeper you can go down to the
disassembly instruction level
that's sometimes very helpful because it
may not be clear when looking at the
source where the time is spent so i'd
like to do that and you get the same
information but now at the instruction
level and again i color coded the most
interesting part red
the tool won't do that for you
but you will see the marker the double
hash symbol and you can search for that
and find out where most of the time is
spent and now at the instruction level
so you can see which instructions are
the most expensive ones
i mentioned customization a couple of
times you have different ways to
customize the information for example on
the display text command
you can limit the number of functions
you want to see in this case and do a
limit five and you can define the
metrics you want to see
we were showing the the function name
the inclusive and exclusive times but i
want to do it a little bit different
what i want to show is i want to show
the name of the function followed by the
exclusive time that's the e
i want to see the time that's the dot
and i want to see a percentage i didn't
show that so far so what i want to look
at is the
both the times and and the percentage
distribution and that's what i need to
uh to do to get it
and this is what i see i see that that
function mxv core is taking 95 percent
of the time so it's by far dominating
the entire
uh run
typing those things in gets starts to
get tedious so what you really uh and
probably end up doing is like what i do
i put those commands in the script it
also serves as a nice way to document
how you got your profile
we accept the hash line starting with
the hash as as comments so you can add
comments if you like as i'm showing here
and the first blue line i defined the
matrix to be the name
followed by the inclusive
total cpu time as a number and a
percentage and the same for the
exclusive as a number and a percentage
i want to sort the timings
relative to the total exclusive total
cpu time it's one of those things you
can you can select
uh i only want to see five lines just in
case just for the demonstration purposes
and i want to see the function overview
so with that that
that script
i feed that into the display text using
the script option i specify that file
and then i got an information
information like this so now i got two
tables inclusive and exclusive
and what has been added are the
percentages
so now you can immediately see that the
second most expensive function is called
init data and inclusive time is 4.5
so it doesn't contribute much but it's
the second most expensive function in my
program
you can customize the data collection
part i just show a simple example here i
already sort of alluded to it you can
you can give the experiment a more
meaningful name
we have a lowercase option and an
uppercase
o option
the lowercase o option will not
overwrite an existing experiment the
capital o option will overwrite the
existing experiment i like that a lot
but if you want to be cautious and not
override existing experiments you can
use the lower case so in this way i can
give the experiment any sort of
meaningful name or whatever name i like
there's more things you can customize
you can set sampling granularity you can
add labels to the experiment like
comments and they'll be shown by the
tools so you can do some sort of simple
form of documenting your experiment i
already mentioned you can archive
including sources objects and so forth
in the experiment and package the whole
thing up support for multi-threading
there's nothing you need to to change
you run your multi-threaded code as
before in this case the only change is
i'm running my matrix vector code
and i i use the dash capital o to give
the experiment a somewhat meaningful
name
and i use the t2 option to request two
threads
so i run it as before again under
control of gproff ng collect
and
i can then start analyzing that data and
for example here i'm i'm playing a bit
with the metrics i change the metrics
but i also want to highlight the threats
command that will give me information
across the threads what is showing me is
the metric values that are requested
for all threads and in this case i'm
looking at the total cpu time and that's
a great way to find a load imbalance in
your multi-threaded application
for example here and this is again a
very simple example we see that uh
threat number two and three they both
take about one second about 47 percent
of the time
but threat number one hardly takes any
time it's five percent of the total
and that's by design that's like the
control thread it's in charge of
executing the program but it will not do
any of the computations so it's mostly
doing the administrative work behind the
scenes to make things happen so this is
perfectly understandable but i wanted to
show it to you that this is a really
good way to find load balance issues in
an application
as before you can put things into a into
a file and your commands and here i'm
showing you the filtering
so the red commands select a certain
thread it doesn't have to be one it can
be a range of threads it can be any sort
of arbitrary combination but one what i
want to show here is that for each
thread i want to see the function
profile i don't want to see the
accumulated profile as i was just
showing i want to show it for each
function on an individual basis so i
want to see it with that one two and
three and here's what here's what
happens
i i got the information for thread
number one
and that's confirmed in the the part
that i color-coded red out of the three
i'm selecting thread number one and it
shows me where the time is spent
and likewise you can do the same for
thread number two and number three and
again that will that will tell you on a
thread by thread basis where the time is
spent and that can really help that in
combination with the load balancing
information can really help you to
quickly find out why is that thread so
slow why is it much lower than the other
ones
i i said it several times i
i'm really happy with our comparison of
profiles feature and i now want to show
you a simple example
i'm also using the hardware event
counter support with the dash h option
as shown in this dotted box
and i want to look at last level cache
misses llm
so i'm asking the tool
show me the last level cache misses and
i want to do that for one and two
threads
so now i have two profiles one for one
thread one for two threads and i'd like
to compare
well how do i do that well
again i put things in a script as i
always do and that script is pretty
simple i limit the output to five lines
i only want to look at the the last
level misses and i enable comparison on
so i want to compare
the numbers and that will give me the
table that is shown here
so now for both experiments i get the
values
and you can you can side by side compare
them
so that's very very useful but
on purpose i pick this experiment
because you can also see the numbers are
very large and sometimes it's even hard
to say
to see whether something is smaller or
bigger so we have a flavors of the
comparison
where in a different version of that
script
i asked the tool to show me the ratios
and now i get the ratios and can
immediately see which one is lower and
which one is higher so we see that the
total number for some reason the total
number of last level misses drops when
i'm running on two threads
not really surprised because i'm using
more cash base but that's shown here so
now um i got about a 20 22 reduction
in the number of cash misses so that's
kind of nice nice little bonus of
running in parallel and with the compare
ratio option that's really easy to get
you can also look at deltas by the way i
don't have that on the slide but another
one is to to look at delta
i've shown you several features already
but
there's a lot more to uh to explore i
didn't even talk about the call tree we
have more filters
you can get a lot more information on
the experiments and the conditions like
uh the job you were running there's more
customization
and we have pretty decent support for
hardware event counters i've shown you
one example but for example you can
monitor more than one event i've shown
only one event you can monitor as many
events as the hardware supports for
example
so hopefully this gave you um some sort
of idea of what griffin g is about this
is all available today these examples
were made with the version that's
available in our repo
and the details are in the in the bin
neutrals
archives so what are what are our
current priorities well first of all
fixed bugs if you have a bug we hope not
but if you run into a bug please let us
know we want to fix that as quickly as
possible we also want to help you
getting started
and outside of those two top priorities
for development we're working on a
porting guide we currently support intel
amd and arm
if people want to port to another
platform it's open source we would
encourage that would like to work with
you
on that and we're working on a document
that tells you where changes need to be
made
we're also working on a gui
which is a really good way to display
and analyze that data that really adds
value and we're busy finishing a tool
that generates an html based system to
browse the data in your in your daily
browser
other things we're looking at but we're
definitely open for suggestions is
improved support for hardware event
counters in particular or more recent
processors
uh we'd like to show you some more
metrics
another thing is that we'd like to have
the tool the ability to attach to a
running processor you grab the process
you monitor you let go again so you can
take a snapshot while the program is
running
please send your feedback or anything
you want to discuss with us to the bin
utils alias it's shown here
that's the recommended way to
communicate
last but not least i want to give you a
sneak preview into the gui
we have
quite a number of views including a
flame chart
we show you a timeline that's the
color-coded behavior of the program over
time so you can see the dynamics of the
program this is showing a multi-threaded
application you can look at the
individual threads
you can zoom in to really zoom in on
certain behavior like to intro like to
zoom in on
and of course we have the comparison the
comparison works in the gui as well and
it's a great way to quickly find find
out why run why one run for example is
is slower than another one
so um
i hope this gave you a good overview
first overview of what g profit g is
about and uh let's now um spend time on
answering your questions thank you
thank you so much for that talk rude um
we've got plenty of time now we've got
like 11 minutes to do some more
conversation and questions about it so
i'll let you do your quick talk if you
want
yep all right well thank you okay
um yeah i hope you found it useful we
both vladimir and i are very excited
about this we we know we have a long way
to go there's lots of things that we
want to add and
and it's quite a quite an effort so
definitely as i um as i put on the slide
uh please contact us preferably through
the bin utils male alias that's we have
just been approved for inclusion in bin
neutrals and we're trying to get onto
the next release not the first coming up
release but maybe the next one so about
mid mid this year
and again we really want to hear your
wishes and prioritize them and and
and of course give you give you what
you're asking for um there are two
developments that i wanted to mention um
the gui the gui is
is in fairly good shape um it's not done
yet but we think that with the gui
especially the timeline
the timeline will
will show you color-coded behavior of
your application so every function has a
color
and we show you the color-coded call
stacks as a function of time and and
that'll work in multi-threaded
environments as well so the question was
can i see wait time yes you will
definitely see wait time you literally
see a gap there if if a thread is not
doing anything it'll show up as a gap
now we want to show more metrics
currently we only show the total cpu
time and i'm the first one to admit that
that's not enough
for serious performance analysis so it's
another thing high on the list to give
you more metrics
a little bit unfortunate is that we
we can't always get out of the linux
kernel what we um
what we'd like to do but there's always
room for improvement so again your
feedback there is is also definitely
appreciated but i think the timeline
will help a lot of people to analyze the
dynamic behavior of their program i use
it all the time
in addition to that um and that's my
this is why i couldn't answer the
question about ptrace that's like
vladimir's
vladimir's territory i'm working on a
tool to generate an html directory
structure so you can browse through the
performance data in your browser you
don't need anything special you you load
up the directory
and patch it in and and
grab your browser and look at it so
that's some of the things that we're
working on now let me look at the
questions
um
let's see
i think that's more like a
comment
to diagnose issues to diagnose issues
like the directory okay you can all see
that i uh
and uh okay yeah yeah
yeah so that was the comment indeed i
think that's a comment about when we uh
when we attach to a running
process we have some ideas what we can
do there but right now you only get the
main process and
now i i think that's we don't even
mention this because i think that's a
non-feature at the moment
so um
so yeah the
um so again attaching to a running
process is another very very big big
thing a lot of applications have that
and you just want to monitor it while
it's running um maybe for a few minutes
whatever
so um yeah we we we recognized that and
um that's um i would say very yeah
definitely in the top three
uh would you like me to read out the
other open questions in the questions
tim
oh let me see let me yeah i can do it
okay thanks um
have you run from g prof and g on g
profangie um yes we do
we we try to be very performance aware
of course um we didn't do that recently
because to be honest we were just so
focused on getting something out of the
door but yes um yeah
overhead that's um yeah that's another
good um good question
uh
usually it all depends on what you're
doing um just this weekend i got an
email from somebody i think um his he
was using 160 threads
uh or around that number because that's
what his hardware had and on a very
intensive java program and he reported
10
10 is about what we see as a maximum
um of course
it depends on the sampling granularity
you can put that to low or high
but i would say um anything more than 10
would would kind of uh warrant our
investigation to see what's going on
yeah
uh
about language yeah another the is there
okay let me answer first uh give the
question is that thinking about
languages built on top of c like python
yeah we would like to do that of course
um you can't already do some basic
profiling but you'll you'll get exposed
to the raw call stacks of whatever you
do
um and um but definitely uh
would be great to have like a tool for
python or rust or other things so
um yeah that's also actually where we
hope the community will help and
volunteers are always welcome so
so technically we can
the infrastructure would support it but
we need higher high level support
how does g profit g compared to other
system level profiling tools like perf
me being a performance analyst i would
like to have both we certainly do not
have any idea to
compete or replace perth i think perth
is very strong in certain areas
especially like the hardware counter
support and improv is really strong
we try to also cover other areas i think
like our display
display capabilities are maybe a little
easier than perth but
the more the better again as a
performance person i want to have as
many tools as possible
so uh yeah
um
let me see
can i get the file name line info so
that
i'm not sure can i get the file name
colon conan line hash info
so that m
x next arrow works
i'm not sure i understand that i'm sorry
i don't think i understand the question
that's
um
we
do have
ideas to integrate
compiler messages with the source
the original tool in the studio
environment had that but that was
integrated into the studio compiler so
another project we have on our list is
to
give you compiler feedback interleaved
with the source
would be great to see what the compiler
did to your source
so you can check it and correct it if if
it doesn't do what you like it to do so
um but i'm i'm sorry i'm afraid i don't
really
understand that question
and see in the chat
okay
i've got two more questions okay yeah
oh i'm sorry i'm a vi guy um the the
question here is
amex next ever refers to emacs compile
mode i'm i'm sorry i i grew up with vi
and i never got beyond that even
switching to vim was already a major
breakthrough in emotionally
i'm sorry i'm sorry i i i i i i'm afraid
i can't help you
um
okay the the other question is i guess
the idea is to keep your performance
information in some sort of revision
control so that you can monitor
performance regressions
yeah that's currently up to you we we
we don't provide anything like that you
know ideally you would use this tool as
a as a lower level engine to drive those
kind of things to
to keep track of of um of like
regressions
the tool doesn't doesn't yet support
that that's that's
maybe one day
and yeah
i do that now myself again in vi
so
that's not optimal but
there's another continuation on the mx
conversation in the questions yeah i'm
using yeah
oh okay okay well okay i just
you use next arrow to navigate through
the source so annotating the output
allows one to get to the source quickly
vi has support for this as also well
thank you i learned something about vi
after all those the years thank you it
shows what kind of a dinosaur i i
actually am
yeah we
the gui has source navigation i we don't
have any integration with editors um
in the html version i try to um you know
i try to give you some some sort of
visual guidance about where time is
spent
but we we don't have any specific um
formats for for
for things like emax or vi
and
with the html tool you'll you'll you'll
get the raw files you can always load
them yourself into your editor uh you
can do that of course as well with the
with the command line
so i think i don't think we have a lot
to offer there unfortunately you know
is there any
uh
recent news since you recorded the talk
that you need to update
um
um the one thing is is that yeah things
the one thing is is that we
we we we have had a positive review in
bin newton's
um
from ben util so we we hope to be part
of that later this year um and we're
targeting maybe the release around mid
this year around the summer there's one
coming up earlier but i don't think we
should force ourselves into it and then
have all sorts of problems we just need
a bit more time to be ready for that
and again if you'd like to communicate
with us um you can always find this on
the bin neutrals alias
that's that's sort of the recommended
way so others can see the questions as
well but of course if you drop us an
email we're not going to ignore you at
all so
so absolutely not
thank you
all right thank you so much rude uh this
is a really interesting talk about a new
tool uh
our next presentation is at 4 40 pm uh
aedt and it's tisch with confessions of
a crypto miner so we'll see you all back
then thank you so much
thanks thanks caitlyn thanks