ฉันควรลงทุนในกระบวนทัศน์การเขียนโปรแกรมใดหากฉันต้องการให้โค้ดของฉันทำงานบนเครื่อง petascale ในอนาคต

มันสวยชัดเจนจากการสำรวจความคิดเห็นของ top500 ที่อุตสาหกรรมมีแนวโน้มต่อเพิ่มขึ้นชี้แจงในแกนประมวลผล ซูเปอร์คอมพิวเตอร์ที่ใหญ่ที่สุดทั้งหมดใช้ MPI สำหรับการสื่อสารระหว่างโหนดแม้ว่าจะไม่มีแนวโน้มที่ชัดเจนสำหรับการขนานบนโหนดด้วยวิธีที่ง่ายที่สุด (แต่ไม่จำเป็นต้องมีประสิทธิภาพมากที่สุด) ในการทำแผนที่กระบวนการ MPI เดียวกับแต่ละแกนโดยอัตโนมัติ การขนานจากคอมไพเลอร์, OpenMP, pthreads, CUDA, Cilk และ OpenCL

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

มุมมองทางประวัติศาสตร์

มันเป็นไปไม่ได้จริงๆที่จะพูดในสิ่งที่กระบวนทัศน์ใหม่จะเป็นอย่างไรในอนาคตตัวอย่างเช่นมุมมองทางประวัติศาสตร์ที่ดีผมขอแนะนำให้อ่านเคนเคนเนดีขึ้นและตกของ HPF Kennedy ให้ข้อมูลเกี่ยวกับรูปแบบที่เกิดขึ้นใหม่สองรูปแบบ MPI เทียบกับคอมไพเลอร์อัจฉริยะและรายละเอียดว่า MPI มีจำนวนผู้ใช้ในช่วงแรกที่เหมาะสมและมีความยืดหยุ่นในการครอง HPF แก้ไขปัญหาได้ในที่สุด แต่ก็สายเกินไป

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

ล้างแนวโน้มในฮาร์ดแวร์

ตอนนี้ความสำเร็จของ MPI มักถูกอ้างถึงอย่างใกล้ชิดว่ามันเป็นแบบจำลองฮาร์ดแวร์ที่ทำงานอยู่ ประมาณแต่ละโหนดมีกระบวนการจำนวนน้อยและส่งข้อความไปยังจุดต่อจุดแบบโลคัลหรือผ่านการดำเนินการแบบรวมที่ประสานงานได้ง่ายในพื้นที่คลัสเตอร์ ด้วยเหตุนี้ผมไม่ทุกคนที่ไว้วางใจที่จะช่วยให้กระบวนทัศน์ที่ไม่ปฏิบัติตามอย่างใกล้ชิดกับแนวโน้มฮาร์ดแวร์ใหม่ที่จริงผมเชื่อว่าความเห็นนี้มาจากการทำงานจากVivak Sarakar

เพื่อให้สอดคล้องกับที่นี่มีแนวโน้มสามประการที่ทำให้ความคืบหน้าชัดเจนในสถาปัตยกรรมใหม่ และให้ฉันชัดเจนตอนนี้มีสิบสองสถาปัตยกรรมที่แตกต่างกันออกวางตลาดใน HPC สิ่งนี้เพิ่มขึ้นจากน้อยกว่า 5 ปีที่ผ่านมาซึ่งมีเฉพาะ x86 ดังนั้นวันที่จะมาถึงจะเห็นโอกาสมากมายสำหรับการใช้ฮาร์ดแวร์ในรูปแบบที่แตกต่างและน่าสนใจ

• ชิปที่มีวัตถุประสงค์พิเศษ: คิดว่าหน่วยเวกเตอร์ขนาดใหญ่เช่นตัวเร่งความเร็ว (เรียกดูโดย Bill Dally ของ Nvidia)
• ชิปพลังงานต่ำ: กลุ่ม ARM ที่ใช้ (เพื่อรองรับงบประมาณพลังงาน)
• Tiling of Chips: คิดถึงการเรียงของชิปที่มีคุณสมบัติแตกต่างกัน (งานของAvant Argwal )

