โทษประสิทธิภาพ 20% สำหรับการออกแบบซอฟต์แวร์ที่ดี

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

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

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

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

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

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

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

นักวิทยาศาสตร์ค่อย ๆ ให้ความสนใจกับข้อกำหนดทั่วไปอื่น ๆ เพิ่มเติมจากวิศวกรรมซอฟต์แวร์:

• เอกสารประกอบ (คู่มือผู้ใช้บทช่วยสอนการใส่โค้ด)
• การบำรุงรักษา (การควบคุมเวอร์ชันการทดสอบการออกแบบแบบแยกส่วน)
• ความสามารถนำกลับมาใช้ใหม่ได้ (การออกแบบแบบแยกส่วน "ความยืดหยุ่น")

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

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

แต่ถ้าคุณไม่มีเวลาในการพัฒนาเพียงพอ มีอะไรดีพอ? มันขึ้นอยู่กับว่าและไม่มีใครจะสามารถให้คำตอบที่ดีกับคำถามนี้ได้โดยไม่มีบริบทเพิ่มเติม

FWIW: ถ้าคุณสนใจที่จะเขียนเคอร์เนลเมทริกซ์กระจัดกระจายที่มีประสิทธิภาพสูงคุณควรเปรียบเทียบกับการติดตั้ง PETSc ที่ดีที่สุดและทำงานกับทีมของพวกเขาหากคุณกำลังตีพวกเขาพวกเขายินดีที่จะรวมเมล็ดที่ได้รับการปรับเข้ากับห้องสมุด

เป็นคำถามเกี่ยวกับสิ่งที่คุณใช้เวลา สำหรับพวกเราส่วนใหญ่เราใช้เวลา 3/4 ของการเขียนโปรแกรมเวลาและ 1/4 ของเวลาที่รอผล (ตัวเลขของคุณอาจแตกต่างกันไป แต่ฉันคิดว่าตัวเลขไม่สมบูรณ์หากไม่มีข้อดี) ดังนั้นหากคุณมีการออกแบบที่อนุญาตให้คุณเขียนโปรแกรมสองครั้งเร็ว (3/4 ของหน่วยเวลาแทนที่จะเป็นหน่วยเวลา 1.5 เท่า) จากนั้นคุณ สามารถใช้งานประสิทธิภาพ 300% (จากหน่วย 1/4 ถึง 1 ครั้ง) และคุณยังคงออกมาข้างหน้าในแง่ของเวลาจริงที่ใช้ในการแก้ปัญหา

ในทางกลับกันถ้าคุณทำการคำนวณหนักการคำนวณของคุณอาจดูแตกต่างและคุณอาจต้องใช้เวลามากขึ้นในการปรับรหัสให้เหมาะสม

สำหรับฉันแล้ว 20% ดูเหมือนจะเป็นการแลกเปลี่ยนที่ดีพอสมควรหากคุณประสบความสำเร็จมากขึ้น

โทษของ IMHO สูงถึง 50% (เนื่องจากเหตุผลอะไรก็ตาม) นั้นไม่เลว

ในความเป็นจริงฉันได้เห็นความแตกต่างของประสิทธิภาพ 0-30% ตามประเภทคอมไพเลอร์ สิ่งนี้มีไว้สำหรับชุดคำสั่ง MatMult แบบกระจัดกระจายของ PETSc สำหรับเมทริกซ์ที่เกิดจากการแยกส่วน FE ต่ำ

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

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