你能帮助我吗？我正在 Windows 7 x64 上开发 OpenCL 应用程序。硬件为 Intel Core i5、NVIDIA GTX 770。OpenCL 使用 NVIDIA 进行加速。

如果我尝试使用 Intel VTune Amplifier XE 2015，我的应用程序将在分析结束时挂起并且不返回任何报告。文档建议禁用所有“Cn(ACPI Cn) 向 OS 报告”BIOS 选项。但绝对不清楚如何更改我的应用程序代码以避免这种挂起。

我还尝试使用本手册https://github.com/UoB-HPC/UoB-HPC.github.io/blob/master/_posts/2015-05-27-nvvp-import-opencl.md使用 NVVP . 不幸的是，分析器生成错误：无法分析应用程序。“另一个 CUDA 工具（分析器、调试器、memcheck）当前正在运行，它会阻止对应用程序进行分析”。仅在运行 NVVP 时也会出现此错误。

在我的工作负载上运行 Intel VTune 时，我看到以下内容：

我阅读了英特尔文档，上面写着（英特尔文档）：

Memory Bound 测量一小部分插槽，其中流水线可能由于需求加载或存储指令而停止。这主要是由于不完整的动态内存需求负载与执行饥饿相吻合，以及存储可能暗示管道背压的不太常见的情况。

这是否意味着我的应用程序中大约有一半的指令在等待内存时停滞了，还是比这更微妙？

在执行我的简单（几行）VS2015 控制台 C++（本机）应用程序的英特尔“高级热点、堆栈和上下文切换分析”（或更高版本）时，其处理挂起并且需要重新启动 Windows，请参阅示例解决方案和屏幕截图包含在 zip 文件中）。这同样适用于更大的解决方案......“。“基本热点”和“没有堆栈的高级热点......”工作正常。有人可以帮忙吗？

热点设置的解决方案和屏幕截图：

https://app.box.com/s/ihb51o9cxrn8y7li6eupa9o7qbkof4dp

Windows 10Pro 64bit Build 1607，Intel Core I7-4771 VS2015 Community V. 14.0.25431.01 Updt。3 英特尔 VTume 放大器。XE2016 Updt 2, build 444464 感谢帮助！！！

编辑 3：图像是全尺寸版本的链接。对不起，文字图片，但图表很难复制/粘贴到文本表中。

对于使用以下代码编译的程序，我有以下 VTune 配置文件icc --std=c++14 -qopenmp -axS -O3 -fPIC：

在该配置文件中，装配视图中突出显示了两组指令。尽管指令相同且顺序相同，但上层集群花费的时间明显少于下层集群。两个集群都位于同一个函数内，并且显然都被称为n时间。每次我在我现在使用的 Westmere Xeon 和 Haswell 笔记本电脑上运行分析器时都会发生这种情况（使用 SSE 编译，因为这是我现在的目标和学习内容）。

我错过了什么？

忽略较差的并发性，这很可能是由于笔记本电脑节流，因为它不会发生在桌面 Xeon 机器上。

我相信这不是微优化的例子，因为这三个加起来占总时间的相当大的百分比，我对这种行为的可能原因非常感兴趣。

编辑： OMP_NUM_THREADS=1 taskset -c 1 /opt/intel/vtune...

相同的配置文件，尽管这次的 CPI 略低。

我有一个多线程程序。我们使用自己的线程池实现。首先，项目的负载足够。对比单线程，两个线程的程序更快。

当我们增加大于 2 的线程数时，性能开始变得很糟糕。显然，我们遇到了多线程的性能问题。

然后，我们开始使用 Intel® VTune™ Amplifier XE 2017 进行性能分析，我们把这个工具集成到 VS2013 中。然后当我点击英特尔® VTune™ Amplifier XE 的星形按钮时发生了一件令人惊讶的事情，项目开始运行，插件收集数据。我们发现，当我们通过插件启动这个项目时，随着线程数的增加，性能变得更高，运行时间也缩短了。我们最多可以打开 20 个线程。时间缩短20倍

那么，我们想知道，英特尔® VTune™ Amplifier XE 2017 能否改变多线程程序的运行模式？为什么会发生这种情况。我被这个问题困扰了很久。

我想要加速的应用程序对大型数组（大约 1e8 个元素）执行逐元素处理。

​每个元素的处理过程非常简单，我怀疑瓶颈可能不是 CPU，而是 DRAM 带宽。所以我决定一开始研究单线程版本。

系统为：Windows 10 64 位，32 GB RAM，Intel Core i7-3770S Ivybridge 1.10 GHz 4 核，启用超线程

并发分析

内存访问分析

内存访问分析为相同数据量的三个连续运行提供不同的 CPU 时间，正如并发分析所说，实际执行时间约为 23 秒。

据我了解摘要页面，情况不是很好。

发现你的内存访问性能瓶颈的论文 说原因是所谓的错误共享。但我不使用多线程，所有处理都由一个线程执行。

另一方面，根据内存访问分析/平台页面 DRAM 带宽不是瓶颈。

所以问题是

1. 为什么并发分析和内存访问分析的 CPU 时间指标值不同
2. 内存指标值不佳的原因是什么，尤其是对于 L1 Bound？

主循环是 lambda 函数，其中

• tasklets：包含用于数据处理的系数的简单结构的 std::vector
• 点：数据本身，Eigen::Matrix
• 投影：Eigen::Matrix，将处理结果放入的数组

代码是：

谢谢你。

我在 Windows 和 Linux (x86-64) 上运行一个程序。它使用相同的编译器（Intel Parallel Studio XE 2017）和相同的选项编译，Windows 版本比 Linux 版本快 3 倍。罪魁祸首是在英特尔数学库中解决了这两种情况的调用std::erf（默认情况下，它在 Windows 上动态链接，在 Linux 上静态链接，但在 Linux 上使用动态链接提供相同的性能）。

这是一个重现问题的简单程序。

当我使用 vTune 分析这个程序时，我发现程序集在 Windows 和 Linux 版本之间有点不同。这是 Windows 上的调用站点（循环）

以及在 Windows 上调用的 erf 函数的开头

在 Linux 上，代码有点不同。调用站点是：

被调用函数（erf）的开头是：

我已经展示了在 Linux 上浪费时间的 2 点。

有没有人足够了解汇编来解释这两个代码的区别以及为什么 Linux 版本慢了 3 倍？

一个函数在应用程序中花费的总时间可以大致分为两个部分：

1. 实际计算所花费的时间 (Tcomp)
2. 内存访问所花费的时间 (Tmem)

通常，分析器提供函数花费的总时间的估计。是否可以根据上述两个组件（Tcomp 和 Tmem）估算所花费的时间？

我正在关注这个关于 VTune Amplifier 的视频教程（来自 Linux），并且我已经关注了所有内容，但是当他比较两个基本分析时，出现了这个错误：

我该如何解决这个问题？

SEP 驱动程序未构建且未安装：

Perf 工具也没有正确构建（内核是定制的）：

但是 - VTune 确实有效，我可以看到分析结果。在这种情况下使用什么样的采样？我在 VTune GUI 中看不到任何相关内容。