[Herb SUTTER
Name
More Exceptional C
The Chinese version is coming soon. As a translator of this book, I am very happy to recommend this book to everyone. Judging from Huazhong University of Science and Technology Press agreed, I will disclose some translation, please ask everyone to criticize.
]
Optimization and performance
For programmers, efficiency is always important. In the tradition of C and C , efficiency is one of the important pillars. "Don't pay any costs for anything that don't use any costs" - also known as zero-cost principles - always language design and library design And, it is also indeed realized to a large extent.
In this chapter and the two appendices after the book, we have observed some important C optimization problems and analyzed their impact on the real world code. Should you optimize your code? How to optimize? What did INLIN have done? Why is the fancy optimization (and does) let us fall into trouble? The last point, and the most interesting point for me: If you are writing multi-thread code, how will the answers on some questions have changed? After all, we care about the efficiency problem in the real world; although the C standard is not talking about the line, in the first line of the program design, there are more and more programmers in writing multi-thread C code every day. . They will care about these questions.
Terms 12: Inline difficulty: 4 and most people's views, keyword inline is actually not magic. In fact, it is only useful when it is properly applied, it will become a useful tool. The question is: When should I use it?
1. What role is inline?
2. Do you increase the function's internal linkage?
3. When should I decide to use the inline function? How to determine?
answer
1. What role is inline?
Storing a function to inline means telling the compiler: The compiler can put the copy of this function code directly in each place where this function is used. The compiler can choose this, or don't do it; if the compiler does this, it will avoid the occurrence of function calls.
2. Do you increase the function's internal linkage?
Not necessarily.
First, before answering this question, if you don't ask yourself to optimize "what", you will fall into a famous trap. The first question should be: "What is your efficiency refers to?" In the above question, the so-called efficiency refers to the program size? Or or memory is occupied? execution time? Development speed? Compiling time? Or what other things?
Second, with most people's views: In all aspects of efficiency, the inline may improve it, and it may deteriorate:
a) Program volume. Many programmers believe that the inline will add the volume of the program because the program has a copy of the function code, and the compiler generates a copy of each place that uses that function. Usually this is right, but not always. If the volume of the inline function is smaller than it is compared to the volume of the "code" of the compiler to perform function calls ", the inline function is smaller, then the internal link will reduce the volume of the program.
b) memory occupation. In addition to the basic programs (above), inline usually has no effect on the memory of the program, there is little affected.
c) execution time. Many programmers believe that the inline linkage will definitely increase the running speed because it avoids the overhead of the function calls; and, through the function calls this "obstacle", the compiler's optimization program has more chances . This may be correct, but not always correct: If the function is not called extremely frequently, the execution time of the entire program usually does not improve significantly. In fact, things may be counterproductive. If the inline increases the volume of the call function, it reduces the "Locality of Reference" of the caller (Terminal: See [Meyers96] Terms 18); this means, if the internal Inner Loop no longer matches the size of the processor cache, the execution speed of the entire program is actually reduced. Don't forget: Objectively, most programs are not limited to CPU. The most common bottlenecks may be on I / O restrictions, including many aspects, such as network bandwidth or delay, access to files or databases, and more.
d) Development speed and compile time. In order to obtain the most effective utilization, the inline code must be visible to the caller; this means that the caller must rely on internal details of the inline code. Relying on the internal implementation details of another module inevitably increase the actual coupling of the module (but does not increase the theoretical coupling, because the caller actually does not use any internal implementation of the caller.) Normally, when the normal function is modified The caller does not need to recompile, just resin. When the inline function is modified, the caller must recompile. Also, the inline function itself will affect the development speed in the debug period, because, if you want to track the internal function of the inline function, or manage breakpoints within the inner function, it will be more difficult for most debuggers. .
In one case, some people will think that inline is an optimization of development speed (this has some disputes) - to avoid the data member as public members, provide an access function (Accessor, after seeing) is good Do
Law, but the cost of writing such an access function may be high. In this case, some people will think that using the internal linkage with good coding style and better module independence.
Finally, please remember that if you want to use what way to improve efficiency, you always use your algorithm and data structure. They will give you a maximum improvement of the order, and the inline process optimization is usually (note that "usually") is minimal.
May wish to say "now"
3. When should I decide to use the inline function? How to determine?
Like any other optimization technology, the answer is: Don't rash before the analysis tool tells you this. This principle has several reasonable exceptions - in some cases you can do not hesitate to inline a function: such as an empty function, and continue to be empty; or, you don't have to do this - for example When writing a non-exported template.
Design guidelines
Use the optimized first principle: do not use it. Use the optimized second principle: do not use it.
Conclusion: As long as the coupling is added, the inline will always bring costs; it is definitely not to pay for a pre-payment, unless you know that it will bring benefits - that is, the return is greater than expenditure.
"But I can always find bottlenecks!" You will think so. Don't worry, not you think so. Most programmers think more or less, but they are still wrong. It's completely wrong. For the real bottleneck in the code, the programmer is a notorious guess. Sometimes, we hit it up with it. But most of our guess is wrong. Usually, only experimental data (or analyzing results) can help us find true hotspots. If you do not take some analytical tool, ten eight nine, a programmer cannot identify his (her) code middle hotspot or bottleneck. It has been done for many years. I have encountered a few programmers against this fact. They (or their colleagues) insist that this fact is not applicable to them, claiming that they can "feel" in their own code. Hotspot. Over the years, I have never seen such a declaration becoming a consistent truth. We are good at deceiving themselves.
Finally, pay attention to another actual reason for using this criterion is: Which inline function should not be inline, the analysis tool is not good at identification.
About intensive computing tasks (such as numerical computing libraries)
Some people have to write short compact library code, such as advanced science and engineering computing libraries, sometimes in line with intuitive use, and do very good. However, even these programmers, they also tend to use inline in wise, think that optimization should not be early. Note, write a module, then compare performance through "Open Inline" and "Close Inline", which is usually not a good idea, because "full opening" and "complete" are a very rough analysis method. It can only tell you the general situation. It won't tell you which function benefits, and will not tell you how much each function. Even in these cases, you should also use the analysis tool and optimize based on its recommendations.
About Access Functions
There will be some people to argue: Only one line of access functions (for example, "X & Y: F () {return myx_;}" is a reasonable exception, which "can" or "should" are automatically inline. I know this truth, but I have to act carefully. Anyway, all inlaid code increases coupling. So, unless you are in advance, it is convinced that the inline will bring benefits, otherwise, it will use the inline decision to delay until the analysis. At that time, if the analysis tool really pointed out that the internal link will be good, you know, you are doing something worth doing; and you will also be coupled and possible with possible compilation overhead - delay to you really know The inline is really necessary. Don't let you suffer, really!
Design guidelines
Inline or detailed optimization can be avoided before performance analysis proves.
