OpenCl ve bunun için araçlar. İncelemeler ve izlenimler. - sayfa 28

 
joo : Sonuçta, yazarının bir konu başlatıcı olduğunu yazıdan asla tahmin edemezsiniz.... Neden bir şube açtığı belli değil.

Birkaç yıl içinde gelecek - bu konuyu hatırlayın.

Şahsen benim için bu konu çok faydalı oldu - topikstarter kırılgan ruhumu hesaplamaların doğruluğunun azalmasının dehşetiyle korkutmaya başladığında bile.

 
Windows'u yıkmaya gitti))) dotnet hiçbir şekilde konmak istemiyor
 
Reshetov :

Genetik algoritmanın etkin olduğu MT5'teki optimizasyon modu çok yavaştır. MT4'te bir Expert Advisor'ı test ettim ve optimize ettim. Çift çekirdekte optimizasyon süresi 5 dakikayı geçmez (MT4'te yalnızca bir çekirdeğin yer aldığı kül kütüğü, ancak diğer görevler artık karışmaz, çünkü bunlar ikinci çekirdekte gerçekleştirilebilir). MT5 için aynı Uzman Danışmanı yeniden yazdı. Optimizasyon için ayarlayın. Optimizasyon süresi bir saatten fazla, tam olarak neredeyse 2 saat. Bir fark var?

Şimdi bir fark yok.

Daha kesin olmak gerekirse, şimdi MetaTrader 5 açık fiyatlarla test yaparken bile liderliği alıyor: MetaTrader 4 ve MetaTrader 5'te test hızının karşılaştırılması

Söz verdiğimiz gibi, çubukları açmak için test modunu basitleştirdik ve yüksek hızlı bir mod yaptık.

 

Pekala, iki yıl oldu.

EA sürümü CUDA üzerinde çalışır. MT4 altında. Şimdiye kadar sadece test modunda. Şimdiye kadar nVidia'nın vaat ettiği hesaplamaların ivmesini elde etmek mümkün olmadı.

Burada iki sorun:

1. Programları yeniden yazma hızını abartan veya genellikle belgelerini YANLIŞ olarak hazırlayan veya programlamanın bazı temel özelliklerini kökten değiştiren nVidia'nın kendisi.

2. Algoritmaların GPU altında paralelleştirilmesi beklenenden çok daha fazla zaman alıyor. Tse dilindeki 20 yılı aşkın deneyimime dayanarak DLL'den CUDA-DLL'ye bir program taşımaya başladığımda, nVidia vaatlerinin 3'e bölünmesi ve bunların verdiği algoritma aktarım süresinin 3 ile çarpılması gerektiğine inanıyordum. .

Ancak buradaki genel kuralın şu olduğu ortaya çıktı: tüm NVIDIA vaatleri TEN'e bölünmeli ve programları C'den CUDA'ya aktarmak için tahmini süre 10 ile çarpılmalıdır.

Not: GPU üzerindeki hızlandırıcının prensiplerini anlıyorsanız, algoritmayı C'den CUDA'ya ÜÇ HAFTA İÇERİSİNDE aktarabilirsiniz. Ve bunu doğrudan yapabilirsiniz - sadece yapıyı kontrol etmek için. Yani programınız video kartındaki yüzlerce veya BİNLERCE küçük işlemciden YALNIZCA BİRİSİ tarafından yürütülecektir. Bu, merkezi süreçten yaklaşık 70 (yetmiş) kat daha YAVAŞ çalışır. Evet, yavaş ama işe yarıyor.

Daha sonra, çok daha fazla çaba sarf ederek programınızı paralelleştirmeye başlayabilirsiniz. Merkezi işlemden 4-5 kat daha yavaş veya sadece 2-3 kat daha hızlı çalışıyor.

Ancak ALGORİTMA'nızı AMATS'ta yürütülecek şekilde global olarak yeniden yapmak için, HATALARI tekrar ediyorum ve dünyadaki tüm ünitelerde öğrettikleri gibi tutarlı bir şekilde değil - bu kolay bir iş değil.

Açıklığa kavuşturuyorum - Çoklu iş parçacığı ilkesine göre geleneksel bir sıralı algoritmayı paralelleştirmek için - bu zor, ancak olağandışı değil. Bu bir şey. Aynı şekilde GPU'da 5-10 kat hızlanma elde ediyorsunuz. Ancak yüzlerce ve binlerce GPU işlemcisini yüklemek ve nVidia tarafından vaat edilen 100x hızlanmayı elde etmek için sıralı bir algoritmayı patlamalı algoritmaya dönüştürmek (sözlüğümde daha iyi bir kelime yok) - bu bir sorun olabilir.

Ama aynı zamanda çözülebilir. An meselesi.

