scalasca13用户手册--中文

scalasca13用户手册--中文内容摘要：

Scalasca分析器管理几个帮助应用测量的控制变量， Scalasca分析器的缺省行为是创建一个汇总文件，而不是创建详细的事件跟踪，由来自 EPIK测量系统的初始化消息指示。 S=C=A=N: Scalasca runtime summarization S=C=A=N: ./epik_sor_vn128_sum experiment archive S=C=A=N: Collect start mpirun mode vn np 128 ./ [00000]EPIK: Created new measurement archive ./epik_sor_vn128_sum [00000]EPIK: Activated ./epik_sor_vn128_sum [NO TRACE] [... Application output ...] [00000]EPIK: Closing experiment ./epik_sor_vn128_sum ... [00000]EPIK: Closed experiment ./epik_sor_vn128_sum S=C=A=N: Collect done S=C=A=N: ./epik_sor_vn128_sum plete. 作业成功执行之后，在一个新的目录中创建一个汇总报表。 本例中，自动产生的测量目录名是epik_sor_vn128_sum，指示在 Blue Gene上以虚拟节点模式 (mode vn)用 128(np 128)个进程执行作业 ，后缀 _sum指运行时摘要试验。 汇总分析报表可以 被后期处理并使用 Scalasca报表浏览器审查分析。 scalasca examine epik_sor_vn128_sum INFO: Postprocessing runtime summarization report ... INFO: Displaying ./epik_sor_vn128_sum/ ... 图 给出了 Scalasca 报表浏览器 CUBE3 的屏幕截图，打开的是 SOR 的汇总分析报表。 应用程序性能汇总的检查 可能显示若干应用程序行为测量方面的影响。 如频繁执行的短函数可能导致重8 大的干扰，应该禁止跟踪：它们 需要 在下一步使用跟踪分析 进行 研究之前被排除 ，并引起重视。 图 用 CUBE观察运行时汇总 在跟踪收集的时候，应用程序执行行为的相关信息被记录，写入事件流。 事件流中事件的数量决定了在内存中保存 流所需要的缓冲区大小。 为了减少需要的内存量、缩短刷新事件缓冲到磁盘的时间，应该只监视最相关的函数。 应用程序运行期间，当整个事件流大于内存缓冲区时，必须将它们刷新到磁盘。 刷新影响应用程序的性能，因为不同进程间刷新并不协调，而且运行时的不均衡会影响测量。 Scalasca 测量系统使用一个每进程或线程 10MB 的缺省值用于事件跟踪，当该值不合适时可以调整以减少或消除内部缓冲的刷新。 当然，如果为缓冲区指定的值太大，应用程序可能因运行内存不足而无法装入，或者以磁盘分页的方式运行。 大的跟踪还需要大量的磁盘空间（至少是临时 的，直到分析完成），并且读写磁盘会相对变慢。 减少跟踪的体积（如，指定更短的执行程序、有选择地插桩和测量）通常更合理，然后才是增加缓冲区大小。 为了估算跟踪测量的缓冲需求， scalasca examine –s将产生一个需要的最大字节数估计值的简短汇总。 scalasca examine s epik_sor_vn128_sum [cube3_score epik_sor_vn128_sum/] Reading ./epik_sor_vn128_sum/... done. Estimated aggregate size of event trace (total_tbc): 25698304 bytes Estimated size of largest process trace (max_tbc): 215168 bytes (When tracing set ELG_BUFFER_SIZE max_tbc to avoid intermediate flushes or reduce requirements using a file listing USR regions to be filtered.) flt type max_tbc time % region ANY 215168 (summary) ALL 9 MPI 195728 (summary) MPI COM 9696 (summary) COM USR 9744 (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/ Reading ... done. Estimated aggregate size of event trace (total_tbc): 25698304 bytes Estimated size of largest process trace (max_tbc): 215168 bytes (When tracing set ELG_BUFFER_SIZE max_tbc to avoid intermediate flushes or reduce requirements using a file listing USR regions to be filtered.) flt type max_tbc time % region ANY 215168 (summary) ALL MPI 195728 (summary) MPI COM 9696 (summary) COM USR 9744 (summary) USR MPI 80000 MPI_Irsend MPI 73600 MPI_Irecv MPI 16040 MPI_Allreduce MPI 16000 MPI_Barrier MPI 9600 MPI_Waitall COM 9600 get_halo USR 4800 update_red USR 4800 update_black MPI 240 MPI_Gather MPI 200 MPI_Bcast USR 48 TRACING USR 48 looplimits MPI 24 MPI_Finalize USR 24 init_boundary 10 USR 24 init_red_black COM 24 sor_iter COM 24 init_field COM 24 setup_grid MPI 24 MPI_Init COM 24 main （执行命令 scalasca examine –s可以报告该命令的基本格式。 ） 因为 SOR实例在单个进程上所需的最大缓冲区 215KB是合适的，这种情况不需要过滤。 说明： 过滤不会防止 被插桩的函数。 因此，当使用基于编译器的自动插桩时，被过滤掉的函数上的测量开销通常可能不会被完全消除。 一旦确定了缓冲区大小和 /或过滤器的配置，在后续测量中 要确保 通过环境变量或工作目录下的测量配置文件 它们。 过滤器文件还可以在 scalasca –analyze命令中使用 f filter_file来指定。 在开始跟踪测量试验之前，要确保建立试验的文件系统适合于并行 I/O（典型地，如 /scratch、/work、或 /home），并且对期望的跟踪有足够的磁盘容量。 当按照测量开销和空间需求最小 化原则 对 Scalasca测量系统的所有选项设置后，可以向 scalasca –analyze命令传递 t选项，来执行被插桩应用的一次新的运行，这将激活 Scalasca测量系统的跟踪模式，并在应用结束后自动启动搜索低效通信行为模式的并行后处理分析器。 scalasca analyze t mpirun mode vn np 128 ./ S=C=A=N: Scalasca trace collection and analysis S=C=A=N: ./epik_sor_vn128_trace experiment archive S=C=A=N: Collect start mpirun mode vn np 128 ./ [00000]EPIK: Created new measurement archive ./epik_sor_vn128_trace [00000]EPIK: Activated ./epik_sor_vn128_trace [10000000 bytes] [... Application output ...] [00000]EPIK: Closing experiment ./epik_sor_vn128_trace [00000]EPIK: Flushed file ./epik_sor_vn128_trace/ELG/00000 ... [00013]EPIK: Flushed file ./epik_sor_vn128_trace/ELG/00013 [00000]EPIK: Closed experiment ./epik_sor_vn128_trace S=C=A=N: Collect done S=C=A=N: Analysis start mpirun mode vn np 128 ./epik_sor_vn128_trace [... SCOUT output ...] S=C=A=N: Analysis done S=C=A=N: ./epik_sor_vn128_trace plete. 11 这将创建一个试验档 案目录 epik_sor_vn128_trace，通过后缀 _trace 与之前的汇总试验 相 区分。 测量关闭时每个 MPI rank 的一个独立跟踪文件被直接写入子目录中，并自动启动并行跟踪分析器SOUT 分析这些跟踪文件，产生一个分析报表 ，可以使用同汇总试验相同的命令和工具来审查该分析报表。 scalasca examine epik_sor_vn128_trace INFO: Postprocessing trace analysis report ... INFO: Displaying ./epik_sor_vn128_trace/ ... 图 用 CUBE3确定一个迟到发送者 图 给出了一幅屏幕截图，分析结果提供的信息乍看与汇总分析结果相同，但是，跟踪分析报表浓缩了额外的 度量 参数，这些 度量参数 揭露为汇总性征的子参数，如由于发送者迟到，早到的接收不得不等待发送启动而潜在地耗费的点到点通信时间部分。 因此，跟踪分析可以揭示低效执行行为的细节。 EPILOG 事件跟踪与分析的文件系统需求比运行时汇总更高。 由于测量结束时的额外文件 I/O和分析，使得批作业的运行时间也相应增加。 成功跟踪之。