วิธีการแสดงข้อมูลเหตุการณ์ในการค้นหาปัญหาด้านประสิทธิภาพ

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

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

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

ชุดข้อมูลนี้มีข้อ จำกัด ในการที่ไม่ทราบว่าโครงสร้างดาต้าโฟลว์ แต่ฉันต้องการทำความเข้าใจให้มากที่สุดก่อนที่จะพยายามรวบรวมสิ่งที่ซับซ้อนมากขึ้น

รูปภาพที่ไม่มีการบีบอัดอยู่ที่นี่ในกรณีที่ทุกคนต้องการมองไปรอบ ๆ (ไม่สามารถอัพโหลดผ่านเส้นทางปกติ) น่าเสียดาย Firefox ไม่ยอมรับแม้ว่าฉันจะเชื่อว่ามันถูกต้องอาจเป็นเพราะมันใหญ่เกินไป

ฉันใช้เวลาเขียนและแก้จุดบกพร่องรหัสคู่ขนานกันมากทั้งที่ใช้ร่วมกันและ / หรือกระจายหน่วยความจำ แต่โดยไม่ทราบว่าปัญหาของคุณเฉพาะฉันสามารถบอกได้ว่าอะไรที่ดีที่สุดสำหรับฉัน

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

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

หนึ่งชิ้นในการใช้ซอฟแวร์ที่ผมค่อนข้างมักจะเป็นIntel VTune Amplifier XE มันมีคุณสมบัติการวางแผนที่ดี / ตัวเลือกที่เห็นได้ชัดการทำงานพร้อมกันของด้าย โปรแกรมจะวาดพล็อตที่คล้ายกับของคุณมาก แต่เมื่อเธรดรอตัวแปร mutex หรือเงื่อนไขมันจะวาดเส้นทแยงมุมจากเธรดที่รอในเวลาที่มันเริ่มรอไปยังเธรดที่ปล่อย mutex หรือสัญญาณจริง เงื่อนไขที่มันรออยู่ในขณะที่ปล่อย / ส่งสัญญาณ สิ่งนี้อาจยุ่งมาก แต่ก็ทำให้คอขวดปรากฏขึ้นทันที

สุดท้ายฉันยังรวบรวมสถิติจำนวนมากเช่นสำหรับ mutex / signal / MPI-call แต่ละครั้งเวลาเฉลี่ยและเวลารอสูงสุดคือเท่าใด ฮิสโตแกรมของเวลารอคอยที่รวบรวมไว้คืออะไร ในขณะที่พล็อตให้ภาพรวมที่ดีคุณสามารถรับค่อนข้างยุ่งเมื่อลงมาถึงรายละเอียดดี

ในที่สุดคำถามหนึ่งข้อที่ไม่ควรประเมิน: คุณรวบรวมเวลาของคุณอย่างไร ตัวจับเวลาของคุณไม่ล่วงล้ำมากพอที่จะไม่ส่งผลต่อรหัสของคุณหรือไม่ ฉันใช้คำสั่ง CPU นับเมื่อเป็นไปได้เช่นRDTSCบนสถาปัตยกรรม x86 โดยปกติจะเพิ่มคำสั่งเดียวในรหัสของคุณ

บางครั้งคุณสามารถรับมุมมองทางเลือกเกี่ยวกับปัญหาด้านประสิทธิภาพผ่านการวิเคราะห์ทรัพยากรระดับสูง: มีคอขวดที่เกี่ยวข้องเช่นแบนด์วิธหน่วยความจำหรือไม่? เธรดของผู้ปฏิบัติงานทุกคนทำงานในปริมาณเท่ากันหรือไม่ ข้อมูลนี้อาจจะเก็บได้อย่างง่ายดายด้วย likwid-perfctr จากเครื่องมือชุด LIKWID โครงการรหัส LIKWID Google หากโปรไฟล์เป็นเช่นนั้นมีฮอตสปอตที่แตกต่างกันมากมายคุณอาจต้องจัดการกับพวกเขาทีละคน อาจมีปัญหาแตกต่างกันขึ้นอยู่กับจำนวนเธรด / กระบวนการที่ใช้

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

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

โชคดี.