소프트웨어 배포의 종류에 대한 몇 가지 세부 사항이 도움이 될 것이다. 이 질문은 소스 코드 배포를 의미하지만, 프로그래머가 Halide 제작 코드를 정교하게 조작해야하는 라이브러리와 Halide 사용이 대부분 최종 사용자에게는 보이지 않는 응용 프로그램과 목표는 단지 그것을 구축하는 것입니다.
비트 코드 배포는 가능하지만 문제가 있습니다. 휴대가 가능하려면 PNaCl 백엔드와 같은 것을 사용해야합니다. (PNaCl은 일반적인 LLVM 비트 코드 표현에 상당히 가깝습니다.) 특정 아키텍처를 대상으로하는 경우 다른 어떤 비트 아키텍처에서도 비트 코드가 컴파일되거나 실행되지 않을 수 있습니다. (Halide는 아키텍처 고유의 내장 함수로 낮출 수 있습니다.) LLVM 커뮤니티는 bitcode를 배포 형식으로 사용하는 것을 권장하지 않습니다. 소스 형식 (.ll이 아닌 .bc) 인 경우 상당히 안정적이며 배송보다 훨씬 나쁨 장기 안정성 측면에서 어셈블리 파일.
Halide는 생성 된 출력에 OS 특정 런타임을 포함하므로 비트 코드가 있더라도 결과에는 많은 타겟 특정 종속성이 포함됩니다.
종종 실제 사용되는 프로세서 유형에 따라 여러 할로겐 출력 중 하나를 런타임에서 선택하는 디자인으로 끝납니다. 예 : Halide를 사용하여 동일한 알고리즘을 SSE2 및 AVX2 프로세서에 대한 두 가지 다른 스케줄로 컴파일합니다. 이 모델에서는 어쨌든 많은 오브젝트 파일이 생길 것이며 빌드시에 특정 아키텍처 및 OS에 포함시킬 오브젝트 파일을 선택할 수 있습니다. 객체를 .o 파일보다는 .ll 파일로 배포하는 것이 효과적 일 수 있지만 많이 구입하지는 못합니다.
전체 소스 코드를 사용할 수 있도록하기 위해 노력할 것입니다. 처음부터 컴파일을 할 때 Halide가 필요하며 다양한 수준의 바이너리 배포를 제공 할 방법을 모색하고 있습니다. 물론 최종 사용자 소프트웨어의 경우 완전히 빌드 된 패키지를 사용자에게 제공하는 방법에 중점을 두어야합니다. 라이브러리의 경우 Halide를 사용하여 라이브러리 사용자에게 상위 레벨 프로그래밍 모델을 표시 할 수 있습니다.이 경우 Halide 컴파일러가 필요합니다.
우리는 시스템에 매우 쉽게 접근 할 수있게하기 위해 노력하고 매우 안정적이지만, 아직까지는 아무 것도 못 박았습니다. 나는 어느 정도 수준의 대체를 제공하려고 노력할 것이고 C 백엔드를 사용하여 일반적인 C 코드를 생성하는 것은 C에서 모든 것을 직접 재 작성하지 않고도 괜찮은 방법 일 수 있습니다. (소스에서 빌드하는 경우, Halide를 설치하거나 사전 빌드 된 C 코드를 사용하여 선택할 수 있습니다.) 이것은 C 백엔드의 더 나은 사용 사례 중 하나입니다. (Halide에서 C 코드를 생성하는 것은 처음에는 좋은 것으로 보이지만 일반적으로 꽤 좋은 아이디어입니다.)
결론적으로 비트 코드는 좋지 않습니다. 나는 Halide가없는 컴파일 경로를 제공 할 것이고, 따라서 가장 빠른 버전을 위해 Halide가 요구 될 것이다. 예 응용 프로그램의 오픈 소스 릴리스를 언급했습니다. – rodrigob