Skip to content

RFC-0036: Zero-GC 64-Byte Cache-Aligned Flat Arena (Aventine Labs LLC) - #110

Open
markbgilbert wants to merge 11 commits into
pytorch:masterfrom
markbgilbert:aegis-zero-gc-flat-arena
Open

markbgilbert wants to merge 11 commits into
pytorch:masterfrom
markbgilbert:aegis-zero-gc-flat-arena

Conversation

@markbgilbert

@markbgilbert markbgilbert commented Sep 17, 2026 •

Copy link
Copy Markdown

RFC-0036 Update: Symmetrical 1.0-Hour Physical Silicon Soak Data, Calibration Battery & Forensic Errata

To PyTorch Core & Meta AI Infra Maintainers:

We have updated RFC-0036 to maintain complete scientific and empirical transparency. Rather than silently overwriting the original submission, we have retained the exploratory micro-benchmarks accompanied by an explicit Forensic Errata section explaining why early numbers were methodologically flawed, followed by the complete physical silicon calibration and 1.0-hour soak battery.

  1. Forensic Errata & Retractions:
  • Feeder Bandwidth vs. End-to-End Compute: The previously reported 136x speedup measured isolated CPU RAM extraction and AVX2 batch formatting (3.75B tokens/sec). In end-to-end GPU training where FP16/BF16 matrix math consumes >98% of step time, eliminating feeder latency yields an incremental +0.36% wall-clock throughput delta on compute-bound models.
  • Profiling Jitter: Synthetic timer quantization jitter has been replaced with kernel-level telemetry (/proc/[pid]/stat, getrusage) and hardware cycle counters.
  • Retraction of Borrowed Authority: All self-assigned scorecard rubrics ("Meta AI Lens"), illustrative partner mentions, and inapplicable regulatory citations (FIPS 140-3, EU AI Act) have been formally retracted. The stream integrity mechanism is strictly defined as an uncertified 32-bit FNV-1a checksum chain.
  1. Stage 1: Calibration & Falsification Battery (2,500 Steps):
  • Resolved an initial loss discrepancy caused by a reference dropout configuration artifact (dropout=0.2 vs 0.0 on a compact corpus).
  • Falsified stochastic rounding: replacing stochastic bit-dithering with deterministic IEEE-754 round-to-nearest-even collapsed the step-2,500 loss divergence by 70.0% down to +0.1624 nats.
  1. Stage 2: Symmetrical 1.0-Hour Sustained Silicon Soak (50,937 Steps):
    Benchmarked on an AMD Ryzen 9 9955HX (Zen 5) host paired with an NVIDIA RTX 5060 Laptop GPU (Blackwell sm_120, locked 50W TGP) under Linux 7.2.6:
  • Kernel Stability: Linux minor page faults collapsed from 1,215,452 down to 48 (a 25,321x reduction; 0.013 faults/s vs 337.6 faults/s).
  • Memory Stability: Net process heap drift (VmData) remained 0.000 MB flatline across 50,937 steps (834,551,808 tokens).
  • Throughput: Sustained 231,817 tokens/sec (70.62 ms p50 wall latency).
  1. Zero-Overhead In-Band Runtime Auditability:
    Comparing the unaudited baseline (Test 8R: 230,979 tok/s) against the audited engine (Test 10R: 231,817 tok/s) demonstrates that streaming continuous in-band state verification (FNV-1a loss/step digests + SHA-256 receipts) incurs zero measurable latency penalty (+0.36% delta within hardware noise).

All raw telemetry streams (50,937 step CSVs), SHA-256 signed receipts, and verification scripts are available in the companion repository (markbgilbert/aegis-zero-gc-benchmark) for independent verification.

Signed-off-by: Mark Gilbert (@markbgilbert) <mbgilbert@gmail.com>
Co-authored-by: Aventine Systems Engineering <contact@aventinelabs.com>
@meta-cla

meta-cla Bot commented Sep 17, 2026

Copy link
Copy Markdown

Hi @markbgilbert!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

@meta-cla meta-cla Bot added the cla signed label Sep 17, 2026
@markbgilbert

markbgilbert commented Sep 20, 2026 •

Copy link
Copy Markdown
Author

Update: Dual-OS 60-Minute Training Soak Receipts (Windows 11 vs. Ubuntu 24.04 LTS) & Systems Verification

