问题标签 [intel]

我最近编写了一些代码（ISO/ANSI C），并对它实现的糟糕性能感到惊讶。长话短说，原来罪魁祸首是floor()函数。它不仅速度慢，而且没有矢量化（使用英特尔编译器，又名 ICL）。

以下是为 2D 矩阵中的所有单元格执行地板的一些基准：

将其与简单的演员表进行比较：

怎么可能floor()比简单的演员阵容慢那么多？！它基本上做同样的事情（除了负数）。第二个问题：有人知道超快速的floor()实现吗？

PS：这是我进行基准测试的循环：

我们一直是一家英特尔商店。所有开发人员都使用 Intel 机器，最终用户推荐的平台是 Intel，如果最终用户想在 AMD 上运行，那是他们的了望。也许测试部门在某处有一台 AMD 机器来检查我们没有运送任何完全损坏的东西，但仅此而已。

直到几年前，我们还只使用了 MSVC 编译器，因为它并没有真正提供很多超出 SSE 级别的处理器调整选项，所以没有人担心代码是否会偏向一个 x86 供应商而不是另一个供应商。然而，最近我们一直在使用英特尔编译器。我们的东西肯定会从中获得一些显着的性能优势（在我们的英特尔硬件上），它的矢量化能力意味着更少需要去 asm/intrinsics。然而，人们开始对英特尔编译器是否实际上可能没有为 AMD 硬件做得这么好感到有点紧张。当然，如果您进入英特尔 CRT 或 IPP 库，您会看到很多 cpuid 查询显然设置跳转表以优化功能。不过，英特尔似乎不太可能为 AMD 芯片做任何好事。

在这方面有任何经验的人可以评论这在实践中是否重要吗？（我们自己实际上还没有对 AMD 进行任何性能测试）。

2010-01-04 更新：嗯，支持 AMD 的需求从未变得足够具体，以至于我自己无法进行任何测试。这里有一些关于这个问题的有趣读物，这里和这里。

2010-08-09 更新：似乎 Intel-FTC 的解决方案对这个问题有话要说 - 请参阅本文的“编译器和肮脏技巧”部分。

昨天我遇到了一个 g++ (3.4.6) 编译器问题，我使用 Intel (9.0) 编译器编译的代码没有问题。这是一个显示发生了什么的代码片段：

g++ 编译器错误是：

显然，以这种方式编写时不接受默认参数，并且编译器假定指定了新的函数参数而不是第二个模板参数，然后它需要一个默认值，因为该stuff参数有一个。我可以通过创建 typedef 来帮助编译器，然后一切都编译得很好：

所以我可以解决我的问题，但我不明白发生了什么。我是否在这里错过了 C++（模板？）语言功能，我做错了什么，还是 g++ 编译器不接受第一段代码是错误的？

注意顺便说一句，这也编译...

我有兴趣了解 C++ 在基于 Intel 的系统上使用的单类型或双类型的二进制格式。

在数据可能需要由另一个系统（即文件或网络）读取或写入的情况下，我避免使用浮点数。我确实意识到我可以使用定点数，并且定点更准确，但我有兴趣了解浮点格式。

OpenSolaris 似乎不支持 Intel 82Q35 芯片组。这会转化为缓慢的 Xorg，其性能会随着时间的推移而下降，甚至在全屏 gnome 控制台终端上执行 ls 也根本不可用。

我注意到 Xorg 进程和 gnome 使用了大量内存（>400Mb）（每个 gnome 应用程序>100Mb）。一旦我切换到 vesa，一切都变得更加合理 Xorg (90Mb)。但有时对于 GUI 密集型应用程序，UI 会变得很慢。

是否有任何替代方案可以使其更具响应性？

有没有人遇到过 Delphi 的框架或库来简化 x86 代码的生成？我不是在寻找一个汇编器，而是一个将代码生成过程抽象到低级位和字节之上的框架。理想情况下，我想在现有库或框架之上构建，而不是根据具体情况对逻辑进行硬编码。

