Latest logs
-
What Is AppTermFailureEvent in Windows 11? 40 ARM64 Records Investigated
On a Windows 11 ARM64 PC, 40 AppTermFailureEvent rows collapsed to 6 ReportId values, and none contained AppName or AppPath. Row count was not incident count.
-
What is Program Files (Arm) on Windows ARM64? The variable existed, but the folder did not
%ProgramFiles(Arm)% is a compatibility path for 32-bit Arm applications. On my Surface Pro 11 running Windows 11 ARM64, the environment and 64-bit registry values remained, but C:\Program Files (Arm) did not exist.
-
FFmpeg ARM64 Windows D3D11VA decode: H.264, HEVC, and AV1 measured
I tested FFmpeg ARM64 Windows D3D11VA decoding on a Surface Pro 11. H.264, HEVC, and AV1 all decoded 1,800 frames through Qualcomm Adreno, but NV12 readback made H.264 and HEVC slower than software decoding in wall time.
-
FFmpeg ARM64 Windows: Qualcomm H.264 hardware encode, native ARM64 vs x64 emulation
I tested FFmpeg ARM64 Windows H.264 encoding on a Surface Pro 11. The forced Qualcomm hardware path took 7.262 seconds with native ARM64 and 9.855 seconds under x64 emulation, but required nv12 and scored below libx264 on PSNR and SSIM.
-
WSL2 ext4 vs /mnt/c: DrvFs took 457x longer for small files
On a Snapdragon X Elite PC, I created, read, stat-ed, and deleted 1,000 4 KB files in WSL2. The median was 70.73 ms on ext4 inside the WSL VHDX and 32,305.75 ms on /mnt/c through DrvFs: a 456.75x gap. Git status on 1,000 tracked files took 180.11x as long.
-
AES-GCM on Snapdragon X Elite: Python 67.6 MB/s vs .NET 6143.2 MB/s
I encrypted the same 128 MB through four AES-256-GCM paths on a Snapdragon X Elite: cryptography, pycryptodome, Windows CNG, and .NET 9. All outputs matched exactly, but throughput differed by 90x. The test also answered the previous question of whether a newer OpenSSL would make the Python path faster.
-
Python SHA-256 was 7.9x faster through Windows CNG via ctypes
CPython 3.12.10's hashlib reached only 289.0 MB/s for SHA-256. Calling Windows CNG in bcrypt.dll directly through ctypes reached 2,292.5 MB/s on the same Python process and the same 128 MB input, with the same digest: a 7.9x result. The same approach did not produce the same gain for SHA-1 or SHA-512.
-
Installing eight native npm packages on ARM64 Windows: two required Visual Studio
I installed eight native-extension npm packages into empty projects on ARM64 Windows and read the PE machine field of their .node files. Six installed with ARM64 prebuilt binaries; bufferutil and canvas entered the node-gyp source-build path and failed while looking for Visual Studio.
-
Pinning one benchmark to each of 12 cores showed an 80% gap - but not core silicon variance
Pinning the same integer loop to each of 12 logical processors for 30 rounds produced minimums from 0.1369 to 0.2469 seconds, an 80.4% spread. The cause was Windows favoring lower-numbered cores, not different core performance. Repeating the test on four idle cores reduced the spread to 6.5%.
-
SHA-256 on Windows ARM64: .NET was 8x faster than Python and Node
The same 128 MB byte sequence was hashed with CPython 3.12.10, Node.js 24.13.0, and .NET 9. Python reached 241.1 MB/s, Node 289.9 MB/s, and .NET 1,882.0 MB/s on the same native ARM64 CPU—nearly an 8x gap.
-
Measuring x64 emulation overhead with the same Python 3.12.10 (SHA-256 reversed the result)
I compared eight workloads using the same Python 3.12.10 in ARM64 and x64 builds. The integer loop was 1.56x slower and square roots 2.21x slower under emulation, but SHA-256 was 1.35x faster under emulation.
-
How Windows reports the 12-core Snapdragon X Elite topology (L3 cache reported as 0)
Reading Win32_Processor as returned shows 12 cores, 12 logical processors, 36,864 KB of L2 cache, and 0 for L3 cache. This separates the values that are useful from the values that should not be trusted.
-
Python vs Node.js loop benchmark on ARM64 Windows: Node was 5x faster
A 10-million-addition loop took a median 934.5 ms in Python and 185.9 ms in Node.js. Both runtimes were native ARM64, with no x64 emulation in the path.
-
PowerShell 7 startup was slower than Windows PowerShell 5.1 on native ARM64
Across seven launches, the median was 386.8 ms for `pwsh -NoProfile -c exit` versus 212.2 ms for `powershell -NoProfile -c exit`. The difference was not caused by emulation: both executables were native ARM64.
-
Can pip install on Windows ARM64? I tested 20 major packages
I checked for win_arm64 wheels across 20 packages. Eighteen were downloaded successfully; only tiktoken and pyarrow failed with No matching distribution found.
-
Windows on Snapdragon X Elite: 71 of 85 running processes were ARM64 native
I classified each process running on a real Surface Pro 11th Edition by reading its PE header. Of 85 processes, 71 were ARM64 native, 11 were x64 emulation, and 3 were x86 emulation. The remaining 14 and what they reveal are documented here.
-
Playwright's Chromium was x64 and counted primes in 297ms
The Chromium 143.0.7499.4 downloaded by Playwright was x64 under chrome-win64, but its prime count took 297ms and did not feel slow here. This is not a strict Node.js-versus-Chromium V8 comparison.
-
The PowerShell $N/$n bug counted zero primes; fixed pwsh was 2.5x faster
The zero-prime, 3ms result came from a collision between $N and $n. After the fix, pwsh took about 5.2 seconds and powershell.exe 13–15 seconds; pwsh was 2.5–2.9x faster in the execution body.
-
Prime-counting benchmark on Windows on ARM: Java 8 x64 beat native Python by more than 15x
The prime count from 2 through 2,000,000 matched at 148933 in all four runtimes. .NET 9 ARM64 took 134 ms, while Python 3.12 ARM64 took 41,519 ms; Java 8 x64 emulation still beat native Python by more than 15x.
-
Surface Pro 11 stayed at 61.6% after five minutes of full load
After 301.0 seconds of load across 12 processes, I tracked 48 samples of % Processor Performance. The first five averaged 60.2% and the last five 61.6%; no clock decline was visible.
-
Windows on ARM64 AppX architecture census: 145 Arm64 packages out of 240
Counting 240 packages returned by Get-AppxPackage found 145 Arm64, 54 Neutral, 25 X64, and 16 X86 packages. The Store app layer still contains a substantial non-Arm64 set.
-
pandas 3.0.0rc2 took 3402.5ms to write a CSV
With a 2,000,000-row DataFrame, to_csv took 3402.5ms and read_csv took 882.7ms. CSV I/O, especially writing, was heavier than the data-processing operations.
-
The first WSL2 aarch64 launch took 15.35 seconds
The first wsl -- uname -a took 15.35 seconds, while wsl -- true immediately afterward took 0.52, 0.41, and 0.54 seconds. Docker was stopped, so its server side could not be checked.
-
Auditing a 23-package backlog from winget upgrade
Running winget upgrade --include-unknown showed 23 pending upgrades. Azure Developer CLI had moved from 1.23.1400 to 1.29.100.
-
Top resident processes on a 32GB Surface Pro 11: why WS was the wrong metric
The Surface Pro 11 had 2.53GB of free physical memory and 149 running services. Sorting `Get-Process` by working set to identify heavy resident processes failed because the metric and the captured process list were incomplete.
-
Auditing sleep resume with 40 event-log entries and 60 WER records - a failed boot-time check
I retrieved 40 Kernel-Power resume events and 60 WER records, but the boot-time query returned rc=1 with no data. I should have checked whether the log existed before querying it.
-
Windows batteryreport measured 94.1% full-charge capacity health
I extracted a design capacity of 51480 mWh and a full-charge capacity of 48450 mWh from powercfg /batteryreport /XML, confirming 94.1% health. Extracting the usage history stalled with zero entries.
-
orjson 3.10.15 was the only package that failed to build on Windows ARM64
httpx, rich, and pydantic installed, but only orjson 3.10.15 failed after 113.28 seconds. There was no win_arm64 wheel, so pip stopped in a Rust source build.
-
Git 2.55.0 ARM64: Cloning Jinja and measuring status
With native ARM64 Git 2.55.0, cloning pallets/jinja took 3.25 seconds and status took 0.07–0.13 seconds on a 16,658-object, 7.20 MiB repository.
-
Archiving 53 files took 0.04 seconds with Python zipfile
Archiving a 53-file, 318,661-byte folder took 0.04 seconds with zipfile, 2.59 seconds with tar.exe, and 2.03 seconds with Compress-Archive.
-
npm install took 21.77 seconds cold and 3.2 seconds warm
With Node.js 24.13.0 and four dependencies, npm install took 21.77 seconds without cache and 3.2 seconds with cache. The 6.8x difference expanded node_modules to 2,027 files.
-
.NET 9 ReadyToRun publish for ARM64 took 35.03 seconds
Publishing for win-arm64 with .NET SDK 9.0.316 took 1.75 seconds for framework-dependent output and 35.03 seconds for self-contained output with ReadyToRun. Runtime execution was 0.12 seconds for both.
-
ffmpeg 8.1.2: Switching to ARM64 did not deliver a decisive win
I compared ffmpeg 8.1.2 x64 and the BtbN ARM64 build across three jobs. The 720p medium result favored ARM64 by 1.10x, the 1080p ultrafast result recorded x64_slower_x as 0.83x and favored x64, and scaling favored ARM64 by 1.43x.
-
Java 8 x64 java -version took 160.3 ms to start
Eclipse Adoptium JDK 8 java -version had a 160.3 ms median, 9.8x slower than the fastest comparison, curl at 16.3 ms. The PE is x64, so it runs under emulation on ARM64.
-
ARM64 Windows Program Files census: x64 EXEs still outnumber ARM64
Reading the PE headers of 957 EXEs under C:\Program Files found 580 x64 files and 315 ARM64 files. Even on Windows on ARM64, installed applications remain a mixture of architectures.
-
A PE-header census found x86 and x64 mixed into System32
Reading PE headers for 702 EXEs and 4,324 DLLs in System32 found a mixture of ARM64, x86, x64, and one ARM32 file rather than ARM64 alone.
-
Python import cost on ARM64 Windows: matplotlib.pyplot took 963.8 ms
In process-level tests that only imported 13 common Python packages, `matplotlib.pyplot` took 963.8 ms and `pandas` took 829.5 ms. The startup and import cost is visible in short CLI commands.
-
json.loads took 105.3 ms, while compiling the regex made little difference
Using the Python 3.12.10 standard library, I measured 50,000 JSON records and a 20,000-line log. json.loads took 105.3ms and the compiled regex took 7.51ms.
-
Pillow 12.1.0 PNG saving took 592.98ms
With a 6000x4000 random image in Pillow 12.1.0, PNG saving was the heaviest operation at 592.98ms. It was over three times slower than 184.42ms JPEG saving, but the measurement design was flawed.
-
NumPy 2.4.1 matmul dipped at 512: 74.77 GFLOPS
On NumPy 2.4.1, float64 matrix multiplication measured 78.03 GFLOPS at 256, 74.77 GFLOPS at 512, and 149.66 GFLOPS at 2048. The 512 case was the dip.
-
zlib level 6 reached 102.7 MB/s and an 110.28x ratio
I measured zlib, bz2, and lzma on the same input. zlib-6 reached 102.7 MB/s with an 110.28x ratio; lzma shrank it by 1030.73x, but the input construction was a failed choice.
-
hashlib blake2b reached 615 MB/s while sha256 managed 145 MB/s
Hashing 64MB of random data with hashlib made blake2b the fastest at 615 MB/s and sha256 the slowest at 145 MB/s. The result made me suspect the OpenSSL crypto-extension path.
-
SQLite 3.49.1 PRAGMA changes stopped at a 1.6x INSERT gain
Inserting 100,000 rows with Python's standard sqlite3 gave 534,050 rows/s with FULL+delete and 863,750 rows/s with OFF+memory. The difference stayed at 1.6x.
-
The Surface Pro 11 SSD was oddly slow only for 256MB writes
On an SDDPTQD-1T00-1124-WD, I measured 64MB and 256MB sequential I/O plus 2,000 small files. Write speed fell from 348MB/s to 197MB/s, while read speed rose from 682MB/s to 1073MB/s.
-
Memory bandwidth with NumPy float64 arrays
With NumPy 2.4.1 and float64 arrays from 16MB to 1024MB, copy ranged from 19.53GB/s to 16.60GB/s and sum ranged from 22.98GB/s to 19.97GB/s.
-
Snapdragon X Elite 12-core scaling: 12 workers were slower than 8
Running a 3,000,000-iteration integer loop per worker with ProcessPoolExecutor produced 37.26 Mops at both 8 and 10 workers, then fell to 34.25 Mops at 12 workers.