我目前正在试验 Halide ，初始测试显示非常有希望的性能改进。
我现在想知道分发 Halide 代码的最佳策略是什么。目前，要求用户安装 Halide 似乎是一个沉重的障碍(因为没有自动安装选项)。
一种选择是使用 compile_to_c ，将生成的 C 代码添加到存储库中，并分发此类 C 代码的编译脚本。 scikit-learn对 Cython 生成的代码使用类似的策略。对于 Halide 来说，这似乎是不可行的，因为生成的 C 代码失去了所有优化，违背了 Halide 的目的。
我目前的想法是使用
compile_to_bitcode ，将生成的位码与调用 llc 的编译脚本一起分发生成所需的机器代码。对用户的唯一要求是拥有 llc (即 llvm )已安装。
有没有人有这个问题的经验？
我分发 bitcode 的想法的利弊是什么？
你会推荐什么？
最佳答案
有关软件分发类型的一些详细信息会有所帮助。该问题暗示了源代码分发，但程序员可能需要在细粒度级别与 Halide 生成的代码进行交互的库与最终用户在很大程度上不可见 Halide 的使用的应用程序之间存在很大差异。目标只是让它构建。
分发位码是可行的，但有问题。为了便于携带，您必须使用类似 PNaCl 的后端。 (PNaCl 非常接近于通用的 LLVM 位码表示。)如果您针对特定架构，则不能保证位码会在任何其他架构上编译或运行。 (例如，Halide 可以降低到特定于架构的内在函数。)LLVM 社区不鼓励使用 bitcode 作为分发格式，但如果它是源代码形式(.ll，而不是 .bc)，它可能相当稳定，并且看起来并不比运输差多少长期稳定性方面的装配文件。
Halide 在生成的输出中包含特定于操作系统的运行时，因此即使使用位代码，结果也包含许多特定于目标的依赖项。
通常最终的设计是在运行时根据所使用的处理器的实际类型在多个 Halide 输出之一之间进行选择。例如。使用 Halide 为 SSE2 和 AVX2 处理器编译具有两种不同调度的相同算法。在这个模型中，无论如何都会有很多目标文件，并且可以在构建时简单地选择要为给定的体系结构和操作系统包含哪些目标文件。将对象作为 .ll 文件而不是 .o 文件分发可能会起作用，但我不确定它会买多少。
我会努力使完整的源代码可用，如果有人从头开始编译，则需要 Halide，并寻找提供各种级别的二进制分发的方法。当然，对于最终用户软件而言，重点应该放在如何将完全构建的软件包交到用户手中。对于库，Halide 可用于向库用户展示更高级别的编程模型，在这种情况下，无论如何都需要存在 Halide 编译器。
我们努力使 Halide 相当容易进入一个系统并且非常稳定，但还没有完全确定。我可能会尝试提供某种程度的回退，并且使用 C 后端生成通用 C 代码可能是一种不错的方法，而无需直接在 C 中重写所有内容。 (如果从源代码构建，可以选择安装 Halide 或使用预构建的 C 代码。)这是 C 后端更好的用例之一。 (从 Halide 生成 C 代码通常是一个非常边缘的想法，尽管它一开始看起来不错。)
关于image-processing - 推荐的方式来分发 Halide 生成的函数？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/24957850/