最新のログ
-
AppTermFailureEvent は何のアプリ？ Windows 11 ARM64で40件を追った
Windows 11 ARM64実機のWERを調べると、AppTermFailureEvent 40行は6個のReportIdにまとまり、AppNameもAppPathも無かった。行数と障害件数を同一視できない。
-
Program Files (Arm) は何？Windows ARM64実機では環境変数だけ残り、フォルダはなかった
%ProgramFiles(Arm)% は32-bit Arm向けの互換パスだった。Surface Pro 11のWindows 11 ARM64では環境変数と64-bitレジストリ値が残る一方、C:\Program Files (Arm)自体は存在しなかった。
-
ffmpeg arm64のD3D11VAデコードをWindows ARM64で実測: H.264/HEVC/AV1
ffmpeg arm64のD3D11VAデコードをWindows ARM64実機で検証。H.264/HEVC/AV1はQualcomm Adrenoで1800フレームを復元できたが、CPUへNV12で戻すとH.264とHEVCのwall timeはソフトウェアより長くなった。
-
ffmpeg arm64をWindows ARM64で実測: Qualcomm H.264変換はネイティブ7.26秒
ffmpeg arm64をWindows ARM64のSurface Pro 11で検証。Qualcomm H.264ハードウェア変換はARM64版7.262秒、x64版9.855秒だったが、nv12指定が必須で、libx264より画質指標は低かった。
-
WSL2 の /mnt/c に1000ファイル置いたら、ext4 の457倍かかった
Snapdragon X Elite の WSL2 で、1000個の4KBファイルをVHDX内ext4と /mnt/c に作成・読込・stat・削除した。中央値は70.73ms対32305.75msで457倍。1000ファイルを追跡した git status も5.28ms対950.97msだった。
-
AES-GCM が Python 67.6 MB/s、.NET 6143.2 MB/s。同じ CPU で 90 倍離れた
Snapdragon X Elite の同じ 128MB を、cryptography / pycryptodome / CNG / .NET 9 の 4 経路で暗号化した。出力は全部一致したのに、AES-256-GCM の速度だけ 90 倍離れた。ついでに前回の宿題だった「OpenSSL を新しくすれば速くなるのか」にも答えが出た。
-
Python の SHA-256 を8倍にした — hashlib をやめて bcrypt.dll を ctypes で叩いた
CPython 3.12.10 の hashlib は SHA-256 で289.0 MB/sしか出ない。Windows の CNG を ctypes で直接呼んだら2292.5 MB/sになった。同じ Python プロセス、同じ128MB、同じ digest で7.9倍。SHA-1 と SHA-512 では同じ手が効かなかったので、原因も一緒に絞り込めた。
-
ネイティブ拡張の npm パッケージを8本入れたら、2本が Visual Studio を要求して落ちた
ARM64 Windows で sharp、better-sqlite3、bcrypt など8本を空のプロジェクトに入れ、置かれた .node の PE machine まで読んだ。6本は ARM64 の配布済みバイナリで入り、bufferutil と canvas は node-gyp のソースビルドに落ちて失敗した。
-
12コアを1つずつ固定して測ったら80%の差が出たが、コアの個体差ではなかった
同じ整数ループを12個の論理プロセッサに1つずつ固定して30周まわすと、最小値が0.1369秒から0.2469秒まで80.4%開いた。原因を追うと、コアの性能差ではなく Windows が低い番号のコアへ仕事を寄せていた。空いている4コアだけで測り直すと差は6.5%まで縮んだ。
-
同じ128MBのSHA-256で8倍差 — 遅いのはSnapdragonではなくOpenSSL 3.0.16だった
まったく同じ128MBのバイト列を CPython 3.12.10 / Node.js 24.13.0 / .NET 9 の3処理系で SHA-256 にかけた。Python は241.1 MB/s、Node は289.9 MB/s、.NET は1882.0 MB/sで、同じ CPU なのに8倍近い差がついた。
-
x64 エミュレーションでどれだけ遅くなるか、同じ Python 3.12.10 で測った（SHA-256 だけ逆転した）
同一ビルドの Python 3.12.10 を ARM64 版と x64 版で用意し、8種類の処理を比べた。整数ループは1.56倍、平方根は2.21倍まで遅くなる一方、SHA-256 はエミュレーション側が1.35倍速いという逆転が出た。
-
Snapdragon X Elite の12コアを Windows がどう見せているか（L3キャッシュが0と報告される）
Win32_Processor が返す値をそのまま読むと、12コア12論理プロセッサ・L2が36864KB・L3が0という構成に見える。数字の意味と、信用してはいけない項目を分けて書く。
-
同じループを Python と Node で回したら5倍差がついた（ARM64 Windows 実測）
1000万回の加算を Python と Node で回したところ、中央値で934.5ms 対 185.9ms になった。どちらも ARM64 ネイティブで、エミュレーションは挟まっていない。
-
PowerShell 7 の起動が Windows PowerShell 5.1 より遅かった話（どちらも ARM64 ネイティブ）
pwsh と powershell.exe の起動時間を7回ずつ測ったところ、中央値で386.8ms 対 212.2ms になった。エミュレーションのせいではなく、どちらもネイティブでこの差が出ている。
-
pip install が ARM64 Windows で通るか、主要20パッケージを実際に試した
win_arm64 の wheel があるかどうかを20パッケージで実測した。18本は問題なく取得でき、tiktoken と pyarrow の2本だけが No matching distribution found で落ちた。
-
Snapdragon X Elite の Windows で、起動中の85本のプロセスのうち何本がネイティブか数えた
Surface Pro 11th Edition の実機で動いているプロセスを1本ずつ PE ヘッダーから判定したところ、85本中71本が ARM64 ネイティブだった。残った14本の内訳と、そこから分かることを書く。
-
Playwright の Chromium は x64 で297msだった
Playwright が落とした Chromium 143.0.7499.4 は chrome-win64 配下の x64 版だったが、素数カウントは297msで、手元では遅さを感じなかった。
-
PowerShellの$N/$nバグで素数0個、修正後はpwshが2.5倍速
素数カウントが0個・3msになった原因は$Nと$nの衝突だった。修正後はpwshが5.2秒、powershell.exeが13〜15秒で、実行部分はpwshが2.5〜2.9倍速かった。
-
素数カウントを5処理系で走らせたらJava 8 x64がPython ARM64を大きく抜いた
2から2,000,000までの素数カウントは4処理系とも148933で一致し、.NET 9 ARM64が134ms、Python 3.12 ARM64が41519msだった。
-
Surface Pro 11 は5分フルロードでも61.6%まで落ちなかった
12プロセスで301.0秒負荷をかけ、48件の% Processor Performanceを追った。最初の5件は60.2%、最後の5件は61.6%で、クロック低下は見えなかった。
-
MSIX 240本の Architecture を数えたら Arm64 は145本だった
Get-AppxPackage で取れる240本を数えると、Arm64 は145本、Neutral は54本、X64 は25本、X86 は16本だった。Store アプリ層にも非 Arm64 がまとまって残っている。
-
pandas 3.0.0rc2 では CSV 書き出しが 3402.5ms かかった
2000000行のDataFrameで to_csv は3402.5ms、read_csv は882.7ms。処理本体よりCSV入出力、とくに書き出しが重かった。
-
WSL2 aarch64 の初回だけ 15.35 秒かかった話
wsl -- uname -a の初回は15.35秒かかったが、直後の wsl -- true は0.52 / 0.41 / 0.54秒だった。Docker は未起動で確認できなかった。
-
winget upgrade で23件の更新待ちを棚卸しした話
winget upgrade --include-unknown を実行したら23件の更新待ちが出た。Azure Developer CLI は 1.23.1400 から 1.29.100 まで飛んでいた。
-
32GB Surface Pro 11 の常駐プロセスを WS で見たら指標を間違えた
Surface Pro 11 の空き物理メモリは2.53GB、実行中サービスは149件だった。Get-Process のWS順だけで常駐の重さを判断しようとして、指標の選び方を間違えた。
-
イベントログ40件とWER60件でスリープ復帰を追った失敗
Kernel-Power の復帰イベント40件と WER 60件は取れたが、起動時間ログは rc=1 で空振りした。ログの有無を先に見るべきだった。
-
batteryreport XMLで満充電容量94.1%を測った
powercfg /batteryreport /XML から設計容量51480mWh、満充電容量48450mWhを抜き、健康度94.1%まで確認できた。使用履歴の抽出は0件で詰まった。
-
orjson 3.10.15 だけが ARM64 Windows でビルド失敗した
httpx、rich、pydantic は入ったが、orjson 3.10.15 だけが113.28秒後に失敗した。win_arm64 wheel が無く、Rust ビルドで止まった記録。
-
Git 2.55.0 ARM64 で Jinja を clone して status を測った
Git 2.55.0 ARM64 で pallets/jinja を clone すると3.25秒、16658オブジェクト・7.20 MiBのリポジトリで status は0.07〜0.13秒だった。
-
53ファイルを固めたら Python zipfile だけ0.04秒だった
53ファイル、318661バイトのフォルダを固めたら、zipfile は0.04秒、tar.exe は2.59秒、Compress-Archive は2.03秒だった。
-
npm install はキャッシュなし21.77秒、あり3.2秒だった
Node.js 24.13.0 で4依存だけの npm install を測ると、キャッシュなし21.77秒、キャッシュあり3.2秒。差は6.8倍で、node_modules は2027ファイルまで膨らんだ。
-
.NET 9 の ReadyToRun publish は35.03秒かかった
.NET SDK 9.0.316 で win-arm64 向けに publish したら、framework-dependent は1.75秒、self-contained + ReadyToRun は35.03秒だった。実行時間はどちらも0.12秒で差が出なかった。
-
ffmpeg 8.1.2 は ARM64 版に替えても決定打にならなかった
ffmpeg 8.1.2 の x64 版と BtbN ARM64 版を3ジョブで比べた。720p medium は1.10倍、1080p ultrafast は0.83倍、scale は1.43倍で結果が割れた。
-
Java 8 x64 の java -version は160.3msかかった
Eclipse Adoptium JDK 8 の java -version は中央値160.3msで、最速の curl 16.3ms の9.8倍だった。PEはx64で、ARM64上ではエミュレーション動作になる。
-
Program Files の x64 EXE が ARM64 より多かった話
C:\Program Files の EXE 957本を PE ヘッダーで調べると、x64 が580本、ARM64 が315本だった。ARM64 Windows でもインストール済みアプリの中身はまだ混在している。
-
System32 に x86 と x64 が混ざっていた PE ヘッダー調査
System32 の EXE 702本と DLL 4324本を PE ヘッダーで数えたら、ARM64 だけではなく x86、x64、ARM32 が混ざっていた。
-
matplotlib.pyplot の import だけで 963.8ms かかった話
主要な Python パッケージ 13 個を import するだけのプロセスで測ると、matplotlib.pyplot は963.8ms、pandas は829.5ms だった。
-
json.loads が 105.3ms、正規表現 compile 差が小さかった話
Python 3.12.10 の標準ライブラリで 50,000 件の JSON と 20,000 行のログを測った。json.loads は105.3ms、compile 済み正規表現は7.51msだった。
-
Pillow 12.1.0 の PNG 保存が592.98msかかった話
Pillow 12.1.0 で6000x4000のランダム画像を測ると、PNG保存が592.98msで最重だった。JPEG保存184.42msより3倍以上遅いが、測定設計には欠陥があった。
-
NumPy 2.4.1 の matmul は 512 で一度沈んだ
NumPy 2.4.1 の float64 行列積を測ると、256 は78.03 GFLOPS、512 は74.77 GFLOPS、2048 は149.66 GFLOPSになった。512だけ谷になる。
-
zlib レベル6が102.7 MB/sで圧縮率110.28倍だった
同じ入力で zlib / bz2 / lzma を測った。zlib-6 は102.7 MB/sで110.28倍、lzma は1030.73倍まで縮むが、入力の作り方が失敗だった。
-
hashlib の blake2b が 615 MB/s、sha256 が 145 MB/s だった
64MB のランダムデータを hashlib で測ると、blake2b は615 MB/sで最速、sha256 は145 MB/sで最遅だった。OpenSSL の暗号拡張まわりを疑いたくなる結果になった。
-
SQLite 3.49.1 の PRAGMA 変更は 1.6倍止まりだった
Python 標準の sqlite3 で 100,000 行を INSERT したら、FULL+delete は 534050 rows/s、OFF+memory は 863750 rows/s。差は 1.6倍に収まった。
-
Surface Pro 11 の SSD は256MB書き込みだけ妙に遅かった
SDDPTQD-1T00-1124-WD で64MBと256MBの読み書き、小ファイル2000個を測った。書き込みは348MB/sから197MB/sへ落ち、読み込みは682MB/sから1073MB/sへ伸びた。
-
numpy 2.4.1 の float64 配列で見たメモリ帯域
numpy 2.4.1 の float64 配列で 16MB から 1024MB まで測ると、copy は 19.53GB/s から 16.60GB/s、sum は 22.98GB/s から 19.97GB/s まで揺れた。
-
Snapdragon X Elite 12 worker は8 workerより遅かった
ProcessPoolExecutorで3000000回の整数ループをworkerごとに回すと、8 workerと10 workerが37.26Mopsで並び、12 workerは34.25Mopsへ落ちた。