OpenCL: gerçek problemler - sayfa 7

Yeni yorum
 

1) Pragmalar, desteğin kendisinin bir aktivasyonu değil (düşündüğünüz gibi) bir derleme zamanı destek gereksinimidir. Yani, video kartı destekliyorsa cl_khr_fp64 zaten etkindir.

2) Ve yürütme sırasında dizinin boyutu değişirse? Tabii ki, bu kodda özel olarak çıkarmak mümkündür, ancak bu hava durumunu iyileştirmeyecektir.

AMD CodeXL'de profil oluşturma yaptığımı hemen size bildiririm:

3) Sadece çekirdeğin hesaplama süresini alırsak, GPU üzerindeki herhangi bir paralelleştirilmiş görevin kazancı CPU çekirdek sayısı aşıldığında olacaktır. Yani 8 görev bile hızlandırmak için yeterli.

4) Yerel hesaplama formülüne gelince, benim de birçok sorum var. En büyük kazanç, work_dim=1 ile görevleri tüm video çekirdeklerine yaydığım zaman oldu ve bu BİRİMLER.

Ve öğelerinin sayısını bölmeniz gerektiğinde neden arabellek boyutunu bölüyorsunuz? - Ben de tam olarak bunu yaptım.

Mathemat : Kısacası: kodunuz ne yapmalı?

Hesaplamalar için hazırlık aşamasının anında gerçekleşmediğini ve arabellek aktarımının çok zaman aldığını göstermek için, sıcak görevlerde bile OpenCL kullanmanın tavsiyesi sorgulanır.

Ayrıca test cihazında CPU'nun seçilmediğini de gösterir.

 
Roffild :

Hesaplamalar için hazırlık aşamasının anında gerçekleşmediğini ve arabellek aktarımının çok zaman aldığını göstermek için, sıcak görevlerde bile OpenCL kullanmanın tavsiyesi sorgulanır.

Bu kesinlikle haber değil. Yani, bu konuda öfkeyle bağırmak tamamen saçmalık. Ancak ölçmek tamamen farklı bir konudur, pratik olarak faydalı olabilir.

Ayrıca test cihazında CPU'nun seçilmediğini de gösterir.

Belki bu haklı, ama aynı zamanda reasürans da olabilir. Her durumda, test sürecinin etkinliğini sağlamak için kasıtlı olarak yapıldığından eminim. Daha kesin olarak optimizasyonlar (çünkü çok iş parçacıklı). Burada, test etme ve optimizasyon kavramı açık bir şekilde ve tamamen ayrıysa (parti siyaseti düzeyinde), yani. test cihazını kullanarak bunları farklı boole türleri olarak tanımlayın. Uygun (resmi olarak farklı) yazılım desteği ile. (Bu birçok yönden iyi olurdu ve ben uzun zamandır bu ayrımın/ayrımın destekçisiyim. Farklı optimizasyon ve test başlatma düğmelerine kadar.)

Ardından teorik olarak test sırasında CPU seçimine izin verebilir ve optimizasyon sırasında devre dışı bırakabilirsiniz (bu doğrudur).

 
Roffild : 1) Pragmalar, (düşündüğünüz gibi) desteğin kendisini etkinleştirmekle değil, derlemede destek talep etmekle ilgilidir. Yani, video kartı destekliyorsa cl_khr_fp64 zaten etkindir.

Evet, pragma ile çok ileri gittim. Vidyaha'nız üzerinde çalışmaya devam ederseniz ve kodu kimseye iletmezseniz, sorun değil. Ama eğer biri bunu bir Barts kartından okumak isterse (örneğin 6870), problemler olacaktır. Çekirdek kodu, herhangi bir hata göstermeden çalışmaya çalışacaktır.

4) Yerel hesaplama formülüne gelince, benim de birçok sorum var. En büyük kazanç, work_dim=1 ile görevleri tüm video çekirdeklerine yaydığım zaman oldu ve bu BİRİMLER.

Gerekli değil. Çekirdeğin kendisindeki işi artırmak genellikle çok daha faydalıdır. Bu, veri aktarımıyla ilişkili ek yükü dengelemek içindir.

Ve UNITS'iniz sadece bir dizi SIMD motorudur. Belgelere göre,

