ภาษาการเขียนโปรแกรมที่ใช้มากที่สุดในการคำนวณประสิทธิภาพสูงคืออะไร? และทำไม? [ปิด]

ฉันเชื่อว่ามีการใช้ Fortran จำนวนมากใน HPC แต่ไม่แน่ใจว่าเป็นเพราะเหตุผลดั้งเดิมเท่านั้น

คุณสมบัติของภาษาการเขียนโปรแกรมสมัยใหม่เช่นการรวบรวมขยะหรือความหลากหลายในเวลาทำงานไม่เหมาะสำหรับ HPC เนื่องจากความเร็วมีความสำคัญดังนั้นจึงไม่แน่ใจว่าที่ C # หรือ Java หรือ C ++ เข้ามา

ความคิดใด ๆ

ฉันได้เห็น Java จำนวนมากที่ใช้สำหรับ HPC ในพื้นที่ที่ (1) มีรหัสดั้งเดิมเล็กน้อยและ (2) เวลาในการพัฒนาและเรื่องคุณภาพของรหัส โดเมนแอปพลิเคชันทั่วไปคือการเงินการขุดข้อมูลหรือสารสนเทศชีวภาพ

มันขึ้นอยู่กับแอปพลิเคชัน (มีชีวิตนอกพีชคณิตเชิงเส้น) แต่ประสิทธิภาพของ JVMs ล่าสุดนั้นมักจะเทียบเท่ากับรหัส C บางครั้งเร็วขึ้นเมื่อ JVM สามารถดำเนินการที่ optimisations ฉลาด runtime ที่คอมไพเลอร์แบบคงที่ (C, Fortran) ไม่สามารถทำ และเร็วขึ้นแน่นอนเมื่อมีการคำนวณสัญลักษณ์มากมาย

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

คุณจะพบการอ้างอิงในhttp://ateji.blogspot.com/2010/09/java-for-high-performance-computing.html

เกี่ยวกับสมมติฐานของ Fortran ว่าที่อยู่สองรายการนั้นไม่ซ้ำกันเรากำลังทำงานกับเครื่องมือวิเคราะห์แบบคงที่ซึ่งจะช่วยให้การปรับให้เหมาะสมสำหรับโค้ดในภาษาระดับสูงคล้ายกัน แต่ไม่มีบิต "สิ่งต่าง ๆ อาจเกิดขึ้น" ติดต่อฉันหากสนใจ

ในประสบการณ์ของฉันนานถึง 5 ปีที่ผ่านมามันเป็นฟอร์แทรนและซีเสมอซึ่งขึ้นอยู่กับว่าคนส่วนใหญ่มาจากวิศวกรรมหรือมากกว่าจากโรงเรียนคิด CS (ฉันไม่รู้วิธีที่จะทำให้ดีขึ้น ตกลงได้ไหม :-)

ในสิ่งที่เราทำ Fortran เกือบจะถูกนำมาใช้โดยเฉพาะ

จากสิ่งที่ฉันอ่านไปทุกวันนี้ด้วยการอัพเดทใหม่สำหรับ Standard F2003 / 08 และด้วยการแนะนำ Co-Arrays ดูเหมือนว่าจะได้รับแรงกระตุ้นอีกครั้ง

นอกจากนี้บทความหนึ่งถ้าไม่ได้ค่อนข้างลำเอียง - ภาษา HPC ในอุดมคติ

ฉันคิดว่าจริง ๆ แล้วเหยียบกับโลหะทางเลือกเดียวที่แท้จริงคือ Fortran เหตุผลก็คือสิ่งที่สำคัญที่สุดสำหรับการเอารัดเอาเปรียบของ ILP ระดับต่ำ (Instruction Level Parallism) คือการแก้ปัญหาความจำที่อยู่ในหน่วยความจำ กฎ defacto ใน Fortran อนุญาตให้คอมไพเลอร์ตรวจสอบว่าที่อยู่สองรายการนั้นไม่ซ้ำกัน (และด้วยเหตุนี้คำสั่งของการโหลดและการจัดเก็บหรือแม้แต่ร้านค้าและร้านค้าก็สามารถแลกเปลี่ยนได้โดยไม่เสี่ยงต่อการสร้างรหัสที่ไม่ถูกต้อง) C ปล่อยขอบเขตมากเกินไปสำหรับการพอยน์เตอร์ที่ทับซ้อนกันสำหรับคอมไพเลอร์เพื่อแยกการขนานในระดับต่ำมากจากโค้ด

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

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

