ศิลปะแห่งการประมวลผลสมรรถนะสูง

 (theartofhpc.com)
3 คะแนน โดย GN⁺ 2023-12-31 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • The Art of HPC เป็นชุดตำราเกี่ยวกับการประมวลผลสมรรถนะสูงที่จัดทำโดย Victor Eijkhout แห่ง TACC โดยรวบรวมเนื้อหาตั้งแต่พื้นฐานของ scientific computing ไปจนถึงการเขียนโปรแกรมแบบขนานและเครื่องมือพัฒนาไว้ในลำดับเดียวกัน
  • เล่มแรกเป็น หนังสือพื้นฐานด้าน scientific computing ที่อธิบายว่าสถาปัตยกรรมคอมพิวเตอร์ เลขคณิต พีชคณิตเชิงเส้น และ ODE/PDE ทำงานเชื่อมโยงกันอย่างไรในการคำนวณขนาดใหญ่
  • เล่มที่สองอธิบาย MPI และ OpenMP เป็นหลักสำหรับการเขียนโปรแกรมแบบขนาน และยังมี PETSc, Kokkos, Sycl, Co-array Fortran รวมอยู่แบบสั้น ๆ
  • เล่มที่สามกล่าวถึง C++17 และ Fortran2008 ที่ใช้ในงานเขียนโปรแกรมด้านวิทยาศาสตร์และวิศวกรรม โดยเหมาะทั้งสำหรับผู้เริ่มต้นและโปรแกรมเมอร์ C
  • เล่มที่สี่แนะนำ เครื่องมือเวิร์กโฟลว์การพัฒนา ที่จำเป็นต่อการทำงาน HPC จริง เช่น คอมไพเลอร์ ระบบบิลด์ และการจัดการซอร์สโค้ด

โครงสร้างชุดตำรา The Art of HPC

  • The Art of HPC เป็นชุดตำราเกี่ยวกับการประมวลผลสมรรถนะสูงที่จัดทำโดย Victor Eijkhout แห่ง TACC
  • ชุดนี้แบ่งเนื้อหาเป็นรายเล่ม ครอบคลุมพื้นฐาน scientific computing, การเขียนโปรแกรมแบบขนาน, ภาษาสำหรับการเขียนโปรแกรมเชิงวิทยาศาสตร์ และระบบนิเวศการพัฒนา HPC

