Chapter 27 — Teaching Notes

One-line purpose. Turn "Fortran is fast" from a slogan the students have taken on faith for 26 chapters into a mechanism they can explain, predict, and (soon) measure — resting on two load-bearing ideas: the column-major/cache-line loop-order effect (the payoff of Ch. 5) and the no-aliasing advantage (the deepest "why Fortran," rigorized from Ch. 1).

Key ideas to emphasize

  • You don't make Fortran fast — the compiler does; your job is to hand it optimizable code. This reframes the whole chapter and preempts the "close to the hardware" misconception. Fortran is high-level; its speed comes from giving a very good compiler provably-safe rewrites, not from touching the metal.
  • Arithmetic is cheap; memory is expensive. The threshold idea of §27.2. Most numerical loops are memory-bound, so the question "is this cache-friendly?" comes before "how many flops?" Put the cache-line diagram on the board and make them trace both loop orders' memory traffic by hand.
  • Inner loop over the FIRST index — by reflex. The single highest-return habit in the book. It rewards Ch. 5 and is drilled again in Ch. 29. Students who leave with only this are ahead.
  • The compiler optimizes because Fortran forbids aliasing. The chapter's reserved Threshold Concept, and the sentence to make them memorize. The guarantee is a language default, enforced by the standard's contract; C's restrict is the opt-in, per-pointer, breakable version. This is why the no-alias rule is a gift with a contract — break it (alias a written arg) and you get UB that differs at -O0 vs -O3.
  • pure/elemental are optimization licenses, not decorations. Pay off the Ch. 6.4 foreshadow: purity lets the compiler hoist/share/reorder/delete/parallelize; elemental hands it a vectorization-shaped loop. The compiler enforces purity (a print in a pure proc is a compile error) — the language catching the exact thing that blocks vectorization.
  • Measure, don't guess. §27.5 + the bridge to Ch. 28. The optimization report turns the optimizer into a conversation; "I think it's faster" becomes "the compiler confirms the loop vectorized."

Misconceptions to preempt

  • "Fortran is fast because it's low-level / close to the hardware." Exactly backwards — it's high-level; the speed is because the programmer doesn't touch the hardware and the compiler is free to reshape.
  • "The compiler will fix a bad loop order for me." It sometimes interchanges loops, but often cannot (calls, dependencies, complex indexing). Loop order is the programmer's responsibility.
  • "Aliasing a written argument is a compile error." No — it is generally NOT diagnosed (the compiler can't see the call site). It is undefined behavior. This is the scariest kind of bug: correct at -O0, wrong at -O3, never flagged. Demo the §27.3 "Find the Bug" (smooth(x,x)).
  • "Vectorized ⇒ 4× faster." Only if compute-bound. A fully-vectorized memory-bound loop (triad, stencil) sees little speedup — the arithmetic was never the bottleneck. This is the sober lesson of CS-02's arithmetic-intensity table; do not skip it.
  • "-Ofast is just a faster -O3." It adds -ffast-math, which reorders FP arithmetic (non-associative — Ch. 20!) and can change results. Tie it to the Ch. 20 non-associativity point; it is opt-in for a reason.
  • "gfortran unrolls my loops at -O3." It does not — needs -funroll-loops. A good example of "what the compiler can do vs what it does by default," which is exactly why the report exists.

Live-coding demo (≈ 20 min) — best at a machine with gfortran + a browser on godbolt.org

  1. Loop order (§27.2). Type the two nests summing a large a(n,n) (code/example-01-loop-order.f90), compile -O3 -march=native, run both, show the elapsed gap live. Predict the direction first on the board (first-index-inner wins). The sum is identical — point that out.
  2. The report (§27.5). Recompile with -fopt-info-vec; find the "loop vectorized" line. Then break vectorization (add a print to a helper, or alias the arrays) and show -fopt-info-vec-missed naming the reason. This is the "conversation with the compiler" moment.
  3. Godbolt (§27.1/27.5). Paste c = a + b; toggle -O2 → -O3 -march=native; watch addsd become vaddpd. Ten seconds, and vectorization becomes visible rather than abstract.
  4. The aliasing bug (§27.3). Show call smooth(x, x); explain why it may give different answers at -O0 vs -O3. (You can't reliably demonstrate the divergence — it's UB — so reason it, honestly.)
  5. Checkpoint. Run project-checkpoint.f90; confirm the correctness block (interior=20, max|diff|=0, maxval=100) and read the two timing lines. The measured ratio is the payoff of Ch. 5 made real.

Time budget (≈ 3 h of class + lab)

  • §27.1 what the compiler does (levels, inlining, unrolling, vectorization intro): 30 min.
  • §27.2 column-major / cache line / the two nests: 40 min (the core; do the memory-traffic trace on the board).
  • §27.3 the no-aliasing advantage + C/restrict + the Find-the-Bug: 40 min (the intellectual heart).
  • §27.4 pure/elemental optimization licenses: 20 min.
  • §27.5 reading the report + Godbolt: 25 min (best live at a machine).
  • Project Checkpoint + lab (run it, measure your own ratio): 30–40 min.

Prerequisites to review before teaching

  • Chapter 5: column-major layout, the cache-line intuition, whole-array operations (§27.2 is its payoff).
  • Chapter 6 §6.4: pure/elemental (§27.4 pays off the explicit "Chapter 27" IOU there).
  • Chapter 1 §1.3: the informal "no-aliasing" and "arrays first-class" pitch (§27.3 rigorizes it).
  • Chapter 20: IEEE 754, non-associativity of FP addition (for -ffast-math and the bit-identical argument).
  • Chapter 2: -O2, -Wall, the compile-link cycle (the flags this chapter extends).

A note on the honesty rule (say this to students)

gfortran was not installed while the book was written, so no timing here was measured — every speedup is an illustrative order of magnitude, and every correctness value was hand-computed. This is a feature, not an apology: it forces you to run the code yourself and measure your own machine, which is the entire point of Part VII. When your ratio differs from "typical," that is not an error in the book — that is your hardware talking, and learning to listen to it is the skill.