เพียงแค่บันทึกเล็ก ๆ น้อย ๆ ฉันไม่ได้ทำการคำนวณประสิทธิภาพสูงเลย

สำหรับการคำนวณ (การบดตัวเลข) Fortran และ C ใช่สำหรับเหตุผลดั้งเดิม:

• ความพร้อมใช้งานที่เพียงพอของรหัสที่มาโดเมนสาธารณะและสูตรอาหาร
• ทั้งการสนับสนุนMPI
• ทั้งสองภาษารวบรวม
• คอมไพเลอร์สำหรับทั้งสองภาษาจัดทำโดย HPC OS และผู้ขายทั้งหมด
• Vectorizing คอมไพเลอร์พร้อมใช้งาน
• ทั้งสองต้องการระดับการปรับแต่งอย่างบ้าคลั่งเพื่อให้ได้ประสิทธิภาพสูงเมื่อย้ายไปยังคลัสเตอร์อื่น (ขนาดหน่วยความจำที่แตกต่างกันจำนวนซีพียู ฯลฯ )
  • สิ่งนี้อธิบายได้ว่าทำไมรหัสโอเพนซอร์ซจึงมีความสำคัญ: จำเป็นต้องมีการปรับแต่งดังนั้นสูตรดั้งเดิมจะต้องเขียนเป็นภาษาที่ดีสำหรับการปรับแต่งด้วยตนเอง

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

แนวโน้มที่สองคือการเขียนในภาษาเฉพาะของ C สำหรับ GPU หรือ Cell BE

สำหรับงานที่ไม่ใช่ตัวเลขเช่นโปรแกรมที่ประมวลผลข้อมูลจากฐานข้อมูล (แต่ไม่ใช่ตัวฐานข้อมูลเอง) มันถูกกว่ามากในการทำงานบนกลุ่มของ "สินค้า" โดยไม่มีอุปกรณ์ระบบเครือข่ายที่กำหนดเองราคาแพง ซึ่งมักเรียกว่า "การรับส่งข้อมูลสูง" และ Python เป็นภาษาอันดับ 1 ที่นี่ (ใช้การย่อแผนที่ที่มีชื่อเสียง) ก่อนที่จะมีงูหลาม, โครงการการประมวลผลชุดสามารถเขียนในภาษาใด ๆ และมักจะถูกส่งโดยแร้ง

ฉันทำงานกับโค้ดที่ต้องใช้การคำนวณจำนวนมากใน (gasp!) C #

ฉันกำลังสร้างการใช้งาน GPGPU ของFDTDสำหรับการสร้างแบบจำลองทางแสง ในคลัสเตอร์ขนาดเล็ก (128 โปรเซสเซอร์) การจำลองสถานการณ์ของเราใช้เวลาหลายสัปดาห์ในการรัน อย่างไรก็ตามการใช้งาน GPU นั้นมีแนวโน้มที่จะทำงานได้เร็วขึ้นประมาณ 50x และอยู่ในการ์ด NVidia ระดับผู้บริโภค ตอนนี้เรามีเซิร์ฟเวอร์ที่มีการ์ดโปรเซสเซอร์คู่ GTX295 สองตัว (หลายร้อยคอร์) และกำลังได้รับเทสลาสบางตัวในไม่ช้า

สิ่งนี้เกี่ยวข้องกับภาษาของคุณอย่างไร ในทำนองเดียวกับที่รหัส C ++ FDTD ที่เราใช้ก่อนหน้านี้คือ CPU-bound เหล่านี้เป็น GPU-bound ดังนั้นความแตกต่างของแรงม้าที่มีขนาดเล็กมากของการจัดการกับ native code ไม่ได้เกิดขึ้น แอป C # ทำหน้าที่เป็นตัวนำ - การโหลดเมล็ด OpenCL ส่งผ่านข้อมูลไปยังและจาก GPU จัดหาส่วนต่อประสานผู้ใช้การรายงานและอื่น ๆ - งานทั้งหมดที่มีความเจ็บปวดในตูดใน C ++

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

