评估 Linux on POWER 的性能

http://www.ibm.com/developerwork ... xonpower/index.html
应用程序性能评估在现代化计算机上可能会是一个复杂的任务。常用的工具很难处理所有性能变量。每个工作负载因它所施压的计算机子系统不同而各有不同。与对 IO 密集型或内存密集型程序进行调优相比，对 CPU 密集型的程序进行测量和调优有相当大的差异。在本文中，我们将重点描述编译语言环境（C、C++ 和其他语言）中的 CPU 密集型和内存密集型程序。我们将演示如何：

    查找程序 hotspots（在执行指令的发生比例较高的程序中的一个区域、函数和方法）
    使用处理器上提供的硬件性能计数器，测量程序在 POWER7 上的性能
    确定用于在 Linux 上进行性能评估的工具。
从 CPI 指标的讨论开始了解应用程序性能分析。每指令周期 (CPI) 指标是完成一个指令所需的处理器周期数。每个指令被分解为多个阶段：一个经典的 RISC 流水线指令会拥有一个提取阶段，然后是指令解码/寄存器读取、执行、一个可选的内存访问，最后是写回阶段。一个 CPU 可以利用指令级并行性提高其 CPI 指标（用较低的 CPI 值测算）：每个阶段都将处理不同阶段中的指令。在优化时，可以尝试尽量降低 CPI 值，以最大限度地提高系统的利用率。图 1 演示了流水线处理器中的优化指令流。
有时一个阶段并不是完全独立于其他阶段存在的，或者说会发出一个有依赖性的指令，强制处理器满足这种需求，然后再继续执行。例如，对于后随算术指令的内存负载，会使得处理器先将数据提取到缓存或内存中，然后发出算术指令。在出现这种情况时，据说处理器流水线会遇到一个停滞，而该停滞会使流水线发生停滞。 图 2 显示了一个停滞的流水线。
在 图 1 和 图 2 的示例中，假设在一个完全填充的流水线上执行 11 个操作周期期间（每一个周期内完成一个指令），处理器可以执行 8 个指令。然而，当出现三个周期的停滞时，在相同数量的周期中，只能执行五个指令。性能将损失 40% 左右。根据这种算法，有些停滞是不可避免的；但是，仔细的分析就可以提供一些关于如何改写或调整部分代码的提示和建议，从而避免这些停滞。在文章 “Modern Microprocessors - a 90 minute guide” 中，可以找到有关现代 CPU 的流水线和指令级并行性的更完整的启发性解释（参阅 参考资料）。

CPI Breakdown Model (CBM) 将功能处理器的各阶段与性能计数器相关联，以显示哪个 CPU 功能单元发生了停滞。CBM 依赖于 CPU 架构和处理器模型；Power Architecture 和 Intel Architecture 具有完全不同的 CBM。POWER5 CBM 与 POWER7 CBM 虽然类似，但仍有所不同。图 3 显示了 POWER7 CBM 的一部分。（请参阅 此信息的文字版。）
未来的优化应尝试通过降低 CPU 停滞和/或 GCT (Global Completion Table) 百分比将该数字最大化。根据这份报告，另一个分析途径是识别发生停滞的代码。要做到这一点，可以使用 perf record 命令。该命令将追踪原始计数器的性能，并利用进程回溯来创建一个映射，从而识别哪个符号生成最多的硬件事件。这类似于 OProfile 的工作方式。在本例中，要跟踪 PM_CMPLU_STALL_DCACHE_MISS 事件，可以发出 清单 14 中的命令：
这个实现相当复杂，主要是因为算法执行了许多 FP 到 INT 的逐位转换。它假定某些 FP 操作（如比较和乘法）在使用浮点数指令时比使用定点指令更昂贵。在某些架构上存在这种情况，但在 Power Architecture 上则不然。

评估该实现的第一步是创建一个可以分析的基准。在这种情况下，因为该实现仅仅是一个带有两个参数和一个简单算法的函数（没有内部函数调用或其他路径），所以可以建立一个简单的基准来评估它（查看 下载 中的 hypot_bench.tar.gz）。基准是性能评估的一部分；优化应该加快算法的运行，或者加快利用总工作负载性能的算法关键部分的运行。合成基准（像这个基准）应该代表该函数的正常使用。由于优化工作往往需要消耗大量资源和时间，所以您需要将重点放在最常见的情况或预期行为上。如果试图优化的代码所代表的程序总体使用率较低，那么这往往是一种资源浪费。
最后，比较这两种实现，执行下面的简单测试。在使用和不使用新算法的情况下重新编译 GLIBC，比较每个基准运行的总时间。默认 GLIBC 实现结果位于 清单 25 中：
优化版本的结果如 清单 26 中所示：
这最终将获得超过 100% 的性能提高，使基准时间减少一半。
结束语

含有硬件计数器分析的性能评估是一个功能强大的工具，可以了解工作负载在特定处理器上的行为方式，并给出关于可在哪些地方进行性能优化的提示。最新的 POWER7 处理器有数百个可用的性能计数器，所以我们介绍了一个简单的模型，说明如何将工作负载映射到 CPU 停滞。了解 POWER7 CBM 有点复杂，所以我们还介绍了一些适用于 Linux 的工具，以便简化它。性能评估的策略集中在如何找到热点，如何理解应用程序的内存模式，以及如何使用 POWER7 CBM。最后，我们使用了 GLIBC 内的三角函数上所完成的最新优化来解释用于优化代码的性能分析。

