1

我是一个软件包的首席开发人员，该软件包的性能是最重要的。当某些设施可用时，所述软件的性能可以大大提高，例如：

  • 软件库（例如 BLAS、LAPACK、...）
  • 支持 SSE、MMX、...

我处于一种情况，我发现很难决定最明智的方法。我看待事物的方式，这些是我的选择：

  1. 确保可移植性和正确的交叉编译：通过使用可选的可用设施并强制用户使用 -enable-X 标志等显式启用它们。这对于可移植性是必要的，因为构建平台上可用的设施可能不存在于目标平台上. PRO：可移植性和交叉编译工作正常。缺点：新手用户会忘记优化并因此遭受性能损失。
  2. 让新手用户的生活更轻松：在配置阶段自动检查库和功能（如 SSE）的可用性，然后使用所有可用的工具。PRO：用户无需烦躁即可获得软件的优化版本。CON：不保证可移植性（例如，当主机有 SSE 而目标没有时，交叉编译会被破坏。我不希望我的用户交叉编译，但死亡和税收是生活中唯一的确定性。）。

我目前倾向于选项 2，因为这是我希望大多数用户欣赏的。此外，在默认行为方面迎合新手可能更有意义。我知道这在可移植性方面构成了大罪。大家觉得最明智的做法是什么？

有什么我不知道的解决方案可以解决我的困境吗？

4

2 回答 2

1

这个问题本质上是主观的，但我认为选项 (1) 是一个更好的选择 - 因为您指定“性能至关重要”。

软件包的大多数用户（即发行版用户）会对预构建的软件包或具有默认选项的源代码构建感到满意。如果性能至关重要，那么期望用户熟悉编译器标志和configure ...用法是合理的。如果用户不关心性能，或者懒得阅读README发行版中的简单内容，那么默认构建应该是可行的——它不必是最佳的。

我不确定交叉编译的缺点 - 看起来你可能会host感到target困惑，因为target在构建交叉编译器工具之外很少见。正确使用host三元组结合config.guess提供了很多有用的信息。例如：

case $host_cpu in
    x86_64) ... we always have SSE available ... ;;
esac

现在假设您指定-march=core2为 [cross] 编译器标志：

#if defined (__SSE3__)
#include <pmmintrin.h> /* (SSE3 Intel intrinsics)
#endif

即使使用交叉编译器也可以工作。（虽然<immintrin.h>现在更可取）

简而言之，新手用户获得了新手构建。您无法针对每个可能的主机和环境组合进行优化，但您可以提供选项。

于 2013-05-04T13:14:26.313 回答
0

无论 SSE 库的可用性如何，您都不能构建未优化的二进制文件，并在运行时确定将使用哪些版本？如果您使用动态链接，这不应该在运行时导致任何性能消耗或开销。

于 2013-05-03T19:30:14.493 回答