Parallel Systems · บทที่ 6 จาก 9

Measuring Performance

เพิ่มหน่วยประมวลผลเป็น 2 เท่า ไม่ได้แปลว่าเร็วขึ้น 2 เท่าเสมอไป — บทนี้ให้เครื่องมือคำนวณว่า "คุ้มแค่ไหน" อย่างเป็นระบบ ตั้งแต่สูตรทางคณิตศาสตร์ไปจนถึง benchmark ที่ใช้วัดกันจริงในอุตสาหกรรม

📚

สังเคราะห์จากเอกสาร "Performance: Model, Metric, and Speedup" (2110732 Parallel Computing) — สูตร Amdahl's/Gustafson's/Sun-Ni's Law และรายละเอียด benchmark suite คงความแม่นยำทางคณิตศาสตร์ไว้ทั้งหมด เพียงปรับตัวอย่างเชิงตัวเลขให้ทันสมัย

1ตัวชี้วัดพื้นฐาน (Performance Metrics)

ตัวชี้วัด	ความหมาย
Execution Time	เวลาทั้งหมดตั้งแต่เริ่มจนจบ (wall-clock time) — ยิ่งน้อยยิ่งดี ขึ้นกับ algorithm, data structure, input, ฮาร์ดแวร์/ซอฟต์แวร์/ภาษาที่ใช้
Processing Speed	MIPS, MFLOPS — วัด "ความเร็วดิบ" แต่หลอกตาได้ง่ายมาก เพราะจำนวนคำสั่งที่ใช้แก้ปัญหาเดียวกันต่างกันได้มากตาม algorithm
Throughput	จำนวนงานที่ทำเสร็จต่อหน่วยเวลา — throughput สูงไม่ได้แปลว่า execution time ของงานแต่ละชิ้นต่ำเสมอไป (เช่น ระบบ pipeline อาจมี throughput สูงแต่แต่ละงานยังใช้เวลานานเท่าเดิม)
Utilization	อัตราส่วนความเร็วที่ทำได้จริง (sustained) เทียบกับความเร็วสูงสุดทางทฤษฎี (peak) — โดยทั่วไป sequential program ทำได้ 5-40% ส่วนโปรแกรมขนานมักทำได้แค่ 1-35% เพราะมี overhead เพิ่มจาก degree of parallelism ที่ต่ำและต้นทุนการสื่อสาร
Cost Effectiveness	อัตราส่วนประสิทธิภาพต่อราคา — เครื่อง PC ทั่วไปมักชนะซูเปอร์คอมพิวเตอร์ในมิตินี้อย่างชัดเจน แม้ประสิทธิภาพดิบจะแพ้ไกล

2สมการต้นทุนของการขนาน

เวลาทั้งหมดของโปรแกรมขนาน

T = Tcomp + Tpar + Tinteract

Tcomp — เวลาคำนวณจริง ขึ้นกับ algorithm และ load-imbalance (บาง process มีงานมากกว่า process อื่น)
Tpar — parallelism overhead จากการจัดการ process (สร้าง, context switch)
Tinteract — interaction overhead จาก synchronization (barrier, lock, critical region), aggregation (reduction เช่นใน MPI_Reduce บทที่ 5), และการสื่อสารระหว่างกัน

ทำไมสมการนี้สำคัญ

เฉพาะ Tcomp เท่านั้นที่เป็น "งานที่มีประโยชน์จริง" — Tpar และ Tinteract คือ overhead ล้วน ๆ ที่ไม่มีในโปรแกรม sequential ยิ่งแบ่งงานละเอียด (fine-grain ตามบทที่ 3) ยิ่งมี Tinteract สูงขึ้นตามสัดส่วน จนถึงจุดที่เพิ่มหน่วยประมวลผลแล้วกลับช้าลงได้จริง ๆ

3Speedup Analysis: สามกฎที่ตอบคำถามต่างกัน

Speedup คืออะไร

Sₙ = (เวลารันบน 1 processor) / (เวลารันบน n processors)

Amdahl's Law — Fixed-Load Speedup

โจทย์: งานขนาดคงที่ W มีสัดส่วน α ที่ขนานไม่ได้ (ต้องรันแบบลำดับ)

W = αW + (1−α)W Sₙ = T / (αT + (1−α)T/n) = n / (1 + (n−1)α) → 1/α เมื่อ n → ∞

สรุป: ต่อให้เพิ่มหน่วยประมวลผลไม่จำกัด speedup ก็จะไม่มีทางเกิน 1/α — ถ้ามีส่วนที่ขนานไม่ได้เพียง 10% (α=0.1) speedup สูงสุดที่ทำได้คือ 10 เท่า ไม่ว่าจะใช้กี่พัน processor ก็ตาม

มุมมองที่ "มองโลกในแง่ร้าย" ของ Amdahl

Amdahl's Law สมมติว่าขนาดปัญหาคงที่ — คำถามคือ "งานเดิมเท่าเดิม ใช้ processor เยอะขึ้นเร็วขึ้นแค่ไหน" ซึ่งมักประเมินประโยชน์ของการขนานต่ำเกินจริงในสถานการณ์จริงจำนวนมาก เพราะในทางปฏิบัติเรามักไม่ได้อยากทำงานเดิมให้เร็วขึ้นอย่างเดียว แต่อยากทำงานใหญ่ขึ้นในเวลาเท่าเดิมด้วย — นำไปสู่มุมมองที่ 2

