Roofline

Which roof binds a loop is predictable from its arithmetic intensity, on one core and on all ten P-cores: a streaming loop with under one flop per byte is bound by the memory roof, a loop with ten flops per byte and the roof's own instruction mix reaches the compute roof (0.96 of the FMA peak on one core, 0.92 on ten), and a Horner polynomial with sixteen flops per byte is bound by the compute roof, no faster from L1 than from DRAM, at 0.73 to 0.75 of the peak.

bench.c measures the roofs, then five kernels of known intensity, all on one thread and again on one thread per P-core (10 threads, pthreads, no pinning since macOS has none, every thread at user-interactive QoS so the scheduler prefers P-cores). The compute roof is the NEON fmla rate of 20 independent float32x4 accumulator chains fed by one L1 load per 20 FMAs from a 4096-byte buffer, 8388608 iterations per pass, a few milliseconds like every other pass so that a thread descheduled by other work costs the roofs and the kernels alike; the same loop with the textbook 16 chains is measured beside it, because on this core 16 chains fall short of the peak and the roof has to be the larger figure. There are three memory roofs, one per stream mix, because on one core the write path is not the read path and two read streams are not one: a float32 sum with 16 independent add chains over a 536870912-byte array, thirty-two times the 16777216-byte L2 of a P-core cluster and sixteen times the two clusters together, is the roof for a loop that only reads; a copy of 268435456 bytes into another 268435456 (8 bytes per element) is the roof for a loop that reads one array and writes one; a triad z = x + a*y over three 268435456-byte arrays (12 bytes per element) is the roof for a loop that reads two and writes one. A write-only fill of 268435456 bytes is measured beside them, because it decides whether a write-allocate read has to be counted. Every roof is measured twice at each thread count, before the kernels and again after them, and the higher median is the roof, since a roof is a ceiling; the table shows that measurement's median, min, max and cv with the other median beside it. Before the first roof the FMA loop spins untimed for 300 ms so the clock has ramped, and every case discards untimed passes until at least 100 ms have run (at least one pass; WARMUP_MS changes it), so the first case of the run is warmed like the rest. The kernels run over 268435456 bytes of float32 each for x and y, the two halves of the bandwidth array: saxpy (y = a*x + y, 2 flops per element over 12 bytes: read x, read y, write y, intensity 0.167 flop/B), a 7-point 1-D stencil (out[i] = sum of tap[k] * in[i+k-3], one multiply and six FMAs, 13 flops over 8 bytes: 4 read and 4 written, the six other loads per element being L1 hits, intensity 1.625 flop/B), fma_stream, which is the roof's own function with its address mask opened so its one load per 20 FMAs walks x instead of cycling the 4096-byte buffer (40 flops over the 4 bytes read, intensity 10.0 flop/B; it is called once per 65536-byte block and the block sums are added in double), poly, a degree-32 polynomial by Horner on every element with the results summed (32 FMAs, 64 flops, over the 4 bytes read, intensity 16.0 flop/B; the reduction adds are not counted), and poly_intrin, the same polynomial with the Horner step written as vfmaq_f32 instead of two instructions of inline asm, because clang emits different code for the two (see Generated code). No write-allocate read is counted in the bytes: the fill row shows this part does not fetch a line it is about to overwrite whole, since counting one would put the fill above the read and write streams together. Each kernel also runs over an L1-resident slice per thread, 16384 bytes of x and of y (65536 bytes of x alone for fma_stream, one block, since a shorter block drains its twenty chains too often), repeated 1024 times per pass (256 for fma_stream), a sixteenth of the one-thread DRAM pass and about two thirds of a ten-thread one, so a pass lasts long enough to time; that rate is what the core alone allows the instruction mix. The roofline prediction for each kernel is min(FMA peak, intensity x memory roof) at the same thread count, with the memory roof whose stream mix matches the loop (the triad for saxpy, the copy for the stencil, the read roof for the three that only read), and the table shows measured over predicted, measured from DRAM over measured from L1, and the DRAM traffic the measured rate implies. Every kernel is NEON intrinsics so the flop count is exact. Each measurement is now_ns() around one pass, then REPS (default 21) timed passes after the warm-up; the statistic is the median (throughput-like) with cv, minimum and maximum shown for the roofs. A spin barrier starts and ends every pass on all threads; the master thread is worker 0. Every result is consumed with SINK() and compared with a double-precision reference computed from the value formulas and the coefficients rather than from the arrays: the data are multiples of 1/8, so the sum, copy, triad, fill, saxpy, stencil and fma_stream checksums match exactly (the FMA loop's accumulators start at multiples of 1/32 and its scale is 1/4, so over one block every partial sum is exact in float32) and the polynomials to 1e-4; a mismatch fails the run.

build.sh writes bench_O2.s from the same flags as the binary. The FMA loop is and, lsl, one ldr q and twenty fmla per iteration, one per chain, on distinct registers, and it is one function: the roof calls it with the mask 1023 over the L1 buffer and fma_stream calls it with the mask open (x1 = -1) and 4096 iterations per 65536-byte block of x; the sum is ldp q pairs feeding sixteen fadd chains; the copy is two ldp and two stp per sixteen elements with the asm barrier that stops clang calling memcpy; the triad and saxpy are ldp pairs, fmla, stp; the fill is two stp q per sixteen elements; the stencil is seven loads, one fmul and six fmla by element, one store; the asm-step Horner loop is ld1r for the pair of coefficients, then per chain the asm's mov and fmla twice, 24 mov.16b and 24 fmla per iteration with no spill or reload; the intrinsic-step loop is 22 mov.16b, 24 fmla and eleven reloads of the twelve x vectors from the stack per iteration, because with vfmaq_f32 clang keeps the copies of the coefficient and spills x instead.

_k_fma:
LBB2_2:
	and	x9, x8, x1                     ; x1 = 1023 for the roof, -1 for fma_stream
	lsl	x9, x9, #2
	ldr	q29, [x0, x9]
	fmla.4s	v18, v22, v29
	fmla.4s	v0, v22, v29
	...                                ; twenty chains on distinct registers
	fmla.4s	v28, v22, v29
	subs	x2, x2, #1
	b.ne	LBB2_2

_run_slice (fma_stream, inlined):
LBB4_30:
	mov	x0, x21                        ; x + block
	mov	x1, #-1                        ; mask open
	mov	w2, #4096                      ; iterations per 65536-byte block
	bl	_k_fma
	fadd	d9, d9, d0
	add	x21, x21, #16, lsl #12         ; next block
	...
	b.ls	LBB4_30

_k_sum:
LBB7_2:
	ldp	q24, q25, [x9, #-128]
	fadd.4s	v23, v23, v24
	fadd.4s	v22, v22, v25
	...                                ; eight ldp, sixteen fadd chains
	b.ls	LBB7_2

_k_copy:
LBB8_2:
	ldp	q0, q1, [x10, #-32]
	stp	q0, q1, [x9, #-32]
	ldp	q0, q1, [x10], #64
	stp	q0, q1, [x9], #64
	; InlineAsm Start
	; InlineAsm End
	...
	b.ls	LBB8_2

_k_triad:
LBB9_2:
	ldp	q1, q2, [x11, #-32]            ; x
	ldp	q3, q4, [x10, #-32]            ; y
	fmla.4s	v1, v0, v3
	fmla.4s	v2, v0, v4
	stp	q1, q2, [x9, #-32]             ; z
	...
	b.ls	LBB9_2

_k_fill:
LBB10_2:
	stp	q0, q0, [x9, #-32]
	stp	q0, q0, [x9], #64
	...
	b.ls	LBB10_2

_k_saxpy:
LBB11_2:
	ldp	q1, q2, [x10, #-32]            ; y
	ldp	q3, q4, [x9, #-32]             ; x
	fmla.4s	v1, v0, v3
	fmla.4s	v2, v0, v4
	stp	q1, q2, [x10, #-32]            ; y
	...
	b.ls	LBB11_2

_k_stencil:
LBB12_2:
	ldur	q6, [x10, #-12]
	fmul.4s	v6, v6, v0[0]
	ldur	q7, [x10, #-8]
	fmla.4s	v6, v7, v1[0]
	...                                ; five more load and fmla pairs
	str	q6, [x9], #16
	...
	b.ls	LBB12_2

_k_poly:
LBB13_3:
	ld1r.4s	{ v10 }, [x14]                 ; coefficient j
	sub	x16, x14, #4
	ld1r.4s	{ v11 }, [x16]                 ; coefficient j - 1
	mov.16b	v12, v10                       ; chain 0, step j: copy c, then p = c + p * x
	fmla.4s	v12, v9, v2
	mov.16b	v9, v11                        ; chain 0, step j - 1, back into v9
	fmla.4s	v9, v12, v2
	...                                ; twelve chains, 24 mov and 24 fmla per iteration
	b.hi	LBB13_3

_k_poly_intrin:
LBB14_3:
	ld1r.4s	{ v10 }, [x14]
	sub	x16, x14, #4
	mov.16b	v11, v10
	ldp	q0, q1, [sp, #192]              ; 32-byte Folded Reload: x vectors
	fmla.4s	v11, v1, v9
	ld1r.4s	{ v9 }, [x16]
	mov.16b	v12, v10
	fmla.4s	v12, v0, v8
	...                                ; 22 mov, 24 fmla, six ldp and five ldr reloads per iteration
	b.hi	LBB14_3

The copy per step is what AArch64 imposes on Horner: fmla adds into its destination, and the coefficient is shared by every chain, so c + p * x needs a fresh copy of c before the fmla. The asm step makes that one mov and one fmla and leaves the register allocation to clang, which keeps all twelve x and twelve p vectors in registers; given the intrinsic instead, clang 17 at -O2 keeps the same number of copies but spills the x vectors and reloads them every step, and the poly_intrin rows measure what that costs.

The call site in measure shows the work cannot be deleted: run_slice is called between the two clock_gettime calls with the barrier on either side, the per-thread results are summed, and the sum goes through the SINK() asm before the checksum comparison.

	bl	_clock_gettime
	...
	ldaddal	w22, w10, [x23]                ; barrier
	...
	bl	_run_slice
	...
	ldaddal	w22, w10, [x23]                ; barrier
	...
	bl	_clock_gettime
	...
LBB1_64:
	ldr	d0, [x11], #128                ; g_w[t].out
	fadd	d9, d9, d0
	subs	x10, x10, #1
	b.ne	LBB1_64
LBB1_65:
	str	d9, [sp, #152]
	add	x10, sp, #152
	; InlineAsm Start
	; InlineAsm End

The read-only kernels are pure functions of global memory and loop-invariant bounds, so run_slice puts a compiler barrier (CLOBBER()) in its pass loop; without it clang is entitled to hoist one call out of the loop, and did so in an experiment where the array pointer never escaped. results/raw.txt prints every checksum next to its reference with the relative error and ends with checksums: every kernel matched its reference; the ten-thread FMA checksums are exactly ten times the one-thread ones, which is the check that every thread did the whole work.

On ten threads the kernels land where their intensity puts them: saxpy at 0.167 flop/B runs at 39.1 GFLOP/s against 37.9 predicted from the triad roof (1.03) and moves 234.8 GB/s, while from L1 the same loop runs at 368.3 GFLOP/s, so from DRAM it delivers 0.11 of what the cores allow and nothing but memory binds it; the stencil at 1.625 flop/B is under the ten-thread ridge point of 5.16 flop/B against the copy roof and does the same, 381.8 GFLOP/s against 387.5 predicted (0.99), 235.0 GB/s of traffic, 0.50 of its 762.5 from L1. fma_stream, the roof's own loop with its load walking x at 10.0 flop/B, is to the right of the ridge and reaches the compute roof: 138.4 GFLOP/s from DRAM on one thread, 0.96 of the 143.7 GFLOP/s FMA peak and 0.98 of its own 140.7 from L1, moving 13.8 GB/s; on ten threads it reaches 1134.5, 0.92 of the 1231.1 peak, where the same loop from L1 reaches 0.98, so at 113.5 GB/s, under half the read roof, the DRAM stream still costs it six percent that a roofline, which has no latency term, does not see. The polynomial at 16.0 flop/B is bound by the compute roof but does not reach it: 104.7 GFLOP/s from DRAM and 103.9 from L1 on one thread (1.01), 918.5 and 920.2 on ten (1.00), 0.73 and 0.75 of the peak, and what sits under the roof is its instruction mix, the register copy each Horner step needs before an fmla that adds into its destination, and twelve chains in flight where the roof needs twenty (sixteen reach 0.90 of the peak in the roof table); written with the intrinsic instead of the two-instruction asm step it runs at 0.76 of the asm form on one thread and on ten (79.6 and 700.7 GFLOP/s), the price of the spills and reloads in the Generated code section. On one thread the ridge point moves to 1.55 flop/B against the read roof (1.17 against the copy roof), because one core gets 92.7 GB/s of the 246.3 GB/s that ten get (2.66 times) while its FMA peak scales 8.57 times, so the stencil crosses to the compute side: the model names the compute roof, and the loop delivers 80.5 GFLOP/s, 0.56 of the peak and 0.89 of the 90.4 it manages from L1, which is itself only 0.63 of the peak, a ceiling set by its seven loads per four elements rather than by either roof. One-thread saxpy is the lesson about the memory roof: the model names the right roof, since its 24.3 GFLOP/s is 0.56 of its L1 rate and far below the compute roof, but the loop sits at 1.17 of the prediction from the triad roof, because the one-core memory roof is not one number: the read stream stops at 92.7 GB/s, the write stream at 141.0, the copy at 123.3 and the triad at 125.1, and saxpy's 145.8 GB/s is a read stream at 1.05 of the read roof with an in-place write riding beside it, which the out-of-place triad, whose stores go to lines the core has not just loaded, does not match; on ten threads, where the memory controller rather than the core is the limit and the roofs converge (the copy at 0.97 and the triad at 0.92 of the read roof), the same loop lands at 1.03. The fill row settles the byte count for the storing loops: on ten threads the fill moves 253.3 GB/s, 1.03 times the read roof, and a write-allocate read would double that to a figure no row in the table approaches, so a stored line costs 4 bytes of traffic here, not 8. The 4.00 fmla per cycle per core at the 4.49 GHz clock estimate on one thread is the four NEON pipes, all busy; the ten-thread figure of 3.43 at the same clock estimate means the all-core clock is lower under DVFS, not that pipes idle, which is also why the ten-thread FMA peak is 8.57 times the one-thread peak rather than ten.

There is no PMU access from user space on macOS, so the bytes moved are counted from the loops rather than read from a memory controller counter, and the absence of a write-allocate read is inferred from the fill row rather than observed. Apple publishes neither the FMA latency nor the memory bandwidth of this part, so the roofs are what the code reaches, which is what the CS Roofline Toolkit also does. DVFS is on, the one-thread clock estimate is taken before the run and the all-core clock is not measured, so the FMA-per-cycle rows are indicative. This run was taken with other processes of the user's running (the load average in the Machine section), which is why the cv column is shown. Inside the run the two measurements of every roof agree within 2 percent (the roof table's last column) except the ten-thread fill, whose second measurement (199.4 GB/s against 253.3; results/raw.txt shows all 21 of its passes near the lower figure, so the whole case ran slow rather than one pass) is a thread that did not have a P-core for the whole case; the 18.6 percent cv of the ten-thread polynomial from L1 and the 7.1 percent cv of poly_intrin from DRAM are single passes cut the same way, which the median discards. The earlier full run with this code (the previous results/raw.txt in the repository history) put the one-thread roofs a few percent lower and the ten-thread FMA roofs where they are now, and since the two measurements inside a run agree, that between-run movement of the one-thread roof is the clock under DVFS and the other load, not measurement noise. The one-core memory roof is not one number here: the read stream, the write stream, the copy, the triad and saxpy each stop at a different rate, which is consistent with reads being limited by the core's outstanding misses while writes are posted, so on one thread a kernel that writes in place can sit above a prediction made from any roof whose stores go elsewhere, and the three memory roofs are there to make that visible rather than to hide it. fma_stream on ten threads is 0.92 of the peak from DRAM against 0.98 from L1 with a longer block making no difference, which is memory latency under ten concurrent streams that the prefetcher does not fully hide, and which a bandwidth roof cannot express. There is no NUMA and no SMT to add ceilings. On an x86 server part the picture changes in constants and in one mechanism: a single core's DRAM bandwidth is a much smaller fraction of the socket's, so the one-thread ridge point is far to the left and the stencil would be memory bound on one core as well; AVX2 or AVX-512 raises the FMA roof per core; vfmadd213ps can put the polynomial's running value in the destination, so Horner needs no register copy there and the polynomial can sit closer to its FMA roof; and a write-allocate read is normally paid unless non-temporal stores are used, which raises the stencil's bytes per element from 8 to 12 and saxpy's from 12 to 16.

./run.sh # full run, about 15 seconds QUICK=1 ./run.sh # smoke test, about 8 seconds; writes results/quick-raw.txt and # results/quick-summary.md and leaves README.md alone REPS=51 ./run.sh # more timed passes per case THREADS=4 ./run.sh # a different all-cores thread count WARMUP_MS=500 ./run.sh # longer warm-up per case

run.sh builds with build.sh, writes the machine description and clock estimate to the top of results/raw.txt, appends the benchmark output, builds results/summary.md from the RESULT lines with awk, and pastes it into this README between the results markers. build.sh also regenerates bench_O2.s, which is where the quoted assembly comes from.