C++在x86架构优化指南：关键性能提升策略

需积分: 9 197 浏览量更新于2024-07-21 收藏 683KB PDF 举报

本指南深入探讨了C++在x86体系结构下的优化技巧，旨在帮助高级程序员和软件开发者提升软件性能。作者是Agner Fog，来自哥本哈根工程大学，该手册针对Windows、Linux和Mac平台提供了实用的优化策略。它假设读者对C++编程语言有扎实的基础，并对编译器工作原理有一定理解。首先，章节1"Introduction"介绍了优化的重要性，强调了优化可能会带来的成本和潜在收益。开发者需要权衡性能提升与开发时间、代码复杂度之间的平衡。章节2详细讨论了选择优化平台的关键决策，包括硬件平台（如处理器）、操作系统、编程语言（C++）、编译器、函数库、用户界面框架等。C++语言本身可能存在的一些局限性也会在此部分被提及，并提供克服方法。接下来，第三部分"Finding the biggest time consumers"聚焦于识别性能瓶颈，如计算效率（时钟周期）、性能分析工具（用于定位热点代码）、程序安装和加载机制、动态链接和位置无关代码、文件访问、系统数据库操作、图形处理和系统资源管理、网络访问、内存访问以及上下文切换等。每个方面都揭示了如何通过深入了解系统的运作来优化性能。章节4"Performance and usability"将性能优化与用户体验相结合，提醒开发者在追求速度的同时不应忽视软件的易用性和稳定性。第四部分"Choosing the optimal algorithm"讨论了选择合适算法对性能的影响，高效算法可以显著减少计算需求。最后，第六部分"The efficiency of different C++ constructs"专门研究了C++语言的不同构造在执行效率上的差异，这对于编写高效代码至关重要，开发者可以根据具体应用场景选择最优化的语法和技术。本指南是一份实用的参考资源，不仅提供了深入的理论指导，还包含了实际问题的解决方案，有助于C++开发者充分利用x86体系结构的优势，提高软件性能。

code that use only a small fraction of the total time. Optimizing less critical parts of the code

will not only be a waste of time, it also makes the code less clear and more difficult to debug

and maintain.

Most compiler packages include a profiler that can tell how many times each function is

called and how much time it uses. (If you are using MS Visual Studio 2005 you need the

"Team Suite" edition to profile native code, in Linux use gprof). There are also third-party

profilers such as AQtime, Intel VTune and AMD CodeAnalyst.

There are several different profiling methods:

Instrumentation: The compiler inserts extra code at each function call to count how

many times the function is called and how much time it takes.

Debugging. The profiler inserts temporary debug breakpoints at every function or every

code line.

Time-based sampling: The profiler tells the operating system to generate an interrupt,

e.g. every millisecond. The profiler counts how many times an interrupt occurs in

each part of the program. This requires no modification of the program under test,

but is less reliable.

Event-based sampling: The profiler tells the CPU to generate interrupts at certain

events, for example every time a thousand cache misses have occurred. This makes

it possible to see which part of the program has most cache misses, branch

mispredictions, floating point exceptions, etc. Event-based sampling requires a CPU-

specific profiler. For Intel CPU's use Intel VTune, for AMD CPU's use AMD

CodeAnalyst.

Unfortunately, profilers are often unreliable. They sometimes give misleading results or fail

completely because of technical problems.

Some common problems with profilers are:

Coarse time measurement. If time is measured with millisecond resolution and the

critical functions take microseconds to execute then measurements can become

imprecise or simply zero.

Execution time to small or too long. If the program under test finishes in a short time

then the sampling generates too little data for analysis. If the program takes too long

time to execute then the profiler may sample more data than it can handle.

Waiting for user input. Many programs spend most of their time waiting for user input or

network resources. This time is included in the profile. It may be necessary to modify

the program to use a set of test data instead of user input in order to make profiling

feasible.

Interference from other processes. The profiler measures not only the time spent in the

program under test but also the time used by all other processes running on the

same computer, including the profiler itself.

Function addresses are obscured in optimized programs. The profiler identifies any hot

spots in the program by their address and attempts to translate these addresses to

function names. But a highly optimized program is often reorganized in such a way

that there is no clear correspondence between function names and code addresses.

The names of inlined functions may not be visible at all to the profiler. The result will

be misleading reports of which functions take most time.

Uses debug version of the code. Some profilers require that the code you are testing

contains debug information in order to identify individual functions or code lines. The

debug version of the code is not optimized.

Jumps between CPU cores. A process or thread does not necessarily stay in the same

core on multi-core CPUs, but event-counters do. This results in meaningless event

counts for threads that jump between multiple CPU cores.

Poor reproducibility. Delays in program execution may be caused by random events that

are not reproducible. Such events as task switches and garbage collection can occur

at random times and make parts of the program appear to take longer time than

normally.

Due to these problems, we may want to make our own measurements rather than using a

ready-made profiler. This does not solve all the problems, but usually gives more reliable