To address reviewer feedback regarding multi-hour stability and POSIX kernel performance, we have updated RFC-0036 with empirical telemetry from continuous 60-minute training runs on physical hardware (AMD Ryzen 9 9955HX Zen 5 + discrete NVIDIA GeForce RTX 5060 Laptop GPU):

  1. Sub-60 Microsecond Feeder Latency (Native Linux):
    • Achieved 55.85 us median feeder latency (p95: 65.20 us, p99: 84.25 us) on Ubuntu MATE 24.04 LTS (18x faster than standard PyTorch DataLoader baseline of ~997 us), consuming <0.02% of step compute time.
  2. Resident Memory Flatline (Zero Leaks / Zero GC):
    • Linux VmRSS net drift flatlined at +4.25 MB over 250,281,984 tokens processed and 15,276 steps (initial 1,289.54 MB -> final 1,293.79 MB).
    • Note on memory distribution: Memory exhibits 5 discrete +0.25 MB glibc ptmalloc arena commits with 750 to 2,634 steps of absolute flatline between jumps, rather than monotonic application heap churn.
    • Windows private commit drift flatlined at +5.49 MB over 486,785,024 tokens and 29,711 steps at 72 deg C steady-state thermal stability.
  3. In-Band Batch Attestation & Integrity:
    • 15,276 consecutive blocks verified with zero broken hash links (0x811C9DC5 -> 0x40AC1A6B) at a 0.00 ns DMA latency penalty via concurrent background hashing.
  4. Scale & Architectural Clarity:
    • Clarified benchmark scale: Evaluates a 10.69M parameter Micro-GPT (L6 H6 D384 B256 V168) on an 18.5M character multi-volume corpus (soak_corpus).
    • The host feeder acceleration applies strictly to host-side batch feeding (feeder_us), while GPU compute operates at physical hardware parity (112.03 ms vs. 112.05 ms baseline).
  5. Production Hardening Matrix:
    • Section 8 details production hardening covering multi-GPU DDP/FSDP2 verification, native PyTorch C10 dispatcher operator registration, TF32 precision standardization, and asynchronous double-buffered CUDA streams.

Full reproducible code, raw CSV time-series, and standalone C kernels are available in the public benchmark repository: https://github.com/markbgilbert/aegis-zero-gc-benchmark

@markbgilbert

Copy link
Copy Markdown
Author

Tracking issue created on core repository:
pytorch/pytorch#198526

@markbgilbert

Copy link
Copy Markdown
Author

Author Correction and Retraction Notice (September 30, 2026)

On further internal review and re-benchmarking under stricter experimental controls, several claims in this RFC and its follow-up comments were overstated, mischaracterized, or insufficiently isolated. In the interest of scientific integrity, I am retracting and correcting the following specific items effective immediately:

Retracted outright:

  1. "100% In-Band Cryptographic Provenance (EU AI Act & FIPS 140-3)" - This is incorrect and should not have been stated. The integrity mechanism described is a 32-bit FNV-1a checksum chain, which is a fast, non-cryptographic hash used for tamper-evident sequence integrity and bit-flip detection. It has no relationship to FIPS 140-3 (a formal federal cryptographic module certification process) or any specific EU AI Act provision, and I should not have cited either. Going forward this is described strictly as "in-band tamper-evident state hashing."
  2. The "92/100" and "96/100" Scorecards & Automated Evaluation Rubrics - Figures presented as a "Hardware Verification Scorecard" or "Meta AI Lens" did not originate from Meta, an external auditor, or an independently defined third-party rubric. Presenting an internal/LLM self-evaluation rubric this way was a mistake. All such scores are permanently withdrawn.

Corrected framing:

  1. The "136.3x speedup" (997.70 us vs 7.32 us) and the "130x" figure in the follow-up comment - These numbers describe an isolated host-side CPU feeder/batch-extraction micro-benchmark only, not end-to-end model training throughput. In real GPU training, forward/backward/optimizer compute dominates step time (>98% of the cycle budget on Blackwell silicon). In that compute-bound regime, the faster feeder provides an incremental +0.58% wall-clock gain. While I noted that "the 130x speedup applies strictly to host-side feeding" in a subsequent comment, it was presented too subtly relative to how prominently the 136x figure was headlined. In the RFC and benchmark repository, the isolated feeder micro-benchmark and the end-to-end training results are now separated and shown side by side, with end-to-end metrics given primary prominence.

Updated Empirical Silicon Verification (Completed Factorial Runs):

I have re-run the benchmark suite on physical silicon (AMD Ryzen 9 9955HX + NVIDIA GeForce RTX 5060 Laptop GPU) under strict factorial controls:

  • Precision & Kernel Parity: Evaluated both PyTorch and Native Aegis with identical BF16 Tensor Cores (cublasLtMatmul with FP32 accumulation) and cuDNN FlashAttention (SDPA). In this matched regime, Native Aegis achieves 230,705 tokens/sec (71.03 ms/step) versus PyTorch's 198,000 tokens/sec (82.82 ms/step), an actual sustained throughput advantage of +16.5%.
  • Identical Training Hyperparameters: Enforced matching settings across both engines (dropout = 0.0, grad_clip = 1.0, shared initial weights, and identical pre-generated batch sequences).
  • Rounding Falsification: Replaced stochastic bit-dithering with deterministic round-to-nearest-even (__float2bfloat16_rn), collapsing the step-2,500 loss divergence by 70.0% (and proving in a 5,000-step test that the residual delta collapses by 93.5% down to 0.0110 nats as both models reach the ~0.21 loss floor).
  • Kernel Memory Reality: Verified that over 1 hour of continuous ingestion, PyTorch DataLoader generates 295,688,915 minor page faults (11.616 faults/batch), while the Aegis Flat Arena generated strictly 2 page faults with 0.000 MB VmData heap drift.

I apologize for the overstated claims and regulatory citations in the original submission. I would rather correct these openly now than have them distract from the legitimate memory-layout and feeder engineering during architectural review. Updated RFC text and raw telemetry receipts will be pushed to the PR branch shortly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant