สรุป A Not So Simple Matter of Software

A Not So Simple Matter of Software | Talk by Turing Award Winner Prof. Jack Dongarra เป็นหัวข้อเกี่ยวกับ Parallel Computing และ HPC (High Performance Computing) แนะนำโดย 9arm ว่าเป็นอาจารย์ โฆษณาหนักมาก มาดูก็ได้วะ 5555

9arm บอกว่าแกรับรางวัลแต่ก็พูดเนื้อหาเดิมตลอด ผมก็เลยจิ้มหยิบคลิปจาก youtube มาอันนึงที่ดูดีๆเป็นทางการหน่อย

Introduction — History of HPC

เริ่มทำงานในสาย HPC ตั้งแต่ปี 1970 เลยทีเดียว สมัยนั้นเป็นเครื่อง CDC 7600 มี 36 Mflop/s และ 65 Kword memory กับ IBM 370/195 ทำได้ 7 operation พร้อมกัน มี memory 4 MB (สมัยนี้ device IOT ยังทำงานได้เร็วกว่า 5555)

ตัว algorithm เองก็มีการพัฒนามาเรื่อยๆเหมือนกัน เริ่มตามลำดับ

1. 1970 — EISPACK — เริ่มที่การคำนวณ linear algebra หา Eigenvalues, etc. ถึงขนาดรวมวิธีคำนวณออกมาเป็นหนังสือเล่มนึงได้เลย เขียนเป็น Algol และมีโปรเจคแปลง Algol หนังสือเล่มนี้เป็น Fortran โดยสมัยนั้นเขาอยากได้ key property: Accuracy, Community, Innovation, Performance, Portability, Productivity, Readability และ Reliability แม้แต่ precision ของเลขทศนิยมสมัยก่อนก็ยังไม่มี IEEE แต่ละเครื่องใครอยากทำอะไรก็ทำ ก็เลยมีรายละเอียดต้องแก้ไขส่วนนี้เยอะ
2. 1980 — LINPACK — เกิดการเปลี่ยนแปลงของ architecture ให้รองรับ vector operation ได้ ชุด LINPACK เป็นการคำนวณ Level-1 BLAS operations ที่ใช้ประโยชน์จาก vector operation
3. 1990 — LAPACK — เกิดการเปลี่ยนแปลงของ architecture อีกแล้ว รอบนี้มี cache เพิ่มขึ้นมา เป็น L1, L2 CPU cache เลยต้องมีการเปลี่ยนแปลง software เพื่อให้มัน cache-friendly เกิดเป็นชุด LAPACK คำนวณ Level-3 BLAS operations
4. 2000 — ScaLAPACK— เปลี่ยนแนวทางอีกแล้ว คราวนี้ shared & distributed memory system พอทุก processors มีชุด memory ของตัวเอง ใช้งาน memory ตัวเองได้ ก็ต้องมีความสามารถในการ shared ข้อมูลนี้ได้ด้วย เกิดเป็น message passing เป็นแนวคิดที่สำคัญมาก แต่ละกลุ่มแยกกันทำเยอะมาก จนมีแนวคิดว่าควรตั้ง standard ขึ้นมา และ MPI Forum ก็เกิดขึ้นมาด้วย หลังจากการประชุม 1.5 ปี เจอกันตัวจริงๆทุกๆ 3 วันที่โรงแรมทุกๆ 6 สัปดาห์ เกิดเป็น MPI-1 specification draft ส่วนชุดของ software เกิดเป็น ScaLAPACK ที่มีการใช้งาน PBLAS Message Passing
5. 2010 — PLASMA/MAGMA — เปลี่ยนอีกแล้ว เกิดเป็น Multicore/Hybrid architecture. multicore คือมีหลาย core ใน chip เดียวแล้วมีการใช้ shared memory ร่วมกัน ส่วน hybrid เกิดจาก GPU เริ่มโตขึ้นมา คำนวณ 64-bit floating point op ได้ ก็เลยเริ่มมีการนำ GPU มาใช้เป็น offload engine ในการช่วยคำนวณได้ เกิดเป็น software PLASMA/MAGMA มีการใช้ GPU ในการคำนวณ ส่วน algorithm จะเป็นตระกูล DAG/scheduler และ block data layout
6. ParSEC and Batched BLAS — จากการเปลี่ยนแปลงของ architecture ข้อก่อนหน้าทำให้เกิดความเป็นไปได้ในการทำ massive parallel พัน core หมื่น core ได้ เทคนิคเบื้องต้นก็เป็นเรื่องเก่าเอามาเล่าใหม่ คือ Fork-Join และ Batching รวมกันเป็น bulk synchronous parallel (BSP) เช่น การคูณ matrix จำนวนมากๆพร้อมกัน จนเป็นรากฐานของการคำนวณ ML ในปัจจุบัน
7. 2020 — SLATE— ในปัจจุบัน เราไม่พอใจกับ hybrid เล็กๆ เราเลยเอา GPU/CPU มากองรวมกันเยอะๆแล้วสร้าง system จะพวกนั้น (วาง layout network, memory, etc. จากการรวม processing core เยอะๆ) เช่น เครื่อง 2-IBM มีพลังที่ 47.9 Tflop/s โดย 46.8 Tflop/s มาจาก GPU เรียกได้ว่า GPU เป็นตัวคำนวณถึง 97.7% ใช้ไฟมหาศาลมาก อย่างกรณีเครื่อง ORNL’s Summit Supercomputer ใช้ไฟ 10 MWatts ใช้เงินไป 10 ล้านดอลลาร์ แค่เฉพาะขั้นตอนเปิดเครื่อง ออกแบบ software package ใหม่ ได้ SLATE สำหรับทดสอบ Tasking DAG scheduling & Tiling และ Heterogeneous Hardware