results. If you are not satisfied with the way a profiler works then you may put the desired

measurement instruments into the program itself. You may add counter variables that count

how many times each part of the program is executed. Furthermore, you may read the time

before and after each of the most important or critical parts of the program to measure how

much time each part takes.

Your measurement code should have #if directives around it so that it can be disabled in

the final version of the code. Inserting your own profiling instruments in the code itself is a

very useful way of keeping track of the performance during the development of a program.

The time measurements may require a very high resolution if time intervals are short. In

Windows, you can use the GetTickCount or QueryPerformanceCounter functions for

millisecond resolution. A much higher resolution can be obtained with the time stamp

counter in the CPU, which counts at the CPU clock frequency. The ReadTSC function in the

function library at www.agner.org/optimize/asmlib.zip

gives easy access to this counter.

The time stamp counter becomes invalid if a thread jumps between different CPU cores.

You may have to fix the thread to a specific CPU core during time measurements to avoid

this. (In Windows, use SetThreadAffinityMask).

The program should be tested with a realistic set of test data. The test data should contain a

typical degree of randomness in order to get a realistic number of cache misses and branch

mispredictions.

When the most time-consuming parts of the program have been found, then it is important

to focus the optimization efforts on the time consuming parts only.

If a small piece of code is particularly critical then it may be useful to measure the number of

cache misses, branch mispredictions, floating point exceptions, etc. in this piece of code.

My test programs at www.agner.org/optimize/testp.zip

are useful for this purpose. See page

136 for details.

A profiler is most useful for finding problems that relate to CPU-intensive code. But many

programs use more time loading files or accessing network and other resources than doing

arithmetic operations. The most common time-consumers are discussed in the following

sections.

3.3 Program installation

The time it takes to install a program package is not traditionally considered a software

optimization issue. But it is certainly something that can steal the user's time. The time it

takes to install a software package and make it work cannot be ignored if the goal of

software optimization is to save time for the user. With the high complexity of modern

software, it is not unusual for the installation process to take more than an hour. Neither is it

unusual that a user has to reinstall a software package several times in order to find and

resolve compatibility problems.

Software developers should take installation time and compatibility problems into account

when deciding whether to base a software package on a complex framework requiring

many files to be installed.

The installation process should always use standardized installation tools. It should be

possible to select all installation options at the start so that the rest of the installation

process can proceed unattended. Uninstallation should also proceed in a standardized

manner.

3.4 Program loading

Often, it takes more time to load a program than to execute it. The load time can be

annoyingly high for programs that are based on big frameworks and intermediate code, as

is commonly the case with programs written in Java, C#, Visual Basic, etc.

But program loading can be a time-consumer even for programs implemented in compiled

C++. This typically happens if the program uses a lot of runtime DLL's (dynamically linked

libraries, also called shared objects), resource files, configuration files, help files and

databases. The operating system may not load all the modules of a big program when the

program starts up. Some modules may be loaded only when they are needed, or they may

be swapped to the hard disk if the RAM size is insufficient.

The user expects immediate responses to simple actions like a key press or mouse move. It

is unacceptable to the user if such a response is delayed for several seconds because it

requires the loading of modules or resource files from disk. Memory-hungry applications

force the operating system to swap memory to disk. Memory swapping is a frequent cause

of unacceptably long response times to simple things like a mouse move or key press.

Avoid an excessive number of DLLs, configuration files, resource files, help files etc.

scattered around on the hard disk. A few files, preferably in the same directory as the .exe

file, is acceptable.

3.5 Dynamic linking and position-independent code

Function libraries can be implemented either as static link libraries (*.lib, *.a) or dynamic

link libraries, also called shared objects (*.dll, *.so). The mechanism of static linking is

that the linker extracts the functions that are needed from the library file and copies them

into the executable file. Only the executable file needs to be distributed to the end user.

Dynamic linking works differently. The link to a function in a dynamic library is resolved at

run time. Therefore, both the executable file and one or more DLLs are loaded into memory

when the program is run. Both the executable file and all the DLLs need to be distributed to

the end user.

The advantages of using static linking rather than dynamic linking are:

Static linking includes only the part of the library that is actually needed by the

application, while dynamic linking makes the entire library load into memory, possibly

including hundreds of unused functions.

All the code is included in a single executable file when static linking is used. Dynamic

linking makes it necessary to load several files when the program is started.

It takes longer time to call a function in a dynamic link library than in a static link library

because it needs an extra jump through a pointer in an import table.

The memory space becomes more fragmented when the code is distributed between

multiple DLLs. The DLLs are always loaded at round memory addresses divisible by

the memory page size (4096). This will make all DLLs contend for the same cache

lines. This makes code caching and data caching less efficient.

DLLs are less efficient in some systems because of the needs of position-independent

code, see below.

Installing a second application that uses a newer version of the same DLL can change

the behavior of the first application if dynamic linking is used, but not if static linking

is used.

The advantages of dynamic linking are:

