Project 2 — The Placement Study

“If the whole body were an eye, where would be the sense of hearing? If the whole body were an ear, where would be the sense of smell?” — 1 Corinthians 12:17 (ESV)

Chapter: 2 — Not All Cores Are Equal Due: End of Week 2 Weight: 7% of your course grade — one of the six weekly labs, all weighted equally. (The Week 2 quiz is a separate 1.5%.) Submit: One link to a public repository containing report.docx, measurements.xlsx, placement-decision.docx, ai-usage.txt, and your raw measurement output files. Nothing else is required and nothing else is read. Workbench: Every Normal-tier requirement is completable on Workbench B — a browser dev environment with no install and no admin rights. Workbench L (a laptop) makes the measurements cleaner. Workbench D (an Android device) is optional everywhere and appears only in the Medium and Hard tiers as a “go further” path. See Appendix A. Allowed tools: g++ or clang++, python3, your shell, and this chapter’s code/ directory. Vendor specification pages and architecture reference manuals for anything you cite. The textbook. AI policy — explain, never source. Use a model freely to explain a concept, review your prose, or check your arithmetic. Do not use one as the source of any figure. Every number in this submission traces to (a) your own measurement, (b) a primary source you cite by URL, or (c) the synthetic model shipped with this chapter, explicitly labeled as synthetic. An uncited external figure scores zero on its line. A fabricated one fails the integrity line for the whole project. ai-usage.txt is mandatory and is graded on honesty, not on abstinence. See Appendix D.

The Setup

A Lutheran relief agency runs a field-survey program in three rural districts. Community health workers carry mid-range Android tablets for ten-hour shifts, walking between households, with no reliable charging until they return in the evening. The tablet does four things all day: it shows a long, scrolling case list; it quietly syncs and indexes the day’s photographed intake forms in the background; it ticks a location and form-autosave every thirty seconds so nothing is lost when a device dies; and, when a worker photographs a paper form, it runs an on-device image enhancement so the handwriting is legible before upload.

Last quarter the workers complained that the case list “stuttered.” A well-meaning contract engineer fixed it: he set a utilization floor on every thread the app owns, so that everything the app does now lands on the fastest cores available. The stutter went away.

And the tablets stopped lasting the shift. Devices that used to come back at 30% now come back dead by mid-afternoon, and a health worker with a dead tablet writes on paper and loses a day to re-entry. The agency’s operations director does not know what a core is. She knows that her fix broke something, that the vendor is telling her to buy newer tablets, and that she cannot afford to.

You have been asked for a placement study: what work belongs on which class of core, what each choice costs in joules, and — the part she is actually paying for — a defensible recommendation she can hand to the contractor. She does not need to understand DynamIQ. She needs to know which of her engineer’s decisions to reverse and why.

The Corinthian error is sitting right in the middle of this scenario, committed against a die instead of a congregation: someone decided the fast core was the good core, put everything on it, and degraded the body. Your job is to replace that ranking with a rule.

Setup (the starter)

Everything you need ships in this chapter’s code/ directory. Build the C++ once:

g++ -O2 -std=c++17 -pthread migrate.cpp -o migrate

• code/core-profiles.csv — the three core classes. Synthetic teaching data; its first line says so, and so must your report.
• code/placement_model.py — time, energy, and deadline verdict per core class, plus the cheapest class that meets the deadline. Models one core at one operating point.
• code/amdahl.py — the speedup curve, and --hetero for the prime-equivalent core count of an asymmetric cluster.
• code/migrate.cpp — the cache-warmth and migration measurement, with warm / cold / migrating (inner) / migrating (outer) and a stated report of whether affinity control was available.

If you did the reps in the reps, you have already drafted three of the four sections below. That was deliberate.

Learning Targets

By completing this project you will demonstrate that you can:

• Inventory a real CPU’s topology and asymmetry from primary sources, and distinguish what the operating system told you from what you looked up.
• Design and run a repeated measurement with warm-up, medians and dispersion, and stated conditions — and report it so a stranger could repeat it.
• Separate two overheads that arrive mixed together in one experiment, and say in writing which number is which.
• Apply the placement rule — the cheapest core that meets the deadline — to named workloads, and defend each decision in joules rather than adjectives.
• Correct a core count for heterogeneity before doing any parallel-speedup arithmetic.
• State the limits of your own model out loud: what is measured, what is modeled, and what you would need real hardware to settle.

Normal Tier

Goal: measure your own machine honestly, then place four named workloads on core classes and defend every row.

Required work

1. Machine inventory. In report.docx, record your machine’s CPU topology: logical CPU count, whether it is heterogeneous, how many of each class, and the private cache sizes if the OS will tell you. Use the commands from Rep 1. For every figure, state where it came from — a command you ran (quote it), or a primary source (cite the URL). Any figure you cannot attribute is either dropped or explicitly marked unverified.

2. The concurrency sweep (this is the measurement, and it is graded hardest). Run increasing numbers of concurrent copies of the fixed kernel and record what happens as the OS runs out of good cores to put them on:

for t in 1 2 4 8 16; do
  echo "=== $t concurrent copies ==="
  for i in $(seq 1 $t); do ./migrate --kib 256 --rounds 200 > run-$t-$i.txt & done
  wait
  grep -h "warm (same core)" run-$t-*.txt
done

Stop at or just past your logical CPU count. In measurements.xlsx, per Appendix C, report for each t: the number of repetitions, the median of the per-copy medians, a dispersion measure (IQR or min–max across copies), and your conditions — plugged in or on battery, what else was running, whether the machine was thermally settled, and whether you controlled placement. Commit the raw run-*.txt files unmodified.

3. Read the sweep. In report.docx, answer: at what t did the copies stop agreeing with each other, and what is the spread at your highest t? Then the interpretation — is that spread consistent with the class inventory from step 1, and what else could produce it? (Shared last-level cache pressure, memory bandwidth, a frequency change, and another process are all real candidates. Naming a rival explanation you cannot rule out earns credit; pretending there isn’t one does not.)

4. The Amdahl correction. Using code/amdahl.py, state the prime-equivalent core count of a 1,3,4 cluster and the speedup it supports at a parallel fraction you choose and justify. State your assumed p explicitly and say what it is based on. Then answer in one sentence: how much of the sweep’s sublinearity in step 3 does heterogeneity explain, and how much does it not?

5. The placement table. In placement-decision.docx, build a four-row table using code/placement_model.py with the workload sheet below. Columns, exactly these:

6. Defend every row under The Four Questions. Under the table, one short paragraph per workload covering all four: performance (does it meet its deadline), energy (what it costs, and what the rejected alternative would have cost), thermals (what changes if this runs continuously — you may point forward to Chapter 5, but you must name the question), and placement (why this class and not the two you rejected). At least one row must be a row where the fastest core is the wrong answer, and that row’s defense must be argued in joules with the ratio stated.

7. The recommendation. Close report.docx with the two paragraphs the operations director actually asked for, in plain language and with numbers: which of the contractor’s decisions to reverse, and what you expect it to buy. No jargon she would have to look up.

8. The honesty section. A clearly headed section of report.docx stating: which numbers you measured, which came from the synthetic model, and which came from a cited primary source — and then what you would need to measure on real hardware to turn this study into an engineering decision rather than a well-reasoned model. Name the specific measurement, not “more testing.”

9. ai-usage.txt. One honest paragraph: which model and version, what you used it for, what you rejected, and confirmation that no figure in this submission came from it.

The workload sheet

SYNTHETIC TEACHING PARAMETERS — modeled on the shape of published mobile workloads, not measured from any product or application. You must state this in your report and say what it limits. If you would rather derive your own instruction counts from a measurement you took, do that instead and show your working; that is a better answer, not a riskier one.

python3 placement_model.py --instructions 24e6  --deadline-ms 8.3
python3 placement_model.py --instructions 1.2e9 --deadline-ms 60000
python3 placement_model.py --instructions 3e6   --deadline-ms 20
python3 placement_model.py --instructions 6e9   --deadline-ms 1000

