Forkrun、GNU Parallelから最大400倍高速化。NUMA対応シェル並列化ツール公開

この記事ではLLMに特化して解説します。LLM全般は LLMとは？仕組みからローカル実行まで徹底解説【2026年完全ガイド】 をご覧ください。

何が起きたか

GitHubで公開されたオープンソースツール「Forkrun」は、GNU Parallelやxargsの後継となるNUMA対応の並列実行ツールだ。14コア28スレッドのi9-7940xで実施した100M行のベンチマークでは、ファイル処理で最大415倍、stdin passthrough（標準入力の直接転送）時に最大256倍の高速化を実現。CPU利用率ではGNU Parallelの6%に対し95～99%を達成している。

背景と経緯

GNU Parallelやxargsといった既存の並列化ツールは、正規表現パースとIPC（Inter-Process Communication：プロセス間通信）のオーバーヘッドにより、マルチソケットサーバーで処理がボトルネックになるケースが多い。特にNUMA（Non-Uniform Memory Access：不均一メモリアクセス）アーキテクチャを持つ最新CPUでは、ソケット間のメモリトラフィックが無視できず、多くのコアが遊休状態に陥るという問題があった。

NUMAとは、複数のCPUソケットがそれぞれ独自のメモリ領域を持ち、自ソケットのメモリへのアクセスは高速だが、他ソケットのメモリにアクセスする場合はレイテンシが増大するアーキテクチャのことだ。サーバー向けの多コアCPUでは標準的な構成となっており、Intel Xeonシリーズやx9世代のCore i9などが該当する。

Forkrunはこうした物理層の制約を設計段階から考慮し、従来ツールとは根本的に異なるアプローチで開発された。単純な並列実行ではなく、NUMAトポロジーを意識したメモリ配置と通信設計が核心にある。

Forkrunのアーキテクチャ

Born-Local NUMA設計

Forkrunの高性能の核心は「Born-Local NUMA」設計にある。データが生成されたNUMAノード上でそのまま処理が完結するように、メモリ配置とワーカーのピン止めが設計されている。クロスソケットのメモリアクセスをほぼゼロに抑えることで、従来ツールで発生していたメモリバス競合を根本から排除する。

主な設計原則

• splice() でstdinからメモリバッファにデータを直接転送（カーネルからユーザー空間へのコピーを省略）
• set_mempolicy(MPOL_BIND) で各チャンクを対象NUMAノード上に事前配置
• 各ソケットにピン止めされたワーカーが独立した処理を実行
• lock-freeリングバッファを使用した競合ゼロの通信メカニズム

適応的なチューニング

Forkrunはバッチサイズを実行環境に応じて自動調整する。GNU Parallelで必要だった -n や -j パラメータの手動チューニングが不要になり、実行環境のCPUトポロジーとワークロードの特性から最適設定を自動導出する。

具体的なベンチマーク結果

パフォーマンス比較表（i9-7940x、100M行）

CPU利用率の比較

GNU Parallelで6%しかCPUが使えていなかった環境でForkrunに切り替えた場合、理論上は同じハードウェアで約16倍の処理量を扱える計算になる。

バッチディスパッチレートの差

インストールと使用方法

インストール

Forkrunは単一のBashファイルで配布され、埋め込まれた自己抽出型のCエクステンションが付属している。PerlもPythonも不要で、以下のワンライナーで完了する。