Multiple applications running simultaneously can share the same DLL without the need

to load more than one instance of the DLL into memory. This is useful on servers

that run many processes simultaneously.

A DLL can be updated to a new version without the need to update the program that

calls it.

A DLL can be called from programming languages that do not support static linking.

A DLL can be useful for making plug-ins that add functionality to an existing program.

Weighing the above advantages of each method, it is clear that static linking is preferable in

critical applications except for parts of the code that are rarely used.

Many function libraries are available in both static and dynamic versions. It is recommended

to use the static version if a performance gain can be expected.

Some systems allow lazy binding of function calls. The principle of lazy binding is that the

address of a linked function is not resolved when the program is loaded, but waits until the

first time the function is called. Lazy binding can be useful if there is a low probability that

the function will be called in a single session. But lazy binding definitely degrades

performance if the function is called. A considerable delay comes when the function is

called for the first time. This delay is caused by the need to load the dynamic linker, and in

some cases from purging the code cache because of self-modifying code.

The delay on lazy binding leads to a usability problem in interactive programs because the

response time to e.g. a mouse click becomes inconsistent and sometimes unacceptably

long. I will not recommend lazy binding.

The memory address at which a DLL is loaded cannot be determined in advance, because

a fixed address might clash with another DLL requiring the same address. This problem is

solved in Linux, BSD and Mac systems by using position-independent code. Unfortunately,

this leads to a considerable extra overhead. There are two reasons for this overhead. The

first reason is that the 32-bit instruction set has no support for self-relative addressing of

data. The code needs to use an extra function call for setting up a register that points to the

data. This is done in every function that needs access to global, static or constant data. The

result is that a register is wasted and that an extra overhead is incurred after almost every

function call. The second reason is that Linux systems access all static data through

pointers stored in a global offset table when position-independent code is used. This leads

to extra instructions for loading a pointer from the global offset table every time a global,

static or constant data item is accessed.

The 64-bit instruction set supports self-relative addressing of data. Therefore, there is less

extra cost to position-independent code in 64-bit systems. Unfortunately, current compilers

for 64-bit Linux still use a global offset table for position independent code although it would

be possible to access the data without such a table.

The Windows system uses a different method for allowing a DLL to be loaded at an arbitrary

address. All addresses in the DLL are simply modified when the DLL is loaded if the

memory address is different from a predefined value. This process is known as relocation. A

DLL may contain thousands of addresses to relocate, but the relocation process is

nevertheless very fast because the address calculations are simple and are done only once.

The conclusion is that there is a significant runtime cost for position-independent code when

using dynamic linking (shared objects) in Linux, BSD and Mac systems. Critical CPU-

intensive code should never be stored in a shared object on these systems.

Note that many compilers for Mac OS X make position-independent code and lazy binding

by default, even when shared objects are not used. Be sure to specify static linking and no

position-independent code (-fno-pic) for best performance when building code for the

Mac system.

3.6 File access

Reading or writing a file on a hard disk often takes much more time than processing the

data in the file, especially if the user has a virus scanner that scans all files on access.

Sequential forward access to a file is faster than random access. Reading or writing big

blocks is faster than reading or writing a small bit at a time. Do not read or write less than a

few kilobytes at a time.

You may mirror the entire file in a memory buffer and read or write it in one operation rather

than reading or writing small bits in a non-sequential manner.

It is usually much faster to access a file that has been accessed recently than to access it

the first time. This is because the file has been copied to the disk cache.

Files on remote or removable media such as floppy disks and USB sticks may not be

cached. This can have quite dramatic consequences. I once made a Windows program that

created a file by calling WritePrivateProfileString, which opens and closes the file

for each line written. This worked sufficiently fast on a hard disk because of disk caching,

but it took several minutes to write the file to a floppy disk.

A big file containing numerical data is more compact and efficient if the data are stored in

binary form than if the data are stored in ASCII form. A disadvantage of binary data storage

is that it is not human readable and not easily ported to systems with big-endian storage.

Optimizing file access is more important than optimizing CPU use in programs that have

many file input/output operations. It can be advantageous to put file access in a separate

thread if there is other work that the processor can do while waiting for disk operations to

finish.

剩余142页未读，继续阅读

sinat_29875411

粉丝: 0
资源: 1

C++在x86架构优化指南：关键性能提升策略

x86_x64体系探索及编程(邓志)高清最新版

加载不使用execve syscall的静态链接的ELF二进制文件（x86体系结构）。-C/C++开发

HeliumOS:x86体系结构的操作系统

KSOS：我们自己的操作系统是从头开始为x86体系结构构建的！

BastionOS：只是用于x86_64体系结构的简单64位爱好操作系统

x86-operating-system：我要使用IA-32体系结构的操作系统

C++ 龙马谷代码注入器 支持x86/x64汇编 DLL注入

Microsoft.Visual.C++.2013.Redistributable.Package.x64.x86.rar

最新资源

C++ 龙马谷代码注入器支持x86/x64汇编 DLL注入