การอพยพล่าสุดในชุมชนโปรแกรมเมอร์ได้จุดประกายการถกเถียงเรื่องประสิทธิภาพของภาษาโปรแกรมขึ้นมาใหม่ โดยท้าทายสมมติฐานที่ว่าภาษาระดับต่ำที่มีการเข้าถึง pointer แบบดิบจะเป็นตัวเลือกที่เร็วที่สุดเสมอ การสนทนาครั้งนี้มุ่งเน้นไปที่ว่าภาษาโปรแกรมที่มีข้อจำกัดมากกว่าสามารถเพิ่มประสิทธิภาพได้ง่ายกว่าและอาจเร็วกว่าภาษาที่ไม่มีข้อจำกัดหรือไม่
ปรัชญาประสิทธิภาพที่ขัดแย้ง
ข้อโต้แย้งหลักชี้ให้เห็นว่าภาษาระดับต่ำสมัยใหม่อย่าง C และ C++ เผชิญกับความท้าทายในการเพิ่มประสิทธิภาพอย่างมีนัยสำคัญเนื่องจากความยืดหยุ่นของภาษาเหล่านี้ ภาษาเหล่านี้ต้องการการวิเคราะห์ alias ที่ซับซ้อนเพื่อกำหนดว่า pointer ต่างๆ อาจอ้างอิงไปยังตำแหน่งหน่วยความจำเดียวกันหรือไม่ ทำให้ compiler ยากที่จะใช้การเพิ่มประสิทธิภาพแบบรุนแรง การอภิปรายในชุมชนเผยให้เห็นปฏิกิริยาที่หลากหลายต่อข้อเรียกร้องนี้ โดยนักพัฒนาบางคนแสดงความสงสัยจากสัญญาด้านประสิทธิภาพของภาษาระดับสูงที่ไม่เป็นจริงมาหลายทศวรรษ
การแลกเปลี่ยนที่ค่อนข้างรุนแรงในชุมชนมุ่งเน้นไปที่การอ้างสิทธิ์ในอดีตเกี่ยวกับ Java ที่อาจมีประสิทธิภาพเหนือกว่า C นักพัฒนาหลายคนจำสัญญาที่คล้ายกันจากช่วงปี 2000 ที่ไม่เคยเป็นจริงอย่างสมบูรณ์ ทำให้เกิดความระแวงเกี่ยวกับการอ้างสิทธิ์การเพิ่มประสิทธิภาพใหม่ๆ อย่างไรก็ตาม คนอื่นๆ ชี้ให้เห็นว่า Java Virtual Machine ได้กลายเป็นความมหัศจรรย์ทางวิศวกรรมจริงๆ โดยทำตามสัญญาเริ่มต้นบางส่วนในบริบทเฉพาะเจาะจงอย่างระบบ backend ขององค์กร
ตัวอย่างจริงของความสำเร็จของภาษาที่มีข้อจำกัด
การอภิปรายเน้นตัวอย่างที่เป็นรูปธรรมหลายประการที่ภาษาที่มีข้อจำกัดบรรลุประสิทธิภาพที่น่าประทับใจ การเพิ่มประสิทธิภาพ stream fusion ของ Haskell สามารถเปลี่ยน nested loop ที่จัดสรร array หลายตัวตามตรรกะให้เป็นการดำเนินการที่ใช้พื้นที่คงที่โดยใช้ unboxed integer ในขณะเดียวกัน Futhark ซึ่งเป็นภาษา parallel เชิงฟังก์ชันที่เป็นเป้าหมายของ GPU แสดงให้เห็นการปรับปรุงที่เป็นลำดับขนาดเหนือ C แบบลำดับโดยการจำกัดการดำเนินการ array และไม่อนุญาต ragged array
SQL เป็นอีกตัวอย่างที่น่าสนใจ โดย query ของ PostgreSQL ทำงานเร็วกว่าเมื่อทศวรรษที่แล้วถึงสองเท่า การปรับปรุงนี้เกิดจากธรรมชาติเชิงประกาศของ SQL ซึ่งให้อิสระอย่างสมบูรณ์แก่ query planner ในการจัดระเบียบการดำเนินการใหม่เพื่อประสิทธิภาพที่เหมาะสมที่สุด
Stream fusion: เทคนิคการเพิ่มประสิทธิภาพที่กำจัดโครงสร้างข้อมูลกลางในการดำเนินการแบบลูกโซ่ Ragged arrays: Array ที่ sub-array สามารถมีความยาวต่างกันได้
ตัวอย่างการเปรียบเทียบประสิทธิภาพของภาษาโปรแกรม:
- Futhark: เร็วกว่า C แบบลำดับหลายเท่าตัวสำหรับปัญหาที่เหมาะสมกับ GPU
- PostgreSQL: ประสิทธิภาพดีขึ้น 2 เท่าในช่วงทศวรรษที่ผ่านมา
- Rust iterators: สร้าง assembly ที่เหมือนกับลูป C ที่เขียนด้วยมือพร้อมการรับประกันความปลอดภัยเพิ่มเติม
- LLVM noalias optimizations: ประสิทธิภาพดีขึ้นประมาณ 5% เมื่อใช้อย่างเหมาะสม
ทางกลางของ Rust และทิศทางในอนาคต
ชุมชนโดยทั่วไปยอมรับ Rust เป็นการประนีประนอมที่มีแนวโน้มดี โดยทำให้ raw pointer เป็นแบบ opt-in ผ่าน keyword unsafe ในขณะที่ให้ abstraction ของ iterator ระดับสูงที่ compile เป็นโค้ดที่มีประสิทธิภาพ แนวทางของ Rust อนุญาตให้เขียนโปรแกรมแบบ functional-style ด้วย closure เพื่อสร้าง assembly ที่เพิ่มประสิทธิภาพเหมือนกับ C loop ที่เขียนด้วยมือ แต่ไม่มี overhead ของการตรวจสอบขอบเขต
อย่างไรก็ตาม การอภิปรายเผยให้เห็นคำถามเชิงปรัชญาที่ลึกซึ้งเกี่ยวกับการออกแบบภาษา แทนที่จะแสวงหาภาษาสากลหนึ่งภาษา นักพัฒนาหลายคนสนับสนุนการทำงานร่วมกันที่ดีขึ้นระหว่างภาษาเฉพาะทาง วิสัยทัศน์รวมถึงภาษาเฉพาะโดเมนแบบ inline สำหรับงานต่างๆ ไม่ว่าจะเป็น Futhark สำหรับการคำนวณแบบ parallel, SQL สำหรับ query หรือ regular expression สำหรับการจับคู่รูปแบบ
ข้อจำกัดหลักของภาษาโปรแกรมมิ่ง:
- Haskell: ความโปร่งใสเชิงอ้างอิง (Referential transparency) ช่วยให้สามารถปรับปรุงประสิทธิภาพการรวมสตรีมได้อย่างก้าวร้าว
- Futhark: จำนวนเต็มขนาดคงที่แบบ unboxed ไม่มีอาร์เรย์แบบ ragged การดำเนินการอาร์เรย์ที่มีขนาดกำหนดแบบสแตติก
- SQL: ลักษณะการประกาศ (Declarative nature) ช่วยให้ตัววางแผนคิวรีมีอิสระในการปรับปรุงประสิทธิภาพ
- Rust: พอยเตอร์ดิบแบบ opt-in ผ่าน
unsafeการแยกแยะตัววนซ้ำ (iterator abstractions) สำหรับการกำจัดการตรวจสอบขอบเขต
ความท้าทายทางเทคนิคและข้อจำกัดของ Compiler
ส่วนสำคัญของการอภิปรายในชุมชนเจาะลึกเข้าไปในความท้าทายการใช้งานทางเทคนิค การสนทนาเผยให้เห็นว่าการเพิ่มประสิทธิภาพ noalias ของ LLVM ยังคงมีข้อบกพร่องมาหลายปีเนื่องจากนักพัฒนา C และ C++ ไม่ค่อยใช้อย่างถูกต้อง เมื่อ Rust ทำให้การเพิ่มประสิทธิภาพเหล่านี้ใช้งานได้อย่างถูกต้องอย่างง่ายดาย ข้อบกพร่องจึงปรากฏขึ้นและได้รับการแก้ไข ซึ่งท้ายที่สุดให้การปรับปรุงประสิทธิภาพประมาณ 5%
การถกเถียงยังสัมผัสกับการเพิ่มประสิทธิภาพระดับฮาร์ดแวร์ ที่ null-terminated string สามารถมีประสิทธิภาพเหนือกว่า length-prefixed string ในการดำเนินการ SIMD เนื่องจากวิธีที่โปรเซสเซอร์จัดการกับการตรวจสอบ zero-flag เทียบกับการเปรียบเทียบความยาว ความเป็นจริงของฮาร์ดแวร์เหล่านี้เน้นให้เห็นว่าทำไมระบบที่เพิ่มประสิทธิภาพ C มักรักษาข้อได้เปรียบด้านประสิทธิภาพ
บทสรุป
แม้ว่าชุมชนโปรแกรมเมอร์ยังคงแบ่งแยกเกี่ยวกับว่าภาษาที่มีข้อจำกัดจะส่งมอบสัญญาการเพิ่มประสิทธิภาพหรือไม่ การอภิปรายเผยให้เห็นความก้าวหน้าที่แท้จริงในโดเมนเฉพาะ ข้อมูลเชิงลึกสำคัญอาจไม่ใช่การหาภาษาอเนกประสงค์ที่สมบูรณ์แบบ แต่เป็นการสร้างเครื่องมือที่ดีกว่าสำหรับการรวมภาษาที่เหมาะสมสำหรับงานเฉพาะแต่ละอย่างอย่างราบรื่น เมื่อความท้าทายในการเพิ่มประสิทธิภาพกลายเป็นเรื่องซับซ้อนมากขึ้น การแลกเปลี่ยนระหว่างการแสดงออกและประสิทธิภาพยังคงพัฒนาต่อไป โดยข้อจำกัดอาจเสนอเส้นทางใหม่สู่ความเร็วแทนที่จะเป็นอุปสรรค