CUDA C编程最佳实践4.1：评估、并行与优化部署详解

需积分: 9 122 浏览量更新于2024-07-29 收藏 2.31MB PDF 举报

《CUDA C最佳实践指南4.1》是一份由NVIDIA发布的最新版本的CUDA编程实践手册，它作为CUDA C编程指南的补充，帮助开发者深入理解CUDA架构和优化技术。这份文档的目标读者是那些希望提升CUDA应用性能和效率的软件工程师，特别是那些处理并行计算和GPU加速任务的专业人士。指南的核心内容分为四个部分： 1. 评估、并行化、优化与部署： - 评估：首先，开发人员需要评估其应用程序是否适合在GPU上运行，包括考虑主机和设备之间的差异，以及设备上的硬件和软件环境。 - 并行化：指南详细介绍了如何利用CUDA的并行库（如CUDA C API）来实现代码的并行化，包括使用CUDA编程模型（如线程块和网格）、数据并行性和控制流。 - 优化：这部分着重于提供性能优化技巧，如内存管理和调度、减少同步开销、避免全局内存访问瓶颈等，以提高代码的执行效率。 - 部署：最后，文档讨论了如何将优化后的CUDA程序部署到不同的硬件平台，并考虑到兼容性、性能监控和调试策略。 2. 评估你的应用程序： - 章节1介绍异构计算的概念，强调了主机和设备在硬件、编程模型和数据处理上的区别，这对于合理分配任务至GPU至关重要。 - 章节2关注应用性能分析，通过创建性能剖析工具，识别出代码中的热点区域，理解程序的可扩展性，以便针对性地优化。 3. 开始并行编程： - 章节3指导初学者如何使用CUDA提供的并行库和编译器特性，以实现高效的并行代码设计。 - 例如，它涵盖了如何编写暴露并行性的代码，如何管理线程和数据，以及如何利用CUDA的内存模型进行高效数据传输。 4. 其他推荐和最佳实践：最后，文档总结了一些建议和最佳实践，涵盖了性能调优的最佳方法、避免常见陷阱以及持续学习和适应CUDA生态系统的新功能。《CUDA C最佳实践指南4.1》是一份实用的参考资源，提供了系统化的指导，帮助开发者充分利用CUDA进行高性能计算，提高应用程序的执行效率和可维护性。通过结合这份文档的学习和实践，开发者可以更好地理解和掌握CUDA编程的艺术。

Heterogeneous Computing

www.nvidia.com

CUDA C Best Practices Guide DG-05603-001_v4.1 | 8

 To use CUDA, data values must be transferred from the host to the device along the

PCI Express (PCIe) bus. These transfers are costly in terms of performance and

should be minimized. (See Section 6.1.) This cost has several ramifications:

● The complexity of operations should justify the cost of moving data to and from

the device. Code that transfers data for brief use by a small number of threads will

see little or no performance benefit. The ideal scenario is one in which many

threads perform a substantial amount of work.

For example, transferring two matrices to the device to perform a matrix addition

and then transferring the results back to the host will not realize much

performance benefit. The issue here is the number of operations performed per

data element transferred. For the preceding procedure, assuming matrices of size

N×N, there are N

operations (additions) and 3N

elements transferred, so the ratio

of operations to elements transferred is 1:3 or O(1). Performance benefits can be

more readily achieved when this ratio is higher. For example, a matrix

multiplication of the same matrices requires N

operations (multiply-add), so the

ratio of operations to elements transferred is O(N), in which case the larger the

matrix the greater the performance benefit. The types of operations are an

additional factor, as additions have different complexity profiles than, for example,

trigonometric functions. It is important to include the overhead of transferring

data to and from the device in determining whether operations should be

performed on the host or on the device.

● Data should be kept on the device as long as possible. Because transfers should be

minimized, programs that run multiple kernels on the same data should favor

leaving the data on the device between kernel calls, rather than transferring

intermediate results to the host and then sending them back to the device for

subsequent calculations. So, in the previous example, had the two matrices to be

added already been on the device as a result of some previous calculation, or if the

results of the addition would be used in some subsequent calculation, the matrix

addition should be performed locally on the device. This approach should be used

even if one of the steps in a sequence of calculations could be performed faster on

the host. Even a relatively slow kernel may be advantageous if it avoids one or

more PCIe transfers. Section 6.1 provides further details, including the

measurements of bandwidth between the host and the device versus within the

device proper.

Application Profiling

www.nvidia.com

CUDA C Best Practices Guide DG-05603-001_v4.1 | 10

$ gcc -O2 -g –pg myprog.c

$ gprof ./a.out > profile.txt

Each sample counts as 0.01 seconds.

% cumulative self self total

time seconds seconds calls ms/call ms/call name

33.34 0.02 0.02 7208 0.00 0.00 genTimeStep

