fix(build): compile x64 binaries against Bun's baseline runtime - #797
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
elucid
marked this pull request as ready for review
August 17, 2026 22:05
Contributor
Greptile SummaryThe PR compiles x64 binaries against Bun’s baseline runtimes and adds pre-AVX2 startup checks to CI and release builds.
Confidence Score: 4/5The PR appears safe to merge after the non-blocking test-file indentation inconsistency is corrected. The baseline target selection and Linux compatibility gates align with the supported native build matrix; the only accepted issue is formatting in the newly added unit test. Files Needing Attention: scripts/build-bin.test.ts Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[build:bin] --> B{Host architecture}
B -->|arm64 or unsupported| C[Bun host-default runtime]
B -->|x64| D{Host platform}
D -->|macOS| E[bun-darwin-x64-baseline]
D -->|Windows| F[bun-windows-x64-baseline]
D -->|Linux glibc| G[bun-linux-x64-baseline]
D -->|Linux musl| H[bun-linux-x64-musl-baseline]
E --> I[Compile dist binary]
F --> I
G --> I
H --> I
C --> I
I --> J[Linux x64 QEMU Nehalem startup check]
Prompt To Fix All With AI### Issue 1
scripts/build-bin.test.ts:5
**Test indentation breaks convention**
The newly added test bodies use two-space indentation instead of the repository's required four-space indentation, leaving the file inconsistent with the required formatting convention.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Reviews (1): Last reviewed commit: "fix(build): compile x64 binaries against..." | Re-trigger Greptile |
Bun's default x64 runtime is built for Haswell (AVX2/BMI2, 2013+), so every prebuilt x64 Hunk binary died before running a line of Hunk code on older CPUs and on VMs that expose a conservative CPU model: SIGILL on Linux, a Bun panic with `Features: no_avx2` on Windows. Reported in #454 against 0.15.3 and reproduced on 0.19.0. Compile x64 hosts against Bun's baseline runtime instead, which only needs x86-64-v2 (SSE4.2/POPCNT), and keep arm64 on Bun's host default. Both CI and the release workflow now run the built linux-x64 artifact under an emulated pre-AVX CPU so a dropped target fails the build instead of shipping a binary that cannot start. Measured on Skylake Linux and Windows hosts with the repo benchmark suite: no material performance difference (median delta -0.29% Linux, +0.84% Windows; metrics with self-noise <= 3% land within +-1%).
elucid
force-pushed
the
fix/x64-baseline-binaries
branch
from
August 18, 2026 15:09
b1cd862 to
b7db92f
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #454.
Problem
Every prebuilt x64 binary dies before running a line of Hunk code on CPUs without AVX2 — pre-2013 hardware and VMs with a conservative CPU model.
bun build --compilewith no--targetembeds Bun's default x64 runtime, which is built for Haswell (AVX2/BMI2). Reported against 0.15.3; 0.19.0 is identical.Reproduced on a real Nehalem KVM VM and on Windows 11 masked to SandyBridge:
Illegal instruction (core dumped), exit 1320.19.0, full TUI with syntax highlightingFeatures: no_avx2, exit 30.19.0Fix
Compile x64 hosts against Bun's baseline runtime, which needs only x86-64-v2 (SSE4.2/POPCNT, Nehalem 2008+). arm64 keeps Bun's host default. CI and the release workflow now run the built linux-x64 artifact under an emulated pre-AVX CPU, so dropping the target fails the build instead of shipping a binary that cannot start.
Performance tradeoff
The baseline runtime is compiled without AVX2-dependent codegen, so this trades a small amount of optimization for running on every x86-64 CPU since 2008. Measured, that tradeoff is not material. Both Bun runtimes were run against the repo's benchmark suite with per-sample interleaving on Skylake Linux and Windows hosts:
Every metric that looked like a regression turned out to be noise: the release gate's own thresholds are exceeded by same-runtime control comparisons on these hosts, and the one metric with a consistent early signal (
scroll_tick_median_ms, baseline slower in 5 of 7 pairs) reversed at 17 pairs to 4.6% faster, slower in 9 of 17.At the primitive level only
Bun.stringWidthmoved (+19.5% CJK, +9.1% ASCII). OpenTUI calls it, but instrumenting real renders shows ~20 calls totaling 0.06–0.08 ms per render — Hunk's own width path is plain JS and unchanged — so it costs roughly 0.015 ms per frame.Distribution
No asset or package names change, so npm, mise/aqua (
hunkdiff-{{.OS}}-{{.Arch}}.tar.gz), and the GitHub release tarballs are unaffected. Homebrew builds from source viabun run build:bin, so its x86_64 bottles pick this up automatically.nix/package.nixinvokesbun build --compiledirectly and is unchanged —--targetfetches a runtime, which the Nix sandbox cannot do.Not included
bin/hunk.cjs. Today it exits 1 with no output when the prebuilt binary dies. Worth fixing separately; note it cannot rescue Windows, where the failure is a normal exit code rather than a signal.