Gustafson's Law — Fixed-Time (Scaled-Load) Speedup

โจทย์: เวลาคงที่ T เท่าเดิม แต่ขนาดงานที่ทำได้ W' ขยายตามจำนวน processor

W' = αW + (1−α)nW Sₙ = α + (1−α)n

สรุป: Speedup เติบโตเป็นเส้นตรงตามจำนวน processor (ไม่ถูกจำกัดด้วย 1/α เหมือน Amdahl) เพราะมองว่าเมื่อมี processor เพิ่ม เราจะขยายขนาดปัญหาให้ใหญ่ขึ้นตาม ไม่ใช่ทำงานเดิมให้เร็วขึ้นอย่างเดียว

Sun and Ni's Law — Memory-Bound Speedup

โจทย์: n processors มี n เท่าของ memory — ใช้ memory ที่เพิ่มขึ้นมาขยายขนาดปัญหาแทน

W* = αW + (1−α)G(n)W โดย G(n) คือฟังก์ชันขยายงานตาม memory ที่มีเพิ่มขึ้น

เป็น superset ของอีกสองกฎ: G(n)=1 ลดรูปเป็น Amdahl's Law (ขนาดงานคงที่), G(n)=n ลดรูปเป็น Gustafson's Law (ขนาดงานโตเชิงเส้น), G(n)>n คือกรณีที่ memory เหลือเฟือมากกว่าที่ต้องการ

ข้อควรจำสำหรับสอบ

ทั้งสามกฎไม่ได้ "ขัดแย้งกัน" — เป็นแค่สมมติฐานต่างกันเกี่ยวกับสิ่งที่คงที่ (โจทย์คงที่ vs เวลาคงที่ vs memory คงที่) เลือกใช้กฎไหนขึ้นกับคำถามจริงที่กำลังตอบ: "งานเดิมเร็วขึ้นแค่ไหน" ใช้ Amdahl, "เวลาเท่าเดิมทำงานได้เยอะขึ้นแค่ไหน" ใช้ Gustafson

4Abstract Machine Models: วิเคราะห์ algorithm โดยไม่ยึดติดฮาร์ดแวร์จริง

โมเดล	แนวคิด	ข้อจำกัด
PRAM Parallel RAM	Shared-memory, synchronous ทุก cycle (SIMD-like) — ไม่มี parallelism/synchronization overhead เลยในโมเดล มีรูปแบบ memory access ย่อย: EREW (Exclusive Read Exclusive Write), CREW (Concurrent Read), CRCW (Concurrent Read/Write)	ง่ายเกินจริง — ไม่มีระบบจริงที่ไม่มี overhead การสื่อสารเลย
BSP Bulk Synchronous Parallel	แบ่งเวลาเป็น superstep — คำนวณอิสระกันในแต่ละ processor ก่อน แล้วซิงโครไนซ์พร้อมกันทีเดียวตอนท้าย superstep (ไม่ใช่ทุก cycle แบบ PRAM) มี local memory แยกกัน ไม่ใช่ shared	ยังไม่ระบุรายละเอียด overhead ของแต่ละองค์ประกอบ
Phase Parallel Model	ปรับปรุงจาก BSP ให้ระบุ overhead ชัดเจนขึ้น: T(n) = T(comp) + T(interact) + T(par) — ตรงกับสมการในหัวข้อ 2 เป๊ะ	ยังไม่คำนึงถึงสถาปัตยกรรมจริงเบื้องหลัง
LogP	โมเดลยุคหลังที่คำนึงถึงสถาปัตยกรรมจริงมากขึ้น — เน้น message-passing และ overhead การสื่อสารโดยเฉพาะ สมจริงกว่าแต่ซับซ้อนกว่าในการใช้วิเคราะห์	ซับซ้อนกว่าโมเดลอื่นในการนำไปใช้จริง

5Benchmark Suite ที่ใช้วัดกันจริงในอุตสาหกรรม

Benchmark	วัดอะไร
LINPACK	โดย Jack Dongarra — แก้สมการเชิงเส้น ใช้เป็นเกณฑ์จัดอันดับTop500 (รายชื่อซูเปอร์คอมพิวเตอร์เร็วที่สุดในโลก) วัด R(max) (ความเร็วสูงสุดที่ทำได้จริง) เทียบกับ R(peak) (ความเร็วทางทฤษฎี)
STREAM	โดย John McCalpin — วัดmemory bandwidthไม่ใช่ compute speed เพราะซีพียูเร็วขึ้นเร็วกว่า memory มาก ทำให้ซีพียูมักต้องรอ memory (memory wall) — ตรงกับบทเรียนเรื่อง shared-memory tiling ใน CUDA (บทที่ 5) ที่พยายามหลีกเลี่ยงปัญหานี้โดยตรง
NAS Parallel Benchmarks (NPB)	โดย NASA Ames — จำลองงาน computational fluid dynamics ประกอบด้วย 5 kernels (IS, EP, MG, CG, FT) และ 3 pseudo-applications (LU, BT, SP)
TPC	วัดประสิทธิภาพ transaction processing (เช่น ระบบธุรกรรมทางธุรกิจ) วัดเป็น $/tpmC (ราคาต่อ transaction ต่อนาที) — เน้น cost-effectiveness โดยตรง
SPEC	ชุด benchmark หลากหลาย เช่น SPEChpc (ระบบประสิทธิภาพสูง), SPEC WEB (ประสิทธิภาพ web server)