W4 will not give you a comfortable answer on one core. Deal with that honestly in the “what this row does not model” column and in that row’s defense — the correct professional move there is worth more than a confident wrong one.

Normal-tier rubric (out of 100)

Medium Tier (+up to 25% extra credit)

M1. The measured migration cost

Turn Reps 4–6 into an experiment with a conclusion. Sweep the working set and record the cold-versus-warm ratio:

for k in 64 128 256 512 1024 2048 4096; do
  echo "=== kib=$k ==="
  ./migrate --kib $k --rounds 60
done

In a section of report.docx (not a new file — see Appendix D on deliverable names), report:

1. The table of working-set size against cold ÷ warm, with dispersion.
2. The two costs held apart: outer − inner (thread creation) and inner − warm (arriving on a different core), each stated in a sentence that cannot be misread as the other. State whether your platform reported affinity control as available, and say what that permits you to conclude and what it does not.
3. The working-set size at which the penalty collapses, compared against the private cache size from your inventory.
4. The scheduler recommendation, which is the point of the whole exercise: for each of W1–W4, should the scheduler be free to migrate that thread, or should it be pinned or damped? Answer in terms of working set and deadline, not adjectives.

M2. The always-on arithmetic

W3 runs every 30 seconds for a ten-hour shift. Compute, showing the arithmetic:

• The number of W3 executions per shift.
• The total energy per shift on the efficiency core, and on the prime core, in joules.
• The ratio between them.

Then the architectural observation this course wants you to reach on your own: even the efficiency-core answer is paying an application processor to wake up for three million instructions. Name the block that should really be doing this work, and say in one sentence why it is not a CPU core at all. (Chapter 6 is where that block gets its own week — anticipating it here is exactly the move.)

Optional Workbench D path: if you have an Android device with developer options, record its battery-usage attribution across a period of foreground scrolling and a period of background sync, and compare the shape to your model. This is a “go further” step and carries no additional points; it is here because touching real hardware changes how you read a model.

Hard Tier (+up to 25% additional extra credit)

H1. The wearable memo (the judgment piece)

The agency’s next procurement is a wrist-worn device for the same health workers: it takes the location and autosave tick (W3), a much-reduced case-list scroll, and nothing else. Your silicon partner gives you a four-core budget on the same three classes in code/core-profiles.csv, and an area budget you should treat as tight.

Write the memo as a section of report.docx, addressed to a technical reader, answering:

1. Which four cores, by class. State the configuration (e.g. 0,1,3) and defend it.
2. The energy arithmetic. For W3 at its real duty cycle and for a reduced scroll frame of your own stated instruction count and deadline, compute per-shift energy under your configuration and under at least two rejected configurations. Use placement_model.py and show the numbers.
3. The area argument. Using the relative_area column, say what your configuration costs in area against the alternatives, and what you bought with the difference.
4. The parallel-speedup check. Run amdahl.py --hetero on your configuration and on one alternative. State whether parallel throughput mattered to this decision at all — and if it did not, say so plainly, because deciding that a metric is irrelevant is a real engineering act.
5. What would change your mind. Name the single measurement that would most likely overturn your recommendation, and say which direction it would push you.

A memo that says “one of each, obviously” without arithmetic scores nothing. A memo that says “four efficiency cores because efficiency” also scores nothing — check it against the scroll frame’s deadline before you write it. The grade lives in the tradeoff you name and the number you back it with.

Submission

Submit one URL: a public repository containing exactly:

1. report.docx — inventory, sweep interpretation, Amdahl correction, the recommendation, the honesty section, plus the Medium and Hard sections if attempted.
2. measurements.xlsx — the measurement log: what, on what, how many repetitions, median, dispersion, conditions.
3. placement-decision.docx — the placement table and the four defenses.
4. ai-usage.txt — the honest disclosure.
5. Your raw run-*.txt output, unmodified.

Open report.docx with this header, filled in:

# Project 2 — The Placement Study