Ama sonra Kırım, Bendera ve benzeri var ....

3. MetaTrader-4 tarafında, CUDA için DLL programı yazarken herhangi bir sorun yoktur.

Sorun, nVidia yazılım geliştiricilerinin (2500 kişi) MetaTrader-4-5'te benimsenen çoklu iş parçacığı modeliyle temel anlaşmazlığıdır. Ayrıca Nvidia, CUDA 3.2'den 4.0+ sürümüne geçerken bu seçeneği kökten değiştirdi. Ayrıca, onlara bunun neden böyle olduğunu sormaya başlarsanız (Metatrader-4'te ve diğer yüzlerce çok iş parçacıklı programda olduğu gibi), ancak bu hale geldi, o zaman yanıt olarak sadece onlardan duyacaksınız "Temelde anlamadınız . KanzEption'ımız" .

Bir yerde bunu zaten duydum .... ve son zamanlarda .....

4. Yeni bir algoritmayı C'den CUDA'ya aktarmak, C'den doğrudan evrensel OpenCL'ye aktarmaktan çok daha kolaydır, bu yüzden bu yolu öneririm. Ayrıca, kelimenin tam anlamıyla bugün, nVidia, teorik olarak, yeni Maxwell serisi GPU'larda ve bazı işletim sistemlerinde, belleğin birleştirilmesi ve ortadan kaldırılması nedeniyle programlama miktarını önemli ölçüde azaltmanın mümkün olacağı CUDA-6'yı resmi olarak tanıtmalıdır. CPU ve GPU arasındaki transfer işlemleri.

 

İyi?

Ve ne?

Hiç kimse bununla ilgilenmiyor mu?

Bir yıl boyunca, tek bir soru veya yazı yok.

Ancak Nvidia bununla ilgileniyor: bu ve diğer forumlardaki şikayetlerimi okudu, muhtemelen sanat konseyini topladı, her taraftan ovuşturdu - ve tüccarların da insan olduğuna ve ticaret terminalinin de bir program olduğuna karar verdiler, aldılar CUDA'nın en son sürümünde sunulan ve yüksek düzeyde çok iş parçacıklı CUDA programları oluşturmak için özel bir derleyici anahtarı vardır.

http://devblogs.nvidia.com/parallelforall/gpu-pro-tip-cuda-7-streams-simplify-concurrency/

tür dizesi

nvcc --varsayılan-iş parçacığı başına akış ./pthread_test.cu -o pthreads_per_thread

 

Ne yazık ki, Xeon Phi bile havalanmadı. Ve geleneksel programlamaya daha yakındır.

Evrensel hesaplamalarda güce ihtiyaç duyanlar, artık genel amaçlı çok işlemcili sistemlerde fazla zorlanmadan kolayca elde edebilirler. Intel işlemcilerdeki çekirdek sayısı oldukça hızlı artıyor.

Örneğin bizim sunucularımız 40 çekirdekli, hatta 20 çekirdekli ve DDR4 belleğe sahip çalışan bir bilgisayarım bile var. 3Ghz'de 40 çekirdekli xeon'lardaki bir sunucu, tek bir kod satırının yeniden yazılmasına gerek kalmadan 56 veya daha fazla çekirdekli düşük frekanslı Xeon Phi'yi benzersiz şekilde işler.

 
Renat :

Evrensel hesaplamalarda güce ihtiyaç duyanlar, artık genel amaçlı çok işlemcili sistemlerde fazla zorlanmadan kolayca elde edebilirler. Intel işlemcilerdeki çekirdek sayısı oldukça hızlı artıyor.

Örneğin bizim sunucularımızda 40 çekirdek var, hatta 20 çekirdekli ve DDR4 belleğe sahip çalışan bir bilgisayarım bile var. 3Ghz'de 40 çekirdekli xeon'lardaki bir sunucu, tek bir kod satırının yeniden yazılmasına gerek kalmadan 56 veya daha fazla çekirdekli düşük frekanslı Xeon Phi'yi benzersiz şekilde işler.

Biraz yanılıyorsunuz (2 kez. Her ikisi de.). Prensip olarak, daha önce de düşündüm, özellikle GPU programlamaya başlarken.

(1). Ana bilgisayar CPU'sunda "Evrensel hesaplamalarda güç" SADECE en basit algoritmalar için kolayca elde edilebilir. Bu, çoğu OpenMP ve GPU programcısı için fişin olduğu yerdir. CUDA'lı video kartları yüz milyonlarca sattı ve bunun için programlar - sadece 300 kadar. Finans için - sadece 7-8 kadar (işe yaramaz kitaplık koleksiyonlarını saymazsak).

İşte nVidia web sitesinde tam liste:

http://www.nvidia.com/object/gpu-applications.html?cFncE

(MT4 ticaret terminali için dünyanın ilk ticari olarak temin edilebilen CUDA-hızlandırılmış Uzman Danışmanı *henüz* orada değil.).

Bu liste birkaç yıldır değişmedi.

Niye ya? Evet, ana bilgisayar CPU'sunda kolayca parçalardan oluşan karmaşık bir uyarlamalı algoritmanın programlanması çok az olduğu için, yine de KATLANMASI gerekir. Ve bu o kadar basit bir mesele değil çünkü:

a). CUDA-OpenCL GPU modelinin özellikleri ve sınırlamaları (farklı boyutlardaki çekirdekler sırayla başlatılmalıdır).

