linux-arm64: official builds run 2.7–4× slower than pointer-compression builds on Qualcomm Oryon (Snapdragon X2)

Đang mở
  • Có gì không ổn?
#67,150 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
javascript, linux, node.js
Lĩnh vực
backend, performance

Hướng nghiên cứu

Start by reproducing the Web Tooling Benchmark comparison in the issue on Snapdragon X2, then compare the official build with the same release built using --experimental-enable-pointer-compression. The report rules out several possible causes but does not identify the underlying reason, so investigate the arm64/V8 performance difference and consult the related issue #55735. Done means establishing a cause and a scoped fix or mitigation for the slowdown.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Version

v26.12.1 (also seen on v27.0.0-v8-canary202610235563f8f7df)

Platform
Linux abc-a16-win 6.18.54.1-microsoft-standard-WSL2 #1 SMP PREEMPT_DYNAMIC Tue Oct  6 18:43:37 UTC 2026 aarch64 GNU/Linux
CPU: Qualcomm Snapdragon X2 Elite Extreme X2E94100 (18 Oryon cores), Windows 11 + WSL2

Native Windows arm64 Node on the same machine shows the same slowdown.

Subsystem

build, v8

What steps will reproduce the bug?

On a Snapdragon X2 (Oryon) machine, run the V8 team's Web Tooling Benchmark with the official linux-arm64 build. Then run it with the same release built locally with only pointer compression enabled:

curl -fsSLO https://v8.github.io/web-tooling-benchmark/cli.js
node cli.js                                    # official v26.12.1 linux-arm64

# same release, only pointer compression changed
curl -fsSLO https://nodejs.org/dist/v26.12.1/node-v26.12.1.tar.xz
tar xf node-v26.12.1.tar.xz && cd node-v26.12.1
./configure --experimental-enable-pointer-compression && make -j"$(nproc)"
out/Release/node ../cli.js
How often does it reproduce? Is there a required condition?

Always, on this machine. Required condition: an arm64 build without pointer compression, which is the official default. I don't have other arm64 cores (Apple M-series, Graviton, Ampere) to check whether it is Oryon-specific. On x64 the effect is small (see below).

What is the expected behavior? Why is that the expected behavior?

Official arm64 builds should perform roughly in line with other V8 builds on the same hardware, as they do on x64. There, official Node is within about 2–8% of pointer-compression Node and of Chromium.

What do you see instead?

The official build is 2.7× slower overall and 4× slower on the babel test than the same release with pointer compression. Hardware IPC drops from 3.31 to 1.29.

Web Tooling Benchmark v0.5.3 (same cli.js bundle everywhere; same A16 machine):

Runtime Geomean runs/s babel IPC (perf)
Official Node v26.12.1 linux-arm64 12.78 7.93 1.29
Node v26.12.1 built locally with --experimental-enable-pointer-compression (GCC 15.2, otherwise default) 34.17 31.94 3.31
Node v27 V8 canary (V8 15.8, pointer compression off) 14.16 9.19 1.37
Electron 44.7.2 with ELECTRON_RUN_AS_NODE=1 (V8 15.2, pointer compression on) 42.05 39.78 3.56
Chrome for Testing 156 headless, linux-arm64 46.69 39.56 3.50

x64 reference (i7-13700K, bare-metal Linux): official Node v26.10.0 32.50; unofficial linux-x64-pointer-compression v26.10.0 33.21; Chromium 155 40.89. Node IPC 2.65 vs Chromium 2.89.

Real-world workload: building @mui/material (Babel 8, single-threaded), same machine:

Official v26.12.1 Same version + pointer compression
In-memory Babel pass over 656 files (best of 5 warmed-up rounds) 3,563 ms 1,147 ms
pnpm build of packages/mui-material 8.58 s 4.79 s

The build output is byte-identical between the two.

Additional information

What was ruled out:

  • WSL/virtualisation: native Windows arm64 Node is equally slow, and Chrome in the same WSL instance is fast.
  • V8 version: the V8 15.8 canary without pointer compression is still slow.
  • JIT tiers and threading: --no-maglev, --no-turbofan, --no-sparkplug, --single-threaded and --no-concurrent-recompilation give unchanged results.
  • TLB pressure: transparent_hugepage=always (about 200 MB of the heap in huge pages) gives unchanged results.
  • A single hot path: perf shows the same profile shape as x64 (megamorphic LoadIC builtins about 17%, scavenger about 10%). Everything in the process runs at about 40% of the IPC; frontend stalls are 42% vs 28% and backend stalls 30% vs 10%.

I haven't identified why uncompressed tagged values are so much more expensive on Oryon than on x64. Input from V8/arm64 folks would be welcome.

Related: #55735 (Pointer Compression and Isolate Groups). If the 4 GB cage limit still blocks a default switch, possible interim options:

  • publish official linux-arm64-pointer-compression (and win-arm64) flavours, like the unofficial x64 one;
  • revisit the default on arm64 specifically, given the size of the effect.
Ngôn ngữ chính
JavaScript
Star
123k
Fork
39.3k
Merge trung bình
4 ngày 16 giờ
Pull request đã merge (30 ngày)
227

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của nodejs/node

Tất cả issue của nodejs/node

Issue tương tự

Thêm issue về JavaScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.