从本篇开始，我们将出一系列文章面向CUDA开发者一起来解读《CUDA C
Best Practices Guide》 （CUDA C最佳实践指南）
大家可以访问：https://docs.nvidia.com/cuda/cuda-c-best-practices-guide/index.html 来阅读原文。
这是一本很经典的手册。
什么是APOD开发模型？
在这本指南的开篇，就介绍了APOD开发模型，即：Assess, Parallelize, Optimize, Deploy
直接的说, 它适合将已有的老代码, 改成CUDA加速版本的过程，并不适合从头开始的新设计和开发的CUDA项目。实际上手册前面一直在说, 如何有效的将一个老项目, 进行CUDA化改造和CUDA加速。
这手册有点教条, 但人家上去也说了, 要交给大家"教条化"的实践方式. 因为先跟随教条走, 你会在经历1-2个项目后, 就有了逐渐的写CUDA项目的经验, 知道了CUDA项目的各方面需要注意的事项, 考虑的因素, 代价的衡量, 等等. 有了这个经验后, 你才能考虑在下一个新的项目中, 直接上去就考虑CUDA的存在。
所以从老项目开始, 进行CUDA化改造, 进行具体的教条式的改造体验, 是一种很好的CUDA实践方式. 只有当你充分熟悉后, 有了自己的发挥后, 再考虑上去的设计。这其实就非常像我们上学学习计算机的样子了. 先死记课本, 对课本中提到的内容进行实践, 然后再有选择的加强对一些方面的认识, 和有选项的忘记一些课本中不贴切的地方, 其实是最快的进步方式. 因为你将在站在了写这本实践手册的人的经验的肩膀上了, 直接模拟跟随,选择性的吸收, 比较快一点。
所以我们就从开头这里看看, 这手册(实践指南)能带给我们什么样的教条.
APOD开发的步骤
APOP是一个含有4个步骤：
- A=评估
- P=并行化其中的某部分
- O=有了基本的并行化实现后, 进行例如kenrel优化 -
- P=发行/发布处理结果, 享受速度提升)的循环.
注意这里是一个循环. 因为该实践并不要求我们一口吃个胖子, 而是每次可以只并行化当前的最主要矛盾, 即如果一个老代码/项目, 有10处运行缓慢的地方, 我们先找出其中的最主要影响速度/最慢的地方, 而暂时忽略剩下9处, 这样先将最影响速度的, 最主要的矛盾揪出来, 解决, 即可完成一轮CUDA化改造.
这样做的好处是：团队可以随时看到工作成果, 而不至于一次性的积攒太多的优化任务而累死, 被老板催死, 见不到明天的曙光而放弃项目。
这种实践的一轮就是一次APOD(评估揪出最矛盾点--尝试并行--尝试优化--发行享受成果)的过程。别忘记了, 刚才的举例中, 实践上可能还剩下9/10处次要的地方, 当最重要的1/10已经解决后, 这9个里面依然可以选出来一个剩下的下一轮的最主要矛盾, 然后下一轮依然可以继续解决它。如此反复, 直到该代码/项目能基本上被CUDA改造完毕. 这样每个轮回都可以看到成果, 就能够让项目持续下去. 实践手册是让我们先从如何评估, 即找到矛盾点开始的. 我们稍后将谈论一下这个.
但在开始之前, 我们要给先认为这个流程很简单的读者们一个警告, 在实际的时间操作中, 可能并没有这样的容易, 因为很多时候, 找到主要矛盾点很容易, 但是想并行化可能很难, 或者说不那么容易.
不那么容易在于, 你可能需要具有一定的CUDA Kernel的写作经验, 或者熟悉几个基本的CUDA库, 才知道如何得到/弄到一个并行化的GPU等效代码(kernel/库函数调用)，CUDA Kernel和相关知识, 你应当已经阅读过了CUDA C编程指南（还记得我们一年多前做的《CUDA学习１００天》么）, 如果没有, 建议先看这里. 而相关的CUDA库, 例如cublas, cudnn, cufft之类的, 如果你已经在你的老代码中使用了类似的库(例如fftw(一个经典的CPU上的fft库), 或者各种blas库), 则也可以尝试替换. 这点是在实践指南中提到的. 也就是说, 在你评估找出最缓慢的点之前, 你应当先具备解决这个点的GPU相关方面的技能, 否则, 不建议你此时看这个实践手册(而你应当回头看我们之前的那个编程指南手册https://bbs.gpuworld.cn/index.php?board=65.0 )。
因为显然么, 你不具备技能, 找出来你也没办法应付, 只能瞪着眼看, 所以为了不打击你, 我们先提前给出这个警告.
今天我们就先开场，下一篇我们在针对这四个步骤稍微做个延展。敬请大家关注。
