问题标签 [intel-vtune]

Is there a way to run same test(for example Lightweight Hotspots) multiple times in Intel VTune Amplifier XE ??? It is annoying to do multiple clicks to perform a single test. I have looked though documentation, but found nothing.
Thanks !

我已经用不同的优化标志编译了 fortran 程序。我有一个带有默认优化标志 -O2 的程序和另一个带有 -fast 优化标志的编译程序。我能够打开使用优化标志 -O2 编译的程序。那么，当我们尝试在 Vtune 中加载程序时，程序也会执行吗？

但是，当我尝试加载使用优化标志 -fast 编译的程序时，Vtune 会抛出错误“无法最终确定结果”。您打开的结果是空的。这可能是由数据收集过程中的错误引起的。这实际上意味着什么？我浏览了这个论坛的其他帖子，但不太明白这是什么意思。

我得到的收集器消息如下：

错误：分析目标的二进制文件不包含分析所需的符号。有关更多详细信息，请参阅文档。错误：在分析目标的静态二进制文件中找不到有效的 dlopen 符号。

我使用的是 ubuntu 12.04 系统。

非常感谢。请尽快回复。

贾巴巴

我正在使用一个爱好程序来自学高性能计算技术。

我的 PC 有一个 Intel Ivy Bridge Core i7 3770 处理器和 32 GB 内存和 Microsoft vs2010 C 编译器的免费版本。

64 位程序需要大约 20 GB 的内存，因为它有五个 4 GB 的查找表（下面的 bytevecM ... bytevecX）。这个搜索程序的内部循环被写成一个单独的 C 文件（因为我以后可能想用汇编版本替换它），如下所示：

顺便说一下，通过在每个线程中以不同的开始和结束范围运行一个副本，上述算法很容易并行化。

使用直觉、英特尔内在函数并单独对每个更改进行基准测试，我能够将运行时间从大约 5 小时减少到 3 小时，如下所示：

这种加速大部分来自内部循环的手动展开。

由于我对英特尔 SSE/AVX 指令非常陌生，如果您刚刚看到上面的内容让您脸红，请告诉我。

Intel VTune 报告最大的热点出现在线路上：

在对应的汇编代码中，热点如下图所示：

这对我来说似乎是一个“数据局部性”问题。每次通过内部循环时，m7 的值在 4 GB 范围内变化很大且不可预测，因此在查找 qqm=bytevecM[m7^1] 时，您可能会遇到第一个 UNROLL(1) 的缓存未命中。

由于随后的 UNROLL(2)..UNROLL(127) xor m7 与 2..127，您通常会在其余的 UNROLL 中获得缓存命中。奇怪的是，通过将 UNROLL(96) 移到 UNROLL(1) 之后来更改 UNROLL 的顺序，可以显着加快速度。

我知道从内存中读取一个字节会导致填充包含该字节的（64 字节）缓存行。

由于我对这个领域非常陌生，我欢迎任何关于如何加快内存查找的建议或良好参考，尤其是在处理大型表时（在我的例子中，4 GB 表）。

我看不到使用上述算法改善数据局部性的明显方法；也欢迎就如何实现这一目标提出建议。

2013 年 3 月 29 日更新

自从编写了这个节点以来，我已经能够将运行时间从 3 小时进一步减少到 20 分钟，如下所示。

为每个 4 GB bytevec 添加一个 4 MB 位图将其减少到大约 40 分钟，通过添加一些 _mm_prefetch 调用进一步减半。

请注意，基本算法保持不变：通过添加位图改善了数据局部性；通过添加 _mm_prefetch 调用减少了延迟。

欢迎提出进一步性能改进的建议。改进后的程序如下：

继续我的第一个问题，我正在尝试优化通过 VTune 分析 64 位 C 程序发现的内存热点。

特别是，我想找到最快的方法来测试一个 128 字节的内存块是否包含全零。您可以为内存块假设任何所需的内存对齐；我使用了 64 字节对齐。

我正在使用带有 Intel Ivy Bridge Core i7 3770 处理器、32 GB 内存和 Microsoft vs2010 C 编译器的免费版本的 PC。

我的第一次尝试是：

对应程序集的 VTune 分析如下：

我能够通过 Intel instrinsics 对此进行改进：

对应程序集的 VTune 分析如下：

如您所见，汇编指令较少，并且此版本进一步证明在时序测试中更快。

由于我在英特尔 SSE/AVX 指令领域相当薄弱，我欢迎就如何更好地使用它们来加速此代码提出建议。

虽然我搜索了数百种可用的内在因素，但我可能错过了理想的那些。特别是，我无法有效地使用 _mm_cmpeq_epi64(); 我寻找了这个内在的“不相等”版本（这似乎更适合这个问题），但没有找到。虽然下面的代码“有效”：