6Benchmark ปัจจุบันวัดสิ่งใดเพิ่มจากแบบเดิม

แล้ว · ~2000–2012

ตอนนี้ · 2026

Top500 วัดความเร็วดิบ (LINPACK) เพียงอย่างเดียว เป็นเกณฑ์หลักที่ทุกคนอ้างอิง

Green500 จัดอันดับซูเปอร์คอมพิวเตอร์ตามประสิทธิภาพต่อพลังงาน (FLOPS/Watt) แทนความเร็วดิบอย่างเดียว — สะท้อนว่าพลังงานกลายเป็นข้อจำกัดสำคัญพอ ๆ กับความเร็ว (ตรงกับ power wall ในบทที่ 1 และ 2) ซูเปอร์คอมพิวเตอร์ยุคใหม่ต้องแข่งกันทั้งสองมิติพร้อมกัน

Benchmark ทั้งหมดเน้นงานวิทยาศาสตร์ดั้งเดิม (เชิงเส้น, CFD, transaction processing)

MLPerf คือ benchmark suite มาตรฐานสำหรับวัดประสิทธิภาพงาน machine learning โดยเฉพาะ (ทั้งการเทรนและการ inference) — วัดสิ่งที่ LINPACK/STREAM แบบเดิมไม่ได้ออกแบบมาให้วัด เช่น throughput ของ Tensor Core และประสิทธิภาพ mixed-precision

STREAM วัด memory bandwidth แยกจาก LINPACK ที่วัด compute — ต้องดูสองตัวเลขแยกกันเพื่อประเมินระบบ

Roofline Model รวมทั้งสองมิติเข้าด้วยกันเป็นกราฟเดียว — แสดงว่า kernel หนึ่ง ๆ ถูกจำกัดโดย compute (compute-bound) หรือโดย memory bandwidth (memory-bound) แล้วชี้ชัดว่าควร optimize ด้านไหนก่อน เป็นเครื่องมือที่ engineer ด้าน ML/HPC performance ใช้จริงในการวิเคราะห์ kernel ที่เขียนเอง (เชื่อมโยงกับบทที่ 5 โดยตรง)

ข้อสังเกตสำคัญ

สูตร Amdahl's/Gustafson's Law และสมการ T = Tcomp + Tpar + Tinteract ไม่มีวันล้าสมัย เพราะเป็นคณิตศาสตร์บริสุทธิ์ที่ไม่ผูกกับเทคโนโลยียุคใดยุคหนึ่ง — สิ่งที่เปลี่ยนคือbenchmark suite ที่ใช้วัดค่าจริง ต้องขยายตัวตามงานที่ระบบยุคใหม่ต้องทำ (AI, พลังงาน) ที่ยุค 2000 ยังไม่ใช่ปัญหาหลัก

คำถามซ้อมสอบ

คำนวณ Amdahl's Law speedup เมื่อ α = 0.05 (5% ขนานไม่ได้) และ n = 100 processors แล้วเปรียบเทียบกับ speedup สูงสุดที่เป็นไปได้เมื่อ n → ∞
อธิบายความแตกต่างระหว่างสมมติฐานของ Amdahl's Law และ Gustafson's Law และยกตัวอย่างสถานการณ์ที่แต่ละกฎเหมาะสมกว่า
อธิบายว่า Sun and Ni's Law เป็น superset ของอีกสองกฎอย่างไร
อธิบายความแตกต่างระหว่าง PRAM และ BSP model ในแง่การจัดการ synchronization
อธิบายว่าทำไม Green500 และ MLPerf จึงจำเป็นต้องเกิดขึ้นเพิ่มเติมจาก Top500/LINPACK แบบดั้งเดิม

7เริ่มจากนิยามขอบเขตเวลา

ก่อนคำนวณ speedup ต้องตกลงว่า T รวมอะไร หาก GPU benchmark นับเฉพาะ kernel แต่ CPU version นับอ่านไฟล์และเตรียมข้อมูล การหารเวลาถูกต้องทางเลขแต่ไม่มีความหมายทางวิศวกรรม

ขอบเขต	รวมอะไร	ตอบคำถามใด
Kernel time	เฉพาะ computation region	Implementation ของ kernel ใช้ device ดีเพียงใด
Application time	Setup, transfer, compute และรวมผล	ผู้ใช้รอจริงเท่าใดบนระบบนั้น
End-to-end	Queue, I/O, network และ orchestration	Workflow หรือบริการให้คุณค่าทันเวลาหรือไม่
Amortized	ต้นทุนครั้งเดียวหารด้วยจำนวนงาน	ระบบที่ใช้ซ้ำหลายรอบคุ้มเพียงใด

จับเวลาเดินทาง

ถ้าเปรียบรถไฟกับรถยนต์โดยจับรถไฟหลังขึ้นขบวน แต่จับรถยนต์ตั้งแต่ออกจากบ้าน ผลอาจตอบคำถามเรื่องความเร็วขณะเคลื่อนที่ แต่ไม่ตอบว่าถึงปลายทางเร็วกว่าอะไร Benchmark ต้องประกาศจุดเริ่มและจุดจบให้ตรงกับคำถาม

8Baseline ที่เป็นธรรม

Serial baseline ควรใช้อัลกอริทึมและ optimization ที่ดีพอ ไม่ใช่โค้ดสาธิตช้า ๆ เพื่อให้ parallel version ดูเด่น ขณะเดียวกันควรรายงาน T(1) ของ parallel implementation เพราะ framework overhead อาจทำให้มันช้ากว่า optimized serial code แม้ scaling ภายในดูดี

