Log-log plot penskalaan / efisiensi paralel


17

Banyak pekerjaan saya sendiri berkisar membuat skala algoritma lebih baik, dan salah satu cara yang disukai untuk menunjukkan penskalaan paralel dan / atau efisiensi paralel adalah untuk memplot kinerja algoritma / kode pada jumlah inti, misalnya

plot penskalaan paralel buatan

di mana sumbu mewakili jumlah core dan sumbu beberapa metrik, misalnya pekerjaan yang dilakukan per unit waktu. Kurva yang berbeda menunjukkan efisiensi paralel masing-masing 20%, 40%, 60%, 80%, dan 100% pada 64 core.yxy

Sayangnya meskipun, dalam berbagai publikasi, hasil ini diplot dengan log-log scaling, misalnya hasil di ini atau ini kertas. Masalah dengan plot log-log ini adalah bahwa sangat sulit untuk menilai penskalaan / efisiensi paralel yang sebenarnya, misalnya

masukkan deskripsi gambar di sini

Yang merupakan plot yang sama seperti di atas, namun dengan penskalaan log-log. Perhatikan bahwa sekarang tidak ada perbedaan besar antara hasil untuk efisiensi paralel 60%, 80%, atau 100%. Saya telah menulis sedikit lebih luas tentang ini di sini .

Jadi inilah pertanyaan saya: Apa alasan untuk menunjukkan hasil dalam penskalaan log-log? Saya secara teratur menggunakan penskalaan linier untuk menunjukkan hasil saya sendiri, dan secara teratur dipalu oleh wasit yang mengatakan bahwa hasil penskalaan / efisiensi paralel saya sendiri tidak terlihat sebagus hasil (log-log) dari orang lain, tetapi untuk kehidupan saya, saya tidak dapat melihat mengapa saya harus mengganti gaya plot.

Jawaban:


16

Saat ini kami sedang menulis makalah yang berisi sejumlah plot yang sebanding, dan kami kurang lebih memiliki masalah yang sama. Makalah ini tentang membandingkan penskalaan berbagai algoritma atas jumlah core, yang berkisar antara 1 dan hingga 100k pada BlueGene. Alasan untuk menggunakan loglog-plot dalam situasi ini adalah jumlah urutan besarnya yang terlibat. Tidak mungkin seseorang dapat memplot 6 orde magnitudo dalam skala linier.

Dan memang, ketika merencanakan waktu lebih dari jumlah core dalam loglog, algoritme tidak terlalu dapat dibedakan, seperti yang Anda lihat dalam plot berikut. Pengaturan waktu sejumlah algoritma pada skala loglog.  Algoritme yang berbeda sulit dibedakan.

Ehal=T1/(halThal)T1ThalhalhalEhalhal

Ehal=Tref/(halThal)Tref

Memetakan efisiensi paralel relatif pada skala semilog menunjukkan penskalaan algoritma dengan cukup jelas, dan juga menunjukkan bagaimana algoritme tersebut bekerja relatif satu sama lain. Efisiensi paralel relatif dari sejumlah algoritma di atas jumlah core.


2
x

Perhatikan bahwa plot tidak terlihat sama mengesankannya dengan plot penskalaan lainnya, karena plot-plot tersebut turun dengan cepat pada skala log. Selain itu, secara teori Anda juga dapat merencanakan efisiensi dalam plot loglog untuk melihat rincian lebih lanjut di tepi kanan. Namun perlu dicatat bahwa ini berarti Anda melihat detail pada efisiensi yang sangat rendah, yang mungkin tidak menarik.
olenz

14

Georg Hager menulis tentang ini di Fooling the Masses - Stunt 3: Skala log adalah teman Anda .

Meskipun benar bahwa plot log-log dari penskalaan yang kuat tidak terlalu tajam pada ujung yang tinggi, mereka memungkinkan untuk menunjukkan penskalaan di lebih banyak urutan besarnya. Untuk melihat mengapa ini berguna, pertimbangkan masalah 3D dengan penyempurnaan biasa. Pada skala linier, Anda dapat menampilkan kinerja secara wajar di sekitar dua urutan besarnya, misalnya 1024 core, 8192 core, dan 65536 core. Tidak mungkin bagi pembaca untuk mengetahui dari plot apakah Anda menjalankan sesuatu yang lebih kecil, dan secara realistis, plot sebagian besar hanya membandingkan dua run terbesar.

Sekarang seandainya kita dapat memasukkan 1 juta sel jaringan per inti dalam memori, ini berarti bahwa setelah penskalaan yang kuat dua kali dengan faktor 8, kita masih dapat memiliki 16k sel per inti. Itu masih ukuran subdomain yang cukup besar dan kita bisa berharap banyak algoritma berjalan secara efisien di sana. Kami telah membahas spektrum visual dari grafik (1024 hingga 65536 core), tetapi bahkan belum memasuki rezim di mana penskalaan yang kuat menjadi sulit.

