《高性能CUDA C编程: 创建和调试性能CUDA C》

需积分: 0 16 浏览量更新于2023-12-16 收藏 307KB PDF 举报

The paper "Creating and Debugging Performance CUDA C" by W. B. Langdon delves into the various methods and best practices for testing, locating, and eliminating bugs in parallel general-purpose computation on graphics hardware (GPGPU) applications, with a specific focus on high-performance CUDA programming. The author provides insights into both generic debugging techniques as well as those tailored to stochastic bio-inspired techniques like genetic programming. The paper highlights the importance of efficient and effective debugging in CUDA C programming, emphasizing the need for thorough testing and bug identification to ensure the proper functioning of GPGPU applications. The author shares valuable software engineering lessons learned from practical experience with CUDA C programming, offering guidance on optimizing performance and leveraging the capabilities of nVidia hardware for high-speed parallel computation. Langdon's work provides a comprehensive overview of the challenges and strategies associated with creating and debugging performance-oriented CUDA C code, shedding light on the nuances of developing GPGPU applications that deliver maximum computational efficiency. The emphasis on bio-inspired techniques also adds a unique perspective, demonstrating how these methods can be effectively integrated into CUDA programming for specialized applications. In summary, "Creating and Debugging Performance CUDA C" presents a wealth of practical insights and best practices for developers and engineers working with CUDA C and GPGPU applications. The paper serves as a valuable resource for optimizing performance, debugging complex parallel computations, and harnessing the power of nVidia graphics hardware for efficient high-performance computing. Whether one is new to CUDA programming or seeking to enhance their proficiency, the guidance offered in this paper can greatly aid in navigating the intricacies of performance-driven GPGPU development.

14 W. B. Langdon

that the GPU can do and so are typically much more than your GPU kernel will

get in practice.

• It is worth considering how much computation is needed per data item. I.e. the

“arithmetic intensity”. Often in Bioinspired algorithms we are concerned with

computationally intensive tasks that most be done for every for every member

of a network, swarm or population but only a few bytes are needed to repre-

sent the individual. Thus arithmetic intensity is usually high. However if only a

few instructions are needed per word, arithmetic intensity should be considered

carefully at the design stage. Effectively arithmetic intensity is another way of

looking at the problem of communications bandwidth bottle necks.

GPU Chip

2.6 GBytes

Processors

84 Gbyte/Second

PCI

448

5.8Gbyte/S

6.1Gbyte/S

Fig. 3 Links from GPU chip to host computer via PCIe bus and to memory on the GPU board.

Fermi C2050.

• From your block level design locate its bottle neck. See Figure 3. We can try and

ﬁnd the limiting part of your design in advance of coding by estimating:

1. The number of bytes of data uploaded into your GPU.

2. The number of bytes from your GPU back to your PC.

3. How many times the PC interacts with the GPU (either to transfer data or to

start kernels).

4. Do the same for global data ﬂows from global memory into your kernel and

from it back to global memory. Assume you are going to code your kernel so

it uses registers rather than local memory.

5. In principle we could consider other bottle necks but already we are getting

into detail and relying on assumptions which may turn out to be wrong.

For GPUs connected to a traditional PC via a PCIe bus we can get a good esti-

mate of the time taken to transfer data across the PCIe by dividing the size of the

data to be passed by the advertised speed of the bus. Take the lower estimate of

your bus’s speed and your GPU’s PCI interface speed. Remember the speed into

the GPU can be different from the speed back from it. If you already have the

hardware, nVidia’s bandwidthTest program will report the actual speeds. (band-

Creating and Debugging Performance CUDA C 15

widthTest will also give you the maximum speed of transfers between global

memory inside your GPU.)

For PCIe transfers, with good coding, the estimates can be accurate enough. With

internal transfers so much will depend upon the details: how well the threads

overlap computation with fetching data, how effective are the various caches.

• Normally the ratio of the volume of PCIe data size to the size of PCIe data buffers

will give the number of times the operating system has to wake up your PC code

so that it can transfer data. Typically there are a few data transfers before and after

each time your GPU kernel software is launched. Usually the system overheads

of rescheduling your process and CUDA starting your kernel are both well under

a millisecond. Nonetheless if your design requires more than a thousand PCIe

I/O operations or kernel launches per second it is probably worth considering the

initiation overhead.

• This should have given you an idea of where the bottle neck is in your design and

if your design is feasible.

If the bottle neck is the GPU’s computational speed, then it probably makes sense

to proceed. It probably means your application is sufﬁciently compute intensive

that it needs to be run in parallel. If it still not going to be fast enough then a

redesign could consider a GPU upgrade, multiple GPUs and/or traditional code

optimisation.

If the bottle neck is bandwidth, which bus is limiting? Concentrate upon the

most constricting part of the design. There are two things to consider: passing

less through the bottle neck and making the bottle neck wider.

• In the case of the PCIe bus, only hardware upgrades can widen the bottle neck.

Can you compress your data in some way? Often a huge fraction of computer data

is zero. Do you need to pass so many zero’s? Can you pack data more tightly?

Can you use char rather than int? (Will the cost of compress/decompress be ex-

cessive?)

Does your application need so much data to be passed? Could you pass some of

it to the GPU once, when the application starts, and leave it on the the GPU to be

reused, rather than being passed to the GPU each time the kernel is used?

The host–GPU bottle neck can be critical to the whole GPU approach. The above

calculations have the advantage of often being feasible to estimate in advance

and typically applications really do get the host–GPU advertised bandwidth. So

you can get good estimates of its impact on your application at the design stage.

However the PCIe bus is inﬂexible. Unlike internal GPU buses, there is no coding

to increase its bandwidth. If your design requires 110% of the PCI’s bandwidth

it is not going to get more than 100%. At this point many GPU designs fail and

alternatives must be considered.

• As already mentioned with internal GPU transfers design stage calculations are

much trickier. Perhaps consider algorithm or design level changes, e.g. splitting

kernels, spreading the work differently across different kernels. Again can the

bottle neck be made wider? E.g. by larger data transfers and/or coalesced trans-

fers. Remember advertised ﬁgures and data reported by bandwidthTest have al-

ready taken into account such optimisations.

剩余43页未读，继续阅读

TracelessLe

粉丝: 6w+
资源: 468

《高性能CUDA C编程: 创建和调试性能CUDA C》

NVIDIACUDA统一计算设备架构编程指南-CUDAProgrammingGuide.pdf

qt-creator-opensource-windows-x86_64-4.14.2.exe

[Linux英文原版图书系列].PRENTICE_HALL-Linux_Debugging_and_Performance_Tuning_Tips_and_Techniques.part1

Amacom_-_Debugging_-_The_Nine_Indispensable_Rules_For_Finding_Even_The_Most_Elusive_Software_And_Hardware_Problems.pdf

Advanced_Apple_Debugging_&_Reverse_Engineering_v1.0.pdf.zip

Linux_Debugging_and_Performance_Tuning_Tips_and_Techniques.rar

Linux_Debugging_and_Performance_Tuning_Tips_and_Techniques.part2

CCNP_TSHOOT_642-832_Quick_Reference.pdf

eclipse_4.7-jee-oxygen-3a-win32-x86_64.zip

Advanced_Apple_Debugging_&_Reverse_Engineering_v2.0.pdf

最新资源