รุ่นปัจจุบัน

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

ให้ฉันทำซ้ำโมเดลและวิธีที่พวกเขาจะต้องเปลี่ยนตามมุมมองฮาร์ดแวร์ใหม่ที่คาดการณ์ไว้

กระจาย

ผู้เล่นในระดับกระจายส่วนใหญ่ตกอยู่ใน MPI และภาษา PGAS MPI เป็นผู้ชนะที่ชัดเจนในขณะนี้ แต่ภาษาของ PGAS เช่น UPC และ Chapel กำลังก้าวเข้าสู่อวกาศ สิ่งบ่งชี้ที่ดีอย่างหนึ่งคือการท้าทายเกณฑ์มาตรฐาน HPC ภาษา PGAS ให้การใช้งานที่ยอดเยี่ยมสำหรับการวัดประสิทธิภาพ

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

แต่ความจริงแล้ว PGAS มีเรื่องราวที่ดีในการก้าวเข้ามาในพื้นที่นี้ คุณต้องการโปรแกรม MPI internode หรือไม่และต้องทำ intranode แบบเดียวกันหรือไม่? ข้อตกลงสำคัญอย่างหนึ่งของสถาปัตยกรรมแบบเรียงต่อกันคือพวกเขาจะมีความเร็วสัญญาณนาฬิกาที่แตกต่างกันในชิปและความแตกต่างที่สำคัญในแบนด์วิดท์ไปยังหน่วยความจำดังนั้นรหัสนักแสดงต้องคำนึงถึงเรื่องนี้

หน่วยความจำที่ใช้ร่วมกันบนโหนด

ที่นี่เราเห็น MPI มักจะ "ดีพอ" แต่ PThreads (และไลบรารีที่มาจาก PThreads เช่น Intel Parallel Building Blocks) และ OpenMP ยังคงใช้บ่อย มุมมองทั่วไปคือจะมีเวลาเมื่อมีเธรดหน่วยความจำแบบแบ่งใช้เพียงพอที่โมเดลซ็อกเก็ตของ MPI จะแยกย่อยสำหรับ RPC หรือคุณต้องการกระบวนการน้ำหนักเบาที่ทำงานบนแกน คุณสามารถเห็นตัวบ่งชี้ของระบบ IBM Bluegene ที่มีปัญหากับ MPI หน่วยความจำที่ใช้ร่วมกัน

ในฐานะที่เป็นความคิดเห็นของ Matt การเพิ่มประสิทธิภาพที่ใหญ่ที่สุดสำหรับการประมวลผลแบบเร่งรัดรหัสคือ vectorization ของรหัสซีเรียล ในขณะที่หลายคนคิดว่าสิ่งนี้เป็นจริงในส่วนช่วยดำเนินการ แต่ก็สำคัญสำหรับเครื่องที่อยู่ในโหนดเช่นกัน ฉันเชื่อว่า Westmere มี FPU 4 วงกว้างดังนั้นหนึ่งสามารถรับหนึ่งในสี่ของ flops โดยไม่มี vectorization

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

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

ร่วมประมวลผล

ในที่สุดการเกิดขึ้นของโปรเซสเซอร์ร่วม (GPU, MIC, ตัวเร่งเซลล์) ได้ถูกจับ เป็นที่ชัดเจนว่าไม่มีเส้นทางไปสู่ ​​exascale ที่จะสมบูรณ์หากไม่มีพวกเขา ที่ SC11 ผู้เข้าแข่งขันที่ได้รับรางวัล Bell ทุกคนใช้พวกเขาอย่างมีประสิทธิภาพมากเพื่อไปยัง petaflops ที่ต่ำ ในขณะที่ CUDA และ OpenCL ได้ครองตลาดปัจจุบันฉันหวังว่าจะมีคอมไพเลอร์ OpenACC และ PGAS เข้าสู่พื้นที่

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

