{"@attributes":{"version":"2.0"},"channel":{"title":"DEV Community: Evan Wilde","description":"The latest articles on DEV Community by Evan Wilde (@etcwilde).","link":"https:\/\/dev.to\/etcwilde","image":{"url":"https:\/\/media2.dev.to\/dynamic\/image\/width=90,height=90,fit=cover,gravity=auto,format=auto\/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F16817%2F51472c0d-cda2-4f6a-a076-e15a08952965.jpg","title":"DEV Community: Evan Wilde","link":"https:\/\/dev.to\/etcwilde"},"language":"en","item":[{"title":"Perf - Perfect Profiling of C\/C++ on Linux","pubDate":"Sat, 18 Nov 2017 06:22:29 +0000","link":"https:\/\/dev.to\/etcwilde\/perf---perfect-profiling-of-cc-on-linux-of","guid":"https:\/\/dev.to\/etcwilde\/perf---perfect-profiling-of-cc-on-linux-of","description":"

I've seen power-Visual Studio users do amazing things with the profiler and debugger. It looks amazing, but there is one small problem. I'm on Linux. No visual studio for me. How do I profile now? There are some profilers out there for Linux too, each with varying degrees of usability.<\/p>\n\n

Perf is a neat little tool that I just found for profiling programs. Perf uses statistical profiling, where it polls the program and sees what function is working. This is less accurate, but has less of a performance hit than something like Callgrind, which tracks every call. The results are still reasonable accurate, and even with fewer samples, it will show which functions are taking a lot of time, even if it misses functions that are very fast (which are probably not the ones you are looking for while profiling anyway).<\/p>\n\n

With a rather contrived example, we implement the infamous Fibonacci sequence in the most pedagogical way possible. Basic Recursion.
\n<\/p>\n\n

\n
\/\/ fib.c<\/span>\n#include<\/span> <stdio.h><\/span>\n#include<\/span> <stdlib.h><\/span>\n<\/span>\nint<\/span> fib<\/span>(<\/span>int<\/span> x<\/span>)<\/span> {<\/span>\n  if<\/span> (<\/span>x<\/span> ==<\/span> 0<\/span>)<\/span> return<\/span> 0<\/span>;<\/span>\n  else<\/span> if<\/span> (<\/span>x<\/span> ==<\/span> 1<\/span>)<\/span> return<\/span> 1<\/span>;<\/span>\n  return<\/span> fib<\/span>(<\/span>x<\/span> -<\/span> 1<\/span>)<\/span> +<\/span> fib<\/span>(<\/span>x<\/span> -<\/span> 2<\/span>);<\/span>\n}<\/span>\n\nint<\/span> main<\/span>(<\/span>int<\/span> argc<\/span>,<\/span> char<\/span> *<\/span>argv<\/span>[])<\/span> {<\/span>\n\n  for<\/span> (<\/span>size_t<\/span> i<\/span> =<\/span> 0<\/span>;<\/span> i<\/span> <<\/span> 45<\/span>;<\/span> ++<\/span>i<\/span>)<\/span> {<\/span>\n    printf<\/span>(<\/span>\"%d<\/span>\\n<\/span>\"<\/span>,<\/span> fib<\/span>(<\/span>i<\/span>));<\/span>\n  }<\/span>\n  return<\/span> 0<\/span>;<\/span>\n}<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
Running the program with time gives us:
\n<\/p>\n\n
\n
$ <\/span>time<\/span> .\/fib\n\n...\n\n.\/fib  15.05s user 0.00s system 99% cpu 15.059 total\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
It seems that the program stops outputting fast enough shortly after 40 numbers. My machine is able to run 40 numbers in ~ 2 seconds, but if you bump that up to 45, it takes a whopping 15 seconds. But being completely naive, I can't spot the issue. I need to profile it.
\n<\/p>\n\n
\n
$ <\/span>perf record .\/fib\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
Running the program again using this command generates the perf.data<\/code> file, which contains all of the time information of our program. Other than creating this new file, nothing exciting shows up. It says how many times perf woke up, the number of samples, and the size of the perf.data file.
\n<\/p>\n\n
\n
[<\/span> perf record: Woken up 10 times <\/span>to write data ]<\/span>\n[<\/span> perf record: Captured and wrote 2.336 MB perf.data (<\/span>60690 samples)<\/span> ]<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
Things get interesting when we run:
\n<\/p>\n\n
\n
perf report\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
which gives us the following view<\/p>\n\n
\"perf<\/a><\/p>\n\n
Okay, great. So basically, it doesn't tell us too much. It does say that we're spending all of our time in the fib function, but not much else. We can hit enter with the fib<\/code> function highlighted, we get a few options. One is to annotate the function. This shows us a disassembly of the instructions in the function, with the percentage of time being taken by each one. So... we can optimize at the assembly level I guess? Seems a bit extreme. That's a little too low-level for most of us mortals.<\/p>\n\n
\"perf<\/a><\/p>\n\n
There is actually some helpful information in this view if we're clever though. We'll get back on that later.<\/p>\n\n
By default, perf only collects time information. We probably want to see a callgraph since we're making calls. Maybe the base case is the culprit (returning a single number is always suspicious after all (laugh with me here, that's a joke)).<\/p>\n\n
To get the call graph, we pass the -g<\/code> option to perf record<\/code>.
\n<\/p>\n\n
\n
$ <\/span>perf record -g<\/span> .\/fib\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
And wait for it to run again... Then run perf report<\/code> again to see the new view.<\/p>\n\n
\"perf<\/a><\/p>\n\n
Not super different. Neat! Okay, so there are some differences between the first run and the second. Namely, instead of having an overhead<\/code> column, it now has a children<\/code> and self<\/code> column, as well as some +<\/code> signs next to some function calls.<\/p>\n\n
Children refers to the overhead of subsequent calls, while self refers to the cost of the function itself. A high children overhead, and a low self overhead indicates that the function makes a call that is expensive, but a high self overhead indicates that the function itself is expensive.<\/p>\n\n
The +<\/code> indicates that the function makes a call that is accessible. Not all functions are follow-able, likely due to the optimizer striping the function names (or strip -d<\/code> which strips debugging symbols) to shrink the binary.<\/p>\n\n
Highlighting a row and hitting enter will expand it, showing the functions called. Note that some older versions of perf<\/code> show the callees by default, not the the functions being called from the function we're looking at. If you are using an older version it might be necessary to change this behaviour by calling record with perf record -g 'graph,0.5,caller'<\/code>.<\/p>\n\n
\"perf<\/a><\/p>\n\n
In my case, I expanded the call to the main<\/code> function, which doesn't spend much time inside of itself. Inside, there are a bunch of calls the the 'fib' function. The bottom one has a +<\/code> symbol next to it, indicating that it can be expanded. expanding it shows another call to fib, with a +<\/code> symbol.<\/p>\n\n
So.. eventually, we get this big long chain of calls to fib from fib. So recursion strikes again!
\nGoing back to the disassembly, most of the time is spent doing the mov %rsp,%rbp<\/code> which are the registers responsible for the stack and frame pointers in the x86 architecture. Since we see that there is a chain of calls to the fib function, and this particular instruction is quite hot, there's a good indication that something about the recursion is to blame. Now we know what to fix. Fixing it is up to you. Some solutions might include memoization, or emulating recursion with a stack and a while loop, or even a combination of both, but that is beyond the scope of this post.<\/p>\n\n
While this is a contrived example, it gives an introduction to profiling using the perf tool. There are many additional features that are not covered here, but this should be enough to get you started with profiling using perf. The results from perf are not perfect, but they are usable. There are other tools out there, but I rather enjoy the interface with perf, and that it doesn't hurt runtime performance very much. What do you think? What are your favourite profilers and tools for profiling?<\/p>\n\n","category":["profiling","linux","cpp","c"]},{"title":"Git and the interactive patch add","pubDate":"Fri, 04 Aug 2017 13:34:25 +0000","link":"https:\/\/dev.to\/etcwilde\/git-and-the-interactive-patch-add","guid":"https:\/\/dev.to\/etcwilde\/git-and-the-interactive-patch-add","description":"
Sometimes, while working, we see a fix that should be made to a part of a file that is near our work area, but is not directly related to what we are working on. Do we make the fix now and just throw it in with the wash when we add the file, or do we wait and hope to remember to fix it so that it can be committed separately?<\/p>\n\n
The answer is, neither. We make the fix now, but instead of just adding the entire file, we can select \"hunks\" of code that we want to have in our commit using the git add --interactive file.txt<\/code> or git add --patch file.txt<\/code>. Both will result in an interactive console that shows the hunks, or grouped lines being changed, that you can either select to be staged, or ignored.<\/p>\n\n
\n  \n  \n  Git add patch\n<\/h2>\n\n
What does it do? It lets you interactively select chunks of code that you want staged for commit from a file, while leaving out other changes in the file.<\/p>\n\n
Upon invoking git add --patch<\/code>, it will show the changes in the file and give you a prompt. You can enter one of 9 different commands depending on what you want to do at the first stage, but there are other commands too; here is a list of all of the commands you can give to git add --patch<\/p>\n\n