ขอบเขตของแต่ละเล่ม

  • Volume 1: The Science of Computing

    • ครอบคลุมความรู้พื้นฐานทั่วไปที่จำเป็นต่อการทำความเข้าใจ scientific computing
    • มีเนื้อหาเกี่ยวกับสถาปัตยกรรมคอมพิวเตอร์, สถาปัตยกรรมคอมพิวเตอร์แบบขนาน, เลขคณิตคอมพิวเตอร์, พีชคณิตเชิงเส้น และ ODE/PDE
    • อธิบายว่าองค์ประกอบแต่ละส่วนเชื่อมกันอย่างไรใน การคำนวณขนาดใหญ่ และเมื่ออ่านคู่กับ Volume 2 จะกลายเป็นส่วนของ “what/why” และ “how” ของ HPC

  • Volume 2: Parallel Programming for Science and Engineering

    • เป็นเล่มที่ว่าด้วย การเขียนโปรแกรมแบบขนาน ซึ่งมีความสำคัญต่อ scientific computing
    • แนะนำโดยเน้น MPI และ OpenMP เวอร์ชันสมัยใหม่เป็นหลัก
    • มีส่วนสั้น ๆ เกี่ยวกับ PETSc, Kokkos, Sycl, Co-array Fortran ด้วย
    • MPI และ OpenMP ครอบคลุมในภาษา C, Fortran, C++ และสำหรับ MPI ยังรวม Python ด้วย

  • Volume 3: Introduction to Scientific Programming

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

  • Volume 4: HPC Carpentry

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-12-31
ความคิดเห็นจาก Hacker News

  • แง่มุมด้าน ฮาร์ดแวร์/ศูนย์ข้อมูล ของหัวข้อนี้ก็น่าสนใจไม่แพ้กัน
    เมื่อก่อนผมเคยทำงานฝั่งซอฟต์แวร์/บริการที่ AWS และบางครั้งก็แอบไปฟังพรีเซนต์ของทีมศูนย์ข้อมูล
    สิ่งที่ได้ตระหนักครั้งใหญ่ที่สุดคือ การเพิ่มขีดความสามารถในการประมวลผลในศูนย์ข้อมูลนั้นใกล้เคียงกับ ปัญหาเทอร์โมไดนามิกส์ มากกว่าการคอมพิวติ้งจริง ๆ ความหนาแน่นของโหนดสูงขึ้นมากจนการป้อนพลังงานเข้าไปและระบายความร้อนออกมา รวมถึงการเพิ่มระบบสำรองซ้ำซ้อนต่าง ๆ กลายเป็นเรื่องยากสุด ๆ ต่อให้พบความไม่มีประสิทธิภาพ ก็ไม่ได้แก้ได้เหมือนอัปเดตซอฟต์แวร์
    เรื่องนี้เป็นเมื่อราว 10 ปีก่อน ตอนนี้อาจมีหลายอย่างเปลี่ยนไปแล้ว แต่ก็น่าทึ่งที่ Amazon ซึ่งเริ่มจากร้านหนังสือออนไลน์ กลับมาอยู่แนวหน้าของการแก้ปัญหาเทอร์โมไดนามิกส์

    • Seymour Cray พูดไว้ตั้งแต่ทศวรรษ 1970 แล้วว่าปัญหาที่ใหญ่ที่สุดคือ การระบายความร้อน
      ใน Cray-2 เขาเลือกวิธีที่สุดขั้วยิ่งกว่า โดยใช้โครงสร้างระบายความร้อนที่นำกองแผงวงจรหนาแน่นไปแช่ในของเหลวพิเศษที่ไม่นำไฟฟ้าชื่อ Fluorinert™: “The Cray-2's unusual cooling scheme immersed dense stacks of circuit boards in a special non-conductive liquid called Fluorinert™”
    • ผมสงสัยมาตลอดว่าทำไม การระบายความร้อนด้วยของเหลว ถึงยังไม่ถูกใช้อย่างแพร่หลายในศูนย์ข้อมูลมากกว่านี้
      น้ำมีความจุความร้อนสูงมาก และสามารถทำความเย็นปริมาณมากได้อย่างรวดเร็วถึงอุณหภูมิที่เหมาะสม แม้ยังต้องใช้พัดลมและเครื่องปรับอากาศเพื่อดึงความร้อนออกจากชิ้นส่วนที่ไม่สามารถใช้ของเหลวระบายความร้อนได้ แต่สำหรับชิ้นส่วนที่กินไฟมากอย่าง CPU หรือ GPU/เอนจินประมวลผล ก็สามารถดึงความร้อนมหาศาลออกมาได้อย่างรวดเร็วและโดยตรง
      ความซับซ้อนและความเสี่ยงจากการรั่วไหลก็เป็นปัญหาอยู่ แต่สำหรับศูนย์ข้อมูลในระดับ Amazon ผมคิดว่าไม่น่าจะเป็นเรื่องที่ต้องกังวลมากขนาดนั้น
    • มีข้อมูลหรือภาพ visualization ดี ๆ ที่แสดงขนาดของปัญหานี้ไหม?
      อยากรู้ว่าเทคโนโลยีระบายความร้อนที่ล้ำหน้าที่สุดมีหน้าตาเป็นอย่างไร

  • น่าสนใจที่บางครั้ง HPC ดูเหมือนถูกทำให้เป็นนามธรรมออกห่างจากฮาร์ดแวร์ไปพอสมควร
    หนังสือต่าง ๆ ดูเหมือนจะพูดถึงการเขียนโปรแกรมแบบ SPMD, อัลกอริทึมและโครงสร้างข้อมูล, task parallelism, การซิงโครไนซ์ ฯลฯ อยู่มาก แต่รายละเอียดด้าน สถาปัตยกรรมคอมพิวเตอร์ เช่น ระบบย่อยหน่วยความจำของซูเปอร์คอมพิวเตอร์, การเชื่อมต่อแบนด์วิดท์สูงอย่าง CXL, โครงสร้าง GPU กลับดูมีน้อย
    เลยสงสัยว่า abstraction และเครื่องมือต่าง ๆ ดีพอแล้วจนไม่ต้องสนใจรายละเอียดพวกนี้หรือไม่ หรือจริง ๆ แล้วผู้ปฏิบัติงาน HPC ต้องปรับ knob แบบกล่องดำกันเยอะเพื่อรีดประสิทธิภาพออกมา

    • ใน HPC ส่วนใหญ่ หากไม่เข้าใจ โครงสร้างและพฤติกรรมของฮาร์ดแวร์ อย่างลึกซึ้ง ก็ไม่สามารถเพิ่ม parallelism และ throughput ให้ถึงขีดสุดได้
      ตามหลักทั่วไป เพื่อให้ได้ scalability ที่ดีที่สุด topology ของซอฟต์แวร์ควรสอดคล้องกับ topology ของฮาร์ดแวร์ให้มากที่สุด ซอฟต์แวร์ HPC ที่มีประสิทธิภาพได้รับอิทธิพลจากคุณลักษณะของฮาร์ดแวร์อย่างมาก
      เวลาต้องเขียนโค้ดสำหรับฮาร์ดแวร์ HPC ใหม่ ๆ ผู้คนมักแปลกใจเสมอเมื่อผมขอเอกสารระบบฮาร์ดแวร์และสถาปัตยกรรม แทนที่จะขอเอกสารการเขียนโปรแกรม เมื่อเข้าใจการออกแบบฮาร์ดแวร์แล้ว การจะออกแบบซอฟต์แวร์บนฮาร์ดแวร์นั้นอย่างไรก็ชัดเจนขึ้นจาก first principles เอกสารการเขียนโปรแกรมมีความจริงเพียงครึ่งเดียวอยู่ไม่น้อย เพื่อทำให้นักพัฒนารู้สึกว่ามันง่ายกว่าความเป็นจริง
      แพลตฟอร์ม HPC บางตัวพยายามทำให้ดูว่า “ใช้ง่าย” จึงสื่อสารอย่างผิด ๆ อยู่เรื่อย ๆ ว่านักพัฒนาต้องทำอะไรเพื่อให้ได้ประสิทธิภาพสูงสุด และถ้าเขียนซอฟต์แวร์ตามแบบที่การตลาดบอกเป็นนัย ก็ไม่สามารถดึงประสิทธิภาพที่ซิลิคอนทำได้ออกมา จนล้มเหลวอย่างหนักในบางกรณี
      สามารถเขียนโค้ด HPC บน abstraction ได้ และในทางปฏิบัติก็มีคนทำเช่นนั้นมาก แต่การสูญเสียด้านประสิทธิภาพและ scalability มักหลีกเลี่ยงไม่ได้ในระดับเป็นจำนวนเท่าตัว เช่นเดียวกับซอฟต์แวร์อื่น ๆ หากมันช่วยให้นักพัฒนาที่มีทักษะน้อยกว่าสามารถออกแบบโค้ดได้ ความสูญเสียแบบนี้ก็มักถูกยอมรับได้
      HPC ก็เหมือนซอฟต์แวร์อื่น ๆ คือมีคนจำนวนมากที่แม้จะมีชื่อตำแหน่งว่าเป็นนักพัฒนามืออาชีพ แต่ก็ยังทำผลงานที่ดีอย่างสม่ำเสมอได้ยาก ฮาร์ดแวร์ราคาแพงจำนวนมากที่ใช้ใน HPC มีอยู่เพื่อบรรเทาการสูญเสียประสิทธิภาพที่เกิดจากการออกแบบซอฟต์แวร์ที่แย่
      หากต้องการประสิทธิภาพสูงสุด ไม่มีทางลัดอื่นนอกจากต้องเข้าใจจริง ๆ ว่าฮาร์ดแวร์ทำงานอย่างไร ไม่ต่างจากซอฟต์แวร์ทั่วไป เพียงแต่ใน HPC ระบบฮาร์ดแวร์ใหญ่และซับซ้อนกว่าเท่านั้น
    • ผมเริ่มทำงาน HPC เมื่อราว 2 ปีก่อนใน คลัสเตอร์ประมาณ 500 โหนด ของบริษัท Fortune 100 จริง ๆ แล้วตอนนั้นกำลังหางานที่ทำ Linux 100% และจนถึงตอนนี้ก็ยังสนุกดี
      แต่มันต่างจากที่คาดไว้ คิดว่าจะได้ทำงานที่เน้นประสิทธิภาพมากกว่านี้ วิเคราะห์ตัวเลข และรีดประสิทธิภาพหยดสุดท้ายจากคลัสเตอร์ พูดตรง ๆ คือช่วงแรกแม้แต่ระบบมอนิเตอร์ก็ยังไม่มี ผมสร้างขึ้นมาเอง แต่แทบไม่มีใครใช้ นาน ๆ ทีผู้บริหารจะถามว่า “คลัสเตอร์ยุ่งแค่ไหน” ด้วยเหตุผลอย่างการชี้แจงงบประมาณ
      ‘การปรับแต่ง’ ส่วนใหญ่คือคอยตรวจว่าคนไม่ได้ขอ CPU 384 ตัวทั้งที่สคริปต์ใช้แค่ 16 ตัว หรือทดสอบว่าซอฟต์แวร์บางตัวทำงานได้ถึง CPU กี่ตัวโดยไม่เกิดประสิทธิภาพตก ผมเปิด Intel profiler แค่สองครั้งเท่านั้น
      งานส่วนใหญ่ใกล้เคียงกับการช่วยงานนักวิจัยมากกว่า ปกติก็คือรันโปรแกรมเชิงพาณิชย์หรือโอเพนซอร์สแล้วแก้ปัญหา หรือเอาโค้ดที่ทีมอื่นเขียนบนคลัสเตอร์อื่นมาบิลด์และรันบนคลัสเตอร์ของเราให้ได้ ต้องขุดโค้ด Python แย่ ๆ และพยายามบิลด์โปรเจ็กต์ C++ ที่มาจากคลัสเตอร์สมัยใหม่กว่าให้ทำงานในสภาพแวดล้อม CentOS 7
      มันก็สนุกในแบบของมัน เพราะผมเคยทำหลายภาษา จึงชอบทำให้อะไรสักอย่างทำงานได้ และขุดดู crash กับ stack trace พอทำงานกับเครื่องใหญ่ ๆ มาตรฐานความปกติก็เพี้ยนไป เวลาเห็นเซิร์ฟเวอร์ที่มี RAM ‘แค่’ 128GB หรือดิสก์ 20TB
      สิ่งที่น่ากลัวคือผลลัพธ์เหล่านี้ถูกนำไปใช้ในโลกจริง แต่บางครั้งคนที่รัน simulation กลับทำไม่ถูกต้อง ผมเคยเจอโค้ดผิด ๆ, ซอร์สโค้ดปะปนกัน, ใช้ข้อมูลคนละชุดกับที่พวกเขาคิดว่ากำลังใช้ และบั๊กขนาดใหญ่ที่มีอยู่มาถึง 3 ปี พอเป็นแบบนั้นก็อดคิดไม่ได้ว่างานทั้งหมดที่ทำมาในหัวข้อนั้นจะกลายเป็นโมฆะไปหรือเปล่า
      ข้อเสียคือ งาน HPC จำนวนมากต้องการ ปริญญาโท ทั้งที่งานเป็นแค่การดูแลคลัสเตอร์ ผมไม่ค่อยเข้าใจนัก ผมไม่ได้เขียนซอฟต์แวร์ที่รันอยู่ และไม่ได้ดูแลคลัสเตอร์ TOP500 รุ่นล่าสุด แค่เอาเครื่องหลาย ๆ ตัวมาต่อเครือข่ายแล้วรันโค้ดเท่านั้น
    • มี abstraction อยู่มากก็จริง แต่หากจะรู้ว่า ควรใช้ abstraction แบบไหน ก็ยังต้องรู้เรื่องฮาร์ดแวร์อยู่มาก
      จากประสบการณ์ที่ทำงานกับนักพัฒนา CUDA พวกเขาปรับ knob กันเยอะเพื่อดึงประสิทธิภาพออกมา Shmoo Plot(https://en.wikipedia.org/wiki/Shmoo_plot, ในบางอุตสาหกรรมเรียกว่า ‘wedge’ ด้วย) เป็นหนึ่งในเครื่องมือหลักของการปรับแต่งประจำวัน
      แต่ผมก็ไม่แน่ใจว่าจะเรียกสิ่งนี้ว่ากล่องดำได้ไหม ผลลัพธ์อาจคล้ายกันก็ได้ แม้จะรู้ว่า knob ทำอะไรและทำงานอย่างไร และคาดเดาอย่างมีเหตุผลแล้ว พอวัดจริงก็มักเจอเรื่องน่าประหลาดใจใหญ่ ๆ อยู่บ่อย ๆ กฎข้อแรกของการปรับแต่งคือการวัด
      ผมนึกถึงบทแรก “The Best Optimizer is Between Your Ears” ใน “Black Book” ของ Michael Abrash http://twimgs.com/ddj/abrashblackbook/gpbb1.pdf อยู่เสมอ แม้จะเน้นเกม PC มากกว่า HPC สมัยใหม่ แต่เป็นบทความยอดเยี่ยมที่แสดงปรัชญาด้านประสิทธิภาพสูงได้ดี
      เมื่อพูดถึง abstraction การจูน knob หนัก ๆ ควรทำในช่วงท้ายของกระบวนการปรับแต่ง เพราะถ้า refactor หรือเปลี่ยนอะไรบางอย่าง ก็ต้องจูน knob ใหม่ การเปลี่ยนแปลงเล็กน้อยของ register spill หรือรูปแบบการเข้าถึง cache ก็อาจทำให้การจูนละเอียดอย่างการจัด thread, cache, ขนาด shared memory ต้องเริ่มใหม่ทั้งหมด
      ถึงอย่างนั้น ระหว่างทางก็ยังจำเป็นต้องจูน knob ในปริมาณที่เหมาะสม เพื่อใช้ตรวจสอบ ถ่วงดุล และสร้างสัญชาตญาณเกี่ยวกับพื้นที่ด้านประสิทธิภาพรอบ ๆ โค้ด
    • ในฐานะผู้ดูแล HPC ผมมักสนับสนุนนักวิจัยในกลุ่ม “long tail of science”
      บนฮาร์ดแวร์ x86_64 ทุกวันนี้ ไม่มีสิ่งที่เรียกว่า ระบบย่อยหน่วยความจำของซูเปอร์คอมพิวเตอร์ อะไรแบบนั้น มันก็แค่ระบบ NUMA ที่หรูหรา และปัญหาใหญ่ที่สุดคือการวางหน่วยความจำไว้ใกล้คอร์ หรือก็คือรักษาข้อมูลให้อยู่ภายใน NUMA node นั้นแบบ local เพื่อลด latency
      การแมปทรัพยากรเป็นหน้าที่ของ scheduler โดย scheduler รู้จักฮาร์ดแวร์ จึงสร้าง cgroup ที่ตอบโจทย์ข้อกำหนดและถูก optimize เท่าที่เป็นไปได้ แล้วนำแอปพลิเคชันไปใส่ใน cgroup นั้นเพื่อรัน

ปัจจุบันราชาแห่ง interconnect ประสิทธิภาพสูงคือ InfiniBand และมันเร่ง MPI ในระดับ fabric ได้ การส่งข้อความ การ broadcast และการ reduce ผลลัพธ์ทำได้เร็วมาก เมื่อข้อความมาถึงก็ถูก reduce ไว้แล้ว และเมื่อ broadcast ก็แค่ส่งข้อความเดียว แล้วชั้น fabric จะจัดการ broadcast ให้ การ์ด IB แบบหลาย context มีคิวจำนวนมาก จึงรันงาน MPI หลายงานบนโหนด/การ์ดเดียวได้ด้วยการแยกคิว/context
ถ้าใช้ framework กับงาน GPU โครงสร้างและการ optimize มักถูกจัดการให้อัตโนมัติในระดับนั้น งานหนักส่วนใหญ่อยู่ที่นักพัฒนา framework ไดรเวอร์ NVIDIA เองก็เป็นเวทมนตร์ดำล้วน ๆ และรับหน้าที่ optimize บางส่วน การเชื่อมต่อระหว่าง GPU เป็นหน้าที่ของ physical fabric และถูกจัดการโดยไดรเวอร์กับ daemon ของตัวเอง
ถ้าคอขวดอยู่ที่ CPU ไลบรารีมักถูกผู้ผลิตปรับแต่งด้วยมือไว้แล้ว เช่น Intel MKL, BLAS, Eigen เป็นต้น ส่วนตัวเคยใช้ Eigen ซึ่งมี hint และการ optimize เฉพาะโปรเซสเซอร์รวมอยู่ด้วย
สิ่งที่ต้องใส่ใจคือคอมไพล์โค้ดให้ตรงกับสถาปัตยกรรมที่ถูกต้อง และตรวจสอบว่าฮาร์ดแวร์ที่ใช้รันสามารถตอบสนองข้อกำหนดได้หรือไม่ เช่น ไม่เข้าถึงหน่วยความจำแบบสุ่มมากเกินไป ถ้าต้องการให้โหนดไปได้ “เร็วที่สุดเท่าที่ทำได้” ก็ต้องปรับให้เข้ากับ prefetcher และ branch predictor ให้ดี และไม่ใช้งานดิสก์อย่างพร่ำเพรื่อ
ในงานคำนวณเชิงตัวเลข หัวใจคือรักษาให้งานเป็นอิสระต่อกันเพื่อให้ทำ instruction-level parallelism/vectorization ได้ ไม่คำนวณสิ่งที่ไม่จำเป็น และไม่ใช้ MPI มากเกินไป กล่าวคือ ลดการคุยกันระหว่างโหนดให้เหลือเท่าที่จำเป็นจริง ๆ
พูดง่ายแต่ทำยาก แต่พอคุ้นแล้ว การคิดถึงเรื่องเหล่านี้จะกลายเป็นสัญชาตญาณที่สอง ถ้างานประเภทนี้ถูกจริตคุณนะ

  • ทั้งใช่และไม่ใช่
    MPI และ OpenMP เป็นวิธีหลักในการ abstraction ฮาร์ดแวร์ใน HPC โดย MPI เป็น abstraction ของการคำนวณขนานแบบหน่วยความจำกระจาย ส่วน OpenMP เป็น abstraction ของการคำนวณขนานแบบหน่วยความจำร่วม นักวิจัยจำนวนมากเขียนโค้ดด้วยสองอย่างนี้เท่านั้น และหลายครั้งก็ใช้ทั้งคู่ในโค้ดเดียวกัน เมื่อใช้งานสิ่งเหล่านี้ ส่วนใหญ่ไม่ต้องสนใจรายละเอียดของสถาปัตยกรรม
    อย่างไรก็ตาม นักวิจัยที่ชอบ optimize เพิ่มเติมก็จะปรับรายละเอียดเชิงสถาปัตยกรรมเล็ก ๆ จำนวนมากเพื่อรีดประสิทธิภาพให้สูงขึ้น เช่น loop unrolling พบได้ค่อนข้างบ่อย และส่วนตัวคิดว่าอาจทำให้สับสนได้พอสมควร ผมจำได้ราง ๆ ว่าเคยได้ยินเรื่องการพยายาม vectorize การคำนวณโดยเลือกใช้การบวกมากกว่าการคูณ เพราะสถาปัตยกรรม CPU บางแบบ แต่ยังไม่เคยเห็นของจริง
    การป้องกัน cache miss ก็เป็นหัวข้อใหญ่เช่นกัน โค้ดบางตัวถูกเขียนให้ข้อมูลที่จำเป็นที่สุดอยู่ใน CPU cache ไม่ใช่ในหน่วยความจำ โค้ดส่วนใหญ่จัดการเพียงระดับรับประกันการวนผ่านแบบ column-major สำหรับการทำงานกับอาร์เรย์ใน Fortran และแบบ row-major ใน C แต่แนวคิดนี้สามารถขยายได้มากกว่านั้น หากรู้ขนาด cache ของโปรเซสเซอร์ ก็อาจ optimize การทำงานบางอย่างเพื่อเก็บข้อมูลที่จำเป็นทั้งหมดไว้ใน cache และลด cache miss ให้เหลือน้อยที่สุดได้ แม้ผมจะไม่เคยเห็นของจริง แต่ในวิชาคำนวณเชิงวิทยาศาสตร์ที่เรียนเมื่อปี 2013 มีการพูดถึงเรื่องนี้อย่างจริงจัง
    การจะใช้ GPU เฉพาะรุ่นหรือไม่นั้นขึ้นอยู่กับปัญหาที่ต้องแก้เป็นอย่างมาก บางปัญหาเหมาะกับ GPU มาก บางปัญหาก็ยากเกินไป น่าเสียดายที่ผมไม่ค่อยรู้เรื่องส่วนนั้น

  • ประทับใจที่ Victor รวบรวมแหล่งข้อมูลที่ยอดเยี่ยมแบบนี้ไว้ได้
    แม้จะไม่ได้รู้จักกันเป็นการส่วนตัว แต่ตอนทำปริญญาเอกที่ UT Austin ในทศวรรษ 1990 ผมทำงานวิจัยจนเสร็จโดยใช้ทรัพยากรที่ TACC ดูแลอยู่ (Cray Y-MP, IBM SP/2 Winterhawk และชื่อโฮสต์ Lonestar ซึ่งตอนนั้นหมายถึง Cray T3E) หนึ่งในกรรมการสอบปริญญาเอกของผมยังอยู่ที่นั่นจนถึงตอนนี้ ถ้าจำไม่ผิด ตอนนั้น TACC ถูกเรียกว่า HPCC หรือ CHPC
    สมัยนั้นโปรแกรมเมอร์ต้องทำให้โค้ดขนานด้วยตัวเอง และในกรณีของผมใช้ MPI บน Cray T3E ในสภาพแวดล้อม UNICOS เพราะสาขานี้ยังอยู่ในช่วงเริ่มต้น จึงจำเป็นต้องเข้าใจฮาร์ดแวร์อยู่พอสมควร ผมแก้ปัญหาโดยอ่านแฟ้มวงแหวนสีเทาของ Cray และหนังสือของ Gropp และคนอื่น ๆ ที่มีอยู่ในมือ แน่นอนว่าคอนแท็กต์ที่มีความรู้ซึ่งกล่าวถึงก่อนหน้านี้ก็ช่วยได้มากเช่นกัน

    • Lonestar5 กลับมาเป็น Cray อีกครั้ง ส่วน Lonestar6 ปัจจุบันเป็น คลัสเตอร์ AMD Milan แบบจุ่มน้ำมันที่มี GPU A100
      ยุคสมัยไม่เคยหยุดนิ่งเลย
    • เคยทำงานกับเขาผ่าน TACC ตอนรันซิมูเลชันขนาดใหญ่ และเพื่อขอบคุณความช่วยเหลือจึงซื้อหนังสือเล่มกระดาษเล่มที่ 1 ของซีรีส์นี้
      แม้จะออกนอกสาขาของผมไปเล็กน้อย แต่ก็น่าสนใจมาก ตั้งใจว่าจะดูเล่มที่เหลือด้วย และขอแนะนำให้คนที่สนใจลองไปดู

  • สนใจฝั่ง การจัดการฮาร์ดแวร์ ของ HPC
    อยากรู้ว่าปัญหาถูกตรวจจับและวินิจฉัยอย่างไร ถูกแมปไปเป็นการดำเนินการอย่างการรีบูต/ติดตั้งใหม่/ซ่อมแซมอย่างไร งานเหล่านี้ถูกจัดตารางอย่างไร และปรับให้เหมาะสมเพื่อให้ได้ระดับบริการที่ดีที่สุดอย่างไร
    ยังสนใจด้วยว่าเมื่อมีเป้าหมายหลายอย่างที่ต้องปรับให้เหมาะพร้อมกัน เช่น ความพร้อมใช้งานของโหนดกับ throughput โดยรวม เขาทำกันอย่างไร, topology หลายแบบส่งผลต่อเรื่องข้างต้นอย่างไร, ข้อจำกัดอื่น ๆ ส่งผลอย่างไร และโดยรวมแล้วมีวิธีมองปัญหาเหล่านี้จากมุมของ system dynamics อย่างไร
    ยังหาแหล่งข้อมูลที่อธิบายเรื่องเหล่านี้ได้ดีไม่ค่อยเจอ ถ้าใครรู้จักแหล่งข้อมูลช่วยบอกด้วยจะดีมาก

    • ถ้าต้องการมุมมองเชิงวิศวกรรมมากกว่าแค่เครือข่าย folded-Clos แบบ non-blocking ทั่วไปหรือกฎของ Little ก็ควรลงลึกใน ทฤษฎีคิว
      ทฤษฎีคิวตอนเริ่มเรียนอาจดูเล็กน้อยและง่าย แต่มีปัญหาเปิดอยู่มากมาย
      เช่น แม้แต่ตัวชี้วัดสมรรถนะของระบบที่มีเวลาเข้ามาแบบสุ่ม เวลาให้บริการอิสระ และมีเซิร์ฟเวอร์ k ตัว (M/G/k) ก็ยังเป็นปัญหาเปิดอยู่
      https://www.sciencedirect.com/science/article/pii/S0895717704905341
      ผิดจากที่คาด ทฤษฎีคิวมีปัญหาเปิดอยู่เยอะจริง ๆ
    • ตอนสัมภาษณ์กับ Meta และ nVidia เมื่อไม่กี่เดือนก่อน เรื่องนี้ดูเป็นหัวข้อใหญ่
      Meta มีวิดีโอ YouTube ดี ๆ อยู่หลายรายการที่อธิบายปัญหาการจัดการ GPU ในสเกลระดับนี้
    • Mark Russinovich แทบจะมีพรีเซนเทชันดี ๆ ทุกปีเกี่ยวกับภายในของ Azure และระบบที่ขับเคลื่อนมัน [1] เป็นตัวอย่างหนึ่ง และพรีเซนเทชันปีอื่น ๆ ก็น่าค้นดูเช่นกัน
      Meta ก็เผยแพร่บทความวิจัย บล็อก และโครงการโอเพนซอร์สจำนวนมากบนไซต์วิศวกรรมของตน [2]
      James Hamilton จาก AWS ก็แทบจะนำเสนอเรื่องโครงสร้างพื้นฐานทุกปีเช่นกัน คุ้มค่าที่จะดูพรีเซนเทชันจากหลาย ๆ ปี [3]
      [1] https://youtu.be/69PrhWQorEM?si=u7vh_Um6SQNoyeFH
      [2] https://engineering.fb.com/category/data-center-engineering/
      [3] https://youtu.be/AyOAjFNPAbA?si=nFRJVcQI4EiamC-O
    • บทความวิจัยของ Microsoft ชิ้นนี้ [1] เป็นงานที่เจ๋งที่สุดเท่าที่เคยเห็นในสาขานี้
      โดยพื้นฐานแล้วเป็นการปรับให้เหมาะสมในระดับ workload ซึ่งในที่นี้คือ งานดีปเลิร์นนิง ทำให้ปรับขนาดงานและ preemption ได้
      [1] https://arxiv.org/pdf/2202.07848.pdf
    • ลองดูโครงการ openbmc และสมาคม DTMF ก็น่าจะดี

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

  • น่าทึ่งที่ผู้เขียนทำหนังสือที่ครอบคลุมขนาดนี้ ซึ่งรวมถึงการสอน C++ และเครื่องมือ Unix แล้วนำมา แชร์ฟรี
    แม้จะไม่ใช่เฉพาะ HPC โปรแกรมเมอร์ทุกคนก็มีสิ่งให้เรียนรู้จากมัน
    แหล่งข้อมูลที่เกี่ยวข้องยังมีหนังสือ “Matters Computational” ของ Jorg Arndt และไลบรารี FXT ด้วย: https://www.jjj.de/fxt/

  • อยากรู้ว่ามอง แนวทางการสอน C++ ที่ใช้ที่นี่อย่างไร มีข้อเสียเฉพาะอะไรไหม?
    ผมใช้ Python มานานมาก และก็พอใช้ C, C++, CUDA ได้บ้าง ทำงานวิจัยระดับแอปพลิเคชัน (ML/DL) ในสภาพแวดล้อม HPC อยู่ อยากพัฒนาทักษะ C++ ให้ดีขึ้น พอลองเปิดดูทั้ง 3 เล่มแล้ว ดูเหมือนจะพอดีกับระดับของผม ไม่ได้เดินเรื่องช้าเกินไป และแทนที่จะมุ่งให้ครอบคลุมทุกอย่าง ก็เป็นแนวทางที่สอน best practices ตามที่ผู้เขียนกล่าวไว้

    • ในฐานะโปรแกรมเมอร์ C++ และผู้สอน ผมมองว่าหนังสือ 3 เล่มนี้เป็น สื่อการเรียนสำหรับผู้เริ่มต้น ที่จัดโครงสร้างได้ดี คุณน่าจะรู้อยู่แล้วเป็นส่วนใหญ่
      ผมลองมองหา range-based for loop, std::array, std::span แล้วก็มีครบ ดีมาก
      เนื่องจากหนังสือเล่มนี้เกี่ยวกับ HPC จึงอยากเสนอเพิ่มอีกสองสามอย่าง น่าจะดีถ้ามีคำอธิบายเรื่อง return value optimization, move semantics และในส่วนฟังก์ชันแบบ recursive ก็มีเรื่อง tail call optimization
      ถ้าเป็นสื่อสำหรับผู้เริ่มต้น ผมแนะนำได้อย่างยิ่ง
    • “The Art of HPC” เล่ม 2 “Parallel Programming for Science Engineering” น่าสนใจตรงที่ครอบคลุม MPI และ OpenMP ใน C, Fortran, C++ และในกรณีของ MPI ก็รวมถึง Python ด้วย: https://theartofhpc.com/pcse/index.html
      อนึ่ง MPI เป็นเพียงวิธีหนึ่งในการทำ HPC ด้วย Python เท่านั้น
      ถ้าจำไม่ผิด ipyparallel สามารถรันงาน MPI ผ่าน tunnel ที่สร้างเองได้
      ถ้ามีบทเกี่ยวกับ dask-scheduler, CuDF, CuGraph(NetworkX), DaskML, CuPy, dask-labextension ก็น่าจะทันสมัยขึ้น
      Dask ไม่ได้จัดการการจัดเก็บข้อมูลแทนให้ ดังนั้นผู้ใช้ต้องรับผิดชอบเองในการรับประกันว่า data store ก่อนแต่ละ barrier จะไม่กลายเป็นคอขวดด้านประสิทธิภาพ
      เอกสาร Dask เรื่อง High Performance Computers: https://docs.dask.org/en/stable/deploying-hpc.html
      แหล่งสุ่มตัวเลขก็อาจเป็นคอขวดได้เช่นกัน จะรู้ไม่ได้จนกว่าจะ profile งานทั้งคลัสเตอร์
      เกี่ยวกับเครื่องมือ tracing ที่ใช้ eBPF: https://news.ycombinator.com/item?id=31688180
      จากนั้นก็น่าจะมีเนื้อหาอย่าง GitOps และ ChatOps, code review และ revision, quota การจัดสรรทรัพยากรของโปรเจกต์ด้วย

  • เมื่อ 10 ปีก่อน ผมได้รับข้อเสนอให้แบ่งหน้าที่เป็นผู้ช่วยสอนในวิชาบัณฑิตศึกษา HPC แต่ปฏิเสธไป
    จากที่ลองอ่านคร่าว ๆ บอกได้ตรง ๆ ว่าถ้าตอนนั้นมีหนังสือเล่มนี้ ผมคงคว้าโอกาสนั้นไว้
    การวางกรอบว่าเป็น ศิลปะ ซึ่งดูเป็นแบบ Knuth, มุมมองที่เปรียบเทียบกับงานไม้ และความจำเป็นที่ต้องเป็นคน DevOps ที่ดีกว่าผู้ดูแล DevOps ของตัวเอง เมื่อรวมกันแล้วโน้มน้าวใจมาก
    ขอปรบมือให้ผลงานของผู้เขียน UT Austin ดูเหมือนจะทำสิ่งในสาขาวิทยาการคอมพิวเตอร์ได้คล้ายกับที่ North Texas State ทำไว้ในด้านดนตรี

  • UT Austin เป็นสถาบันที่ยอดเยี่ยมจริง ๆ ในด้าน HPC และระเบียบวิธีเชิงคำนวณ

    • BLAS แทบทุกตัวที่คุณอยากใช้ ล้วนเกี่ยวข้องกับ TACC ของ UT Austin ในระดับหนึ่ง

  • ตอนที่ผมเข้าร่วมบริษัทเล็ก ๆ แห่งหนึ่งที่สนับสนุนวิศวกร HPC ของผู้ผลิตรถยนต์รายใหญ่ ผมแปลกใจมากที่มีสคริปต์พัฒนาภายในจำนวนมากล้อมรอบ scheduler อย่าง LSF
    นานหลังจากนั้น เมื่อได้ลองเล่น SLURM บนมินิคลัสเตอร์ส่วนตัว จึงได้รู้ว่าเวอร์ชันของซอฟต์แวร์ scheduler โดยมากไม่ค่อยเข้ากันได้ กล่าวคือ ไม่สามารถใช้เวอร์ชันหนึ่งภายในคลัสเตอร์ แล้วใช้อีกเวอร์ชันหนึ่งบนเครื่องไคลเอนต์ภายนอกได้
    ดังนั้นจึงจำเป็นต้องมีซอฟต์แวร์กาวเชื่อมเพื่อส่งงานเข้า scheduler จากภายนอก แล้วดึงผลลัพธ์กลับมาในภายหลัง โดยส่วนตัวผมมองว่าสิ่งนี้ลดคุณค่าของ scheduler ลง
    ผมคิดว่าถ้าทำการคำนวณแบบกระจายประสิทธิภาพสูงกันมาราว 30 ปีแล้ว ข้อกำหนดต่าง ๆ ก็น่าจะเป็นที่รู้กันดี และอย่างน้อย protocol สำหรับแลกเปลี่ยนคำสั่งกับข้อมูลก็น่าจะนิ่งแล้ว แต่ดูเหมือนจะไม่ใช่

    • การยืนยันตัวตนกับคลัสเตอร์จริง ๆ แล้วยังคงเป็นเรื่องปวดหัวในทุกปฏิสัมพันธ์อยู่ดี ในระบบส่วนใหญ่ ตัวหารร่วมต่ำสุดคือสามารถเข้า login node ผ่าน SSH ได้หรือไม่ จากจุดนั้นเป็นต้นไป คำสั่งหลักสำหรับงานอย่าง sbatch/squeue ก็ค่อนข้างเสถียร
      ในอดีตก็เคยมีความพยายามทำมาตรฐาน API จัดการงานพื้นฐาน และ DRMAA เป็นตัวอย่างที่น่าสนใจ อย่างไรก็ตาม DRMAA v2 มีเพียง Grid Engine ที่ implement และโดยพื้นฐานแล้วก็เป็นแค่เวอร์ชันที่ abstract API ภายในออกมาเล็กน้อย จึงไม่ได้รับการรองรับระดับ first-class ใน Slurm/PBS/LSF
      สำหรับ Slurm นั้น REST API ถูกมองว่าเป็นทิศทางในอนาคต ส่วนปัญหาการยืนยันตัวตนก็โยนให้ผู้ดูแลระบบจัดการผ่านพร็อกซี Apache/NGINX ด้วยวิธีใดก็ตามที่ต้องการเชื่อมต่อ API สำหรับการส่งงานพื้นฐานและสถานะได้เสถียรพอแล้วจนแอปพลิเคชันไคลเอนต์แทบทุกเวอร์ชันในอนาคตน่าจะใช้งานได้