我相信以下代码执行典型的
的工作流程。
我发现非常奇怪的是,当我使用NSight Profiler的Trace Application选项时,在报告中打开了“堆栈跟踪”,我发现最昂贵的操作是以粗体显示的行只是那条线,而其他memoCopy操作几乎只占这个memoCopy操作的10%或更少。
这是因为它是调用内核之后的第一行,因此分析器以某种方式将某些同步成本包含在此特定memoCopy操作的成本中吗?
对于像我正在处理的那个问题,这需要非常频繁的同步并将结果“返回”给主持人,有人能提供一些关于最佳实践的一般建议吗?我特别考虑了两个选项,我不确定最终会有什么帮助
{
int numP = p_psPtr->P.size();
int numL = p_psPtr->L.size();
// Out partition is in Unit of the Number of Particles
int block_dim = BLOCK_DIM_X;
int grid_dim = numP/block_dim + (numP%block_dim == 0 ? 0:1);
vector<Particle> pVec(p_psPtr->P.begin(), p_psPtr->P.end());
Particle *d_part_arr = 0;
Particle *part_arr = pVec.data();
HANDLE_ERROR(cudaMalloc((void**)&d_part_arr, numP * sizeof(Particle)));
HANDLE_ERROR(cudaMemcpy(d_part_arr, part_arr, numP * sizeof(Particle), cudaMemcpyHostToDevice));
vector<SpringLink> lVec(p_psPtr->L.begin(), p_psPtr->L.end());
SpringLink *d_link_arr = 0;
SpringLink *link_arr = lVec.data();
HANDLE_ERROR(cudaMalloc((void**)&d_link_arr, numL * sizeof(SpringLink)));
HANDLE_ERROR(cudaMemcpy(d_link_arr, link_arr, numL * sizeof(SpringLink), cudaMemcpyHostToDevice));
Point3D *d_oriPos_arr = 0;
Point3D *oriPos_arr = p_originalPos.data();
HANDLE_ERROR(cudaMalloc((void**)&d_oriPos_arr, numP * sizeof(Point3D)));
HANDLE_ERROR(cudaMemcpy(d_oriPos_arr, oriPos_arr, numP * sizeof(Point3D), cudaMemcpyHostToDevice));
Vector3D *d_oriVel_arr = 0;
Vector3D *oriVel_arr = p_originalVel.data();
HANDLE_ERROR(cudaMalloc((void**)&d_oriVel_arr, numP * sizeof(Vector3D)));
HANDLE_ERROR(cudaMemcpy(d_oriVel_arr, oriVel_arr, numP * sizeof(Vector3D), cudaMemcpyHostToDevice));
Point3D *d_updPos_arr = 0;
Point3D *updPos_arr = p_updatedPos.data();
HANDLE_ERROR(cudaMalloc((void**)&d_updPos_arr, numP * sizeof(Point3D)));
HANDLE_ERROR(cudaMemcpy(d_updPos_arr, updPos_arr, numP * sizeof(Point3D), cudaMemcpyHostToDevice));
Vector3D *d_updVel_arr = 0;
Vector3D *updVel_arr = p_updatedVel.data();
HANDLE_ERROR(cudaMalloc((void**)&d_updVel_arr, numP * sizeof(Vector3D)));
HANDLE_ERROR(cudaMemcpy(d_updVel_arr, updVel_arr, numP * sizeof(Vector3D), cudaMemcpyHostToDevice));
int *d_converged_arr = 0;
int *converged_arr = &p_converged[0];
HANDLE_ERROR(cudaMalloc((void**)&d_converged_arr, numP * sizeof(int)));
HANDLE_ERROR(cudaMemcpy(d_converged_arr, converged_arr, numP * sizeof(int), cudaMemcpyHostToDevice));
// Run the function on the device
handleParticleKernel<<<grid_dim, block_dim>>>(d_part_arr, d_link_arr, numP,
d_oriPos_arr, d_oriVel_arr, d_updPos_arr, d_updVel_arr,
d_converged_arr, p_innerLoopIdx, p_dt);
**HANDLE_ERROR(cudaMemcpy(oriPos_arr, d_oriPos_arr, numP * sizeof(Point3D), cudaMemcpyDeviceToHost));**
HANDLE_ERROR(cudaMemcpy(oriVel_arr, d_oriVel_arr, numP * sizeof(Vector3D), cudaMemcpyDeviceToHost));
HANDLE_ERROR(cudaMemcpy(updPos_arr, d_updPos_arr, numP * sizeof(Point3D), cudaMemcpyDeviceToHost));
HANDLE_ERROR(cudaMemcpy(updVel_arr, d_updVel_arr, numP * sizeof(Vector3D), cudaMemcpyDeviceToHost));
HANDLE_ERROR(cudaMemcpy(converged_arr, d_converged_arr, numP * sizeof(int), cudaMemcpyDeviceToHost));
}
答案 0 :(得分:2)
特定的cudaMemcpy
调用需要更长时间,因为它一直等到内核完成。如果在内核之后添加cudaDeviceSynchronize
,那么cudaMemcpy
调用的感知执行时间应该与所有其他调用一致。 (当然,您所看到的额外时间将用于cudaDeviceSynchronize
电话)。
然而,你在cudaDeviceSynchronize
花费的时间有点基本费用,你无法真正解决;如果你需要使用内核的输出,那么你必须等到内核完成执行。由于内核启动是异步的,因此您可以在内核运行时执行不相关的语句;但是,在您的情况下,下一个调用是将内核的一个输出复制到主机内存,因此您必须等待内核完成才能获取数据。
如果您的程序允许,您可以尝试将内核启动和内存传输拆分为块并使用不同的流启动它们,尽管这可能性取决于几个因素(即您的内核可能无法很好地分解为独立的部分)。如果你选择这条路线,最好的情况就是这样(取自the CUDA Best Practices Docs)
这将允许您将数据传输与内核执行重叠,这有助于隐藏一些数据传输成本。您可以通过零拷贝实现类似的异步,只需预先警告这些传输不会被缓存,因此根据您的内核访问模式,您最终可能会获得较低的吞吐量。