OpenCL'in Geleceği?


22

OpenCL programlama paradigması, heterojen bilişim için telif ücretsiz bir standart açar. OpenCL'i temel alan yazılımlar geliştirmek için zamanımızı harcayalım mı? Artılar ve eksiler?


CUDA'da daha zor kodlayabilirsiniz. OpenCL'in yalnızca yapıları desteklediği C ++ sınıflarınız var. Yani CUDA biraz daha olgun. Gelişmiş şeylere ihtiyacınız yoksa, OpenCL'e geçeceğim.
vanCompute

Yanıtlar:


19

Soru çok geniş ve gerçekten cevaplanamayacak kadar belirsiz. Bununla birlikte, OpenCL'e karşı, nadiren vurgulanan bilimsel hesaplama açısından dikkate değer bir nokta görüyorum. Şimdiye kadar, OpenCL için açık kaynak kodlu altyapı kütüphaneleri üretmek için hiçbir çaba sarf edilmedi, oysa CUDA'nın birçok mükemmel seçeneği var:

Bunun, OpenCL'i gerçekten inciteceğine inanıyorum çünkü evlat edinmenin en büyük kolaylaştırıcısı yüksek kaliteli açık kütüphaneler.


3
İlginç nokta; Özellikle CUDA derleyicisinin lisansı çok açık olmadığından (bu adamları üst üste kurduğumu farz ediyorum), oysa ki (lisanstan çıkabildiğim kadarıyla) iddialı bir programcının yolunda hiçbir şey durmayacaktı. Tamamen açık kaynak kodlu bir OpenCL çözümü geliştirmek isteyen ...
Erik P.

2
@ JackPoulson Ayrıca OpenCL kütüphanelerinin eksikliğinden de şaşırdım, ancak CUDA sebebi açık. Gerçekten harika insanları işe almanın ve faydalı kütüphaneler geliştirmenin arkasına kaynaklar koymuşlar.
Matt Knepley

6
Kütüphaneler hızlı doğar ve ölür; standartlar uzun ve acı verir.
saat

6
Göz ardı edilmemesi gereken ViennaCL var .
Aron Ahmadia

4
@mbq Bilimsel kütüphanelerin uzun ömürleri vardır ve uygulama kadar düşünme üzerinde de büyük etkisi vardır. Tanık CHARMM, BLAS, RELAP, GEANT, vb.
Matt Knepley

16

OpenCL vs ne?

Eğer soru OpenCL'e karşı CUDA ise, bu soruya çok fazla elle sıkıldığını görüyorum ve bu bana delilik gibi geliyor. Önemli değil. Dürüst. Çekirdekler - zor düşüncenin gitmesi gereken yerler - pratik olarak iki dil arasında aynıdır; OpenCL ve CUDA arasında sıçrama yapmak için çalışmanızın% 99'unu yapmak için favori editörünüz için makrolar yazabilirsiniz. Bu şekilde olmalı; Son derece benzer donanım türlerinin düşük seviye kontrolü. Önemli çekirdeklerinizi {OpenCL, CUDA} 'da nasıl yazacağınızı öğrendikten sonra, onları {CUDA, OpenCL}' e taşımak önemsizdir.

Yazmanız gereken kazan plakası ana bilgisayar kodu da benzerdir, ancak CUDA basit vakaları basit tutar. Bu yüzden merkezimizde CUDA'yı öğretiyoruz; doğruca çekirdek kodunu yazmaya başlayabilirsiniz, oysa 1-2 saatlik kursumuzu 1-2 saat harcamak zorunda kalacağız.