source <( curl -sL https://raw.githubusercontent.com/jkool702/forkrun/main/frun.bash )

スクリプトをソースすると、シェル環境にCのロードバブルビルトインが自動設定される。インストール時にCエクステンション（forkrun_ring.c）が自動コンパイルされるため、gccが必要になるケースがある。

基本的な使用例

# カスタムBash関数を並列化
frun my_bash_func < inputs.txt

# パイプベースの入力、順序付き出力（-k オプション）
cat file_list | frun -k sed 's/old/new/'

# stdin passthrough（-s オプション）、順序付き出力
frun -k -s sort < records.tsv

# stdin passthrough、出力ファイル名にIDを埋め込み
frun -s -I 'gzip -c >{ID}.gz' < raw_logs

高度な使用例

# 大量ファイルのMD5ハッシュ計算（ファイル処理の典型例）
find /data -type f | frun md5sum > checksums.txt

# ログファイルの並列圧縮
ls /var/log/*.log | frun -I 'gzip -9 {}'

# CSVの並列変換（フィールド抽出）
cat large_dataset.csv | frun -k awk -F',' '{print $1","$3}'

# 並列処理結果をソート済みで出力
seq 1 1000000 | frun -k -s grep '[02468]$' | head -20

GNU Parallelからの移行

GNU Parallelを使用していた既存スクリプトをForkrunに移行する際の対応表。

# GNU Parallel（移行前）
cat inputs.txt | parallel -j4 my_function

# Forkrun（移行後）— -j指定不要、自動最適化
cat inputs.txt | frun my_function

# GNU Parallel（順序付き出力）
cat inputs.txt | parallel -k my_function

# Forkrun（順序付き出力）
cat inputs.txt | frun -k my_function

Apache Airflowのようなワークフローオーケストレーターと組み合わせる場合、個々のタスク内でForkrunを使うことでデータ処理工程の並列化効率が大幅に向上する。

セキュリティと検証可能性

Build検証の透明性

埋め込まれたCエクステンション（forkrun_ring.c）はGitHub Actionsで透過的にコンパイルされ、Base64 blobとしてスクリプトに挿入される仕組みだ。

# ソースコードのBase64エンコード部分を確認
grep -n 'BASE64_START\|BASE64_END' frun.bash

# Git blameでバイナリの出所を追跡
git log --follow -p frun.bash | grep -A5 'BASE64'

git blameを追跡することで、バイナリが公開CIの実行まで遡れるため、隠れた悪意のあるコードが含まれていないことを検証できる。カールで取得したバイナリをそのまま実行するリスクを軽減する設計になっている。

既存ツールとの比較と位置づけ

ツール別の適用シーン

Forkrunが最も威力を発揮するのは、既存ツールがIPCオーバーヘッドとクロスソケットデータ移動によるコア遊休を避けられない場面だ。具体的には次のようなケースが該当する。

• 100M行以上のログ処理: テキスト解析・フィルタリング・変換
• 大規模ファイルのハッシュ計算: セキュリティ検証・整合性チェック
• バッチ画像変換: ffmpegやImageMagickを並列実行
• 科学計算の前処理: 大量データのフォーマット変換

一方、GNU Parallelが依然として優位なケースもある。SSH経由でのリモートホスト並列実行や、複雑な引数展開が必要な場面ではGNU Parallelの豊富な機能が有用だ。

実装概要と主な特性

パフォーマンス指標のまとめ

• バッチディスパッチレート: 200,000+/秒（GNU Parallel 約500/秒）
• CPU利用率: 95～99%全コア（GNU Parallel 約6%）
• クロスソケットメモリトラフィック: ほぼゼロ（NUMA対応Born-Local設計）
• 外部依存: なし（Perl・Python不要）
• インストール: ワンライナー1行

シェルベースのデータパイプラインにおいて、ハードウェアの性能を最大限引き出すことを最優先に設計されたツールだ。既存のGNU Parallelスクリプトからのマイグレーションコストも低く、コマンドの置き換えから始めることができる。AIデータパイプラインの前処理ステップとしてForkrunを活用する場合、RAGFlowによる検索システム構築の前段に組み込むことで、インデックス生成の速度を大幅に向上させることができる。

実際の活用シナリオ

データエンジニアリングパイプラインでの活用

大量のCSVファイルやログファイルを前処理するデータエンジニアリングのパイプラインでは、Forkrunが特に効果的だ。

#!/bin/bash
# 大規模ログファイルを並列でJSONに変換するスクリプト

source <( curl -sL https://raw.githubusercontent.com/jkool702/forkrun/main/frun.bash )

# 全ログファイルを並列でJSONLに変換（順序付き出力）
find /var/log/app -name "*.log" -newer /tmp/last_processed | \
  frun -k -I 'python3 /opt/scripts/log2json.py {} > {}.jsonl'

# 変換済みファイルを並列で圧縮
ls /var/log/app/*.jsonl | frun -I 'gzip -9 {} && rm {}'

echo "処理完了: $(date)"

機械学習データセットの前処理

# 1億行のテキストデータをトークン化して並列保存
source <( curl -sL https://raw.githubusercontent.com/jkool702/forkrun/main/frun.bash )

cat /data/corpus/raw_text.txt | \
  frun -k -s python3 -c "
import sys
for line in sys.stdin:
    tokens = line.strip().split()
    print(' '.join(tokens[:512]))  # 最大512トークンに切り詰め
" > /data/corpus/tokenized.txt

パフォーマンスチューニングのポイント

ワークロード別の最適オプション

NUMA構成の確認

Forkrunの効果を最大化するには、まず対象システムのNUMAトポロジーを把握することが重要だ。

# NUMAノードの構成を確認
numactl --hardware

# NUMAノード間のメモリアクセス速度を確認
numactl --show

# 現在のNUMAメモリ使用状況
numastat -m

NUMAノードが1つしかない環境（一般的なデスクトップPC）では、Born-Local設計の恩恵は限定的だ。Forkrunが最大の効果を発揮するのは、デュアルソケット以上のサーバー環境だ。

関連記事: LLMとは？仕組みからローカル実行まで徹底解説【2026年完全ガイド】

参照ソース

• Forkrun 公式リポジトリ（GitHub）
• Hacker Newsでの議論
• GNU Parallel 公式サイト

この記事はAI業界の最新動向を速報でお届けする「AI Heartland ニュース」です。