local_work_size[] , programın belirtilen OpenCL çekirdeği tarafından gerçekleştirilecek görevlerin bir alt kümesini belirtir. Boyutu , work_items[] boyutuna eşittir ve ortak bir görev alt kümesinin, bölme artıkları olmadan daha küçük alt kümelere kesilmesine olanak tanır. Aslında, local_work_size[] dizisinin boyutları, global work_items[] görev kümesi daha küçük alt kümelere bölünecek şekilde seçilmelidir . Bu örnekte, work_items [40, 100, 320] local_items[10, 10, 10] dizisinden herhangi bir kalıntı bırakmadan birleştirilebildiğinden local_work_size[3]={10, 10, 10} yeterli olacaktır .

SIMD motorlarının sayısı kesinlikle bir donanım sabitidir ve küresel görevi tamamen bölmek zorunda değildir.

Ancak önce küresel görevin kendisini doğru bir şekilde değerlendirmeniz gerekir.

Test cihazındaki CPU'ya gelince - anladım, ikna oldum.

 
MetaDriver :

Bu kesinlikle haber değil. Yani, bu konuda öfkeyle bağırmak tamamen saçmalık. Ancak ölçmek tamamen farklı bir konudur, pratik olarak faydalı olabilir.

Ama nedense bu ölçümlerle uğraşmak zorunda kaldım... "İletim gecikmesi var" yazısını okuduğunuzda ne kadar büyük olduğunu hayal bile edemezsiniz.

Matematik : Ve UNITS'iniz sadece bir dizi SIMD motorudur. Belgelere göre,

SIMD motorlarının sayısı kesinlikle bir donanım sabitidir ve küresel görevi tamamen bölmek zorunda değildir.

Resmi belgeleri daha iyi kullanalım:

CL_DEVICE_MAX_COMPUTE_UNITS cl_uint OpenCL aygıtındaki paralel hesaplama birimlerinin sayısı. Bir çalışma grubu, tek bir hesaplama biriminde yürütülür. Minimum değer 1'dir.
local_work_size
Çekirdek tarafından belirtilen çekirdeği yürütecek bir çalışma grubunu (çalışma grubunun boyutu olarak da adlandırılır) oluşturan çalışma öğelerinin sayısını tanımlayan work_dim işaretsiz değerler dizisine işaret eder.
Bu yüzden sonuçlarım doğru ve AMD CodeXL'de bir çalışmayla onaylandı
 

Konu farklı. Birimlerinizi en azından varil olarak adlandırın, ancak gerçek şu ki: kodunuzdaki birimler genel görevi tamamen bölmez (benim için kesinlikle bölmez: 240/28 tamsayı değildir; sizin için de, çünkü birimleriniz var = 18). Bu bir eklemdir.

İkincisi: burada ve şimdi MQL5 için OpenCL ile çalışıyorsunuz (peki, bu yanlış, ama beni anladınız) ve bu hala Khronos'tan farklı bir OpenCL.

PS Bir köprü oluşturmadım, kendi kendine ortaya çıktı :)

Roffild :
CL_DEVICE_MAX_COMPUTE_UNITS cl_uint OpenCL aygıtındaki paralel hesaplama birimlerinin sayısı. Bir çalışma grubu, tek bir hesaplama biriminde yürütülür. Minimum değer 1'dir.

Diğer kaynaklarda "hesaplama birimlerinin" ne olduğunu okuyun.

Bu arada, ikinci makalemden bir tablo. Tüm bu hesaplama birimlerini (18), akış çekirdeklerini (288), işlem öğelerini (1440), maksimum dalga cephesi/GPU (496) ve iş öğeleri/GPU'yu (31744) anlasaydınız iyi olurdu. Henüz anlayamadım.


 
Mathemat :

Konu farklı. Birimlerinizi en azından varil olarak adlandırın, ancak gerçek şu ki: kodunuzdaki birimler genel görevi tamamen bölmez (benim için kesinlikle bölmez: 240/28 tamsayı değildir; sizin için de, çünkü birimleriniz var = 18). Bu bir eklemdir.

Peki neden bayt 240 sayısını temel aldınız? İki katı bayt olarak mı kesmeye karar verdiniz? Yapabilirsin ve yapabilirsin, ama vidyaha yapamaz. Yani 240/8 = 30 iki katına çıkar.

240 bayt, 30 double tamponun tamamıdır.

Ve "bir tamsayı bölenini al" sadece resmi belgelerden bir öneridir. Ve bu öneri mükemmel çalışmıyor.

VE BİRİMLER hakkında - bu benim şakam değil, OpenCL forumlarından tavsiye. Test ettim ve maksimum hıza ulaştım...

matematik :

İkincisi: burada ve şimdi MQL5 için OpenCL ile çalışıyorsunuz (peki, bu yanlış, ama beni anladınız) ve bu hala Khronos'tan farklı bir OpenCL.