ใช้ compiler flags, precision และ library version ที่เทียบกันได้
ตรวจผลลัพธ์และ tolerance ให้เหมือนกัน
แยก algorithmic improvement จาก parallel speedup
ระบุ hardware, topology, frequency policy และ software environment
ถ้าใช้ baseline ต่าง algorithm ให้รายงานทั้งสองชุดและอธิบายเหตุผล

Speedup อาจมาจากการเปลี่ยนอัลกอริทึม

ถ้า serial ใช้ O(n²) แต่ parallel version เปลี่ยนเป็น O(n log n) ผลที่ดีไม่ได้มาจาก processor count อย่างเดียว ควรให้เครดิต algorithm และ parallelism แยกกัน ไม่เช่นนั้นการคาดการณ์เมื่อเพิ่มเครื่องจะผิด

9Speedup, Efficiency, Cost และ Overhead

ตัวชี้วัดหลัก

S(p)=T(1)/T(p)
E(p)=S(p)/p
Cost(p)=p·T(p)
Overhead(p)=p·T(p)−T(1)

Speedup บอกเวลาที่ประหยัด Efficiency บอกสัดส่วนการใช้ทรัพยากร Cost บอก processor-time รวม และ overhead บอกงานเพิ่มจากการทำงานร่วมกัน ระบบอาจเร็วขึ้นแต่ใช้ทรัพยากรมากจน cost สูงเกินความจำเป็น

ตัวอย่าง

งานเดิม 100 วินาที ใช้ 8 processors เหลือ 20 วินาที ได้ speedup 5, efficiency 62.5%, cost 160 processor-seconds และ overhead 60 processor-seconds ผู้ใช้ได้คำตอบเร็วขึ้น 5 เท่า แต่ระบบใช้ทรัพยากรรวมเพิ่ม 60%

10Strong และ Weak Scaling

Strong scaling คงปัญหาเดิมแล้วเพิ่ม processors เพื่อย่นเวลา Weak scaling เพิ่มขนาดปัญหาตามจำนวน processors เพื่อรักษางานต่อ processor ใกล้เดิม สองกราฟตอบคนละคำถามและไม่ควรใช้แทนกัน

Weak-scaling efficiency แบบหนึ่ง

Eweak(p)=T(1,n)/T(p,pn)

ถ้าเวลายังคงใกล้เดิมเมื่อขนาดข้อมูลโตตาม p efficiency ใกล้ 1 แต่ต้องรายงานว่าข้อมูลหรือ work โตอย่างไร เพราะปัญหาบางชนิด complexity ไม่เป็นเส้นตรง

งาน production อาจต้องดูทั้งสองแบบ: request เดียวต้องไม่ช้าเกิน deadline และระบบต้องรับ workload รวมที่โตขึ้นด้วย

11Amdahl's Law แบบอ่านให้พ้นสูตร

Amdahl สมมติขนาดปัญหาคงที่และแบ่งเวลา baseline เป็นส่วน serial กับ parallel หาก serial fraction เท่ากับ α speedup เมื่อ p โตมากถูกจำกัดด้วย 1/α

แต่ α ไม่จำเป็นต้องคงที่เมื่อเปลี่ยน p Overhead, communication และ imbalance อาจเพิ่ม ทำให้ effective serial fraction โตขึ้น ส่วน cache locality อาจดีขึ้นทำให้เวลาบางส่วนลดเกิน model Amdahl เป็นกรอบตั้งคำถาม ไม่ใช่เครื่องทำนายที่ครอบคลุม hardware ทุกอย่าง

เพดานที่ย้ายตำแหน่ง

หลังเร่ง computation ส่วนหลัก 20 เท่า preprocessing ที่เคยใช้เพียง 2% อาจกลายเป็นสัดส่วนใหญ่ของเวลารวม การ optimize ไม่ได้ทำให้คอขวดหาย แต่ทำให้คอขวดส่วนถัดไปมองเห็นชัดขึ้น

12Gustafson: ทรัพยากรเพิ่มแล้วแก้โจทย์ใหญ่ขึ้น

Gustafson มองว่าผู้ใช้มักขยายงานเมื่อมีทรัพยากรเพิ่ม เช่น simulation ละเอียดขึ้นหรือทดลอง parameter มากขึ้น ส่วน serial time อาจคงที่ จึงอธิบาย scaled speedup ได้ดีกว่า Amdahl ในบริบทนี้

Scaled speedup

S_G(p)=p−α(p−1)

α คือสัดส่วน serial ที่วัดบนการรันแบบขนาน สูตรนี้ไม่ได้หักล้าง Amdahl แต่เปลี่ยนคำถามจาก “งานเดิมเร็วเท่าไร” เป็น “ในเวลาใกล้เดิม เราทำงานใหญ่ขึ้นได้เท่าไร”

13Sun–Ni และข้อจำกัดจากหน่วยความจำ

เมื่อ processors เพิ่ม memory รวมมักเพิ่มด้วย เราอาจเลือกขยายข้อมูลตาม memory capacity ไม่ใช่ตาม workload ต่อ processor แบบเส้นตรง Sun–Ni เน้น memory-bounded speedup และสะท้อนงานที่ขนาดปัญหาถูกจำกัดด้วยพื้นที่เก็บ state

