在本系列的前两期中，我们考虑了 Perl 中浮动操作的性能，
Python 和 R 在一个玩具示例中计算函数cos(sin(sqrt(x)))，其中 x 是一个非常大50M 双精度浮点数数组。
将算术密集型部分委托给 C 的混合实现是性能最高的实现之一。在本期中，我们将稍微偏离主题，看看玩具示例的纯 C 代码实现的性能。
C 代码将提供有关内存局部性对于性能重要性的进一步见解（默认情况下，C 数组中的元素存储在内存中的顺序地址中，以及数字 API，例如 PDL 或 numpy 与此类容器的接口）相对于容器,
例如Perl 数组不将其值存储在内存中的连续地址中。最后但同样重要的是，C 代码实现将允许我们评估与低级编译器（在本例中为 gcc）的浮点运算相关的标志是否会影响性能。
这一点值得强调：普通人在“管道”安装或构建内联文件时完全依赖于编译器标志的选择。如果一个人不触及这些标志，那么人们就会幸福地不知道他们可能会错过什么，或者他们可能会避免的陷阱。
简陋的 C 文件 makefile 允许人们明确地进行此类性能评估。
下面完整列出了我们玩具示例的 C 代码。该代码相当不言自明，因此除了指出它包含四个函数之外，不会花时间解释
在这种情况下，人们可能希望编译器足够聪明，能够识别平方根映射到汇编中的打包（向量化）浮点操作，以便可以使用适当的 SIMD 指令对一个函数进行向量化（请注意，我们没有使用OpenMP 代码的 simd 程序）。
也许矢量化的加速可以抵消重复访问相同内存位置（或不访问）所造成的性能损失。
一个关键问题是，使用快速浮动编译器标志（一种以速度换取代码准确性的技巧）是否会影响性能。
这是没有这个编译器标志的 makefile
这是带有此标志的：
这是运行这两个程序的结果
请注意，可以在 Numba 代码中使用 fastmath，如下所示（默认为 fastmath=False）：
值得注意的几点：
标题：“性能追求第三部分：C Force”
在本系列的前两期中，我们考虑了 Perl 中浮动操作的性能，
Python 和 R 在一个玩具示例中计算函数cos(sin(sqrt(x)))，其中 x 是一个非常大50M 双精度浮点数数组。
将算术密集型部分委托给 C 的混合实现是性能最高的实现之一。在本期中，我们将稍微偏离主题，看看玩具示例的纯 C 代码实现的性能。
C 代码将提供有关内存局部性对于性能重要性的进一步见解（默认情况下，C 数组中的元素存储在内存中的顺序地址中，以及数字 API，例如 PDL 或 numpy 与此类容器的接口）相对于容器,
例如Perl 数组不将其值存储在内存中的连续地址中。最后但同样重要的是，C 代码实现将允许我们评估与低级编译器（在本例中为 gcc）的浮点运算相关的标志是否会影响性能。
这一点值得强调：普通人在“管道”“安装”或构建内联文件时完全依赖于编译器标志的选择。如果一个人不触及这些标志，那么人们就会幸福地不知道他们可能会错过什么，或者他们可能会避免的陷阱。
简陋的 C 文件 makefile 允许人们明确地进行此类性能评估。
下面完整列出了我们玩具示例的 C 代码。该代码相当不言自明，因此除了指出它包含四个函数之外，不会花时间解释
在这种情况下，人们可能希望编译器足够聪明，能够识别平方根映射到汇编中的打包（向量化）浮点操作，以便可以使用适当的 SIMD 指令对一个函数进行向量化（请注意，我们没有使用OpenMP 代码的 simd 程序）。
也许矢量化的加速可以抵消重复访问相同内存位置（或不访问）所造成的性能损失。
一个关键问题是使用快速浮动编译器标志（一种以速度换取代码准确性的技巧）是否会影响性能。
这是没有这个编译器标志的 makefile
这是带有此标志的：
这是运行这两个程序的结果
请注意，可以在 Numba 代码中使用 fastmath，如下所示（默认为 fastmath=False）：
值得注意的几点：
以上是追求性能第三部分：C Force的详细内容。更多信息请关注PHP中文网其他相关文章！
