OpenCL: gerçek problemler - sayfa 6

[Roffild]

Mathemat : Henüz test cihazında test etmedim.

O zaman neden doğrulanmamış saçmalık yayınladınız?

Sanırım test cihazında hala OpenCL kullanan tek kişi benim... denedim...

[Sceptic Philozoff]

Roffild :

O zaman neden doğrulanmamış saçmalık yayınladınız?

Sanırım test cihazında hala OpenCL kullanan tek kişi benim... denedim...

Bu saçmalık değil, tatmin edici bir uygulama.

Bir kez daha: hizmet masasına yazın ve ne istediğinizi doğrulayın. Bunu haklı çıkaramıyorsan, bu senin sorunun.

Bu makaleleri yazarken, test cihazında OpenCL kullanımıyla ilgili konuşma henüz ciddi anlamda başlamadı. Uygulama bu zamana atıfta bulunur.

Beyni açmanızın zamanı geldi, çünkü 0.35300 ms özellikle clEnqueue[Read/Write]Buffer ()'ı ifade eder ve çekirdeğin içindeki global bellek erişimini değil.

Bu komut, MQL5 için OpenCL uygulamasında mevcut değildir. Neden bahsediyorsun?

[Vladimir Gomonov]

Roffild :

Yazılarımı tekrar oku.

Ana kriter: MQL kodunun 1 onay işareti için "OpenCL stilinde" yürütülmesi, süreyi aşmalıdır = Number_of_Buffers * 0.35300 ms

MQL'deki algoritmanın hızını mikrosaniyelik bir doğrulukla (1000 mikrosaniye = 1 milisaniye) bulmak için test cihazında ve Total_Time / Number_Ticks'te (en üstteki mesajım) birkaç kez çalıştırmanız gerekecek.

Arabellek gecikmesi olmasaydı, kodum testi ~30 saniyede geçti - bu, MQL "OpenCL stilinden" (55 saniye) ~2 kat ve normal koddan (320 saniye) ~11 kat daha hızlıdır.

Başka hangi kriterler var?

Şimdi her şeyi bırakıp tekrar okuyacağım. OpnCL ile ilgili forumdaki tüm yazılarımı tekrar okumanızı istemiyorum .. :) Ve orada, bu arada, tüm ana kriterler açıklanmış ve tartışılmıştır.

Ana kriter t_alg/t_mem oranıdır, burada t_alg çekirdek algoritmasını hesaplamak için algoritmik olarak optimize edilmiş zamandır, t_mem uzak (*) belleğe erişim zamanıdır. Bu kriter ne kadar büyük olursa, OpenCL kullanarak hızlanma olasılığı da o kadar büyük olur. Başka bir deyişle, hesaplamalar "ağır" ve dizilerin cihaza ve geriye aktarımı ne kadar az olursa, o kadar umut verici olur.

(*) uzak bellek = her türlü "kayıtlı olmayan" bellek (kayıtlı bellek çok hızlıdır), örneğin (1) aygıtın genel belleği kayıtlı bellekten çok daha yavaştır, ancak (2) aygıtın harici belleğinden (işlemci) çok daha hızlıdır. VERİ DEPOSU).

[Roffild]

Mathemat :

Bu saçmalık değil, tatmin edici bir uygulama.

Bir kez daha: hizmet masasına yazın ve ne istediğinizi gerekçelendirin. Bunu haklı çıkaramıyorsan, bu senin sorunun.

Bir kez daha: 2013.10.17 23:17 tarihli hata # 865549 ve geliştiriciler bilgilendirildi, ancak herhangi bir şeyi düzeltmeleri pek mümkün değil. Muhtemelen bir tanesi, optimizasyon sırasında tüm işlemciyi askıya almamak için bu kısıtlamayı özel olarak ekledi.

Ancak makalelerde bununla ilgili hiçbir kelime yok!

matematik :

Beyni açmanızın zamanı geldi, çünkü 0.35300 ms özellikle clEnqueue[Read/Write]Buffer ()'ı ifade eder ve çekirdeğin içindeki global bellek erişimini değil.

Bu komut, MQL5 için OpenCL uygulamasında mevcut değildir. Neden bahsediyorsun?

Eh ... ve OpenCL hakkında makaleler veriyorsunuz ...

