Некоторые подробности о типе распространения программного обеспечения не помешали бы. Вопрос подразумевает распространение исходного кода, но существует большая разница между библиотекой, в которой программистам может потребоваться взаимодействовать с кодом, созданным 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. (Генерация кода C из Halide, как правило, довольно маргинальная идея, несмотря на то, что поначалу она кажется хорошей.)
person
Zalman Stern
schedule
25.07.2014
