Masa Depan OpenCL?

Paradigma pemrograman OpenCL berjanji untuk menjadi standar bebas royalti untuk komputasi heterogen. Haruskah kita menginvestasikan waktu kita dalam mengembangkan perangkat lunak berbasis OpenCL? Pro kontra?

Pertanyaannya terlalu luas dan tidak jelas untuk dijawab. Namun, saya melihat satu poin penting terhadap OpenCL, dari sudut pandang komputasi ilmiah, yang jarang ditekankan. Sejauh ini, belum ada upaya untuk menghasilkan open source, perpustakaan infrastruktur untuk OpenCL, sedangkan CUDA memiliki beberapa opsi yang sangat baik:

• CUBLAS , CUFFT , CUSPARSE
• Thrust , titik puncak , OpenCurrent
• Dukungan PETSc

Saya percaya ini akan sangat merugikan OpenCL karena fasilitator utama adopsi adalah perpustakaan terbuka berkualitas tinggi.

OpenCL vs apa?

Jika pertanyaannya adalah OpenCL vs CUDA, saya melihat banyak tangan meremas pertanyaan ini, dan sepertinya gila bagi saya. Itu tidak masalah. Jujur. Kernel - di mana semua pemikiran keras harus pergi - praktis identik antara dua bahasa; Anda bisa menulis makro untuk editor favorit Anda untuk melakukan 99% dari pekerjaan untuk bangkit antara OpenCL dan CUDA. Itu harus seperti itu; mereka adalah kontrol tingkat rendah dari jenis perangkat keras yang akhirnya mirip. Setelah Anda mengetahui cara menulis kernel penting Anda di {OpenCL, CUDA}, itu sepele untuk port mereka ke {CUDA, OpenCL}.

Kode host boilerplate yang harus Anda tulis juga serupa, tetapi CUDA membuat case sederhana tetap sederhana. Itu sebabnya kami mengajar CUDA di pusat kami; Anda dapat langsung menulis kode kernel, sedangkan kami harus menghabiskan 1-2 jam saja sepanjang hari kami hanya menjelaskan hal-hal peluncuran kernel untuk OpenCL.

Tetapi bahkan di sana perbedaannya tidak begitu penting; begitu Anda mulai melakukan hal yang lebih rumit (kernel asinkron pada banyak GPU), keduanya sama-sama rumit dan sekali lagi Anda bisa melakukan terjemahan baris demi baris dari satu ke yang lain.

Jika itu OpenCL vs pendekatan berbasis direktif - OpenACC atau HMPP atau sesuatu - itu mungkin (semoga?) Akan menjadi cara yang baik untuk pemrograman jenis arsitektur ini di masa depan, di mana Anda bisa mendapatkan 90% kinerja untuk 10% dari pekerjaan. Tapi pilihan mana yang akan "menang" masih harus dilihat dan saya tidak akan merekomendasikan menghabiskan banyak waktu bekerja dengan mereka dulu.

Jadi saya akan mengatakan, antara CUDA atau OpenCL memilih bahasa yang nyaman untuk Anda dan menggunakannya, dan jangan terlalu khawatir tentang hal itu. Bagian yang berharga - mencari tahu cara menguraikan masalah Anda menjadi kode SIMD paralel-besar-besaran untuk core kecil dengan memori sangat sedikit - akan menjadi sangat mudah dibawa-bawa antara model pemrograman.

Jika Anda menggunakan perangkat keras NVIDIA - dan mungkin memang demikian - maka saya biasanya merekomendasikan CUDA - poin Matt Knepley tentang perpustakaan itu mematikan. Jika tidak, maka OpenCL.

Apakah Anda harus menginvestasikan waktu Anda dalam mengembangkan perangkat lunak berbasis OpenCL adalah pertanyaan yang hanya dapat Anda jawab. Jika sepertinya memiliki potensi untuk menyelesaikan masalah yang Anda hadapi saat ini, dan tidak ada solusi terbuka lainnya, tindakan terbaik Anda mungkin adalah mengambil risiko menerapkan proyek kecil bersamanya.