ตัวอย่างคือ graph หรือ matrix ที่เครื่องเดียวเก็บไม่พอ การใช้ cluster ทำให้ปัญหา “เป็นไปได้” ก่อนจะถามว่าเร็วเท่าไร Metric จึงควรรวม maximum solvable problem size ด้วย ไม่ใช่ runtime อย่างเดียว

14Karp–Flatt Metric: ประมาณ Serial Fraction ที่สังเกตได้

Karp–Flatt

e = (1/S(p) − 1/p) / (1 − 1/p)

e รวมผลที่ดูเหมือน serial ทั้งส่วนลำดับและ overhead หาก e เพิ่มตาม p มีสัญญาณว่า communication, synchronization หรือ imbalance โต ไม่ใช่เพียง serial code คงที่

การ plot e เทียบ p ช่วยแยกว่า speedup แบนเพราะข้อจำกัดเดิมหรือ overhead ใหม่ แต่ e ยังเป็นค่ารวม ไม่บอกสาเหตุเฉพาะ ต้องใช้ profiler และ experiment แยกประกอบ

15Isoefficiency: ต้องเพิ่มงานเร็วแค่ไหนจึงรักษาประสิทธิภาพ

เมื่อ p เพิ่ม overhead เพิ่ม หากต้องการ efficiency คงเดิม ขนาดปัญหาต้องโตชดเชย Isoefficiency function บอกอัตราที่ work W ต้องเพิ่มตาม p ระบบที่ isoefficiency โตช้าถือว่า scale ได้ดีกว่า

จาก Efficiency

E = W / (W + Tₒ) = 1 / (1 + Tₒ/W)

เพื่อให้ E คงที่ ต้องรักษา Tₒ/W คงที่ แล้วแก้หา W เป็นฟังก์ชันของ p

แนวคิดนี้ตอบคำถามเชิงออกแบบได้ดีกว่า speedup จุดเดียว: workload ขององค์กรโตเร็วพอที่จะใช้ cluster รุ่นใหญ่ขึ้นอย่างคุ้มค่าหรือไม่

16Scalability ไม่ได้มีมิติเดียว

มิติ	สิ่งที่เพิ่ม	คำถาม
Size scalability	ข้อมูลหรือจำนวนงาน	ระบบยังทำงานได้เมื่อ problem size โตหรือไม่
Resource scalability	Core, GPU, node	เพิ่มทรัพยากรแล้วได้ประโยชน์เท่าใด
Geographic scalability	ระยะทางและภูมิภาค	Latency/consistency เปลี่ยนอย่างไร
Administrative scalability	ทีม นโยบาย และ fault domain	ใครดูแลและ deploy โดยไม่เป็นคอขวด
Economic scalability	ค่าใช้จ่ายตามโหลด	Cost per result คงที่ ลดลง หรือโตเร็วขึ้น

17Roofline Model และ Arithmetic Intensity

ขอบเขต Roofline

Attainable Performance ≤ min(Peak Compute, Bandwidth × Arithmetic Intensity)

Arithmetic intensity คือ operations ต่อ byte ที่ย้าย ถ้าต่ำ performance อยู่ใต้เส้น bandwidth การเพิ่ม compute units ไม่ช่วยจนกว่าจะลด traffic หรือเพิ่ม reuse ถ้าสูงจึงชน compute roof และควรปรับ vectorization, instruction mix หรือ utilization

Roofline ทำให้คำว่า “ใช้ GPU แล้วยังช้า” มีกรอบอธิบาย GPU อาจมี peak FLOPS สูง แต่ kernel ที่อ่านข้อมูลมากและคำนวณน้อยยังถูกจำกัดด้วย memory bandwidth

18Latency, Throughput และ Tail

HPC batch มักสนใจ makespan ส่วนบริการออนไลน์สนใจ request latency และ throughput ค่าเฉลี่ยอาจดูดีแต่ผู้ใช้ส่วนหนึ่งเจอ p99 สูงมาก โดยเฉพาะระบบ fan-out ที่ request หนึ่งรอ subtasks หลายตัว

ห้องเรียนที่รอคนสุดท้าย

ถ้าแจกข้อสอบคืนได้เมื่อผู้ช่วยทุกคนตรวจเสร็จ เวลารวมไม่ได้ขึ้นกับผู้ช่วยเฉลี่ย แต่ขึ้นกับกองที่ช้าที่สุด ระบบ fan-out ก็เช่นกัน ยิ่งเรียกปลายทางมาก โอกาสเจอ tail จากสักตัวสูงขึ้น

รายงาน p50, p95, p99 พร้อม throughput
ระบุ concurrency และ queue depth
แยก service time จาก queueing time
ทดสอบช่วง steady state และ burst

19Little's Law และ Queueing

Little's Law

L = λW

L คือจำนวนงานเฉลี่ยในระบบ, λ คืออัตราเข้า และ W คือเวลาที่งานอยู่ในระบบ หากรับ 1,000 requests/s และ latency เฉลี่ย 0.2 s จะมีงานค้างเฉลี่ยประมาณ 200 requests

เมื่อ utilization เข้าใกล้ 100% queueing delay มักเพิ่มรวดเร็ว การ benchmark ที่ดันจน throughput สูงสุดโดยไม่ดู latency อาจเลือกจุดทำงานที่เปราะต่อ burst Production capacity ควรมี headroom

20Warm-up, Cache และ JIT