16.67 0.03 0.01 240 0.04 0.12 calcStats

16.67 0.04 0.01 8 1.25 1.25 calcSummaryData

16.67 0.05 0.01 7 1.43 1.43 write

16.67 0.06 0.01 mcount

0.00 0.06 0.00 236 0.00 0.00 tzset

0.00 0.06 0.00 192 0.00 0.00 tolower

0.00 0.06 0.00 47 0.00 0.00 strlen

0.00 0.06 0.00 45 0.00 0.00 strchr

0.00 0.06 0.00 1 0.00 50.00 main

0.00 0.06 0.00 1 0.00 0.00 memcpy

0.00 0.06 0.00 1 0.00 10.11 print

0.00 0.06 0.00 1 0.00 0.00 profil

0.00 0.06 0.00 1 0.00 50.00 report

2.1.2 Identifying Hotspots

In the example above, we can clearly see that the function genTimeStep() takes one-third

of the total running time of the application. This should be our first candidate function

for parallelization. Section 2.1.3 discusses the potential benefit we might expect from

such parallelization.

It is worth noting that several of the other functions in the above example also take up a

significant portion of the overall running time, such as calcStats() and

calcSummaryData(). Parallelizing these functions as well should increase our speedup

potential. However, since APOD is a cyclical process, we might opt to parallelize these

functions in a subsequent APOD pass, thereby limiting the scope of our work in any

given pass to a smaller set of incremental changes.

2.1.3 Understanding Scaling

The amount of performance benefit an application will realize by running on CUDA

depends entirely on the extent to which it can be parallelized. Code that cannot be

sufficiently parallelized should run on the host, unless doing so would result in

excessive transfers between the host and the device.



High Priority: To get the maximum benefit from CUDA, focus first on finding ways

to parallelize sequential code.

By understanding how applications can scale it is possible to set expectations and plan

an incremental parallelization strategy. Section 2.1.3.1 describes strong scaling, which

allows us to set an upper bound for the speedup with a fixed problem size. Section

Application Profiling

www.nvidia.com

CUDA C Best Practices Guide DG-05603-001_v4.1 | 11

2.1.3.2 describes weak scaling, where the speedup is attained by growing the problem

size. In many applications, a combination of strong and weak scaling is desirable.

2.1.3.1 Strong scaling and Amdahl’s Law

Strong scaling is a measure of how, for a fixed overall problem size, the time to solution

decreases as more processors are added to a system. An application that exhibits linear

strong scaling has a speedup equal to the number of processors used.

Strong scaling is usually equated with Amdahl’s Law, which specifies the maximum

speedup that can be expected by parallelizing portions of a serial program. Essentially, it

states that the maximum speedup S of a program is:

  



󰇛  󰇜  





Here P is the fraction of the total serial execution time taken by the portion of code that

can be parallelized and N is the number of processors over which the parallel portion of

the code runs.

The larger N is (that is, the greater the number of processors), the smaller the P/N

fraction. It can be simpler to view N as a very large number, which essentially

transforms the equation into

= 1 / (1

). Now, if ¾ of the running time of a sequential

program is parallelized, the maximum speedup over serial code is 1 / (1  ¾) = 4.

In reality, most applications do not exhibit perfectly linear strong scaling, even if they do

exhibit some degree of strong scaling. For most purposes, the key point is that the larger

the parallelizable portion P is, the greater the potential speedup. Conversely, if P is a

small number (meaning that the application is not substantially parallelizable),

increasing the number of processors N does little to improve performance. Therefore, to

get the largest speedup for a fixed problem size, it is worthwhile to spend effort on

increasing P, maximizing the amount of code that can be parallelized.

2.1.3.2 Weak scaling and Gustafson’s Law

Weak scaling is a measure of how the time to solution changes as more processors are

added to a system with a fixed problem size per processor; i.e., where the overall problem

size increases as the number of processors is increased.

Weak scaling is often equated with Gustafson’s Law, which states that in practice, the

problem size scales with the number of processors. Because of this, the maximum

speedup S of a program is:

    󰇛  󰇜󰇛  󰇜

剩余79页未读，继续阅读

i_ckone

粉丝: 0
资源: 4

CUDA C编程最佳实践4.1：评估、并行与优化部署详解

CUDA C Best Practices Guide

CUDA_C_Best_Practices_Guide

NVIDIA CUDA C Programming Best Practices Guide Version 2.3

BMIDE Best Practices Guide

opencl best practices guide

Intel FPGA SDK for OpenCL Best Practices Guide

Avoiding Pitfalls in Monte Carlo Simulation in MATLAB: A Best Practices Guide

Navicat Connection to MySQL Database: Best Practices Guide for Enhancing Database Connection ...

CUDA_C_Best_Practices_Guide_cuda_GPU_

CUDA_C_Best_Practices_Guide.pdf

最新资源