Jika itu berjalan dengan baik, Anda dapat mencobanya dengan proyek-proyek yang lebih besar dan seterusnya sampai Anda membangun kepercayaan yang cukup untuk membakukannya, atau membuangnya demi beberapa solusi lain (yang mungkin merupakan solusi Anda sendiri, solusi terbuka lain atau bahkan solusi berpemilik lainnya).

Hal yang luar biasa tentang pergerakan open source adalah karena Anda memiliki sumber, Anda memiliki semua yang Anda butuhkan untuk melakukan fork proyek jika perlu. Bahkan jika komunitas itu sendiri tidak memberikan Anda fasilitas yang Anda butuhkan, tidak ada yang menghentikan Anda untuk menerapkan fasilitas itu sendiri. Juga, jika Anda menginginkan fasilitas itu, ada kemungkinan yang berbeda bahwa pengguna lain mungkin menginginkannya, jadi akan sangat menghargai jika Anda menyumbangkan perubahan itu kembali ke proyek inti.

Tidak hanya itu, tetapi jika Anda membuatnya lebih baik dari sudut pandang Anda, itu mungkin membuatnya lebih baik untuk orang lain, mendorong mereka untuk mengirimkan perangkat tambahan mereka sendiri dan pada akhirnya membuat perangkat lunak lebih baik untuk semua orang.

Akhirnya, ya ini adalah jawaban yang agak umum untuk pertanyaan yang agak umum. Untuk menjawab lebih lengkap, kami perlu tahu apa yang menjadi perhatian Anda terhadap OpenCL. Apakah itu kedewasaan? Dukungan komunitas? Kemudahan penggunaan? Waktu yang dibutuhkan untuk belajar? Waktunya berkembang? Mengubah prosedur Anda? Ketika Anda bertanya tentang Pro dan Kontra, produk apa yang Anda coba bandingkan dengan OpenCL ? Penelitian apa yang sudah Anda lakukan? Fitur apa yang Anda butuhkan untuk mendukung lingkungan komputasi heterogen Anda?

Satu PRO besar adalah jumlah vendor di balik OpenCL. Saya memiliki pengalaman anekdotal tentang hal ini, setelah bertemu dengan kelompok riset yang menghabiskan banyak waktu dan upaya untuk mengembangkan kode CUDA yang cukup rumit untuk sistem bertenaga NVIDIA. Setahun kemudian setelah kode dikembangkan, kelompok riset mendapatkan akses ke sistem berbasis AMD yang lebih besar dan lebih cepat tetapi mereka tidak dapat menggunakannya karena mereka tidak memiliki sumber daya (manusia) untuk mem-porting kode tersebut.

Sekalipun set inti fitur CUDA dan OpenCL hampir identik (seperti yang ditunjukkan oleh @JonathanDursi dengan baik), jika pengembang asli bukanlah yang ditugaskan dengan tugas mengubah kode, keseluruhan proyek porting dapat memakan waktu.

Namun, ada beberapa ketidakcocokan resmi antara CUDA dan OpenCL. Kebanyakan CUDA mendukung templat c ++ sementara OpenCL belum secara resmi mendukungnya. Namun, ada upaya yang dilakukan oleh AMD untuk mengembangkan ekstensi ke OpenCL dengan dukungan untuk templat dan fitur C ++ lainnya, informasi lebih lanjut dalam posting ini dari AMD dev central . Saya berharap revisi OpenCL di masa depan dapat menambahkan pekerjaan ini.

Pada titik ini (awal 2012), pustaka mengagumkan yang ditautkan oleh @MattKnepley adalah sumber tertutup atau gunakan templat, sehingga pustaka tersebut tidak akan tersedia untuk perangkat keras selain NVIDIA, setidaknya dalam waktu yang bersamaan.