Fakat orada bile fark bu kadar önemli değil; daha karmaşık bir şey yapmaya başladığınızda (çoklu gpus'ta asenkron çekirdekler), ikisi de aynı şekilde karmaşıktır ve yine bir satırdan diğerine bir satır satır çeviri yapabilirsiniz.

Eğer OpenCL'e veya direktif temelli yaklaşımlara - OpenACC veya HMPP veya başka bir şeyse - bunlar muhtemelen (umarım?) Gelecekte bu tür mimarileri programlamanın iyi bir yolu olacak, bunun için performansın% 90'ını alabilirsiniz. İşin% 10'u. Ancak hangi seçeneğin "kazanacağı" görülmeye devam ediyor ve henüz onlarla çalışmak için fazla zaman harcamanızı önermem.

Bu yüzden, CUDA veya OpenCL arasında sizin için uygun bir dil seçin ve onu kullanın ve çok fazla endişelenmeyin. Değerli kısım - çok az hafızalı küçük çekirdekler için sorununuzu büyük ölçüde paralel SIMD koduna nasıl ayıracağınızı bulmak - programlama modelleri arasında kolayca taşınabilir olacak.

NVIDIA donanımını kullanıyorsanız - ve muhtemelen kullanıyorsunuz - o zaman genellikle CUDA'yı öneririm - Matt Knepley'nin kütüphanelerdeki noktası sona erdi. Eğer değilseniz, o zaman OpenCL.


1
Tek farkın çekirdek olduğunu ve çekirdeklerin aynı olduğunu söylüyorsunuz, ancak daha sonra kazan plakası daha basit olduğu için CUDA kullandığınızı söylüyorsunuz. Ben CUDA klişe daha basit olduğunu kabul ederseniz ancak OpenCL boilerplate, örneğin yardımcı olabilir kütüphaneler vardır code.google.com/p/clutil ve github.com/hughperkins/OpenCLHelper (uyarı: OpenCLHelper benimkisi)
Hugh Perkins

7

OpenCL'e dayalı bir yazılım geliştirmek için zamanınızı harcamanız gerekip gerekmediği , yalnızca yanıtlayabileceğiniz bir sorudur. Şu anda karşı karşıya olduğunuz sorunları çözme potansiyeline sahip görünüyorsa ve başka hiçbir açık çözüm bulunmuyorsa, en iyi eylem yolunuz muhtemelen küçük bir projeyi uygulama riskini almaktır.

İşler iyi giderse, daha büyük projelerle deneyebilirsiniz, ya da standart hale getirmek için yeterince güven inşa edinceye kadar ya da başka bir çözümden (kendi özel çözümünüz olabilir, başka bir açık çözüm ya da hatta başka bir özel çözüm).

Açık kaynak hareketi ile ilgili harika şey , kaynağa sahip olduğunuzdan, eğer gerekliyse projeyi doldurmak için ihtiyacınız olan her şeye sahip olmanızdır. Topluluğun kendisi size ihtiyacınız olan olanakları sağlamazsa bile, bu tesisleri kendiniz uygulamanıza engel olacak hiçbir şey yoktur. Ayrıca, bu tesisleri kullanmak isteseniz, diğer kullanıcıların da isteyebileceği belirgin bir olasılık var, bu yüzden bu değişiklikleri çekirdek projeye geri kazandırdıysanız seviniriz.

Sadece bu değil, aynı zamanda bakış açınızdan daha iyi yaparsanız, başkaları için daha iyi hale getirebilir, kendi geliştirmelerini sunmalarını ve nihayetinde yazılımı herkes için daha iyi hale getirmelerini teşvik edebilir.

Son olarak, evet, bu genel bir soruya oldukça genel bir cevaptır. Daha iyi cevap vermek için OpenCL'deki endişelerinizin ne olduğunu bilmemiz gerekir. Vade mi? Topluluk desteği? Kullanım kolaylığı? Öğrenmek için gereken zaman? Geliştirme zamanı? Prosedürlerini değiştiriyor musun? Avantaj ve Dezavantajları sorduğunuzda, OpenCL'i başka hangi ürünlerle karşılaştırmaya çalışıyorsunuz ? Ne tür bir araştırma yaptın? Heterojen bilgi işlem ortamınızı desteklemek için hangi özelliklere ihtiyacınız var?


6

Büyük bir PRO, OpenCL'in ardındaki satıcı sayısıdır. NVIDIA destekli bir sistem için oldukça karmaşık bir CUDA kodu geliştirmek için çok fazla zaman ve çaba harcayan bir araştırma grubuyla tanışmış olmakla ilgili bazı anekdot deneyimlerim var. Kod geliştirildikten bir yıl sonra, araştırma grubu daha büyük ve daha hızlı bir AMD tabanlı sisteme erişebildi, ancak kodu taşımak için (insan) kaynakları olmadığı için kullanamadılar.

CUDA ve OpenCL'in temel özelliklerinin kümesi neredeyse aynı olsa bile (@JonathanDursi'nin belirttiği gibi), orijinal geliştirici kodu dönüştürme görevine atanmış değilse, tüm taşıma projesi oldukça zaman alabilir.

Ancak, CUDA ve OpenCL arasında resmi olarak bir takım uyuşmazlıklar var. En dikkat çekici şekilde CUDA, c ++ şablonlarını desteklerken, OpenCL henüz resmi olarak desteklememektedir. Bununla birlikte, AMD'nin şablonlara ve diğer C ++ özelliklerine destek veren OpenCL'in bir uzantısını geliştirmek için çaba göstermesi , bu yazıda AMD dev central'dan daha fazla bilgi almak için bir çaba var . Umarım OpenCL'in gelecekteki bir gözden geçirmesi bu çalışmayı ekleyebilir.

