|
通用计算似乎能够实现CPU和GPU一起运算，但其实由于GPU并不能读懂CPU的指令，因此他们之间的工作方式不是“合体”，而是“各自为政”。因此实际上OpenCL，或者其他通用计算，都有个任务分工的问题。如果我们点开LuxMark让它全屏化，就会看到软件实际把100%的工作划分成了46.4%和53.6%分别给了GPU和CPU去处理，让它们各自完成自己的工作，然后把结果汇总呈现给用户。 问题来了，如果GPU的处理效率低下，那么情况就会是CPU处理完了GPU还在处理，拖慢了整体的进度；而另一种状况，就是我们上面遇到的，GPU的处理效率比CPU更高，把任务分给CPU做，还不如直接把所有任务给GPU做。 ●这是说现在GPU能够秒杀CPU了吗？ 越加速越慢的问题出在CPU处理效率上，那么是否说GPU已经足以秒杀CPU，以后大家装电脑就买强力显卡搭配垃圾CPU就行了呢？完全不是，这只是“术业有专攻”，它们有着不同的处理方式，如果论规格，如逻辑判断力、运算精度，CPU还是要比GPU更强的。那么它们是怎样运作的呢？
我们以扫雷为例来分析，如果能通过电脑自己运算来扫雷，那么CPU的处理风格就像上图所示，它是线性的，而且是快速的，它快速处理完一截雷区，然后就会再处理同样大小的另一截雷区，直到所有雷区全部处理完。
而GPU方面，由于核心数量极多，因此其处理是大规模并发的，形成的处理效果就好像一个面，一块一块雷区地处理，但是单个雷块的处理速度其实不如CPU，而且也不会因应雷区的形状自动变换处理面的形状，比较僵化，全凭数量形成面去取胜。 如果任务真的就像上面那样，是一个大面积的雷区需要扫雷，那么很明显，GPU的面式处理风格会更有优势。而如果任务是一个只有两行的长条状的雷区，那么GPU的面处理就会有很大部分用不上，结果就是CPU的处理风格更有优势。实际上，大部分任务处理都要求更好的灵活性，而不是更大的覆盖面，因此，说GPU完全秒杀 CPU并不合理。 ●怎样避免出现这种越加速越慢的情况？
如果要坚持CPU+GPU一起运算，怎样避免这种越加速越慢的情况呢？我们来看一个三代i5成功加速的案例，三代i5单CPU默认LuxMark成绩为346分，而加上其自带的核显2500之后，成绩稍微得到了提升，变成了385分，这还是得益于正确的任务量分配。 没错，如果软件能够根据CPU和GPU之间的性能强弱来调整任务量的分配，其实CPU+GPU还是能在大多数通用计算适用场合下实现加速的。比如LuxMark运行的详细参数中就可以看到一个“Prf Idx”的数据，这个就是Performance Index性能指数，通过这个指数，软件能够判断CPU和GPU大概的性能强弱对比，从而按性能大致分配好任务，实现加速，而A6+D7850加速失败，深层原因其实在于A6有个错误的性能指数( 1.15 )，比HD7850( 1.0 )更高，却实际性能更差，因此效果就是非但没有加速，速度还拖得比GPU自己算更慢了。 怎样让软件知道硬件之间的强弱对比呢？建立一个在线的性能指数数据库可能会是最可行的办法。但是这个数据库的建立有个大难点，就是怎样收集相关数据，因为OpenCL面向广泛、不定的硬件，软件不运行过是不会知道哪个硬件的性能更强的，而从硬件厂商角度出发，这种大规模硬件性能对比数据库实在太直接，对于市场营销竞争会有负面效果，因此不会免费提供硬件来做测试，那么跑测试的任务，就自然而然落到各位用户身上了——这不大科学。 因此综合来说，短期之内“越加速越慢”还是个很难根治的难题，把性能的希望寄托在CPU身上还是比较靠谱的。 总结：硬件加速技术虽然能大幅优化部分应用的处理效率，具有很好的应用前景，但它现在其实还处于比较初级的阶段，很多技术难题一时间还不大可能解决，未来如果通用计算变得大行其道，也不会是这两三年内的事，到时候大家的电脑早换代了，因此对于目前来说，高性能的CPU还是非常有必要的。
|
正在阅读：越加速反而越慢？通用计算实用性浅析越加速反而越慢？通用计算实用性浅析
2012-12-17 00:15
出处：PConline原创
责任编辑：liganlin
键盘也能翻页，试试“← →”键
| 本文导航 | ||
|
