OpenCL: MQL5'te dahili uygulama testleri - sayfa 4
Ticaret fırsatlarını kaçırıyorsunuz:
- Ücretsiz ticaret uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Kayıt
Giriş yap
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Hesabınız yoksa, lütfen kaydolun
Doğru anladıysam, 1 GPU çok güçlü bir aracı mı? Bu durumda işlemci aracılarını devre dışı bırakmak mümkün müdür (videoya göre düşük hızları nedeniyle)? Ve tekrar ediyorum: çapraz ateş olmadan iki ATI'ye sahip olmak mümkün mü?
AMD, OpenCL için Crossfire kullanılmasını kesinlikle önermemektedir - çünkü crossfire ile aslında iki GPU vardır, ancak CAM sürücüsü TEK grafik görevini aralarında böler. Aksine, OpenCL 1.1 için ekran kartı sürücüsünün iki GPU arasında bir OpenCL işini paylaşması için henüz bir yol yoktur (yukarıya bakın).
nvidia SLI'da da aynı.
OpenCL'nin dahil edilmesi bulutta bilgi işlem maliyetini nasıl etkiler?
GPU'lu bir temsilcinin maliyeti, GPU'su olmayan bir temsilcinin maliyetinden daha yüksek olacaktır, çünkü ilk ajanın tahmini süresi önemli ölçüde daha kısa olacak mı?
Yerel makinede yalnızca bir aracıya GPU verileceği gerçeğini hesaba katarsak, aynı yerel makinedeki farklı aracıların maliyetinin farklı olacağı (ve önceden hesaplandığı) anlamına mı gelir?
OpenCL'nin dahil edilmesi bulutta bilgi işlem maliyetini nasıl etkiler?
GPU'lu bir temsilcinin maliyeti, GPU'su olmayan bir temsilcinin maliyetinden daha yüksek olacaktır, çünkü ilk ajanın tahmini süresi önemli ölçüde daha kısa olacak mı?
Yerel makinede yalnızca bir aracıya GPU verileceği gerçeğini hesaba katarsak, aynı yerel makinedeki farklı aracıların maliyetinin farklı olacağı (ve önceden hesaplandığı) anlamına mı gelir?
Varsayılan olarak, başlangıçtaki terminal/aracı, yeteneklerine göre en güçlü GPU cihazını seçer. Şimdiye kadar, MQL5'ten cihaz seçme düşüncesi yok - bu yalnızca kodu karmaşıklaştıracak ve ek hatalara yol açacaktır.
Bunun yerine, her bir fiziksel GPU'yu ayrı ajanlara otomatik olarak dağıtma biçiminde daha güzel bir fikir var, bu da onların tam potansiyelleriyle kullanılmalarını sağlayacak.
Diyelim ki, GPU'lu aracılarda GPU'suz olandan 20 kat daha hızlı optimize eden EX5 (OpenCL kullanarak) var.
Bulutta optimizasyona başlıyoruz . Açıkçası, optimizasyonu öncelikle fiziksel bir GPU'nun olduğu aracılarda çalıştırmak (harcanan zaman açısından) daha karlı. Onlara arama seçeneklerinin çoğunu vermek. Bu, PR'lerinin 20 kat daha yüksek olmasına eşdeğerdir. AMA, GPU kullanmadan PR'ları aynıdır. Onlar. yeni PR - PR_gpu hesaplamasını girmek gereklidir.
" Bir görev yürütülürken, test aracısı tarafından yapılan iş, harcanan zamana göre PR'sinin ürünü olarak dikkate alınır. "
Bu formülden, PR_gpu yoksa, buluttaki tüm optimizasyonun GPU'lu maliyeti, onsuzdan daha ucuz olacaktır.
Ne yazık ki, alternatif bir PR hesaplamasının tanıtımı - optimize edilmiş EX5 dosyasının tek bir test geçişi, evrensel kullanımının imkansız olması nedeniyle çok sayıda tuzak içerir.
Bu formülden, PR_gpu yoksa, buluttaki tüm optimizasyonun GPU'lu maliyeti, onsuzdan daha ucuz olacaktır.
Ne yazık ki, alternatif bir PR hesaplamasının tanıtımı - optimize edilmiş EX5 dosyasının tek bir test geçişi, evrensel kullanımının imkansız olması nedeniyle çok sayıda tuzak içerir.
Bilmediğim ayrıntılara girmeden gerçek PR revize edilmezse GPU ile buluta geçmenin bir anlamı yok.
ayrıca, yeni bir konsept tanıtıyorsanız ve onu seviyorsanız), örneğin, bir aracının maliyetini hemen tanımlamak daha iyidir, aksi takdirde bu durumda kullanıcı tarafından bahsettiğimizi tahmin etmeniz gerekir.
Şu anda, PR = Const Koef/referans görevinde harcanan zaman .
Optimizasyonun maliyeti, optimizasyonun sürdüğü süre boyunca hesaplanabilecek referans görevlerin sayısına eşittir. Onlar. hesaplamaların maliyeti, bulutun görevleri aracılar arasında nasıl dağıttığına bağlı değildir. Ancak optimizasyonun son süresi, en önemli gösterge olan doğru dağılıma bağlıdır.
Bulutun, tahmini süreyi azaltmak (ancak maliyeti düşürmemek - CONST) için önceden hesaplanmış PR ile orantılı olarak görevleri aracılar arasında dağıttığı açıktır.
OpenCL ile görevler elbette ilk etapta uygun bir GPU'ya sahip aracılara verilecektir.
hesaplamaların maliyeti, bulutun görevleri aracılar arasında nasıl dağıttığına bağlı değildir.
Ne yazık ki, alternatif bir PR hesaplamasının tanıtımı - optimize edilmiş EX5 dosyasının tek bir test geçişi, evrensel kullanımının imkansız olması nedeniyle çok sayıda tuzak içerir.
Optimize edicinin maliyeti her zaman sabit olduğundan, ancak süresi büyük ölçüde PR'nin (bu görev için) yeterli hesaplamasına bağlı olduğundan, vicdan üzerinde EX5 PR_calculate kodunuza optimizasyon girdisini eklemeye değer olabilir. Optimize edici, algoritmasının özelliklerine dayanarak, görevi için en uygun olan dağıtımsal PR hesaplamasını kendisi yapacaktır.
Örneğin, görev tamamen hesaplamalıysa, PR_calculate'deki vurgu matematik olacaktır.
Görev, büyük veri dizilerini devrederse - bellekle çalışma hızı.
GPU biraz kullanılıyorsa - bunu PR_calculate'inizde görüntüleyin.
GPU, EX5'te her yerde kullanılıyorsa - uygun PR_calculate'i yazın (uygun GPU kullanımıyla).
Bu şema ile buluta güç bağışlayanlar kesinlikle bir şey kaybetmezler ve gücü kullanan bulut, hesaplamalarını önemli ölçüde hızlandırma fırsatı bulur.
PR_hesapla ayarlanmazsa, zaten kabul edilen evrensel referans sorunu kullanılır.
PS PR_calculate yalnızca görevleri bulutta dağıtmak için kullanılır. Maliyeti hesaplamak için her şey aynı PR olarak kalır.
PPS Elbette tuzaklar vardır - önce tüm ücretsiz aracılarda PR_calculate'i çalıştırmalısınız. PR_calculate yanlış yazılmış olabilir - döngülü. Bu nedenle, PR_hesaplanın hesaplanması sırasında klasik PR şemasına göre de para alın. Vb.
Optimize edicinin maliyeti her zaman sabit olduğundan, ancak süresi büyük ölçüde PR'nin (bu görev için) yeterli hesaplamasına bağlı olduğundan, vicdan üzerinde EX5 PR_calculate kodunuza optimizasyon girdisini eklemeye değer olabilir. Optimize edici, algoritmasının özelliklerine dayanarak, görevi için en uygun olan dağıtımsal PR hesaplamasını kendisi yapacaktır.