Zamanın bu noktasında (2012'nin başlarında), @MattKnepley'in bağlandığı harika kütüphaneler kapalı kaynak veya şablon kullanıyorlar, bu nedenle en azından ortalama zamanda NVIDIA dışındaki donanımlar için uygun olmayacaklar.

GPU hesaplamayı öğrenen biri için OpenCL C'nin oldukça zor olabileceğini söyleyebilirim, çünkü öğrenciyi temel fikirlerden ayıran birçok ayrıntı vardır, oysa CUDA daha basit ve anlaşılırdır. Bununla birlikte, OpenCL'i öğrenmek ve kullanımı PyOpenCL (opencl için python sarmalayıcı) gibi kullanımı daha kolay hale getiren araçlar vardır; bu da tüm python şekerini OpenCL'e getirir (ayrıca bir PyCUDA olduğunu da unutmayın). Örneğin, iki dizi eklemek için PyOpenCL demosu 25 satırın hemen altındadır ve şunları içerir: ana bilgisayar ve aygıt üzerinde dizilerin oluşturulması, veri aktarımı, bağlam ve sıranın oluşturulması, çekirdek, çekirdeğin nasıl oluşturulması ve yürütülmesi , sonuçları GPU'dan almak ve bunları numpy ile karşılaştırmak (aşağıdaki bağlantılara bakın).

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

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

Tecrübeli gpu-programcıları için, burada @ JonathanDursi, CUDA ve OpenCL ile aynı fikirdeyim ve kesinlikle belediye başkanı farklılıkları yok. Dahası, GPU'lar için verimli bir algoritma geliştirmenin zor işi, dilden bağımsızdır ve OpenCL satıcılardan ve belgelerden destek almaktadır, şimdi 2 yıl öncesine göre daha olgunlaşmıştır. Hâlâ fark yaratan tek nokta, NVIDIA'nın CUDA topluluğuna destekleriyle gerçekten harika işler yapmak olduğudur.

OpenCL, CPU'larda çalışabilmesi ve Intel ve AMD tarafından zaten desteklenmesinin ek avantajına sahiptir. Bu nedenle, mevcut herhangi bir CPU çekirdeğinden yararlanmak istiyorsanız algoritmik çerçevenizi değiştirmeniz gerekmez. CPU için optimize edilmiş bir çekirdeğin GPU için optimize edilmiş bir çekirdekten önemli ölçüde farklı görünebileceği için OpenCL'nin tek bir CPU / çok çekirdekli odaklı uygulama için en iyi çözüm olduğu kanısında değilim. Ancak, benim deneyimlerime göre, CODE geliştirme CPU üzerinde çalışabilmekten fayda sağlar.


5

Bence OpenCL şu anda bir "şampiyon" eksikliğinden muzdarip. Örneğin, şu anda NVIDIA sitesini ziyaret ederseniz (12/16/2011), açılış sayfasındaki GPU hesaplamanın bilimsel / endüstriyel yönüne odaklanan birkaç "Ken Burns Effect" tarzı çekim yaptınız ve ~ 1 / Navigasyon seçeneklerinin dördüncüsü, muhtemelen CUDA'da bitecek olanlara işaret ediyor. "GPU hesaplama" sunucuları ve iş istasyonlarını satan üreticiler, NVIDIA çözümleri satmaktadır.

ATI'nin sunduğu rekabet teklifleri, genel AMD sitesiyle karıştırılıyor, bulması daha zor ve üçüncü parti çözümlerde çok fazla yer almıyor. Bu çözümler ve OpenCL tabanlı programlama yapma yeteneği kesinlikle var, ancak bir fikir bıraktı - en azından aklımda, fakat konuştuğum diğer bazı kişilerin kafasında - OpenCL platformunun büyük kurumsal sponsorlarının zaten sahip olduğu " alandan çıkın ". Örneğin, OS X kullanan insanlar, bir Apple iş istasyonunun OpenCL GPU hesaplamayı zorlayan bir inanca sahip olmak için bir yıl içinde bile var olup olmayacağı konusunda spekülasyon yapmakla meşguller.


4

En önemli faktör, CUDA'nın yalnızca NVIDIA donanımı tarafından desteklenecek olmasıdır.

Bu nedenle, sağlam ve taşınabilir bir yazılım yapmak istiyorsanız, OpenCL tek seçenek. En fazla şu anda CUDA destekli bazı kütüphaneleri oluşturabilir ve gelecekte kodunuzu çekerek OpenCL’den daha fazla yararlanabileceklerini umabilirsiniz.


Hiç net değil. Birçok insanın benimsemesinden sonra ortaya çıkan kesin standartlar vardır.
Matt Knepley

@MattKnepley Lütfen, NVIDA bile CUDA'yı standart olarak zorlamaya çalışmıyor; Yapsalar bile, temelde OpenCL ile özdeş bir şeyle sonuçlanacaklarından bahsetmiyorum.
mbq

1
Aslında, tam tersi olacak. OpenCL, CUDA'dan (çoğu zaten var olan, nereden geldiğini düşünüyorsun?) Tüm güzel şeyleri benimsemeye ve şu anda oradaki daha sakıncalı şeylerden kurtulmaya son verecek.
Matt Knepley
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.