b). GPU ve ana işlemci arasında PCI veri yolu üzerinden herhangi bir veri aktarımı, hızdaki tüm kazancı öldürür. Ve karmaşık uyarlanabilir algoritmalarda, onlarsız yapılamaz.

(2). "tek bir kod satırının yeniden yazılmasını gerektirmeden" - bu aynı zamanda yalnızca basit algoritmalar içindir. GPU'ya gerçek bir alternatif olan OpenMP'nin gizemli bir şekilde çalışması, yani bazen işe yaraması ve bazen de çöp vermesi durumu daha da kötüleştiriyor. Sadece bir yere bir pragma çizgisi ekleyerek, algoritmanın hemen bu şekilde paralelleşeceği bir yanılsamadır. Doğrudan çok uzak. Karmaşık bir algoritmada, veriler ve paralel akışlar arasında bir grafik oluşturmadan yapamayacağınız beklenmedik ilişkiler ortaya çıkar.

GPU tamamen farklı bir konudur. İlk başta daha çok iş var, AMA program senkronizasyon açısından DAİMA DOĞRU çalışıyor. Ayrıca, CUDA için yeniden yazılmış bir program (çekirdek yazmadan bile) GERÇEKTEN bir satır pragma ile OpenMP'ye çevrilir - ve gerçekten işe yarar. Ancak bundan sonra OpenMP'ye aktarmak anlamsızdır - CUDA-OpenCL için çekirdek eklemek çok daha umut verici ve güvenilirdir. Şaşırtıcı bir şekilde, CUDA GPU çekirdekleri kısa, anlaşılır ve güvenilirdir.

Mutlak hız ve güvenilirlik açısından, ana bilgisayar CPU'sunun GPU'ya karşı şansı yoktur.

=Özellikle finans piyasaları ve forex, dünya çapındaki devasa süreçlerin YÜKSEK sıkıştırılmış versiyonudur.

= Bu nedenle, fiyat tahmini için agloritm basit olamaz. Bu nedenle, şu anda uyarlanabilir ve mecazi anlamda istatistiksel olmalıdır.

= Bu nedenle, böyle iyi bir algoritmada simülasyon ve uyarlanabilir geri bildirim olmadan, hiçbir yerde.

= Bu nedenle, sipariş verme amacıyla, ana bilgisayar CPU'su hala sığabiliyorsa (yani hızı hala yeterli), o zaman test ve optimizasyon için GPU olmadan çalışmak neredeyse imkansızdır.

 

İki kez yanıldığımı söyledin ve sonra kanıt kisvesi altında tamamen alakasız bir şey verdin.

Aşağıdakiler konusunda haklıyım (hemen belirtildi):

  1. Evrensel (x86 CPU tabanlı) hesaplamalarda/algoritmalarda CUDA/OpenCL'ye geçmenin bir anlamı yoktur. x86 mimarisi GPU'yu tüm cephelerde kırar: daha düşük geliştirme maliyeti, yeniden eğitim maliyeti, yeniden yazma maliyeti (bu sadece bir felaket), nihai performans daha yüksek, karmaşıklık daha düşük, yüksek frekanslı çekirdeklerin sayısı artıyor, temel bellek sarsıntılarla büyüyor - DDR4.
  2. Eşlik eden karmaşıklıklar (linux tabanlı ortam) nedeniyle çok çekirdekli bir Xeon Phi girişimi bile öldü, temel işlemcinin yüksek frekanslı çekirdeklerinde saf bir artış kaybetti.


OpenMP'den hiç bahsetmedim. Benim bakış açıma göre, OpenMP "pısırıklar için gümüş bir kurşun". Gerçek performans için savaşıyorsanız, OpenMP ile saçmalıkları atın ve başlangıçta doğru / yerel çok iş parçacıklı kodu elle yazın, profilini çıkarın ve maksimuma getirin.

GPU hesaplama için yeterli program olmadığını kendiniz kanıtladınız. Çoğu GPU yazılımı, şifre kırıcılar ve aptal madenciler de dahil olmak üzere yalnızca en basit durumlardır (oyunları tartışmıyoruz).

