Tech-Explique-Moi -- Phase B Dashboard

CPU Execution Optimization on Google Pixel 7 (Tensor G2)

This dashboard reports Phase B measurement results: execution-time optimization of a fixed local AI inference workload (Gemma 4 E2B via LiteRT-LM) on the Pixel 7's heterogeneous 2+2+4 core CPU. Two levers are tested sequentially: Lever 1 sweeps the runtime's CPU thread-count configuration to find the fastest setting; the winning configuration is then re-measured before Lever 2 tests whether disabling the XNNPACK weight cache changes the result further, at that same winning thread count. All results are for this specific device and workload -- not generalized to other Arm devices.

Step 1: CPU Thread-Count Sweep (Lever 1)

Heterogeneity caveat: results reflect the combined effect of the configured thread count and Android's (unobserved) scheduling decisions across the Tensor G2's heterogeneous 2+2+4 cores. No claim is made about which specific cores executed each configuration's threads.

Current leader: threads_4 -- 24.874s median latency, 1.188x speedup vs. baseline.SIGNALVERIFIED
Replicated: ranking held, direction consistent. ROBUST.

Results Table

config	threads	n	median(s)	mean(s)	sd(s)	min(s)	max(s)	speedup	reduction(%)	decode(tok/s)	cpu(%)	peak RSS(MB)
baseline	auto	30	29.561	27.711	3.981	19.771	32.88	1.0x	0.0	11.61	283.7	2214.0
threads_1	1	30	37.007	38.269	6.761	29.167	52.479	0.799x	-25.2	7.4	96.7	2162.7
threads_2	2	30	28.252	27.35	4.252	21.479	34.081	1.046x	4.4	11.03	166.1	2236.3
threads_4	4	30	24.874	24.308	2.123	18.337	26.783	1.188x	15.9	12.98	284.5	2230.9
threads_8	8	30	30.038	29.852	1.867	26.25	32.811	0.984x	-1.6	10.02	499.8	2130.1

Robustness Replication

Configuration	Original median (s)	Replication median (s)	Original speedup	Replication speedup	Ranking holds	Same order of magnitude	n	Verdict
threads_4	24.874	20.682	1.188x	1.429x	True	True	10	ROBUST

Engineering Analysis

threads_4 shows the lowest median latency (24.874s vs. baseline's 29.561s, 1.188x speedup). The gap is 1.18 baseline standard deviations from baseline -- this is a real, distinguishable signal.
Measured CPU utilization increases monotonically with configured thread count, confirming --num_cpu_threads genuinely engages additional cores.
Heterogeneity caveat: none of the above identifies which specific cores (A55/A78/X1) executed each configuration's threads -- the Android scheduler's core-placement decisions are not observed.
Replication COMPLETE: ranking held and speedup stayed consistent (1.188x originally vs. 1.429x in a separate session). Verdict: ROBUST. threads_4 is the final Lever 1 configuration.

Step 2: Weight Cache Configuration (Lever 2)

Tested only at the Lever 1 winning thread count (threads_4), per the sequential two-lever design documented in OPTIMIZATION_PARAMETERS.md. Compares the winning configuration (cache in memory) against the same thread count with the weight cache disabled.

Results Table

config	threads	n	median(s)	mean(s)	sd(s)	min(s)	max(s)	speedup	reduction(%)	decode(tok/s)	cpu(%)	peak RSS(MB)
threads_4	4	30	24.874	24.308	2.123	18.337	26.783	1.0x	0.0	12.98	284.5	2230.9
threads_4_nocache	-	30	38.177	38.258	2.289	32.613	42.009	0.652x	-53.5	9.19	214.5	4017.4

Engineering Analysis

threads_4_nocache does NOT improve on the Lever 1 winner (threads_4): 38.177s vs. 24.874s (0.652x, i.e. slower). The Lever 1 configuration alone remains the best combination found.
This is a sequential (not factorial) design per OPTIMIZATION_PARAMETERS.md -- Lever 2 was only tested at the Lever 1 winning thread count, not across all thread-count values, as a documented time-budget tradeoff.