นอกจากนี้ความแตกต่างด้านประสิทธิภาพส่วนใหญ่ของคุณไม่ได้มาจากภาษาที่คุณเลือก แต่มาจากทักษะของนักพัฒนาซอฟต์แวร์ของคุณ ไม่กี่สัปดาห์ที่ผ่านมาฉันย้ายการดำเนินการส่วนเดียวจากภายในของการวนซ้ำสามแถว (traversal อาร์เรย์แบบสามมิติ) ซึ่งลดเวลาการดำเนินการสำหรับโดเมนการคำนวณที่กำหนด 15% นั่นเป็นผลมาจากสถาปัตยกรรมตัวประมวลผล: การหารช้าซึ่งเป็นหนึ่งในใบหน้าที่คุณต้องหยิบขึ้นมาที่ไหนสักแห่ง

Fortran เป็นเรื่องธรรมดาส่วนใหญ่เนื่องมาจากมรดก (คนยังคงใช้รหัสเก่า) และความคุ้นเคย (คนส่วนใหญ่ที่ทำ HPC ไม่คุ้นเคยกับภาษาประเภทอื่น ๆ )

คุณสมบัติของภาษาการเขียนโปรแกรมสมัยใหม่เช่นการรวบรวมขยะหรือความหลากหลายในเวลาทำงานไม่เหมาะสำหรับ HPC เนื่องจากความเร็วมีความสำคัญดังนั้นจึงไม่แน่ใจว่าที่ C # หรือ Java หรือ C ++ เข้ามา

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

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

Fortran สำหรับเหตุผลที่ดีและเหตุผลที่ไม่ดี สำหรับ crunching ทางคณิตศาสตร์อย่างหนักเหตุผลที่ดีคือมีรูทีนย่อยมากมาย (BLAS, LAPACK) ของรูทีนย่อยแบบลองและจริงทั้งหมดที่เขียนใน Fortran (แม้ว่าจะสามารถเรียกได้จาก C และ C ++)

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

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

โดยพื้นฐานแล้วโปรแกรมทั้งหมดที่ใช้ในการทำงานจริงของการบีบอัดตัวเลขยังคงเป็น FORTRAN (เช่น blas, lapack, arnoldi และอื่น ๆ ที่ยังใช้อยู่) ... อย่างไรก็ตามเมื่อมาถึงโครงสร้างระดับที่สูงขึ้น ... ผู้คนกำลังใช้งานมากขึ้น C ++

ความซับซ้อนของการจำลองนั้นเกี่ยวข้องกับรหัสขนาดใหญ่และการได้รับผลประโยชน์ใด ๆ จากการเขียนสิ่งหนึ่งคือการทำให้มันสามารถใช้ซ้ำได้ นอกจากนี้แนวคิดที่ใช้ก็มีความซับซ้อนเช่นกัน เกือบบ้าคลั่งที่จะแสดงข้อมูลนั้นโดยใช้ FORTRAN นั่นคือสิ่งที่ C ++ เข้ามาเนื่องจากมันสนับสนุนการออกแบบเชิงวัตถุ อย่างไรก็ตาม Run-Time Polymorphism ไม่ค่อยเป็นที่ต้องการ คนส่วนใหญ่มักจะใช้ Static Polymorphism แทน (ซึ่งนำไปใช้ใน C ++ ด้วยเทมเพลต meta-programming)

นอกจากนี้คอมไพเลอร์ก็ดีจริง ๆ ดังนั้นการเพิ่มประสิทธิภาพจำนวนมากจึงถูกทิ้งให้คอมไพเลอร์

มีปัญหาสองประเภทที่ต้องแก้ไขในแอปพลิเคชัน HPC: หนึ่งคือหมายเลขที่กระทืบตัวเองและอีกปัญหาหนึ่งคือการจัดการการคำนวณ คนแรกมักจะเข้าหากับโค้ดที่เขียนใน Fortran, C หรือ C ++ เนื่องจากความเร็วและเนื่องจากความจริงที่ว่ามีอัลกอริทึมทางวิทยาศาสตร์จำนวนมากที่เขียนในภาษานี้แล้ว การบังคับการคำนวณถูกนำไปใช้อย่างสะดวกยิ่งขึ้นในภาษาระดับสูงกว่า Python เป็นภาษาที่ "กาว" ของทางเลือกสำหรับการจัดการตรรกะแอปพลิเคชันและส่วนขยายการโทรที่ใช้ในภาษาที่รวบรวม Java ใช้บ่อยโดยโครงการที่จัดการเครือข่ายและการคำนวณแบบกระจายเป็นสิ่งจำเป็น