Ve "öteki" nedir?

Kendi uygulamalarınızı ve basit sarmalayıcılarınızı karıştırıyorsunuz. OpenCL MQL, Khronos OpenCL API'si üzerinde yalnızca bir sarıcıdır. OpenCL MQL ve Khronos arasındaki fark hakkında.

 
Mathemat : Bu arada, ikinci makalemden bir tablo. Tüm bu hesaplama birimlerini (18), akış çekirdeklerini (288), işlem öğelerini (1440), maksimum dalga cephesi/GPU (496) ve iş öğeleri/GPU'yu (31744) anlasaydınız iyi olurdu. Henüz anlayamadım.

hesaplama birimleri, çalıştırılacak eşzamanlı görevlerin sayısıdır.

max wavefronts/GPU (496) ve work-ites/GPU (31744) yürütme kuyruğudur.

AMD CodeXL sonunda zaten zayuzat - tüm bu soruları yanıtlıyor.

 
Roffild :

hesaplama birimleri, çalıştırılacak eşzamanlı görevlerin sayısıdır.

max wavefronts/GPU (496) ve work-ites/GPU (31744) yürütme kuyruğudur.

AMD CodeXL sonunda zaten zayuzat - tüm bu soruları yanıtlıyor.

Bir şey anlamayabilirim, öyleyse özür dilerim. ama Alexei'yi şahsen tanıyor musun? Aleksey yoldaş mütevazı, "dürtme" ye tepki vermeyebilir. ama bir şekilde bir şey tarafından değil ..... bir tazı gibi konuşuyorsun, herkesten daha mı akıllı? Akıllı olmak günah değil, kardeşler arasında bununla övünmek ayıp ama...

 

Ben basit bir dostum ve konuya cevap veriyorum.

OpenCL'i gerçekten anlamak istiyorsanız ve sadece varsaymak istemiyorsanız, AMD CodeXL'i kurmanız ve C / C ++ ile kendi sarmalayıcınızı oluşturmanız gerekecektir.

Paketleyicimi gönderebilirim, ancak C/C++ pratiğim olmadığı için bazı mantıksız satırları var.

 
Roffild : Peki neden bayt sayısını 240'a dayandırdınız? İki katı bayt olarak mı kesmeye karar verdiniz? Yapabilirsin ve yapabilirsin, ama vidyaha yapamaz. Yani 240/8 = 30 iki katına çıkar.

240 bayt, 30 double tamponun tamamıdır.

Peki, kendi kodunuza bakın:

 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);
Print( "Глобальная задача = ", global_work_size[ 0 ] );  /// Это я добавил, вышло 240. Но это и так легко подсчитать: 30*double = 240
local_work_size[ 0 ] = global_work_size[ 0 ] / units;

Ve son satırda 240'ı 18'e bölersiniz (bunlar haritanızın birimleridir).

Ve "bir tamsayı bölenini al" sadece resmi belgelerden bir öneridir. Ve bu öneri mükemmel çalışmıyor.

MQL5 OpenCL ile çalışıyoruz. Sitemizin dokümantasyon bölümüne odaklanıyorum. Tabii bir de Khronos'a bakıyorum.

VE BİRİMLER hakkında - bu benim şakam değil, OpenCL forumlarından tavsiye. Test ettim ve maksimum hıza ulaştım...

Diğer parametrelerle maksimumu aldım. Ve ne?

Kolay gelsin. GPU sineklerinde aynı anda çalışan 18 görev, 4-5 CPU iş parçacığında yapılabilecek maksimum sayıdır. Ve x86 öykünmesi üzerindeki CPU çok daha fazla iş parçacığı düzenleyebilir. En azından Intel ise. Eski Pentium G840 (2 çekirdekli), iki ünitede yaklaşık 70 kat hızlanma verdi! Şu anki durumumdan bahsetmiyorum ... nispeten konuşursak, i7 yapıyor.

İyi paralel bir görev ( MetaDriver 'ocl ile ilgili ilk daldan bir komut dosyasına bakın), GPU'da 1000 veya daha fazla hızlanma elde etmenize olanak tanır (MQL5'te CPU üzerinde 1 iş parçacığında yürütmeye kıyasla). Bulamazsan atarım, haritanda test ederim.

OpenCL'i gerçekten anlamak istiyorsanız ve sadece varsaymak istemiyorsanız, AMD CodeXL'i kurmanız ve C / C ++ ile kendi sarmalayıcınızı oluşturmanız gerekecektir.

Tamam, bir göz atacağım, teşekkürler.

12345678
Yeni yorum