Tournament Trees, Buffering & Run Generation

Find the min of k fronts, fast

Outputting one record means finding the smallest among k run-fronts. Scanning costs k−1 comparisons per record — at k = 1000, that's 999 comparisons for every single record. We need the next minimum in log k. Answer: tournament trees.

Keep disk and CPU busy at once

Disk reads, disk writes, and in-memory merging are three different pieces of hardware. With the minimum k+1 buffers, whenever the output buffer is being written the merge must halt — the CPU twiddles its thumbs at disk speed. Answer: double & floating buffers.

Make runs longer than memory

Phase 1 produced runs of exactly M records — memory-sized. Fewer, longer runs mean a smaller m and fewer passes. Can a memory of M records emit runs longer than M? Astonishingly yes, ~2M on average. Answer: replacement selection.

Think IPL playoffs or Wimbledon. A winner tree for n players is a complete binary tree with:

• n external nodes (leaves) — the players. For us: the current front record of each of the k runs.
• n − 1 internal nodes — the matches. Each stores the winner of its two children. We want the minimum, so smaller wins: a min winner tree.
• The root holds the overall winner — the smallest of all k fronts, readable in O(1).

Height (excluding the player level) = log₂ n. Building it plays every match once: n − 1 matches, O(n).

Read it like a sports bracket: 4 vs 3 → 3 wins; 6 vs 8 → 6; 1 vs 5 → 1; 7 vs 3 → 3. Semis: 3 vs 6 → 3; 1 vs 3 → 1. Final: 3 vs 1 → champion 1.

Replaying a match in a winner tree needs the new value's opponent. But who is the opponent at each internal node? It is the player who lost the last match played there — the winner moved up and away! In a winner tree you must look at a node's sibling subtree to find that loser.

So flip the storage: let each match node store the loser, and keep the overall winner in one extra node above the root. Now, walking up from the changed leaf, your opponent is sitting right there in the node: one comparison, write the new loser, carry the winner up. Same Θ(log n) asymptotics, but fewer memory accesses and exactly one comparison per level.

Check one node: the final was 3 vs 1 → the root stores the loser 3; winner 1 goes on top. When 1's leaf is replaced, its replay partners (5's node, 3's node…) are exactly the values stored on its path.

Every animation so far has treated a "read" or "write" as one instantaneous thing. In reality, disk transfers use DMA (Direct Memory Access): the CPU tells the disk controller "copy this block to/from this memory address," then walks away — the controller moves the bytes in the background and interrupts the CPU only when done. So disk-in, disk-out, and CPU-merge really are three independent workers running at once, not a simplification for this course. That's what the animation below now shows explicitly.

But this only pays off if each worker always has somewhere to work. With just the minimum k + 1 buffers:

• While the output buffer is being written to disk, merged records have nowhere to go → merge halts. Fix: two output buffers — merge into one while the other writes.
• While a run's input buffer is being refilled, if the merge needs that run's next record → merge halts. Fix: read ahead into a second buffer for that run.

So aim for 2k input + 2 output = 2k + 2 buffers. But there's a trap: fixing two buffers per run still fails — watch it happen →

Lecture 4's Phase 1 was: fill the desk, sort, ship the whole bundle, repeat — runs of exactly M. But notice: the moment you ship the smallest sheet, its spot is free and a new sheet arrives immediately. If the new sheet's number is larger than what you just shipped, it can still join the current sorted bundle! Only when it's smaller must it wait (frozen ✱) for the next bundle.

So: keep a pool of M records (in practice, a loser tree — Walters, Painter & Zalk). Repeatedly output the smallest unfrozen record, refill from input, freeze arrivals smaller than the last output. When everything is frozen, close the run, thaw, continue. Runs come out ≈ 2M long on average (Knuth's "snowplow" argument), so m halves, and passes = log_k m shrink.