HPC Native Roadmap

This roadmap turns the current HPC-friendly posture into a staged path toward an HPC-native claim. The repository should not treat HPC-native as a current status—it is an evidence-backed endpoint requiring progressive accelerator work and benchmark proof.

Roadmap sequence

1. Integrated GPU optimization on Apple Silicon — Metal-backed acceleration, CPU fallback contract stability, representative workloads and repeatable benchmark gains
2. Discrete GPU acceleration — expand after Metal path is measured and contract-safe; use shared abstraction contract
3. TPU implementation — reuse JAX-oriented path; require proof that device transfer overhead is worthwhile
4. FPGA implementation — define toolchain and kernel shape before implementation widens
5. ASIC / custom-circuit implementation — last-stage execution lane; require strong workload regularity evidence

Current evidence status

Benchmark status

Benchmark status is evidence-gated: CPU baselines are committed, while device-backed speedup remains pending until reviewed production packets exist. The current Apple Metal track has established the committed CPU baselines; device-backed comparison remains separately gated.

• Discrete GPU: implementation lane defined
• TPU: implementation lane through JAX-oriented backend, comparison evidence pending
• FPGA: implementation lane with adapter placeholders, real runtime pending
• ASIC/custom-circuit: deployment assumptions defined, comparison evidence pending

Production speedup evidence gate

Every evidence packet carries a scalar_cpu_baseline and a memory_throughput_baseline, together with workload hash, timing, throughput, device metadata, parity, and fallback results. These baselines are the reference for every accelerator lane.

The Conductor track hpc-production-speedup-evidence-program_20260625 now defines a machine-readable production benchmark packet with workload hash, production-scale classification, warm-up iterations, timing, throughput, device metadata, CPU fallback, CPU comparison, owner, review status, and an explicit blocked reason. The deterministic handoff includes a CPU reference plus GPU, TPU, Metal, FPGA, and ASIC states. Visibility, setup, parity, and benchmark packets do not prove production speedup; an accelerator packet cannot be promoted until a reviewed production workload beats the CPU comparison. HPC-native remains blocked.

CPU cluster evidence

The CPU cluster track records a single-process reference, a local process-scheduler smoke check, and an explicit multi-node blocked packet. Each packet carries the worker and node counts, scheduler, workload hash, warm-up, timing, throughput, CPU baseline, result-envelope preservation, and diagnostics preservation. Local parallel execution demonstrates contract behavior; it is not a claim of multi-node production speedup without an authenticated cluster or cloud runner.

Apple Metal evidence

Apple deployment requirements

Apple deployment requirements include macOS Apple Silicon hosts for build and validation, Metal-capable system libraries at runtime, and CPU fallback coverage preserved in CI. The exact deployment requirement is macOS Apple Silicon hosts for build and validation. The release gate requires CPU fallback coverage preserved in CI.

The Apple Metal track validates CPU reference and Metal/MPS packets for workload hash, warm-up, timing, throughput, CPU baseline, result parity, and fallback. When Apple Silicon is unavailable, the handoff records a blocked status. CPU fallback remains authoritative; setup or MPS visibility alone is not an Apple production-speedup claim.

Discrete GPU evidence

The discrete GPU track requires CUDA device metadata, workload hashes, warm-up iterations, repeated timing, throughput, CPU comparison, transfer overhead, compile overhead, result parity, and CPU fallback. Colab or cloud quota/runtime unavailability is recorded as blocked; a T4 visibility/parity packet is not a production-sized speedup claim.

TPU production-scale evidence

The TPU follow-through track requires production-scale workload hashes, warm-up and repeated timings, throughput, CPU comparison, compile and transfer overhead, EVPI result parity, and CPU fallback. The current handoff contains a deterministic CPU reference and an explicit TPU blocked packet: compact Colab v5e visibility or parity does not prove speedup. A production TPU claim remains gated on an authenticated Colab TPU runtime or gcloud project with quota, billing, and TPU allocation.

Contract rules

• CPU behavior stays the reference path until an accelerator proves itself
• The public result envelope must not change just because a new backend is introduced
• Benchmark evidence, reproducibility, and deployment realism come before any HPC-native claim
• Apple integrated GPUs are the first accelerator target for lower-risk validation of backend plumbing

Registry-readiness tracks

The HPC registry path is coordinated separately: hpc-registry-readiness, spack-registry-readiness, easybuild-registry-readiness, hpsf-curation-readiness, and e4s-curation-readiness.