Bildiğiniz gibi: clEnqueueReadBuffer = CLBufferRead ve clEnqueueWriteBuffer = CLBufferWrite ve bunlar eşzamanlı olarak da adlandırılır.

Bilgi buradan başlar

MetaDriver : Ana kriter, t_alg/t_mem oranıdır; burada t_alg, çekirdek algoritmasını hesaplamak için algoritmik olarak optimize edilmiş zamandır, t_mem, uzak (*) belleğe erişim zamanıdır. Bu kriter ne kadar büyük olursa, OpenCL kullanarak hızlanma olasılığı da o kadar büyük olur. Başka bir deyişle, hesaplamalar "ağır" ve dizilerin cihaza ve geriye aktarımı ne kadar az olursa, o kadar umut verici olur.

Bu yalnızca bir performans optimizasyon kriteridir. Gönderilerimden önce arabelleklerin aktarım hızı hakkında yaklaşık bir sayı yoktu.

[Roffild]

İnsanlar, daha fazla bir şey kanıtlamadan önce şunu düşünün: buradan başlayarak ve özellikle hakkında üç gönderi hakkında

mql5 : Spesifik olarak, bu örnekte, OpenCL kullanmanın avantajı, kopyalama arabelleklerinin ek yükü tarafından tüketilir.

Ve sonra, çekirdeğin kendisini optimize etmeye odaklandınız ve gönderilerim arabelleklerle ilgili.

[Sceptic Philozoff]

Roffild : Bildiğiniz gibi: clEnqueueReadBuffer = CLBufferRead ve clEnqueueWriteBuffer = CLBufferWrite ve aynı zamanda eşzamanlı olarak da adlandırılırlar.

MQL5 için OpenCL uygulamasının gerçek API üzerinde yalnızca bir sarmalayıcı olduğunu uzun zamandır biliyordum. Ve bu arada, ikinci makalesinde, çalışma grubunun (çalışma grubunun) boyutunu belirlemek için yeterli fırsatın olmadığını yazdı. Servis masasına bir talepte bulundum ve bir süre sonra yaptılar.

CLBuffer[Read/Write] öğesinin clEnqueue[Read/Write]Buffer ile benzer olduğunu da biliyorum, ancak bu işlevler hiç de aynı değil: farklı sözdizimlerine sahipler .

Ama neden OpenCL for MQL5'te mevcut olmayan clEnqueueXXX işlevlerinden bahsettiğinizi anlamıyorum.

Ne istediğini anlamaya çalışacağım.

Roffield :

Beyni açmanızın zamanı geldi, çünkü 0.35300 ms özellikle clEnqueue[Read/Write]Buffer ()'ı ifade eder ve çekirdeğin içindeki global bellek erişimini değil.

İkincisi, çekirdeğin kendisini optimize ederek çözülür, ancak birincisi bir demir sınırlamasıdır ve beyin burada yardımcı olmayacaktır.

İyi. İddialar kim? Video kartının üreticisine mi?

[Roffild]

Mathemat : CLBuffer[Read/Write]'ın clEnqueue[Read/Write]Buffer'a benzer olduğunu da biliyorum, ancak bu işlevler hiç de aynı değil: farklı sözdizimlerine sahipler .

Ama neden OpenCL for MQL5'te mevcut olmayan clEnqueueXXX işlevlerinden bahsettiğinizi anlamıyorum.

Evet, hiçbir fark yok. Muhtemelen şöyle bir şey var:

 template < typename T>
cl_int BufferWrite(cl_mem buffer, const T *ptr)
{
        size_t bufsize;
        errcode = clGetMemObjectInfo(buffer, CL_MEM_SIZE, sizeof (bufsize), &bufsize, 0 );
         return (errcode = clEnqueueWriteBuffer(enqueue, buffer, CL_TRUE, 0 , bufsize, ptr, NULL , NULL , NULL ));
}
template < typename T>
cl_int BufferRead(cl_mem buffer, T *ptr)
{
        size_t bufsize;
        errcode = clGetMemObjectInfo(buffer, CL_MEM_SIZE, sizeof (bufsize), &bufsize, 0 );
         return (errcode = clEnqueueReadBuffer(enqueue, buffer, CL_TRUE, 0 , bufsize, ptr, NULL , NULL , NULL ));
}

Yani sözdizimi hakkında da icat yapamazsınız. Ve 3. argüman = CL_TRUE zaten onaylandı.

matematik :