http://www.ibm.com/developerwork ... xonpower/index.html
应用程序性能评估在现代化计算机上可能会是一个复杂的任务。常用的工具很难处理所有性能变量。每个工作负载因它所施压的计算机子系统不同而各有不同。与对 IO 密集型或内存密集型程序进行调优相比，对 CPU 密集型的程序进行测量和调优有相当大的差异。在本文中，我们将重点描述编译语言环境（C、C++ 和其他语言）中的 CPU 密集型和内存密集型程序。我们将演示如何：

    查找程序 hotspots（在执行指令的发生比例较高的程序中的一个区域、函数和方法）
    使用处理器上提供的硬件性能计数器，测量程序在 POWER7 上的性能
    确定用于在 Linux 上进行性能评估的工具。
从 CPI 指标的讨论开始了解应用程序性能分析。每指令周期 (CPI) 指标是完成一个指令所需的处理器周期数。每个指令被分解为多个阶段：一个经典的 RISC 流水线指令会拥有一个提取阶段，然后是指令解码/寄存器读取、执行、一个可选的内存访问，最后是写回阶段。一个 CPU 可以利用指令级并行性提高其 CPI 指标（用较低的 CPI 值测算）：每个阶段都将处理不同阶段中的指令。在优化时，可以尝试尽量降低 CPI 值，以最大限度地提高系统的利用率。图 1 演示了流水线处理器中的优化指令流。
有时一个阶段并不是完全独立于其他阶段存在的，或者说会发出一个有依赖性的指令，强制处理器满足这种需求，然后再继续执行。例如，对于后随算术指令的内存负载，会使得处理器先将数据提取到缓存或内存中，然后发出算术指令。在出现这种情况时，据说处理器流水线会遇到一个停滞，而该停滞会使流水线发生停滞。 图 2 显示了一个停滞的流水线。
在 图 1 和 图 2 的示例中，假设在一个完全填充的流水线上执行 11 个操作周期期间（每一个周期内完成一个指令），处理器可以执行 8 个指令。然而，当出现三个周期的停滞时，在相同数量的周期中，只能执行五个指令。性能将损失 40% 左右。根据这种算法，有些停滞是不可避免的；但是，仔细的分析就可以提供一些关于如何改写或调整部分代码的提示和建议，从而避免这些停滞。在文章 “Modern Microprocessors - a 90 minute guide” 中，可以找到有关现代 CPU 的流水线和指令级并行性的更完整的启发性解释（参阅 参考资料）。

CPI Breakdown Model (CBM) 将功能处理器的各阶段与性能计数器相关联，以显示哪个 CPU 功能单元发生了停滞。CBM 依赖于 CPU 架构和处理器模型；Power Architecture 和 Intel Architecture 具有完全不同的 CBM。POWER5 CBM 与 POWER7 CBM 虽然类似，但仍有所不同。图 3 显示了 POWER7 CBM 的一部分。（请参阅 此信息的文字版。）
未来的优化应尝试通过降低 CPU 停滞和/或 GCT (Global Completion Table) 百分比将该数字最大化。根据这份报告，另一个分析途径是识别发生停滞的代码。要做到这一点，可以使用 perf record 命令。该命令将追踪原始计数器的性能，并利用进程回溯来创建一个映射，从而识别哪个符号生成最多的硬件事件。这类似于 OProfile 的工作方式。在本例中，要跟踪 PM_CMPLU_STALL_DCACHE_MISS 事件，可以发出 清单 14 中的命令：
这个实现相当复杂，主要是因为算法执行了许多 FP 到 INT 的逐位转换。它假定某些 FP 操作（如比较和乘法）在使用浮点数指令时比使用定点指令更昂贵。在某些架构上存在这种情况，但在 Power Architecture 上则不然。

评估该实现的第一步是创建一个可以分析的基准。在这种情况下，因为该实现仅仅是一个带有两个参数和一个简单算法的函数（没有内部函数调用或其他路径），所以可以建立一个简单的基准来评估它（查看 下载 中的 hypot_bench.tar.gz）。基准是性能评估的一部分；优化应该加快算法的运行，或者加快利用总工作负载性能的算法关键部分的运行。合成基准（像这个基准）应该代表该函数的正常使用。由于优化工作往往需要消耗大量资源和时间，所以您需要将重点放在最常见的情况或预期行为上。如果试图优化的代码所代表的程序总体使用率较低，那么这往往是一种资源浪费。
最后，比较这两种实现，执行下面的简单测试。在使用和不使用新算法的情况下重新编译 GLIBC，比较每个基准运行的总时间。默认 GLIBC 实现结果位于 清单 25 中：
优化版本的结果如 清单 26 中所示：
这最终将获得超过 100% 的性能提高，使基准时间减少一半。
结束语

含有硬件计数器分析的性能评估是一个功能强大的工具，可以了解工作负载在特定处理器上的行为方式，并给出关于可在哪些地方进行性能优化的提示。最新的 POWER7 处理器有数百个可用的性能计数器，所以我们介绍了一个简单的模型，说明如何将工作负载映射到 CPU 停滞。了解 POWER7 CBM 有点复杂，所以我们还介绍了一些适用于 Linux 的工具，以便简化它。性能评估的策略集中在如何找到热点，如何理解应用程序的内存模式，以及如何使用 POWER7 CBM。最后，我们使用了 GLIBC 内的三角函数上所完成的最新优化来解释用于优化代码的性能分析。