タグ: ベンチマーク
「ベンチマーク」に関係するログが 31 本あります。
-
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 では同じ手が効かなかったので、原因も一緒に絞り込めた。
-
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倍速いという逆転が出た。
-
同じループを 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 になった。エミュレーションのせいではなく、どちらもネイティブでこの差が出ている。
-
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%で、クロック低下は見えなかった。
-
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 は未起動で確認できなかった。
-
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上ではエミュレーション動作になる。
-
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へ落ちた。