Öncelikle beni bu konuya yönlendirdiği için Aron Ahmadia'ya teşekkür etmek istiyorum.
Bilimsel kodda OpenCL'e gelince: OpenCL düşük seviyeli bir API anlamına gelir, bu nedenle makul bir üretkenliğe ulaşmak için bu işlevselliği bir şekilde sarmak çok önemlidir. Ayrıca, birkaç hesaplama çekirdeği dahil edilir edilmez, OpenCL çekirdeği ve bellek tutamaçlarının bir uygulama içinde yoğun bir şekilde geçirilmesi gerekiyorsa kod ÇOK kirli olabilir. OCLTools'u tanımıyorum, bu yüzden bu konuda yararlı olup olmadıklarını söyleyemem.
ViennaCL'e gelince: ViennaCL'in başkanıyım, bu yüzden yakın zamanda kütüphanede çalıştım. :-) ben biraz daha büyük bir kapsamda, yani ViennaCL CUDA tabanlı matematik kütüphaneleri Cusp karşı ve de zirve ile bir karşılaştırma için istek davranırız aşağıdaki MAGMA . Sürmekte olan birçok gelişme olmasına rağmen (en azından bizim tarafımızda), sadece mevcut devlet göz önünde bulundurulur.
İşlevsellik . MAGMA, normal fonksiyon arayüzleri aracılığıyla yoğun matrisler için BLAS işlevselliği sağlar. Bu fonksiyonelliğin çoğu, operatör aşırı yükleri ve diğer sözdizimsel şekeri kullanarak ViennaCL 1.2.0 ile de sağlanır.
Aynı üç yinelemeli çözücü (CG, BiCGStab, GMRES) cusp ve ViennaCL ile birlikte verilmektedir. Ön koşullandırma seti özellikle farklılık gösterir: Cusp, diyagonal, SA-AMG ve çeşitli Bridson ön koşullandırma cihazları sunar. ViennaCL tamamlanmamış LU faktörlendirmeleri, çapraz önkoşullayıcılar ve son zamanlarda çeşitli AMG lezzetleri ve Seyrek Yaklaşık Ters önkoşulları sunar. Bildiğim kadarıyla, tüm doruk önkoşulları tamamen GPU'da çalışıyor, ViennaCL özellikle CPU tabanlı hesaplamalar için kurulum aşamasında güveniyor. Şu anda, seyrek matris formatlarının sayısı doruğa daha fazladır: COO, CSR, DIA, ELL, HYB, ViennaCL 1.2.0 ise COO ve CSR sağlar.
ViennaCL ile sağlanan ve MAGMA ya da doruğun bir parçası olmayan birçok ek özellik vardır: Yapısal matris türleri (Circulant, Hankel, vb.), Hızlı Fourier dönüşümü, yeniden sıralama algoritmaları (örn. Cuthill-McKee) ve doğrusal cebir için sargılar diğer kütüphanelerden türler.
Performans. ViennaCL'deki daha büyük özellikler ve donanım desteği, CUDA tabanlı uygulamalara kıyasla tipik olarak daha düşük performans maliyeti ile birlikte gelir. Bu, kısmen CUDA'nın NVIDIA ürünlerinin mimarisine göre uyarlanmış olmasından kaynaklanırken, OpenCL bir anlamda farklı çok çekirdekli mimariler arasında makul bir uzlaşmayı temsil ediyor.
Genel olarak, ViennaCL şu anda MAGMA'dan daha yavaş, özellikle BLAS düzey 3'te. Bunun nedeni, ViennaCL'in (yoğun doğrusal cebir yerine seyrek) farklı odaklanması ve dolayısıyla MAGMA'daki yüksek optimizasyon derecesidir. Özellikle BLAS seviye 3 işlemleri MAGMA'da şu anda oldukça hızlı.
Benzer şekilde, genel olarak biraz daha iyi bir genel performans sağlar. Bununla birlikte, seyrek matris işlemleri genellikle bellek bant genişliği sınırlı olduğundan, farklılıklar, veri kurulumuna ve benzerlerine kıyasla oldukça küçüktür ve genellikle önemsizdir. Ön koşullandırıcı ve parametrelerinin seçimi genellikle, genel yürütme süresi üzerinde, seyrek matris-vektör çarpımlarındaki herhangi bir performans farkından daha büyük bir etkiye sahiptir.
Taşınabilirlik . Donanım taşınabilirliğine gelince, ViennaCL, OpenCL sayesinde tüm büyük üreticilerin CPU'larını ve GPU'larını kullanabilir. Buna karşılık, doruğa ve MAGMA uygun bir NVIDIA GPU’ya güveniyor.
ViennaCL yalnızca başlıktır, çok çeşitli C ++ derleyicilerinde derlenebilir ve GPU desteği gerekirse yalnızca OpenCL kitaplığına bağlanması gerekir. Prensip olarak, ViennaCL'deki jenerik algoritmalar herhangi bir OpenCL bağlantısı olmadan da kullanılabilir; oysa cusp ve MAGMA, derleme için NVIDIA derleyicisini ve yürütmek için hedef sistemdeki CUDA kütüphanesini gerektirir. MAGMA ayrıca, yeni bir sistemi bulmak veya kurmak için bazen zor olabilecek bir BLAS kütüphanesi gerektirir.
API . MAGMA, BLAS işlevselliği için BLAS tarzı işlev arayüzleri sağlar. Cusp'ın C ++ arayüzü de BLAS'tan bazı fonksiyonlar kullanır, ancak operatör aşırı yüklenmez. ViennaCL'deki çoğu arayüz kasıtlı olarak Boost.uBLAS ile benzer olduğundan ve operatör aşırı yükleri gibi sözdizimsel şekere sahip olduğundan, ViennaCL'in Boost.uBLAS gibi kullanılması da amaçlanmıştır. Bu nedenle, sadece önceden tanımlanmış bir dizi işlem ve algoritmanın çağrılmasının yanı sıra, standart olmayan algoritmalar kullanılsa bile, tamamen CPU tabanlı yürütmeden GPU koduna geçiş yapmak mümkün. Özel bir OpenCL çekirdeğinin gerekli olması durumunda, kendi OpenCL çekirdeğinizi ViennaCL'e entegre etmek için bir çerçeve de vardır. Böylece, ViennaCL daha doğru hedefliyorGPU'da yeni algoritmalar uygulamak için gereken zamanın en aza indirilmesi anlamında yüksek verimlilik . Bu tasarruflar, doruğa ve MAGMA'ya kıyasla (varsa) herhangi bir performans cezasından daha ağır basabilir. ( Ünite testinde , kod geliştirme zamanının bilimdeki değerli bir kaynak olduğu da belirtilmiştir.)
Karşılaştırma sırasında kesinlikle çok sayıda ideolojik sorun (örneğin CUDA ve OpenCL, BLAS arayüzü ve operatör aşırı yüklemeleri) var, ancak tartışmaları ilk sorunun kapsamı dışında.