สิ่งนี้มีผลต่อผู้พัฒนาแอพอย่างไร

ตอนนี้เพื่อไปที่คำถามของคุณ หากคุณต้องการปกป้องตนเองจากความซับซ้อนที่กำลังจะมาถึงของเครื่อง exascale คุณควรทำบางสิ่ง:

• พัฒนาอัลกอริทึมของคุณให้เหมาะสมกับลำดับชั้นแบบขนานอย่างน้อยสามระดับ
• ออกแบบอัลกอริธึมของคุณในแง่ของเมล็ดที่สามารถเคลื่อนย้ายระหว่างการสืบทอด
• ผ่อนคลายความต้องการของคุณสำหรับกระบวนการตามลำดับใด ๆ เอฟเฟกต์เหล่านี้ทั้งหมดจะเกิดขึ้นแบบอะซิงโครนัสเนื่องจากการดำเนินการแบบซิงโครนัสนั้นเป็นไปไม่ได้

หากคุณต้องการเป็นนักแสดงวันนี้ MPI + CUDA / OpenCL ก็ดีพอ แต่ UPC ก็ไปถึงที่นั่นดังนั้นจึงไม่ควรใช้เวลาสองสามวันในการเรียนรู้ OpenMP ช่วยให้คุณเริ่มต้น แต่นำไปสู่ปัญหาเมื่อรหัสต้องถูก refactored PThreads ต้องการการเขียนโค้ดของคุณใหม่ตามสไตล์อย่างสมบูรณ์ ซึ่งทำให้ MPI + CUDA / OpenCL เป็นรุ่นที่ดีที่สุดในปัจจุบัน

สิ่งที่ไม่ได้กล่าวถึงที่นี่

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

สิ่งนี้นำไปสู่แนวโน้มอื่น ๆ ที่อาจเกิดขึ้น (หากหน่วยงานระดมทุนที่เหมาะสมมีส่วนร่วม) เครื่องจักรจะมีความเชี่ยวชาญมากขึ้นสำหรับประเภทของการคำนวณที่ต้องการ เราเห็นแล้วว่าเครื่องจักร "ใช้ข้อมูลจำนวนมาก" ซึ่งได้รับทุนจาก NSF แต่เครื่องเหล่านี้อยู่ในเส้นทางที่แตกต่างจาก 2019 Exascale Grand Challenge

สิ่งนี้ยาวเกินกว่าที่คาดหมายไว้สำหรับการอ้างอิงที่คุณต้องการในความคิดเห็น

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

ข้อเท็จจริงที่ว่า pthreads เพียงอย่างเดียวไม่สามารถทำให้คุณมีประสิทธิภาพสูงสุดกับชิปที่ทันสมัยใด ๆ เพราะคุณต้องใช้ประโยชน์จากหน่วยเวกเตอร์ (จริงตั้งแต่ Cray แรก) ใน Intel และ AMD คุณสามารถใช้งานอินทรินได้ แต่สิ่งเหล่านี้ไม่สามารถพกพาได้และในความคิดเห็นของฉัน CUDA และ OpenCL มี vectorization อยู่ภายในไลบรารีและทำให้ง่ายต่อการรับประสิทธิภาพสูงสุด ฮาร์ดแวร์ใหม่ทั้งหมดที่ฉันรู้มีข้อกำหนดของเวกเตอร์นี้ดังนั้นโซลูชันใดควรคำนึงถึงสิ่งนี้ สำหรับฉัน CUDA / OpenCL เป็นวิธีปัจจุบันที่จะไป