Untuk seseorang yang belajar gpu-computing, saya akan mengatakan bahwa OpenCL C bisa sangat sulit, karena ada banyak detail yang mengalihkan pelajar dari ide-ide dasar, sedangkan CUDA lebih sederhana dan lurus ke depan. Namun, ada alat yang membuat OpenCL jauh lebih mudah dipelajari dan digunakan seperti PyOpenCL (pembungkus python untuk opencl) yang membawa semua gula python ke OpenCL (perhatikan bahwa ada juga PyCUDA). Sebagai contoh, demo PyOpenCL untuk menambahkan dua array hanya di bawah 25 baris dan itu termasuk: pembuatan array pada host dan perangkat, transfer data, pembuatan konteks dan antrian, kernel, cara membangun dan menjalankan kernel , dapatkan hasilnya dari GPU dan membandingkannya dengan numpy (lihat tautan di bawah).

PyOpenCL - http://mathema.tician.de/software/pyopencl

PyCUDA - http://mathema.tician.de/software/pycuda

Untuk pemrogram gpu berpengalaman, di sini saya setuju dengan @JonathanDursi, CUDA dan OpenCL pada dasarnya sama dan tidak ada perbedaan walikota. Selain itu, kerja keras mengembangkan algoritma yang efisien untuk GPU sangat independen dalam hal bahasa, dan dukungan OpenCL dari vendor dan dokumentasi sekarang jauh lebih matang daripada 2 tahun yang lalu. Satu-satunya poin yang masih membuat perbedaan, adalah bahwa NVIDIA benar-benar melakukan beberapa pekerjaan hebat dengan dukungan mereka kepada komunitas CUDA.

OpenCL memiliki manfaat tambahan yang dapat dijalankan pada CPU dan sudah didukung oleh Intel dan AMD. Jadi Anda tidak perlu mengubah kerangka algoritme Anda jika Anda ingin memanfaatkan core CPU yang tersedia. Bukan pendapat saya bahwa OpenCL adalah solusi terbaik untuk satu aplikasi berorientasi CPU / multicore karena kernel yang dioptimalkan CPU mungkin terlihat sangat berbeda dari kernel yang dioptimalkan GPU. Namun, dalam pengalaman saya, pengembangan CODE tidak mendapat manfaat karena dapat berjalan pada CPU.

Saya pikir OpenCL saat ini menderita karena kurangnya "juara". Misalnya, jika Anda mengunjungi situs NVIDIA sekarang (16/12/2011), Anda memiliki beberapa foto gaya "Ken Burns Effect" di halaman pembuka yang berfokus pada sisi ilmiah / industri dari komputasi GPU, dan ~ 1 / Keempat opsi navigasi Anda mengarahkan Anda ke hal-hal yang mungkin akan berakhir di CUDA. Produsen yang menjual server dan workstation "komputasi GPU" menjual solusi NVIDIA.

Penawaran yang bersaing dari ATI dicampur dengan situs AMD umum, lebih sulit ditemukan, dan tidak banyak ditampilkan dalam solusi pihak ketiga. Solusi itu, dan kemampuan untuk melakukan pemrograman berbasis OpenCL tentu ada, tapi itu meninggalkan persepsi - setidaknya dalam pikiran saya, tetapi dalam pikiran beberapa orang lain saya sudah bicara dengan - bahwa sponsor perusahaan besar platform OpenCL sudah " keluar dari bidang ". Orang-orang yang menggunakan OS X misalnya, mungkin semua terlalu sibuk berspekulasi tentang apakah workstation Apple atau tidak akan ada dalam satu tahun untuk memiliki keyakinan pada mereka mendorong komputasi OpenCL GPU.

Faktor yang paling penting adalah bahwa CUDA akan tetap didukung hanya oleh perangkat keras NVIDIA.

Jadi, jika Anda ingin membuat perangkat lunak yang kuat dan portabel, OpenCL adalah satu-satunya pilihan. Paling-paling Anda dapat membangun di sekitar beberapa perpustakaan yang saat ini didukung CUDA dan berharap mereka akan diperluas melalui OpenCL di masa depan dengan menarik kode Anda dengannya.