รอบแรกอาจรวมโหลด library, allocate memory, fill cache, JIT compile หรือ GPU context initialization การทิ้ง warm-up ทุกครั้งก็อาจไม่ตรงกับ serverless/cold-start workload จึงต้องรายงานทั้ง cold และ warm ตาม use case

Cache state ต้องควบคุม หากวัด database query รอบสอง ข้อมูลอยู่ cache แล้วและเร็วขึ้นมาก นั่นไม่ผิด แต่ตอบคำถาม warm-cache performance ไม่ใช่ cold read ต้องตั้งชื่อผลให้ตรง

21การวัดซ้ำและความไม่แน่นอน

วัดหลาย repetitions และรายงาน median/percentile หรือ mean พร้อม dispersion
ดู distribution และ outliers ไม่ลบเพียงเพราะไม่สวย
สุ่มหรือสลับลำดับ configuration เพื่อลด bias จากเวลา
ควบคุม background load, thermal throttling และ frequency governor
ใช้ confidence interval เมื่อเปรียบเทียบความต่างเล็ก
เก็บ raw data กับ script เพื่อทำซ้ำได้

ค่าเฉลี่ยสามรอบไม่ใช่พิธีกรรม

จำนวนรอบควรขึ้นกับ noise และขนาด effect หากความต่าง 30% และระบบนิ่ง อาจเห็นชัดเร็ว หากความต่าง 1% ต้องวัดมากและควบคุมสภาพแวดล้อมละเอียดขึ้น

22Energy และ Cost per Result

ระบบเร็วที่สุดอาจไม่ประหยัดที่สุด GPU เพิ่มทำให้งานเสร็จเร็ว แต่ idle power, cloud price และ communication อาจทำให้ cost ต่อผลสูงขึ้น ตัวชี้วัดควรรวม Joules/task, requests/kWh, บาทต่อ simulation หรือค่าเสียโอกาสจากการรอ

ตัวอย่างตัวชี้วัด

Cost per result = (runtime × ราคา resource ต่อเวลา + data transfer + storage) / จำนวนผลลัพธ์

การใช้ spot instance อาจลดราคาแต่เพิ่ม interruption และ retry ต้องคิด expected cost รวม failure ไม่ใช่ราคา list เพียงอย่างเดียว

23Benchmark แบบ Micro, Kernel และ Application

ระดับ	ข้อดี	ข้อจำกัด
Microbenchmark	แยก latency, bandwidth หรือ operation เฉพาะ	อาจไม่แทน access pattern จริง
Kernel benchmark	วัดแกนคำนวณ เช่น GEMM, stencil, sort	ละ orchestration และ I/O
Suite	เปรียบเทียบระบบด้วยงานหลายชนิด	คะแนนรวมอาจซ่อนจุดแข็ง/อ่อน
Application benchmark	ใกล้ผู้ใช้และ workflow จริง	หาสาเหตุยากและทำซ้ำแพง

แนวทางที่ดีใช้หลายระดับ: application บอกว่าปัญหามีจริง profiler ชี้ region และ microbenchmark ทดสอบสมมติฐานเฉพาะ

24Profiler กับ Tracing

Profiler สรุปว่าเวลาอยู่ function/kernel ใด Counter บอก hardware stalls ส่วน tracing แสดง timeline ของ tasks, communication และ idle gaps เครื่องมือแต่ละชนิดตอบต่างกัน

CPU sampling profiler หา hot code โดย overhead ต่ำ
Hardware counters แยก branch/cache/memory/port behavior
MPI trace แสดง rank imbalance และ collective waiting
GPU timeline แสดง transfer, kernels, gaps และ stream overlap
Distributed trace เชื่อม service calls และ queueing ข้ามระบบ

อย่าเริ่ม optimize จาก function ที่ใช้เวลา 5% แม้ดูแก้ง่าย Amdahl เตือนว่าผลรวมสูงสุดถูกจำกัดด้วยสัดส่วนที่เราแตะได้

25การทดลองแบบ Isolate ตัวแปร

ตั้งสมมติฐาน เช่น scaling แบนเพราะ memory bandwidth
เลือกหลักฐาน เช่น bandwidth counter และ stall cycles
เปลี่ยนตัวแปรเดียว เช่น ลด bytes ด้วย compression/layout
วัดภายใต้ input และ environment เดิม
ถ้าผลไม่เปลี่ยน ให้ยกเลิกหรือปรับสมมติฐาน ไม่แต่งคำอธิบายตามหลัง

Performance engineering คือการทดลอง

การเปลี่ยน compiler, thread count, block size และ data layout พร้อมกันแล้วเร็วขึ้นบอกเพียงว่าชุดใหม่ดีกว่า แต่ไม่สอนว่าอะไรทำงาน ความรู้ที่นำไปใช้ต่อเกิดจากการแยกเหตุและผล

26กรณีศึกษา: วิเคราะห์ Superlinear Speedup

สมมติ T(1)=180 ชั่วโมง และ T(8)=8 ชั่วโมง ได้ speedup 22.5 เท่า ก่อนประกาศผลควรตรวจขั้นต่อไปนี้

ยืนยันว่า serial และ parallel คำนวณผลเดียวกันด้วย algorithm ที่เทียบได้
วัด cache miss, page fault และ memory footprint ต่อ worker
รัน parallel code ด้วย 1 process เพื่อแยก code change จาก processor effect
ทดลอง 1,2,4,8 processors และหลาย problem sizes ดูจุดที่ working set ข้าม cache level
วัด CPU time รวมและ wall time แยกกัน
สร้างคำอธิบายว่า overhead ใดของ baseline ถูกกำจัด พร้อมหลักฐาน counter

