วัตถุประสงค์
ประการแรกสิ่งสำคัญคือต้องตระหนักว่า MPICH และ Open-MPI แตกต่างกันอย่างไรกล่าวคือได้รับการออกแบบมาเพื่อตอบสนองความต้องการที่แตกต่างกัน MPICH ควรจะใช้อ้างอิงที่มีคุณภาพสูงของมาตรฐาน MPI ล่าสุดและเป็นพื้นฐานสำหรับการใช้งานอนุพันธ์เพื่อตอบสนองความต้องการวัตถุประสงค์พิเศษ Open-MPI กำหนดเป้าหมายกรณีทั่วไปทั้งในแง่ของการใช้งานและท่อร้อยสายเครือข่าย
รองรับเทคโนโลยีเครือข่าย
เปิด MPI เอกสารสนับสนุนเครือข่ายของพวกเขาที่นี่ MPICH แสดงรายการข้อมูลนี้ใน README กระจายกับแต่ละรุ่น (เช่นนี้สำหรับ 3.2.1) โปรดทราบว่าเนื่องจากทั้ง Open-MPI และ MPICH รองรับOFI(aka libfabric) เลเยอร์เครือข่ายรองรับเครือข่ายเดียวกันจำนวนมาก อย่างไรก็ตาม libfabric เป็น API หลายด้านดังนั้นจึงไม่ใช่ทุกเครือข่ายที่อาจได้รับการสนับสนุนเหมือนกันในทั้งสอง (เช่น MPICH มีการใช้งาน IBM Blue Gene / Q ที่ใช้ OFI แต่ฉันไม่ทราบถึงการสนับสนุนที่เท่าเทียมกันใน Open-MPI) . อย่างไรก็ตามการใช้งานตาม OFI ของทั้ง MPICH และ Open-MPI กำลังทำงานบนหน่วยความจำที่ใช้ร่วมกันอีเทอร์เน็ต (ผ่าน TCP / IP) Mellanox InfiniBand Intel Omni Path และเครือข่ายอื่น ๆ Open-MPI ยังรองรับทั้งสองเครือข่ายเหล่านี้และเครือข่ายอื่น ๆ (เช่นไม่มี OFI อยู่ตรงกลาง)
ในอดีตข้อร้องเรียนทั่วไปเกี่ยวกับ MPICH คือไม่รองรับ InfiniBand ในขณะที่ Open-MPI ทำ อย่างไรก็ตาม MVAPICH และ Intel MPI (ในกลุ่มอื่น ๆ ) ซึ่งทั้งสองอย่างนี้เป็นอนุพันธ์ของ MPICH - รองรับ InfiniBand ดังนั้นหากมีใครยินดีที่จะกำหนด MPICH เป็น "MPICH และอนุพันธ์" MPICH ก็มีการสนับสนุนเครือข่ายที่กว้างขวางมากรวมทั้ง InfiniBand และเป็นกรรมสิทธิ์ การเชื่อมต่อระหว่างกันเช่น Cray Seastar, Gemini และ Aries รวมถึง IBM Blue Gene (/ L, / P และ / Q) Open-MPI ยังรองรับการเชื่อมต่อระหว่างกันของ Cray Gemini แต่ Cray ไม่รองรับการใช้งาน เมื่อไม่นานมานี้ MPICH สนับสนุน InfiniBand ผ่าน netmod (ปัจจุบันเลิกใช้แล้ว) แต่ MVAPICH2 มีการเพิ่มประสิทธิภาพอย่างกว้างขวางซึ่งทำให้การใช้งานเป็นที่ต้องการในเกือบทุกกรณี
คุณสมบัติรองรับจากมาตรฐาน MPI ล่าสุด
แกนที่ตั้งฉากกับฮาร์ดแวร์ / แพลตฟอร์มรองรับมาตรฐาน MPI ที่นี่ MPICH มักจะเหนือกว่า MPICH เป็นการนำมาตรฐาน MPI มาใช้เป็นครั้งแรกในทุก ๆ รุ่นตั้งแต่ MPI-1 ถึง MPI-3 Open-MPI เพิ่งรองรับ MPI-3 เมื่อเร็ว ๆ นี้และฉันพบว่าคุณสมบัติ MPI-3 บางอย่างมีข้อบกพร่องในบางแพลตฟอร์ม (แน่นอนว่า MPICH ไม่ใช่บั๊ก แต่ข้อบกพร่องในคุณสมบัติ MPI-3 นั้นพบได้น้อยกว่ามาก)
ในอดีต Open-MPI ไม่ได้รับการสนับสนุนแบบองค์รวมMPI_THREAD_MULTIPLEซึ่งเป็นสิ่งสำคัญสำหรับบางแอปพลิเคชัน อาจได้รับการสนับสนุนในบางแพลตฟอร์ม แต่โดยทั่วไปไม่สามารถถือว่าใช้งานได้ ในทางกลับกัน MPICH ได้รับการสนับสนุนแบบองค์รวมมาเป็นMPI_THREAD_MULTIPLEเวลาหลายปีแม้ว่าการใช้งานจะไม่ได้มีประสิทธิภาพสูงเสมอไป (โปรดดู"การล็อกมุมมองในการใช้งาน MPI หลายเธรด"สำหรับการวิเคราะห์หนึ่งครั้ง)
คุณลักษณะอื่นที่เสียใน Open-MPI 1.x คือการสื่อสารด้านเดียวหรือที่เรียกว่า RMA สิ่งนี้เพิ่งได้รับการแก้ไขเมื่อเร็ว ๆ นี้และฉันพบว่าในฐานะผู้ใช้คุณลักษณะเหล่านี้จำนวนมากโดยทั่วไปแล้วพวกเขาจะทำงานได้ดีใน Open-MPI 3.x (ดูเช่นเมทริกซ์การทดสอบ ARMCI-MPI ใน Travis CIสำหรับผลลัพธ์ที่แสดงว่า RMA ทำงานร่วมกับ การใช้งานทั้งสองอย่างอย่างน้อยก็ในหน่วยความจำที่ใช้ร่วมกันฉันเห็นผลลัพธ์เชิงบวกที่คล้ายกันบน Intel Omni Path แต่ยังไม่ได้ทดสอบ Mellanox InfiniBand
การจัดการกระบวนการ
พื้นที่หนึ่งที่ Open-MPI เคยเหนือกว่าอย่างเห็นได้ชัดคือตัวจัดการกระบวนการ การเปิดตัว MPICH (MPD) แบบเก่านั้นเปราะและใช้งานยาก โชคดีที่เลิกใช้งานไปหลายปีแล้ว (ดูรายละเอียดในรายการคำถามที่พบบ่อยของ MPICH ) ดังนั้นการวิพากษ์วิจารณ์ MPICH เนื่องจาก MPD จึงเป็นการปลอมแปลง
ตัวจัดการกระบวนการของ Hydra ค่อนข้างดีและมีความสามารถในการใช้งานและคุณสมบัติที่คล้ายกันซึ่งตั้งเป็น ORTE (ใน Open-MPI) เช่นทั้งสองสนับสนุน HWLOC สำหรับการควบคุมโทโพโลยีของกระบวนการ มีรายงานเกี่ยวกับการเปิดตัวกระบวนการ Open-MPI ที่เร็วกว่า MPICH-derivatives สำหรับงานขนาดใหญ่ (มากกว่า 1,000 กระบวนการ) แต่เนื่องจากฉันไม่มีประสบการณ์โดยตรงที่นี่ฉันจึงไม่สะดวกที่จะระบุข้อสรุปใด ๆ ปัญหาด้านประสิทธิภาพดังกล่าวมักเป็นปัญหาเฉพาะเครือข่ายและบางครั้งอาจเป็นปัญหาเฉพาะเครื่อง
ฉันพบว่า Open-MPI มีประสิทธิภาพมากขึ้นเมื่อใช้ MacOS กับ VPN กล่าวคือ MPICH อาจค้างในการเริ่มต้นเนื่องจากปัญหาการแก้ปัญหาชื่อโฮสต์ เนื่องจากเป็นข้อบกพร่องปัญหานี้จึงอาจหายไปในอนาคต
การพกพาแบบไบนารี
ในขณะที่ทั้ง MPICH และ Open-MPI เป็นซอฟต์แวร์โอเพนซอร์สที่สามารถรวบรวมได้บนแพลตฟอร์มที่หลากหลายการพกพาของไลบรารี MPI ในรูปแบบไบนารีหรือโปรแกรมที่เชื่อมโยงกันมักมีความสำคัญ
MPICH และอนุพันธ์จำนวนมากสนับสนุนความเข้ากันได้ของ ABI ( เว็บไซต์ ) ซึ่งหมายความว่าอินเทอร์เฟซไบนารีกับไลบรารีมีค่าคงที่ดังนั้นจึงสามารถรวบรวมmpi.hจากการนำไปใช้งานหนึ่งแล้วเรียกใช้กับอีกรายการหนึ่งได้ สิ่งนี้เป็นจริงแม้ในไลบรารีหลายเวอร์ชัน ตัวอย่างเช่นฉันมักจะรวบรวม Intel MPI แต่LD_PRELOADเป็นเวอร์ชันพัฒนาของ MPICH ที่รันไทม์ ข้อดีอย่างหนึ่งของความเข้ากันได้ของ ABI คือ ISV (ผู้จำหน่ายซอฟต์แวร์อิสระ) สามารถเผยแพร่ไบนารีที่รวบรวมกับสมาชิกเพียงคนเดียวในตระกูล MPICH
ABI ไม่ใช่ประเภทเดียวของความเข้ากันได้ของไบนารี สถานการณ์ที่อธิบายไว้ข้างต้นสมมติว่าผู้ใช้ใช้ตัวเรียกใช้งาน MPI เวอร์ชันเดียวกัน (โดยปกติmpirunหรือmpiexecพร้อมกับ daemons โหนดคอมพิวท์) และไลบรารี MPI ทุกที่ สิ่งนี้ไม่จำเป็นสำหรับตู้คอนเทนเนอร์
ในขณะที่เปิด MPI ไม่ได้สัญญาว่าเข้ากันได้ ABI พวกเขาได้ลงทุนอย่างมากในการสนับสนุนภาชนะบรรจุ ( เอกสาร , ภาพนิ่ง ) สิ่งนี้ต้องใช้ความระมัดระวังเป็นอย่างยิ่งในการรักษาความเข้ากันได้ในเวอร์ชันต่างๆของตัวเรียกใช้งาน MPI, ตัวเรียกใช้ตัวเรียกใช้และไลบรารี MPI เนื่องจากผู้ใช้อาจเปิดงานโดยใช้ตัวเรียกใช้ MPI เวอร์ชันใหม่กว่าตัวเรียกใช้งานในการสนับสนุนคอนเทนเนอร์ หากไม่ใส่ใจอย่างรอบคอบในความเสถียรของอินเทอร์เฟซตัวเรียกใช้งานงานคอนเทนเนอร์จะไม่เปิดขึ้นเว้นแต่ว่าเวอร์ชันของแต่ละองค์ประกอบของตัวเรียกใช้งานจะเข้ากันได้ นี่ไม่ใช่ปัญหาที่ผ่านไม่ได้:
ตัวอย่างเช่นวิธีแก้ปัญหาที่ใช้โดย Docker world คือการบรรจุโครงสร้างพื้นฐานพร้อมกับแอปพลิเคชัน กล่าวอีกนัยหนึ่งคือคุณรวม MPI daemon ไว้ในคอนเทนเนอร์ด้วยแอ็พพลิเคชันเองจากนั้นกำหนดให้คอนเทนเนอร์ทั้งหมด (รวม mpiexec) เป็นเวอร์ชันเดียวกัน วิธีนี้ช่วยหลีกเลี่ยงปัญหาเนื่องจากคุณไม่มีการดำเนินการโครงสร้างพื้นฐานข้ามเวอร์ชันอีกต่อไป
ฉันรับทราบ Ralph Castain จากทีม Open-MPI ที่อธิบายปัญหาเกี่ยวกับคอนเทนเนอร์ให้ฉันฟัง คำพูดก่อนหน้านี้เป็นของเขา
การเปรียบเทียบเฉพาะแพลตฟอร์ม
นี่คือการประเมินของฉันบนพื้นฐานทีละแพลตฟอร์ม:
Mac OS: ทั้ง Open-MPI และ MPICH ควรใช้งานได้ดี ในการรับคุณสมบัติล่าสุดของมาตรฐาน MPI-3 คุณต้องใช้ Open-MPI เวอร์ชันล่าสุดซึ่งมีให้จาก Homebrew ไม่มีเหตุผลที่จะคิดถึงประสิทธิภาพ MPI หากคุณใช้งานบนแล็ปท็อป Mac
Linux พร้อมหน่วยความจำที่ใช้ร่วมกัน: ทั้ง Open-MPI และ MPICH ควรทำงานได้ดี หากคุณต้องการเวอร์ชันรีลีสที่รองรับ MPI-3 หรือ MPI_THREAD_MULTIPLE ทั้งหมดคุณอาจต้องใช้ MPICH แม้ว่าคุณจะสร้าง Open-MPI ด้วยตัวเองเพราะเช่น Ubuntu 16.04 ให้เฉพาะเวอร์ชันโบราณ 1.10 ผ่าน APT ฉันไม่ทราบถึงความแตกต่างของประสิทธิภาพที่สำคัญระหว่างการใช้งานทั้งสอง ทั้งสองสนับสนุนการเพิ่มประสิทธิภาพสำเนาเดียวหากระบบปฏิบัติการอนุญาต
Linux กับ Mellanox InfiniBand: ใช้ Open-MPI หรือ MVAPICH2 หากคุณต้องการเวอร์ชันรีลีสที่รองรับ MPI-3 ทั้งหมดหรือMPI_THREAD_MULTIPLEคุณอาจต้องใช้ MVAPICH2 ฉันพบว่า MVAPICH2 ทำงานได้ดีมาก แต่ยังไม่ได้ทำการเปรียบเทียบโดยตรงกับ OpenMPI บน InfiniBand ส่วนหนึ่งเป็นเพราะคุณสมบัติที่ประสิทธิภาพมีความสำคัญกับฉันมากที่สุด (RMA aka one-sided) ถูกทำลายใน Open-MPI ในอดีต
Linux ที่มี Intel Omni Path (หรือรุ่นก่อนคือ True Scale): ฉันใช้ MVAPICH2, Intel MPI, MPICH และ Open-MPI ในระบบดังกล่าวและทั้งหมดใช้งานได้ Intel MPI มีแนวโน้มที่จะได้รับการปรับให้เหมาะสมที่สุดในขณะที่ Open-MPI มอบประสิทธิภาพที่ดีที่สุดของการใช้งานโอเพนซอร์สเนื่องจากมีการใช้งานแบ็คเอนด์PSM2 ที่ปรับให้เหมาะสม ฉันมีข้อสังเกตบางประการเกี่ยวกับ GitHubเกี่ยวกับวิธีสร้างการใช้งานโอเพนซอร์สที่แตกต่างกัน แต่ข้อมูลดังกล่าวหายไปค่อนข้างเร็ว
Cray หรือซูเปอร์คอมพิวเตอร์ของ IBM: MPI มาติดตั้งบนเครื่องเหล่านี้โดยอัตโนมัติและขึ้นอยู่กับ MPICH ในทั้งสองกรณี มีการสาธิต MPICH บน Cray XC40 ( ที่นี่ ) โดยใช้OFI , Intel MPI บน Cray XC40 ( ที่นี่ ) โดยใช้ OFI, MPICH บน Blue Gene / Q โดยใช้ OFI ( ที่นี่ ) และ Open-MPI บน Cray XC40 โดยใช้ทั้ง OFI และ uGNI ( ที่นี่ ) แต่ไม่มีผู้ให้บริการสนับสนุน
Windows: ฉันไม่เห็นประเด็นในการเรียกใช้ MPI บน Windows ยกเว้นผ่าน Linux VM แต่ทั้ง Microsoft MPI และ Intel MPI รองรับ Windows และใช้ MPICH ฉันเคยได้ยินรายงานการสร้าง MPICH หรือ Open-MPI ที่ประสบความสำเร็จโดยใช้Windows Subsystem สำหรับ Linuxแต่ไม่มีประสบการณ์ส่วนตัว
หมายเหตุ
ในการเปิดเผยข้อมูลทั้งหมดขณะนี้ฉันทำงานให้กับ Intel ในด้านการวิจัย / การค้นหาเส้นทาง (กล่าวคือฉันไม่ได้ทำงานกับผลิตภัณฑ์ซอฟต์แวร์ใด ๆ ของ Intel) และเคยทำงานให้กับ Argonne National Lab เป็นเวลาห้าปีซึ่งฉันทำงานร่วมกับทีม MPICH อย่างกว้างขวาง