Software Structure

เป็นความแตกต่างของความค่าพลังในการประมวลผล เวลาเราสร้าง software เราก็คาดหวังว่าเวลาเราเดินขึ้นชั้น pyramid นี้ จะไม่จำเป็นต้องลงไปเปลี่ยน software ข้างล่างมาก (จริง ไม่งั้นเหนื่อยตาย) ดังนั้นเราก็ควรพิจารณา property ต่างๆในขณะออกแบบ software ตั้งแต่แรก

สำหรับปัจจุบัน เรามีพื้นฐาน และความเข้าใจใน software structure ดังนี้

• Highly Parallel — มี Distributed memory, ใช้ MPI + OpenMP programming model
• Heterogeneous — ใช้ commodity processors + GPU accelerators
• Simple loop level parallelism มีข้อจำกัดเยอะไปละ ไม่ปลื้ม
• Communication ระหว่างแต่ละส่วนประกอบ มันแพงงงงง (ใช้เวลานาน เมื่อเทียบกับ floating point ops)
• ดังนั้นการเปรียบเทียบ operation count แบบดั้งเดิม ไม่ได้เป็นตัวชี้วัดเวลาที่ดีอีกต่อไป เพราะเราควรจะเอาเวลาจาก communication เข้าไปรวมด้วย
• Floating point ops ถ้าเราลด precision เช่น 32-bit ops ก็พอ แปลว่าเราสามารถทำ parallel ได้เร็วกว่า 64-bit ops 2 เท่า ในปัจจุบันมี 64, 32, 16 และ 8-bit floating point ops

ปัจจุบัน เรากำลังจะขึ้นไปอยู่ในระดับพลังการคำนวณ Exascale หรือ 10¹⁸ floating point operations per seconds

สำหรับเครื่องทรงพลังแบบนี้ จะวัดโดยใช้ benchmark ชื่อว่า TOP 500 benchmark ที่ด้านในเป็น LINPACK จากนั้นก็เช็คความถูกต้องของคำตอบที่ 64-bit precision (สำคัญมาก คำนวณแล้วคำตอบผิดก็ปล่าวประโยชน์สิ 555)

HPC Project

ลงเงินไปทั้งหมด 3.6B dollars ได้ผลลัพธ์สุดท้ายออกมาเป็น Exascale computer 3 ตัว (ราคา $600M each), 21 applications ที่ถูกออกแบบมาสำหรับทำงานบนเครื่องพวกนี้โดยเฉพาะ และ 84 software projects

(เป็นกราฟ scale LOG ไม่ใช่ linear)

