当对一个程序进行加速的时候，很多时候需要预估出程序使用GPU加速后的加速比（比如你老板不懂GPU，或者甲方会问你预估加速比等等）。从大二接触GPU加速，到现在大概有6年时间，大大小小的项目也做了十几个，很多时候都需要事先回答加速比会有多少这个问题。这里简单的说一下自己的经验，欢迎各位大神指点。
文中的经验基于目前主流的显卡，比如GTX1080，最低也得是GTX9**系列的。
1.阿姆达尔定律
谈加速比，首先要先明白一个定律-
阿姆达尔定律
。该定律一般应用与CPU加速，可以总结为一句话-
程序中可并行代码的比例决定你增加处理器（总核心数）所能带来的速度提升的上限。
应用在GPU加速情景上比较简单，假设程序S由A和B两个步骤组成，现在对A步骤进行GPU加速，那么
GPU加速比=A步骤加速前的时间/A步骤加速后的时间
，而不是
加速前S的总时间/加速后S的总时间。
这个非常重要，因为很多人不懂GPU加速，他们往往只关注整个程序的加速效果。而对于一个完整的程序，很多都包括一些非常耗时的操作（比如读取图片等）。这种情况下就算你对程序中的某个步骤使用GPU加速到极致，整个程序可能只感觉快了一点点，这是非常不公平的。
2.估算加速比
下面将列出几种常见情况。其中CPU实现的大for循环是最耗时的，其次是资源（显存和句柄等）的申请，最后是核函数级别的优化。
（1）程序CPU实现，并行度高，数据依赖低
这是最理想的情况，常见于各种较简单的图像算法，比如二值化，细化等。简单来讲就是一个大for循环，循环之间没有数据依赖。这种情况下，加速比很容易就上10+倍。当图片较大时（比如1024*1024），上几十倍也是很容易的。
（2）程序GPU实现，但是资源管理差
这是次理想的情况，程序已经由GPU核函数或者调用GPU API实现，但是资源（显存和句柄的申请和释放等）管理比较差。比如流程比较算法的算法，显存和句柄在程序中使用时才申请。这种情况下，看资源申请所占的时间比例，不过一般加速比能到几倍就很不错了。
（3）程序GPU实现，但核函数实现比较差
如果资源管理也做的比较好，一般从核函数本身入手了。对核函数进行优化（使用共享内存，条件分支优化，合并核函数等），得到的加速比一般在2X以内，超过2X的情况并不多。