它是不可读的，并且（不出所料）被证明比上面给出的两个版本要慢得多。我确信必须有一种更优雅的方式来使用 _mm_cmpeq_epi64() 并欢迎就如何实现这一点提出建议。

除了使用 C 中的内部函数外，还欢迎针对此问题的原始英特尔汇编语言解决方案。

我想优化我在 linux 平台上用 c++ 编写的代码。为此，我正在使用 Intel VTune Performance Analyzer Profiler。当我识别热点时，它成功运行了我指定路径的二进制可执行文件，然后它给出了错误： “数据无法显示，没有可用于数据的视点”。

任何人都可以帮助解决这个错误。

继我之前的两个问题之后，如何提高 64 位 C/intel 汇编程序的内存性能/数据局部性和使用 C/Intel 汇编，测试 128 字节内存块是否包含全零的最快方法是什么？，我进一步将这些问题中提到的测试程序的运行时间从 150 秒降低到了 62 秒，如下所述。

64 位程序有五个 4 GB 查找表（bytevecM、bytevecD、bytevecC、bytevecL、bytevecX）。为了减少（大量）缓存未命中的数量，在我上一个问题中分析过，我添加了五个 4 MB 位图，每个查找表一个。

这是原始的内部循环：

这个简单的“预检查”背后的想法是，如果所有 128 个字节都为零，则避免代价高昂的内部循环。然而，正如上次所讨论的，分析表明，由于大量缓存未命中，这种预检查是主要瓶颈。所以我创建了一个 4 MB 的位图来进行预检查。（顺便说一句，大约 36% 的 128 字节块是零，而不是我上次错误报告的 98%）。

这是我用来从 4 GB 查找表创建 4 MB 位图的代码：

欢迎提出更好的方法来做到这一点。

使用通过上述函数创建的位图，然后我将“预检查”更改为使用 4 MB 位图，而不是 4 GB 查找表，如下所示：

这是“成功的”，因为在简单的单线程情况下，运行时间从 150 秒减少到 62 秒。但是，VTune 仍然会报告一些相当大的数字，如下所示。

我分析了一个更现实的测试，其中八个同时运行的线程在不同的范围内运行。内部循环检查零块的 VTune 输出如下所示：

除此之外，大量时间（令我困惑）归因于这条线：

我不完全理解上面 VTune 输出中的大数字。如果有人能更清楚地了解这些数字，我会全力以赴。

在我看来，我的 5 个 4 MB 位图比我的 Core i7 3770 处理器的 8 MB L3 缓存要大，导致许多缓存未命中（尽管比以前少得多）。如果我的 CPU 有 30 MB L3 缓存（正如即将推出的 Ivy Bridge-E 一样），我推测这个程序会运行得更快，因为所有五个位图都可以轻松放入 L3 缓存中。那正确吗？

此外，由于测试位图的代码，即：

现在在内循环中出现了五次，非常欢迎任何关于加速此代码的建议。

我想使用 Vtune Profiler API 来分析在 Xeon Phi（Linux，使用卸载执行）上运行的代码，以查看执行的指令数、L1 缓存未命中数等。但我找不到任何解释如何使用的地方这个图书馆。

在 Linux 中哪里可以找到库文件和包含文件？如何编写代码来分析在 Xeon Phi 上运行的短代码？

我会期待这样的事情：

谢谢

我正在使用 Intel Vtune Amplifier XE 2013 来分析在多核 CPU 上运行的并行程序，特别是它是用 OpenCL 编写并在 Xeon Phi 中执行的。我想知道Vtune带来的结果应该如何准确解释，即

1. 是单线程还是整个核心收集的性能计数器的值？（假设一个 CPU 中有许多内核，并且许多线程可以在一个内核上同时执行，例如 Xeon Phi）。
2. Vtune 如何在多核 CPU 上采样？它是在单个核心上采样并报告它，还是在多个核心上采样并取平均值？

我正在为我的 linux 应用程序热点收集使用 Intel(R) VTune(TM) Amplifier XE 2013 Update 5 (build 274450)，但报告说“[在任何已知模块之外]”消耗大部分时间，所以我想获取有关未知模块的更多信息。

当我阅读 vtune Amplifier 的发行说明时，它说“热点列表可能包含”在内核早于 2.6.20 (200233501) 的系统上的“任何已知模块之外””，但我的 linux 内核是“2.6.32”，有什么想法吗？

我正在尝试优化此代码。

英特尔 VTune 显示大约一半的处理器时间花在第二for 条指令上，而不是循环内的 2 行 。当我展开汇编源代码时，我可以看到c++ 指令已被翻译成许多操作码，其中 3 个似乎正在吞噬 CPU 时间：for for

我不明白一个简单的移动和比较怎么会那么耗时。