我目前正在试验Halide，最初的测试显示出相当有希望的性能改进。推荐分配卤化物生成函数的方法？
我现在想知道分配Halide代码的最佳策略是什么。要求用户安装Halide在这个时候看起来像是一个沉重的障碍（因为没有自动安装选项）。
一种选择是使用compile_to_c，将生成的C代码添加到存储库中，并为这些C代码分发编译脚本。 scikit-learn为Cython生成的代码使用了类似的策略。对于Halide来说，这看起来像是一个不行，因为生成的C代码失去了所有的优化，从而破坏了Halide的目的。
我现在的想法是使用 compile_to_bitcode，与调用llc产生所需机器的代码编译脚本一起分发的生成位码。用户的唯一要求是安装llc（即llvm）。
有没有人有这方面的经验？
分配位码的想法有哪些优缺点？
你会推荐什么？
的那种软件分发的一些细节会有所帮助。这个问题意味着一个源代码分发，但是程序员可能需要在细粒度级别上与Halide生成的代码进行交互的库和使用Halide对于最终用户来说基本上不可见的应用程序之间存在巨大差异，目标只是让它建立。
分布式位码是可行的但存在问题。为了便于携带，你必须使用类似于PNaCl后端的东西。 （PNaCl非常接近通用的LLVM位码表示）。如果您的目标是特定的体系结构，则不能保证位编码可以编译或在任何其他体系上运行。 （例如，Halide可以降低到特定架构的内部函数。）LLVM社区不鼓励使用位代码作为分布格式，但如果它是源代码形式（.ll，而不是.bc），它可能相当稳定，似乎并不比运输差得多汇编文件在长期稳定性方面。
Halide在生成的输出中包含一个操作系统特定的运行时间，所以即使使用位代码，结果也包含许多目标特定的依赖关系。
通常情况下，一个设计会在运行时根据所使用的处理器的实际类型选择多个Halide输出之一。例如。使用Halide针对SSE2和AVX2处理器使用两种不同的时间表编译相同的算法。在这个模型中，无论如何都会有很多的目标文件，并且在构建时可以简单地选择哪些包含给定的体系结构和操作系统。将对象分配为.ll文件而不是.o文件可能会起作用，但我不确定它购买多少。
我会尽力使完整的源代码可用，需要Halide如果从头开始编译，并寻找方法来提供各种级别的二进制分发。当然，对于最终用户软件来说，重点应该放在如何将完全构建的软件包交付给用户。对于库，Halide可以用来为库的用户提供更高层次的编程模型，在这种情况下，Halide编译器无论如何都需要存在。
我们努力让Halide相当容易地进入系统，并且非常稳定，但还没有完全确定。我可能会尝试提供某种级别的回退，并使用C后端生成通用C代码可能是一种体面的方式，无需直接在C中重写所有内容。 （如果从源代码构建，可以选择安装Halide或使用预编译的C代码）。这是C后端更好的用例之一。 （从Halide生成C代码通常是一个相当微不足道的想法，尽管它起初似乎很好。）
compile_to_c（）肯定不被推荐，因为它生成的代码并不是非常优化;它主要用作调试/开发工具。编译_to_bitcode（）听起来像它可以工作，但我不知道任何人使用这个作为分配方法。
（这很可能是有用的一个自动安装可用于卤化物）
因此，底线，bitcode是一个坏主意。我将提供一个没有Halide的编译路径，对于最快的版本，Halide将成为一项要求。 是的，我指的是一个应用程序的开源版本。 – rodrigob