82436b0e93
Runtime: the loader's AVX2 probe used [System.Runtime.Intrinsics.X86.Avx2] via powershell.exe, which only exists on .NET Core — stock Windows PowerShell 5.1 raised TypeNotFound, so every Windows host silently loaded the baseline addon and paid ~270ms for the spawn on the startup path. Ask the kernel via bun:ffi (IsProcessorFeaturePresent(PF_AVX2_INSTRUCTIONS_AVAILABLE), ~0.5ms) and fall back to pwsh-then-powershell for Node embeds. scripts/host-detect.ts shared the same broken probe for build-time variant selection. Build: `bun run build:native` on a win32 host died deep inside the bazel msvc repo rules (linux/mac exec hosts only, by design). The `host` pseudo-target now delegates to the local napi build against real VS Build Tools, and other targets fail fast with guidance. build-bindings.ts resolves the @napi-rs/cli JS entry from its manifest (the node_modules/.bin shim is a PE launcher Bun cannot parse) and auto-appends VS Build Tools' bundled CMake/Ninja to PATH via vswhere so a vcvars prompt is no longer required. Cap maudio at opt-level=1 to dodge a rustc ICE codegenning MaybeUninit<ma_fence> for x86_64-pc-windows-msvc under the pinned nightly (Bazel's older pin is unaffected). Compile: Bun.Glob.scan yields backslash paths on Windows; the legacy Pi virtual module used them verbatim for export keys and generated identifiers, producing invalid JavaScript in compiled-binary builds. Tests: strip ConPTY negotiation escapes in the pty argv test; ignore the bazel-oh-my-pi convenience symlink.
55 lines
1.6 KiB
TypeScript
55 lines
1.6 KiB
TypeScript
import { dlopen, FFIType } from "bun:ffi";
|
|
import * as fs from "node:fs";
|
|
|
|
function runCommand(command: string, args: string[]): string | null {
|
|
try {
|
|
const result = Bun.spawnSync([command, ...args], { stdout: "pipe", stderr: "pipe" });
|
|
if (result.exitCode !== 0) return null;
|
|
return result.stdout.toString("utf-8").trim();
|
|
} catch {
|
|
return null;
|
|
}
|
|
}
|
|
|
|
export function detectHostAvx2Support(): boolean {
|
|
if (process.arch !== "x64") return false;
|
|
|
|
if (process.platform === "linux") {
|
|
try {
|
|
const cpuInfo = fs.readFileSync("/proc/cpuinfo", "utf8");
|
|
return /\bavx2\b/i.test(cpuInfo);
|
|
} catch {
|
|
return false;
|
|
}
|
|
}
|
|
|
|
if (process.platform === "darwin") {
|
|
const leaf7 = runCommand("sysctl", ["-n", "machdep.cpu.leaf7_features"]);
|
|
if (leaf7 && /\bAVX2\b/i.test(leaf7)) return true;
|
|
const features = runCommand("sysctl", ["-n", "machdep.cpu.features"]);
|
|
return Boolean(features && /\bAVX2\b/i.test(features));
|
|
}
|
|
|
|
if (process.platform === "win32") {
|
|
// `[System.Runtime.Intrinsics.X86.Avx2]` only exists on .NET Core, so the
|
|
// PowerShell probe reported `false` on every host whose `powershell.exe`
|
|
// is Windows PowerShell 5.1 (.NET Framework) — i.e. a stock Windows box —
|
|
// silently downgrading AVX2 machines to the baseline ISA. Ask the kernel
|
|
// instead: PF_AVX2_INSTRUCTIONS_AVAILABLE == 40.
|
|
try {
|
|
const kernel32 = dlopen("kernel32.dll", {
|
|
IsProcessorFeaturePresent: { args: [FFIType.u32], returns: FFIType.i32 },
|
|
});
|
|
try {
|
|
return kernel32.symbols.IsProcessorFeaturePresent(40) !== 0;
|
|
} finally {
|
|
kernel32.close();
|
|
}
|
|
} catch {
|
|
return false;
|
|
}
|
|
}
|
|
|
|
return false;
|
|
}
|