openmlsys-zh
openmlsys-zh copied to clipboard
openmlsys
Chapter 7内容讨论
感谢各位的付出。 { 7.2.2 Shared Memory 的访存几十个cycle，而且还受指令依赖等其他因素制约。通用寄存器GPR的访问周期是依附于指令的，FFMA这种指令快的话从指令issue到拿到结果只需要~10 cycle而且指令间存在并行。因此Shared Memory与GPR没有可比性，如果硬要比的话GPR也远快与Shared Memory。 Shared Memroy作用范围似乎没讲（一个block之内）。 Local Memory好像没说。
7.3 似乎是没讲CUTLASS，实际工业场景自定义算子用CUTLASS较多。 指令集层面应该没提SASS。
7.3.3 Fragment映射到底层是寄存器而不是TensorCore上的某个区域，所以前后文字包括伪代码应该都有一些不准确的地方。
最后 GEMM优化最重要的应当是提高compute intensity（通俗理解就是计算读取比），制约GPU的因素个人经验主要是在于内存（包括global与shared）读写周期长而不是计算。大部分时间在优化访存流水线，这里似乎用较多篇幅在强调WMMA与TensorCore。 此外 合并访问，warp divergence这些concepts似乎也没提。 } Best regards, Jie
感谢各位的付出。 { 7.2.2 Shared Memory 的访存几十个cycle，而且还受指令依赖等其他因素制约。通用寄存器GPR的访问周期是依附于指令的，FFMA这种指令快的话从指令issue到拿到结果只需要~10 cycle而且指令间存在并行。因此Shared Memory与GPR没有可比性，如果硬要比的话GPR也远快与Shared Memory。 Shared Memroy作用范围似乎没讲（一个block之内）。 Local Memory好像没说。
7.3 似乎是没讲CUTLASS，实际工业场景自定义算子用CUTLASS较多。 指令集层面应该没提SASS。
7.3.3 Fragment映射到底层是寄存器而不是TensorCore上的某个区域，所以前后文字包括伪代码应该都有一些不准确的地方。
最后 GEMM优化最重要的应当是提高compute intensity（通俗理解就是计算读取比），制约GPU的因素个人经验主要是在于内存（包括global与shared）读写周期长而不是计算。大部分时间在优化访存流水线，这里似乎用较多篇幅在强调WMMA与TensorCore。 此外 合并访问，warp divergence这些concepts似乎也没提。 } Best regards, Jie
感谢回复！很专业。这一章节从设计上来说主要是想介绍硬件加速器相关的，而不是单独介绍GPU相关的硬件结构及性能优化方法。特别的，GEMM这个case中，我们更多的是想介绍如何通过一些编程原语去使能tensorcore这一硬件加速器，所以篇幅上也是围绕tensorcore去介绍。细节上的一些错误，随后我们会修复。再次感谢！
感谢耐心回复。 从实现来说通过个人更建议CUTLASS的层面给予相关篇幅介绍。因为如文章所说cuBlas这种库的灵活性极差且在corner case下性能较差；而wmma指令又关注的过于细节，导致容易实现过程首尾不相顾或缺乏代码抽象增加编程难度。实际实践中通常用CUTLASS这种既提供抽象封装不需要过度关注每一行的代码实现，又有足够灵活性（指支持算子融合及定制化算子如depthwise conv）与高性能（指能实现与cuBlas相接近的性能）的库开发算子。 Best regards, Jie
感谢耐心回复。 从实现来说通过个人更建议CUTLASS的层面给予相关篇幅介绍。因为如文章所说cuBlas这种库的灵活性极差且在corner case下性能较差；而wmma指令又关注的过于细节，导致容易实现过程首尾不相顾或缺乏代码抽象增加编程难度。实际实践中通常用CUTLASS这种既提供抽象封装不需要过度关注每一行的代码实现，又有足够灵活性（指支持算子融合及定制化算子如depthwise conv）与高性能（指能实现与cuBlas相接近的性能）的库开发算子。 Best regards, Jie
是的，我们正考虑做一些调整，后续添加这部分内容！再次感谢您的建议！