Superlinear speedup เป็นไปได้จาก cache locality, paging หรือ search pruning แต่ยิ่งผลเกินเส้น linear มากเท่าไร ยิ่งต้องอธิบาย baseline และ mechanism ให้ละเอียดเท่านั้น

27Reproducibility Checklist

บันทึก source commit, build flags, dependencies และ container/environment
บันทึก CPU/GPU model, memory, interconnect และ topology
เก็บ dataset หรือ generator พร้อม random seed
ระบุ warm-up, repetitions, outlier policy และ timing boundary
บันทึก thread/rank placement และ power/frequency settings
เผยแพร่ raw observations ไม่ใช่เฉพาะกราฟ

28แล็บที่แนะนำ

แล็บ Scaling Curve

รันโปรแกรม PS 5 ด้วย 1,2,4,8 workers วัด speedup, efficiency, cost, overhead และ Karp–Flatt แล้วอธิบายจุดที่กราฟเริ่มแบนจาก profiler

แล็บ Roofline

สร้าง kernels ที่เปลี่ยน arithmetic intensity ได้ วัด bandwidth กับ FLOPS แล้ววางจุดบน Roofline เปรียบเทียบ optimization ที่เพิ่ม reuse กับเพิ่ม instructions

แล็บ Benchmark Audit

ให้แต่ละกลุ่มรับกราฟ speedup ที่จงใจซ่อน setup, ใช้ baseline ไม่เท่ากัน หรือเลือก input เดียว แล้วเขียน reviewer report ว่าต้องขอหลักฐานอะไรเพิ่ม

29Residual Analysis: Model อธิบายไม่ครบตรงไหน

ถ้า model ทำนายว่า T(p)=T1/p+communication แต่เวลาจริงช้ากว่า ส่วนต่างหรือ residual ไม่ควรถูกทิ้งเป็น noise รูปของ residual ตาม p และ input size อาจชี้ overhead ที่ model ยังไม่มี

รูป Residual	สมมติฐาน	การทดลองถัดไป
โตตาม p	Scheduling/coordination ต่อ worker	วัด runtime overhead และ task count
กระโดดเมื่อข้าม socket	NUMA/coherence	Pin threads และวัด remote memory
กระโดดเมื่อข้อมูลเกินขนาดหนึ่ง	Cache/TLB/paging	Sweep working-set และ counters
แปรปรวนเมื่อโหลดสูง	Queueing หรือ noisy neighbor	วัด queue/utilization และ isolated run

Model ที่ดีไม่ต้อง fit ทุกจุด แต่ต้องช่วยออกแบบการทดลองที่แยกสาเหตุได้ การเติมพจน์จนสมการพอดีโดยไม่มีความหมายทางระบบเป็น curve fitting ไม่ใช่ความเข้าใจ

30Scalability Envelope

ระบบไม่ได้ scalable แบบคำตอบสองค่า แต่มีบริเวณ workload, resource และ SLO ที่ทำงานได้ เมื่อออกนอกบริเวณ คอขวดใหม่ปรากฏ ควรระบุ problem size, request rate, skew, จำนวน nodes, bandwidth, deadline, p99, cost และ failure headroom

Claim ที่ทดสอบซ้ำได้

แทนคำว่า “รองรับผู้ใช้จำนวนมาก” ให้บอกว่า ภายใต้ 8 nodes, payload 4 KB และ p99 ไม่เกิน 200 ms ระบบรับ 40,000 requests/s ได้โดย CPU ต่ำกว่า 70% และทน node หายหนึ่งตัว

31Sensitivity Analysis

เปลี่ยน message size, block size, thread count, batch และ skew เพื่อดูว่าระบบไวต่ออะไร Parameter ที่ผลแทบไม่เปลี่ยนอาจไม่คุ้ม tune ส่วน parameter ที่เปลี่ยนเล็กแล้ว latency กระโดดคือจุดเสี่ยง

หากสงสัย interaction เช่น block size กับ register use หรือ batch กับ concurrency ควรทำ factorial experiment บางส่วน ไม่สรุปจากการเปลี่ยนทีละตัวอย่างเดียว

32Performance Regression Testing

Correctness test ป้องกันคำตอบผิด Performance test ป้องกันคำตอบถูกแต่ช้าลง ควรมี microbenchmarks สำหรับ hot primitives, end-to-end scenario สำหรับ critical path, baseline แยก hardware และ trend dashboard เพื่อเห็นการเสื่อมทีละน้อย

Threshold ต้องคำนึง noise และเก็บ environment/version เพื่อย้อนสาเหตุ ไม่ควร fail จากความต่างเล็กทุกครั้งหรือเปิดช่องให้ regression ใหญ่ผ่านเพราะ variance สูง

33Benchmark Fallacies

ข้อผิดพลาด	สิ่งที่ถูกซ่อน
เลือก input พอดี cache	Behavior เมื่อข้อมูลจริงใหญ่
รายงานครั้งดีที่สุด	Tail และ noise
ใช้ uniform keys	Hot partition แบบ Zipf
เพิ่ม throughput แต่ปล่อย latency โต	Queue backlog
ละ failure/recovery	Capacity เมื่อ node หาย
นับเฉพาะ compute price	Storage, egress และ retry

34Stop Rule: เมื่อใดควรหยุด Optimize

