> 新闻中心 > 评测室
目前最高端的Nehalem-EP型号：Xeon X5570，主频2.93GHz，QPI频率3.2GHz
4核心Nehalem-EP处理器晶元图
Nehalem架构仍然基于成熟的Core微架构并在其基础上进行改进，因此，桌面版本Nehalem使用了Core i7的系列名称（上一代则是Core 2），服务器版本也不例外，仍然使用了Xeon的名称，不过处理器系列更新为5500（上一代为5400，上上一代为5300）。
配合Nehalem-EP使用的Intel Tylersburg-EP芯片
几天前，我们曝光了Nehalem-EP处理器??Xeon E5540的实物（同时给出了基于X58主板的上机图），并发布了我们根据当前资料做出的架构分析，不过由于NDA保密协议的缘故，我们不能给出其性能数据，现在随着Nehalem-EP的正式发布，禁令也相应消失，下面我们终于可以尽情地享受Nehalem-EP的极致性能了。由于篇幅较多，因此建议读者们使用下面的导航功能，直接打开到感兴趣的页面。
Intel Nehalem-EP官方评测样机，配置了双路Xeon X5570处理器和24GB DDR3内存
我们IT168评测中心收到了Intel发出的第一批测试样机。由于样机是从Intel位于Oregen俄勒冈州的Hillsboro研发中心（也就是负责Nehalem架构开发工作团队的所在）发来，因此最终留给我们的时间不是很多，下面我们就来领略这台顶级Nehalem-EP服务器的威力。
对于Intel的Tick-Tock战略已经是老生常谈了??从另一方面讲，这标明了Tick-Tock战略的成功之处，一个简单、明晰、有序和易于理解的发展计划，对合作厂商、用户和投资者都是极为有利的。TIck-Tock战略简而言之就是Intel处理器在奇数年进行制程转换（Tick），例如2005年的65nm和2007年的45nm，而在偶数年进行处理器的架构更新（Tock），Nehalem架构发布的2008年轮换到了Tock，也就是处理器的架构更新。
Nehalem作为Intel用以取代Penryn微架构的新一代处理器架构，和Penryn相比，Nehalem的微架构并非是全新的，不过，架构上则是一个很大的飞跃：Nehalem采用了直联架构。除此之外，Nehalem还具有一个鲜明的设计理念，就是采用了可扩展的模块化设计，它将处理器划分为两个部分：Core核心和Uncore非核心（或者叫“核外”），所有产品线的Nehalem处理器，其Core核心部分都是一样的，只是Uncore部分可能不同，以满足Intel对其提出的动态可扩展的要求。Nehalem满足了这个要求，它的内核具有可扩展的高可伸缩架构。
由于共处在一个Tick-Tock上，因此Nehalem和Penryn都同样属于45nm工艺，从65nm工艺转变到45nm工艺带来的巨大能耗降低已经无法再次重新，因此Nehalem就不再注重于能耗的降低，而是注重于性能的提升，这样的设计理念，带来了处理器架构的巨大变化，这些变化均面向性能的提高，也即是说，我们可以期望Nehalem具有着强大的性能。
Harpertown是基于45nm Penryn的四核Xeon DP处理器：两个“双核”粘结而成
可以说，Core现在在所有产品线上都获得了成功??因为它强劲的性能，以及很好的功耗表现，然而，Core确实具有一个移动计算的起源，它的原始架构都是围绕着这个中心来设计。例如，古老的双核设计：笔记本不需要太多的处理核心（即使是现在，也只有少量工作站级别的笔记本配置了四核），让目前的Core架构已经不太适合于服务器市场，虽然6核心的7400系列Xeon已经推出，不过它和当前的四核产品一样，都是多个“双核”粘结在一起的产物。不会有基于Core架构（不是Core微架构）的8核心产品了，那样做的代价太大，基于FSB方面的原因，性能将会很受限制（六核心的Dunnington是Core架构/FSB总线的绝唱）。
六核心45nm Penryn至强Dunnington是Core架构/FSB总线的绝唱，并融合了Nehalem的“原生单核”设计
Core架构具有一个移动计算的起源，它源自Banias Pentium M处理器，Pentium M处理器是以色列（Israel）的海法（Haifa）研究中心专门针对笔记本电脑的产品，特点是高效、低耗。时值2004年，开发NetBurst架构的美国德克萨斯州（Texas）的奥斯丁（Austin）设计团队尚在设计Tejas（Prescott的下一代）。很快NetBurst失败，Core架构被扶正，之后迅速地成为Intel的主要架构，产品开始扩展到桌面乃至服务器产品线（很可怕地，Austin设计团队被分派去设计一个极低功耗的CPU，就是后来的Atom凌动处理器）。
初代Core架构：Banias Pentium M
Core架构的成功我们都已经看到了，然而随着时间的流逝，如古老的双核设计（4核是两个双核粘在一起，6核则是三个双核粘结）、过时的FSB总线以及没有充分为64位计算准备等等，让其无法获得很好的伸缩性，难以未来需要高性能多处理器需求的企业级市场。此外，在NetBurst架构上耗资了数亿美元的HTT超线程技术也没能得到体现，Intel需要制作一款新的处理器产品来满足未来的需求。
Intel对Core架构作出了改动，首先它将原来的架构扩展为原生4核（甚至6核、8核）设计，并为多核的需要准备了新的总线QPI来满足巨大的带宽需求，结果就是Nehalem内核。Nehalem内核还采用了集成内存控制器的设计，也是为了满足多核心巨大的带宽需求（丛目前来看，Nehalem-EP不会有6核、8核的型号，这些产品会出现在Nehalem-EX上面）。
4核心Nehalem-EP处理器晶元图
4核心Nehalem-EP处理器的一些简要参数
了解Nehalem的设计思想之后，我们先来看看Nehalem微架构设计，和前面所说的一样，基于模块化设计，所有的Nehalem处理器的微架构都是一致的，因此接下来的内容适合于包括移动、桌面在内的Nehalem处理器。
The Core: Partition
核心：功能区间划分
首先我们需要清楚地知道，Nehalem是一款OOOE（Out of Order Execute）乱序执行的Superscaler超标量x86处理器。x86处理器上的超标量设计是从Pentium开始，乱序执行则是从Pentium Pro开始（Pentium仍然是IOE-In Order Execute的）。现在的乱序执行处理器采用的流水线可能深度不一，但是它们都离不开取指（Instruction Fetch)、解码（Decode）、执行（Execute）、串行顺序回退（Retire）这四个阶段。
官方公布的简单的架构图
既然是乱序执行，那么四个阶段中，取指令、指令解码和回退阶段实际上仍然是属于In-Order顺序的。加上内存存取方面的内容，Nehalem处理器可以按下面的颜色划分：
Nehalem Microarchitecture，经笔者整理
紫色部分属于取指令部分，橙色则属于解码部分。黄色部分是乱序执行的准备部分（灰色Retirement Register File属于乱序架构的Retire部分），蓝色方框是计算单元，绿色方框是内存子系统（包括紫色部分的指令缓存在内），计算单元和内存子系统的一部分（存取单元）一起成为乱序执行单元。绿色方框包含了Core和Uncore两部分，Uncore的内容，不同系列的Nehalem的处理器是不同的，就上图标明和本文谈论到的，都适用于我们的主角：Nehalem-EP处理器。
下面就大致从指令拾取开始介绍Nehalem的微架构，这些内容就经过了笔者的多方面查证以确保具有较高的准确性。然而由于内容太多，错漏难以避免，欢迎读者们一一指出。
The Core Front-End: Instruction Fetch
处理器核心前端：指令拾取
处理器在执行指令之前，必须先装载指令。指令会先保存在L1缓存的I-cache（Instruction-cache）指令缓存当中，Nehalem的指令拾取单元使用128bit带宽的通道从I-cache中读取指令。这个I-cache的大小为32KB，采用了4路集合关联，在后面的存取单元介绍中我们可以得知这种比Core更少的集合关联数量是为了降低延迟。
为了适应超线程技术，RIP（Relative Instruction Point，相对指令指针）的数量也从一个增加到了两个，每个线程单独使用一个。
指令拾取单元包含了分支预测器（Branch Predictor），分支预测是在Pentium Pro处理器开始加入的功能，预测如if then这样的语句的将来走向，提前读取相关的指令并执行的技术，可以明显地提升性能。指令拾取单元也包含了Hardware Prefetcher，根据历史操作预先加载以后会用到的指令来提高性能，这会在后面得到详细的介绍。
两级分支预测机制
当分支预测器决定了走向一个分支之后，它使用BTB（Branch Target Buffer，分支目标缓冲区）来保存预测指令的地址。Nehalem从以前的一级BTB升级到了两个级别，这是为了适应很大体积的程序（数据库以及ERP等应用，跳转分支将会跨过很大的区域并具有很多的分支）。Intel并没有提及BTB详细的结构。与BTB相对的RSB（Return Stack Buffer，返回堆栈缓冲区）也得到了提升，RSB用来保存一个函数或功能调用结束之后的返回地址，通过重命名的RSB来避免多次推测路径导致的入口／出口破坏。RSB每个线程都有一个，一个核心就拥有两个，以适应超线程技术的存在。
RSB：重命名的返回堆栈缓冲器
指令拾取单元使用预测指令的地址来失去指令，它通过访问L1 ITLB里的索引来继续访问L1I Cache，128条目的小页面L1 ITLB按照两个线程静态分区，每个线程可以获得64个条目，这个数目比Core 2的少。当关闭超线程时，单独的线程将可以获得全部的TLB资源。除了小页面TLB之外，Nehalem还每个线程拥有7个条目的全关联（Full Associativity）大页面ITLB，这些TLB用于访问2M/4M的大容量页面，每个线程独立，因此关闭超线程不会让你得到14个大页面ITLB条目。
指令拾取单元通过128bit的总线将指令从L1I Cache拾取到一个16Bytes（刚好就是128bit）的预解码拾取缓冲区。128位的带宽让人有些迷惑不解，Opteron一早就已经使用了256bit的指令拾取带宽。最重要的是，L1D和L1I都是通过256bit的带宽连接到L2 Cache的。
由于一般的CISC x86指令都小于4Bytes（32位x86指令；x86指令的特点就是不等长），因此一次可以拾取4条以上的指令，而预解码拾取缓冲区的输出带宽是6指令每时钟周期，因此可以看出指令拾取带宽确实有些不协调，特别是考虑到64位应用下指令会长一些的情况下（解码器的输入输出能力是4指令每时钟周期，因此32位下问题不大）。
75%的x86指令小于4Bytes。
指令拾取结束后会送到18个条目的指令队列，在Core架构，送到的是LSD循环流缓冲区，在后面可以看到，Nehalem通过将LSD移动后更靠后的位置来提高性能。
The Core Front-End: Decode
处理器核心前端：解码
在将指令充填到可容纳18条目的指令队列之后，就可以进行解码工作了。解码是类RISC（精简指令集或简单指令集）处理器导致的一项设计，从Pentium Pro开始在IA架构出现。处理器接受的是x86指令（CISC指令，复杂指令集），而在执行引擎内部执行的却不是x86指令，而是一条一条的类RISC指令，Intel称之为Micro Operation??micro-op，或者写为µ-op，一般用比较方便的写法来代替希腊字母：u-op或者uop。相对地，一条一条的x86指令就称之为Macro Operation，或macro-op。
RISC架构的特点就是指令长度相等，执行时间恒定（通常为一个时钟周期），因此处理器设计起来就很简单，可以通过深长的流水线达到很高的频率（例如31级流水线的Pentium 4……当然Pentium 4要超过5GHz的屏障需要付出巨大的功耗代价），IBM的Power6就可以轻松地达到4.7GHz的起步频率。关于Power6的架构的非常简单的介绍可以看《机密揭露：Intel超线程技术有多少种？》，我们继续说Nehalem：和RISC相反，CISC指令的长度不固定，执行时间也不固定，因此Intel的RISC/CISC混合处理器架构就要通过解码器将x86指令翻译为uop，从而获得RISC架构的长处，提升内部执行效率。
和Core一样，Nehalem的解码器也是4个：3个简单解码器加1个复杂解码器。简单解码器可以将一条x86指令（包括大部分SSE指令在内）翻译为一条uop，而复杂解码器则将一些特别的（单条）x86指令翻译为1~4条uops??在极少数的情况下，某些指令需要通过额外的可编程microcode解码器解码为更多的uops（有些时候甚至可以达到几百个，因为一些IA指令很复杂，并且可以带有很多的前缀/修改量，当然这种情况很少见），下图Complex Decoder左方的ucode方块就是这个解码器，这个解码器可以通过一些途径进行升级或者扩展，实际上就是通过主板Firmware里面的Microcode ROM部分。
2006年进行的一个研究当中表示，最常用的20条x86指令当中：
mov占35%（寄存器之间、寄存器与内存之间移动数据），push占10%（压入堆栈，也经常用来传递参数），call占6%，cmp占5%，add、pop、lea占4%（实际计算指令非常少）
75%的x86指令短于4 bytes，也就是小于32 bits。不过这些短指令只占代码大小的53%??有一些指令非常长
之所以具有两种解码器，是因为仍然是关于RISC/CISC的一个事实：大部分情况下（90%）的时间内处理器都在运行少数的指令，其余的时间则运行各式各样的复杂指令（不幸的是，复杂就意味着较长的运行时间），RISC就是将这些复杂的指令剔除掉，只留下最经常运行的指令（所谓的精简指令集），然而被剔除掉的那些指令虽然实现起来比较麻烦，却在某些领域确实有其价值，RISC的做法就是将这些麻烦都交给软件，CISC的做法则是像现在这样：由硬件设计完成。因此RISC指令集对编译器要求很高，而CISC则很简单。对编程人员的要求也类似。
The Core Front-End: Decode
作为对比，AMD的处理器从K8以来就具有强大的三组复杂解码器，并且大部分指令都可以解码为1~2条AMD的Micro-operations（这个Micro-op和Intel的uop是不同的东西）。
Macro Fusion功能
在进行解码的时候，会碰到Intel在Core 2开始加入的技术：Macro Fusion。关于Macro Fusion可以看这里《64位对决32位 SPEC CPU运算效能测试》，这项技术可以将一些比较并跳转的分支x86指令集合（CMP+TEST/JCC）最终解码为单条uop（CMP+JCC），从而提升了解码器的带宽、降低执行指令数量，让系统运行效率更高。和Core 2相比，Nehalem现在支持更多的比较／跳转分支情况，如JL/JNGE、JGE/JNL、JLE/JNG、JG/JNLE等，此外，Nehalem也开始更多地为服务器平台考虑，它的Macro Fusion开始支持64位模式，而不是Core 2的只支持32位模式。随着内存容量的日益增长，即使是在桌面平台及移动平台，64位用户也在不断增加，因此这个改进对用户很有吸引力。
除了将多条Macro Ops（就是x86指令）聚合之外，Nehalem也支持将多条uops聚合，也就是Micro Fusion功能，用于降低uop的数量。这是一个从Pentium M开始存在的老功能了，它在顺序上是在比Macro Fusion后面的后面，也就是在LSD循环流监测器后方。据说，Micro Fusion可以提升5%的整数性能和9%的浮点性能，而Macro Fusion则可以降低10%的uop数量。
The Core Front-End: Loop Stream Detector
处理器核心前端：循环流检测
在解码为uop之后Nehalem会将它们都存放在一个叫做uop LSD Buffer的缓存区。在Core 2上，这个LSD Buffer是出现在解码器前方的，Nehalem将其移动到解码器后方，并相对加大了缓冲区的条目。Core 2的LSD缓冲区可以保存18个x86指令而Nehalem可以保存28个uop，从上一页可以知道，大部分x86指令都可以解码为一个uop，少部分可以解码为1~4个uop，因此Nehalem的LSD缓冲区基本上可以相当于保存21~23条x86指令，比Core 2要大上一些。
The Core Front-End: Loop Stream Detector
LSD循环流监测器也算包含在解码部分，它的作用是：假如程序使用的循环段（如for..do/do..while等）少于28个uops，那么Nehalem就可以将这个循环保存起来，不再需要重新通过取指单元、分支预测操作，以及解码器，Core 2的LSD放在解码器前方，因此无法省下解码的工作。
Nehalem LSD的工作比较像NetBurst架构的Trace Cache，其也是保存uops，作用也是部分地去掉一些严重的循环，不过由于Trace Cache还同时担当着类似于Core/Nehalem架构的Reorder Buffer乱序缓冲区的作用，容量比较大（可以保存12k uops，准确的大小是20KB），因此在cache miss的时候后果严重（特别是在SMT同步多线程之后，miss率加倍的情况下），LSD的小数目设计显然会好得多。不过笔者认为28个uop条目有些少，特别是考虑到SMT技术带来的两条线程都同时使用这个LSD的时候。
在LSD之后，Nehalem将会进行Micro-ops Fusion，这也是前端（The Front-End）的最后一个功能，在这些工作都做完之后，uops就可以准备进入执行引擎了。
The Core Execution Engine: Out-of-Order Execution
处理器核心执行引擎：乱序执行
OOOE??Out-of-Order Execution乱序执行也是在Pentium Pro开始引入的，它有些类似于多线程的概念，这些在《机密揭露：Intel超线程技术有多少种？》里面可以看到相关的介绍。乱序执行是为了直接提升ILP（Instruction Level Parallelism）指令级并行化的设计，在多个执行单元的超标量设计当中，一系列的执行单元可以同时运行一些没有数据关联性的若干指令，只有需要等待其他指令运算结果的数据会按照顺序执行，从而总体提升了运行效率。乱序执行引擎是一个很重要的部分，需要进行复杂的调度管理。
然而乱序执行架构中，不同的指令可能都会需要用到相同的通用寄存器（GPR，General Purpose Registers），为了在这种情冲突的况下指令们也能并行工作，处理器需要准备解决方法。一般的RISC架构准备了大量的GPR，而x86架构天生就缺乏GPR（x86具有8个GPR，x86-64具有16个，一般RISC具有32个，IA64则具有128个），为此Intel开始引入重命名寄存器（Rename Register），不同的指令可以通过具有名字相同但实际不同的寄存器来解决，这有点像魔兽世界当中的副本设计，当然其出现要比WoW早多了。
此外，为了SMT同步多线程，这些寄存器还要准备双份，每个线程具有独立的一份。
The Core Execution Engine: Out-of-Order Execution
乱序执行从Allocator定位器开始，Allocator管理着RAT（Register Alias Table，寄存器别名表）、ROB（Re-Order Buffer，重排序缓冲区）和RRF（Retirement Register File，退回寄存器文件）。在Allocator之前，流水线都是顺序执行的，在Allocator之后，就可以进入乱序执行阶段了。在每一个线程方面，Nehalem和Core 2架构相似，RAT将重命名的、虚拟的寄存器（称为Architectural Register或Logical Register）指向ROB或者RRF。RAT是一式两份，每个线程独立，每个RAT包含了128个重命名寄存器（Pentium 4之前??Pentium Pro到Pentium III的重命名寄存器基于ROB，数量为40个；据说Pentium 4有128个）。RAT指向在ROB里面的最近的执行寄存器状态，或者指向RRF保存的最终的提交状态。
ROB（Re-Order Buffer，重排序缓冲区）是一个非常重要的部件，它是将乱序执行完毕的指令们按照程序编程的原始顺序重新排序的一个队列，打乱了次序的指令们依次插入这个队列，当一条指令通过RAT发往下一个阶段确实执行的时候这条指令（包括寄存器状态在内）将被加入ROB队列的一端，执行完毕的指令（包括寄存器状态）将从ROB队列的另一端移除（期间这些指令的数据可以被一些中间计算结果刷新），因为调度器是In-Order顺序的，这个队列也就是顺序的。从ROB中移出一条指令就意味着指令执行完毕了，这个阶段叫做Retire回退，相应地ROB往往也叫做Retirement Unit（回退单元），并将其画为流水线的最后一部分。
在一些超标量设计中，Retire阶段会将ROB的数据写入L1D缓存，而在另一些设计里，写入L1D缓存由另外的队列完成。例如，Core/Nehalem的这个操作就由MOB（Memory Order Buffer，内存重排序缓冲区）来完成。
ReOrder Buffer重排序缓冲区是一个Retire Queue回退队列，是OOOE乱序架构流水线的最后一段
ROB是乱序执行引擎架构中都存在的一个缓冲区，重新排序指令的目的是将指令们的寄存器状态依次提交到RRF退回寄存器文件当中，以确保具有因果关系的指令们在乱序执行中可以得到正确的数据。从执行单元返回的数据会将先前由调度器加入ROB的指令刷新数据部分并标志为结束（Finished），再经过其他检查通过后才能标志为完毕（Complete），一旦标志为完毕，它就可以提交数据并删除重命名项目并退出ROB了。提交状态的工作由Retirement Unit（回退单元）完成，它将确实完毕的指令包含的数据写入RRF（“确实”的意思是，非猜测执性、具备正确因果关系，程序可以见到的最终的寄存器状态）。和RAT一样，RRF也同时具有两个，每个线程独立。Core/Nehalem的Retirement Unit回退单元每时钟周期可以执行4个uops的寄存器文件写入，和RAT每时钟4个uops的重命名一致。
由于ROB里面保存的指令数目是如此之大（128条目），因此一些人认为它的作用是用来从中挑选出不相关的指令来进入执行单元，这多少是受到一些文档中的Out-of-Order Window乱序窗口这个词的影响（后面会看到对ROB会和MOB一起被计入乱序窗口资源中）。
ROB确实具有RS的一部分相似的作用，不过，ROB里面的指令是调度器通过RAT发往RS的同时发往ROB的，也就是说，在“乱序”之前，ROB的指令就已经确定了。指令并不是在ROB当中乱序挑选的（这在RS当中进行），ROB担当的是流水线的最终阶段：一个指令的Retire回退单元；以及担当中间计算结果的缓冲区。
RS（Reservation Station，中继站）：等待源数据到来以进行OOOE乱序执行（没有数据的指令将在RS等待）
ROB（ReOrder Buffer，重排序缓冲区）：等待结果到达以进行Retire指令回退（没有结果的指令将在ROB等待）
The Core Execution Engine: Out-of-Order Execution
Nehalem的128条目的ROB担当中间计算结果的缓冲区，它保存着猜测执行的指令及其数据（猜测执行也是在Pentium Pro开始引入的，Pentium Pro真是一个划时代的产品），猜测执行允许预先执行方向未定的分支指令，Nehalem的分支预测成功率没有被提及（只是含糊地说“业内最高”）。在大部分情况下，猜测执行工作良好??分支猜对了，因此其在ROB里产生的结果被标志为已结束，可以立即地被后继指令使用而不需要进行L1 Data Cache的Load操作（这也是ROB的另一个重要涌出，典型的x86应用中Load操作是如此频繁，达到了几乎占1/3的地步，因此ROB可以避免大量的Cache Load操作，作用巨大）。在剩下的不幸的情况下，分支未能按照如期的情况进行，这时猜测的分支指令段将被清除，相应指令们的流水线阶段清空，对应的寄存器状态也就全都无效了，这种无效的寄存器状态不会也不能出现在RRF里面。
Pentium Pro架构，可见在后继型号在OOOE方面变化的基本只是一些数字变大了
重命名技术并不是没有代价的，在获得前面所说的众多的优点之后，它令指令在发射的时候需要扫描额外的地方来寻找到正确的寄存器状态，不过总体来说这种代价是非常值得的。RAT可以在每一个时钟周期重命名4个uops的寄存器，经过重命名的指令在读取到正确的操作数并发射到统一的RS（Reservation Station，中继站，Intel文档翻译为保留站点）上。RS中继站保存了所有等待执行的指令。
和Core 2相比，Nehalem的ROB大小和RS大小都得到了提升，ROB重排序缓冲区从96条目提升到128条目（鼻祖Pentium Pro具有40条），RS中继站从32提升到36（Pentium Pro为20），它们都在两个线程（超线程中的线程）内共享，不过采用了不同的策略：ROB是采用了静态的分区方法，而RS则采用了动态共享，因为有时候会有一条线程内的指令因等待数据而停滞，这时另一个线程就可以获得更多的RS资源。停滞的指令不会发往RS，但是仍然会占用ROB条目。由于ROB是静态分区，因此在开启HTT的情况下，每一个线程只能分到64条，不算多，在一些极少数的应用上，我们应该可以观察到一些应用开启HTT后会速度降低，尽管可能非常微小。
The Core Execution Engine: Execution Unit
处理器核心执行引擎：执行单元
在为SMT做好准备工作并打乱指令的执行顺序之后，uops通过每时钟周期4条的速度进入Reservation Station中继站（保留站），总共36条目的中继站uops就开始等待超标量（Superscaler）执行引擎乱序执行了。自从Pentium开始，Intel就开始在处理器里面采用了超标量设计（Pentium是两路超标量处理器），超标量的意思就是多个执行单元，它可以同时执行多条没有相互依赖性的指令，从而达到提升ILP指令级并行化的目的。Nehalem具备6个执行端口，每个执行端口具有多个不同的单元以执行不同的任务，然而同一时间只能由一条指令（uop）进入执行端口，因此也可以认为Nehalem有6个“执行单元”，在每个时钟周期内可以执行最多6个操作（或者说，6条指令），和Core一样；令人意外的是，古老的Pentium 4每时钟周期也能执行最多6个指令，虽然它只有4个执行端口，然而其中两个执行端口的ALU单元是双倍速的（Double Pump，每时钟周期执行两条ALU指令）。
Nehalem:Superscale Execution Unit超标量执行单元
中文版本可能反而不便于理解（如负载操作实际上是Load载入操作），下面是英文原版：
Nehalem:Superscale Execution Unit超标量执行单元
36条目的中继站指令在分发器的管理下，挑选出尽量多的可以同时执行的指令（也就是乱序执行的意思）??最多6条??发送到执行端口。
这些执行端口并不都是用于计算，实际上，有三个执行端口是专门用来执行内存相关的操作的，只有剩下的三个是计算端口，因此，在这一点上Nehalem实际上是跟Core架构一样的，这也可以解释为什么有些情况下，Nehalem和Core相比没有什么性能提升。
计算操作分为两种：使用ALU（Arithmetic Logic Unit，算术逻辑单元）的整数（Integer）运算和使用FPU（Floating Point Unit，浮点运算单元）的浮点（Floating Point）运算。SSE指令（包括SSE1到SSE4）是一种特例，它虽然有整数也有浮点，然而它们使用的都是128bit浮点寄存器，使用的也大部分是FPU电路。在Nehalem中，三个计算端口都可以做整数运算（包括MMX）或者SSE运算（浮点运算不太一样，只有两个端口可以进行浮点ADD和MUL/DIV运算，因此每时钟周期最多进行2个浮点计算，这也是目前Intel处理器浮点性能不如整数性能突出的原因），不过每一个执行端口都不是完全一致：只有端口0有浮点乘和除功能，只有端口5有分支能力（这个执行单元将会与分支预测单元连接），其他FP/SSE能力也不尽相同，这些不对称之处都由统一的分发器来理解，并进行指令的调度管理。没有采用完全对称的设计可能是基于统计学上的考虑。和Core一样，Nehalem的也没有采用Pentium 4那样的2倍频的ALU设计（在Pentium 4，ALU的运算频率是CPU主频的两倍，因此整数性能明显要比浮点性能突出）。
The Core Execution Engine: "Computional" Unit
Nehalem的ALU和FP/SSE单元都使用了相同的三个端口，相比之下，Barcelona Opteron的FP/SSE单元和ALU单元具有不同的入口，因此每时钟周期可以同时执行最多6条计算指令。不过，Barcelona Opteron的3存取操作使用和ALU单元一样的端口，因此其执行单元每时钟周期可以同时执行的指令仍然为6条。
不幸的是，虽然可以同时执行的指令很多，然而在流水线架构当中运行速度并不是由最“宽”的单元来决定的，而是由最“窄”的单元来决定的。这就是木桶原理，Opteron的解码器后端只能每时钟周期输出3条uops，而Nehalem/Core2则能输出4条，因此它们的实际最大每时钟运行指令数是3/4，而不是6。同样地，多少路超标量在这些乱序架构处理器中也不再按照运算单元来划分，Core Duo及之前（到Pentium Pro为止）均为三路超标量处理器，Core 2/Nehalem则为四路超标量处理器。可见在微架构上，Nehalem/Core显然是要比其他处理器快一些。顺便说一下，这也是Intel在超线程示意图中，使用4个宽度的方块来表示而不是6个方块的原因。
评测文章导读：
渝公网安备 50010702500475号