集群
自从1994年首次采用Beowulf集群以来，集群(通过一个本地网络来连接一些工作站或者个人电脑)就被广泛地使用。集群的魅力就在于它(潜在的)低成本(硬件和软件)以及构造者和使用者对这个集群系统所拥有的控制权。业界对于集群的热情从活跃的IEEE集群计算任务组（TFCC：Task Force on Cluster Computing）上观察到，TFCC定期发布当前集群计算的综合报告。此外那些介绍构造和维护集群的图书也相当受欢迎。随着集群市场变得相对地成熟和有吸引力，大型的HPC厂商和一些才开始厂商都开始进入这块市场，并且为那些不希望从头开始构建集群的组织提供（或多或少现成的）out-of-the-box（取出即可用）集群解决方案。
销售集群配置的厂商数目已经增长到了在这份报告中包括所有的产品是不现实的。此外，一般来说集群的用途和它的更为综合的副本之间差别巨大，我们将在下个章节来讨论这个问题：集群主要用来进行能力计算（capability computing），而综合系统主要进行容量计算（capacity computing）。第一种模式意味着系统主要针对一个或极少的应用程序所使用，并且从计算能力上讲没有其他的可选方案。
第二种模式则是通过许多，有时候甚至是数量众多的应用程序和用户来充分利用系统资源。传统意义上，大型系统厂商已经学会为后一种模式的运算提供产品，因为这些系统的宝贵资源需要被最大限度地利用。作为对比，Beowulf集群主要是通过Linux操作系统（很少一部分Beowulf集群采用微软的Windows操作系统），而这些Linux系统中，往往不是缺少工具，就是工具对于集群进行良好的容量计算来说不够成熟。
然后，随着平均意义上的集群变得越来越大和越来越稳定，有一种趋势来将集群作为容量计算服务器。第30条参考书目就关注了这类用法的一些必备条件，如现有的集群管理工具和批处理系统（batch systems）。在同一份报告中，还对普通应用程序工作量情况下的集群性能进行了评估，既有采用RISC处理器（Compaq Alpha）的系统，也有给予Intel Pentium III处理器的系统。一个很重要，但是不太让人吃惊的结论就是除开大多数计算范围内的应用程序，网络的传输速度是相当重要的。另一个值得注意的观察就是从简洁以及可能的能源和降温的角度来看，在一个计算节点上采用超过1个CPU可能很有吸引力，不过更多的CPU会给节点上的公用内存带来更大的负担，也会最终严重损害系统性能。在这种情况中，节点的带宽无法满足内存读取密集型应用程序的需求。
幸运地是，现在已经有了一些集群上使用的通讯网络。当然100M的以太网是长期可行的方案，至少从经济的角度来看是这样，不过100M的以太网也有缺点，最高带宽仅为10M/秒，而延迟也很高，大约100 μs。千兆级以太网拥有10倍与100M以太网的带宽，不过延迟却是相同的。也有一些替补方案，可以在用户空间（user space）里运行，如Myrinet、Giganet cLAN和SCI。前两个拥有100M/秒的最大带宽以及15－20 μs的延迟，SCI拥有更高的带宽400－500MB/秒（理论上），而延迟仅为10 μs。最后一种方案成本最高，不过在一些集群配置中还是采用了这种方案。Myrinet、cLAN以及当然的SCI网络的速度或多或少地与部分综合并行系统持平。所以，除了处理器的速度和由DM-MIMD系统厂商提供的软件上速度差异，这类系统与集群之间的差异已经变得相当的微弱，并且还会毫无疑问地在以后几年中继续削弱。