ต่อไปเครื่องเหล่านี้ทั้งหมดจะเป็น NUMA ซึ่งยากต่อการเขียนโปรแกรม แต่ฉันคิดว่ากลยุทธ์เคอร์เนลใช้งานได้ คุณแบ่งงานและข้อมูลออกเป็นหน่วยเล็ก ๆ สิ่งเหล่านี้อาจถูกกำหนดเวลาโดยอัตโนมัติเช่นเดียวกับที่เกิดขึ้นใน CUDA และ OpenCL แต่คุณสามารถระบุการขึ้นต่อกันได้ สำหรับปัญหาที่เหมาะสมกับกระบวนทัศน์การสตรีมการโหลดนี้สามารถทำได้โดยอัตโนมัติ Intel TBB ทำเช่นนี้ แต่ฉันชอบวิธีการห้องสมุดระดับสูงกว่ามากโดยThrustและCuspซึ่งสามารถกำหนดเป้าหมายเป็น CUDA หรือ TBB (เร็ว ๆ นี้)

ฉันจะลองตอบสั้น ๆ กว่าเพื่อนร่วมงานที่ฉันนับถือบางคนในกระทู้นี้ ;-)

ข้อความของฉันให้กับนักเรียนทุกคนของฉันอยู่เสมอว่าเวลาของนักพัฒนามีค่ามากกว่าเวลาของ CPU นั่นหมายความว่าหากคุณมีเวลาในการแปลงรหัส 100% ที่ประสิทธิภาพ 80% เพื่อทำงานบนเครื่องจักรขนาดใหญ่ - โดยใช้วิธีการระดับสูง - คุณจะดีกว่าเมื่อคุณใช้ระดับต่ำที่ใช้เวลานาน วิธีการที่ให้ประสิทธิภาพ 100% กับรหัส 20% ของคุณ เป็นผลให้ฉันเป็นแฟนตัวยงของห้องสมุดระดับสูง สิ่งที่ฉันชอบในบริเวณนี้คือการสร้างเกลียว (TBB) เนื่องจากมันช่วยให้ฉันดูอัลกอริทึมที่ลูปนอกสุดและในระดับสูง นอกจากนี้ยังสามารถทำทุกสิ่งที่คุณอาจต้องการทำกับ pthreads โดยไม่ต้อง cruddiness ที่ต้องจัดการกับฟังก์ชั่นของระบบปฏิบัติการ ฯลฯ ฉันไม่ได้เป็นแฟนของแนวทางที่ดูลูปด้านในสุดเพราะนั่นเป็นระดับที่ไม่ถูกต้อง - ดังนั้นจึงไม่มี OpenMP

ฉันไม่สามารถพูดกับผู้มีอำนาจเกี่ยวกับ OpenCL, CUDA และอื่น ๆ

คำตอบที่โพสต์ก่อนหน้านี้ที่ยอดเยี่ยม แต่ส่วนใหญ่เน้นสถาปัตยกรรมโหนดซึ่งผมคิดว่าสะท้อนให้เห็นถึงความจริงที่ว่า MPI โดยทั่วไปถือว่าเพียงพอเป็นรูปแบบการเขียนโปรแกรมปล้องในกรณีส่วนใหญ่และว่ามันเป็น intranode ขนานที่เราต่อสู้

ต่อไปนี้เป็นความพยายามของฉันในการตอบคำถามสองข้อที่ยังไม่ได้รับคำตอบหรือตอบค่อนข้าง จำกัด :

ฉันควรทำสมมติฐานเกี่ยวกับสถาปัตยกรรมที่เชื่อมต่อระหว่างกระบวนการอย่างไร

ฉันจะพิจารณาคุณสมบัติของเครือข่ายสามประการ:

1. แฝง
2. แบนด์วิดธ์และ
3. เห็นพ้องด้วย

