Perpustakaan Matematika untuk OpenCL?

Saya mencari informasi dari siapa saja yang telah mencoba menggunakan OpenCL dalam kode ilmiah mereka. Adakah yang pernah mencoba (baru-baru ini) ViennaCL ? Jika demikian, bagaimana jika dibandingkan dengan puncak ?

Bagaimana dengan OCLTools ? Apakah itu memenuhi janji? Jika demikian, apakah ini akan menjadi cara yang layak untuk mulai menulis kernel matematika di OpenCL?

Pertama-tama saya ingin mengucapkan terima kasih kepada Aron Ahmadia karena telah menunjuk saya ke utas ini.

Adapun OpenCL dalam kode ilmiah: OpenCL dimaksudkan untuk menjadi API tingkat rendah, oleh karena itu penting untuk membungkus fungsi ini dalam beberapa cara untuk mencapai produktivitas yang wajar. Selain itu, segera setelah beberapa kernel penghitungan terlibat, kode dapat menjadi SANGAT kotor jika OpenCL kernel dan memory handling harus sangat banyak dilewatkan dalam suatu aplikasi. Saya tidak tahu OCLTools, jadi saya tidak bisa mengatakan apakah mereka berguna dalam hal ini.

Adapun ViennaCL: Saya adalah kepala ViennaCL, jadi saya baru-baru ini bekerja dengan perpustakaan. :-) Pada bagian berikut, saya akan memperlakukan permintaan untuk perbandingan dengan titik puncak dalam lingkup yang sedikit lebih besar, yaitu ViennaCL versus bidang matematika dasar perpustakaan dan Magma berbasis CUDA . Hanya kondisi sekarang yang dipertimbangkan, meskipun ada banyak perkembangan yang sedang berlangsung (setidaknya di pihak kita).

Fungsionalitas . MAGMA menyediakan fungsionalitas BLAS untuk matriks padat melalui antarmuka fungsi yang biasa. Sebagian besar fungsi ini juga dilengkapi dengan ViennaCL 1.2.0 menggunakan kelebihan operator dan gula sintaksis lainnya.

Tiga pemecah iteratif yang sama (CG, BiCGStab, GMRES) disediakan dengan cusp dan ViennaCL. Himpunan prekondisi berbeda: Cusp menyediakan diagonal, SA-AMG dan berbagai prekondisi Bridson. ViennaCL menawarkan faktorisasi LU yang tidak lengkap, prekondisi diagonal, dan baru-baru ini berbagai rasa AMG dan Prekondisi Inversif Perkiraan Jarang. Sepengetahuan saya, semua preconditioner cusp beroperasi sepenuhnya pada GPU, sementara ViennaCL bergantung terutama selama fase pengaturan pada perhitungan berbasis CPU. Saat ini, jumlah format matriks jarang lebih besar di puncak: COO, CSR, DIA, ELL, HYB, sementara ViennaCL 1.2.0 menyediakan COO dan CSR.

Ada sejumlah fitur tambahan yang disediakan oleh ViennaCL, yang bukan merupakan bagian dari MAGMA atau cusp: Jenis matriks terstruktur (Circulant, Hankel, dll.), Fast Fourier transform, pengurutan ulang algoritma (misalnya Cuthill-McKee) dan pembungkus untuk aljabar linier jenis dari perpustakaan lain.

Performa. Serangkaian fitur dan dukungan perangkat keras yang lebih besar di ViennaCL biasanya datang dengan biaya kinerja yang lebih rendah bila dibandingkan dengan implementasi berbasis CUDA. Ini juga sebagian karena fakta bahwa CUDA dirancang untuk arsitektur produk-produk NVIDIA, sementara OpenCL mewakili kompromi yang masuk akal antara berbagai arsitektur inti.

Secara keseluruhan, ViennaCL saat ini lebih lambat daripada MAGMA, khususnya di BLAS level 3. Alasannya adalah fokus yang berbeda dari ViennaCL (jarang bukan aljabar linier padat) dan dengan demikian tingkat optimasi yang lebih tinggi dalam MAGMA. Terutama operasi level 3 BLAS saat ini jauh lebih cepat di MAGMA.

