微观和宏观并行化

《风险-收益分析：理性投资的理论与实践（第2卷）》微观和宏观并行化,页面无弹窗的全文阅读!

按照我的设想，一个典型的LRG应包含两个或更多相互协作的处理器，以及它们的本地（快速）存储器，再加上通信设施和大容量存储器。LRG将充当它们的管理人，像IBM EAS-E的管理人一样，除了管理人之间可进行信息交流外。

我区分微观和宏观并行化的依据，是任务能够被分配给不同的LRG还是最好在同一LRG内部完成。在“易于并行化的进程”小节中讨论的任务和子任务，可由宏观并行化来处理。例如，有关怎样快速地计算109个数的统计量的讨论，假设这个主任务被分解为多个子任务，并被分配给多个LGR，因而是宏观并行化的一个例子。

一项基本的计算机操作，例如将两个数相加，涉及多个步骤：两个运算对象都必须从内存移动到寄存器，然后在寄存器中执行相加指令。它们可能首先移动到待操作队列中运算对象的“高速缓存”，然后在寄存器中执行相加指令，并存储结果。之后，这一结果必须被移动到存储器中。然而，也可能有一个运算对象已经在或两个运算对象都已在寄存器中，负责执行运算的运算器（arithmetic logical unit，ALU）可以直接访问寄存器。此外，也可能不需要存储结果，因为它是一个部分和，很快就会再次与其他数相加。

考虑运算对象从内存提取且运算结果又被存储到内存中的情形。如果串行计算机上只有这一任务在运行，那么访问和存储数据时ALU是闲置的。现代高性能并行计算机的功能之一，是接下来运算的数据提取，或之前运算的数据存储，可以与当前的算术运算同时进行。

这产生了一个问题：由谁或什么来决定何者与何者在宏观层面并行处理？阿伦和肯尼迪（Allen and Kennedy，2002）的著作介绍了当前计算机向用户提供并行处理的6种不同方式，并给出了适于这些硬件类型的编码。他们从试验中得出结论认为：

在源语言中显式地表示并行性，并不足以保证最佳地利用并行的硬件。所介绍的6种机器类型中的每一种，都要求对并行性有一个不同的表示——在一些情形中是完全不同的表示。并且，得到对一个特定机器而言最佳的表示形式，要求对机器的架构有详细的了解。这一观察表明，需要对显式的并行程序进行修改，以适应不同的个体架构；当它们从一台机器移植到另一台机器的时候，效率会下降。

……

考虑到软件的使用期越来越长，而硬件的寿命越来越短，这些经验教训表明，修改代码使之适应特定的机器架构，最好留待编译器来完成。

因此，在微观层面将计算机资源分配给计算任务，应该留待适于特定计算机架构的优化编译器。然而，SIMSCRIPT M执行程序会将主计算任务分派给可用的LRG。这样的宏观并行化是一个经典的作业车间问题，可以借鉴作业车间研究的悠久传统。

一些LRG可能有专门的用途。例如，也许有一个或多个LRG具备检索档案信息的专长。它们可能较难或无法与终端用户进行交流，因为它们的主要功能是对管理人之间有关大量极少用到之数据的请求做出响应。如果所有的LRG都是相同的，那么任务分配进程，就是一个有很多同一种服务器的作业车间的进程。如果LRG是不同的，那么宏观并行性就被当作一个经典的多服务器作业车间来实现。

目前，SIMSCRIPTⅢ像它之前的SIMSCRIPTⅡ.5一样，对C代码进行编译，并让C来做（微观）代码优化。在理想的情况下，如果代码优化过程以SIMSCRIPT（例如SIMSCRIPT M）开始，最终可能会更好。例如，我们看到SIMSCRIPTⅡ的COMPUTE命令指定了一个要计算其各种统计量的实体集。如果SIMSCRIPT编译器编写了线性码来完成这一任务，那么C编译器也许能也许不能辨别出某些中间结果是不需要存储的。

从程序员的视角来看，COMPUTE命令仍然是COMPUTE命令。取决于从其中获取主题实体的集合大小，以及计算机硬件的具体情况，人们希望SIMSCRIPT编译器和实时操作系统将会利用“最先进的”宏观和微观并行性。一般而言，对于一个优化编译器，基于模拟程序或DSS建模者意图的SIMSCRIPTⅡ式声明来辨别何者可以并行化处理，何者必须串行处理，不会比基于实现这一意图的线性码来做决定更困难。8