Paralelleştirme hesaplamasında CPU çekirdekleri her çekirdeğe nasıl dağıtılır?
Soru sormadan önce doğru anladığımdan emin olmak istiyorum. Bazı kişilerin Mathematica'daki bazı işlevlerin otomatik olarak çoklu çekirdek kullanacağını söylediğini gördüm (paralelleştirdiklerimizden bahsetmiyorum, benzerlerine atıfta bulunuyorum NIntegrate), bu yüzden 2 çekirdeğim varsa, tekli çekirdekten daha hızlı olacağını düşünüyorum. çekirdek. Yani sorularım, aşağıdaki gibi bir kodum olup olmadığıdır:ParallelTable[NIntegrate[x, {x, 1, 3}], {loop, 1, 3}]
Sanırım üç çekirdek piyasaya sürülecek. 4 çekirdeğim varsa, bu dört çekirdek her bir çekirdeğe nasıl dağıtılır? (Her çekirdeğin fonksiyon entegrasyon özelliğine göre çoklu çekirdek kullanabileceğini düşündüğüm için)
Yanıtlar
Hoşgeldin noo-b, m.se, M hakkında sonsuz öğrenme için harika bir topluluktur!
Sanırım birkaç yanlış varsayımınız var:
Birincisi, tek iş parçacıklı işlemler bile birden çok çekirdek üzerinden işleyebilir. İyi bir işletim sistemi bundan kaçınmaya çalışır, ancak birkaç saniyede bir başka bir çekirdeğe geçebilir veya yükü birden çok çekirdeğe bölebilir - ikincisi genellikle uzun bir süre için olmasa da.
İkinci olarak, NIntegrate'in tüm girdiler için her zaman paralel olacağını varsayamazsınız ve özellikle de NIntegrate'in tüm hesaplama süresi boyunca paralel olacağını varsayamazsınız. Yalnızca başlatma için veya sonunda veya aradaki seçili görevlerde paralel olabilir. Örneğin,
Do[Do[NIntegrate[x,{x,1,3}],{3}],{100000}]
Çekirdek kullanıma bakarsanız (değil: basit bir görev yöneticisinde olduğu gibi işlem kullanımına) - Linux'taysanız, en üstte çalıştırabilir ve 1'e basabilirsiniz - bunun zamanın% 99'unu tek çekirdek. Bir süre sonra çekirdeği değiştirebilir, ancak o zaman bu çekirdek için% 99 görürsünüz . Bu yüzden NIntegrate'in birden çok çekirdek üzerinde iş parçacığı olduğunu görmüyorum, en azından her zaman değil (belki de saniyeler için). Bu, farklı NIntegrate girdileri için farklı olabilir, ancak bu basit örnek, NIntegrate'in her zaman paralel olmadığını ve tüm hesaplama süresi boyunca paralel olmadığını gösterir.
M paralellik çerçevesi ile bu değişmez, bu gerçekten bir işletim sistemi meselesidir. ParallelTable (ve kardeşler) ile yalnızca daha fazla işlemden işleme görevlerini ve çekirdeklere yönelik işletim / s zamanlamalarının tamamen işletim sistemine bağlı olduğunu sağlarsınız. Dolayısıyla, paralel süreçleri anlamaktan çekirdeklere atamayı gerçekten "geri alamazsınız".
biraz teğet:
Scala, Java veya C # 'da (veya diğer birçok dilde) görevleri iş parçacığı düzeyinde planlayabilirsiniz. Ancak o zaman bile, izleri çekirdeklere programlamak o / s'ye bağlıdır. Java'nın vmstat'ı ile iş parçacıklarının harika bir görselleştirmesine sahip olursunuz (zamanla büyüyen yatay çubuklar, her iş parçacığı başına bir tane), bence gerçekten ilgilendiğiniz şey iş parçacıklarında iş parçacıklarının nasıl çalıştığıdır, iş parçacıklarının çekirdeklere nasıl atandığı değil . Bununla birlikte, iş parçacıkları bir donanım kavramı değil, bir yazılım kavramıdır, bir çekirdek iş parçacığının ne olduğunu bilmez. Ama bir iş parçacığı analizinin size eşzamanlılığı anlamanız için daha fazla şey söyleyeceğini düşünüyorum çünkü çekirdeklere atama ve çekirdek değiştirme ve her çekirdek için iş yükü yüzdeleri tamamen o / s'ye bağlıdır.
Otomatik olarak birden çok çekirdek kullanan bazı işlevler vardır. Kaç çekirdek kullandıkları, içindeki bazı ayarlar tarafından belirlenir SystemOptions["ParallelOptions"].
Bu tür işlevleri alt çekirdeklerde kullanırsanız, bunlar yalnızca tek bir çekirdek kullanır. Bunu bakarak doğrulayabilirsiniz ParallelEvaluate@SystemOptions["ParallelOptions"]. Tüm iş parçacığı sayılarının alt çekirdeklerde 1'e ayarlandığına dikkat edin.
Genel olarak, açık paralelleştirme (gibi ParallelTable), bazı işlevlerin yerleşik paralelleştirilmesi kadar verimli değildir. Dolayısıyla, darboğazınız zaten paralel olarak çalışan bir işlevse, o zaman ParallelTableveya ilgili işlevlerle ek paralelleştirme uygulamak onu yavaşlatacaktır (veya en azından kontrol ettiğim tüm durumlarda yavaşlatmıştır).