cudapro case study notefloat4 alignment and class案例研究对齐类rev2.pdfVIP

：

：：

本文档内容由ice根据CUDAProfessional讨论整理而来。简要经过

和结论由ice总结并写在本文前部，脱水版讨论原文附于其后。ice不保证该总结100%正确，

参考，请以讨论原文为准。讨论原文中，各人观点由发言的各人负责，发言内容的所有

权益亦归发言的各人享有。欢迎参考，讨论。

如非性学术组织和个人需要学习和使用文中内容，请给予合适的和致谢。

如其他性质组织和团体需要使用文中内容，请联系文中的发言的群友，取得。

其他未尽事宜，请联系CUDAProfessional管理团队。

2012-5-5第一版根据当日上午讨论内容总结整理，第一次发布。

2012-5-5第二版邀请神秘琪琪审阅了第一版，并对该问题作了讨论和验证，整理为第

二版。和琪琪的脱水版讨论附于最后。对琪琪的大力支持表示由衷的感谢。

2012-5-5第二版修正版（rev2.1）由琪琪大人统稿并做了修正和删减。

和结论：

和结论：

事情经过：[]-石头(736183739)发现他的某个class在cpp文件内编译后的大小和在cu

内编译后的大小不同，造成赋值错位，并验证了这一点。（琪琪：--正常。谁让他是.cpp

而不是.cu呢。这导致文件不会被nvcc过一遍的。联合编译不会出问题）经过讨论，风辰认

为“float4在在设备端是16字节对齐的，如果是vs或gcc则是4字节，你可以使用gcc的

attribute对齐到16字节，vs也应该有相关的设置”。（琪琪：“--这个要看情况下。如

果被nvcc过了一遍了，是16B对齐的。”并通过实测得知，.cu里的hostcode，float4对齐

到16B；32-bit.p,VC下，float4对齐到4B；--64bit的.p，VC下，float4对齐到16B。

也就是只会在分开编译，且是32位VC的情况下发生。64bit的VC分开编译结果和参与混

合编译的一样。）同时ice发现programmingguide4.2中也分别提到过相关内容。

B.3.1

。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

结论：在使用class/struct的时候要十分内建变量在device端和host端由于对齐约定不

同，造成的实际位置不同，进而产生错误。

经琪琪指正，结论重新整理为：

hostcode用.cu的话，NVCC会在将host端code交给hostcompiler之前做修改，被NVCC

过滤后的hostcode里的struct实际上是带有__attribute__的对齐的属性的（某些情况下可能

是作为编译器的对齐参数，例如-malign-double，在-m32的gcc下的时候）（或者将某些，这

将指导hostcompiler采用和NVCC一致的对齐方式，如此怎么用都无需考虑。）

如果是不能联合编译的情况（如C#），或者是使用driverAPI，那么请手工根据对应的

编译器进行对应形式的“align”。

如果是NVCC下，因为某种需要调整对齐模式，建议使用NVCC自带的__align__(n)，

这是一个自动转换的宏，会根据hostcompiler是VC还是GCC，是32位还是64位目标代

码编译，而自动转换为合适的形式。

任何调用/使用.cu里的东西的，都推荐在另外一个.cu里。否则就算能编译，结果可能异

常。

同时实验得知，.cu中的float4是自动对齐到16B的，.p在64bitVC下恰好也是16B

对齐，而在32bitVC下是4B对齐。

脱水版原文：

脱水版原文：

[]-石头(736183739)9:30:57

VC里边遇到诡异的bug

[]-石头(736183739)9:31:05

一个结构体A

[]