并行编程提升单芯片多处理性能

在指定的实现技术下，要将单个处理器性能发挥到极致并不容易。更快的时钟，更深的管线和更大的缓存都会导致占用更大的硅片面积和功耗开销，并有可能使得最后10%的性能增益化为乌有。有些时候没有其它选择，只能靠提高时钟速率，升级电源和冷却子系统。但是将处理任务分配到多个处理器的做法可以最大程度提升整体性能极限，处理器设计也会更简单、更高效。

当今的许多嵌入式系统级芯片(SoC)设计已经在使用多个处理器，不过，它们都是以一种特定应用或松散结合的方式实现。直到最近，针对软件友好的多处理SoC设计功能还是受限。如今市场已经有诸如MIPS32 1004K一致处理系统(CPS)这种新的SoC设计组件推出，意味着在单操作系统环境中片上对称多处理(SMP)技术已经成为现实。

虽然并行编程会使软件工程师感到恐惧，因为并不是全部现有代码都是针对并行处理平台编写的，但针对并行软件已经有多种范例，其中一些对于软件设计师是来说已经是很熟悉的了。

数据并行算法

数据并行算法通过划分数据集来使用一个以上的处理器，甚至数量众多的CPU。在教科书中，大的数据集通常是一种很大的输入文件或数组，但在嵌入式系统中，它可能意味着高的I/O和事件服务带宽。在一些SoC架构中，多个输入数据源(如网络接口端口)可以被静态地分配到运行相同驱动程序/路由程序代码的多个处理器上，从而实现自然的数据并行处理。

当对单个数组或输入流应用多处理器技术时，“分而治之”的数据并行算法很常见。这样的算法对于单处理器来说通常不是最优的，但是因为具有更多的计算带宽，因此可以弥补效率的不足。这些算法对并行计算来说是可扩展的，但是将一个正常工作的顺序执行程序转换成一个并行数据算法可能面临价值不高、困难或不可能的局面，具体情况取决于程序依赖特性等因素。为了提高性能，如果绝大部分的应用计算都是用很少量的常规运算循环来实现的话，系统设计师很可能毫不犹豫地采用数据并行算法。

用于PC、工作站、服务器的多内核X86芯片的出现催生了新的库和工具套件，它们可以帮助设计师在数量适中的处理器上更容易地建立和开发并行算法。对于像MIPS这样的嵌入式架构来说许多算法都是开源和可移植的。针对数据并行C/C++以及Fortran的GCC扩展已经成为标准GNU编译器集的一个组成部分。

图1左：复杂模块化多任务处理嵌入式软件系统通常表现出“偶发”的并行特性。在使用时间共享的OS时，每个任务必须运行在独立的处理器上。而在一个时间共享的单处理器上，每个任务将在不同时间片中轮流执行。在一个采用了SMP OS的多处理器上，任务将在多个处理器上并行运行。

　　图1右：在SMP OS中，所有处理器都能看到相同的存储器、I/O器件和全局OS状态。在使用时间片的单CPU上执行多任务的一组程序可以在SMP系统的多个CPU上并行运行。

并行控制编程

并行控制编程将根据任务而不是输入进行工作划分。如果将100通道的并行数据算法比作汽车工厂内100个工人各自在组装一辆汽车，那么并行控制程序就可以比作有100个工作岗位的组装线，每个岗位完成百分之一的工作。组装线通常效率更高，但是组装一辆汽车的工作可能只能进行这样的分工。对于可以扩展到多达数千个处理器的科学计算程序而言，这个限制影响很大，但是对于一般的并行SoC架构来说不是问题。

软件工程师经常将程序划分成若干个阶段以便于编码、调试和维护，并减轻指令存储器和缓存的压力。通常，并行控制分解在OS可视任务层面就已经完成。在类似Unix这样的系统中，单指令“cc”顺序地调用C语言预处理器、编译器、汇编器和目标代码连接器。其中几个可以同时运行，每个后续程序使用前一个阶段的输出作为其输入，并使用类似Unix这样的OS内的文件或软件管线。

当分解成独立运行的任务还没有完成的时候，需要某些软件工程使应用阶段对OS和底层硬件可见，并且在任务之间明确地传递数据。但是不需要对部分阶段算法进行重写。粗粒度的任务分解可以通过文件、套接字或管线实现进程通信来完成。对于细粒度控制，许多OS支持Posix线程API、pthreads，包括Linux、微软的Windows和多种实时操作系统。

复杂的模块化多任务嵌入式软件系统通常表现出偶然的并行特性。整个系统任务可能涉及到对应不同输入而具有不同功能的多个任务。当没有时间共享的OS时，每个任务必须运行在一个独立的处理器上。而在一个时间共享的单处理器上，每个任务将在不断轮换的时间片中运行。在一个采用SMP操作系统的多处理器上，每个任务可以在多个可用的处理器上并