우선 Aron Ahmadia 에게이 스레드를 지적 해 주셔서 감사합니다.
과학 코드의 OpenCL의 경우 : OpenCL은 저수준 API를 의미하므로 합리적인 생산성에 도달하기 위해이 기능을 어떤 방식으로 포장하는 것이 중요합니다. 또한 여러 컴퓨팅 커널이 관련되는 즉시 OpenCL 커널 및 메모리 핸들을 응용 프로그램 내에서 많이 전달해야하는 경우 코드가 매우 더러워 질 수 있습니다. OCLTools를 모르므로 이러한 점에서 유용한 지 여부를 말할 수 없습니다.
ViennaCL의 경우 : 저는 ViennaCL의 책임자이므로 최근에 도서관에서 일했습니다. :-) 다음에서는 약간 큰 범위, 즉 ViennaCL 대 CUDA 기반 수학 라이브러리 cusp 및 MAGMA 에서 cusp와의 비교 요청을 처리합니다 . (적어도 우리 편에서) 진행중인 개발이 많이 있더라도 현재 상태 만 고려됩니다.
기능성 . MAGMA는 일반적인 함수 인터페이스를 통해 고밀도 매트릭스에 BLAS 기능을 제공합니다. 이 기능의 대부분은 연산자 과부하 및 기타 구문 설탕을 사용하여 ViennaCL 1.2.0과 함께 제공됩니다.
동일한 세 가지 반복 솔버 (CG, BiCGStab, GMRES)가 cusp 및 ViennaCL과 함께 제공됩니다. 전제 조건 세트는 현저히 다릅니다. Cusp는 대각선, SA-AMG 및 다양한 Bridson 전제 조건을 제공합니다. ViennaCL은 불완전한 LU 분해, 대각 전제 조건 및 최근 다양한 AMG 풍미 및 Sparse Approximate Inverse 전제 조건을 제공합니다. 내가 알기로는 모든 cusp 전제 조건은 GPU에서 완전히 실행되는 반면 ViennaCL은 특히 CPU 기반 계산의 설정 단계에 의존합니다. 현재 COO, CSR, DIA, ELL, HYB와 같은 희소 행렬 형식의 수는 더 많으며 ViennaCL 1.2.0은 COO 및 CSR을 제공합니다.
ViennaCL에는 MAGMA 또는 cusp의 일부가 아닌 여러 가지 추가 기능이 있습니다. 구조화 된 행렬 유형 (Circulant, Hankel 등), 빠른 푸리에 변환, 재정렬 알고리즘 (예 : Cuthill-McKee) 및 선형 대 수용 래퍼 다른 라이브러리의 유형.
공연. ViennaCL의 더 큰 기능 및 하드웨어 지원은 CUDA 기반 구현과 비교할 때 일반적으로 성능이 저하됩니다. 이는 CUDA가 NVIDIA 제품의 아키텍처에 맞게 조정 된 반면 OpenCL은 여러 가지 핵심 아키텍처 간의 합리적인 타협을 나타냅니다.
전반적으로 ViennaCL은 현재 MAGMA보다 느리고 특히 BLAS 레벨 3입니다. 그 이유는 ViennaCL (고밀도 선형 대수 대신 희소)의 초점이 다르기 때문에 MAGMA의 최적화 수준이 높습니다. 특히 BLAS 레벨 3 작업은 현재 MAGMA에서 상당히 빠릅니다.
마찬가지로, cusp는 일반적으로 전반적으로 약간 더 나은 성능을 제공합니다. 그러나, 희소 행렬 연산은 일반적으로 메모리 대역폭이 제한되어 있기 때문에, 데이터 설정 등에 비해 차이가 상당히 작고 종종 무시할 수있다. 전제 조건과 매개 변수의 선택은 일반적으로 희소 행렬 벡터 곱셈의 성능 차이보다 전체 실행 시간에 더 큰 영향을 미칩니다.
이식성 . 하드웨어 이식성과 관련하여 ViennaCL은 OpenCL 덕분에 모든 주요 공급 업체의 CPU와 GPU를 사용할 수 있습니다. 대조적으로, cusp와 MAGMA는 적합한 NVIDIA GPU에 의존합니다.
ViennaCL은 헤더 전용이며 광범위한 C ++ 컴파일러에서 컴파일 할 수 있으며 GPU 지원이 필요한 경우에만 OpenCL 라이브러리와 링크하면됩니다. 원칙적으로 ViennaCL의 일반 알고리즘은 OpenCL 연결 없이도 사용할 수 있지만 cusp 및 MAGMA에는 컴파일을 위해 NVIDIA 컴파일러가 필요하며 실행을 위해서는 대상 시스템의 CUDA 라이브러리가 필요합니다. MAGMA에는 BLAS 라이브러리도 필요합니다.이 라이브러리는 때때로 새로운 시스템에서 찾거나 설치하는 데 약간의 번거 로움이 될 수 있습니다.
API . MAGMA는 BLAS 기능을위한 BLAS 스타일 기능 인터페이스를 제공합니다. cusp의 C ++ 인터페이스는 BLAS의 일부 함수를 사용하지만 연산자 오버로드는 없습니다. ViennaCL의 대부분의 인터페이스는 의도적으로 Boost.uBLAS와 유사하고 연산자 오버로드와 같은 구문 설탕을 특징으로하기 때문에 ViennaCL도 Boost.uBLAS와 같이 사용됩니다. 따라서 사전 정의 된 연산 및 알고리즘 집합을 호출하는 것 외에도 비표준 알고리즘을 사용하더라도 순수한 CPU 기반 실행에서 가능한 한 간단하게 GPU 코드로 전환하는 것이 목적입니다. 전용 OpenCL 커널이 필요한 경우 ViennaCL에 자체 OpenCL 커널을 통합하기위한 프레임 워크도 있습니다. 따라서 ViennaCL은 더 많은 것을 목표로합니다GPU에서 새로운 알고리즘을 구현하는 데 필요한 시간이 최소화된다는 점에서 높은 생산성 . 이러한 비용 절감은 커 스프 및 MAGMA에 비해 성능 저하 (있는 경우)보다 훨씬 클 수 있습니다. (또한 코드 개발 시간은 과학에서 귀중한 자원이라고 단위 테스트 스레드에서 언급되었습니다 .)
필자의 비교에는 분명히 많은 이데올로기 문제 (예 : CUDA vs. OpenCL, BLAS- 인터페이스 vs. 연산자 과부하)가 있지만 그 논의는 초기 질문의 범위를 벗어납니다.