İkincisi, çekirdeğin kendisini optimize ederek çözülür, ancak birincisi bir demir sınırlamasıdır ve beyin burada yardımcı olmayacaktır.

İyi. İddialar kim? Video kartının üreticisine mi?

İddia, özellikle makale yazarlarına yöneliktir, bu en önemli sınırlama hakkında pratik bir veri yoktur! (Test edene kadar değil.)

[Vladimir Gomonov]

Roffild :

İddia, özellikle makale yazarlarına yöneliktir, bu en önemli sınırlama hakkında pratik bir veri yoktur! (Test edene kadar değil.)

Daha fazla makale okumayın. Ve hiçbir şikayet olmayacak. ;)

--

Ne yapıyorsun? Bir makalede bilinmeyen verileri nasıl sağlayabilirsiniz? Cihazdan / cihaza veri iletiminin gecikmesinin büyük olması ve forumda bir kereden fazla hesaba katılması gerekir. Belirli rakamlar belirli ekipmana bağlıdır. Valla ben kendim test ettim aferin. Dışarıdaki insanlar (kendim dahil) bazen çeşitli donanımların yeteneklerini ve sınırlamalarını değerlendirmek için test kodu gönderir. Diğer insanlardan sonuçları paylaşmalarını isterler, insanlar bunu sıklıkla yaparlar (buna saygı duyulur), aynı zamanda herkes istatistikleri ve neyin hangi kombinasyonlarda işe yaradığını görür. Ardından, sonuçlara odaklanan biri donanımı yeniden satın alır veya kod yazma yaklaşımlarını değiştirir. Ve sen, lanet olsun... Ne istiyorsun? Peki, Sportloto'ya bir şikayet yazın, belki bu kodunuzun daha hızlı çalışmasını sağlar ...

:)

[Roffild]

Aslında, https://www.mql5.com/ru/forum/13715/page5#comment_646513 adresindeki her şeyi zaten bitirdim, ancak makalelerin yazarları başka bir şey kanıtlamak istedi.

Makalelerinizde belirli ve çok önemli bilgiler yoktur, bu nedenle bitmemiş ve gerçekçi olmayan görevleri açıklamaktadır.

Makalelere bilgi ekleyemezsiniz, ancak bu sayıların bir anlamı yokmuş gibi davranmak aptallıktır.

[Sceptic Philozoff]

Gönderdiğin senaryonun/danışmanın gizli anlamını anlamadım, Roffield . Kod, hafifçe söylemek gerekirse, yanlış anlamalardır.

- cl_khr_fp64 pragması nerede? Çekirdekte double ile hesaplama yaparken gereklidir.

- OnTick() işlevinde , genellikle bir kez hesaplanmış olan, genellikle ilk başlatmaya taşınabilen bu kod parçası neden var?

 uint units = ( uint ) CLGetInfoInteger (hcontext, CL_DEVICE_MAX_COMPUTE_UNITS );
uint global_work_offset[] = { 0 };
uint global_work_size[ 1 ];
uint local_work_size[ 1 ];
global_work_size[ 0 ] = ArraySize (price);
local_work_size[ 0 ] = global_work_size[ 0 ] / units;

- Küresel görev boyutu neden 240 bayt? OpenCL'den herhangi bir fayda elde etmek için çok daha büyük olması gerekir. Eh, en az bir milyon kez - gözle tahmin ederseniz.

- Yerel görevin boyutunu elde etmek için küresel görev neden birim sayısına bölünür? Hem CPU hem de GPU, küresel bir görevi çok daha fazla sayıda alt göreve bölmenize olanak tanır. Ve sizin durumunuzdaki birimler sadece SIMD motorlarının sayısıdır.

Burada, diyelim ki, ekran kartındaki birim sayısı 28'dir (Radeon HD7950). Ancak bu sayı 240'ı tam olarak bölmez. Bu, hesaplamaların önemli bir bölümünün paralel olmayabileceği anlamına gelir.

Sahip olduğum shader sayısı 1792. Sizinki 1440. Haritayı normal şekilde yüklemek için global görevi bu sayıya bölmek daha iyi. Ancak global görevin boyutunu doğru bir şekilde hesaplamanız gerekir. (Ve bölmek değil, çarpmak daha iyidir.)

Ve kartınızın bunca zaman ne düşündüğü hiç belli değil.

Kısacası: kodunuz ne yapmalı?