描绘一下当地一家快餐公司的车道服务窗口。现在,假设有一排车在等候点菜,付账、取快餐。如果是一排车队在一个窗口如此等候,要比分两队在两个窗口耗时的多。由此吞吐量可能增加至近两倍。同样,该原理可以应用到通过数据级并行性执行的数据处理中。
数据根据处理器可处理的线程数划分为 N 个分区,以此来提高指令吞吐量。将数据分配到线程有
静态和
动态两种不同的分配方式。在静态分配方式中,迭代被分为大小为
chunk_size 的多个数据块,这些数据块按线程号码顺序以轮询方式静态地分配至组中的线程。注意,最后分配的数据块可能有较少的迭代。
当数据块数目不确定时,迭代空间将被分为近似相同大小的数据块,每个线程至多分配一个数据块。
在动态分配方式中,迭代被分为数据块大小和数据块数目,当线程要求时每个数据块才被分配。线程执行迭代的数据块,然后请求另一个数据块,直至再没有需要分配的数据块。注意,最后分配的数据块可能有更小数目的迭代。(OpenMP* 规范)静态分配形式的 CPU 费用很低,动态分配的 CPU 费用要稍高一些,但它提供了潜在的更好的工作负载平衡。以下是两个案例研究,采用的是在解决方案中执行数据并行性而获得显著的性能优势的游戏引擎。
案例研究:
Codemasters/SixByNine Colin McRae Rally 4*,原名为 Xbox*,它是一个在 PC 机上的不在路面驾驶模拟。为支持多平台运行,设计了 3D 引擎,但从建筑学层次很难改变游戏的设计。开发商的目的是找到一个引擎的具体部件来从数据级并行性获益,而不影响周围的代码。确定线程的部分是天气系统的计算,用以增加 3D 引擎产生粒子的数量。
天气系统由两个获益于数据级并行性的环路组成。第一个环路用来计算每个帧的新位置,第二个环路用来决定引擎产生离子在周围地形情况下的碰撞。为了在这些环路中执行线程,该游戏的开发商取消了粒子产生环路所有的全局变量,然后设置局部变量以避免数据使用时的竞态状态。通过使用带英特尔® 编译器的高性能可用设置,环路的速度性能增加了 5%。粒子系统内的数据级并行性使天气系统的速度又另外提高了 7-8%。开发商也使用了英特尔® 线程分析器,用它来检查线程应用中的负载不平衡情况以及所有同步开销。
利用优化的速度提升和个人电脑上超线程(HT)技术中更高的时钟速度,开发人员能够将受粒子影响区域的运行速度提升 4 倍,与游戏最初的 Xbox 版本相比,粒子的密度增加 8 倍。
这样,在游戏中就产生了更加出色的视觉效果。