我有一个运行复数的内核,我正在加载这样的值:
thrust::complex<float> x = X[tIdx];
其中X
在全局内存中。当我用nvvp
分析这个内核时,我发现内存带宽有限,而分析器建议我改进内存访问模式:
Global Load L2 Transactions / Access = 8,Ideal Transactions / Access = 4
反汇编确认此行确实分为两个32位加载,产生了一个跨步访问模式:
LDG.E R9, [R16];
LDG.E R11, [R16+0x4];
如何将其编译为单个64位加载?
我意识到这与this earlier question密切相关,但建议的解决方案(更改全局内存布局或使用共享内存)似乎不如64位负载理想。
NVidia developer blog建议将reinterpret_cast
建议使用float2
这样的矢量数据类型,但我对于如何使用指针别名规则感到有点朦胧。
我还必须承认这是一个理论上的问题。对于这个特定的内核,我受设备内存带宽的限制,因此将L2事务的数量减半不应该显着提高整体性能。但我预计在未来会使用更复杂的数字,如果有一个简单的解决方案,那么我现在就开始使用它了。
答案 0 :(得分:4)
这里的基本问题是编译器在生成向量加载和存储指令之前似乎需要一个类型的显式对齐规范。考虑以下简单的例子:
class __align__(8) cplx0
{
public:
__device__ __host__ cplx0(float _re, float _img) : re(_re), img(_img) {};
float re, img;
};
class cplx1
{
public:
__device__ __host__ cplx1(float _re, float _img) : re(_re), img(_img) {};
float re, img;
};
template<typename T>
__global__ void memsetkernel(T* out, const T val, int N)
{
int tid = threadIdx.x + blockIdx.x * blockDim.x;
int stride = blockDim.x * gridDim.x;
#pragma unroll 8
for(; tid < N; tid += stride) out[tid] = val;
}
template<typename T>
__global__ void memcpykernel(const T* __restrict__ in, T* __restrict__ out, int N)
{
int tid = threadIdx.x + blockIdx.x * blockDim.x;
int stride = blockDim.x * gridDim.x;
#pragma unroll 8
for(; tid < N; tid += stride) out[tid] = in[tid];
}
template<typename T>
void memcpy(const T* in, T* out, int Nitems)
{
int nthreads = 1024;
int nblocks = 13 * 2; // GTX 970 with 13 SM
memcpykernel<T><<<nblocks, nthreads>>>(in, out, Nitems);
cudaDeviceSynchronize();
}
template<typename T>
void memset(T* in, const T value, int Nitems)
{
int nthreads = 1024;
int nblocks = 13 * 2; // GTX 970 with 13 SM
memsetkernel<T><<<nblocks, nthreads>>>(in, value, Nitems);
cudaDeviceSynchronize();
}
int main(void)
{
const int Nitems = 1 << 24;
typedef cplx0 fcomplex0;
typedef cplx1 fcomplex1;
{
fcomplex0* in;
fcomplex0* out;
cudaMalloc((void **)&in, Nitems * sizeof(fcomplex0));
cudaMalloc((void **)&out, Nitems * sizeof(fcomplex1));
for(int i=0; i<10; i++) {
memset<fcomplex0>(in, fcomplex0(1.0f,1.0f), Nitems);
memcpy<fcomplex0>(in, out, Nitems);
}
cudaFree(in);
cudaFree(out);
}
{
fcomplex1* in;
fcomplex1* out;
cudaMalloc((void **)&in, Nitems * sizeof(fcomplex1));
cudaMalloc((void **)&out, Nitems * sizeof(fcomplex1));
for(int i=0; i<10; i++) {
memset<fcomplex1>(in, fcomplex1(1.0f,1.0f), Nitems);
memcpy<fcomplex1>(in, out, Nitems);
cudaDeviceSynchronize();
}
cudaFree(in);
cudaFree(out);
}
cudaDeviceReset();
return 0;
}
这里我们有两种自制的复杂类型,一种具有明确的对齐规范,另一种没有。否则它们是相同的。通过这个测试工具中的naïvemempcy和memset内核,我们可以检查每种类型的工具链的代码生成行为,并对性能进行基准测试。
首先是代码。对于具有显式8字节对齐的cplx0
类,编译器在两个内核中发出向量化加载和存储:
<强> memcpykernel 强>
ld.global.nc.v2.f32 {%f5, %f6}, [%rd17];
st.global.v2.f32 [%rd18], {%f5, %f6};
<强> memsetkernel 强>
st.global.v2.f32 [%rd11], {%f1, %f2};
而对于cplx1
情况,它不会:
<强> memcpykernel 强>
ld.global.nc.f32 %f1, [%rd16];
ld.global.nc.f32 %f2, [%rd16+4];
st.global.f32 [%rd15+4], %f2;
st.global.f32 [%rd15], %f1;
<强> memsetkernel 强>
st.global.f32 [%rd11+4], %f2;
st.global.f32 [%rd11], %f1;
考虑到性能,memset案例(CUDA 8发布工具包,带有Linux 367.48驱动程序的GTX 970)的性能存在非常重要的差异:
$ nvprof ./complex_types
==29074== NVPROF is profiling process 29074, command: ./complex_types
==29074== Profiling application: ./complex_types
==29074== Profiling result:
Time(%) Time Calls Avg Min Max Name
33.04% 19.264ms 10 1.9264ms 1.9238ms 1.9303ms void memcpykernel<cplx1>(cplx1 const *, cplx1*, int)
32.72% 19.080ms 10 1.9080ms 1.9055ms 1.9106ms void memcpykernel<cplx0>(cplx0 const *, cplx0*, int)
19.15% 11.165ms 10 1.1165ms 1.1120ms 1.1217ms void memsetkernel<cplx1>(cplx1*, cplx1, int)
15.09% 8.7985ms 10 879.85us 877.67us 884.13us void memsetkernel<cplx0>(cplx0*, cplx0, int)
Thrust模板化复杂类型没有明确的对齐定义(虽然它可能通过专业化,尽管这会在某种程度上打败目的)。因此,您唯一的选择是使用显式对齐创建自己的Thrust类型,或者使用另一种复杂类型(如CUBLAS和CUFFT使用的cuComplex
类型)。