RidgeRun CUDA Optimisation Guide/Optimisation Workflow/Tools: Difference between revisions

From RidgeRun Developer Wiki
(Created page with "<noinclude> {{RidgeRun CUDA Optimisation Guide/Head|previous=|next=|keywords=}} </noinclude> Continuing with the workflow, profiling and debugging tools are crucial for optim...")
 
mNo edit summary
Line 4: Line 4:


Continuing with the workflow, profiling and debugging tools are crucial for optimisation. Having basic knowledge is critical for finding optimisation opportunities and debugging issues that can arise.
Continuing with the workflow, profiling and debugging tools are crucial for optimisation. Having basic knowledge is critical for finding optimisation opportunities and debugging issues that can arise.
== CUDA debugger and checker ==
Most of the issues can be identified by using ''execution tracing'' (a.k.a placing printf everywhere). However, that's suboptimal in some cases and, for debugging optimisation issues, it is better to know where they are and how to fix them without working around them. Additionally, it is a good practice to identify the issues that the original application has before any attempt. It will help you to (1) fix them, and (2) avoid headaches when introducing the optimisations.
Additionally, without implementing any change, it is necessary to profile the application to identify the current hotspots and bottlenecks. There are three possible paths to follow when optimising: (1) the GPU computation, (2) the memory access, and (3) the I/O. Depending on your profiling results, you should check them.


<noinclude>
<noinclude>
{{RidgeRun CUDA Optimisation Guide/Foot||}}
{{RidgeRun CUDA Optimisation Guide/Foot||}}
</noinclude>
</noinclude>

Revision as of 18:19, 6 October 2021




  Index  




Continuing with the workflow, profiling and debugging tools are crucial for optimisation. Having basic knowledge is critical for finding optimisation opportunities and debugging issues that can arise.

CUDA debugger and checker

Most of the issues can be identified by using execution tracing (a.k.a placing printf everywhere). However, that's suboptimal in some cases and, for debugging optimisation issues, it is better to know where they are and how to fix them without working around them. Additionally, it is a good practice to identify the issues that the original application has before any attempt. It will help you to (1) fix them, and (2) avoid headaches when introducing the optimisations.

Additionally, without implementing any change, it is necessary to profile the application to identify the current hotspots and bottlenecks. There are three possible paths to follow when optimising: (1) the GPU computation, (2) the memory access, and (3) the I/O. Depending on your profiling results, you should check them.



  Index