August on DGX Spark
August's LLVM compiler built and ran on a physical DGX Spark on October 2, 2026. It passed the language regression suite, safety gyms, and installed-CLI checks for all four public native libraries. These are CPU results. They do not qualify GPU execution or the rest of PyTorch's API.
Machine and measurement
The host ran Ubuntu 24.04.4 LTS, Linux 6.17.0-1021-nvidia, on a 20-core ARM64 CPU with Cortex-X925 and Cortex-A725 cores. Builds used August's Debian 12 maintainer container: glibc 2.36, Node 24.21.0, LLVM 23.1.2, and Debian Clang 14.0.6 for the independent C references. The container ran directly on the Spark's ARM64 CPU.
Timed runs were restricted to four performance cores, CPUs 5–8. Frequency and other host activity were not fixed. Each sample started a fresh executable; timings include process startup and exclude compilation. Implementation order rotated in a separate measurement process, and every output was checked. Both August and C used O2 without LTO or fast-math. Compare implementations within a row; do not treat these numbers as a comparison of Spark and the Mac results.
The raw reports say unknown for the CPU model because Node did not expose its name in the container. The hardware description above comes from the host's lscpu inventory. The reports are preserved as recorded.
Core workloads
DGX Spark execution time
Median ms · shorter is better. Each panel starts at zero and scales to the implementations shown.
StartupCode and spec ↗
- August1.33 ms
- C0.92 ms
- Node19.3 ms
- Python7.43 ms
Integer loop · 2 million stepsCode and spec ↗
- August7.77 ms
- C7.51 ms
- Node36.76 ms
- Python220.76 ms
Map + Set · 20,000 entriesCode and spec ↗
- August4.24 ms
- C3.7 ms
- Node28.03 ms
- Python12.68 ms
Map + Set · 200,000 entriesCode and spec ↗
- August63.48 ms
- C22.47 ms
- Node82.6 ms
- Python50.7 ms
JSON · 5,000 recordsCode and spec ↗
- August7.19 ms
- C1.6 ms
- Node22.65 ms
- Python22.29 ms
Exact values and sample ranges
| Program | Implementation | Median | Minimum | Maximum | Samples |
|---|---|---|---|---|---|
| Startup | August | 1.33 | 0.94 | 2.19 | 60 |
| Startup | C | 0.92 | 0.71 | 3.46 | 60 |
| Startup | Node | 19.3 | 15.72 | 25.4 | 60 |
| Startup | Python | 7.43 | 6.54 | 10.02 | 60 |
| Integer loop · 2 million steps | August | 7.77 | 7.45 | 8.19 | 60 |
| Integer loop · 2 million steps | C | 7.51 | 7.14 | 8.27 | 60 |
| Integer loop · 2 million steps | Node | 36.76 | 32.79 | 40.13 | 60 |
| Integer loop · 2 million steps | Python | 220.76 | 212.99 | 241.88 | 60 |
| Map + Set · 20,000 entries | August | 4.24 | 3.36 | 5.74 | 60 |
| Map + Set · 20,000 entries | C | 3.7 | 2.38 | 5.21 | 60 |
| Map + Set · 20,000 entries | Node | 28.03 | 21.53 | 34.93 | 60 |
| Map + Set · 20,000 entries | Python | 12.68 | 10.18 | 14.79 | 60 |
| Map + Set · 200,000 entries | August | 63.48 | 46.06 | 73.46 | 60 |
| Map + Set · 200,000 entries | C | 22.47 | 17.67 | 27.57 | 60 |
| Map + Set · 200,000 entries | Node | 82.6 | 63.91 | 96.84 | 60 |
| Map + Set · 200,000 entries | Python | 50.7 | 43.21 | 59.74 | 60 |
| JSON · 5,000 records | August | 7.19 | 6.74 | 8.54 | 60 |
| JSON · 5,000 records | C | 1.6 | 1.27 | 2.05 | 60 |
| JSON · 5,000 records | Node | 22.65 | 18.61 | 27.16 | 60 |
| JSON · 5,000 records | Python | 22.29 | 20.41 | 24.64 | 60 |
These medians use 60 samples after three warmups. The full report includes all samples, peak memory, build times, Node and Python comparisons, and the C migration backend. The performance guide explains the programs and their comparison limits.
| Program | Work per run | August LLVM | C | August / C |
|---|---|---|---|---|
| Startup | Print one integer | 1.33 ms | 0.92 ms | 1.44 |
| Integer loop | 2,000,000 steps | 7.77 ms | 7.51 ms | 1.04 |
| Map and Set | 20,000 entries | 4.24 ms | 3.70 ms | 1.15 |
| Map and Set | 200,000 entries | 63.48 ms | 22.47 ms | 2.83 |
| JSON | 5,000 records | 7.19 ms | 1.60 ms | 4.49 |
The larger collection case and JSON still have substantial overhead. The JSON C reference parses and writes data without constructing August records. The migration check compares LLVM with the same August program compiled through C. The standalone C references perform different work, as described below.
Eight application kernels
DGX Spark application kernels
Median ms · shorter is better. Each panel starts at zero and scales to the implementations shown.
Floating-point loopCode and spec ↗
- August2.15 ms
- C1.57 ms
Labeled callsCode and spec ↗
- August2.5 ms
- C1.58 ms
List traversalCode and spec ↗
- August3.62 ms
- C1.96 ms
String processingCode and spec ↗
- August8.29 ms
- C2.07 ms
Map deletion and refillCode and spec ↗
- August5.31 ms
- C4.47 ms
Checked failuresCode and spec ↗
- August1.04 ms
- C0.72 ms
Record allocationCode and spec ↗
- August22.6 ms
- C3.09 ms
Task schedulingCode and spec ↗
- August8.23 ms
- C1.3 ms
Exact values and sample ranges
| Program | Implementation | Median | Minimum | Maximum | Samples |
|---|---|---|---|---|---|
| Floating-point loop | August | 2.15 | 1.87 | 2.59 | 30 |
| Floating-point loop | C | 1.57 | 1.3 | 2.3 | 30 |
| Labeled calls | August | 2.5 | 2.21 | 3.28 | 30 |
| Labeled calls | C | 1.58 | 1.4 | 2.03 | 30 |
| List traversal | August | 3.62 | 2.64 | 4.53 | 30 |
| List traversal | C | 1.96 | 1.35 | 2.56 | 30 |
| String processing | August | 8.29 | 7.74 | 8.79 | 30 |
| String processing | C | 2.07 | 1.71 | 2.6 | 30 |
| Map deletion and refill | August | 5.31 | 4.96 | 5.92 | 30 |
| Map deletion and refill | C | 4.47 | 4.13 | 5.38 | 30 |
| Checked failures | August | 1.04 | 0.93 | 1.24 | 30 |
| Checked failures | C | 0.72 | 0.64 | 1.04 | 30 |
| Record allocation | August | 22.6 | 18.59 | 26.15 | 30 |
| Record allocation | C | 3.09 | 2.28 | 3.93 | 30 |
| Task scheduling | August | 8.23 | 6.17 | 9.18 | 30 |
| Task scheduling | C | 1.3 | 0.9 | 2.09 | 30 |
These medians use 30 samples after three warmups. Each linked project shows the complete August code beside its compiled explanation, with an indentation/braces switch. Raw samples and expected results retain the C migration comparison too.
| Program and code/spec | Work per run | August LLVM | C | August / C |
|---|---|---|---|---|
| Floating-point loop | 1,000,000 | 2.15 ms | 1.57 ms | 1.37 |
| Labeled calls | 200,000 | 2.50 ms | 1.58 ms | 1.59 |
| List traversal | 100,000 | 3.62 ms | 1.96 ms | 1.84 |
| String processing | 20,000 | 8.29 ms | 2.07 ms | 4.00 |
| Map deletion and refill | 4,000 | 5.31 ms | 4.47 ms | 1.19 |
| Checked failures | 20,000 | 1.04 ms | 0.72 ms | 1.43 |
| Record allocation | 50,000 | 22.60 ms | 3.09 ms | 7.32 |
| Task scheduling | 2,000 | 8.23 ms | 1.30 ms | 6.32 |
The C references use concrete representations and explicit cleanup. The ordered map uses linear search. The task reference calls functions sequentially; it does not implement August's scheduler or cancellation rules. August also performs managed allocation and task scheduling. Those costs are included in the measurements.
HTTP throughput
DGX Spark HTTP throughput
Median requests/s · longer is better. Each panel starts at zero and scales to the implementations shown.
1 concurrent clientsCode and spec ↗
- August18,441 requests/s
- Node17,271 requests/s
16 concurrent clientsCode and spec ↗
- August37,864 requests/s
- Node34,749 requests/s
64 concurrent clientsCode and spec ↗
- August35,395 requests/s
- Node31,815 requests/s
Exact values and sample ranges
| Program | Implementation | Median | Minimum | Maximum | Samples |
|---|---|---|---|---|---|
| 1 concurrent clients | August | 18,441 | 16,748 | 20,600 | 5 |
| 1 concurrent clients | Node | 17,271 | 16,492 | 18,410 | 5 |
| 16 concurrent clients | August | 37,864 | 37,439 | 39,762 | 5 |
| 16 concurrent clients | Node | 34,749 | 31,874 | 38,037 | 5 |
| 64 concurrent clients | August | 35,395 | 33,698 | 36,969 | 5 |
| 64 concurrent clients | Node | 31,815 | 31,214 | 34,998 | 5 |
Each median covers five fresh server runs with 5,000 validated requests per run, after warmup. The load is HTTP/1.1 loopback with keep-alive, fixed concurrency and no TLS, authentication or logging. It measures this endpoint and client together, not a server's maximum capacity. There is no standalone C HTTP implementation in this comparison.
| Concurrent clients | August LLVM | August C backend | Node |
|---|---|---|---|
| 1 | 18,441 requests/s | 16,157 requests/s | 17,271 requests/s |
| 16 | 37,864 requests/s | 38,866 requests/s | 34,749 requests/s |
| 64 | 35,395 requests/s | 36,414 requests/s | 31,815 requests/s |
Safety and real imports
All 266 LLVM parity tests passed with no skips, including source breakpoints and debugger variable inspection. The full safety gym report passed 3,612 generated and edge-case checks in development and optimized builds, rejected eight forbidden contracts, and detected all 14 valid behavioral mutations. All six additional circuits passed with no skipped tests: source mutations, ownership/concurrency, native boundaries, package integrity, HTTP boundaries and sanitizers.
The installed-CLI report records public URL imports and named aliases for CPU LibTorch v0.1.4, SQLite v0.1.3, zlib v0.1.3, and Rust BLAKE3 v0.1.3. The real libraries produced the expected tensor sum, database query, compression round trip and hash. Frozen/offline restores, relocated deployments, same-file tests, resource cleanup counters, tasks, JSON, clocks, crypto and HTTP forms passed too. This check used a locally supplied compiler archive before publication.
After 0.21.0 was published, a fresh installed-CLI check repeated all those operations with the public compiler and library downloads. Its source and artifact caches started empty, and no native developer tools were on the test processes' search path. The report omits only its temporary directory path. The separate clean-container CI checks remove compilers, Git and development headers from the consumer filesystem.
These finite tests do not prove arbitrary foreign code safe. Core sanitizers do not instrument the interiors of prebuilt libraries, and the coroutine gate does not establish whole-process leak freedom. Read the gym limits before interpreting a pass.
Revision
This run used commit e3c072b. All three benchmark/gym reports carry source SHA-256 d6afc98df62d8a40990cf4032cf01595e8c353bf7419d44ddfefa7c479681a79, which includes the platform's prepared compiler-pack metadata. The results apply to that recorded snapshot. Contributor instructions explain how to produce new evidence after a change.