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