並列化と GPU:Amdahl・Gustafson の法則、仕事量と依存鎖、roofline モデル
対象読者: 学部の微積分と Python の基本、浮動小数点数の丸め誤差の記事、本テーマ第 1 章(乱数種と再現性)を学んだ人。並列計算や GPU のプログラミング経験は仮定しません。
前提となる記事:再現できる数値実験:乱数種・環境・設定の記録と決定性、浮動小数点数と丸め誤差:IEEE 754・標準モデル・和と Horner 法の誤差解析
0. この記事の要点
Section titled “0. この記事の要点”計算を速くしたいとき、「コアの数を倍にすれば、時間は半分になるのか」というのは素朴で大事な疑問です。実際には、順番にしかできない仕事が残ることや、データの出し入れで待たされることのせいで、倍にしても倍速くはなりません。この記事は、そうなる理由と限界を、実験の前に紙の上で見積もる道具(Amdahl の法則など)と、並列にしたときに和の末尾の桁や乱数がどうなるかを扱います。読み終えると、並列化や GPU に手を出す前に、どれくらい速くなりそうかを見積もれるようになります。
以下の要点は、記事全体の結果を先にまとめたものです。分からない言葉があっても、各節で定義から順に説明するので、そのまま読み進めて構いません。
- 逐次にしか実行できない部分の割合が の計算は、何台使っても 倍より速くなりません(Amdahl の法則)。問題の規模を台数に比例させて大きくするなら、速度向上は と台数にほぼ比例します(Gustafson の法則)。2 つは同じ量を別の基準で測ったもので、変換式 で移り合います。
- 測定した速度向上から逆算した逐次割合 (Karp–Flatt 指標)が台数とともに増えるなら、並列化のオーバーヘッドが増えています。
- 仕事量 、最長の依存鎖 の計算は、 台で ステップ以上かかり、貪欲なスケジュール(実行できる作業があれば、空いている台数の分だけ必ず実行する方針)で ステップ以下で終わります(Brent の評価)。
- 演算強度 (1 バイトあたりの浮動小数演算数)の計算の性能は を超えません(roofline モデル)。GPU などの加速器に仕事を移して得をするのは、節約できる計算時間が転送の時間を上回るときだけです。
- 配列を 個に分けて足した結果は、逐次和と 以内でしか一致しません。分割をスレッド数によらず固定すれば、結果はビット単位で再現します。
- 並列のワーカーに同じ乱数種を渡すと標本が重複し、平均の分散は 倍になりません。
SeedSequence.spawn(1 つの種から、重ならない子の種を作る NumPy の関数)で子を作って渡します。
数値実験が 1 日で終わらなくなると、多くの人はまずコア数の多い計算機や GPU を探します。ところが、16 コアの計算機に移しても 3 倍しか速くならなかった、GPU に移したらかえって遅くなった、スレッド数を変えたら結果の末尾の桁が変わった、という経験もまたよくあります。これらは実装の巧拙以前に、計算の構造から決まる上限と、浮動小数の加法の性質から説明できる現象です。
この章の目的は、並列化の前に紙の上で見積もりをするための道具をそろえることです。逐次部分の割合が分かれば Amdahl の法則が速度向上の上限を与え、依存関係の深さが分かれば Brent の評価が必要なステップ数を上下から挟み、演算数とメモリの読み書きの量が分かれば roofline モデルが「コアを増やしても速くならない」計算を見分けます。どれも証明は短く、仮定がはっきりしています。仮定がはっきりしていれば、測定がモデルから外れたときに、どの仮定が破れたのかを問うことができます。
並列化はまた、再現できる数値実験の章で扱った決定性を壊しやすい操作でもあります。和の順序が変わることと、乱数の消費の順序が変わることの 2 点について、何が保証され何が保証されないかを命題として述べます。
この章では時間の計測値を載せません。計測値は計算機ごとに違い、読者の手元で再現しないからです。速度向上はモデルの式と演算数で論じ、コードの出力は、命題が予言する挙動を見るための例にとどめます。
2. 速度向上・効率・スケーリング
Section titled “2. 速度向上・効率・スケーリング”ある計算を 台( は整数。コア・プロセス・計算ノードのいずれでもよい)で実行したときの所要時間を とする。
をそれぞれ速度向上(speedup)、効率(efficiency)という。 のうち、台数を増やしても短くならない部分の時間 の割合 を逐次部分の割合という。
問題の規模を固定して台数 を増やし、 がどう減るかを調べることを強スケーリングという。台数に比例して問題の規模を大きくし(1 台あたりの仕事を一定に保ち)、所要時間がどれだけ一定に保たれるかを調べることを弱スケーリングという。
並列化の形にも名前を付けておきます。同じ操作を配列の多数の要素に同時に適用する形をデータ並列、互いに異なる仕事を同時に進める形をタスク並列といいます。仕事が互いに独立で、結果を最後に集めるだけで済む計算(パラメータの掃引、乱数種を変えた試行、画像ごとの処理)は「恥ずかしいほど並列」(embarrassingly parallel)と呼ばれ、逐次部分は入力の配布と結果の集計だけです。
実行の単位はプロセス(定義 3.1[OS の役割])とスレッドです。プロセスはアドレス空間を別々に持ち、スレッドは 1 つのプロセスの中でアドレス空間を共有します。標準の CPython には、Python のバイトコードを同時に 1 スレッドしか実行させないロック(GIL: global interpreter lock)があるので、純粋な Python のループをスレッドで分けても速くなりません。NumPy の配列演算の多くは計算の間 GIL を手放し、内部で呼ぶ BLAS(行列やベクトルの基本演算をまとめた、高速な標準ライブラリ)は自前のスレッドを使うので、配列演算はスレッドでも並列に走ります。Python のループそのものを並列にしたいときは、プロセスを分ける(concurrent.futures.ProcessPoolExecutor)か、ループを機械語に翻訳して GIL の外で実行する(Numba などの実行時翻訳、JIT)ことになります。
3. Amdahl の法則と Gustafson の法則
Section titled “3. Amdahl の法則と Gustafson の法則”3.1. Amdahl の法則
Section titled “3.1. Amdahl の法則”AI 時代のエンジニアの生存戦略の章の一般化アムダール則(命題 3.1[AI時代のITエンジニアの生存戦略])は、作業の一部分だけが速くなるときの全体の速度向上を与えました。ここでは部分の数を増やした形で述べ直し、並列計算の法則をその系として導きます。
1 台での所要時間 が 個の部分の時間の和 ()に分かれ、 台では第 の部分が 倍速くなって になるとする。 とおくと
である( の、重み による調和平均)。とくに、逐次部分(割合 、)と並列化できる部分(割合 、)の 2 つに分かれるとき
が成り立つ( のとき右端は と読む)。左の等号は のときに成り立つ。
証明(定理 3.1)
なので で、 です。
2 つの部分の場合は で、これは 命題 3.1[AI時代のITエンジニアの生存戦略] で高速化される割合を 、速度倍率を とした式そのものです。 と から なので、分母は 以上で、 です。等号は (または )のときです。さらに から で、 なら です。
仮定 は「 台に分けた仕事は、1 台のときの 倍より速くはならない」というモデルの仮定です。実際の計算機では、分割によって 1 台あたりのデータがキャッシュに収まるようになり、 倍を超える速度向上(超線形の速度向上)が測定されることがあります。これは定理の反例ではなく、仮定が破れた場合です。
定理の読み方は単純です。 なら上限は 倍で、 でも にとどまります。効率は です。並列化できる部分をどれだけ速くしても、残りの が全体を支配するようになります。クラウドの章の拡張則(命題 5.5[クラウドコンピューティング])は、これに台数間の調整コストの項を足して、台数を増やすとかえって遅くなる領域があることを示したものでした。命令のパイプライン化で段数倍に達しない(命題 7.2[コンピュータアーキテクチャとCPUの構造])のも、段ごとの固定の遅延が「逐次部分」として残るという同じ構造です。
3.2. Gustafson の法則
Section titled “3.2. Gustafson の法則”Amdahl の法則は問題の規模を固定しています。しかし台数が増えたら、同じ問題を速く解くのではなく、同じ時間でより大きい問題(細かい格子、多い標本)を解く、という使い方のほうが普通です。このとき基準にするのは 1 台での時間ではなく、並列機での時間です。
証明(定理 3.2)
、 なので で、最初の式を得ます。
です。これを について解きます。分母を払うと 、すなわち で、(、 から )なので です。
最後に から
で、逆数をとると です。
2 つの法則は矛盾しません。違いは、逐次部分の割合を何に対して測るかだけです。Amdahl の は「1 台で走らせたときの時間」に対する割合、Gustafson の は「 台で走らせたときの時間」に対する割合で、同じ実行でも 台のほうが全体の時間が短いぶん、逐次部分の割合は大きく見えます。たとえば 台で時間 のうち逐次部分が なら で、1 台なら かかるので です。
同じ点を、もう少し詳しく述べます。同じ 1 回の実行について、逐次部分の割合を 1 台での時間に対して測ったのが 、 台での時間に対して測ったのが です。 を固定して を増やすと は に近づきます。つまり Gustafson の法則が台数に比例する速度向上を与えるのは、「問題を大きくすると並列部分だけが増え、逐次部分は増えない」という仮定のおかげです。格子を細かくすると逐次の前処理も重くなる計算では、この仮定が成り立ちません。
3.3. 測定から逐次割合を逆算する
Section titled “3.3. 測定から逐次割合を逆算する”は実測しにくい量です。逆に、測定した から「Amdahl の法則が等号で成り立つとしたら はいくらか」を逆算することはできます。
と に対し
とおく。所要時間が、逐次割合 とオーバーヘッドの割合 を使って
と書けるとき、次が成り立つ。
- 。
- であることと、、すなわち であることは同値。
- で ならば 。
証明は式変形だけです。 は、仕事を分けたことで新しく生じる余分な時間(通信、同期の待ち、負荷の偏りなど)の、1 台での時間に対する割合です。 の式から の部分を取り出すと、残りが の定数倍になることを示します。
証明(命題 3.3)
-
なので
です。 で割ると です。
-
1 から で、 は と同じです。
-
1 から です。 は について減少するので で、 から です。両辺を で割ると です。
速度向上や効率の表だけを見ていると、効率が落ちる原因が逐次部分(台数によらない)なのか、通信・同期・負荷の偏りなどのオーバーヘッド(台数とともに増える)なのかが区別できません。 を並べると、一定なら前者、増えていれば後者と読めます。対策は違います。前者なら逐次部分そのものを速くするしかなく、後者なら分割の粒度や通信の回数を見直します。
例 3.4(Amdahl・Gustafson の数値表と Karp–Flatt 指標)
3 つの式を表にします。Karp–Flatt 指標は、、 として、時間のモデル (台数に比例するオーバーヘッド)から計算した に適用します。測定値ではなく、モデルの式の値です。
# Python 3.12.14(標準ライブラリのみ)def amdahl(f, p): # S(p) = 1/(f + (1-f)/p) return 1.0 / (f + (1.0 - f) / p)
def gustafson(g, p): # 拡大速度向上 g + (1-g)p return g + (1.0 - g) * p
def karp_flatt(S, p): # e(p) = (1/S - 1/p)/(1 - 1/p) return (1.0 / S - 1.0 / p) / (1.0 - 1.0 / p)
ps = [1, 2, 4, 8, 16, 64, 256, 1024]print("Amdahl S(p) = 1/(f + (1-f)/p)")print(" f " + "".join(f"{p:>8d}" for p in ps) + " 1/f")for f in (0.01, 0.05, 0.2): print(f" {f:4.2f} " + "".join(f"{amdahl(f, p):8.2f}" for p in ps) + f"{1/f:8.1f}")print("Gustafson g + (1-g)p")for g in (0.01, 0.05, 0.2): print(f" {g:4.2f} " + "".join(f"{gustafson(g, p):8.2f}" for p in ps))
# Karp–Flatt: 時間のモデル T(p) = f + (1-f)/p + c(p-1)(T(1) = 1)print("Karp-Flatt e(p) (f = 0.05)")print(" c " + "".join(f"{p:>8d}" for p in ps[1:]))for c in (0.0, 0.001): row = [] for p in ps[1:]: T = 0.05 + 0.95 / p + c * (p - 1) row.append(karp_flatt(1.0 / T, p)) print(f" {c:5.3f} " + "".join(f"{e:8.3f}" for e in row))Amdahl S(p) = 1/(f + (1-f)/p) f 1 2 4 8 16 64 256 1024 1/f 0.01 1.00 1.98 3.88 7.48 13.91 39.26 72.11 91.18 100.0 0.05 1.00 1.90 3.48 5.93 9.14 15.42 18.62 19.64 20.0 0.20 1.00 1.67 2.50 3.33 4.00 4.71 4.92 4.98 5.0Gustafson g + (1-g)p 0.01 1.00 1.99 3.97 7.93 15.85 63.37 253.45 1013.77 0.05 1.00 1.95 3.85 7.65 15.25 60.85 243.25 972.85 0.20 1.00 1.80 3.40 6.60 13.00 51.40 205.00 819.40Karp-Flatt e(p) (f = 0.05) c 2 4 8 16 64 256 1024 0.000 0.050 0.050 0.050 0.050 0.050 0.050 0.050 0.001 0.052 0.054 0.058 0.066 0.114 0.306 1.074検算. (a) 、 は手計算で で、表と一致します。どの行も を超えていません(定理 3.1)。(b) 、 は です。(c) の行は で一定(命題 3.3 の 2)、 の行は 1 の式 に一致し( で )、台数とともに増えています。 で になるのは、、つまり 1 台より遅くなっていることを表します。
4. 仕事量と依存鎖:Brent の評価
Section titled “4. 仕事量と依存鎖:Brent の評価”Amdahl の法則の は、計算のどこが「逐次」なのかを問いません。依存関係の構造から速度向上の上限を導くには、計算を有向グラフで表します。
有限個の単位時間の作業を頂点とし、作業 の結果を作業 が使うときに辺 を引いた、閉路のない有向グラフを計算グラフという。頂点の数 を仕事量(work)、有向道に含まれる頂点の数の最大値 を最長の依存鎖の長さ(span、深さ)という。 台でのスケジュールとは、各頂点 に実行するステップの番号 を割り当てる写像で、辺 があれば 、同じ番号の頂点は 個以下、という条件を満たすものをいう。使うステップの数の最小値を と書く。
仕事量 、最長の依存鎖の長さ の計算グラフと整数 について
が成り立つ。右の不等式は、各ステップで「前提の作業がすべて済んでいる未実行の作業」を、 個以上あれば 個、なければ全部実行する貪欲なスケジュールで達成される。
下界は、「1 ステップで 個までしか進められない」ことと「依存の鎖は順番にしか進められない」ことから直ちに出ます。上界の証明の方針は次のとおりです。貪欲なスケジュールのステップを、 個すべてを使えたステップ(満杯)と、使い切れなかったステップ(不足)に分けます。満杯のステップは多くても 回です。不足のステップでは、実行できる作業をすべて実行するので、残りの作業の依存鎖が必ず 1 つ短くなり、不足のステップは 回までしかありません。両者を足したものが上界です。以下の証明に出てくる「源点」は、まだ実行していない作業のうち、前提となる作業がすべて済んでいるもの、つまり今すぐ実行できる作業のことです。
証明(命題 4.2)
下界. 1 ステップで実行できる頂点は 個以下なので、 ステップで実行できる頂点は 個以下で、 です。また、 個の頂点を含む有向道 をとると、スケジュールの条件から で、これらは相異なる正の整数なので です。よって です。
上界. 貪欲なスケジュールを考えます。ステップ の開始時点で未実行の頂点が誘導する部分グラフを 、 の有向道に含まれる頂点の数の最大値を とします( はもとのグラフで )。頂点 の前提がすべて済んでいることは、 に入る辺の始点が に無いこと、つまり が の中で入る辺をもたないこと( の源点であること)と同じです。 が空でなければ源点があります。頂点から入る辺を逆向きにたどり続けると、閉路がないので同じ頂点に戻らず、頂点は有限個なので、入る辺をもたない頂点で止まるからです。したがって未実行の頂点がある限り、各ステップで少なくとも 1 個が実行され、スケジュールは有限ステップで終わります。辺 があるとき、 は が実行された後のステップで初めて源点になるので、 も満たされます。
ステップを 2 種類に分けます。 個を実行するステップを満杯のステップ、 個未満(源点の全部)を実行するステップを不足のステップと呼びます。
満杯のステップは 1 回につき 個の頂点を実行するので、その回数は 以下です。
不足のステップでは を示します。 は から源点をすべて除いたグラフです。 の有向道 を任意にとると、 は の源点ではないので、 の中に辺 をもつ頂点 があります。閉路がないので は のどれとも異なり、 は の有向道で 個の頂点を含みます。よって で、 です。満杯のステップでは は の部分グラフなので です。、 なので、不足のステップは 回以下です。
合わせて、貪欲なスケジュールのステップ数は 以下で、 はそれ以下です。
速度向上に直すと、 なので です。 は台数をいくら増やしても超えられない上限で、計算の並列度と呼ばれます。上界の側は、台数が並列度より十分小さければ()、 で、ほぼ台数倍の速度向上が達成できることを言っています。
例 4.3(逐次和と対ごとの和の依存鎖)
個の数の和を考えます。どの計算方法でも加算は 回なので です。
逐次和 では、各加算が直前の加算の結果を使うので で、並列度は です。何台あっても速くなりません。
対ごとの和(配列を半分に分けて、それぞれの和を足す)では、 個の和の依存鎖の長さ は 、 を満たします(大きいほうの半分が長い)。 なら なので、 についての帰納法で です。命題 4.2 から、 台で ステップ以下で終わります。、 なら 以下で、下界 とほとんど差がありません。
同じ 回の加算でも、括弧の付け方で並列度が から の程度まで変わります。その代わり、括弧を付け替えると丸めの入り方が変わり、結果のビット列は一般に変わります(§6)。
5. メモリ帯域と加速器:roofline モデル
Section titled “5. メモリ帯域と加速器:roofline モデル”5.1. 演算強度と性能の上限
Section titled “5.1. 演算強度と性能の上限”コアを増やしても速くならない計算のもう 1 つの典型は、演算ではなくメモリの読み書きが律速している計算です。
ある計算が行う浮動小数演算の回数を 、その間に主記憶とプロセッサ(キャッシュ)の間で転送されるデータの量を バイトとする。 を演算強度(arithmetic intensity)という。単位は演算数/バイトである。
1 秒あたり高々 回の浮動小数演算を行え(ピーク演算性能)、主記憶との間で 1 秒あたり高々 バイトを転送できる(メモリ帯域)計算機で、演算数 、転送量 、演算強度 の計算を時間 で実行したとする。このとき性能 は
を満たす。2 つの上限が一致する演算強度 より が小さい計算では、上限は で、 によらない。
証明(命題 5.2)
時間 の間に行える演算は 回以下なので 、転送できるデータは バイト以下なので です。前者から 、後者から で です。 なら なので です。
図や例で使う GFLOP/s は、1 秒あたり 回の浮動小数演算を表す単位です。
命題は自明に近いのですが、使い道ははっきりしています。 の計算では、コアを増やして を上げても上限 は動きません。メモリ帯域は同じソケットのコアが共有するからです。速くするには を上げる、つまり同じ演算数をより少ないメモリ転送で行うように計算の順序を組み替えるしかありません。
例 5.3(行列ベクトル積と行列積の演算強度)
倍精度(1 要素 8 バイト)の 行列について、演算数と転送量を数えます。転送量は「キャッシュに収まるデータは 1 回読めば使い回せ、収まらないデータは使うたびに主記憶から読む」という単純なモデルで数えます。 は行列全体( バイト)がキャッシュに収まらないほど大きく、長さ のベクトル数本( バイトずつ)は収まるとします。
行列ベクトル積 。乗算 回と加算 回で です。 の各要素を 1 回読み()、 を読み を読み書きする()ので 、 です。 の要素は 1 回ずつしか使わないので、順序をどう工夫しても は を超えません。
行列積 、ブロック化なし。 を の三重ループで計算します。 です。 の第 行は を動かす間キャッシュに残りますが、 の第 列は ごとに別の バイトで、 全体は収まらないので、 の組ごとに読み直します。 で、 です。
行列積、ブロック化あり。 を の倍数とし、行列を のブロックに分けて をブロック単位で行います。 は 3 つのブロック( バイト)がキャッシュに収まるように選びます。 の組は 個で、1 組につき と を読み( バイト)、乗算 回と加算 回を行います。 は を動かす間キャッシュに置き、 ごとに 1 回読んで 1 回書きます( バイト)。合計は
です。演算強度は から に上がります。 なら です。
図の仮の計算機( GFLOP/s、 GB/s、)では、命題 5.2 の上限は、行列ベクトル積とブロック化なしの行列積で GFLOP/s(ピークの )、ブロック化した行列積で GFLOP/s です。最適化された BLAS の行列積が、自分で書いた三重ループより桁違いに速い主な理由がこれです。行列積を自分で書かない、というのが実務上の結論です。
5.2. 加速器に仕事を移す損得
Section titled “5.2. 加速器に仕事を移す損得”GPU は多数の演算器と専用のメモリをもつ加速器です。NumPy と同じ書き方で配列を GPU の上に置いて計算するライブラリ(CuPy など)を使うと、配列演算を GPU に移せます。ただし配列は、計算機本体(ホスト)のメモリと GPU(デバイス)のメモリの間を転送しなければなりません。
ホストで時間 かかる計算を、同じ計算を 倍の速さで行う加速器に移すとする。移すにはデータを 単位だけ転送する必要があり、転送には 1 単位あたり時間 と、データ量によらない固定の時間 (呼び出しと同期の待ち)がかかるとする。このとき、加速器に移したほうが所要時間が短くなることは
と同値である。とくに なら決して得にならず、 がどれだけ大きくても なら得にならない。
証明(命題 5.4)
加速器に移したときの所要時間は です。これが より小さいことは、 を移項して と同じです。 なら左辺は で不等式は成り立ちません。 のとき なので左辺は より小さく、 なら不等式は成り立ちません。
小さい配列で GPU が遅い理由は、この式から読み取れます。要素ごとの演算(、、 は要素数)では、条件は です。括弧の中が正でも、 が より小さければ固定の時間 を取り返せません。括弧の中が負(1 要素の計算より 1 要素の転送のほうが高くつく)なら、 をいくら大きくしても損です。一方、行列積のように が 、 が に比例する計算は、 が大きくなるほど有利になります。
実務での対処は、転送の回数を減らすことです。配列を一度デバイスに置いたら、一連の計算をデバイスの上で済ませ、最後の結果(多くはスカラーか小さな配列)だけをホストに戻します。ループの中でホストとデバイスを往復させると、 を反復のたびに払うことになります。
6. 並列の和はどこまで一致するか
Section titled “6. 並列の和はどこまで一致するか”配列の和を 個のスレッドで計算すると、各スレッドが担当分の部分和を作り、最後に 個の部分和を足します。これは逐次和とは別の括弧づけなので、再現性の章で示したとおり結果は一般に変わります。変わる幅には上界があります。
次の定理のねらいは 2 つです。1 つめは、スレッド数を変えて結果が変わったとき、それが丸めの差で説明できる範囲かを判定する基準を作ることです。上界の は §0 の事前知識で触れた、 回の加算で生じる相対誤差の上限を表す量で、再現性の章の結果をそのまま使います。2 つめは、分割の仕方を決めておけば結果がビット単位で同じになることを示すことです。
定理 6.1(部分和に分けた和の差の上界と、分割の固定による再現)✓
()を浮動小数点数、 を単位丸めとし、、 とする。添字の集合 を空でない 個の組に分け、各組の和を浮動小数の加算で(任意の順序・任意の括弧づけで)計算し、得られた 個の部分和を浮動小数の加算で(任意の順序・任意の括弧づけで)足した結果を とする。逐次和の結果を とする。どの計算でもオーバーフローとアンダーフローが起きないならば、次が成り立つ。
- 。
- 組への分け方、各組の中の加算の順序と括弧づけ、部分和を足す順序と括弧づけがすべて同じ 2 回の実行は、加算が同じ丸めの方向で正しく丸められる限り、どの加算をどのスレッドがいつ実行したかによらず、同じ浮動小数点数を返す。
証明(定理 6.1)
-
各組の和の計算は、その組の を葉とし、内部の頂点が浮動小数の加算である二分木で表されます。部分和を足す計算は、 個の部分和を葉とする二分木です。後者の葉に前者の木を差し込むと、 を葉とし、 個の加算を内部の頂点とする 1 つの二分木になります。これは再現性の章の意味での の和の木(定義 3.2[再現できる数値実験])で、 はその計算結果です。 も、添字の順に左から括弧を付けた和の木(高さ の一本道の木)の計算結果です。同じ の 2 つの和の木の計算結果の差は 以下(定理 3.4[再現できる数値実験])なので、主張を得ます。
-
正しく丸められる加算の結果は、厳密な和 を決まった方向に丸めた値で(定義 2.2[浮動小数点数と丸め誤差])、2 つの入力 だけで決まります。1 の二分木の各頂点の値が、2 回の実行で一致することを、頂点の高さ(葉までの最長の道の長さ)についての帰納法で示します。高さ の頂点は葉で、値は入力 そのものなので一致します。高さ の頂点の値は、2 つの子(高さ 以下)の値の加算の結果で、子の値は帰納法の仮定から 2 回の実行で一致するので、この頂点の値も一致します。仮定から 2 回の実行の二分木は同じなので、根の値、すなわち結果が一致します。どのスレッドがいつ計算したかは、二分木にも入力にも現れません。
1 は「スレッド数を変えたら結果が変わった」ときの判定規則を与えます。差がこの上界の内側なら丸めの差として説明がつきます。上界を超えていたら、和の順序ではない別の原因(競合状態、初期化されていない変数、担当範囲の重複や抜け)を疑います。上界 は最悪の場合の評価で、実際の差はずっと小さいのが普通です。対ごとの和どうしなら、定理 5.2[浮動小数点数と丸め誤差] の を使ったより小さい評価ができます。
2 は対処法を与えます。多くの並列ライブラリは、既定ではスレッド数に応じて分割を決めるので、スレッド数を変えると二分木が変わります。分割を「長さ のブロックごと」のようにスレッド数によらない規則で決め、部分和を番号順に足せば、何スレッドで実行しても同じビット列になります。その分、スレッド数に合わせた最適な分割はできなくなります。
例 6.2(分割数を変えた和と、分割を固定した和)
乱数種を固定して作った 個の binary64 の数(大きさが から に散らばる)を、 個の連続した区間に分けて部分和を作り、部分和を番号順に足します。プロセスやスレッドは起こさず、分割だけを再現しています(定理 6.1 の 2 から、結果は実際に並列で実行した場合と同じです)。正しく丸めた和は math.fsum で求めます。
# Python 3.12.14 / NumPy 2.5.2import mathimport numpy as np
rng = np.random.default_rng(20261008)n = 10**6x = rng.standard_normal(n) * 10.0 ** rng.integers(-8, 9, size=n)
def seq_sum(a): # 逐次和(左から 1 つずつ) s = 0.0 for v in a.tolist(): s += v return s
exact = math.fsum(x) # 正しく丸めた和sum_abs = math.fsum(np.abs(x))u = 2.0 ** -53gamma = (n - 1) * u / (1 - (n - 1) * u)bound = 2 * gamma * sum_abss1 = seq_sum(x)print(f"n = {n}, Σ|x_i| = {sum_abs:.6e}, 2γ_(n-1)Σ|x_i| = {bound:.3e}")print(" p p 個の部分和を足した結果 逐次和との差 fsum との差")for p in (1, 2, 4, 8, 16): edges = [n * k // p for k in range(p + 1)] parts = [seq_sum(x[edges[k]:edges[k + 1]]) for k in range(p)] s = seq_sum(np.array(parts)) print(f"{p:3d} {s:.17e} {abs(s - s1):.3e} {abs(s - exact):.3e}")
# 分割を固定する: ブロック長 4096(ワーカー数によらない)、部分和は番号順に足すB = 4096nblocks = (n + B - 1) // Bdef fixed_blocks(workers): parts = [None] * nblocks for w in range(workers): # ワーカー w の担当は j ≡ w (mod workers) for j in range(w, nblocks, workers): parts[j] = seq_sum(x[j * B:(j + 1) * B]) return seq_sum(np.array(parts))vals = [fixed_blocks(w) for w in (1, 2, 4, 8, 16)]print("固定ブロック:", [v.hex() for v in vals])print("すべて同じビット列:", len({v.hex() for v in vals}) == 1)n = 1000000, Σ|x_i| = 5.249892e+12, 2γ_(n-1)Σ|x_i| = 1.166e+03 p p 個の部分和を足した結果 逐次和との差 fsum との差 1 -1.97246295270851440e+10 0.000e+00 5.150e-04 2 -1.97246295270854721e+10 3.281e-04 1.869e-04 4 -1.97246295270855408e+10 3.967e-04 1.183e-04 8 -1.97246295270857315e+10 5.875e-04 7.248e-05 16 -1.97246295270857353e+10 5.913e-04 7.629e-05固定ブロック: ['-0x1.25eb7d85c57b7p+34', '-0x1.25eb7d85c57b7p+34', '-0x1.25eb7d85c57b7p+34', '-0x1.25eb7d85c57b7p+34', '-0x1.25eb7d85c57b7p+34']すべて同じビット列: True検算. (a) 分割数 を変えると結果は有効数字の 15 桁目から変わり、逐次和との差は から です。上界 の内側にあり、上界より 6 桁以上小さい値です。(b) 上界の値は手計算でも確かめられます。、これに を掛けて です。(c) fsum との差(真の丸め誤差)も同じ程度の大きさで、この例では が大きいほうがおおむね小さくなっています。部分和に分けると、足し込まれる側の値が小さくなり、1 回の丸めの絶対的な大きさが減る、と説明できます。(d) ブロック長を固定した和は、担当の割り振りを 1・2・4・8・16 通りに変えても同じビット列でした。
7. 並列の乱数:種の渡し方
Section titled “7. 並列の乱数:種の渡し方”Monte Carlo 法は「恥ずかしいほど並列」な計算の代表です。 個のワーカーがそれぞれ 個の標本を作り、平均を集めます。このとき各ワーカーに渡す乱数種を誤ると、台数を増やした意味がなくなります。
次の命題は、平均の分散(ばらつき)が、ワーカー間の相関によってどう変わるかを計算します。ワーカーどうしが無相関なら分散は台数に反比例して減り、同じ列を使うと台数を増やしても減らない、というのが結論です。証明は、和の分散を各項の分散と共分散の和に分けて数えるだけです。
(、)を、平均 、分散 の確率変数とし、各 について は互いに無相関とする。(ワーカー の標本平均)、(全体の標本平均)とおく。
- 定数 があって、すべての で ならば
- ワーカーどうしが無相関()なら 。
- すべてのワーカーが同じ列を使う(すべての で )なら で、2 の 倍である。
証明(命題 7.1)
分散の基本性質(命題 5.3[確率変数と期待値])の 2 と 4 を使います。まず各 について、 が互いに無相関なので 4 の共分散の項は消え、
です。
-
同じ性質の 4 を に使うと、 の組は 個あるので
で、 はこれを で割ったものなので、2 から で割って主張の式を得ます。
-
1 で とします。
-
仮定から がすべての で成り立つので で、 です(このとき なので、1 で とした式とも一致します)。
擬似乱数生成器の出力列は種で一意に決まります(命題 5.2[再現できる数値実験])。したがって、すべてのワーカーに同じ種を渡すと 3 の状況がそのまま起こります。 個の標本を作ったつもりで、実質は 個です。さらに悪いことに、 個が独立だとして標準誤差を と計算すると、真の標準誤差 の 倍に過小評価します。結果は「誤差棒の小さい、精度の高い推定」に見えます。
プロセスを fork(実行中のプロセスのメモリをそのまま複製して、子プロセスを作る方式)で複製する方式では、親プロセスで作った生成器の状態がそのまま子に複製されるので、種を明示的に渡していなくても同じことが起こります。種を seed + j のように連番で作るのも、生成器によっては列の間に相関が残るので勧められません。NumPy では SeedSequence.spawn で、1 つの種から互いに独立とみなせる子の種を作って渡します。子の列がなぜ重ならないとみなせるのか(ストリームの分け方の理論)は、擬似乱数生成器そのものを扱う章に譲り、ここでは使い方だけを示します。
例 7.2(SeedSequence.spawn の子を渡す雛形と、同じ種を渡した場合)
単位正方形の一様乱数が 4 分円に入る割合から を推定します。8 個の仕事(それぞれ標本 個)をプロセスプールに渡します。
# Python 3.12.14 / NumPy 2.5.2from concurrent.futures import ProcessPoolExecutorimport numpy as np
M = 100_000 # ワーカー 1 つあたりの標本数
def worker(seed): """単位正方形の一様乱数で π/4 を推定する。戻り値は (的中数, 最初の乱数)""" rng = np.random.default_rng(seed) xy = rng.random((M, 2)) hits = int(np.count_nonzero((xy ** 2).sum(axis=1) < 1.0)) return hits, float(xy[0, 0])
def run(seeds, workers): with ProcessPoolExecutor(max_workers=workers) as ex: return list(ex.map(worker, seeds)) # map は入力の順に結果を返す
if __name__ == "__main__": p = 8 good = run(np.random.SeedSequence(20261008).spawn(p), workers=4) again = run(np.random.SeedSequence(20261008).spawn(p), workers=2) bad = run([20261008] * p, workers=4) # 誤り: 全員に同じ種 for name, res in (("spawn の子", good), ("同じ種", bad)): hits = [r[0] for r in res] print(f"{name}: 的中数 = {hits}") print(f" 異なる的中数 = {len(set(hits))} 通り, π の推定 = {4 * sum(hits) / (p * M):.5f}") print("ワーカー数 4 と 2 で同じ結果:", good == again) print("同じ種のときの最初の乱数:", sorted({r[1] for r in bad}))spawn の子: 的中数 = [78330, 78433, 78746, 78457, 78764, 78605, 78959, 78272] 異なる的中数 = 8 通り, π の推定 = 3.14283同じ種: 的中数 = [78552, 78552, 78552, 78552, 78552, 78552, 78552, 78552] 異なる的中数 = 1 通り, π の推定 = 3.14208ワーカー数 4 と 2 で同じ結果: True同じ種のときの最初の乱数: [0.12563646004385953]検算. (a) 同じ種を渡した 8 個の仕事は、的中数も最初の乱数もすべて同じで、同じ標本を 8 回数えただけです。(b) 1 個の標本(的中なら 、外れなら )の標準偏差は () なので、標準誤差は、独立な 個なら 、実質 個なら です(命題 7.1 の 2 と 3。比は )。spawn の子の推定の誤差は で、標準誤差 と矛盾しません。(c) 同じ種の推定 はこの 1 回ではたまたま に近い値ですが、誤差の大きさを と報告すれば、 倍の過小評価です。1 回の結果の近さから方法の良し悪しは判断できません。(d) 子の種を仕事の番号に結びつけ、map が入力の順に結果を返すので、ワーカー数を 4 から 2 に変えても結果のリストは一致します。乱数の消費の順序がプロセスの実行順に左右されないからです。
弱スケーリングの観点からも、Monte Carlo 法は並列に向いています。標準誤差を半分にするには標本を 4 倍にする必要があり、それには台数を 4 倍にして同じ時間だけ走らせればよく、逐次部分は種の配布と結果の集計だけです。定理 3.2 の がほぼ の計算です。
8. 実務の作法
Section titled “8. 実務の作法”まず測る。 並列化の前に、プロファイラ(標準ライブラリの cProfile など)で時間のかかっている箇所を特定します。定理 3.1 から、全体の を占める部分をいくら並列にしても 倍が上限です。逐次部分を先に速くする(Python のループを配列演算に直す、同じ計算の繰り返しをやめる)ほうが、たいてい効果が大きく、再現性も損ないません。
スレッドの掛け算を避ける。 NumPy が呼ぶ BLAS は既定でコア数だけスレッドを使います。その上でプロセスを 個起こすと、スレッドの総数は コア数になり、コアの取り合いで文脈の切り替え(定義 3.2[OS の役割])が増えて、1 プロセスのときより遅くなることがあります。命題 3.3 の が増える典型的な原因です。プロセスで並列にするときは、環境変数 OMP_NUM_THREADS、OPENBLAS_NUM_THREADS、MKL_NUM_THREADS を 1 にして BLAS を 1 スレッドにし、実行記録にスレッド数を残します。
大きな配列をプロセス間で渡さない。 プロセスはアドレス空間が別なので、引数と戻り値は直列化(データをバイト列に変換すること)して複製されます。命題 5.4 と同じ損得勘定()がここでも成り立ちます。ワーカーには配列ではなく「種と設定」や「ファイル名と範囲」を渡し、配列はワーカーの中で作るか読みます。戻り値は集計に必要な小さな量にします。どうしても共有するなら共有メモリ(multiprocessing.shared_memory)かメモリマップしたファイルを使います。
JIT が効く形と効かない形。 Numba のような実行時翻訳は、数値の配列に対する単純なループ(添字の計算と四則演算)を機械語にします。効くのは、配列演算に直しにくい逐次的な漸化式や、要素ごとに条件分岐があるループです。Python のオブジェクト(辞書、文字列、任意のクラス)を扱うループには効きません。並列化の指定で和の順序が変わる点は §6 と同じです。
GPU と精度。 CuPy の配列の既定の型は NumPy と同じ倍精度ですが、GPU 向けに書かれたコード(とくに深層学習の枠組み)は単精度 float32 を既定にしていることが多く、単精度のほうが大幅に速い GPU もあります。単精度の単位丸めは なので、必要な桁数が単精度で足りるかどうかは精度の選び方の章の手順で先に見積もります。GPU の縮約演算(和、内積)は並列に行われるので、ホストの逐次和とは 定理 6.1 の範囲で異なります。
チャンクの大きさと負荷の偏り。 仕事を細かく分けすぎると 1 件ごとの受け渡しのコストが効き、粗すぎると、重い仕事を引いたワーカーだけが遅れて他が待つことになります。仕事の所要時間にばらつきがあるときは、細かめのチャンクを動的に配るほうが偏りを吸収できます。ただし動的に配ると、どのワーカーがどの仕事を処理したかが実行ごとに変わります。
結果を集める順序を固定する。 完了した順に結果を足すと、和の順序が実行ごとに変わります。結果は仕事の番号をキーにして保存し、番号順に集計します(定理 6.1 の 2)。乱数の種も仕事の番号から決めます(例 7.2)。これで「どのワーカーが、いつ処理したか」が結果に入らなくなります。数日かかる計算では、これに中断と再開が加わります。長時間ジョブの管理の章で扱います。
逐次部分の割合が の計算について、定理 3.1 の等号が成り立つとする。(i) 速度向上 を得るのに必要な台数を求めてください。(ii) 速度向上 は有限の台数では得られないことを示してください。
解答
(i) から 、 です。効率は です。
(ii) 有限の では なので で、 です。 でも 、 台が必要です。
演習 9.2標準
ある計算の速度向上を測ったところ 、、 でした。Karp–Flatt 指標 を計算し、効率の低下の原因について何が言えるかを述べてください。
解答
、、 です。
は とともに増えています。所要時間を 命題 3.3 の形に書くと、3 からオーバーヘッドの割合は です。効率の低下は逐次部分だけでは説明できず、台数とともに増えるコスト(通信、同期、スレッドの取り合い、負荷の偏り)があります。もし が で一定だったなら、 は になっていたはずです。
演習 9.3標準
行列とベクトルの積を、各行の内積の和を対ごとの和で計算するとします。乗算と加算をそれぞれ単位時間の作業として、仕事量 と最長の依存鎖の長さ を求め、、 のときのステップ数の下界と上界を 命題 4.2 から求めてください。
演習 9.4標準
仮の数値で考えます。ホストは の行列積(演算数 )を毎秒 演算の速さで計算し、加速器はその 倍の速さです。転送するのは 3 つの行列( バイト)で、転送は 1 バイトあたり 秒、固定の時間は 秒とします。 と のそれぞれで、加速器に移すと得かどうかを 命題 5.4 で判定してください。
解答
秒、 なので左辺は 秒、右辺は 秒です。
: 左辺 、右辺 。左辺のほうが小さく、損です。ホストで 秒で終わる計算に、固定の時間だけで 秒を払うことになります。
: 左辺 、右辺 。左辺のほうが大きく、得です。所要時間は 秒から 秒になり、約 倍です。加速器そのものは 倍速いのに、全体では 倍にとどまります。転送が 定理 3.1 の逐次部分の役をしています。
- G. M. Amdahl, “Validity of the single processor approach to achieving large scale computing capabilities”, AFIPS Conference Proceedings 30 (1967), 483–485.
- J. L. Gustafson, “Reevaluating Amdahl’s law”, Communications of the ACM 31 (1988), 532–533. doi:10.1145/42411.42415
- A. H. Karp, H. P. Flatt, “Measuring parallel processor performance”, Communications of the ACM 33 (1990), 539–543. doi:10.1145/78607.78614
- R. P. Brent, “The parallel evaluation of general arithmetic expressions”, Journal of the ACM 21 (1974), 201–206. doi:10.1145/321812.321815
- S. Williams, A. Waterman, D. Patterson, “Roofline: an insightful visual performance model for multicore architectures”, Communications of the ACM 52 (2009), 65–76. doi:10.1145/1498765.1498785
- N. J. Higham, Accuracy and Stability of Numerical Algorithms, 2nd ed., SIAM, 2002 — Chapter 4(和の計算の誤差解析)。
- NumPy のドキュメント「Parallel random number generation」 https://numpy.org/doc/stable/reference/random/parallel.html
執筆: Claude Code(Opus 5.5)、Claude Code(Sonnet 5.5)・監査 2 回(Claude Code)・最終 2026-10-12
この記事の誤りを報告する ・運営: 夢現技研合同会社 ・料金 ・利用条件 ・特定商取引法に基づく表記
© 2026 夢現技研合同会社 ・コード例は MIT ライセンスです。