Benim düşünceme göre CPU ve altında yatan altyapı oldukça hızlı bir şekilde gelişiyor ve gerçekte uygulanan gerçek uygulamalarda gerçek performansta GPU'yu geride bırakıyor. 3-4 yıl önce GPU'nun potansiyeline inanmak mümkündü, ama şimdi her şey netleşti.

 
Renat :

İki kez yanıldığımı söyledin ve sonra kanıt kisvesi altında tamamen alakasız bir şey verdin.

Aşağıdakiler konusunda haklıyım (hemen belirtildi):

  1. Evrensel (x86 CPU tabanlı) hesaplamalarda/algoritmalarda CUDA/OpenCL'ye geçmenin bir anlamı yoktur. x86 mimarisi GPU'yu tüm cephelerde kırar: daha düşük geliştirme maliyeti, yeniden eğitim maliyeti, yeniden yazma maliyeti (bu sadece bir felaket), nihai performans daha yüksek, karmaşıklık daha düşük, yüksek frekanslı çekirdeklerin sayısı artıyor, temel bellek sarsıntılarla büyüyor - DDR4.
  2. Eşlik eden karmaşıklıklar (linux tabanlı ortam) nedeniyle çok çekirdekli bir Xeon Phi girişimi bile öldü, temel işlemcinin yüksek frekanslı çekirdeklerinde saf bir artış kaybetti.


OpenMP'den hiç bahsetmedim. Benim bakış açıma göre, OpenMP "pısırıklar için gümüş bir kurşun". Gerçek performans için savaşıyorsanız, OpenMP ile saçmalıkları atın ve başlangıçta doğru / yerel çok iş parçacıklı kodu elle yazın, profilini çıkarın ve maksimuma getirin.

GPU hesaplama için yeterli program olmadığını kendiniz kanıtladınız. Çoğu GPU yazılımı, şifre kırıcılar ve aptal madenciler de dahil olmak üzere yalnızca en basit durumlardır (oyunları tartışmıyoruz).

Benim düşünceme göre CPU ve altında yatan altyapı oldukça hızlı bir şekilde gelişiyor ve gerçekte uygulanan gerçek uygulamalarda gerçek performansta GPU'yu geride bırakıyor. 3-4 yıl önce GPU'nun potansiyeline inanmak mümkündü, ancak şimdi her şey netleşti.

1. Çekirdeklerin büyüme oranını ana bilgisayar CPU'dan tahmin edersek, önümüzdeki yıllarda , iyi bir ekran kartıyla BUGÜN gibi, sayılarının 3000 çekirdeğe ulaşması pek olası değildir . Ve sonuçta video kartının her bir çekirdeği yaklaşık 1 GHz'de çalışıyor. Yani ana işlemci GPU ile rekabet edemeyecek. Ancak bu, yalnızca ve yalnızca bu 3000 çekirdeği iş ile yüklemekle kalmayıp, aynı zamanda günümüzün donanım GPU mimarisinin tüm tuzaklarını BYPASS yapabilen iyi bir program olması şartıyla sağlanır. Ve bugün ortalama bir video kartındaki GDDR5 belleğinin video hızı yaklaşık 150 GB / s'dir. Her tür DDR4 (25 GB / sn) belleğin hala orada kesilmesi ve kesilmesi gerekiyor.

Bir ana işlemci, 4GHz ve 25 Gb/sn bellekte bile 40-60 çekirdeğiyle nasıl rekabet edebilir?

2. Phi gibi herhangi bir egzotik, bir video kartı gibi gerekli desteğe ve çok yönlülüğe sahip değildir. Bu nedenle öldüler.

3. Çoklu iş parçacığının doğrudan programlanması ihtiyacı hakkında - evet, size katılıyorum, ancak bu zor bir yol. HEMEN karmaşık YENİ bir uyarlamalı algoritmayı çok iş parçacıklı bir sürümde yazmak çok zordur. Ve burada, tabiri caizse, evrimsel olarak çalışmak gerekiyor. Ve sonra, gerçekten çok fazla olduğunda (her türlü gecikme varken) Windows'un çoklu iş parçacıklarını ne kadar kötü yönettiğini söylemek bana düşmez. Bu nedenle, işletim sisteminde bile, sözde fiberler - basitleştirilmiş akışlar buldular.

Sonuç: GPU'dan daha ucuz, daha umut verici ve daha güvenilir bir şey yoktur.

 
İlgilenen herkesin zaten bildiği bir teoriyi yeniden anlatıyorsunuz.

Gerçek şu ki, genel görevlerde cpu, faktörlerin bir kombinasyonu açısından daha hızlıdır. Şimdi netleşti. Gümüş mermi gpu kategorik olarak hedefe ulaşmıyor.
Neden: