พล็อตการปรับขนาด / การบันทึกแบบขนานของล็อก - ล็อก

งานของฉันจำนวนมากหมุนรอบการทำให้อัลกอริธึมขยายขนาดได้ดีขึ้นและหนึ่งในวิธีที่ต้องการในการแสดงการปรับสเกลแบบขนานและ / หรือประสิทธิภาพแบบขนานคือการพล็อตประสิทธิภาพของอัลกอริทึม / รหัสบนจำนวนแกนเช่น

โดยที่ -axis แสดงถึงจำนวนแกนและy -axis ตัวชี้วัดบางตัวเช่นงานที่ทำต่อหน่วยเวลา เส้นโค้งที่แตกต่างกันแสดงประสิทธิภาพแบบขนานที่ 20%, 40%, 60%, 80% และ 100% ที่ 64 แกนตามลำดับ$x$$y$

แต่น่าเสียดายที่แม้ว่าในสิ่งพิมพ์หลายผลเหล่านี้มีพล็อตที่มีการเข้าสู่ระบบเข้าสู่ระบบการปรับเช่นผลลัพธ์ในนี้หรือนี้กระดาษ ปัญหาของแผนการบันทึกการใช้งานเหล่านี้คือมันยากที่จะประเมินค่า / ประสิทธิภาพขนานจริงอย่างไม่น่าเชื่อ

ซึ่งเป็นพล็อตเดียวกับด้านบน แต่ยังมีการปรับขนาดบันทึกการทำงาน โปรดทราบว่าขณะนี้ไม่มีความแตกต่างอย่างมากระหว่างผลลัพธ์ที่มีประสิทธิภาพแบบขนาน 60%, 80% หรือ 100% ผมเคยเขียนบิตอย่างกว้างขวางมากขึ้นเกี่ยวกับเรื่องนี้ที่นี่

ดังนั้นนี่คือคำถามของฉัน: มีเหตุผลอะไรบ้างที่แสดงผลลัพธ์ในการปรับขนาดบันทึกการทำงาน ฉันใช้มาตราส่วนแบบเส้นตรงเพื่อแสดงผลลัพธ์ของตัวเองเป็นประจำและใช้ค้อนทุบโดยผู้ตัดสินบอกว่าผลการวัด / ประสิทธิภาพแบบขนานของตัวเองไม่ได้ดูดีเท่าผลการบันทึก (log-log) ของผู้อื่น แต่สำหรับชีวิตของฉันฉัน ไม่เห็นว่าทำไมฉันจึงควรเปลี่ยนรูปแบบการพล็อต

ขณะนี้เรากำลังเขียนบทความที่มีจำนวนแปลงใกล้เคียงกันและเรามีปัญหาเดียวกันไม่มากก็น้อย บทความนี้เกี่ยวกับการเปรียบเทียบขนาดของอัลกอริธึมที่แตกต่างกันกับจำนวนคอร์ซึ่งมีช่วงระหว่าง 1 ถึงสูงสุด 100k บน BlueGene เหตุผลในการใช้ loglog-plots ในสถานการณ์นี้คือจำนวนคำสั่งของขนาดที่เกี่ยวข้อง ไม่มีวิธีใดที่จะสามารถวางลำดับความสำคัญได้ 6 ระดับในระดับเชิงเส้น

และแน่นอนเมื่อทำการพล็อตเวลากับจำนวนคอร์ใน loglog อัลกอริทึมจะไม่สามารถแยกแยะได้มากอย่างที่คุณเห็นในพล็อตต่อไปนี้

$E_p=T_1/(p T_p)$$T_1$$T_p$$p$$p$$E_p$$p$

$E_p=T_{ref}/(p T_p)$$T_{ref}$

การพล็อตประสิทธิภาพแบบคู่ขนานสัมพัทธ์ในสเกล semilog แสดงให้เห็นถึงการปรับขนาดของอัลกอริธึมอย่างชัดเจนและยังแสดงให้เห็นว่าอัลกอริธึมทำงานอย่างไรเมื่อเปรียบเทียบกัน

Georg Hager เขียนเกี่ยวกับเรื่องนี้ในFooling the Masses - Stunt 3: ระดับบันทึกเป็นเพื่อนของคุณขนาดบันทึกเป็นเพื่อนของคุณ

ในขณะที่มันเป็นความจริงที่แผนการบันทึกล็อกของมาตราส่วนที่รัดกุมไม่ได้มองที่ปลายสูงพวกเขาอนุญาตให้แสดงมาตราส่วนตามลำดับความสำคัญมากขึ้น หากต้องการดูว่าทำไมสิ่งนี้จึงมีประโยชน์ให้พิจารณาปัญหา 3D ด้วยการปรับแต่งปกติ ในระดับเชิงเส้นคุณสามารถแสดงประสิทธิภาพได้อย่างสมเหตุสมผลในสองลำดับความสำคัญเช่น 1024 คอร์, 8192 คอร์และ 65536 คอร์ เป็นไปไม่ได้ที่ผู้อ่านจะบอกจากพล็อตไม่ว่าคุณจะวิ่งอะไรเล็ก ๆ และแนบเนียนแล้วพล็อตส่วนใหญ่จะเปรียบเทียบการวิ่งที่ใหญ่ที่สุดสองครั้ง

ตอนนี้สมมติว่าเราสามารถใส่กริดเซลล์ 1 ล้านเซลล์ต่อหนึ่งคอร์ในหน่วยความจำซึ่งหมายความว่าหลังจากปรับสเกลแรงสองครั้งด้วยปัจจัย 8 เรายังสามารถมีเซลล์ 16k ต่อแกน นั่นยังคงเป็นโดเมนย่อยที่มีขนาดใหญ่และเราคาดหวังว่าอัลกอริธึมหลายอย่างจะทำงานได้อย่างมีประสิทธิภาพ เราได้ครอบคลุมสเปกตรัมภาพของแผนภูมิ (1024 ถึง 65536 แกน) แต่ยังไม่ได้เข้าสู่ระบอบการปกครองที่การปรับสเกลแข็งแกร่งกลายเป็นเรื่องยาก

สมมติว่าเราเริ่มต้นด้วย 16 คอร์ด้วย 1 ล้านเซลล์กริดต่อคอร์ ทีนี้ถ้าเราขยายเป็น 65536 cores เราจะมี 244 เซลล์ต่อหนึ่งคอร์ซึ่งจะมีมากฉลาดมากขึ้น แกนบันทึกเป็นวิธีเดียวที่จะแสดงสเปกตรัมอย่างชัดเจนจาก 16 คอร์ถึง 65536 คอร์ แน่นอนว่าคุณยังคงสามารถใช้แกนเชิงเส้นและมีคำบรรยายว่า "จุดข้อมูลสำหรับ 16, 128 และ 1024 แกนทับซ้อนกันในภาพ" แต่ตอนนี้คุณกำลังใช้คำแทนรูปเพื่อแสดง

มาตราส่วนล็อก - ล็อกยังทำให้สเกลของคุณ "กู้คืน" จากแอ็ตทริบิวต์เครื่องเช่นการย้ายที่เกินโหนดเดียวหรือชั้นวาง มันขึ้นอยู่กับคุณว่าสิ่งนี้เป็นที่ต้องการหรือไม่

ฉันเห็นด้วยกับทุกสิ่งที่เจดต้องพูดในการตอบกลับของเขา แต่ฉันต้องการเพิ่มสิ่งต่อไปนี้ ฉันกลายเป็นแฟนตัวยงของมาร์ตินเบอร์ซินส์และเพื่อนร่วมงานของเขาแสดงการปรับขนาดสำหรับกรอบ Uintah พวกเขาพล็อตการปรับขนาดที่อ่อนแอและแข็งแกร่งของรหัสบนแกนบันทึกการใช้งาน (ใช้เวลาทำงานต่อขั้นตอนของวิธีการ) ฉันคิดว่ามันแสดงให้เห็นว่าโค้ดปรับขนาดได้ดีเพียงใด (แม้ว่าการเบี่ยงเบนจากการปรับขนาดที่สมบูรณ์นั้นยากที่จะกำหนด) ดูหน้า 7 และ 8 ตัวเลข 7 และ 8 จากนี้ * กระดาษตัวอย่างเช่น พวกเขายังให้ตารางที่มีตัวเลขที่สอดคล้องกับตัวเลขการปรับแต่ละ

ข้อดีของการทำเช่นนี้คือเมื่อคุณให้หมายเลขแล้วผู้วิจารณ์อาจพูดว่าไม่มากนัก (หรืออย่างน้อยก็ไม่มากนักที่คุณไม่สามารถโต้แย้งได้)

* J Luitjens, M. Berzins “ การปรับปรุงประสิทธิภาพของ Uintah: กรอบการคำนวณแบบ Adaptive Meshing ขนาดใหญ่” ในการดำเนินการประชุมวิชาการประมวลผล IEEE International Parallel and Distributed (IPDPS10) ครั้งที่ 24 ที่ Atlanta, GA, pp. 1--10 2010 DOI: 10.1109 / IPDPS.2010.5470437