PSDP — 同一言語並列化

実測データ

数字は必ず測定条件と一緒に出します。条件を書かない倍率は掲載しません。 一次記録は 開発過程・検証記録 にあります。

ワークロード	測定条件	速度	一致
夜間バッチ・集計	PostgreSQL 16.14 実サーバ / fetch を id レンジ分割 / 50 万行以上 8 接続 4.73× が最良。20 接続は劣化するため接続数も判定対象です。	3.26 – 5.81×	bit-exact 20 / 20
独立行へのバッチ更新	実 PostgreSQL / 並列 32 (128 は頭打ち) / C# Npgsql	8.57×	bit-exact
EC 受注バッチ (税率クラス / クーポン / ポイント / 切り捨て)	DB 5 エンジン (PostgreSQL / H2 / HSQLDB / SQLite / Derby)	2.98 – 4.54× (PostgreSQL 4.47×)	5 エンジンすべてで同一ビット
オンライン応答 (N+1 が出ている画面)	買い物履歴 / localhost PostgreSQL = 効果の下限 本番は DB がネットワーク越しなので効果はより大きくなります。	5.95× / 5.29× 50 注文 11.8→2.0ms 200 注文 30.9→5.8ms	証跡一致。CPU 消費は 0.63 – 0.71 倍に減少
計算そのものが重い処理 (行列乗算 / 画像畳み込み / 表計算 / 実 TCP)	Rust (標準ライブラリのみ) / スレッド 1 〜 20	6.67× / 6.30× 5.35× / 16.88×	全スレッド数で digest dfcf3fee29d7d15c 固定
言語をまたいだ一致 (変換器同梱サンプル)	総仕事量 200,000 task 固定 / 20 コア / 行列乗算 N=16 / 2026-08-18 再測定	Go 4.05× C# 2.81×	並列度 1〜20 の全通り、および Go / C# 間で 0xe718490618e7f144 一致
Track A (Java 本流・決定性実証)	実行モデルは逐次 (topological phase order)	—	bit-exact 378 / 378 golden d2fc575a50086c6f 再現済。決定性の実証であって並列性能の実証ではありません。

★ 上記の並列実行部は当社で実装して測っています (自動変換ツールの出力ではありません)。位置づけは 「適用が完了したときに出る値」です。前提は § 前提と限界 に明記しています。

仕組み — 速くしてよい所を、機械が先に決める

並列化そのものは難しくありません。難しいのは「速くなって、かつ答えが変わらない」境界を引くことです。 PSDP はこの境界を 4 段で引き、境界の内側は取りに行きます。

判定は 4 値で返ります。

• AUTO_PARALLELIZED順序を外しても結果が変わらないと判定できた。並列化する。
• VERIFIED_SEQUENTIAL順序に意味があると判定できた。逐次のまま残す。
• NEEDS_CONTRACT判定に必要な契約 (金額の scale・merge 順・partition key 等) が宣言されていない。宣言すれば並列化できます。
• REJECTED_UNSAFE順序依存が実証された。並列化しない。

保証は二段構え — 前段 bit-exact / 後段 完全一致

PSDP の保証は、同一言語内とまたいだときの二段に分かれます。 前段を言語別のオプション (SlimeX2X ファミリー) が、後段を PSDP 本体が持ちます。

★ 後段が要る理由。前段だけでは「その言語・その並列度・その DB では合っていた」までしか言えません。 実測では、同じ SQL 集計が PostgreSQL と H2 で 419 / 512 グループ不一致になり、 正しく分割していない並列版はスレッド数ごとに全部違う値を返しました。 開発機と本番機で答えが変わらないことは、後段でしか言えません。

どこに効くか

効き方はその処理の律速で決まります。実測した律速は 4 種類。 導入前にどれかを判定するので、「入れたが速くならなかった」は起きません。

