ความสำเร็จและความล้มเหลวของ Ninja (2020)

• ความสำเร็จและความล้มเหลวของ Ninja

  • ราว 9 ปีก่อน ผู้เขียนได้เปิดตัว Ninja ซึ่งเป็นระบบ build ที่คล้ายกับ Make ตอนแรกก็รู้สึกเขินอยู่บ้าง แต่ตอนนี้ถูกใช้อย่างแพร่หลายแล้ว
  • โครงการหลักที่ใช้ Ninja ได้แก่ Chrome, Android และโครงการ Meson
  • Ninja เป็นโครงการโอเพนซอร์สที่ประสบความสำเร็จมากที่สุดของผู้เขียน เปิดตัวในปี 2011 โอนความเป็นเจ้าของในปี 2014 และตอนนี้ได้ส่งต่อไปยังผู้ดูแลรักษาคนที่สามแล้ว
  • ผู้เขียนได้เรียนรู้ว่าการเขียนโปรแกรมนั้น สถาปัตยกรรมสำคัญกว่าการเขียนโค้ด และประเด็นทางสังคมสำคัญยิ่งกว่าสถาปัตยกรรมอีก

• รายละเอียดทางเทคนิค

  • Ninja เป็นระบบเรียบง่ายที่รันคำสั่งตามข้อกำหนดที่ได้รับ
  • Ninja รับไฟล์ ninja.build ตรวจสอบเวลาแก้ไขของไฟล์ และรันคำสั่งที่จำเป็นแบบขนาน
  • เมื่อเทียบกับ Make แล้ว Ninja มีความสามารถของภาษาสำหรับกำหนด build ขาเข้าน้อยกว่า และเน้นการทำงานที่รวดเร็ว
  • Ninja แมปพาธของไฟล์ขาเข้าไปยังอ็อบเจ็กต์ในหน่วยความจำเพื่อเพิ่มประสิทธิภาพการเปรียบเทียบพาธ

• บันทึกด้านสถาปัตยกรรม

  • การแทนกราฟของ Ninja ใช้กราฟสองส่วนระหว่างไฟล์กับคำสั่ง เพื่อจับโครงสร้างการ build ได้ดียิ่งขึ้น
  • ใช้ข้อมูล dependency เพิ่มเติมเพื่อจัดการ dependency ของ C header
  • Ninja ไม่ใช่ daemon process แบบถาวร แต่จะเริ่มทำงานใหม่ตั้งแต่ต้นในแต่ละครั้งที่รัน
  • สถานะของไฟล์นั้นเคอร์เนลแคชไว้อยู่แล้ว จึงแทบไม่จำเป็นต้องแคชซ้ำอีกใน user space
  • Ninja ถูกออกแบบโดยอิงจากการ build ของ Chrome และกำลังเผชิญปัญหาเรื่องการขยายขนาดในโครงการขนาดใหญ่

• อุปมาแบบ 'assembler'

  • Ninja ไม่ได้พยายามทำฟังก์ชันของระบบ build หลากหลายแบบ แต่ทำเฉพาะ action graph เพื่อให้ผู้ใช้สามารถเลือกโปรแกรม generator อื่นได้
  • การออกแบบนี้ทำให้ Ninja ทั้งรวดเร็วและยืดหยุ่น

• ความสำคัญของค่าตั้งต้น

  • โดยค่าตั้งต้น Ninja จะรันคำสั่งแบบขนาน ทำให้สามารถ build แบบขนานได้อย่างปลอดภัยกว่า Make

• ความเร็ว

  • Ninja มุ่งเน้นประสิทธิภาพของ incremental build ใน codebase ขนาดใหญ่ ซึ่งมีผลต่อความพึงพอใจของผู้ใช้อย่างมาก
  • Ninja ใช้ CPU น้อยกว่า จึงช่วยปรับปรุงประสิทธิภาพของการ build โดยรวมด้วย

• CMake

  • Ninja ทำงานร่วมกับ CMake ได้ดี และการผสานรวมนี้ถูกนำไปใช้กับงานของ LLVM

• การรองรับ Windows

  • Ninja ทำงานบน Windows ได้เช่นกัน และผู้ใช้ยุคแรกจำนวนมากก็เป็นผู้ใช้ Windows

• งานที่เกี่ยวข้อง

  • การออกแบบของ Ninja ได้แรงบันดาลใจจาก blaze/bazel ซึ่งเป็นระบบ build ของ Google

• การดูแลรักษาโอเพนซอร์ส

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

• คำขอบคุณส่งท้าย

  • ผู้เขียนขอขอบคุณผู้ดูแลรักษาและผู้มีส่วนร่วมกับ Ninja

[GN⁺]

ความคิดเห็นจาก Hacker News

• มีความเห็นว่าการเขียนโปรแกรมนั้น สถาปัตยกรรมสำคัญกว่าการเขียนโค้ด และประเด็นทางสังคมสำคัญยิ่งกว่าสถาปัตยกรรม

  • บอกว่านี่เป็นการถ่ายทอดความคิดที่อยู่ในใจมานานได้อย่างชัดเจน

• Ninja มีบทบาทสำคัญในระบบบิลด์ของ Android

  • ในช่วงแรกใช้ makefiles แต่ต่อมามีความซับซ้อนขึ้นด้วยระบบบิลด์เชิงประกาศแบบคัสตอมชื่อ soong
  • Google ได้พัฒนา kati สำหรับแปลง Makefiles เป็นไฟล์บิลด์ของ Ninja
  • การย้ายไปใช้ Ninja ใช้เวลา แต่หลังจากย้ายแล้วจะทำงานได้รวดเร็ว

• มีความเห็นว่า Google เคยทำวิจัยเกี่ยวกับ latency และหวังว่างานวิจัยนี้จะถูกเผยแพร่สู่สาธารณะ

• มีความเห็นว่าเมื่อใช้ CMake ยังจำเป็นต้องใช้ Ninja สำหรับ C++20 modules จึงน่าจะยังถูกใช้งานต่อไปอีกระยะหนึ่ง

• มีการเปลี่ยนจาก Ninja ไปใช้ Samurai และบอกว่าดีขึ้นในทุกด้าน

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

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

  • บอกว่าเครื่องมือที่ยอมลดทอนความถูกต้องเพื่อความสะดวก อาจสร้างระบบนิเวศที่ถูกต้องแม่นยำกว่าได้

• มีประสบการณ์เกี่ยวกับระบบบิลด์ และบอกว่า Ninja มีขนาดเล็กพอที่จะนำไปเขียนใหม่ด้วยภาษาโปรแกรมที่ชอบได้

  • สงสัยว่ามีบทช่วยสอนแบบเป็นขั้นตอนสำหรับการสร้างระบบบิลด์ของตัวเองหรือไม่

• คิดว่าชื่อ Ninja นั้นดี และบอกว่ายังมีวิธีทำให้เร็วขึ้นได้อีก

  • อธิบายว่าเครื่องมือนี้จงใจไม่เก็บสถานะจากการรันครั้งก่อนเอาไว้