タグ: アーキテクチャ
「アーキテクチャ」に関係するログが 16 本あります。
-
Program Files (Arm) は何？Windows ARM64実機では環境変数だけ残り、フォルダはなかった
%ProgramFiles(Arm)% は32-bit Arm向けの互換パスだった。Surface Pro 11のWindows 11 ARM64では環境変数と64-bitレジストリ値が残る一方、C:\Program Files (Arm)自体は存在しなかった。
-
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 のソースビルドに落ちて失敗した。
-
同じ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という構成に見える。数字の意味と、信用してはいけない項目を分けて書く。
-
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で、手元では遅さを感じなかった。
-
MSIX 240本の Architecture を数えたら Arm64 は145本だった
Get-AppxPackage で取れる240本を数えると、Arm64 は145本、Neutral は54本、X64 は25本、X86 は16本だった。Store アプリ層にも非 Arm64 がまとまって残っている。
-
WSL2 aarch64 の初回だけ 15.35 秒かかった話
wsl -- uname -a の初回は15.35秒かかったが、直後の wsl -- true は0.52 / 0.41 / 0.54秒だった。Docker は未起動で確認できなかった。
-
orjson 3.10.15 だけが ARM64 Windows でビルド失敗した
httpx、rich、pydantic は入ったが、orjson 3.10.15 だけが113.28秒後に失敗した。win_arm64 wheel が無く、Rust ビルドで止まった記録。
-
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 が混ざっていた。