![]()
tag:blogger.com,1999:blog-2471378914199150966.post-92079316828471072712021-12-01T10:00:00.002-08:002021-12-01T10:00:00.139-08:00Faster Chrome - Let The Compiler do the work<a href="https://1.bp.blogspot.com/-2736RfrYfyA/YaeK7ehpekI/AAAAAAAABwE/sBj0IvPGWQ4bQv1g0Dma7lvXBXdoD4TLQCLcBGAsYHQ/s1999/image1.jpg" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" data-original-height="830" data-original-width="1999" height="240" src="https://1.bp.blogspot.com/-2736RfrYfyA/YaeK7ehpekI/AAAAAAAABwE/sBj0IvPGWQ4bQv1g0Dma7lvXBXdoD4TLQCLcBGAsYHQ/w578-h240/image1.jpg" width="578" /></a><br /><br /><i>Chrome is fast, but there's always room for improvement. Often, that's achieved by carefully crafting the algorithms that make up Chrome. But there's a lot of Chrome, so why not let computers do at least some part of our work? In this installment of <a href="https://blog.chromium.org/search/label/the%20fast%20and%20the%20curious">The Fast And the Curious</a>, we'll show you several changes in how we build Chrome to achieve a <b>25.8% higher score on Speedometer on Windows and a 22.0% increase in browser responsiveness. </b><br /></i><br /><br /><div><h1 style="text-align: left;">Why speed?</h1>So why do we care about performance benchmarks? It's not a simple "higher numbers is better" chasing of achievements - performance was so important to Chrome that we embedded in our <a href="https://www.chromium.org/developers/core-principles">core principles</a>, the "4Ss" - Speed, Security, Stability, Simplicity. And speed matters because we want a browser that responds quickly. Speed matters so much because we want to build a faster and more responsive browser. And by improving the speed of the browser, there's the additional benefit of maximizing battery use, so you don't have to charge your laptop/devices as often.<br /><br /><br /><h1 style="text-align: left;">Speed? Size? Something Else?</h1>Let's look at a typical optimization.<br /><br /><br /></div><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><div><span style="font-family: courier;"><span style="color: #2b00fe;">int</span> foo();</span></div><div><span style="font-family: courier;"><span style="color: #2b00fe;">int</span> fiver(<span style="color: #2b00fe;">int</span> num) {</span></div><div><span style="color: #2b00fe; font-family: courier;"> for</span><span style="font-family: courier;">(</span><span style="color: #2b00fe; font-family: courier;">int</span><span style="font-family: courier;"> j = </span><span style="color: #38761d; font-family: courier;">0</span><span style="font-family: courier;">; j < </span><span style="color: #38761d; font-family: courier;">5</span><span style="font-family: courier;">; j++)</span></div><div><span style="font-family: courier;"> num = num + foo();</span></div><div><span style="font-family: courier;"><span style="color: #2b00fe;"> return</span> num;</span></div><div><span style="font-family: courier;">}</span></div></blockquote><div><br /><br />The compiler can either compile this as a loop (<a href="https://godbolt.org/z/ja7d6x7hE">smaller</a>), or turn it into five additions in a row (<a href="https://godbolt.org/z/x76PohPz9">faster, but bigger</a>)<br /><br />You save the cost of checking the end of the loop and incrementing a variable every time through the loop. But in exchange, you now have many repeated calls to foo(). If foo() is called a lot, that is a lot of space.<br /><br />And while speed matters a lot, we also care about binary size. (Yes, we see your memes!) And that tradeoff - exchanging speed for memory, and vice versa, holds for a lot of compiler optimizations.<br /><br />So how do you decide if the cost is worth it? One good way is to optimize for speed in areas that are run often, because your speed wins accumulate each time you run a function. You could just guess at what you inline (your compiler can do this, it's called "a heuristic", it's an educated guess), and then measure speed and code size.<br /><br />The result: Likely faster. Likely larger. Is that good?<br /><br />Ask any engineer a question like that, and they will answer “It depends”. So, how do you get an answer?<br /><br /><br /><h1 style="text-align: left;">The More You Know… (profiling & PGO)</h1>The best way to make a decision is with data. We collect data based on what gets run a lot, and what gets run a little. We do that for several different scenarios, because our users do lots of different things with Chrome and want them to be fast.<br /><br />Our goal is collecting performance data in various scenarios, and using that to guide the compiler. There are 3 steps needed:<br /><ol style="text-align: left;"><li>Instrument for profiling</li><li>Run that instrumented executable in various scenarios</li><li>Use the resulting performance profile to guide the compiler. </li></ol><div><br /></div><div><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="https://1.bp.blogspot.com/-6dDeIoVTc6I/YaeTFMkR_TI/AAAAAAAABwM/MzIaqq7XtHseXAYVnOnfuspjnsgm-y-NQCLcBGAsYHQ/s1999/image2.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1328" data-original-width="1999" height="365" src="https://1.bp.blogspot.com/-6dDeIoVTc6I/YaeTFMkR_TI/AAAAAAAABwM/MzIaqq7XtHseXAYVnOnfuspjnsgm-y-NQCLcBGAsYHQ/w548-h365/image2.png" width="548" /></a></div><br /><div><br /></div><h1 style="text-align: left;">But we can do more (ThinLTO)</h1>That's a good start, but we can do better. Let's look at inlining - the compiler takes the code of a called function and inserts all of it at the callsite.<br /> <br /><br /></div><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><div><span style="font-family: courier;"><span style="color: #2b00fe;">inline</span> int foo() { <span style="color: #2b00fe;">return</span> <span style="color: #38761d;">3</span>; };</span></div><div><span style="font-family: courier;"><span style="color: #2b00fe;">int</span> fiver_inline(<span style="color: #2b00fe;">int</span> num) {</span></div><div><span style="font-family: courier;"> <span style="color: #2b00fe;">for</span>(<span style="color: #2b00fe;">int</span> j = <span style="color: #38761d;">0</span>; j < <span style="color: #38761d;">5</span>; j++)</span></div><div><span style="font-family: courier;"> num = num + foo();</span></div><div><span style="font-family: courier;"><span style="color: #2b00fe;"> return</span> num;</span></div><div><span style="font-family: courier;">}</span></div></blockquote><div><br /><br />When the compiler inlines foo(), it turns into<br /><br /></div><div><br /></div><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><div><span style="font-family: courier;"><span style="color: #2b00fe;">int</span> fiver_inline(<span style="color: #2b00fe;">int</span> num) {</span></div><div><span style="font-family: courier;"><span style="color: #2b00fe;"> for</span>(int j = <span style="color: #38761d;">0</span>; j < <span style="color: #38761d;">5</span>; j++)</span></div><div><span style="font-family: courier;"> num = num + 3;</span></div><div><span style="font-family: courier;"><span style="color: #2b00fe;"> return</span> num;</span></div><div><span style="font-family: courier;">}</span></div></blockquote><div><br /><br />Not bad - saves us the function call and all the setup that goes with having a function. But the compiler can in fact even do better - because now all the information is in one place. The compiler can apply that knowledge and deduce that fiver_inline() adds the number three and does so 5 times - and so the entire code is <a href="https://godbolt.org/z/dY1vGPYbj">boiled down to</a><br /> <br /><br /></div><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px;"><div style="text-align: left;"><span style="font-family: courier;"> return num + 15;</span></div></blockquote><div><br /><br />Which is awesome! But the compiler can only do this if the source code for foo() and the location where it is called are in the same source file - otherwise, the compiler does not know what to inline. (That's the fiver() example). A trivial way around that is to combine all the source files into one giant source file and compile and link that in one go.<br /><br /><br /><a href="https://1.bp.blogspot.com/-TJ_rYc42VWI/YaeXP883q1I/AAAAAAAABwU/1LWmjCYSuVYWj3Ou2IzSpWM4dnmH877XQCLcBGAsYHQ/s1999/image4.png" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" data-original-height="1329" data-original-width="1999" height="384" src="https://1.bp.blogspot.com/-TJ_rYc42VWI/YaeXP883q1I/AAAAAAAABwU/1LWmjCYSuVYWj3Ou2IzSpWM4dnmH877XQCLcBGAsYHQ/w577-h384/image4.png" width="577" /></a><br /><br /><br />There's just one downside - that approach needs to generate all of the machine code for Chrome, all the time. Change one line in one file, compile all of Chrome. And there's a lot of Chrome. It also effectively disables caching build results and so makes remote compilation much less useful. (And we rely a lot on remote compilation & caching so we can quickly build new versions of Chrome.)<br /><br />So, back to the drawing board. The core insight is that each source file only needs to include a few functions - it doesn't need to see every single other file. All that's needed is "cleverly" mixing the right inline functions into the right source files. <br /><br /><br /><a href="https://1.bp.blogspot.com/-owYckDrSAr0/YaeXesh7WjI/AAAAAAAABwY/hrvwTy6onlsfxevg-r1Qcu6fh_84s2hbQCLcBGAsYHQ/s1999/image3.png" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" data-original-height="1329" data-original-width="1999" height="405" src="https://1.bp.blogspot.com/-owYckDrSAr0/YaeXesh7WjI/AAAAAAAABwY/hrvwTy6onlsfxevg-r1Qcu6fh_84s2hbQCLcBGAsYHQ/w608-h405/image3.png" width="608" /></a><br /><br /><br />Now we're back to compiling individual source files. Distributed/cached compilation works again, small changes don't cause a full rebuild, and since "ThinLTO" does just inline a few functions, and it is relatively little overhead.<br /><br />Of course, the question of "which functions should ThinLTO inline?" still needs to be answered. And the answer is still "the ones that are small and called a lot". Hey, we know those already - from the profiles we generated for Profile Guided Optimization (PGO). Talk about lucky coincidences!<br /><br /><br /><h1 style="text-align: left;">But wait, there's more! (Callgraph Sorting)</h1>We've done a lot for inlined function calls. Is there anything we can do to speed up functions that haven't been inlined, too? Turns out there is. <br /><br />One important factor is that the CPU doesn't fetch data byte by byte, but in chunks. And so, if we could ensure that a chunk of data doesn't just contain the function we need right now, but ideally also the ones that we'll need next, we could ensure that we have to go out and get chunks of data less often.<br /><br />In other words, we want functions that are called right after the other to live next to each other in memory also ("code locality"). And we already know which functions are called close to each other - because we ran our profiling and stored performance profiles for PGO.<br /><br />We can then use that information to ensure that the right functions are next to each other when we link.<br /><br /><br />I.e.<br /><br /><br /></div><blockquote style="border: none; margin: 0px 0px 0px 40px; padding: 0px; text-align: left;"><div><span style="font-family: courier;">g.c</span></div><div><span style="font-family: courier;"> extern int f1();</span></div><div><span style="font-family: courier;"> extern int f2();</span></div><div><span style="font-family: courier;"> extern int f3();</span></div><div><span style="font-family: courier;"> int g() {</span></div><div><span style="font-family: courier;"> f1();</span></div><div><span style="font-family: courier;"> for(..) {</span></div><div><span style="font-family: courier;"> f3();</span></div><div><span style="font-family: courier;"> }</span></div><div><span style="font-family: courier;"> f1();</span></div><div><span style="font-family: courier;"> f2();</span></div><div><span style="font-family: courier;">}</span></div></blockquote><div><br /><br />could be interpreted as "g() calls f3() a lot - so keep that one really close. f1() is called twice, so… somewhat close. And if we can squeeze in f2, even better". The calling sequence is a "call graph", and so this sorting process is called "call graph sorting".<br /><br />Just changing the order of functions in memory might not sound like a lot, but it leads to <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=1113282">~3% performance improvement</a>. And to know which functions calls which other ones a lot… yep. You guessed it. Our profiles from the PGO work pay off again.<br /><br /><br /><h1 style="text-align: left;">One more thing.</h1>It turns out that the compiler can make even more use of that profile data for PGO. (Not a surprise - once you know where the slow spots are, exactly, you can do a lot to improve!). To make use of that, and enable further improvements, LLVM has something called the "new pass manager". In a nutshell, it's a new way to run optimizations within LLVM, and it helps a lot with PGO. For much more detail, I'd suggest reading the <a href="https://blog.llvm.org/posts/2021-03-26-the-new-pass-manager/">LLVM blog post</a>. <br /><br />Turning that on leads to another ~3% performance increase, and ~9MB size reduction.<br /><br /></div><div><br /></div><div><h1 style="text-align: left;">Why Now?</h1>Good question. One part of that is that PGO & profiling unlock an entire new set of optimizations, as you've seen above. It makes sense to do that all in one go. <br /><br />The other reason is our toolchain. We used to have a colorful mix of different technologies for compilers and linkers on different platforms.<br /><br /><br /><a href="https://1.bp.blogspot.com/-RBY8v7fl5CA/YaeZd_KZRrI/AAAAAAAABws/3ZRiRVC_fVQdYAj7Rse3FwHbEwN1GbRIACLcBGAsYHQ/s916/9NcAMNnoAe52Ly9.png" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" data-original-height="319" data-original-width="916" height="166" src="https://1.bp.blogspot.com/-RBY8v7fl5CA/YaeZd_KZRrI/AAAAAAAABws/3ZRiRVC_fVQdYAj7Rse3FwHbEwN1GbRIACLcBGAsYHQ/w478-h166/9NcAMNnoAe52Ly9.png" width="478" /></a><br /><br /><br />And since this work requires changes to compilers and linkers, that would mean changing the build - and testing it - across 5 compilers and 4 linkers. But, thankfully, we've simplified our toolchain (Simplicity - another one of the 4S's!). To be able to do this, we worked with the LLVM community to make clang a great <a href="https://blog.llvm.org/2018/03/clang-is-now-used-to-build-chrome-for.html">Windows compiler</a>, in addition to partnering with the LLVM community to create new ELF (Linux), COFF (Windows), and Mach-O (macOS, iOS) linkers.<br /><br /><br /><a href="https://1.bp.blogspot.com/-vTgjC1aAkB4/YaeZCZTA3DI/AAAAAAAABwk/uU5fFI5sjXQO78hGzePPDcYRp-aJmindwCLcBGAsYHQ/s921/7kspjpiq3gfYBFE.png" style="margin-left: 1em; margin-right: 1em; text-align: center;"><img border="0" data-original-height="321" data-original-width="921" height="167" src="https://1.bp.blogspot.com/-vTgjC1aAkB4/YaeZCZTA3DI/AAAAAAAABwk/uU5fFI5sjXQO78hGzePPDcYRp-aJmindwCLcBGAsYHQ/w476-h167/7kspjpiq3gfYBFE.png" width="476" /></a><br /><br /><br />And suddenly, it's only a single toolchain to fix. (Almost. LTO for lld on MacOS is <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=471146">being worked on</a>).<br /><br />Sometimes, the best way to get more speed is not to change the code you wrote, but to change the way you build the software.<br /><br />Posted by Rachel Blum, Engineering Director, Chrome Desktop</div><div><br /></div><div><i>Data source for all statistics: <a href="https://browserbench.org/Speedometer2.0/">Speedometer 2.0</a>.</i><br /><br /></div><div class="separator" style="clear: both; text-align: center;"><br /></div><br /><div class="separator" style="clear: both; text-align: center;"><br /></div><br /><div class="separator" style="clear: both; text-align: center;"><br /></div><br /><div class="separator" style="clear: both; text-align: center;"><br /></div><br />Chromium Bloghttps://www.blogger.com/profile/06394244468194711527[email protected]
文章来源: http://www.blogger.com/feeds/2471378914199150966/posts/default/9207931682847107271
如有侵权请联系:admin#unsafe.sh