但若是一般中小规模的终端从业者或方案设计业者，可能就很难采取上述方式，此时就必须要使用标准架构，但这么一来和那些资金充足的厂商之间的差距是不是就无法拉近了？其实也不用担心，目前针对移动应用的计算加速结构其实还有不少的选择，即便不自己设计芯片，市场上也可以找到不少现成方案。

当然，一般常见的 DSP、FPGA 都已经相当成熟，也有不少供货商提供相关方案，不过这些方案在机器学习，或者是 OpenCL 之类的支持方面并不如主流 GPU 那样积极。所以，采用这类的方案必须要有心理准备。

但以绝对性能而言，这类方案其实不会逊色于 GPGPU，甚至在功耗、性能均衡性方面要有过之而不及。回过头来看 GPGPU 计算，其在 PC 及服务器平台上的普及，主要还是 CUDA 与相关生态的推波助澜，而非绝对性能的优势。

但必须注意的是 Google 在其移动平台上大力推广 Render 这个自有通用计算标准，而不采用 OpenCL，有部分原因是因为芯片方案商所销售的专用计算加速架构（比如芯片中整合了 DSP 或者其他多媒体计算加速单元）多半都是封闭的，不为开发商提供标准的开发工具包，导致芯片中可能有部分的区块的利用效率极低，因此造成运算性能的浪费，比如高通过去就是如此。

但不利用既有的成熟开放标准去达到同样目的，而是采用封闭标准，最后会不会变成芯片商也被 Google 绑架？以后相关计算加速单元的设计都要遵照 Google 的标准？这也是令业界深感忧虑的问题。

Render 有其应用上的优势，在 Google 的平台上可以发挥极高的性能，且不同处理器之间的兼容性也很高，不用担心不同方案商采用的加速架构不同，这一点上要优于 OpenCL。但应用开发上明显比标准 OpenCL 要复杂不少，且因为是全新的 API，使用者需要时间去学习适应，这可能会拉长应用开发周期。

此外，OpenCL 的好处就是转换平台方便，即便是针对 Android 平台开发，也不用担心把程序代码转换到 PC 或其他平台上会遇到问题。当然，iOS 就不用想了，苹果有自己的规矩。

在移动计算平台上使用机器学习，乍看之下选择不少，但实际上可用方案比较有限。Google TPU 这类针对性很强的架构，在相对性能上表现肯定是最好的，但相较于 GPGPU 的通用性，可能会有应用弹性较差的缺点。

另外，DSP 和 FPGA 虽也是被业界广泛采用的架构，但移动计算平台上的机器学习对这些架构而言还是相当新颖的应用，可能在开发环境方面尚需时日才会趋于成熟。

就目前而言，CPU 与 GPGPU 是立即可用的计算资源，如需要快速投入实战，这两种计算架构都可以胜任，但考虑到未来的应用需求以及复杂度的变化，不同类型的架构还是有各自的优缺点。不论是各自使用，或搭配混用，业界应针对应用场景做全盘考量。

-End-