Using Nsight to determine bank conflicts and coalescing

How can i know the number of non Coalesced read/write and bank conflicts using parallel nsight?

Moreover what sho开发者_如何学Culd i look at when i use nsight is a profiler? what are the important fields that may cause my program to slow down?

I don't use NSight, but typical fields that you'll look at with a profiler are basically:

• memory consumption
• time spent in functions

More specifically, with CUDA, you'll be careful to your GPU's occupancy.
Other interesting values are the way the compiler has set your local variables: in registers or in local memory.

Finally, you'll check the time spent to transfer data to and back from the GPU, and compare it with the computation time.

For bank conflicts, you need to watch warp serialization. See here.

And here is a discussion about monitoring memory coalescence <-- basically you just need to watch Global Memory Loads/Stores - Coalesced/Uncoalesced and flag the Uncoalesced.

M. Tibbits basically answered what you need to know for bank conflicts and non-coalesced memory transactions.

For the question on what are the important fields/ things to look at (when using the Nsight profiler) that may cause my program to slow down:

1. Use Application or System Trace to determine if you are CPU bound, memory bound, or kernel bound. This can be done by looking at the Timeline.

a. CPU bound – you will see large areas where no kernel or memory copy is occurring but your application threads (Thread State) is Green

b. Memory bound – kernels execution blocked on memory transfers to or from the device. You can see this by looking at the Memory Row. If you are spending a lot of time in Memory Copies then you should consider using CUDA streams to pipeline your application. This can allow you to overlap memory transfers and kernels. Before changing your code you should compare the duration of the transfers and kernels and make sure you will get a performance gain.

c. Kernel bound – If the majority of the application time is spent waiting on kernels to complete then you should switch to the "Profile" activity, re-run your application, and start collecting hardware counters to see how you can make your kernel's actual execution time faster.