OpenCl ve bunun için araçlar. İncelemeler ve izlenimler. - sayfa 6
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
Mischek'in bir ay önce bunun hakkında bağırdığından şüpheleniyorum.
OpenCL'nin kapsamını ya yoğun testler için ya da anında çok yoğun paralel hesaplamalar için görüyorum.
Şimdiye kadar buna gerek yok (tüm ağır hesaplamalar indüktörün init() içinde var), ama not aldım.
Alexey, bende de aynı sorun var: Bir şeyi init içine sürüklemeye çalışıyorum ve ancak bundan sonra - gerçek zamanlı olarak :)
Beyinler prosedürel dile döndü. OOP - arzu edilir, ancak - yerel değil.
mql5.com'a bakmayan fanatik dörtlüler için: OpenCL: MQL5'te dahili uygulama testleri
Teşekkürler, kendim görmemiştim. Ama her şey o kadar basit değil.
Ek olarak, Rinat insanların kafasını karıştırıyor: OpenCL 1.0 double float ile iyi çalışabilir, orada tüm üreticiler tarafından desteklenen "genel bir seçenek olarak" sağlanır - AMA SADECE ESKİ KARTLARININ TÜMÜ İÇİN DEĞİL.
http://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/
"Opsiyonel Çift Hassasiyet ve Yarım Kayan Nokta
OpenCL 1.0, isteğe bağlı uzantılar olarak çift kesinlik ve yarım kayan nokta desteği ekler. Çift veri türü, IEEE-754 çift duyarlıklı depolama biçimini onaylamalıdır.
Double kullanmak isteyen bir uygulamanın, çekirdek kodunda herhangi bir çift duyarlıklı veri türü bildirilmeden önce #pragma OPENCL EXTENSION cl_khr_fp64: etkinleştirme yönergesini içermesi gerekir. Bu, yerleşik vektör ve skaler veri türlerinin listesini aşağıdakileri içerecek şekilde genişletecektir:....."
Test cihazında da çalışabilir, ancak OpenCL 1.0 uzmanında çalışmaz ve Rinat'ın dediği gibi "çift şamandıra olmadığı" için değil, tam olarak - yukarıda söylediğim gibi - güvenli olmaması nedeniyle. OpenCL 1.0'da diş açma ve - MT4-5'te akışlarla birdirbir için.
Genel olarak OpenCL'de (ve CUDA'da) çok fazla kafa karışıklığı var. Ne alırsınız? Sonuçta, radyo mühendisleri programlama kavramını değiştirmeyi üstlendiler. Ayrıca demir beyinleri var.
Sorun aynı zamanda sözde "PLATFORM seçimi" ile de olacaktır: bir program, yani bir MT veya bir uzmanın DLL'si veya bir uzman - MUTLAKA, platformu (AMD, Nvidia, Intel) MANUEL OLARAK seçmelidir. bilgisayarda, OpenCL çekirdeğini başlatacak ve ardından bilgisayarda Çoklu GPU varsa, CİHAZI manuel olarak seçecek birkaç ve farklı olabilir. OpenCL'de henüz otomatik platform seçimi yok. Rinat "en güçlünün otomatik seçimi"nden bahsediyor ama nasıl olduğunu bilmiyorum. Orada gösterilen örnekte platform seçimi ve cihaz (GPU, CPU) seçimi yoktur.
Ayrıca, standart olarak birkaç GPU'da veya GPU + CPU'da OpenCL görevlerinin otomatik paralelleştirilmesi hala yoktur. Şöyle söyleyelim: AMD, sürücülerinin/SDK'nın bazı sürümlerinde otomatik dağıtım yaptı, ancak sorunlar vardı ve AMD bu şeyi şimdilik kapattı.
Özetle: MT4-5 için OpenCL programlarını geliştirmek ve etkinleştirmek için bazı manuel çabalara ihtiyaç vardır ve bu nedenle bu, otomatik olarak veya "bir seçenekle yeniden derleme" ile çalışmayacaktır. Hangi sırayla gerçek işte birçok fişle doludur. Bu iyi bir iş olacak ve daha da önemlisi, tekrar etmeme izin verin, ne yazık ki bu DONANIM ODAKLI PROGRAMLAMA, ki bu yanlış. CUDA veya OpenCL için paralel programlarda hata ayıklamak, donanım devrimcilerinin beklediğinden çok daha zor çıktı. Nvidia, 2011 sonbaharındaki CUDA konferansını, sürücü sorunları ve hata ayıklama hatalarıyla ilgili çok sayıda şikayet nedeniyle iptal etti. En son Araç Takımına 1000 yeni işlev daha eklediler - ve en basit program bile sıradan insanlar için çalışmıyorsa veya fişlerle birlikte mi geliyorsa şimdi onunla ne yapmalıyız? Sonuçta, tanımlayıcı araçlarda OpenCL veya CUDA'nın iç mekanizmasının çalışmalarının yarısını bile göstermediler.
Sürücü veya program uyumluluğu nedeniyle takılan bir video kartının GPU hızı (Gigaflop cinsinden) sıfırdır.
Teşekkürler, kendim görmemiştim. Ama her şey o kadar basit değil.
....Evet, genel olarak mesele bu değil. Beşte prosedürel tarzda yazabilirsiniz.
joo: Ve bu gerçek beni caydırdı, akhtung! - Dll'yi çağıran MQL4 betiği, aynı dll ile MQL5 betiğinden daha hızlı çalışır ...
Ama bu rahatsız edici.
MQL5'te OMP için yerel destek alacak ve yapacaklardı. Kodlayıcı için basit ve kızgın olacak ve hiçbir dll yazılmasına gerek yok.
Ve bitmemiş bir demir programlama dilinde yapılmış bu arı sürüsü ... şu ana kadar pek ilham verici değil. Evet, bazı durumlarda yüz kat hızlanma harikadır, ancak programlama kültürü açısından bu bir geri adımdır.
Genel olarak OpenCL'de (ve CUDA'da) çok fazla kafa karışıklığı var. Ne alırsınız? Sonuçta, radyo mühendisleri programlama kavramını değiştirmeyi üstlendiler. Demir beyinleri var.
Sorun aynı zamanda sözde "PLATFORM seçimi" ile de olacaktır: bir program, yani bir MT veya bir uzmanın DLL'si veya bir uzman - MUTLAKA, platformu (AMD, Nvidia, Intel) MANUEL OLARAK seçmelidir. bilgisayarda, OpenCL çekirdeğini başlatacak ve ardından bilgisayarda Çoklu GPU varsa, CİHAZI manuel olarak seçecek birkaç ve farklı olabilir. OpenCL'de henüz otomatik platform seçimi yok. Rinat "en güçlünün otomatik seçimi"nden bahsediyor ama nasıl olduğunu bilmiyorum. Orada gösterilen örnekte platform seçimi ve cihaz (GPU, CPU) seçimi yoktur.
Ayrıca, standart olarak birkaç GPU'da veya GPU + CPU'da OpenCL görevlerinin otomatik paralelleştirilmesi hala yoktur. Şöyle söyleyelim: AMD, sürücülerinin/SDK'nın bazı sürümlerinde otomatik dağıtım yaptı, ancak sorunlar vardı ve AMD bu şeyi şimdilik kapattı.
Özetle: MT4-5 için OpenCL programlarını geliştirmek ve etkinleştirmek için bazı manuel çabalara ihtiyaç vardır ve bu nedenle bu, otomatik olarak veya "bir seçenekle yeniden derleme" ile çalışmayacaktır. Hangi sırayla gerçek işte birçok fişle doludur. Bu iyi bir iş olacak ve daha da önemlisi, tekrar etmeme izin verin, ne yazık ki bu DONANIM ODAKLI PROGRAMLAMA, ki bu yanlış. CUDA veya OpenCL için paralel programlarda hata ayıklamak, donanım devrimcilerinin beklediğinden çok daha zor çıktı. Nvidia, 2011 sonbaharındaki CUDA konferansını, sürücü sorunları ve hata ayıklama hatalarıyla ilgili çok sayıda şikayet nedeniyle iptal etti. En son Araç Takımına 1000 yeni işlev daha eklediler - ve en basit program bile sıradan insanlar için çalışmıyorsa veya fişlerle birlikte mi geliyorsa şimdi onunla ne yapmalıyız? Sonuçta, tanımlayıcı araçlarda OpenCL veya CUDA'nın iç mekanizmasının çalışmalarının yarısını bile göstermediler.
Bir sürücü veya program uyumluluğu nedeniyle asılı kalan bir video kartının GPU'sunun (Gigaflop cinsinden) hızı sıfırdır.
Evet, genel olarak mesele bu değil. Ayrıca beşte prosedürel tarzda yazabilirsiniz.
Ama bu rahatsız edici.
MQL5'te OMP için yerel destek alacak ve yapacaklardı. Basit ve öfkeli ve herhangi bir dll yazmanıza gerek yok.
Ve bitmemiş bir demir programlama dilinde yapılmış bu arı sürüsü ... şu ana kadar pek ilham verici değil. Evet, bazı durumlarda yüz kat hızlanma harikadır, ancak programlama kültürü açısından bu bir geri adımdır.
Ayrıca mql4, MQL5'ten daha hızlı çalıştığında gerçeklerle tanıştım. Bu, en sık olarak proger için optimize edilmiş matematiksel işlemlerde kendini gösterir.
Ama bence asıl sorun bu değil, OpenCL MQ'ya giderken ana programlama yoluna paralel giden yolda olduk, belki şu an için bu geri çekilmeyi gerektiriyor, ancak bilgisayar teknolojisinin gelecekteki gelişiminde karmaşık göreceğiz. seri işleme veya paralel işlemenin koda bağlı olacağı ölçeklenebilir sistemler.
Yani yol doğru. Günümüzde paralel bir yaklaşımın uygulanmasını gerektiren çok fazla algoritma olmamasına rağmen, bunun nedeni daha çok matematiksel düşüncenin paralel hesaplamaları uygulayacak donanıma sahip olmaması ve dolayısıyla bu tür algoritmalar oluşturmaya gerek olmamasıdır.
Aleksey, sadece bir gerçeği düşün, tüm matematiksel keşifler 200-300 yıl önce yapıldı, son 100 yılda matematiksel düşünce basitçe olanı cilaladı. Ve sadece Ulusal Meclisin keşfi paralel hesaplamalar için bir talep oluşturdu. Önümüzdeki 100 yıl içinde esasen paralel algoritmalar ortaya çıkacak. Ve onlardan birini de icat edebilirsiniz.
Ayrıca mql4, MQL5'ten daha hızlı çalıştığında gerçeklerle tanıştım. Bu, en sık olarak proger için optimize edilmiş matematiksel işlemlerde kendini gösterir.
Ama bence asıl sorun bu değil, OpenCL MQ'ya giderken ana programlama yoluna paralel giden yolda olduk, belki şu an için bu geri çekilmeyi gerektiriyor, ancak bilgisayar teknolojisinin gelecekteki gelişiminde karmaşık göreceğiz. seri işleme veya paralel işlemenin koda bağlı olacağı ölçeklenebilir sistemler.
Yani yol doğru. Günümüzde paralel bir yaklaşımın uygulanmasını gerektiren çok fazla algoritma olmamasına rağmen, bunun nedeni daha çok matematiksel düşüncenin paralel hesaplamaları uygulayacak donanıma sahip olmaması ve dolayısıyla bu tür algoritmalar oluşturmaya gerek olmamasıdır.
Aleksey, sadece bir gerçeği düşün, tüm matematiksel keşifler 200-300 yıl önce yapıldı, son 100 yılda matematiksel düşünce basitçe olanı cilaladı. Ve sadece Ulusal Meclisin keşfi paralel hesaplamalar için bir talep oluşturdu. Önümüzdeki 100 yıl içinde esasen paralel algoritmalar ortaya çıkacak. Ve onlardan birini de icat edebilirsiniz.
Hayır, tamamen umutsuz değilsin. :)
Merhaba.
Aferin MQ, GPU'daki hesaplamalar için destek tanıtımı olarak bu tür hemoroidlerle (onlar için) uğraşmaktan korkmadılar. Hemoroid, her şeyden önce, temelde yeni teknolojilerin (herhangi bir) tanıtılmasının, ilk çiftte bir bütün olarak platformun güvenilirliğini ve hata toleransını azalttığı gerçeğiyle bağlantılıdır. Ancak geleceğin paralel hesaplamaya ait olduğunun farkındalar ve er ya da geç bu yönde bir şeyler yapmak zorunda kalacaklardı (ilk adım zaten atıldı - bulut).
PS Merhaba Nikolai . Neden kayboldu? - kişisel olarak grev.
Bu bir gerçek değil, çünkü Bu doğru değil. Matematiğin niteliksel gelişimi hiçbir zaman kesintiye uğramamıştır.
Evet ve paralel hesaplamalar yalnızca NN'den çok uzakta gereklidir, ayrıca daha sıradan görevler de vardır - örneğin video kodlama veya oluşturma.
Ancak MQ'nun genel hareket vektörü elbette cesaret verici olamaz.