Part of #500. Depends on #506, #508, #510, and #512. Run after a candidate passes canonical x64 confirmation.
Question
Do confirmed x64 mechanisms retain their direction on ARM64 without unacceptable tail-latency, energy-per-delivery, or thermal-sustainability regressions?
Mechanism
IL2CPP toolchains, ARM64 code generation, cache hierarchy, big.LITTLE scheduling, worker topology, DVFS, thermal limits, and device state can reverse an x64 result. Short floods can reward an implementation that throttles in a real session.
Contract
Keep Windows x64 IL2CPP as the canonical confirmation platform and label ARM64 results by device and toolchain. Never average architectures or devices.
Separate uninstrumented verdict sessions from profiler attribution. Declare device, SoC, ABI, OS/firmware, Unity/toolchain, workers, core/cluster behavior, battery/charging state, thermal entry/exit, cooling rule, and performance mode. Run fixed-performance and normal/sustained mobile lanes separately.
Measure fixed completed work. Prefer a synchronized external power meter. Report gross and active-minus-idle energy with instrument uncertainty; on-device power estimates are diagnostic.
Factors and workloads
- Canonical Windows x64 plus available macOS, Android, and iOS ARM64 players.
- Oldest-supported Unity and current pinned Unity line.
- Normal/adaptive, fixed-performance, and sustained modes where supported.
- Cold start, GlobalToOne, StructNoBox, middleware, SubUnsub, frame bursts, and promoted queued/Burst tiers.
- Short warm and sustained thermal runs.
- Candidate/control order, device session, day, battery band, worker count, and thermal block.
- Throughput, p99, joules per delivered callback, temperature/state, frequency/core residency, and time to throttling.
Primary response
The preregistered platform interaction contrast:
log(candidate/control on ARM64) - log(candidate/control on canonical x64).
Independent unit
One complete device session beginning inside the battery and thermal entry band. Frames and windows inside it are nested.
Effect threshold
An absolute interaction beyond 3 percentage points is material and requires platform qualification. An ARM64 win requires its target to pass the calibrated threshold while energy per delivered callback and p99 pass preregistered noninferiority/equivalence bounds. Alternative architectures retain the 20% promotion threshold.
RED proof
- Add fixed CPU work and prove energy per operation and sustained thermal behavior worsen.
- Run identical binaries and prove the protocol does not invent an interaction.
- Violate battery/charging/thermal entry rules and prove the whole session is rejected while raw data remains.
- Change workers or performance mode and prove provenance distinguishes the run.
GREEN suites
Pass ARM64 shipping-player correctness, differential replay, lifecycle/reentrancy, AOT-root/stripping, separate supported allocation attribution, thermal-state validation, energy-tool controls, and repeated uninstrumented sessions.
Stop rule
Do not make energy claims when completed work, device state, or instrument resolution is unknown. Do not make sustained claims when thermal criteria fail. Do not substitute Editor or simulator data. If an accepted mechanism cannot pass oldest-Unity and ARM64 non-regression, keep it architecture/toolchain-conditional.
Immutable evidence
Retain player/APK/IPA hashes, device/SoC/OS/firmware, Unity/native toolchains, profile/candidate hashes, session order, battery/charging/thermal logs, workers/cores, raw timing and power traces, attribution hashes, analysis, interaction interval, and qualified decision.
Dependencies
This task consumes #506, #508, #510, and #512. It gates cross-platform default promotion, not early x64 screening.
Completion checklist
Part of #500. Depends on #506, #508, #510, and #512. Run after a candidate passes canonical x64 confirmation.
Question
Do confirmed x64 mechanisms retain their direction on ARM64 without unacceptable tail-latency, energy-per-delivery, or thermal-sustainability regressions?
Mechanism
IL2CPP toolchains, ARM64 code generation, cache hierarchy, big.LITTLE scheduling, worker topology, DVFS, thermal limits, and device state can reverse an x64 result. Short floods can reward an implementation that throttles in a real session.
Contract
Keep Windows x64 IL2CPP as the canonical confirmation platform and label ARM64 results by device and toolchain. Never average architectures or devices.
Separate uninstrumented verdict sessions from profiler attribution. Declare device, SoC, ABI, OS/firmware, Unity/toolchain, workers, core/cluster behavior, battery/charging state, thermal entry/exit, cooling rule, and performance mode. Run fixed-performance and normal/sustained mobile lanes separately.
Measure fixed completed work. Prefer a synchronized external power meter. Report gross and active-minus-idle energy with instrument uncertainty; on-device power estimates are diagnostic.
Factors and workloads
Primary response
The preregistered platform interaction contrast:
log(candidate/control on ARM64) - log(candidate/control on canonical x64).Independent unit
One complete device session beginning inside the battery and thermal entry band. Frames and windows inside it are nested.
Effect threshold
An absolute interaction beyond 3 percentage points is material and requires platform qualification. An ARM64 win requires its target to pass the calibrated threshold while energy per delivered callback and p99 pass preregistered noninferiority/equivalence bounds. Alternative architectures retain the 20% promotion threshold.
RED proof
GREEN suites
Pass ARM64 shipping-player correctness, differential replay, lifecycle/reentrancy, AOT-root/stripping, separate supported allocation attribution, thermal-state validation, energy-tool controls, and repeated uninstrumented sessions.
Stop rule
Do not make energy claims when completed work, device state, or instrument resolution is unknown. Do not make sustained claims when thermal criteria fail. Do not substitute Editor or simulator data. If an accepted mechanism cannot pass oldest-Unity and ARM64 non-regression, keep it architecture/toolchain-conditional.
Immutable evidence
Retain player/APK/IPA hashes, device/SoC/OS/firmware, Unity/native toolchains, profile/candidate hashes, session order, battery/charging/thermal logs, workers/cores, raw timing and power traces, attribution hashes, analysis, interaction interval, and qualified decision.
Dependencies
This task consumes #506, #508, #510, and #512. It gates cross-platform default promotion, not early x64 screening.
Completion checklist