Demikian pula, puncak memberikan kinerja keseluruhan yang sedikit lebih baik secara umum. Namun, karena operasi matriks jarang biasanya bandwidth memori terbatas, perbedaannya jauh lebih kecil dan sering diabaikan dibandingkan dengan pengaturan data dan sejenisnya. Pilihan prekondisi dan parameternya biasanya memiliki dampak yang lebih tinggi pada waktu eksekusi keseluruhan daripada perbedaan kinerja dalam perkalian vektor-vektor yang jarang.

Portabilitas . Adapun portabilitas perangkat keras, ViennaCL dapat menggunakan CPU dan GPU dari semua vendor utama berkat OpenCL. Sebaliknya, cusp dan MAGMA mengandalkan GPU NVIDIA yang sesuai.

ViennaCL hanya header, dapat dikompilasi pada berbagai kompiler C ++ dan hanya perlu dihubungkan dengan perpustakaan OpenCL jika dukungan GPU diperlukan. Pada prinsipnya, algoritma generik di ViennaCL juga dapat digunakan tanpa tautan OpenCL, sementara cusp dan MAGMA membutuhkan kompiler NVIDIA untuk kompilasi dan perpustakaan CUDA pada sistem target untuk dieksekusi. MAGMA juga membutuhkan perpustakaan BLAS, yang kadang-kadang agak merepotkan untuk menemukan atau menginstal pada sistem baru.

API . MAGMA menyediakan antarmuka fungsi bergaya BLAS untuk fungsionalitas BLAS. Antarmuka C ++ cusp juga menggunakan beberapa fungsi dari BLAS, tetapi tidak ada operator yang berlebihan. Karena sebagian besar antarmuka di ViennaCL sengaja mirip dengan Boost.uBLAS dan fitur gula sintaksis seperti kelebihan operator, ViennaCL juga dimaksudkan untuk digunakan seperti Boost.uBLAS. Jadi, selain hanya memanggil seperangkat operasi dan algoritma yang telah ditentukan, niat kami adalah untuk membuat transisi dari eksekusi murni berbasis CPU ke kode GPU sesederhana mungkin, bahkan jika algoritma non-standar digunakan. Dalam hal diperlukan kernel OpenCL khusus, ada juga kerangka kerja untuk mengintegrasikan kernel OpenCL Anda sendiri di ViennaCL. Dengan demikian, ViennaCL bertujuan lebih ke arahproduktivitas tinggi dalam arti bahwa waktu yang diperlukan untuk mengimplementasikan algoritma baru pada GPU diminimalkan . Penghematan ini secara signifikan dapat melebihi hukuman kinerja apa pun (jika ada) dibandingkan dengan cusp dan MAGMA. (Juga disebutkan di utas pada unit testing bahwa waktu pengembangan kode adalah sumber yang berharga dalam sains.)

Tentu saja ada sejumlah masalah ideologis (misalnya CUDA vs OpenCL, BLAS-interface vs operator overloads) di seluruh perbandingan saya, tetapi diskusi mereka berada di luar ruang lingkup pertanyaan awal.

OpenCL dapat digunakan, namun, ada kekurangan infrastracture, misalnya perpustakaan matematika standar dewasa yang penting dengan komponen aljabar linier standar de facto yang disesuaikan dan sampai batas tertentu alat profil yang baik, meskipun masalah yang terakhir telah meningkat secara signifikan untuk GPU. Ini tersedia di CUDA mulai hari ini dan dapat dikontribusikan ke bagian dari kesuksesan Nvidia dengan model pemrograman ini. Namun, OpenCL tampaknya mengejar ketinggalan (lambat).

Saat ini, sebagai titik awal untuk pemrograman GPU CUDA baik-baik saja, dan jika diperlukan, tidak ada yang mencegah menggunakan OpenCL sebagai alternatif, misalnya untuk membuat kode lebih portabel. Pada dasarnya, kode kernel yang sama dapat digunakan baik di CUDA dan OpenCL sehingga seharusnya tidak menjadi masalah besar untuk beralih dari CUDA ke OpenCL. Ini dikonfirmasi oleh pengalaman sendiri menguji ini. Dari perspektif kinerja, teknik optimisasi yang sama dapat digunakan dan untuk kompiler kode konkuren sepele harus melakukan pekerjaan dengan baik (misal loop unrolling, dll.).