（软件工程）GPU并行软件开发指北

事先声明，本篇博文中不涉及任何技术，原理和代码。如果想知道GPU开发实践方法，请直接查阅OpenCL与CUDA开发手册。

在“GPU并行软件开发指北”这篇博文中，我仅仅是想谈论一下GPU平台上的软件开发的方法论。当然，我也不是行业大牛，撰写不了能够刊登在三大学报的指南性论文，故而只能谈一谈在GPU平台上开发中所遇到的坑，所以只能指北。

“快不快”与“对不对”

强耦合乃软件工程第一天敌

异构计算的核心是设备

不要太迷信理论加速值

“快不快”与“对不对”

既然要使用GPU平台来做加速，那么十有八九是在计算过程中遇到了计算时间的瓶颈。通过多数的案例可以知道，GPU确确实实的能够削减很多工程计算过程中的计算开销，但快的前提是保证足够计算精度，不然就会出现以下情况：

那么，算不对还要这GPU有何用呢，还不如打算盘来算。。。

所以，才完成一次工作后，一定要对数据进行测试。最简单好用的方法就是做减法，测算GPU丢的精度值。

当然，这样做的工作量会比较大，因为我们要面对的就是很耗时的应用，这样就很开心了。每测一次，就可以打一盘游戏（又有借口耍手机了）。

如果将多个CPU函数改为kernel函数后再来测试，不出BUG则已，一出BUG就得版本回滚。

强耦合乃软件工程第一天敌

毋容置疑的一个结论就是----软件设计模式是软件工程设计的集大成者，Erich等四人的核心思路就是给予工程师们一套可复用的软件设计模式。我个人认为策略模式简直就是为算法工程师们量身定做的，但是在当今敏捷开发的潮流下，一般来说软件开发出来，能用就行了。然后，新来的开发者就在一堆强耦合的代码上继续再加加功能，最后就成了一个摇摇欲坠的大楼。

我在这里肯定不是讨论软件工程的，当CPU代码需要迁移到GPU上时的首要任务就是为函数解耦。如果软件框架的耦合度过高会使得代码修改无从下手，况且在解耦的同时还需要分析函数中的运算哪里有数据依赖，哪里适合并行。

为CPU代码解耦的时候，还是应该一步一步来，反复测试。一个大大的框架梦想是可以有的，但是工程实践还是要脚踏实地。

值得一提的时，在早期的开发版本中，不要将device中分配的变量贯穿整个软件的声明周期，否则遇到串行度较高的计算过程时还要重新调代码。即用即释放的操作方法可以规避很多奇奇怪怪的问题。

异构计算的核心是设备

不要在不了解设备的情况下直接上手改程序。

对设备参数的足够了解才能保证开发过程足够流畅。我曾经在某问答网站上还有问PGI编译器能否部署在游戏卡上，估计这个大兄弟需要了解下游戏卡是否为Tesla架构。除此之外，GPU软件开发可以灵活的选择计算卡片，如果实在云平台上做开发，需要时常小心隔壁做深度学习开发的朋友是不是抢完了你的计算资源，因为这些框架可能会直接喊出整个显存的变量空间（说的就是你TF）。

不要太迷信理论加速值

可是具体问题需要具体分析，开发过程一定要实事求是。

例如官方说明中说纹理内存就比较适合跨址的计算操作，片上内存可以有效的减少读写开销等。这些加速方案一定要测试之后才能判断出是否适合于当前的并行软件开发。软件开发是工程实现，我们只能是在出现问题后去分析以及解释问题，而不是纯粹依靠数学模型或算法原理来推测。

差不多先写这些，以后遇坑接着写。

图片皆选自网络，侵权请告知，必删。