Bagaimana inti CPU didistribusikan ke setiap kernel dalam perhitungan paralelisasi?
Hanya ingin memastikan bahwa saya memahami dengan benar sebelum mengajukan pertanyaan. Saya melihat beberapa orang mengatakan bahwa beberapa fungsi di Mathematica akan secara otomatis menggunakan multi-core (saya tidak mengacu pada yang kita paralelkan, tetapi mengacu pada yang serupa NIntegrate
), jadi saya pikir jika saya memiliki 2 core, itu akan lebih cepat daripada single inti. Jadi pertanyaan saya adalah apakah saya memiliki kode seperti berikut:ParallelTable[NIntegrate[x, {x, 1, 3}], {loop, 1, 3}]
Saya pikir tiga kernel akan diluncurkan. Jika saya memiliki 4 inti, bagaimana keempat inti ini didistribusikan ke setiap kernel? (Karena saya pikir setiap kernel dapat menggunakan multi-core berdasarkan properti integrasi fungsi)
Jawaban
Selamat datang noo-b, m.se adalah komunitas yang hebat untuk pembelajaran tanpa batas tentang M!
Saya pikir Anda memiliki beberapa asumsi yang salah:
Pertama, bahkan operasi single-threaded dapat melakukan thread di beberapa inti. Sistem operasi yang baik mencoba menghindarinya, tetapi setiap detik sekian, ia dapat beralih ke inti lain, atau mungkin membagi beban ke beberapa inti - meskipun yang terakhir biasanya tidak untuk waktu yang lama.
Kedua, Anda tidak dapat berasumsi bahwa NIntegrate akan selalu paralel untuk semua input, dan khususnya Anda tidak dapat berasumsi bahwa NIntegrate akan memparalelkan untuk seluruh waktu komputasi. Ini mungkin memparalelkan hanya untuk inisialisasi atau di akhir, atau pada tugas-tugas tertentu di antaranya. Sebagai contoh,
Do[Do[NIntegrate[x,{x,1,3}],{3}],{100000}]
jika Anda melihat pada pemanfaatan inti (bukan: pemanfaatan proses, seperti pada pengelola tugas sederhana) - jika Anda menggunakan Linux, Anda dapat menjalankan atas dan menekan 1 - Anda akan melihat bahwa ini menghabiskan 99% waktu untuk satu inti. Ini mungkin beralih inti setelah beberapa waktu, tapi kemudian Anda melihat 99% untuk yang inti. Jadi saya tidak melihat NIntegrate melakukan threading pada banyak core sama sekali, setidaknya tidak sepanjang waktu (mungkin selama sepersekian detik). Ini mungkin berbeda untuk input NIntegrate yang berbeda, tetapi contoh sederhana ini menunjukkan bahwa NIntegrate tidak selalu paralel dan tidak untuk seluruh durasi komputasi.
Dengan kerangka paralelisme M ini tidak berubah, ini benar-benar masalah sistem operasi. Dengan ParallelTable (dan saudara-saudara) Anda hanya menyediakan tugas pemrosesan dari lebih banyak proses, dan bagaimana jadwal o / s yang ke inti sepenuhnya tergantung pada o / s. Jadi Anda tidak dapat benar-benar "menarik" tugas ke inti dari pemahaman tentang proses paralel.
agak bersinggungan:
Di Scala, Java atau C # (atau banyak bahasa lainnya) Anda dapat menjadwalkan tugas di level thread. Tetapi bahkan kemudian terserah pada o / s untuk menjadwalkan tapak ke inti. Dengan vmstat Java Anda memiliki visualisasi utas yang luar biasa (bilah horizontal yang tumbuh dari waktu ke waktu, satu per utas), saya pikir apa yang benar-benar Anda minati adalah bagaimana segala sesuatunya bekerja di utas, belum tentu bagaimana utas ditetapkan ke inti . Meskipun demikian, utas adalah konsep perangkat lunak, bukan konsep perangkat keras, inti tidak tahu apa itu utas. Tapi saya pikir analisis utas akan memberi tahu Anda lebih banyak untuk memahami konkurensi sebagai penugasan ke inti, dan peralihan inti, dan persentase beban kerja untuk setiap inti, sepenuhnya tergantung pada o / s.
Ada beberapa fungsi yang secara otomatis menggunakan banyak inti. Berapa banyak inti yang mereka gunakan ditentukan oleh beberapa pengaturan di SystemOptions["ParallelOptions"]
.
Jika Anda menggunakan fungsi seperti itu pada subkernel, mereka hanya akan menggunakan satu inti. Anda dapat memverifikasi ini dengan melihat ParallelEvaluate@SystemOptions["ParallelOptions"]
. Perhatikan bahwa semua jumlah utas disetel ke 1 pada subkernel.
Umumnya, paralelisasi eksplisit (seperti ParallelTable
) tidak seefisien paralelisasi bawaan dari beberapa fungsi. Jadi, jika kemacetan Anda adalah fungsi yang sudah berjalan secara paralel, maka menerapkan paralelisasi tambahan dengan ParallelTable
atau fungsi terkait akan memperlambatnya (atau setidaknya itu memperlambatnya dalam semua kasus yang saya periksa).