Chapter 30 — Instructor Notes

Teaching Notes

Where this sits. Chapter 30 closes Part VII (Performance) and is the easy chapter of the four — intermediate, ~4 hours — deliberately, because it follows the demanding Ch 27–29. Its job is to convert three chapters of hard-won understanding into a build habit, and to hand the reproducibility baton to Ch 37. It is also the first time the book leaves gfortran, so it doubles as a gentle "the wider compiler world" orientation.

The single idea to nail. -O0 through -O3 change speed, not answers; -Ofast changes the promise. If students leave with only one thing, make it this. It dissolves two chronic confusions at once: fear of turning up optimization ("will it corrupt my results?" — no) and misplaced trust in -Ofast ("more speed, same code, why not?" — because it can silently change your numbers). The (1e20 + -1e20) + 1 example that turns 1.0 into 0.0 is the emotional core of the chapter; spend time there.

Key ideas to emphasize. - Two builds, always: a guarded development build and a lean release build. This is a habit, not a fact — reinforce it every time you compile in front of the class. - Never time a -fcheck=all build. This is the most common self-inflicted benchmarking wound; Case Study 30.1 is built entirely around it. - Record the flags. A number without its build recipe is not a measurement. Tie this forward to Ch 37 so it reads as the start of real software engineering, not nagging. - -march=native is a scalpel: superb where build==run, dangerous in a shipped binary.

Misconceptions to preempt. 1. "Higher -O might give wrong answers." Only -Ofast/-ffast-math can; the rest are result-preserving. Show example-01 printing 385.00 at three levels. 2. "A bug that appears only at -O3 is a compiler bug." Almost never — it is the student's own undefined behavior (uninitialized variable, out-of-bounds) that optimization exposed. The Find-the-Bug callout and the -O0 -fcheck=all -finit-real=snan diagnostic are the payoff; this is the chapter's Threshold Concept. 3. "Same source ⇒ same answer across compilers." Intel's relaxed FP default (-fp-model fast) alone refutes this. The cross-compiler agreement-to-tolerance idea (CS-02 Phase 3) is the mature response. 4. "-Ofast is just faster -O3." It is -O3 plus a relaxation of IEEE. If you want the vectorization without the numeric risk, that is plain -O3.

Live-coding demo (15 min). Take example-02-ofast-reassoc.f90 (or write it live). Build at -O2; run; get 1.00. Reason through the parentheses on the board. Then build the same file at -Ofast. Whether or not your gfortran actually flips it to 0.00, walk the class through why it is allowed to. Then open example-01 and show that -O0/-O2/-O3 all print 385.00 — the contrast (safe levels vs -Ofast) is the whole lesson in five minutes. If time allows, paste a loop into godbolt.org and show the AVX instructions appear at -O3 -march=native.

Prerequisites to review before class. Ch 20 (non-associativity of FP, machine epsilon) — the -Ofast danger is meaningless without it. Ch 2 (the five early flags, dev vs release). Ch 28 (timing methodology) if you will assign Case Study 30.1.

Time budget (~4 h of student work). - §30.1 (the ladder + -Ofast + -march=native + -flto): 90 min — the heart, do not rush. - §30.2 (other compilers): 30 min — a reading/translation section. - §30.3 (two builds): 30 min. - §30.4 (PGO + reproducibility): 45 min. - §30.5 (portability): 20 min. - Project Checkpoint + one case study: 45–60 min.

Assessment tips. The quiz's "what does this print?" items (Q19–Q20) and the interleaved exercises (23, 25) discriminate real understanding from memorized flag lists. Exercise 28 (write a flags policy) makes an excellent short written assignment; Case Study 30.1 (decompose the dishonest 24×) is a strong exam or lab prompt because it cannot be answered by flag recall alone.

A note for the instructor on honesty. Every speedup in the chapter is Tier-2 illustrative and labeled; none was measured. If you run the examples live and your numbers differ, that is a teaching opportunity, not an erratum — it is exactly why the chapter insists you measure and record rather than trust a printed figure. Model that: run the checkpoint on the classroom machine and record your number with your flags.