ความหน่วงจะแปรผกผันกับความถี่ เรารู้ว่าการปรับขนาดความถี่หยุดนิ่ง ดังนั้นเราสามารถสรุปได้ว่าความล่าช้าไม่น่าจะลดลงอย่างมีนัยสำคัญในอนาคต MPI send-recv latency บน Blue Gene / Q อยู่ที่ 2 เราซึ่งสอดคล้องกับ 3200 รอบ มากกว่าครึ่งหนึ่งของเวลาแฝงนั้นเป็นซอฟต์แวร์ แต่ MPI นั้นต้องการส่วนที่ดี การปรับแต่งอย่างละเอียดอาจลดเวลาในการตอบสนองให้อยู่ใกล้กับเรา 1 คนโดยเฉพาะอย่างยิ่งหากสามารถยืนยันได้ว่าจะไม่มีการใช้สัญลักษณ์แทน MPI

ไม่ว่าในกรณีใด ๆ เวลาแฝงของฮาร์ดแวร์สำหรับการฉีดแพ็คเก็ตในระบบ Blue Gene และ Cray นั้นอยู่ที่ 1 เรา หากมีสิ่งใดการเพิ่มการทำงานพร้อมกันของระดับโหนดจะทำให้หมายเลขนี้ต่ำมาก แต่ฉันก็มองโลกในแง่ดีว่านักออกแบบฮาร์ดแวร์จะหาวิธีรักษาเวลาแฝงที่ต่ำกว่า 5 เราไว้สำหรับอนาคตอันใกล้นี้

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

ไม่มีข้อ จำกัด พื้นฐานสำหรับแบนด์วิดท์เครือข่ายเฉพาะในทางปฏิบัติเท่านั้น แบนด์วิดท์จะต้องเสียเงินและกำลัง ผู้ออกแบบระบบจะต้องคำนึงถึงการแลกเปลี่ยนระหว่างแบนด์วิดท์เครือข่ายและส่วนอื่น ๆ ของเครื่องเมื่อพัฒนาระบบในอนาคต รหัสจำนวนมากไม่ได้ จำกัด แบนด์วิดท์ของเครือข่ายดังนั้นจึงไม่น่าเป็นไปได้ที่เราจะเห็นเครื่องที่มีแบนด์วิดท์ต่อการเชื่อมต่อมากขึ้นอย่างมากในอนาคต อย่างไรก็ตามแบนด์วิดท์ต่อโหนดควรเพิ่มสัดส่วนตามกำลังคำนวณดังนั้นจึงจำเป็นต้องมีการเชื่อมต่อหลายจุดต่อโหนดเพื่อเพิ่มขนาด

คุณสมบัติที่สามของเครือข่ายที่มักถูกมองข้ามในรูปแบบที่เป็นทางการคือจำนวนข้อความที่สามารถส่งได้ในครั้งเดียว การมีเครือข่ายที่มีเวลาแฝง 1 ns และ / หรือแบนด์วิดท์ 1 TB / s ที่สามารถส่งข้อความได้ครั้งละ 1 ข้อความเท่านั้นจะไร้ประโยชน์อย่างสิ้นเชิงสำหรับประเพณีส่วนใหญ่ เป็นสิ่งสำคัญที่จะสามารถส่งข้อความจำนวนมากจากเธรดจำนวนมากในเวลาเดียวกันและเพื่อให้เครือข่ายไม่ยุบภายใต้การต่อสู้ ทั้งระบบ Cray และ Blue Gene สามารถทำได้มากกว่า 1 MMPS (ล้านข้อความต่อวินาที) ฉันจำตัวเลขไม่ได้ แต่ทั้งคู่ก็สามารถบรรลุแบนด์วิดธ์สูงสุดของข้อความขนาดเล็กได้ เครือข่ายในอุดมคติอาจสามารถเข้าถึงแบนด์วิดท์สูงสุดพร้อมข้อความขนาดใดก็ได้ แต่เป็นไปไม่ได้ในทางปฏิบัติเนื่องจากส่วนหัวของแพ็คเก็ตและค่าโสหุ้ยการทำบัญชีที่เกี่ยวข้อง อย่างไรก็ตาม

