เมื่อใดที่ฉันควรใช้เทมเพลตนิพจน์ C ++ ในวิทยาศาสตร์การคำนวณและเมื่อใดที่ฉัน * ไม่ควรใช้เทมเพลตเหล่านี้

สมมติว่าฉันกำลังทำงานกับรหัสทางวิทยาศาสตร์ใน C ++ ในการสนทนาเมื่อเร็ว ๆ นี้กับเพื่อนร่วมงานเป็นที่ถกเถียงกันอยู่ว่าเทมเพลตนิพจน์อาจเป็นสิ่งที่ไม่ดีจริงๆซึ่งอาจทำให้ซอฟต์แวร์สามารถคอมไพล์ได้ใน gcc บางรุ่นเท่านั้น สมมุติว่าปัญหานี้ส่งผลกระทบต่อรหัสทางวิทยาศาสตร์บางประการตามที่กล่าวถึงในคำบรรยายของเรื่องล้อเลียนเรื่อง Downfallการล้อเลียนของหายนะนี้(นี่เป็นเพียงตัวอย่างเดียวที่ฉันรู้ดังนั้นลิงก์)

อย่างไรก็ตามคนอื่น ๆ แย้งว่าเทมเพลตการแสดงออกมีประโยชน์เพราะพวกเขาสามารถเพิ่มประสิทธิภาพการทำงานได้เช่นเดียวกับในบทความนี้ใน SIAM Journal of Scientific Computingโดยหลีกเลี่ยงการเก็บผลลัพธ์กลางในตัวแปรชั่วคราว

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

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

คนอื่น ๆ ให้ความเห็นเกี่ยวกับปัญหาว่าการเขียนโปรแกรม ET นั้นยากเพียงใดรวมถึงความซับซ้อนของการทำความเข้าใจข้อความแสดงข้อผิดพลาด ให้ฉันแสดงความคิดเห็นในปัญหาของคอมไพเลอร์: มันเป็นความจริงที่ในขณะที่หนึ่งในปัญหาใหญ่คือการหาคอมไพเลอร์ที่เป็นไปตามมาตรฐาน C ++ พอที่จะทำให้ทุกอย่างทำงาน เป็นผลให้เราพบข้อบกพร่องมากมาย - ฉันมีรายงานข้อผิดพลาด 2-300 รายงานในชื่อของฉันกระจายผ่าน gcc, Intel icc, IBM xlC และ pgicc ของพอร์ตแลนด์ ดังนั้นสคริปต์การกำหนดค่า deal.II เป็นที่เก็บของการทดสอบข้อผิดพลาดคอมไพเลอร์จำนวนมากส่วนใหญ่ในพื้นที่ของแม่แบบประกาศเพื่อน, เนมสเปซ ฯลฯ

แต่ปรากฎว่าผู้ผลิตคอมไพเลอร์ได้รับการกระทำของพวกเขาร่วมกัน: วันนี้ gcc และ icc วันนี้ผ่านการทดสอบทั้งหมดของเราและมันเป็นเรื่องง่ายที่จะเขียนโค้ดที่พกพาได้ระหว่างสองคน ฉันจะบอกว่า PGI อยู่ไม่ไกลหลังนี้ แต่มีนิสัยใจคอมากมายที่ดูเหมือนจะไม่หายไปในช่วงหลายปีที่ผ่านมา xlC ตรงกันข้ามเป็นเรื่องที่แตกต่างกันโดยสิ้นเชิง - พวกเขาแก้ไขข้อผิดพลาดทุก ๆ 6 เดือน แต่แม้จะมีการรายงานบั๊กกับพวกเขาเป็นเวลาหลายปีความคืบหน้าก็ช้ามากและ xlC ก็ไม่สามารถรวบรวมข้อตกลงได้สำเร็จ

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

ฉันได้ทดลองกับ ET เป็นเวลานานแล้วอย่างที่คุณได้กล่าวไว้คอมไพเลอร์ยังคงดิ้นรนกับพวกเขา ฉันใช้ห้องสมุดblitzสำหรับพีชคณิตเชิงเส้นในรหัสของฉันบางส่วน ปัญหาก็คือการได้รับคอมไพเลอร์ที่ดีและในขณะที่ฉันไม่ใช่โปรแกรมเมอร์ C ++ ที่สมบูรณ์แบบการตีความข้อความผิดพลาดของคอมไพเลอร์ หลังถูกจัดการเพียงแค่ โดยเฉลี่ยแล้วคอมไพเลอร์จะสร้างข้อความแสดงข้อผิดพลาดประมาณ 1,000 บรรทัด ไม่มีทางที่ฉันจะพบข้อผิดพลาดในการเขียนโปรแกรมอย่างรวดเร็ว

คุณสามารถค้นหาข้อมูลเพิ่มเติมได้จากหน้าเว็บoonumerics (มีการประชุมเชิงปฏิบัติการ ET สองครั้ง)

แต่ฉันจะอยู่ห่างไกลจากพวกเขา ....

ปัญหาเริ่มต้นด้วยคำว่า 'expression templates (ET)' แล้ว ฉันไม่รู้ว่ามีคำจำกัดความที่แม่นยำหรือไม่ แต่ในการใช้งานทั่วไปมันก็มีหลายวิธีที่จะให้คุณแสดงโค้ดพีชคณิตเชิงเส้นและวิธีคำนวณ ตัวอย่างเช่น:

คุณรหัสการดำเนินงานของเวกเตอร์

v = 2*x + 3*y + 4*z;                    // (1)

และมันก็คำนวณโดยลูป

for (int i=0; i<n; ++i)                 // (2)
    v(i) = 2*x(i) + 3*y(i) + 4*z(i);

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

myGreatVecSum(alpha, x, beta, y, gamma, z, result);    // (3)

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

สิ่งที่ฉันอธิบายไม่มีอะไรใหม่ ในทางตรงกันข้ามมันเป็นแนวคิดเบื้องหลัง BLAS / LPACK:

• การดำเนินการที่สำคัญด้านประสิทธิภาพทั้งหมดใน LAPACK ทำได้โดยการเรียกใช้ฟังก์ชัน BLAS
• BLAS เพียงกำหนดอินเตอร์เฟสสำหรับนิพจน์พีชคณิตเชิงเส้นที่จำเป็นโดยทั่วไป
• สำหรับ BLAS การปรับใช้ที่แตกต่างกันมีอยู่

หากขอบเขตของ BLAS ไม่เพียงพอ (เช่นไม่มีฟังก์ชันเช่น (3)) ก็สามารถขยายขอบเขตของ BLAS ได้ ดังนั้นไดโนเสาร์จากยุค 60 และยุค 70 ตระหนักถึงด้วยเครื่องมือยุคหินของการแยกอินเทอร์เฟซและการนำไปปฏิบัติ เป็นเรื่องตลกที่ไลบรารีตัวเลข C ++ (ส่วนใหญ่) ไม่บรรลุคุณภาพซอฟต์แวร์ระดับนี้ แม้ว่าภาษาการเขียนโปรแกรมตัวเองมีความซับซ้อนมากขึ้น ดังนั้นจึงไม่น่าแปลกใจที่ BLAS / LAPACK ยังมีชีวิตอยู่และพัฒนาอย่างแข็งขัน

ดังนั้นในความคิดของฉัน ETs ไม่ได้ชั่วร้าย แต่วิธีที่ใช้กันทั่วไปในไลบรารีตัวเลข C ++ ทำให้พวกเขามีชื่อเสียงที่แย่มากในแวดวงการคำนวณทางวิทยาศาสตร์