最初的用途是在运行时生成小的代码存根，类似于 Delphi 分派 SOAP 请求的方式。如果我找不到东西，我可能会自己动手，但我不想重新发明轮子。如果许可证允许在商业和开源项目中翻译和使用，那么“C”中的某些内容可能会让我感兴趣。

更新：

这里有一些更多的上下文：我正在努力将接口和/或类的运行时实现作为持久性框架的一部分。有点像 Java 注释驱动的持久性 (JPA/EJB3)，除了具有明显的 Delphi 风格。调用目标是一个模块化/可扩展的框架，它将实现一个通用的持久性模型。我需要以非常动态和流畅的方式调度和挂钩基于 RTTI 和注释/属性模型（类似于 InstantObjects 元数据）的方法调用。

谢谢，大卫

我有几个关于多核 CPU 或多处理器系统中使用的高速缓存存储器的问题。（虽然与编程没有直接关系，但在为多核处理器/多处理器系统编写软件时会产生很多影响，因此在这里问！）

1. 在多处理器系统或多核处理器（英特尔四核、酷睿二双核等）中，每个 cpu 核心/处理器是否有自己的高速缓存（数据和程序高速缓存）？

2. 一个处理器/核心是否可以访问彼此的缓存，因为如果允许它们访问彼此的缓存，那么我相信可能会有更少的缓存未命中，在这种情况下，如果该特定处理器缓存没有一些数据但其他一些数据处理器的缓存可能有它，从而避免从内存读取到第一个处理器的缓存？这个假设是否有效和真实？

3. 允许任何处理器访问其他处理器的高速缓存内存会有什么问题吗？

我正在寻找一种方法来获得有关 Xeon E5420 的精确架构信息。该处理器有 4 个内核和 2x6Mo 缓存，因此 2 个内核共享一个 6Mo 缓存。

我正在使用具有 2 个 Xeon 处理器的机器，因此具有 8 个内核，查看 /proc/cpuinfo 只是让我知道哪个内核在哪个处理器上。

通常奇数核心在一个处理器上，偶数核心在另一个处理器上，但我没有找到方法知道同一处理器上的哪两个核心共享 6Mo 缓存。

有什么线索吗？

已经阅读了这个问题，我有理由确定使用浮点运算和相同输入的给定进程（在相同的硬件上，使用相同的编译器编译）应该是确定性的。我正在研究一个不正确的案例，并试图确定是什么原因造成的。

我已经编译了一个可执行文件，我给它提供了完全相同的数据，在单台机器（非多线程）上运行，但是我得到了大约 3.814697265625e-06 的错误，经过仔细的谷歌搜索，我发现它实际上等于 1 /4^9 = 1/2^18 = 1/262144。这非常接近 32 位浮点数的精度级别（根据维基百科大约 7 位）

我怀疑它与已应用于代码的优化有关。我正在使用英特尔 C++ 编译器，并将浮点推测转为快速而不是安全或严格。这会使浮点过程变得不确定吗？是否有其他优化等可能导致这种行为？

编辑：根据 Pax 的建议，我重新编译了代码，浮点推测转为安全，我现在得到了稳定的结果。这让我可以澄清这个问题——浮点推测实际上做了什么，当应用于完全相同的输入时，这如何导致相同的二进制文件（即一次编译、多次运行）产生不同的结果？

@Ben 我正在使用 Intel(R) C++ 11.0.061 [IA-32] 进行编译，并且在 Intel 四核处理器上运行。

我正在尝试将程序从 gfortran 移植到 ifort（英特尔 Fortran 编译器 11）。我遇到了两个只能用 gfortran 编译的文件：

当我尝试使用这些文件运行 intel fortran 编译器时，我得到：

并且没有创建目标文件。

现在，我该如何解决这个问题o_O？

编辑：将文件扩展名从 ff 重命名为 fpp

帮助：

http://www.rcac.purdue.edu/userinfo/resources/black/userguide.cfm#compile_fortran_cpp

更新：有没有办法让 intel fortran 编译器工作而不必重命名文件？