เรามองกราฟดูการเติบโตของ HPC ได้ สีแดงคือเครื่องที่เร็วที่สุด (TOP 1) จุดสีแดงที่เป็นเส้นราบๆหมายถึงมันเป็น champion ไม่มีเครื่องอื่นมาโค่นครับ ส่วนสีส้มเป็น entrypoint สำหรับ TOP 500 ส่วนสีฟ้าคือนำพลังทั้งหมดของ 500 เครื่องมา SUM รวมกัน (ด้วย excel sheet ก็ได้ตรงๆเลย) โดยประมาณยังส่วนที่มันหักลงชัดเจนตอนประมาณปี 2014 เนี่ย อาจจะเป็นเพราะจุดสิ้นสุดของ Moore’s Laws หรือจริงๆอาจจะแค่ปัญหาเศรษฐกิจ หรืออาจจะทั้งคู่ก็ได้

ส่วนเครื่องปัจจุบัน laptop อาจารย์เขาอยู่ที่ 166 Gflop/s ถ้าย้อนกลับไปก็คือที่หนึ่งของ HPC ในปี 1995 (ใครย้อนเวลาได้ มึงพกคอมกลับไปตัวเดียวก็เขย่าทั้งโลกแล้ว 555)

เทียบดูว่า HPC ส่วนใหญ่นั้นใช้ architecture ของอะไร พบว่า 81% ใช้ Intel (โหว๊ว)

ส่วน GPU Nvidia เอาไปครอง

Machine Learning

แน่นอนว่า HPC ในปัจจุบัน จะไม่พูดถึง Machine learning ไม่ได้ Machine Learning ในปัจจุบันมักจะประกอบไปด้วย Matrix multiplication ซึ่งมีการคูณ matrix เล็กๆจำนวนมากๆในสามารถทำให้เร็วขึ้นด้วย parallel programming ได้ (เรื่อง matrix เล็กๆมากๆ CNN พอเข้าใจ แต่ fully connected layers เนี่ยนึกภาพไม่ออก 555)

Floating Point Representation

มีเกริ่นไปก่อนหน้าแล้ว ว่าถ้าเราไม่ได้ต้องการ precision ที่สูงมากเนี่ย เราลด bit ops ลงมาได้ แล้วทำให้เร็วขึ้นได้มาก แต่การลด precision ต้องระวัง อย่างเช่น IEEE FP16 รองรับค่ามากสุดแค่ 65504 ซึ่งน้อยมาก ส่วนของ Google ก็คงเห็นด้วยว่าน้อยไป เลยออกแบบ format ใหม่เอง ใช้ใน TPU ลด decimal precision ลงไปหนึ่งหลัก แต่เพิ่มจำนวนเต็มได้สูงสึดถึง 10³⁸ เลย (ทำได้ไงหว่า เดี๋ยวต้องไปหาอ่าน 555)

ส่วน Nvidia ที่อยู่ใน ML game ด้วยเหมือนกัน เลยเสนอมาว่า เรามี hardware format สำหรับคำนวณให้ละกัน สำหรับคำนวณได้เร็ว อยู่กึ่งกลางระหว่าง IEEE FP16 กับ Google BFloat16

ซึ่งการออกแบบ format ใหม่นี้ก็เริ่มเป็น norm ละ มีบริษัทยักษ์ใหญ่หลายเจ้าเริ่มออกแบบ processor สำหรับใช้งานเอง เช่น Google TPU, Amazon Gravitons, Apple M1

Data Movement

หรือ communication นั่นแหละ แน่นอนว่าการคำนวณ เมื่อเสร็จแล้วก็ต้องเก็บเข้า storage และดึงข้อมูลใหม่มาคำนวณต่อถูกไหม ดังนั้น ratio ที่ดีที่สุด คือ 1 flop per word from memory. จากกราฟเป็นการ plot เทียบ flops กับความสามารถในการดึง word ออกจาก memory จะเห็นว่าสมัยแรกๆเลย (แถบเขียว) การคำนวณมันช้ากว่า memory แต่พอมาหลังๆ (แถบเหลือง) การคำนวณมันเร็วขึ้นละ สิ่งที่มีราคาคือการดึง memory ที่พัฒนาตาม processing power ไม่ทัน ปัจจุบันการสื่อสารราคาแพงมาก

ตัวอย่างกับเลขจริงๆบน laptop อาจารย์เขา ดีมากเลย

• สีฟ้า คือ vector คูณกับ constant
• สีเขียว คือ Matrix คูณ vector
• สีแดง คือ matrix คูณ matrix