นี่คือคำตอบที่ไม่สมบูรณ์และไม่สมบูรณ์ คนอื่นยินดีที่จะพยายามปรับปรุงหรือแนะนำสิ่งที่ฉันควรปรับปรุง

พาร์ทิชันภาษาสากลที่อยู่ในพื้นที่ว่างจะพร้อมใช้งาน "ในการผลิต" บนเครื่อง petascale หรือไม่?

ระบบ Cray XE, XK และ XC มีคอมไพเลอร์ UPC และ CAF คุณภาพการผลิต ระบบ Blue Gene สามารถส่งด้วย XLUPC และ XLCAF แต่ไม่มีใครถามถึงสิ่งนี้จึงไม่ได้ส่งมอบ PERCS มีคอมไพเลอร์ XLUPC และ XLCAF ระดับการผลิต แต่ไม่มีการติดตั้งขนาดใหญ่ที่ชุมชนวิทยาศาสตร์สามารถเข้าถึงได้

Coarrays เป็นส่วนหนึ่งของ Fortran 2008 แม้ว่าการนำไปใช้งานใน Intel และ GNU Fortran นั้นยังไม่ได้คุณภาพสูง การติดตั้งใช้งานของ Intel นั้นขึ้นชื่อว่าทำงานได้ค่อนข้างช้า (มีรายงานของ PGAS12 เกี่ยวกับเรื่องนี้)

สำหรับโมเดลการเขียนโปรแกรม PGAS (เนื่องจากรูปแบบการเขียนโปรแกรมไม่ใช่ภาษาการเขียนโปรแกรม - เป็นเรื่องของคำถามต้นฉบับ) ไลบรารี Global Arrays เป็นค่าประมาณที่เหมาะสมสำหรับคุณภาพการผลิตในหลายกรณี ในฐานะรันไทม์มันไม่ได้แข็งแกร่งเท่ากับ MPI แต่ MPI นั้นมีความเป็นเอกลักษณ์ในแง่ของคุณภาพของการติดตั้งใช้งาน การติดตั้ง ARMCI-MPI ของ ARMCI ทำให้ Global Arays มีเสถียรภาพมากขึ้นแม้ว่าจะช้าลงในบางกรณี

มันค่อนข้างง่ายที่จะใช้การสร้างแบบ PGAS ในทางคุณภาพการผลิตโดยใช้ MPI-3 RMA หากมีคนโพสต์คำถามใหม่เกี่ยวกับเรื่องนี้ฉันยินดีที่จะตอบ

จำนวนแกนขนาดใหญ่จริงๆยังเปิดมุมมองที่น่าสนใจ แต่ก็มีประโยชน์อย่างน่าประหลาดใจเพียงใช้เพื่อเรียกใช้การวนซ้ำของการจำลองทั้งหมด

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

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

ฉันเพิ่งจะโพสต์คำตอบสำหรับคำถามนี้แต่มันถูกปิดเป็นสำเนาของคำถามนี้ดังนั้นที่นี่ไป:

สิ่งนี้อาจฟังดูโซโลมอนนิดหน่อย แต่จากประสบการณ์ของฉันอนาคตเป็นของไฮบริดที่มีโหนดหลายแกนหน่วยความจำที่ใช้ร่วมกันหลายแห่งที่ใช้เคอร์เนลแบบมัลติเธรดเชื่อมต่อผ่านกระบวนทัศน์หน่วยความจำแบบกระจายเช่น MPI

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

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

โดยสรุปอุปสรรคในการเคลื่อนย้ายจากหน่วยความจำแบบกระจายอย่างหมดจดไปเป็นกระบวนทัศน์หน่วยความจำแบบแบ่งส่วน / หมดจดค่อนข้างสูง หากคุณต้องการใช้เธรดอย่างมีประสิทธิภาพคุณต้องลืม OpenMP และจัดการเธรดและการทำงานพร้อมกันด้วยตัวคุณเอง (สวัสดีpthreadsลาก่อน Fortran)

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