Autoconf：默认的开箱即用优化与交叉编译

Question

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

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

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

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

我目前倾向于选项2，因为这是我希望大多数用户欣赏的内容。另外，在默认行为中迎合新手可能更有意义。我知道这在可移植性方面构成了一个重要的罪恶。你们认为最明智的做法是什么？

我的困境是否有任何我不知道的解决方案？

Answer 1

这个问题本质上是主观的，但我认为选项（1）是更好的选择 - 因为你指定＆＃34;表现至关重要。＆＃34;

软件包的大多数用户（即发行版用户）都会对预构建的软件包或使用默认选项的源代码构建感到满意。如果性能 至关重要，那么期望用户熟悉编译器标志和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>更可取）

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

Answer 2

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