部位	律速	実測	判定
独立行へのバッチ更新	往復遅延	8.57×	最も効きます。
オンライン応答 (N+1 が出ている画面)	待ち	5.95×	効きます。CPU もむしろ減ります。同時実行数が高い時間帯は 並列度を自動で縮退させます (同時 16 以降は逐次が有利、という実測に基づく)。
夜間バッチ・集計 (読み中心)	fetch	3.26 – 5.81×	効きます。50 万行から効き始めます。
帳票・明細・残高推移	prefix-scan	効きます	金額が整数 (最小単位) または BigDecimal / decimal であること。 Java / C# の EC はこの条件を最初から満たしています。 double 建ての場合のみ対象外です。
計算そのものが重い処理	CPU	5.35 – 16.88×	効きます。正しい分割軸は分野ごとに違う (行 / 位相 / 接続 / id レンジ) ため、軸の選定も判定に含みます。
受注・在庫・決済 (同一行に集中)	競合	1.00×	効きません。並列度を上げても 560 ops/s のまま。 ここは判定で除外し、代わりに手段を替えます — 楽観ロックが入っている場合は行ロック / 直列化へ替えるだけで 9.9 倍はやく、しかも正しくなります (実測 56.8 → 560 ops/s)。
取り込みが支配的な処理	取り込み	1.06×	集計をいくら並列化しても伸びません (読込が 94.1%)。 取り込み側の並列化に切り替えます。

実測 6 件のうち、4 件は「並列化しない」が正解でした

野良の実在 OSS・実 DB に対して判定を通した結果です。 PSDP は「何でも並列化する道具」ではなく、「並列化してはいけない所を止める道具」である、 というのがこの 6 件の意味です。

題材	正解	実測
会計元帳の取り込み (cl-ledger)	並列化しない	集計を無限コアで並列化しても上限 1.06× (読込が 94.1%)
競合行の更新	並列化しない	行ロック / 直列化の方が 9.9 倍はやく、しかも正しい (楽観ロックは逐次の 10.2 倍おそい)
ランニング残高	型を変えるまで並列化しない	f64 は順序を保存しても不一致。整数 / BigDecimal なら完全一致
既に並列なライブラリ (OpenBLAS)	外側を並列化しない	★外側 8 × BLAS 20 は逐次の 2.7 倍おそい。最速は「外側を並列化しない」構成
RAG 検索	採点だけ並列・top-k は逐次	同点 24 文書から top5 が 100 種類。ID 二次順序でコストほぼゼロで決定論化
HNSW (近似最近傍) の構築	並列構築し artifact を凍結	並列構築 5.96×。★検索は決定論・構築が非決定論なので、 index のバイト列を固定すれば再現します (保存済み index の再読込は 63/63 完全一致)

なぜ「bit-exact」を証跡にするのか

速くする手段は、どれも間違えると金額が変わり、しかもテストでは出ません。 以下はすべて実機で観測した実物です。PSDP はこの全部を通した上で速度を出しています。

観測した壊れ方	実測	PSDP 経路
集計を SQL に寄せるとエンジンで金額が変わる	419 / 512 グループが PostgreSQL と H2 で不一致 (HSQLDB とは 490 / 512、max |Δ| 1.6e-8)	5 エンジンすべてで同一ビット。 DB を替えても金額が動かないことは、移行・監査・規制報告に直結します。
ORDER BY が全順序でない	更新前は 5 エンジン中 4 つが緑。UPDATE … SET qty=qty を 1,893 行流しただけで PostgreSQL と HSQLDB が破綻。合計 3,238,609.2700000014 は同じに見える	全順序性を判定対象に含みます。★開発 = H2 / 本番 = PostgreSQL は Java 基幹でごく普通の構成で、開発では原理的に再現しません。
金額の型で並列化可否が決まる	順序を完全保存した prefix-scan でも f64 は全ブロック幅で不一致 (chunk 64 で 9,742 / 10,000)。整数・BigDecimal は完全一致	金額の型を判定に含めるため、BigDecimal / decimal の資産は迷わず並列化できます。
壊れている版の方が速い	EC 受注バッチ: 正しい版 4.47× に対し違反版 6.09×。 表示金額は同じに見えるのに税額の下位ビットが変わる (…767999999E8 → …768000002E8)	速さだけを見ると誤った方を選びます。だから証跡が要ります。
スレッド数で答えが変わる	違反版はスレッド数ごとに全部違う値。開発機 8 コア / 本番 16 コアで変わる	正しい軸ならスレッド 1〜20 で digest 固定 (dfcf3fee29d7d15c)。
素朴な並列化はデータ構造を壊す	同期なしの共有 HashMap は例外を吐いて落ち、 merge(…, Double::sum) 版はrun 1 と run 2 でも 478 / 512 不一致	= 顧客別売上が毎晩違う値になる形。判定で落とします。

