Trước hết tôi muốn cảm ơn Aron Ahmadia vì đã chỉ cho tôi chủ đề này.
Đối với OpenCL trong mã khoa học: OpenCL có nghĩa là một API cấp thấp, do đó, điều quan trọng là phải bọc chức năng này theo một cách nào đó để đạt được năng suất hợp lý. Hơn nữa, ngay sau khi một số hạt nhân tính toán có liên quan, mã có thể bị RẤT bẩn nếu hạt nhân OpenCL và các thẻ điều khiển bộ nhớ cần được truyền qua rất nhiều trong một ứng dụng. Tôi không biết OCLTools, vì vậy tôi không thể nói liệu chúng có hữu ích trong vấn đề này hay không.
Đối với ViennaCL: Tôi là người đứng đầu ViennaCL, vì vậy gần đây tôi đã làm việc với thư viện. :-) Trong phần sau tôi sẽ xử lý yêu cầu so sánh với cusp trong phạm vi lớn hơn một chút, cụ thể là ViennaCL so với các thư viện toán học dựa trên CUDA cusp và MAGMA . Chỉ có nhà nước hiện tại được xem xét, mặc dù có rất nhiều sự phát triển đang diễn ra (ít nhất là về phía chúng tôi).
Chức năng . MAGMA cung cấp chức năng BLAS cho ma trận dày đặc thông qua các giao diện chức năng thông thường. Hầu hết các chức năng này cũng được cung cấp với ViennaCL 1.2.0 bằng cách sử dụng quá tải toán tử và đường cú pháp khác.
Ba bộ giải lặp tương tự (CG, BiCGStab, GMRES) được cung cấp với cusp và ViennaCL. Tập hợp các điều kiện tiên quyết khác nhau đáng chú ý: Cusp cung cấp các điều kiện tiên quyết chéo, SA-AMG và Bridson khác nhau. ViennaCL cung cấp các yếu tố LU không hoàn chỉnh, các điều kiện tiên quyết chéo, và các hương vị AMG khác nhau gần đây và các điều kiện tiên quyết nghịch đảo thưa thớt. Theo hiểu biết của tôi, tất cả các điều kiện tiên quyết cusp chạy hoàn toàn trên GPU, trong khi ViennaCL đặc biệt dựa vào giai đoạn thiết lập trên các tính toán dựa trên CPU. Hiện tại, số lượng định dạng ma trận thưa thớt lớn hơn trong cusp: COO, CSR, DIA, ELL, HYB, trong khi ViennaCL 1.2.0 cung cấp COO và CSR.
Có một số tính năng bổ sung được cung cấp với ViennaCL, không phải là một phần của MAGMA hoặc cusp: Các loại ma trận có cấu trúc (Circulant, Hankel, v.v.), biến đổi Fourier nhanh, thuật toán sắp xếp lại (ví dụ Cuthill-McKee) và trình bao cho đại số tuyến tính loại từ các thư viện khác.
Hiệu suất. Tập hợp các tính năng và hỗ trợ phần cứng lớn hơn trong ViennaCL thường có chi phí hiệu năng thấp hơn khi so sánh với các triển khai dựa trên CUDA. Điều này cũng một phần là do CUDA phù hợp với kiến trúc của các sản phẩm NVIDIA, trong khi OpenCL thể hiện ở một khía cạnh nào đó là sự thỏa hiệp hợp lý giữa các kiến trúc nhiều lõi khác nhau.
Nhìn chung, ViennaCL hiện tại chậm hơn so với MAGMA, đặc biệt là ở BLAS cấp 3. Lý do là trọng tâm khác nhau của ViennaCL (thưa thớt thay vì đại số tuyến tính dày đặc) và do đó mức độ tối ưu hóa cao hơn trong MAGMA. Đặc biệt các hoạt động BLAS cấp 3 hiện đang nhanh hơn đáng kể trong MAGMA.
Tương tự, cusp cung cấp hiệu suất tổng thể tốt hơn một chút nói chung. Tuy nhiên, do các hoạt động ma trận thưa thớt thường bị giới hạn băng thông bộ nhớ, sự khác biệt nhỏ hơn đáng kể và thường không đáng kể so với thiết lập dữ liệu và tương tự. Sự lựa chọn của điều kiện tiên quyết và các tham số của nó thường có tác động cao hơn đến thời gian thực hiện tổng thể so với bất kỳ sự khác biệt hiệu suất nào trong phép nhân vectơ ma trận thưa thớt.
Tính di động . Về tính di động của phần cứng, ViennaCL có thể sử dụng CPU và GPU từ tất cả các nhà cung cấp chính nhờ OpenCL. Ngược lại, cusp và MAGMA dựa trên GPU NVIDIA phù hợp.
ViennaCL chỉ dành cho tiêu đề, có thể được biên dịch trên một loạt các trình biên dịch C ++ và chỉ cần được liên kết với thư viện OpenCL nếu cần hỗ trợ GPU. Về nguyên tắc, các thuật toán chung trong ViennaCL cũng có thể được sử dụng mà không cần bất kỳ liên kết OpenCL nào, trong khi cusp và MAGMA yêu cầu trình biên dịch NVIDIA để biên dịch và thư viện CUDA trên hệ thống đích để thực thi. MAGMA cũng yêu cầu một thư viện BLAS, đôi khi có thể gặp một chút rắc rối khi tìm hoặc cài đặt trên một hệ thống mới.
API . MAGMA cung cấp các giao diện chức năng kiểu BLAS cho chức năng BLAS. Giao diện C ++ của cusp cũng sử dụng một số chức năng từ BLAS, nhưng không quá tải toán tử. Vì hầu hết các giao diện trong ViennaCL tương tự như Boost.uBLAS và có tính năng cú pháp như quá tải toán tử, ViennaCL cũng được sử dụng như Boost.uBLAS. Do đó, ngoài việc chỉ gọi một tập hợp các thuật toán và thuật toán được xác định trước, ý định của chúng tôi là thực hiện chuyển đổi từ thực thi hoàn toàn dựa trên CPU sang mã GPU càng đơn giản càng tốt, ngay cả khi sử dụng thuật toán không chuẩn. Trong trường hợp yêu cầu một nhân OpenCL chuyên dụng, cũng có một khung để tích hợp các nhân OpenCL của riêng bạn trong ViennaCL. Do đó, ViennaCL nhắm nhiều hơn vàonăng suất cao theo nghĩa là thời gian cần thiết để thực hiện các thuật toán mới trên GPU được giảm thiểu . Những khoản tiết kiệm này có thể vượt xa đáng kể bất kỳ hình phạt hiệu suất nào (nếu có) so với cusp và MAGMA. (Nó cũng đã được đề cập trong chủ đề về thử nghiệm đơn vị rằng thời gian phát triển mã là một tài nguyên quý giá trong khoa học.)
Chắc chắn có một số vấn đề về ý thức hệ (ví dụ CUDA so với OpenCL, giao diện BLAS so với quá tải toán tử) trong suốt so sánh của tôi, nhưng cuộc thảo luận của họ nằm ngoài phạm vi của câu hỏi ban đầu.