ความสัมพันธ์ของการคำนวณแบบต่างๆระหว่าง Flop กับ memory transfer อธิบายอยู่ข้างซ้าย สำหรับกรณีสีฟ้าเนี่ย มันคูณเสร็จ แล้วก็เอาไปเก็บใน memory แล้วก็ดึงชุดใหม่มาคูณต่อ เลยกลายเป็นว่า Gflop/s ที่ควรจะได้สูงๆตาม processing power จริงมันหดลงไปเยอะมาก เพราะติดที่ memory transfer

ดังนั้น classical analysis ที่บอกว่าดู processors จากนั้นดูว่า ops per cycle เท่าไร แล้วคำนวณออกมาเนี่ย มัน mislead พอสมควรเลย เพราะขึ้นกับ algorithm ด้วย

Performance and Benchmark Evaluation Tools

1. Linpack benchmark — เป็น benchmark สมัยแรกเลย ส่วนใหญ่เป็นการคำนวณ dense matrix multiplication ดังนั้นเป็นการรีด Flop/s ให้ได้สูงที่สุด ซึ่งเหมาะกับสมัยนั้นเพราะ arithmetic มีราคาแพง แต่เดี๋ยวนี้มันเปลี่ยนไปแล้ว เพราะ over previsioned and inexpensive (ตามที่แสดงในหัวข้อก่อน) จึงควรมองว่าเป็น benchmark แบบเก่า และไม่เหมาะสมอีกต่อไป
2. HPCG benchmark (High Performance Conjugate Gradient) มีการคำนวณที่หลากหลายกว่า ทั้ง dense และ sparse matrix multiplication ซึ่งสอดคล้องกับ application จริงมากกว่า

เราเลยนำ HPCG ไปลอง benchmark กับเครื่องจริงดู ได้ผลดังนี้

ลำดับไม่ได้สำคัญเท่ากับผล % ด้านขวาสุดครับ ปรากฎว่าจากเดิมที่คำนวณ HPL ได้ 442 Pflop/s แม่งพอเอาไปวัดด้วย HPCG ลดลงมาเหลือ 16 Pflop หรือ “เหลือ” แค่ 3% เท่านั้นเอง กำๆๆๆ 555 คนหน้างานหลายคนก็เขินมาก แต่มันคือความเป็นจริง (ห้ามเอาเลขนี้ไปบอกคนให้ทุนเด็ดขาดนะ 555)

สรุป

• Software development follows the hardware — และมีแนวโน้มต้องเปลี่ยนทุกๆ 10 ปี
• Experiment with mixed precision — มีความน่าสนใจ เพราะ AI/ML ยังอยู่กับเรา
• การเปรียบเทียบ ops count ไม่ได้บ่งชี้ถึงเวลาในการใช้งานจริง
• Responsible “recklessly” algorithm น่าสนใจ — มันคือ algorithm กลุ่มที่มีโอกาสให้คำตอบผิดได้ แต่ถ้าเวลาที่ใช้ในการ verified นั้นเร็วมาก และการคำนวณต่อครั้งนั้นเร็ว อาจจะออกมาดูดีก็ได้ (ฟังดูเหมือน quantum computing เลยแหะ 55555)
• ทุกอย่างคือ Marathon (วิ่งไกล) ไม่ใช่ sprint (วิ่งเร็ว) — อย่าลืม key สำคัญ: Accuracy, Community, Innovation, Performance, Portability, Productivity, Readability, and Reliability

สรุปจากผู้เขียน

ดีมากเลยครับ สมที่นายอาร์มแนะนำมาจริงๆ คนนี้จะมาสายวิจัย HPC เนี่ยควรดูคลิปนี้ตั้งแต่ก่อนเลือกหัวข้อจริงๆนะ มันจะเข้าใจเลย benchmark ที่เห็นใน paper บ่อยๆมันคืออะไร ทำไปทำไม บลาๆ ส่วนผมเหรอ ดูคลิปนี้ก่อนวันสอบจบ 1 วันถ้วน 55555 แต่ผมไม่ได้ทำ HPC ผมทำ distributed computing เลยไม่ได้ต้องใช้ขนาดนั้น :P คลิปนี้สนุกมากครับ เล่าจากมุมมองคนที่ทำงานสายนี้ตั้งแต่ 70s จน 2020s ได้เห็นความแตกต่างชัดมากเลยทีเดียว

5 July 2023