ContentsThe library

Turning Text Into Instructions

Your Instructions Arrive in Order and Are Executed in Whatever Order Suits

Last timeToo Few Places to Put Things

The compiler rearranged your program and then handed it to a processor that rearranges it again at run time. The second reordering is invisible until a second thread is watching.

Not the order you wrote

Seven lessons have followed your program from text to machine instructions. The

last transformation happens after all of that, at run time, inside the

processor, and it is the largest rearrangement of the lot.

The instructions arrive in order. They are not executed in order. A modern

processor fetches a long way ahead, keeps a hundred or more instructions in

flight at once, and starts each one at the moment its inputs exist and a

suitable unit is free. An instruction whose input is still coming from memory

sits and waits while a dozen instructions written after it run to completion.

What stops this from being chaos is the last step. Results are held aside as

they are produced and made official in the original program order. Nothing

becomes visible out of sequence, so from the point of view of the thread doing

the work, the program ran exactly as written.

FIG 1What happens to one instruction
Two waiting loops, and they are the only places the original order is honoured: once at fetch and once at retirement. Everything between them is scheduled by readiness.

Why it is worth doing

The cost of this machinery is large. A substantial share of the transistors on

a processor, and of its power budget, goes to keeping instructions in flight

and sorting out their order. It is worth it because of one number.

FIG 2The cost of waiting in order
cycles lost to waiting
number of times the program stops to wait
cycles each wait costs
With c around three hundred for an access that misses every cache, a program that waits a thousand times in a loop loses three hundred thousand cycles. In-order execution pays that in full; out-of-order execution fills most of it with work that was available anyway.

Lesson eight of the previous course on this shelf established the number: an

access that reaches main memory costs a few hundred cycles. In an in-order

machine everything behind that access stops for the duration, including

instructions that have nothing to do with it. There is almost always work

available that does not depend on the value being fetched, and out-of-order

execution exists to find it and do it during the wait.

The lesson stops here

5 more paragraphs to go

You have read the opening. The rest of the argument, the problems that check whether it landed, and the lines worth keeping at the end all come with a plan.

The first lesson of every course in the library reads the whole way through, free, so you can see exactly what the rest of them are.

See the planThe contents

This is the reading half

Starting the course gives you your own copy of it. Every idea on every page has problems standing under it, marked with a reason rather than a tick, and any sentence you do not believe can be opened and argued with. None of that can happen on a page nobody owns.

The contents

The rest of this course

  1. 01Before It Can Read Your Program It Has to Decide Where the Words End
  2. 02Precedence Is Not a Table You Memorise, It Is the Shape of the Rulesopening only
  3. 03The Stage That Finds Out Whether Your Names Refer to Anythingopening only
  4. 04One Neutral Form in the Middle Turns a Multiplication Into an Additionopening only
  5. 05Every Transformation Obeys One Rule, and the Rule Is Narrower Than You Thinkopening only
  6. 06The Compiler Deleted Your Safety Check Because You Had Already Broken the Ruleopening only
  7. 07Thousands of Values and Sixteen Places to Keep Themopening only
  8. 08Your Instructions Arrive in Order and Are Executed in Whatever Order Suitsyou are here

Read alongside