Tier targeted:        Normal / Medium / Hard
Machine measured:     (logical CPUs, heterogeneous yes/no, classes)
Conditions:           (power source, thermal state, what else was running)
Placement rule used:  the cheapest core that meets the deadline
Row where fastest was wrong:  (which workload, and the energy ratio)
What is modeled, not measured:  (one line)
What I would measure next:      (one line, specific)
AI usage:             model + version, used for ____, no figure sourced from it
                      Signed: <your name>

Hints (Read Before You Begin)

• Do the reps first. Reps 1, 2, 5, 9 and 10 are literally the sections of this project, done small. If you did them, this is an afternoon of assembly. If you skipped them, it is a week.
• Run the sweep on a settled machine. Close everything. Do not run it on battery for one t and plugged in for another — that is two experiments in one table, and Week 8 will teach you to spot it in someone else’s report. Whatever you choose, state it.
• The spread across concurrent copies is the measurement, not a nuisance. Most students report the mean across copies and throw away the very thing the experiment exists to show. Report the spread.
• Filter, then minimize. Every placement decision is: eliminate the classes that miss the deadline, then pick the cheapest survivor. Doing it in the other order produces answers that are efficient and useless.
• W4 is supposed to be uncomfortable. One core class meets a one-second deadline for six billion instructions, and it is the expensive one. The honest response names the model’s limit and points at the tool that addresses it — not a confident single-core answer.
• Do not invent an instruction count. Either use the sheet (labeled synthetic) or derive one from a measurement and show the derivation. There is no third option that passes.
• Cite or drop. If you want to state a real device’s core configuration or cache size, cite the vendor’s own page. If you cannot find it there, write “not published” — which is itself a finding, and a more interesting one than a number.

What Mastery Looks Like (Beyond the Rubric)

A great Placement Study reads like something a staff engineer would put in front of a director. The measurement section is reproducible by a stranger: conditions stated, repetitions counted, dispersion shown, raw data committed. The placement table is not four opinions but four applications of one stated rule, and the row where the rule contradicts intuition is the row the author spends the most words on. The Amdahl correction is used as a check on enthusiasm, not as a decoration. And the honesty section is specific — it names the exact measurement missing, on the exact hardware, that would move this from a model to a decision.

The tell of a weak submission is a placement table with no losers: every row picks the obvious core, no alternative is priced, and no tradeoff is visible. Placement without a rejected option is not analysis. It is preference with a table around it.

Coach’s Note — The operations director in this scenario is not going to read your DynamIQ paragraph, and she should not have to. But she will absolutely notice whether your recommendation comes with a number and a rejected alternative. That is the difference between an engineer she trusts and a vendor she does not. Write the technical sections for your peers and the recommendation for her, and do not let either one lie.

When You’re Done

1. Re-read measurements.xlsx and ask: could a stranger reproduce this from what I wrote alone? If any condition is in your head rather than the file, put it in the file.
2. Check every row of the placement table has a rejected alternative with a cost attached. A row with no loser is a row with no reasoning.
3. Search your own report for numbers. For each one, say out loud where it came from. Any that answers “I think I read it somewhere” gets cited or deleted before you submit.
4. Confirm the words synthetic and modeled appear where they should. If a reader could mistake core-profiles.csv for a measurement, you have not finished.
5. (Hard) Re-read the memo and strip every sentence that has no number and no tradeoff in it. What remains is the memo.
6. Commit, push, submit the URL. Then read Chapter 3 — the memory hierarchy, where you find out that most of what you just called “CPU performance” was actually memory behavior wearing a costume.

A theological footnote. The verse over this project is Paul refusing a ranking. Corinth had sorted its members into impressive and unimpressive and drawn the obvious conclusion; Paul answers that a body made entirely of the eye is not a better body but no body, and that the members which seem weaker are indispensable. The contractor in this scenario made exactly the Corinthian move — he decided which core was the good one and put everything on it — and the tablets came back dead. Your placement table is, in a small and literal way, the correction: each part measured on the scale of its own office, given the work it is actually for. That is not sentiment about silicon. It is a habit of attention, and it transfers. The engineer who can only value the impressive path will misjudge the efficiency core, and will misjudge most of the quiet, constant, uncomplimented work that keeps every system — and every congregation, and every relief agency — actually running.

See you next week.