问题标签 [intel-vtune]

我正在使用 Intel Vtune 进行一些分析：内存访问、访问争用等，我收到此错误：无法显示数据。无法显示数据：没有适用于数据的视口。

我正在使用 Debian 6，Intel Vtune Amplifier (GUI) Update 5 (2013)。

我在 Ubuntu 上找到了一些关于这个问题的建议，但没有找到任何适用于 debian 的建议，并且建议的 ubuntu 解决方案似乎不适用于 debian。

我使用生产者-消费者模型用 pthread 编写了一个多线程程序。

当我使用英特尔 VTune 分析器分析我的程序时，我发现生产者和消费者在 pthread_mutex_unlock 上花费了大量时间。我不明白为什么会这样。我认为线程可能会等待很长时间才能获得互斥锁，但释放互斥锁应该很快，对吧？

下面的快照来自英特尔 VTune。它显示了消费者尝试从缓冲区中获取项目的代码，以及每个代码行所消耗的时间。

我的问题是为什么 pthread_mutex_unlock 有这样的开销？是 pthread mutex 本身的问题还是我使用它的方式有问题？

我在 32-nm Intel Westmere 处理器上运行 Linux。我担心来自性能计数器的 DTLB 未命中数上看似矛盾的数据。我使用随机内存访问测试程序（单线程）进行了两次实验，如下所示：

• 实验（1）：我使用以下性能计数器计算了 DTLB 未命中

  DTLB_MISSES.WALK_COMPLETED ((Event 49H, Umask 02H)

• 实验（2）：我通过以下两个计数器值相加来计算 DTLB 未命中

  MEM_LOAD_RETIRED.DTLB_MISS (Event CBH, Umask 80H)

  MEM_STORE_RETIRED.DTLB_MISS (Event 0CH, Umask 01H)

我希望这些实验的输出是相似的。然而，我发现实验（1）中报告的数字几乎是实验（2）中的两倍。我不知道为什么会这样。

有人可以帮助阐明这种明显的差异吗？

我正在编写一些模板代码来对使用浮点数和双精度数的数值算法进行基准测试，以便与 GPU 实现进行比较。

我发现我的浮点代码速度较慢，在使用英特尔的 Vtune Amplifier 进行调查后，我发现 g++ 正在生成额外的 x86 指令（cvtps2pd/cvtpd2ps 和 unpcklps/unpcklpd）以将一些中间结果从浮点数转换为双精度然后再返回。此应用程序的性能下降近 10%。

在使用标志 -Wdouble-promotion 编译后（顺便说一句，-Wall 或 -Wextra 不包含该标志），果然 g++ 警告我结果正在提升。

我将其简化为一个简单的测试用例，如下所示。请注意，c++ 代码的顺序会影响生成的代码。复合语句 (T d1 = log(r)/r;) 会产生警告，而单独的语句不会 (T d = log(r); d/=r;)。

以下使用 g++-4.6.3-1ubuntu5 和 g++-4.7.3-2ubuntu1~12.04 编译，结果相同。

编译标志是：

g++-4.7 -O2 -Wdouble-promotion -Wextra -Wall -pedantic -Werror -std=c++0x test.cpp -o test

我意识到 c++11 标准允许编译器在这里自行决定。但是为什么顺序很重要？

我可以明确指示 g++ 仅将浮点数用于此计算吗？

编辑：由 Mike Seymour 解决。需要使用 std::log 来确保获取重载版本的 log 而不是调用 C double log(double)。没有为分隔语句生成警告，因为这是转换而不是提升。

我有一个例程对小矩阵（50-100 x 1000 元素）执行一些 MKL 调用以拟合模型，然后我调用不同的模型。在伪代码中：

调用上面的版本1。由于模型是独立的，所以我可以使用OpenMP线程来并行化模型拟合，如下（版本2）：

当我在主机上运行版本 1 时，大约需要 11 秒，并且 VTune 报告并行化较差，大部分时间都处于空闲状态。主机上的版本 2 大约需要 5 秒，并且 VTune 报告了出色的并行化（几乎 100% 的时间花费在使用 8 个 CPU 上）。现在，当我编译代码以在本机模式下（使用 -mmic）在 Phi 卡上运行时，在 mic0 上的命令提示符下运行时，版本 1 和 2 都需要大约 30 秒。当我使用 VTune 对其进行分析时：

• 版本 1 大约需要 30 秒，热点分析表明大部分时间都花在了 __kmp_wait_sleep 和 __kmp_static_yield 上。在 7710 秒 CPU 时间中，有 5804 秒用于自旋时间。
• 版本 2 需要 fooooorrrreevvvver... 在 VTune 中运行几分钟后，我将其杀死。热点分析表明，25254s的CPU时间中，有21585s花费在[vmlinux]上。

谁能解释这里发生了什么以及为什么我的表现如此糟糕？我使用 OMP_NUM_THREADS 的默认值并设置 KMP_AFFINITY=compact,granularity=fine（如英特尔推荐的那样）。我是 MKL 和 OpenMP 的新手，所以我确定我犯了新手错误。

谢谢，安德鲁

单独运行 VTUNE 时出现某些错误，但如果我从 MSVC IDE 运行它，一切正常。
如果我从 MSVC 内部运行 VTUNE，是否会有任何报告不准确？

当我们使用 VTune 分析应用程序时，我知道应用程序应该在发布模式下编译，这样它就只有相关代码，没有额外的调试代码或其他代码。但是在这篇文章之后，我注意到它提到了收集调试信息。为什么需要此调试信息？由于这些调试信息的开销，它不会导致时序报告不准确吗？

在 Vtune 结果中，数字 0、1、2（和 3）实际代表什么？

Blue bar over 0 是什么意思？

我正在关注本教程以了解如何使用 VTUNE 删除锁
此页面在收集 Vtune 结果后显示以下内容：

识别最热门的代码行

单击热点导航按钮转到等待时间最长的代码行。VTune Amplifier 突出显示进入 draw_task 函数中临界区 rgb_critical_section 的第 170 行。draw_task 函数在此代码行执行期间等待了将近 27 秒，并且大部分时间处理器未得到充分利用。在此期间，临界区被争用了 438 次。

rgb_critical 部分是应用程序序列化的地方。每个线程必须等待关键部分可用才能继续。一次只能有一个线程位于临界区。您需要优化代码以使其更具并发性。

在我到达下一部分之前，我能够按照本教程进行操作：移除锁

取下锁

引入 rgb_critical_section 是为了保护计算免受多线程访问。简要分析表明，代码是线程安全的，临界区并不是真正需要的。

我的问题是我们怎么知道代码是线程安全的？

正如建议的那样，我评论了那些行（EnterCritical ...和LeaveCritical ...），并看到了巨大的性能提升，但我不明白为什么不需要这个关键部分？哪项分析告诉我们这一点？

相关代码在analyze_locks.cpp中：

我想使用 Intel VTune Amplifier XE 2013（应用的最新更新 15）分析 java 多核算法。

为此，我使用 Oracle JDK 1.7.0_40（64 位）从 Eclipse 启动 java 应用程序，然后将 vtune 分析器附加到正在运行的 java 进程。操作系统是 Windows 8.1 x64。vtune 可以收集统计信息，但显然 vtune 无法正确附加到 JVM，因此大多数记录的函数调用都被标记为“在任何已知模块之外”。在开始收集之前，VTune 收集器会报告以下警告：

有人经历过这个并找到了使用 VTune 启用完整的 java profiling 的方法吗？