/* Page prose (ja) */
"FanningOutWithTaskGroup" = "# `withTaskGroup` で展開する\n\n`withTaskGroup(of:)` でグループを開き、各子が返す型を伝えます。その中で、要素ごとに（好きなだけ）`group.addTask { ... }` を呼び出し、`for await` でグループを反復して結果を読み取ります。";
"FanningOutWithTaskGroup-2" = "この形をよく読んでください。これが章の全体だからです。\n\n* `withTaskGroup(of: Double.self)` はグループを開きます。`Double` は各子が返すもの、ここでは1フレームの明るさです。\n* `group.addTask { ... }` は**子タスク**をスケジュールします。それぞれが兄弟と並行に実行され、それぞれが `Double` を返します。\n* `for await brightness in group` は結果を**完了した順に1つずつ**取り出します。グループは、子の戻り値からなる `AsyncSequence` です。\n* クロージャから `return` する値が、`await withTaskGroup(...)` 式全体の結果になります。\n\nその効果を実感するために、同じ処理を逐次的に、つまり次のフレームを始める前に各フレームを await して実行する場合と比べてみましょう。";
"FanningOutWithTaskGroup-3" = "逐次版は次のフレームを始める前に各フレームを await するので、1つあたり0.5秒の8フレームは約**4秒**かかります。上の task group 版は8つすべてを一度に開始するので、それらが重なり合い、バッチ全体が約**0.5秒**で終わります。\n\n* callout(試してみよう): 上のコードで `frameCount` を `40` に上げて再実行してみましょう。並列時間はほとんど変わりません。対照的に、40フレームに対する単純な逐次ループは20秒に近づいていくでしょう。\n\nデバイスにコアが2つしかなくても*なぜ*これが重なり合うのかに注目してください。ここでは各フレームはほとんど**待って**いて（あの `Task.sleep` はファイルを読む処理の代わりです）、[なぜ並行処理か](Why%20Concurrency.playgroundchapter/Overview) の章で見たように、待っているタスクは互いに道を譲り合います。実際の補正は CPU の処理でもあり、そこでもグループはシステムが存在するだけのコアにフレームを分散させることを可能にします。いずれにせよ、グループは独立した処理の山を1つの並行なバッチに変えます。\n\n[前へ](@previous)  |  3 / 9 ページ  |  [次へ: 結果は完了順に届く](@next)";
