scalasca1.3用户手册中文.doc

scalasca 1.3 用户手册目 录1 引言11.1 如何阅读本文档11.2 性能优化周期11.3 Scalasca概述22 入门指南42.1 插桩42.2 运行时测量收集与分析52.3 分析报告审查62.3.1 CUBE3的使用62.4 一个完整的工作流程例子73. 应用插桩123.1 自动编译器插桩133.2 手动区域插桩143.3 半自动插桩153.4 使用PDTOOLKIT进行自动源代码插桩163.4.1 限制173.5 选择插桩184. 测量收集与分析194.1 NEXUS配置194.2 测量配置204.1.2 基于编译器插桩的子程序过滤204.2.2 选择性MPI事件生成204.3 硬件计数器度量参数的测量与分析214.4 自动并行事件痕迹分析224.5 自动串行事件痕迹分析235. 辅助工具255.1 辅助EPILOG事件痕迹工具255.2 痕迹转换器255.3 用户指定的虚拟拓扑记录25附录A：MPI包联系27A.1 函数到组27A.2 组到函数34参考文献411 引言超级计算是现代科学与工程的关键技术之一，是解决高复杂度关键问题不可缺少的。作为当今大规模计算系统生产应用的先决条件，高性能计算机需要强大而健壮的性能分析工具，这些工具能够优化并行应用使之更有效、更高效。Scalasca是一个由Jlich超算中心开发的性能分析工具集，它被专门设计用于包括IBM Blue Gene 和 Cray XT等大规模系统，不过，它也适用于使用MPI和/或OpenMP的较小的高性能计算平台。Scalasca支持一种渐增式的性能分析处理，它采用不断细化的测量配置策略，通过事件跟踪机制将并发行为的深入研究与运行时摘要有机地结合在一起。Scalasca的一个与众不同的特征是它能够识别如工作负载分布不均衡等所导致的等待状态。特别是当试图测量处理器数量巨大的通信集约型应用时，这些等待状态对取得好的性能可能是严峻的挑战。与它的前身KOJAK相比，Scalasca可以发现这些等待状态，即使在使用一个新的并行跟踪分析模式的很大的过程配置中。1.1 如何阅读本文档1.2 性能优化周期无论是为了单个核心的性能还是可扩展性，对应用进行优化的基本途径是很相似的。首先，应用的行为必须被监测，然后可以评估记录下来的行为并得出进一步改进的结论。这是一个迭代过程，可以用一个周期来描述，称作性能优化周期。它由下列部分组成：l 插桩（Instrumentation）l 测量（Measurement）l 分析（Analysis）l 表示（Presentation）l 评估（Evaluation）l 代码优化（Optimization of the code）图1.1 性能优化周期如图1.1所示，用户以原始（未优化）的应用开始，进入优化周期的“插桩”阶段。插桩描述修改应用程序代码的处理过程，使得能够在应用运行期间对性能相关数据进行测量。Scalasca可以通过不同的机制来完成这一工作。如源代码插桩、基于编译器的自动插桩和连接预插桩库。源代码级插桩可以通过引入附加指令到源代码中来实现。大多数系统中，插桩工作可以通过使用编译器的专门特征自动完成，但是这种方法通常不允许进行细粒度的插桩控制。第三种方法是使用预插桩库，预插桩库中含有已插桩的相关库函数的实现。消息传递接口标准MPI提供了用于这种插桩的专门接口，称作PMPI接口。由于这种接口被定义在MPI标准中，因此它的API是轻量的，并且为工具开发者创造了一个为多种不同的MPI实现提供单一轻量级测量库的机会。当被插桩代码在测量阶段执行时，性能数据被收集。这些数据可以依据期望的信息需求级别存储为概要描述或事件跟踪。插桩期间被插入的额外指令及关联的测量存储需要一些资源（内存以及CPU时间）。因此应用的执行会受到一定程度的影响。由额外测量指令产生的干扰很小，足以获取应用程序行为的精确视图。然而，某些应用属性，如极小时间内频繁执行的区域，将总是导致高的干扰。因此必须避免对这些区域的测量。应用执行之后可以分析测量数据。如果已经收集了详细的事件跟踪，可以研究不同进程产生的事件间更复杂的依赖，生成更详细的分析报告。特别是交互进程事件的相互关系通常只能通过事后检查分析进行。用于分析这些相互关系的信息通常分布在这些进程中。测量期间应用程序运行过程中的数据传输将引起严重干扰，为此将需要一些网络应用资源。收集的数据被分析后，结果需要表示在一个分析报告中，从而转入性能优化周期的下一阶段，称作表示阶段。在这一阶段，重要的是简化收集的性能数据的复杂性以便用户容易评估。如果呈现的数据太抽象，关键性能事件可能不能被用户识别，如果太详细，用户可能被淹没在大量数据中。因此为用户产生应用优化的指导是关键。评估阶段的结论是由表示的信息产生优化意向。用户对应用的优化策略建议在下一个优化阶段实现。然后，优化效能被另一个优化周期验证。当用户经过评估对应用的性能感到满意并且不需要进一步的优化时，可以摒弃插桩，未插桩应用的执行性能被接受。1.3 Scalasca概述Scalasca支持当前大多数HPC平台上的用C、C+和Fortran编写的MPI、OpenMP及混合MPI/OpenMP应用程序的测量和分析。主要通过具有适当选项的Scalasca命令来使用。图1.2给出了Scalasca支持的基本分析流程。图1.2 Scalasca性能分析工作流程在收集性能数据之前，目标应用程序需要被插桩。插桩的意思是修改代码以随时记录发生的与性能相关的事件。在多数系统上，这件工作可以使用编译支持自动完成。有些系统上提供人工和自动插桩的混合机制。当在并行机上执行插桩后的代码时，用户可以产生一个含有每个函数调用路径的聚合信息的汇总报表（也称作profile），此外，可以通过记录独立的运行时事件产生一个事件跟踪，之后可以由此产生一个profile或者时间序的可视化视图。运行时概括能力对获取性能行为概观及下一次的优化插桩都是非常有用的。由于跟踪事件往往是很大的，而且不恰当的插桩和测量配置将使结果分析打折，因此这一步被强烈推荐。当跟踪被激活，每个进程产生一个包含它的所有本地进程事件记录的跟踪文件。程序终止之后，Scalasca将跟踪文件重新装入内存，并且使用同应用程序运行时一样多的CPU数并行地分析它们。在分析时，Scalasca搜索指示等待状态的特征模式及相关的性能特性，按类别对找到的实例分类并量化它们的重要性，分析结果是一个与汇总报表结构类似的模式分析报表，但对高级通信和低效同步进行了浓缩。汇总和模式报表都含有每个函数调用路径的性能度量及可以在图形资源管理器中相互探究的系统资源（见图2.1中的例子）。自动分析的另一种选择是，转换跟踪事件并使用诸如Paraver和Vampir的第三方跟踪浏览器进行分析研究，以发挥它们强大的时间序可视化优势和丰富的统计功能。2 入门指南本章介绍Scalasca工具集在实例应用分析基础方面的使用。将指出最突出的特点并给出后面章节更深入的相关信息的参照。Scalasca的使用包括三个阶段：程序插桩、执行测量与分析、分析报告审查。Scalasca命令提供调用skin、scan和square等相关命令的选项。这些选项是：1. scalasca instrument用于插入Scalasca测量系统的调用到应用程序的代码中。有自动、半自动和连接预插桩库三种方式。2. scalasca analyze用于控制应用程序执行期间的测量环境，并在跟踪使能时自动执行测量完成后的跟踪分析。Scalasca测量系统支持运行时汇总和/或事件跟踪与分析，也可选择包括硬件计数器信息。3. scalasca examine用于处理测量产生的运行时汇总报表和/或分析研究跟踪事件。并启动Scalasca分析报告审查浏览器CUBE3。执行没有参数的scalasca命令，或执行scalasca h命令，可以打开Scalasca快速参考（如果存在相应的pdf阅读器），以获得简要的Scalasca的使用总结。以下三节给出这三个选项最核心的综述，以及在性能分析的相关步骤如何使用它们。2.4节展示了一个完整的工作流程例子。2.1 插桩为了使用Scalasca测量系统进行测量，用户应用程序需要被插桩，即在应用程序运行时的特定关键点（事件）必须插入专门的测量调用。有三种插桩方法：编译时插入的自动插桩方法（3.1节）、半自动“POMP”插桩方法（3.3节）、人工插桩方法（3.2节）。此外如果Scalasca已经配置，还可以使用PDTOOLKIT插桩器进行自动源代码插桩（3.4节）。对于单纯OpenMP或混合MPI/OpenMp应用，或者使用半自动“POMP”方法时，内部使用OPARI源代码插桩器。阅读作为Scalasca文档一部分的OPEN_ISSUES文件的OPARI节，来了解当前的限制及如何围绕它工作。包括：l 并行编译（即使用gmake -j）l 单一目录下的多应用编译l 资源分布在多个目录中的应用通过scalasca instrument命令，Scalasca插桩器处理用户必需的全部插桩、MPI及OpenMP函数。因此，构建应用的编译和连接命令应该具有“scalasca instrument”前缀（在Makefile中）。如，要对由2个源文件myprog1.f90 和 myprog2.f90产生的可执行应用myprog插桩，将下列组合编译和连接的命令mpif90 myprog1.f90 myprog2.f90 -o myprog替换为scalasca -instrument mpif90 myprog1.f90 myprog2.f90 -o myprog注意：插桩器必需和连接命令一起使用。虽然并不是所有的object文件都需要插桩，并且仅对包含MPI和/或OpenMP代码的源模块插桩往往已足够。如果使用Makefile，定义一个宏PREP是很方便的，它可以放在编译和连接命令的前面。MPICC = $(PREP) mpiccMPICXX = $(PREP) mpicxxMPIF90 = $(PREP) mpif90使用下面的命令可以很容易地产生一个程序的插桩版本。make PREP=scalasca -instrument缺省情况（命令行没有指定PREP）下，保持完全优化且没有插桩。尽管自动插桩通常很方便，但它可能导致太多或太破碎的测量，可以使用选择插桩或测量过滤（见3.4节和3.5节）。2.2 运行时测量收集与分析Scalasca测量收集与分析使用scalasca analyze命令，包括如下步骤：l 测量配置l 执行应用程序l 测量数据收集l 自动跟踪分析（如果已配置）要想对已插桩的可执行程序进行性能测量，目标应用程序的执行命令必须具有scalasca analyze命令前缀。scalasca -analyze options $MPIEXEC $MPI_FLAGS target args对于非MPI（单纯的OpenMP）应用，应忽略MPI运行命令及相关的选项。每次测量试验都使用一个唯一的目录，测量开始时该目录必须是不存在的，如果指定的目录存在则测量终止。每个EPIK测量档案目录的缺省名依据目标可执行应用的名字、运行配置（即指定的处理器数及OMP_NUM_THREADS）以及测量配置来创建。该档案目录名具有epik_前缀，其位置可以在Scalasca命令中使用-e 选项或通过改变配置变量来明确指定。测量完成后，测量档案目录中包含若干记录文件及一个或多个分析报告。缺省情况下，运行时摘要提供一个汇总报表，包括每个进程每个调用路径的时间开销和执行次数。对于MPI测量包括MPI时间、消息和文件I/O的统计。对于OpenMP测量，OpenMP专有的参数被计算。混合MPI/OpenMP包含两个参数集合。如果需要硬件计数器度量参数，还可以将其包括在汇总报表中。也可以收集事件跟踪数据作为测量的一部分，为每个进程产生一个EPI-LOG跟踪文件。为了收集跟踪事件数据作为测量的一部分，使用scalasca -analyze t命令（或者设置配置变量EPK_TRACE=1）。这样，在测量完成后会自动启动跟踪分析。需要注意的是，对于纯OpenMP代码，自动跟踪分析还不能提供一个像运行时摘要那样的更详细的等待状态分析。当然，你可能仍然希望收集跟踪以便在图形跟踪浏览器中进行可视化显示和研究。scalasca -analyze n预览模式可以用于显示（但不实际执行）测量和分析运行的命令，结合几个检查来测试成功的可能性。额外的说明信息（通过 v）可能也是有用的，特别是测量和分析不成功时。在出现问题但没有显式报告错误或警告时，执行插桩应用前设置配置变量EPK_VERBOSE=1，查看Scalasca测量系统的控制消息，帮助追踪问题所在或给Scalasca实现者更详细的问题报告（由于消息量可能很大，使用一个小的、适当短的执行配置）。当在机群环境中使用环境变量时，确保这些环境变量在机群的所有节点的所有应用进程具有相同的值。一些机群环境中，在远程节点上执行子作业时不会自动传输环境，可能需要在批作业提交脚本中明确设置和输出。2.3 分析报告审查自动分析的结果被存储成试验档案目录中的一个或多个报表。使用scalasca examine命令可以处理和审查这些报表。scalasca -examine epik_在运行CUBE3报表阅读器之前，已在第一时间完成了检查档案的后处理工作。对于已经处理过的试验档案、或者用CUBE文件作为参数执行scalasca examine命令，阅读器立即运行。可以不运行阅读器来获得一个短小的文本评价表。scalasca -examine -s epik_该评价表来自cube3_score实用程序，提供测量包括的不同区域的分类以及需要的跟踪缓冲区容量、跟踪记录的总体积（total_tbc）以及处理的最大跟踪记录的体积（max_tbc）的估算，这可用于为后续跟踪测量指定一个合适的ELG_BUFFER_SIZE。CUBE3同样能够用于一个试验档案或CUBE文件。cube3 epik_cube3 .cube但是要记住，这种情况没有执行后处理工作，因此仅是Scalasca分析的子集及参数的显示。2.3.1 CUBE3的使用下面是CUBE3用法的一个简短介绍。为更有效地使用GUI，你还应该阅读随Scalasca发布提供的CUBE3手册。CUBE3是一个通用用户接口，它显示和浏览并行应用的性能和调试信息。先进的数据模型独立于显示的详细的性能属性。CUBE3主窗口由3个包含树形显示或交替式分析报表图形视图的画板构成。左侧的画板执行程序的性能属性，中间画板显示应用的调用树或相应的profile，右侧的树显示构成机器的系统层级、计算节点、进程、线程和应用的进程或线程的拓扑视图。所有的树节点用参数值和颜色框标识以帮助识别热点。参数值的颜色取决于占总值（root）或指定的其它参考值的比例。在性能属性或者调用路径上单击选择相应节点。这将产生如下影响：该节点拥有的参数值（如执行时间）将被细分为它的更小的成分。就是说，选择一个性能属性后，中间画板显示整个调用树的分布。选择一个调用路径（调用树中的一个节点）后，系统树显示整个本地系统的调用树的性能属性的分布。单击树节点左边的图标展开或收缩该节点。通过展开或收缩树中的节点，可以以不同的粒度级观察分析结果。为了获取性能属性的准确定义，按鼠标右键，选择与性能属性关联的上下文菜单中的Online Description，从Info菜单项可以得到简要描述。更多的信息还可以从下列网站得到：/CUBE3还提供了一些操作分析报表的命令行代数工具（这些工具目前仅能在试验档案目录中的CUBE文件上工作）。可以使用cube3_mean 或cube3_merge平均或合并多个分析报告。使用cube3_diff计算两个分析报告间的差异。使用cube3_cut可以修剪指定的调用树或/和指定一个新的调用树根（root）节点，而产生一个新的分析报表。这对后面消除不感兴趣的段（如初始化）和重点关注选中的可执行程序部分的分析可能特别有用。这些工具中的每一个都产生一个新的CUBE格式的报表作为输出。cube3_score工具可被用于根据汇总或跟踪分析报表来估算跟踪缓冲区的需求。如果物理内存充足，可以将其指定为配置变量ELG_BUFFER_SIZE的值用于后续的跟踪收集。cube3_score r可以检查输出详细的区域，以识别影响测量的频繁执行的区域及分析部分没有被考虑的值。如没有OpenMP及MPI操作的区域通过选择插桩和测量（见3.4节和3.5节）从后续试验中排除可能是合适的。从测量中消除某些函数可以节省跟踪缓冲容量，这可通过提供一个过滤器文件来实现，该文件列出了被排除的函数的函数名。使用-f 选项可以评估可能的过滤器文件。2.4 一个完整的工作流程例子前面的章节介绍了Scalasca的一般用法。本节将通过SOR（solver kernel）实例分析指导使用红黑相间的over-relaxation方法解算泊松方程。下述试验使用的环境是IBM Blue Gene/P，给出的命令和输出可能与你的系统不同。缺省的，Scalasca使用基于编译器的自动插桩特征。当你缺少对应用的详细了解并且需要识别代码的热点时，这通常是最好的首选。SOR仅由一个源文件构成，它可以使用下面2条命令编译和连接。scalasca -instrument mpixlc -c sor.cscalasca -instrument mpixlc sor.o -o sor.x现在，必须在系统中执行插过桩的二进制文件。在超级计算系统中，用户通常必须提交他们的作业到批处理系统，并且不允许直接运行并行作业。因此，必须在一个批处理脚本中提供对Scalasca命令的调用，当请求的资源有效时它将被调度执行。不同调度系统中批处理脚本的语法是不同的。但是任何批处理脚本的公共部分是一个段，在这里可以放置所有将被执行的shell命令。这里，Scalasca分析器的调用必须放置在应用执行命令之前。scalasca -analyze mpirun -mode vn -np 128 ./sor.x当批处理脚本被执行时要确保Scalasca命令是可访问的，如需要的话，可修改PATH。在Blue Gene系统上参数-mode和-np是mpirun的选项，其他的运行器将有不同的选项和语法。Scalasca分析器管理几个帮助应用测量的控制变量，Scalasca分析器的缺省行为是创建一个汇总文件，而不是创建详细的事件跟踪，由来自EPIK测量系统的初始化消息指示。S=C=A=N: Scalasca 1.3 runtime summarizationS=C=A=N: ./epik_sor_vn128_sum experiment archiveS=C=A=N: Collect startmpirun -mode vn -np 128 ./sor.x00000EPIK: Created new measurement archive ./epik_sor_vn128_sum00000EPIK: Activated ./epik_sor_vn128_sum NO TRACE. Application output .00000EPIK: Closing experiment ./epik_sor_vn128_sum.00000EPIK: Closed experiment ./epik_sor_vn128_sumS=C=A=N: Collect doneS=C=A=N: ./epik_sor_vn128_sum complete.作业成功执行之后，在一个新的目录中创建一个汇总报表。本例中，自动产生的测量目录名是epik_sor_vn128_sum，指示在Blue Gene上以虚拟节点模式(-mode vn)用128(-np 128)个进程执行作业，后缀_sum指运行时摘要试验。汇总分析报表可以被后期处理并使用Scalasca报表浏览器审查分析。scalasca -examine epik_sor_vn128_sumINFO: Post-processing runtime summarization report .INFO: Displaying ./epik_sor_vn128_sum/summary.cube .图2.1给出了Scalasca报表浏览器CUBE3的屏幕截图，打开的是SOR的汇总分析报表。应用程序性能汇总的检查可能显示若干应用程序行为测量方面的影响。如频繁执行的短函数可能导致重大的干扰，应该禁止跟踪：它们需要在下一步使用跟踪分析进行研究之前被排除，并引起重视。图2.1 用CUBE观察运行时汇总在跟踪收集的时候，应用程序执行行为的相关信息被记录，写入事件流。事件流中事件的数量决定了在内存中保存流所需要的缓冲区大小。为了减少需要的内存量、缩短刷新事件缓冲到磁盘的时间，应该只监视最相关的函数。应用程序运行期间，当整个事件流大于内存缓冲区时，必须将它们刷新到磁盘。刷新影响应用程序的性能，因为不同进程间刷新并不协调，而且运行时的不均衡会影响测量。Scalasca测量系统使用一个每进程或线程10MB的缺省值用于事件跟踪，当该值不合适时可以调整以减少或消除内部缓冲的刷新。当然，如果为缓冲区指定的值太大，应用程序可能因运行内存不足而无法装入，或者以磁盘分页的方式运行。大的跟踪还需要大量的磁盘空间（至少是临时的，直到分析完成），并且读写磁盘会相对变慢。减少跟踪的体积（如，指定更短的执行程序、有选择地插桩和测量）通常更合理，然后才是增加缓冲区大小。为了估算跟踪测量的缓冲需求，scalasca -examine s将产生一个需要的最大字节数估计值的简短汇总。scalasca -examine -s epik_sor_vn128_sumcube3_score epik_sor_vn128_sum/summary.cubeReading ./epik_sor_vn128_sum/summary.cube. done.Estimated aggregate size of event trace (total_tbc): 25698304 bytesEstimated size of largest process trace (max_tbc): 215168 bytes(When tracing set ELG_BUFFER_SIZE max_tbc to avoid intermediate flushesor reduce requirements using a file listing USR regions to be filtered.)flt type max_tbc time % regionANY 215168 11849.04 100.00 (summary) ALLMPI 195728 147.47 1.24 (summary) MPICOM 9696 465.93 3.93 (summary) COMUSR 9744 11235.64 94.82 (summary) USR表的第一行（ALL）给出了执行的所有函数的汇总信息。列max_tbc是为每个进程确定的以字节为单位的跟踪缓冲区需求总量。如果max_tbc超过了内存中事件流的有效缓冲区大小，在测量期间将引发中间刷新。为了防止刷新，可以增加缓冲区的大小，或者从测量中剔除一些特定函数。为辅助建立合适的过滤器文件，“评分”功能提供了不同类型的划分，这取决于每个调用路径的区域类型。MPI类型是对MPI库的函数调用；OMP类型是OpenMP区域或对OpenMP API的调用；直接或间接调用MPI或OpenMP的路径上的用户程序例程对理解并行程序的通信和同步行为能够提供重要的上下文信息，标记为COM类型；其它纯本地计算的例程标记为USR类型。对过滤来说，具有USR类型的例程通常是最佳候选，过滤将有效地使它们对测量和分析不可见。COM类型的例程也可以被过滤，尽管这通常是不合适的，因为这样会消除上下文信息。而MPI和OpenMP区域是Scalasca分析需要的，它们不能被过滤。通过比较跟踪缓冲区需求和特定组例程上的时间开销，初始评分报表将会显示出过滤会带来什么样的预期好处。当然，为了实际设置过滤器，还需要更详细的考察。这可直接在已经进行了后处理的汇总报表上使用带命令行选项-r的cube3_score命令来完成。cube3_score -r epik_sor_vn128_sum/summary.cubeReading summary.cube. done.Estimated aggregate size of event trace (total_tbc): 25698304 bytesEstimated size of largest process trace (max_tbc): 215168 bytes(When tracing set ELG_BUFFER_SIZE max_tbc to avoid intermediate flushesor reduce requirements using a file listing USR regions to be filtered.)flt type max_tbc time % regionANY 215168 11849.04 100.00 (summary) ALLMPI 195728 147.47 1.24 (summary) MPICOM 9696 465.93 3.93 (summary) COMUSR 9744 11235.64 94.82 (summary) USRMPI 80000 2.14 0.02 MPI_IrsendMPI 73600 1.07 0.01 MPI_IrecvMPI 16040 20.77 0.18 MPI_AllreduceMPI 16000 14.32 0.12 MPI_BarrierMPI 9600 87.25 0.74 MPI_WaitallCOM 9600 304.28 2.57 get_haloUSR 4800 5432.60 45.85 update_redUSR 4800 5432.87 45.85 update_blackMPI 240 0.54 0.00 MPI_GatherMPI 200 3.63 0.03 MPI_BcastUSR 48 368.66 3.11 TRACINGUSR 48 0.50 0.00 looplimitsMPI 24 0.52 0.00 MPI_FinalizeUSR 24 0.54 0.00 init_boundaryUSR 24 0.48 0.00 init_red_blackCOM 24 2.88 0.02 sor_iterCOM 24 156.25 1.32 init_fieldCOM 24 0.82 0.01 setup_gridMPI 24 17.23 0.15 MPI_InitCOM 24 1.70 0.01 main（执行命令scalasca -examine s可以报告该命令的基本格式。）因为SOR实例在单个进程上所需的最大缓冲区215KB是合适的，这种情况不需要过滤。说明：过滤不会防止被插桩的函数。因此，当使用基于编译器的自动插桩时，被过滤掉的函数上的测量开销通常可能不会被完全消除。一旦确定了缓冲区大小和/或过滤器的配置，在后续测量中要确保通过环境变量或工作目录下的测量配置文件EPIK.CONF指定它们。过滤器文件还可以在scalasca analyze命令中使用-f filter_file来指定。在开始跟踪测量试验之前，要确保建立试验的文件系统适合于并行I/O（典型地，如/scratch、/work、或/home），并且对期望的跟踪有足够的磁盘容量。当按照测量开销和空间需求最小化原则对Scalasca测量系统的所有选项设置后，可以向scalasca analyze命令传递-t选项，来执行被插桩应用的一次新的运行，这将激活Scalasca测量系统的跟踪模式，并在应用结束后自动启动搜索低效通信行为模式的并行后处理分析器。scalasca -analyze -t mpirun -mode vn -np 128 ./sor.xS=C=A=N: Scalasca 1.3 trace collection and analysisS=C=A=N: ./epik_sor_vn128_trace experiment archiveS=C=A=N: Collect startmpirun -mode vn -np 128 ./sor.x00000EPIK: Created new measurement archive ./epik_sor_vn128_trace00000EPIK: Activated ./epik_sor_vn128_trace 10000000 bytes. Application output .00000EPIK: Closing experiment ./epik_sor_vn128_trace00000EPIK: Flushed file ./epik_sor_vn128_trace/ELG/00000.00013EPIK: Flushed file ./epik_sor_vn128_trace/ELG/0001300000EPIK: Closed experiment ./epik_sor_vn128_traceS=C=A=N: Collect doneS=C=A=N: Analysis startmpirun -mode vn -np 128 scout.mpi ./epik_sor_vn128_trace. SCOUT output .S=C=A=N: Analysis doneS=C=A=N: ./epik_sor_vn128_trace complete.这将创建一个试验档案目录epik_sor_vn128_trace，通过后缀_trace与之前的汇总试验相区分。测量关闭时每个MPI rank的一个独立跟踪文件被直接写入子目录中，并自动启动并行跟踪分析器SOUT分析这些跟踪文件，产生一个分析报表，可以使用同汇总试验相同的命令和工具来审查该分析报表。scalasca -examine epik_sor_vn128_traceINFO: Post-processing trace analysis report .INFO: Displaying ./epik_sor_vn128_trace/trace.cube .图2.2 用CUBE3确定一个迟到发送者图2.2给出了一幅屏幕截图，分析结果提供的信息乍看与汇总分析结果相同，但是，跟踪分析报表浓缩了额外的度量参数，这些度量参数揭露为汇总性征的子参数，如由于发送者迟到，早到的接收不得不等待发送启动而潜在地耗费的点到点通信时间部分。因此，跟踪分析可以揭示低效执行行为的细节。EPILOG事件跟踪与分析的文件系统需求比运行时汇总更高。由于测量结束时的额外文件I/O和分析，使得批作业的运行时间也相应增加。成功跟踪之后，Scalasca测量已经创建了一个包含事件跟踪和它的分析文件的目录。在跟踪模式，Scalasca的缺省行为是创建一个运行时汇总报表（存储为summary.cube）及跟踪分析报表（存储为trace.cube）。在跟踪分析成功之后，删除试验档案之前，可以通过删除试验档案目录中的ELG子目录来删除跟踪文件。3. 应用插桩Scalasca提供了几种可能方法为用户的应用代码插桩。除基于编译器的自动插桩（3.1节）外，还提供了使用EPIK API的人工插桩（3.2节）、使用POMP指示的半自动插桩（3.3节）及使用基于PDToolkit插桩器的自动源代码插桩（3.4节，如果配置）。此外，如果使用基于编译器的自动插桩，Scalasca提供了一种从测量中排除已插桩的用户例程的过滤能力（3.5节）。象用户例程和指定的源代码区域一样，Scalasaca目前支持下列事件类型：l MPI库调用插桩操作通过使用标准MPI描述接口 PMPI来完成。为了启用它，应用程序必须连接EPIK API（或混合的）测量库及MPI专用库。注意，EPIK库必须在MPI库之前被连接以确保插入的有效性。l OpenMP指示与API调用Scalasca测量系统使用OPARI工具为OpenMP结构插桩。如何对OpenMP源代码插桩，参见OPARI文档。此外，应用程序必须连接OpenMP（或混合的）测量库。Scalasca插桩器命令scalasca instrument自动地使用正确的前缀编译和连接命令，产生一个被插桩的可执行程序。通常，仅需在Makefile中为$(CC)或$(MPICC)（或与之等价的）定义前缀。使用编译器进行预处理时，前缀命令不是必须的，因为此时不进行插桩。在没有Scalasca插桩器的情况下编译时，kconfig命令可被用于简单地确定合适的连接操作和库：kconfig -mpi|-omp|-hybrid -for -user -32|-64 -libs-mpi,、-omp或hybrid选项用于选择期望MPI、OpenMP或混合MPI/OpenMP测量支持。在缺省情况下，kconfig假定正在被连接的是C或C+程序，Fortran应用必须用-for选项显式地指明。指定-user选项可使EPIK手动用户插桩API有效。如果需要，可用-32或-64选项选择32位或64位测量版本库。注意：Scalasca的个例安装可能没有提供全部的测量配置。kconfig命令还可以用于确定正确的编译选项以指定epik_user.h或 epik_user.inc头文件的包含目录。kconfig -for -cflags或者，使用户插桩宏有效：kconfig -for -user -cflagsScalasca支持多种插桩类型用于用户级源代码例程和任意区域，除全自动MPI及OpenMP插桩外，汇总在下表中：TypeSwitchDefaultStandardinstrumdroutinesOtherinstrumdregionsRuntimemeasmentcontrolMPI(auto) configured by install(Sec. 4.2.2)OpenMP(auto)(Sec. 3.5)all parallelconstructsCompiler(Sec. 3.1)-compallall ornonenotsupported(Sec. 4.2.1)PDToolkit(Sec. 3.4)-pdtall, orselectivenotsupportedPOMP(Sec. 3.3)-pompmanually annotatedmanuallyannotatedEPIK API(Sec. 3.2)-usermanuallyannotatedmanuallyannotated表3.1 Scalasca插桩器选项综述 当插桩器确定使用了MPI或OpenMP时，它自动分别使MPI库插桩和基于OPARI的OpenMp插桩有效。被插桩的MPI库函数的缺省集在安装Scalasca时指定。所有OpenMP并行结构和API调用被缺省插桩，但是，OpenMP同步调用类的插桩可以选择性地屏蔽，在3.5节有相应描述。缺省情况下，自动由编译器对用户级源代码例程进行插桩（等价于-comp=all）。需要时，可以使用-comp=none来屏蔽，如使用PDToolkit、POMP、EPIK用户API手动源代码插桩、分别使用-pdt、-pomp及-user选项时。编译器、PDToolkit、POMP、EPIK用户API手动源代码插桩可以同时使用或任意组合。然而，通常期望的是避免重复插桩（如果所有这些操作都用于对同一个例程插桩结果会怎样）。3.1 自动编译器插桩目前大多数编译器都支持位于例程入口和出口的插桩调用的自动插入，Scalasca可以利用这种能力来确定哪些例程被包含在插桩测量中。Scalasca缺省情况或使用-comp=all显式请求，均可启用对指定源文件中所有例程的编译器插桩。使用-comp=none可以屏蔽编译器插桩。取决于编译器及它如何实现插桩，插桩的插入可能失去内联能力和其他重要优化，或者内联例程可能根本不被插桩（因此是不可见的）。基于编译器的自动插桩已经在几个编译器上进行了测试。 GCC (UNIX-like operating systems, not tested with Windows) IBM xlc, xlC (version 7 or later, IBM Blue Gene and AIX) IBM xlf (version 9.1 or later, IBM Blue Gene and AIX) PGI (Cray XT and Linux) Intel compilers (version 10 or later, Cray XT and Linux, not tested withWindows) SUN Studio compilers (Linux and Solaris, Fortran only) PathScale compilers (Cray XT and SiCortex) CCE/Cray compiler (Cray XT) NEC compiler (NEC SX)任何情况下，Scalasca支持C、C+及Fortran代码的自动插桩。但SUN Studio编译器是个例外，在它的Fortran编译器上仅提供适当的支持。说明：自动编译器插桩可能在短函数调用上产生一个不容忽视的测量开销。这可能影响测量期间应用的整体性能。C+应用尤其容易受到这种影响，取决于应用的设计和C+ STL函数是否也被编译器插桩。目前，使用自动编译器插桩在所有平台上避免特定函数的插桩是不可能的。如果你遇到巨大的开销，参见3.5节，了解如何手动对应用插桩。对插桩例程的命名取决于编译器，它可能对Fortran和C+例程名增加下划线或其他修饰，并且在Scalasca安装时是否已激活“demangling”名字及能被成功应用。3.2 手动区域插桩如果基于编译器的自动插桩（见2.1节) 或半自动插桩（见3.3节) 过程失败，可以使用手动插桩。手动插桩还可用于扩展自动插桩区域或程序段来改善分析报表的结构。通常，主程序例程应该被插桩，以在分析中测量和包含完整的执行程序。可以根据使用的程序设计语言，按照下列方法完成插桩。Fortran:#include epik_user.incsubroutine foo(.)!declarationsEPIK_FUNC_REG(foo)EPIK_USER_REG(r_name,iteration loop)EPIK_FUNC_START().EPIK_USER_START(r_name)do i= 1, 100.end doEPIK_USER_END(r_name).EPIK_FUNC_END()end subroutine fooC/C+:#include epik_user.hvoid foo(.)/* declarations */EPIK_USER_REG(r_name,iteration loop);EPIK_FUNC_START();.E