対応言語

変換器は 24 本・16 言語。ただし言語によって並列化の効き方が違うので、段階を分けて書きます。

速度を条件付きで 測れる (6 言語)	同一仕事量でスレッド数を振れる実装。C# / Go ほか。 実測 Go 4.05× / C# 2.81×。
並列実行はする	Java 17 / 8to17 / _prime は new Thread( を task ごとに作るため、 同一仕事量でスレッド数を振れません (= 速度の比較測定ができない)。 ThreadPool 化が次の作業です。
CPU 並列が存在しない	Node.js / PHP (PHP は変換器自身が "PHP core lacks threads" と明記)。 Python は GIL のため 1.00× (bit-exact は成立)。
検体	変換器に同梱の検体は行列乗算 1 本です。 EC バッチ・RDB の実測は、変換器を通さず別途 PoC を書いて測っています。

PSDP オプション — 言語別 並列最適化 (SlimeX2X ファミリー) 開発中

PSDP 本体が後段 (またいでも完全一致) を持ち、 前段 (同一言語内で bit-exact) を言語別のオプションが担います。 オプションはすべて同一言語変換です — Java は並列 Java へ、Rust は並列 Rust へ。

オプション	変換	前段の根拠になる実測	状態
SlimeJava2Java	Java → 並列 Java	Java の倍率実測は 0 件 (本流 Track A は逐次実行)。 ボリュームゾーンの穴であり、最優先です。	開発中
SlimeCSharp2CSharp	C# → 並列 C#	C# 2.81× (総仕事量固定・20 コア)、 独立行バッチ更新 8.57× (実 PostgreSQL / Npgsql)。測定系が整っています。	設計
SlimeGo2Go	Go → 並列 Go	Go 4.05×。C# との出力ハッシュが 0xe718490618e7f144 で一致 (= 後段が実証されている組)。	設計
SlimeRust2Rust	Rust → 並列 Rust	行列乗算 6.67× / 画像畳み込み 6.30× / 表計算 5.35× / 実 TCP 16.88×、 スレッド 1〜20 で digest 固定。4 分野の実測は Rust で取っています。	設計
SlimeKotlin2Kotlin SlimeScala2Scala SlimeCpp2Cpp SlimeSwift2Swift ほか	同一言語変換	変換器は存在します。同一仕事量でスレッド数を振れる形への改修が前提です。	構想
Python / Node.js / PHP	—	CPU 並列が存在しないため、並列最適化の対象外です (Python は GIL のため 1.00×、PHP は変換器自身が "PHP core lacks threads" と明記)。 bit-exact 変換自体は成立します。	対象外

★ 同一言語に閉じる理由: 元コードをそのまま実行 oracle として保持でき、 他言語との数値 API 差を扱わずに済み、生成コードを顧客が読め、 失敗した箇所だけ元へ戻せるためです。既存のテスト・ビルド・監視もそのまま使えます。

SlimeJava2Java (最優先) の設計

中心は compute と commit の分離です。既存コードをそのまま複数スレッドで走らせるのではありません。

// 1. Snapshot / Fetch    — 必要な入力を固定する
// 2. Parallel Compute    — 口座ごとの計算を独立実行 (DB 更新・出力はしない)
// 3. Deterministic Commit — 元の順序で DB 更新・出力する

List<IndexedStatement> prepared =
    parallelCompute(accounts, account -> calculateStatement(account));

prepared.sort(byOriginalIndex());

for (IndexedStatement result : prepared) {
    repository.save(result.statement());
    output.write(result.statement());
}

並列化するのは計算の準備部分で、副作用は元の順序で確定します。 これにより DB 更新順・出力順・例外の観測順・ログ順・帳票行順を保ったまま、 重い計算だけを並列化できます。

証明を 2 種類に分ける

• Execution
  Certificate 特定の入力スナップショットについて、元の逐次版と最適化版 (並列度 1 / 2 / 4 / 8) が 同じ canonical bytes を返したことを示す。「このバッチ実行について同一」という証明。
• Transformation
  Certificate 受理した変換パターンについて、partition 間に read/write 競合がない・ partition 内の順序を保持する・merge 順が固定・数値規約が固定・副作用が commit 段に隔離・ 例外の観測順を保持、を静的に検査する。「この契約を満たす全入力について同値」という、より強い証明。

★ 主張は「任意の Java コードを自動的に数学証明できる」ではなく、 「fail-closed で受理した変換だけを証明する」です。

v1 の対象 / 対象外

対象	顧客・口座・店舗・加盟店単位で独立したバッチ / 帳票生成 / 請求・手数料計算 / 明細生成 / 残高推移 (金額が整数・BigDecimal の場合) / 日次・月次集計 / read-only fetch 後の独立計算
対象外	同一行への競合更新 / 複数 partition をまたぐトランザクション / グローバル可変状態 / 時刻・乱数への暗黙依存 / native method / reflection で呼出し先が変わる処理 / 順序未固定の浮動小数 reduction / 外部サービスへの非冪等呼出し / 例外順序を保存できない処理 対象外のコードは元の逐次コードをそのまま残します。
実装状態	未実装。Go / No-Go 判定用の検体 (BigDecimal の残高推移・EC バッチ 1 本) の作成が次の作業です。

納品物

最適化されたソースだけでなく、速度と安全性の根拠を一式で出します。

• 並列化プランどこを並列化し、どこを逐次に残したか。partition key、依存グラフ、拒否した箇所とその理由。
• 同値証跡元ソース hash / 最適化ソース hash / 入力スナップショット hash / 数値規約 / 並列度別の出力 hash。
• 性能レポートfetch / compute / merge / commit / GC / 並列 overhead を分離して計測。どこが律速かが残ります。
• 逐次フォールバック問題があれば元コードへ即時復帰できる状態を保つ。

前提と限界 (2026-08-19 時点)

2026-08-17 〜 18 に独立した別エンジンによる監査を受け、指摘を全件こちらで再現しました。 崩れた主張は取り下げ、修正の経緯ごと公開しています。以下は現時点の前提です。

適用作業が要ります	掲載している速度は、並列実行部の適用が完了した状態の値です。 再ビルドだけで速くなるものではありません。 適用範囲は判定レポートで事前に確定します。
判定器の位置づけ	着眼点 (ORDER BY 全順序性・金額の型・資源規則) は実測で裏づけられていますが、 実装は着眼点にまだ追いついていません。現在の運用は 「人が再確認する前提の判定」で、自動修正・安全証明・成功報酬判定には使いません。
対象外の異常	判定が見ているのは単一スレッド内の順序依存です。 lost update・デッドロック・分離レベル異常は対象外です。
Java の速度実測	Java 本流 (Track A) は逐次実行、変換器 6 本のうち 3 本は構造的に速度を測れません。 Java の倍率実測は 0 件です (C# は 2.81×)。Java 21 の実測取得が最優先作業です。
★「偽受理ゼロ」は 一般コードの安全性ではない	旧版の入口は実質 compute(seed) → 2 次元 float 配列という専用 signature でした。 実在 Python 102,750 関数で完全適合は 0 件。つまり 意味の判定に到達する前に、形で全件が落ちていただけです。 「公式 fixture だけが通る」のも、それが規約用 kernel だったからであって、 一般コードに対する安全性の証拠ではありません。 成立しているのは規約適合 kernel における bit-exact 性 (6 言語で 0xe718490618e7f144 一致) までで、 汎用の意味 Admission はこれから構築する部分です。 上部の中心契約が指す「証明できた区間」は、現時点ではこの規約の内側を指します。
取り下げた主張	「false-safe 0」「封印レコードを課金根拠にできる」 「整数かつ総和 253 以内なら f64 は結合的」ほかを取り下げました。 全件と理由は 検証記録 に台帳として残しています。

★ 「壊れないこと」を売る製品が、自社の主張が壊れたときに黙るわけにはいきません。 取り下げた主張・監査の指摘・自作検査器に作り込んだ欠陥の記録は、すべて 開発過程・検証記録 に公開しています。

価格・ライセンス (暫定、2026-05-18 — 10,000 LOC 試算例)

導入パス	LOC	買い切り / LOC	買い切り合計	ランタイム率	ランタイム / 年	サポート
SlimeNENC (変換)	10,000	US$ 9.95	US$ 99,500	—	—	フル
PSDP (SlimeNENC 顧客)	10,000	US$ 0.00	US$ 0	2%/年	US$ 1,990	フル
PSDP 直販 (SIer / パートナー経由)	10,000	US$ 1.00	US$ 10,000	20%/年	US$ 2,000	フル (パートナー経由)
PSDP エンドユーザー直販 (30% OFF)	10,000	US$ 0.70	US$ 7,000	20%/年	US$ 1,400	FAQ のみ

上 3 経路では LOC あたりの年ランタイム費用が同水準に収束する設計、差は買い切り部分のみで SlimeNENC 変換ツールの価値に対応。 エンドユーザー直販はセルフ導入向け (FAQ のみのサポート、SI 関与なし — 実機統合支援が要る場合はパートナー経由)。

方式	Ed25519 署名 license + 3-hop air-gap activation (金融機関向け)。
license server	license.javatel.jp (AWS Lightsail、HSTS / OCSP stapling)
特許	特願 2026-046620 (経路間で契約再交渉不要)

SIer / パートナー様向け: 直販定価でご販売頂くパートナー様には、 買い切り部分に対して相応のマージンが、さらに同率が 毎年継続のランタイム購読収入に対しても適用されます。 顧客が稼働を続ける限り、年次の収入が積み重なる継続収益モデル。 具体的な tier 数字はパートナー契約の一部として登録後にご案内します (/ja/partners/)。

直販 Edition (暫定、2026-05-18 — 正式アナウンス時に変更の可能性あり)

Edition	PSDP-managed LOC 上限	買い切り (年初)	ランタイム / 年	備考
Trial	10,000	US$ 0	US$ 0 (14 日)	機能制限なし、商用不可
Individual	50,000	LOC × $1.00 (上限 $50)	LOC × $0.20	コミュニティサポート、商用可
Corporate	1,000,000	LOC × $1.00	LOC × $0.20	メールサポート、SLA 99%、audit chain export
Enterprise	unlimited	LOC × $1.00	LOC × $0.20 (上限 $1,000,000/年)	24h SLA 99.9%、3-hop air-gap activation、金融 / 医療
OEM	unlimited + 再ライセンス権	個別交渉	個別交渉	source-escrow option、組込・再販可

「PSDP-managed LOC」とは、psdp.toml で PSDP-managed と宣言した namespace / packages 配下の ソースファイル LOC 数 (cloc / tokei で計測、年初 git revision に対して算定)。 ランタイムが同値を self-report し、相互検証可能。 本表は 暫定であり、上限・最低金額・SLA tier は GA 価格発表時に改訂される可能性があります。

特許

• 特願 2026-046620 (PSDP コア / Phase-Synchronous Deterministic Parallelism)
• 特願 2026-046625 (位相同期実装、安全機構、請求項 29-32)
• 追加出願準備中 (SIMD / GPU 拡張)

関連製品

サービスとして試す (PSDP) → 資料請求 / お問い合わせ SlimeNENC ファミリー 開発過程・検証記録 他の製品を見る