|
|
The Chip
Barcelona是AMD第一款四核心处理器，四个核心将被构建于一个65nm的Die上。与Intel的Kentsfield四核心处理器不同，Barcelona并不是由两个双核Die拼凑而成，所以AMD把它叫做真正意义上的四核心。尽管AMD的方法在技术上有着优势，但我们不能确定这一优势是否可以在实际的处理器性能中能显现出来。
Barcelona以AMD的65nm制造工艺为基础，有着比K8更为复杂的设计，需要总共11层的金属层。而K8需要9层，Core 2则只需要8层。在过去的几年中，AMD在同代处理器中的金属层一向比Intel多，所以Barcelona也不例外。更多的金属层使制造更为复杂，但对终端用户来说，区别不大。
Barcelona在一个Die上有着四颗核心，还有一个2 MB的三级缓存，总共集成了4.63亿个晶体管，相比Kentsiefield的5.82亿晶体管要少1.19亿。晶体管越少，缓存容量就越小，每个Barcelona核心有128 KB一级缓存和512 KB二级缓存，四个核心共享2 MB三级缓存，所以一个Die上共有4.5 MB缓存。而由两个Die组成的Kentsfield，有两个核心，每个核心有64 KB一级缓存和4 MB二级缓存，一个Kentsfield处理器在总共有8.25 MB缓存，比Barcelona多80%，所以在晶体管总数量上要多25.6%。
同时，Barcelona的晶体管数目也比一个四核心的K8处理器要多得多。我们估计一个没有缓存的Athlon 64 X2双核心处理器晶体管数量大约是0.94亿，Barcelona是2.47亿。就算将其晶体管数量乘2（以达到4颗核心）也不及到Barcelona的数量。注意，将0.94亿这个数字乘以2，还是不能和Barcelona的一个On-Die北桥相比。其实，在Barcelona中，除了多核心和缓存应用外，为了架构上的增强还增加了6000万个晶体管（每核心1500万）。
SSE128
在Barcelona上的许多“主要”改进都是由一个意义重大的变革而引发的，AMD称之为SSE128。在K8架构中，AMD可以并行处理两个SSE操作，而其SSE执行单元只有64-bits宽。对于128-bit的SSE操作，K8必须将其分为两个64-bit来完成。这也就是说，当一个128-bit SSE指令被取出时，它首先解码为两个micro-ops（每个都是64-bit半指令），然后对于单个的指令再进行一次特别的解码。Barcelona将SSE操作从64-bits扩展为128-bits，所以现在128-bit SSE操作不需要分为两个64-bit来处理。这也意味着可以用单个的micro-op来处理128-bit SSE指令，浮点调度程序可以更好的应对128-bit SSE任务。
SSE执行带宽的增加，在核心中引起了其他一些变化。自从在执行128-bit SSE指令时可以得到更高的带宽后，AMD又发现了新的瓶颈：指令读取带宽。这些128-bit SSE指令都比较大，为了最大化并行解码的数量，Barcelona核心现在可以每周期读取32-bytes，而K8为16-bytes。32B指令读取能力不仅对SSE代码有益，对整数代码也有好处。通常，高并行处理指令数会以显著性能提升的形式表现出来。
现在你可以读取和解码更多的指令，那就还需要为执行核心提供更多的数据。所以AMD对一级数据缓存和Barcelona的SSE寄存器间的接口进行了扩展。Barcelona现在可以在一级数据缓存中每周期运行双128-bit SSE负载，而在K8里是双64-bit负载。AMD接着扩展了二级缓存和内存控制器之间的接口，现在每个周期可以传输128-bits，使上述改进再次平衡。
SSE128改进的顶峰，类似于从Yonah到Merom的改变。在Conroe/Merom之前，Yonah在FP/SSE性能上不能和K8相比。在一般应用上Yonah和K8基本一样，但在用到视频编码的时候，专业的3D和游戏的表现上，就明显不能与K8相比了。
Yonah的SSE性能有过一系列的改进，但直到Intel的Core 2处理器出现才使得Intel真正在视频编码的测试上胜过K8。不论这些改进是否是因为Core 2中提高了单周期SSE吞吐量或者更宽的前端，还是二者兼而有之，编码性能是AMD如今的心中隐痛，而SSE128的改进可以对此有些帮助。
内核调整
Barcelona的诸多进步中，SSE128还只是冰山一角。Barcelona性能提升的清单中，第一个就是分支预测。
一般而言，CPU的分支预测精度决定了你的设计可以作到多宽和多深。在预测前的误报指令平均数，决定了可以运行指令的数量，以此也控制了可以有多少个执行单元保持反馈。K8的分支预测非常好，并且为其架构进行了优化，在Intel Pentium M和Pentium 4上的一些优点，AMD也可以从中得到借鉴。
Barcelona增加了512条间接分支预测，用来预测间接分支。一个间接分支就是一个由内存地址指向分支对象的位置。换句话说，一个分支有着多个对象，分支并没有直接指向一个分支指令里的标签，而是由CPU向内存位置发送了间接分支指令，其中包含了要到达的指令地址。误预测分支数量越少，处理器的效率越高（这样可以降低能耗）。出于这一考虑，Intel在Pentium M处理器上增加了间接分支预测。Intel Prescott核心处理器也在NetBurst架构上用到间接分支预测，来弥补性能的不足。
在Prescott中，仅仅增加间接分支预测就可以在SPEC CPU2000测试中降低12%的误报。而AMD和Intel在误报算法上具体有什么不同，并没有公开，我们期待当间接分支普及的时候，处理器性能会有很大的提升。在SPEC CPU2000的253.perlbmk测试中，Prescott误报分支的减少是非常显著的，达到了55%。对于Barcelona，越少的分支误报意味着越高的整体IPC和越高的效率。尽管AMD不用去像Intel那样为Prescott“深不可测”的流水线担忧，但效率的改进还是有意义的。
Barcelona中的改进不仅仅是一个间接分支预测，新核心中的返回栈容量是K8的两倍。在很深层的呼叫链中，比如编码调用许多子程序（例如递归函数），CPU为持续跟踪来路会彻底用完所有的空间，一旦开始丢失返回地址，将失去预报分支的能力。Barcelona将返回栈容量翻倍来缓解这一问题。这样的改进一般在制造CPU时，通过软件模仿来实现，所以我们询问AMD在Barcelona中使用了什么样的软件。AMD没有给我们具体的说明，而是说，返回栈大小的改进，是根据“大软件商”的要求来实现的。（盖茨同学？）
比K8分支预测更进步的最后一项改进是通过正常的途径——Barcelona比其前辈跟踪了更多的分支。在分支预测上没有什么神秘的技术：一个处理器监视处理分支就是依靠历史数据，历史数据保存的越多，分支预测就越准确。这就像象棋游戏将大量棋谱、路数保存在内，让电脑选择合适招数应对。K8设计为130nm的制造工艺，最初的Barcelona设计为65nm，AMD有着足够的Die空间来追踪更多的分支历史数据。
边带堆栈优化器
Intel的初代Pentium M引入了一个Intel称之为专用堆栈管理器的功能。顾名思义，专用堆栈管理器用来处理所有x86堆栈操作（也就是push、pop、call、return）。堆栈管理器的用途就是将这些在代码中经常被函数调用的堆栈操作与其他发往CPU的x86指令流分开。专用堆栈管理器将完成解码和“执行”这些操作，这样他们就不会阻塞处理器的解码和在流水线中滞后执行单元。Intel卸下了一些分离硬件的操作，以“扩展”核心。
在Barcelona中，AMD引入了类似的技术，称为边带堆栈优化器。堆栈指令不再通过三方解码器，堆栈操作也不再通过整数执行单元，在最少的成本上有效扩展了Barcelon。边带堆栈优化器，就象Intel的专用堆栈管理器一样，使用自己的加法器来处理所有的堆栈操作。这一小小的改进可以使整体性能有所提高，值得AMD去实现这个功能。
更快的加载
观察Athlon 64和Intel Core 2处理器的性能，我们很容易理解为什么Intel在应用上有着更强的性能，因为大量使用了SSE。但AMD使用了集成在Die中的内存控制器，为什么没有在游戏和商务应用上更出色呢？Core 2的大容量二级缓存和强大的预取能力已经可以胜过AMD的On-Die内存控制器了吗？
Intel的Core微架构中，一个主要的优势就是它拥有允许load指令绕过先前的load和store指令的能力。平均来说，程序中大约有1/3的指令是以load来结束的，那么如果能提高加载性能，就能够在整体的性能上有所提升。在Intel Core微架构上，loads是可以被重新排列的，这样可以确保指令根据loads来读取所需数据，不需要等待内存访问。
Core还允许loads排在stores之前，这在以前是不允许的，因为可能会导致刚加载的数据使之前存储的数据无效。Intel认为在load后接着需要store的可能性很小，大概只有1-2%，所以在store前要求load时，使用一个适当精确的预测器你就可以进行正确地估算。Intel Core 2处理器的特点是逻辑预测，看store和load是否共享内存地址。如果预测器发现它们并未共享内存地址，那么就允许在store之前进行load。如果过万一预测器不准，那么load必须重新完成（与处理器误预测分支相类似）。
AMD K8架构与上述不同，在其他loads和stores之前不允许次序颠倒的load命令。所以，就算没有On-Die内存控制器，Intel也可以做到在一些内存操作上比AMD更快。不过Barcelona解决了这一问题，采用的是与INTEL Core 2处理器上相类似的解决方案。
Barcelona现在可以像Core 2处理器那样在其他loads之前进行loads重新排序，还可以在load和store不共享内存地址时，将loads在其他stores之前执行。Intel使用了预测器来测定load和store是否共享地址，而AMD在这一点上就比较保守。Barcelona需要等待store地址计算出来后，再确定是否将load提前执行。Barcelona采用这种方式的好处是绝对不会出错，也就不存在误预报的可能性。AMD的设计人员本来是想向Intel那样用一个预测器，但发现那样的设计并不能得到性能的提升。因为AMD在每个时钟上可以产生三个store地址，它有三个地址生成单元（Address Generation Units），而Intel只有一个。所以，AMD选择先计算store地址再进行判断的方法并不会造成性能下降，非常符合其设计。在该方面，应该说AMD占有一定优势。
在Barcelona中乱序加载处理的改进，将证明他们比Core 2更为有效。AMD以往在Int/FP程序上不能做任何的re-ordering load，而Core Duo在一定范围内可以进行re-ordering。
更多的改进
Translation Lookaside Buffers简称为TLBs，可以称作旁路转换缓冲或者页表缓冲，它在系统中用来储存虚拟地址到物理地址的转换图表。TLB的命中率一般十分高，但随着程序越来越大，就产生了更高的内存需求量，微处理器设计人员必须修正TLB的容量来适应需求。在K8中，AMD在K7的基础上增加了TLB的容量，在Barcelona中，AMD又一次采用了这一措施。
Barcelona的TLB比K8要稍大一些，不过它们都支持1G的页面，这在数据库应用和虚拟负载方面很实用。AMD在Barcelona中还引入了128条2M二级TLB，有助于处理使用更大页面的新程序。Barcelona中对TLB的改进对于桌面应用没有实际的影响，但在有着较大的内存需求量的服务器应用上还是有所改善的。
当Intel引入第二代Pentium M--Dothan的时候，它的一个主要改进就是更低的integer divide latency。在那时这一细节是没什么价值的，如今AMD表示要花精力去减少Barcelona的integer divide latency。我们不能确定AMD是否会以类似Dothan所采用的方式来实现，但可以确定在实际的应用中不能期待它能带来显著的性能提升。这些调整只能综合在一起对整体的性能有些提高，不是说某一个改进就可以将性能翻倍。
为了在不增加众多数量晶体管的情况下提升Barcelona，AMD将几个微代码指令注入fastpath解码指令当中。一个微代码指令将花很长时间来解码，要比通过核心里的fastpath解码器的时间要长的多。CALL和RET-Imm指令现在已经作为fastpath而存在，它们为Barcelona的边带堆栈优化做出了贡献。MOVs从SSE寄存器到整形寄存器也已经经过fastpath处理。
在“指令”这个话题中，AMD还介绍了一些新的ISA扩展。包含有两个新的二进制指令：LZCNT和POPCNT。Leading Zero Count(LZCNT)将一个OP中的前导零进行记数，而Pop Count将OP中的前导1进行记数，两个指令都是用于密码应用的。AMD还引入了四个新的SSE扩展：EXTRQ/INSERTQ, MOVNTSD/MOVNTSS。前两个扩展是将操作结合到一个单个的指令中，后两个是梯状流存储器（可以以梯形操作进行存储）。在Penryn和其他未来的Intel处理器中，我们也会看到类似的指令。
[ 本帖最后由 ilovejulia 于 2007-6-17 19:02 编辑 ] |
|
IP卡
狗仔卡
发表于 2007-6-17 18:59
QQ好友和群
收藏
分享
好贴
烂贴
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
楼主