从Power、UltraSPARC T1、安腾到双核Opteron、Xeon，各个领域都显示出，多核处理器计算平台势必成为服务器的主流或者说是强势计算平台，但上游硬件厂商的乐观预期似乎还有些过早——并不是所有的操作系统和应用软件都做好了迎接多核平台的准备，尤其是在数十年来均为单一线程开发应用的x86服务器领域。
微软软件架构师Herb Sutter曾指出:软件开发者对多核处理器时代的来临准备不足。他说，软件开发社区认识到处理器厂商被迫采用多核设计以应对处理器速度提升带来的发热问题，但却没有清楚地了解这样的设计为软件开发带来多少额外的工作。
在过去一段长时间里，x86系统上软件的性能随着来自Intel和AMD处理器速度越来越快而不断提高，开发者只需对现有软件程序作轻微改动就能坐观其性能在随着硬件性能的上升而不断提升。不过，多核设计概念的出现迫使软件世界不得不直面并行性(将单个任务拆分成多个小块以便分别处理之后再重新组合的能力)问题。当然，为服务器设计软件的开发者已经解决了一些此类难题，因为多核处理器和多路系统在服务器市场已经存在多年(在传统的Unix领域)，一些运行在RISC架构多核多路系统上的应用程序已经被设计成多线程以利用系统的并行处理能力。但是，在x86领域，应用程序开发者多年来一直停留在单线程世界，生产所谓的“顺序软件”。
现在的情况是软件开发者必须找出新的开发软件的方法，面向对象编程的兴起增加了汇编语言的复杂性，并行编程也需要新的抽象层次。
另一方面，处理器设计厂商在设计产品时也应该将软件开发者考虑在内，“处理器的首要着眼点应该是可编程性，而不是速度。”Sutter说。
多核处理器要想发挥出威力，关键在于并行化软件支持，多核设计带动并行化计算的推进，而给软件带来的影响更是革命性的。
Intel很早就通过超线程技术实现了逻辑上的双处理器系统，可以并行计算，但这不过是对处理器闲置资源的一种充分利用而已，并且这种充分利用只有在特定的条件下，尤其是针对流水线比较长且两种运算并不相互交叉的时候，才会有较高的效率，如编码解码、长期重复某种矩阵运算以及一些没有经过仔细编写的软件等。
即使IBM的Power5架构，也需要跟最新的操作系统进行融合，加上运行在其上的软件，才有可能利用并发多线程。
虚拟化技术在一定程度上能够处理一些因为多核带来的问题，可以让应用软件和操作系统在透明的环境下对处理器资源进行分配和管理。
目前在对称多处理器方面，操作系统对资源的分配和管理并没有本质的改变，多以对称的方式进行平均分配。也就是说，在操作系统层面，当一个任务到来时，剥离成为两个并行的线程，因为线程之间需要交流以及操作系统监管，它导致的效率损失要比硬件层面大得多。并且，多数软件并没有充分考虑到双核乃至多核的运行情况，导致线程的平均分配时间以及线程之间的沟通时间都会大大增加，尤其是当线程需要反复访问内存的时候。目前，多数操作系统还没有完全实现自由的资源分配，如IBM是通过AIX 5.3L来支持Power5上的虚拟化功能，才实现了资源的动态调配和划分的。
从长远来看，需要使用虚拟化技术才可能实现操作系统对任务的具体划分，这很可能改变一些通用的编程模式。
面对多核系统，需要有并行编程的思想才有可能充分利用资源，而人类的思维模型习惯于线性思维，对“面”或者更为复杂的立体编程模式，效率会下降很多。
软件在并行化方面的滞后给多核处理器技术的发展蒙上了一些阴影。尽管用户在充满希望地期待着，但思维的改变不是一朝一夕的事情。
服务器端的并行化应用设计似乎已经解决了一些，但仍需要努力提高其扩展能力。
并行化对于客户端的应用是一项巨大的挑战，而对于许多基于服务器的程序来说，却是一个“已经圆满解决的问题”。我们在服务器上使用的并行化架构一直在很好地工作，但要想确保这类架构的顺利编程和扩展能力，人们仍然需要付出巨大的努力。这些应用通常都具有很强的并行特性，它们可以同时处理许多独立的请求流。例如，一台Web服务器或一个Web站点可以独立执行同一代码在大部分不重叠数据上的数千个版本。此外，这些执行都是相互独立的，通过一个抽象数据存储来共享状态，例如通过支持高度并行化访问结构化数据库。今天，表达并行的方式有很多种，每种方式只适用于一个特定的程序子集。这些并行编程模型在两方面的区别比较大:并行运行的粒度和任务间相互配合的程度。
并行执行的操作可能是单个指令，如加法或乘法，也可能是需要用几天时间来运行的复杂程序。很明显，对于小型操作来说，并行基础设施的开销成本是非常巨大的，总的来说，任务分割得越小，将其生成为单个任务和提供通信及同步时所需要的成本就越高。
另外一个方面就是操作间通信和同步配合的程度。最理想的程序是没有任何的配合，操作完全是独立运行的，而且产生的结果也是完全不同的。在这种情况下，操作可以按任何顺序运行，也不会产生任何同步或通信成本，在编程时无须考虑数据竞争的问题，编程过程自然也就会非常容易。然而，这种状态是非常罕见的，多数并行程序都要在操作之间共享数据。当操作变得越来越多样化时，确保正确和有效的操作其复杂性也会随之提高。最简单的案例是为每个操作执行相同的代码，这种共享类型是一种无规律的并行方式。更具有挑战性的是，无规划的并行方式，在这种方式中，操作是完全不同的，而且共享方式也更难以理解。
独立并行 在这种方式下，一种或多种操作是针对数据集中的每个项目独立实施执行的。精细的数据并行依靠的是操作的并行执行，它们不应当共享输入的数据或结果，并应当在无协调的情况下完全可以执行。
在实际应用中，搜索引擎等应用只共享一个大型的只读数据库，因此并发的处理检索不需要任何协调，同样，大型模拟通常需要在运行时分析大量的输入参数，也是一种独立并行模型。
有规律的并行 比独立并行更复杂一些的是当运算之间存在相互依存关系时，将同一种运算应用到一个数据集上。如果两个运算之间存在通信或同步，则在数据上某一部分执行的运算会与另外一个运算存在依存关系。有规律的并行程序要想取得正确的结果，需要同步或认真协调执行策略，与一般并行不同的是，我们可以对这类操作背后的代码进行分析，确定如何以并发的方式对其加以执行，以及确定它们共享哪些数据。
无结构的并行 无结构的并行对数据的访问是不可预见的，而且需要通过明确的同步方式对其加以协调。在使用线程和明确的同步方式写成的程序中，这种并行形式最为普遍。在这类程序中每一个线程都有自己特定的职责，我们很难讨论这类并行形式中任何具体的内容，但有一点:两个线程在访问数据时如果发生冲突，就必须使用明确的同步方式来解决，否则，程序将进入无法确定的状态。
