• Abstract and Figures
• Public Full-text

COZ: Finding Code that Counts with Causal Profiling Charlie Curtsinger ∗ Emery D. Berger Department of Computer Science College of Information and Computer Sciences Grinnell College University of Massachusetts Amherst [email protected] [email protected] Abstract tance, they often do not have enough of an impact on perfor- Improving performance is a central concern for software mance to meet programmers’ demands [10]. Programmers developers. To locate optimization opportunities, developers seeking to increase the throughput or responsiveness of their rely on software profilers. However, these profilers only report applications thus must resort to manual performance tuning. where programs spent their time: optimizing that code may Manually inspecting a program to find optimization op- have no impact on performance. Past profilers thus both waste portunities is impractical, so developers use profilers. Con- developer time and make it difficult for them to uncover ventional profilers rank code by its contribution to total exe- significant optimization opportunities. cution time. Prominent examples include oprofile, perf, and This paper introduces causal profiling. Unlike past pro- gprof [17, 27, 29]. Unfortunately, even when a profiler ac- filing approaches, causal profiling indicates exactly where curately reports where a program spends its time, this infor- programmers should focus their optimization efforts, and mation can lead programmers astray. Code that runs for a quantifies their potential impact. Causal profiling works by long time is not necessarily a good choice for optimization. running performance experiments during program execution. For example, optimizing code that draws a loading animation Each experiment calculates the impact of any potential op- during a file download will not make the program run faster, timization by virtually speeding up code: inserting pauses even though this code runs just as long as the download. that slow down all other code running concurrently. The key This phenomenon is not limited to I/O operations. Figure 1 insight is that this slowdown has the same relative effect as shows a simple program that illustrates the shortcomings of running that line faster, thus “virtually” speeding it up. existing profilers, along with its gprof profile in Figure 2a. This program spawns two threads, which invoke functions We present COZ, a causal profiler, which we evaluate on f f a range of highly-tuned applications: Memcached, SQLite, a and b respectively. Most profilers will report that these functions comprise roughly half of the total execution time. and the PARSEC benchmark suite. COZ identifies previously f unknown optimization opportunities that are both significant Other profilers may report that a is on the critical path, or that the main thread spends roughly equal time waiting for fa and and targeted. Guided by COZ, we improve the performance f of Memcached by 9%, SQLite by 25%, and accelerate six b [23]. While accurate, all of this information is potentially f PARSEC applications by as much as 68%; in most cases, misleading. Optimizing a away entirely will only speed up f these optimizations involve modifying under 10 lines of code. the program by 4.5% because b becomes the new critical path. 1. Introduction Improving performance is a central concern for software example.cpp developers. While compiler optimizations are of some assis- 1 void a() { // ˜6.7 seconds ∗ 2 for(volatile size_t x=0; x<2000000000; x++) {} This work was initiated and partially conducted while Charlie Curtsinger 3 } was a PhD student at the University of Massachusetts Amherst. 4 void b() { // ˜6.4 seconds 5 for(volatile size_t y=0; y<1900000000; y++) {} 6 } 7 int main() { Permission to make digital or hard copies of all or part of this work for personal or 8 // Spawn both threads and wait for them. classroom use is granted without fee provided that copies are not made or distributed 9 thread a_thread(a), b_thread(b); for profit or commercial advantage and that copies bear this notice and the full citation 10 a_thread.join(); b_thread.join(); on the first page. Copyrights for components of this work owned by others than the 11 } author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. Figure 1: A simple multithreaded program that illustrates the SOSP’15, October 4–7, 2015, Monterey, CA. f Copyright is held by the owner/author(s). Publication rights licensed to ACM. shortcomings of existing profilers. Optimizing a will improve ACM 978-1-4503-3834-9/15/10. $15.00. performance by no more than 4.5%, while optimizing fb would http://dx.doi.org/10.1145/2815400.2815409 have no effect on performance. 184 Conventional Profile for example.cpp Causal Profile For example.cpp % cumulative self self total line 2 (a) line 5 (b) time seconds seconds calls Ts/call Ts/call name 6% ● ● 55.20 7.20 7.20 1 a() ● ● ●● ● ● ● ● ●● ● 45.19 13.09 5.89 1 b() ● ●● ● ● 4% ● ● % time self children called name <spontaneous> 2% 55.0 7.20 0.00 a() ● -------------------------------------------------- 0% <spontaneous> Program Speedup 45.0 5.89 0.00 b() 0% 25% 50% 75% 100% 0% 25% 50% 75% 100% Line Speedup (a) A conventional profile for example.cpp, collected with gprof (b) Causal profile for example.cpp Figure 2: The gprof and causal profiles for the code in Figure 1. In the causal profile, the y-axis shows the program speedup that would be achieved by speeding up each line of code by the percentage on the x-axis. The gray area shows standard error. Gprof reports that fa and fb comprise similar fractions of total runtime, but optimizing fa will improve performance by at most 4.5%, and optimizing fb would have no effect on performance. The causal profile predicts both outcomes within 0.5%. Conventional profilers do not report the potential impact of cludes, when a web page finishes rendering, or when a query optimizations; developers are left to make these predictions completes. A causal profiler then measures the rate of visits to based on their understanding of the program. While these each progress point to determine any potential optimization’s predictions may be easy for programs as simple as the one effect on throughput. To profile latency, programmers instead in Figure 1, accurately predicting the effect of a proposed place two progress points that correspond to the start and optimization is nearly impossible for programmers attempting end of an event of interest, such as when a transaction begins to optimize large applications. and completes. A causal profiler then reports the effect of This paper introduces causal profiling, an approach that potential optimizations on the average latency between those accurately and precisely indicates where programmers should two progress points. focus their optimization efforts, and quantifies their potential To demonstrate the effectiveness of causal profiling, we impact. Figure 2b shows the results of running COZ, our have developed COZ, a causal profiler for Linux. We show prototype causal profiler. This profile plots the hypothetical that COZ imposes low execution time overhead (mean: 17%, speedup of a line of code (x-axis) versus its impact on min: 0.1%, max: 65%), making it substantially faster than execution time (y-axis). The graph correctly shows that gprof (up to 6× overhead). optimizing either fa or fb in isolation would have little effect. We show that causal profiling accurately predicts optimiza- A causal profiler conducts a series of performance exper- tion opportunities, and that it is effective at guiding optimiza- iments to empirically observe the effect of a potential opti- tion efforts. We apply COZ to Memcached, SQLite, and the mization. Of course it is not possible to automatically speed extensively studied PARSEC benchmark suite. Guided by up any line of code by an arbitrary amount. Instead, a causal COZ’s output, we optimized the performance of Memcached profiler uses the novel technique of virtual speedups to mimic by 9%, SQLite by 25%, and six PARSEC applications by as the effect of optimizing a specific line of code by a fixed much as 68%. These optimizations typically involved mod- amount. A line is virtually sped up by inserting pauses to ifying under 10 lines of code. When possible to accurately slow all other threads each time the line runs. The key insight measure the size of our optimizations on the line(s) identified is that this slowdown has the same relative effect as running by COZ, we compare the observed performance improve- that line faster, thus “virtually” speeding it up. Figure 3 shows ments to COZ’s predictions: in each case, we find that the real the equivalence of virtual and actual speedups. effect of our optimization matches COZ’s prediction. Each performance experiment measures the effect of vir- Contributions tually speeding up one line by a specific amount. By conduct- ing many performance experiments over the range of virtual This paper makes the following contributions: speedup from between 0% (no change) and 100% (the line is 1. It presents causal profiling, which identifies code where completely eliminated), a causal profiler can predict the effect optimizations will have the largest impact. Using virtual of any potential optimization on a program’s performance. speedups and progress points, causal profiling directly Causal profiling further departs from conventional profil- measures the effect of potential optimizations on both ing by making it possible to view the effect of optimizations throughput and latency (§2). on both throughput and latency. To profile throughput, devel- 2. It presents COZ, a causal profiler that works on unmod- opers specify a progress point, indicating a line in the code ified Linux binaries. It describes COZ’s implementation that corresponds to the end of a unit of work.

Load more

  14

Copy Link