使用 UltraSPARC T1 和 UltraSPARC T2 性能计数器估算内核负载并查找潜在的性能改善区域。
目录
* 简介
* 指令利用率
* 浮点计算
* 延迟预算利用率
* 估算 UltraSPARC T1 处理器的延迟预算
* 估算 UltraSPARC T1 处理器的延迟预算
* 优化 CMT 处理器的其他方法
简介
UltraSPARC T1 和 UltraSPARC T2 处理器专为高吞吐量设计，它们具备多个相同的内核，因此支持多线程处理。UltraSPARC T1 处理器具备 8 个内核，每个内核在一个周期内能够发送一条
命令并且支持 4 个线程，共相当于 32 个虚拟处理器。UltraSPARC T2 处理器也有 8 个内核，每个内核在一个周期内能够发送 2 条指令而且支持 8 个线程，共相当于 64 个虚拟处理器。处理器性能的峰值通过计算频率与内核数量以及指令数量的乘积而得到。假设两个处理器运行的频率都是 1.4GHz，那么 UltraSPARC T1 处理器每秒钟能够处理 112（1.4*8=11.2）亿条指令，UltraSPARC T2 处理器每秒钟能够处理 224 亿条指令。
由于多个线程共享一个内核，因此内核满载与否是一个非常有趣的问题。举例来说，假设内核是满载的，这就意味着每个线程应该能均等地获得共享指令内核。所以每个线程每 4 个周期就能发送一条指令。在这种情况下，内核运行较少的线程是否可提高
应用程序的反应时间呢？这也是一个有趣的问题。另一个问题，如果某个特定内核上的线程并非都处于忙碌状态，那么内核是否有充足的指令处理能力来处理额外线程呢？
本文将深入研究 UltraSPARC T1 和 UltraSPARC T2 内核利用率的问题，并尝试确定分配较少或较多的虚拟处理器是否可以提高性能。
指令利用率
相对而言，使用 cpustat 命令（作为超级
用户）确定
系统的平均指令处理速度是比较容易的。在下面的代码示例中，我们每隔 10 秒钟使用 cpustat 收集指令
数据一次。
每个 CPU 都有一条 cpustat 输出线。相对而言，通过后处理为各内核提供格式化利用率输出信息（以百分比的形式）比较简单。（psrinfo -v 的作用是报告处理器类型以及计算所需的时钟速度信息）。事实上，可
下载的 corestat
工具已经执行了此计算。
指令数方面的信息对确定内核是否完全处于饱和状态非常有用，同时可用于判断内核是否有多余能力增加额外线程，以及能否通过降低活动线程数量的方式来提高反应时间。
浮点计算
UltraSPARC T1 处理器有一个单独的浮点运算单元，而 UltraSPARC T2 处理器的每个内核均有一个浮点运算单元。因此，人们就会类似地问及浮点运算单元利用率的问题。两个处理器都有一个计数器记录浮点指令。如下例所示，cpustat 命令的结果显示了浮点指令数以及指令总数：
此外，还可以计算两种处理器浮点运算单元的利用率。
延迟预算利用率
传统处理器与 UltraSPARC T1、UltraSPARC T2 的不同之处在于它们对优化机制的响应方式不同。在传统的处理器上，代码优化涉及确定处理器延迟的原因以及努力排除这些延迟。例如，您可以增加预取指令提高缓冲区的命中率，从而相应的降低
内存的延迟时间。
然而，在 UltraSPARC T1 和 UltraSPARC T2 处理器上，这些延迟周期被共享内核的其他线程占有，因此不能再利用延迟周期进行优化。尽管如此，了解延迟周期仍然是很有趣的事情，但是从一个单独的线程中撤去延迟周期却不一定引起吞吐量的直接提高，虽然这可能有助于提高线程响应。
要解释这种情况，请考虑到理想负载情况下每个线程每 4 个周期处理一条指令这一事实。这意味着对于每条指令来说，线程在 3 个周期内不能对其进行处理。如果线程对每条指令的延迟时间超过 3 个周期，那么线程会因获得比公平共享更少的指令预算而结束。如果指令的延迟少于 3 个周期，并不一定导致指令处理更频繁，因为其他 3 个线程可能还有待处理的指令。
看待这一问题的另一个角度是设想每个线程有一个指令预算，他们对应着公平负载下每秒钟期望执行的指令数量。每个线程还有一个延迟预算，该预算与延迟事件减少执行指令数量之前每秒钟线程可能被延迟的周期数相对应，其值是指令预算的 3 倍。
许多事件都将引起延迟，从而用完延迟周期的预算，比如缓冲命中失败。所以了解延迟的主要原因是很有用的。如果计数器记录事件而非周期，那么计算每个事件估计的花费与事件数量的乘积就是必要的。这些花费是处理器特有的。
估算 UltraSPARC T1 的延迟预算
不幸的是，UltraSPARC T1 处理器上的大部分性能计数器计算的都是事件而不是周期。存储队列计数器是一个例外，它计算的是存储队列处于满时的周期数。然而，由于传递路径很简易，所以用事件的数量乘以事件的估计花费就可以估算出各种延迟所用去的周期数，如下表所示。
表 1：延迟周期的估算数量
可以编写一个简单的脚本来多次运行一个应用程序，并计算各事件所造成处理器延迟的周期数。在二级缓存中含数据集的应用程序上运行此脚本的结果如下表。
表 2：计算 UltraSPARC T1 处理器延迟周期的采样结果
很明显，大部分延迟时间（50%）是因为驻留在二级缓存芯片上的信息在高速缓存命中失败时进行加载所造成的。一小部分加载也会在二级缓存命中时失败，这会花掉巨额的时间用于从内存读取数据。 如果这是真实的代码，那么提高高速缓存的利用率以及根据读取过的信息进行信息读取将会实行能得到全面提高。
然而，看看指令数就会发现，应用程序一般只会用到指令预算的 14%。因为每个内核有 4 个线程，每个内核每个周期能够处理一条指令，因此一个理想的应用程序将用到指令预算的 25%。所以虽然降低高速缓存命中失败的次数会提高性能，但是最优性能收益也只有 14% - 25% 的指令预算利用率，如果内核上的所有线程处于活动状态，那么性能提高接近双倍。
综合考虑，传统处理器上的所有内存延迟时间都可以转变成性能，而在 CMT 处理器上由于多线 程之间共享周期所以内存延迟时间的提高有一个上限。
估算 UltraSPARC T1 的延迟预算
UltraSPARC T2 处理器有 8 个线程共享一个内核，该内核每个周期能处理 2 条指令，这使得这些指令具有同样的预算 ：即每个线程每 4 个周期能够处理一条指令，有 3 个周期不能处理指令。
在 UltraSPARC T2 处理器上有一系列不同的性能计数器，其上带有新型乘法器，没有周期计 数器用于存储延迟队列，同时，浮点指令计数器的名字也有所不同。下表显示的是性能计数器以及他们的 乘法器。
表 3：UltraSPARC T2 处理器上的性能计数器
在 UltraSPARC T2 上运行相同代码所产生的结果如下表所示。
表 4：计算 UltraSPARC T2 处理器延迟周期的抽样结果
大部分时间同样花在对驻留在二级缓存的数据的加载操作上。此应用程序用到总周期的 16%，仍小于理论上 25% 的峰值。因此，降低高速缓存命中失败的概率能够进一步提高性能。另一个值得考虑 的问题是内存管道由 8 个线程共享，应用程序的峰值性能依赖于内核每次载入两条指令，否则应用程序 可能被限定在每 8 个周期处理一条指令的范围内。
优化 CMT 处理器的其他方法
前面的讨论说明运行在 CMT处理器上的应用程序对内存延迟的花费有很大的容忍力。在较传统的处理器上，内存延迟时间可以被降到最低，这将直接导致性能上的收益。在 CMT 处理器上，减少延迟时间所导致的性能收益仅能达到
进程指令处理预算耗费的 25% 这一水平，在此之上减少延迟事件不太可能再产生明显的性能收益，因此为进一步减少指令延迟所作的工作都是白费。
对于 CMT 处理器，可采用三种方法提高性能，按照有效性由高到低排列如下：
* 使用更多线程。每个额外的线程都将获取一个新的指令处理预算，两个线程可以达到事半功倍速的效果。
* 减少指令数。对于 UltraSPARC T1 和 UltraSPARC T2 处理器，每个线程每次可处理一条指令 ，因此指令数将与完成任务所花费的时间直接挂勾。一个处理器在同一个周期内可能处理一个线程中的多条指令，因此一些处理指令的取得应该不受限制
* 降低延迟时间。降低延迟时间可能不会直接提高性能，因为一个线程可能在另外一个线程的延迟时间内工作。当内核以峰值指令速度工作时，通过降低延迟事件耗费周期的方式不可能获得性能收益。当然，一个线程上的延迟时间可能使该线程获得指令预算的公平共享，并且可能降低线程的响应时间，但不会对系统的吞吐量产生影响
[
本帖最后由 云杉上的蝴蝶 于 2008-6-10 20:23 编辑 ]
Powered by IXPUB.Net © 2001-2007 All Right Reserved. 
