move unfinished compilation articles to drafts

Author: sslotin

content/english/hpc/compilation/abstractions.md

@@ -1,6 +1,7 @@
 ---
 title: Non-Zero-Cost Abstractions
 weight: 7
+draft: true
 ---
 
 In general, abstractions are great. Applied well, they reduce the amount of code and the mental burden of a programer.

content/english/hpc/compilation/limitations.md

@@ -1,6 +1,7 @@
 ---
 title: What Compilers Can and Can't Do
 weight: 10
+draft: true
 ---
 
 Let's sum up this chapter with a general advice.

content/english/hpc/compilation/pgo.md

@@ -1,6 +1,7 @@
 ---
 title: Compile-Time Computation
 weight: 8
+draft: true
 ---
 
 ### Precalculation

content/english/hpc/compilation/precalc.md

@@ -71,9 +71,41 @@ int factorial(int n) {
 ```
 
 <!--
-
 What it usually does is it swaps the branches so that the more likely one goes immediately after jump (recall that "don't jump" branch is taken by default). The performance gain is usually rather small, because for most hot spots hardware branch prediction works just fine.
-
 -->
 
 There are many other cases like this when you need to point the compiler in the right direction, but we will get to them later when they become more relevant.
+
+### Profile-Guided Optimization
+
+Adding all this metadata to the source code is tedious. People already hate writing C++ even without having to do it.
+
+It is also not always obvious whether certain optimizations are beneficial or not. To make a decision about branch reordering, function inlining, or loop unrolling, we need answers to questions like these:
+
+- How often is this branch taken?
+- How often is this function called?
+- What is the average number of iterations in this loop?
+
+Luckily for us, there is a way to provide this real-world information automatically.
+
+*Profile-guided optimization* (PGO, also called "pogo" because it's easier and more fun to pronounce) is a technique that uses [profiling data](/hpc/profiling) to improve performance beyond what can be achieved with just static analysis. In a nutshell, it involves adding timers and counters to the points of interest in the program, compiling and running it on real data, and then compiling it again, but this time supplying additional information from the test run.
+
+The whole process is automated by modern compilers. For example, the `-fprofile-generate` flag will let GCC instrument the program with profiling code:
+
+```
+g++ -fprofile-generate [other flags] source.cc -o binary
+```
+
+After we run the program — preferably on input that is as representative of real use case as possible — it will create a bunch of `*.gcda` files that contain log data for the test run, after which we can rebuild the program, but now adding the `-fprofile-use` flag:
+
+```
+g++ -fprofile-use [other flags] source.cc -o binary
+```
+
+It usually improves performance by 10-20% for large codebases, and for this reason it is commonly included in the build process of performance-critical projects. One more reason to invest in solid benchmarking code.
+
+<!--
+
+We will study how profiling works more deeply in the [next chapter](../../profiling).
+
+-->