Misalkan kita mulai dari 16 core, juga dengan 1 juta sel jaringan per inti. Sekarang jika kita skala ke 65536 core, kita hanya akan memiliki 244 sel per inti, yang akan jauh lebih cerdas. Sumbu log adalah satu-satunya cara untuk secara jelas mewakili spektrum dari 16 core hingga 65536 core. Tentu saja Anda masih dapat menggunakan sumbu linier dan memiliki keterangan yang mengatakan "titik data untuk 16, 128, dan 1024 core tumpang tindih dalam gambar", tetapi sekarang Anda menggunakan kata-kata alih-alih gambar itu sendiri untuk ditampilkan.

Skala log-log juga memungkinkan penskalaan Anda untuk "pulih" dari atribut mesin seperti bergerak di luar satu node atau rak. Terserah Anda apakah ini diinginkan atau tidak.


xy

1
Hal ini jauh lebih sulit untuk skala yang kuat masalah tunggal dengan faktor 4096 selain untuk skala dua yang berbeda ukuran masalah dengan faktor 64 masing-masing. Dalam contoh yang saya berikan, mudah untuk membuat dua case independen menunjukkan efisiensi yang lebih baik dari 95%, tetapi memiliki case kombinasi tunggal memiliki efisiensi kurang dari 30%. Dalam sains dan industri, tidak ada alasan yang telah ditentukan untuk waktu turn-around yang diinginkan untuk jatuh dalam kisaran ukuran sempit di mana algoritma "nyaman".
Jed Brown

Saya sepenuhnya setuju bahwa penskalaan dari satu ke ribuan adalah tantangan besar! Alasan saya menganggap besaran yang berbeda sebagai masalah yang berbeda adalah bahwa itu akan berarti hal yang berbeda untuk pengguna akhir. Misalnya di MD, sebagian besar ahli biologi tidak memiliki BlueGene di ruang bawah tanah, tetapi memiliki beberapa workstation multi-core, atau bahkan hibah untuk beberapa waktu pada cluster berukuran sedang (sejumlah kecil node), dan orang-orang yang melihat besar Masalah CFD, bagaimanapun, tidak akan terlalu peduli untuk kasus single-node karena masalah tidak akan muat di memori. Ini bukan tentang kenyamanan algoritma, tetapi pengaturan pengguna.
Pedro

2

Saya setuju dengan semua yang dikatakan Jed dalam jawabannya, tetapi saya ingin menambahkan yang berikut. Saya telah menjadi penggemar cara Martin Berzins dan rekan-rekannya menunjukkan skala untuk kerangka kerja Uintah mereka. Mereka merencanakan penskalaan kode yang lemah dan kuat pada sumbu log-log (menggunakan run time per langkah dari metode ini). Saya pikir ini menunjukkan bagaimana kode skala cukup baik (meskipun penyimpangan dari penskalaan sempurna agak sulit untuk ditentukan). Lihat halaman 7 dan 8 angka 7 dan 8 makalah * ini misalnya. Mereka juga memberikan tabel dengan angka yang sesuai dengan masing-masing angka skala.

Keuntungan dari hal ini adalah bahwa setelah Anda memberikan angka, tidak banyak yang bisa dikatakan oleh reviewer (atau setidaknya tidak banyak yang tidak bisa Anda bantah).

* J. Luitjens, M. Berzins. “Meningkatkan Kinerja Uintah: Kerangka Kerja Komputasi Adaptive Meshing Skala Besar,” Dalam Prosiding Simposium Pemrosesan Paralel dan Terdistribusi IEEE Internasional ke-24 (IPDPS10), Atlanta, GA, hlm. 1--10. 2010. DOI: 10.1109 / IPDPS.2010.5470437


Apakah Anda bisa menanamkan gambar langsung ke jawaban Anda?
Aron Ahmadia

Meskipun bisa dibilang adil untuk meminjam angka mereka, saya lebih suka mengarahkan lalu lintas ke situs penulis. Mungkin saya akan membuat beberapa angka dan grafik saya sendiri dan kembali lagi nanti dengan angka.
Bill Barth

Dari perspektif itu, Anda dapat membungkus gambar sehingga tautan ke situs penulis, serta meningkatkan jumlah teks dalam tautan. Jika Anda ingin membahas ini lebih lanjut, saya dapat membuka utas meta / obrolan.
Aron Ahmadia

@BillBarth Tautan Anda baru saja dialihkan ke beranda mereka sekarang. Bisakah Anda memperbaikinya atau menyematkan gambar yang dimaksud?
Jed Brown

1
@JedBrown Link diedit. Referensi lengkap ditambahkan. DOI menambahkan.
Bill Barth
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.