ควรหยุดเมื่อ SLO ผ่าน มี headroom พอ ผลประหยัดน้อยกว่าต้นทุนพัฒนา หรือคอขวดอยู่นอกขอบเขตที่ควบคุมได้ Optimization ที่ทำให้โค้ดเปราะควรมี benchmark, comment และ fallback

เร็วขึ้น 2% อาจทำให้เข้าใจยากขึ้น 200%

ถ้าผลเล็กและสมมติฐานละเอียด การรักษาเวอร์ชันเรียบง่ายอาจคุ้มกว่าตลอดอายุระบบ

35Checklist รายงาน Performance

คำถามและ metric หลักคืออะไร
Timing boundary อยู่ตรงไหน
Baseline เป็นธรรมและผลลัพธ์เทียบได้หรือไม่
Hardware/software/input ทำซ้ำได้หรือไม่
วัดกี่รอบและรายงาน uncertainty อย่างไร
Strong หรือ weak scaling
Profiler/counter สนับสนุนคำอธิบายหรือไม่
รวม cost, energy, failure และ tail ตามบริบทหรือยัง

36Multi-Objective Performance

ระบบจริงไม่ได้ optimize เวลาเพียงตัวเดียว เราอาจต้องรักษาความแม่นยำ ค่าใช้จ่าย พลังงาน memory footprint และ reliability พร้อมกัน Configuration ที่เร็วที่สุดอาจใช้เงินเพิ่มสองเท่าเพื่อประหยัดเวลา 5% หรือใช้ precision ต่ำจนผลทางวิทยาศาสตร์เปลี่ยน

เป้าหมาย	Metric	ความขัดแย้งที่พบบ่อย
เวลา	Runtime, p99	เพิ่ม replicas/GPU แล้ว cost สูง
Throughput	Jobs/s, requests/s	Batch ใหญ่ทำ latency ต่อชิ้นเพิ่ม
ความแม่นยำ	Error, convergence, quality	Approximation/low precision เร็วแต่คุณภาพลด
พลังงาน	Joules/result	เร่ง clock ลดเวลาแต่เพิ่ม power มาก
ต้นทุน	บาท/result	Resource ถูกอาจช้าและเพิ่ม waiting cost
ความทนทาน	Recovery, successful jobs	Checkpoint/replication เพิ่ม overhead

วิธีรายงานที่ดีกว่าคะแนนรวมแบบกำหนดน้ำหนักลอย ๆ คือแสดง Pareto frontier: configuration ที่ไม่มีตัวเลือกอื่นดีกว่าทุกมิติพร้อมกัน แล้วให้ผู้ตัดสินเลือกตามบริบท เช่น deadline หรือ budget

37Approximate Computing และคุณภาพคำตอบ

บางงานยอมลด precision, sample ข้อมูล หรือหยุด iteration ก่อน convergence เพื่อแลกเวลา/พลังงาน แต่ speedup ต้องรายงานคู่กับ error ไม่เช่นนั้นกำลังเปรียบเทียบคนละโจทย์ ใน Machine Learning ควรวัดคุณภาพบนชุดข้อมูลเดียวกันและรวมเวลาถึง target accuracy ไม่ใช่เพียงเวลาต่อ epoch

เสร็จเร็วแต่ยังไม่ถึงเส้นชัย

นักวิ่งที่หยุดที่กิโลเมตร 8 ย่อมใช้เวลาน้อยกว่าคนวิ่งครบ 10 กิโลเมตร การลด iteration แล้วบอกว่าเร็วขึ้นต้องบอกด้วยว่าคำตอบห่างจากเกณฑ์เดิมเท่าใด

38การสื่อสารผลโดยไม่ Overclaim

ควรแยกสิ่งที่วัดได้จากคำอธิบายและการคาดการณ์: “วัดได้เร็วขึ้น 3.2 เท่าบน input และเครื่องชุดนี้” เป็นหลักฐาน ส่วน “เพราะ cache locality” เป็นสมมติฐานที่ต้องมี counter สนับสนุน และ “จะ scale เป็น 30 เท่าบน cluster ใหญ่” เป็น extrapolation ที่ต้องมี model กับข้อจำกัด

รายงาน limitation ไม่ทำให้งานอ่อนลง แต่กำหนดขอบเขตที่ claim ยังจริง งานที่บอกตรง ๆ ว่าทดสอบเฉพาะ warm cache และ node เดียวมีประโยชน์กว่างานที่ใช้คำว่า scalable โดยไม่ระบุขนาดหรือ failure condition

39สรุปและขั้นตอนถัดไป

การวัด performance ไม่ใช่ขั้นตอนตกแต่งหลังเขียนโปรแกรม แต่เป็นส่วนของวิธีวิจัย ต้องนิยามเวลาและ baseline ให้ตรงคำถาม แยก strong/weak scaling อ่าน speedup คู่กับ efficiency, cost และ overhead แล้วใช้ model อย่าง Amdahl, Gustafson, Karp–Flatt, isoefficiency และ Roofline เป็นเลนส์ ไม่ใช่คำทำนายศักดิ์สิทธิ์

บทถัดไปจะย้ายจากงานคำนวณหนึ่งงานไปสู่ Internet service ที่รับผู้ใช้จำนวนมาก Metric จะเปลี่ยนจาก runtime ของ job ไปเป็น throughput, tail latency, queue, availability และ cost แต่หลักเดิมยังอยู่: คอขวดเกิดจาก work, communication, contention, placement และการรอครับ