WebGLを使用したGoでの並行性の視覚化

Goプログラミング言語の長所の1つは、Tony Hoar のCommunicating Sequential Processesの作業に基づいた、組み込みの並行処理サポートです。 Goは、マルチスレッドプログラミングの便利な作業のために設計されており、非常に複雑な並行プログラムを非常に簡単に構築できます。 しかし、さまざまな同時実行パターンが視覚的にどのように見えるか疑問に思ったことはありませんか？

もちろん、彼らは考えました。 何らかの方法で、私たちは皆、視覚的なイメージで考えます。 「1から100」の数字を含むものについて尋ねると、頭の中で何らかの形で即座に「見え」ます。 たとえば、1から100までのシリーズは、数字が付いた線として表示され、20度右に90度回転し、1000 +まで続きます。 そして、記憶を掘り下げて、壁に沿ったロッカールームの一番最初の幼稚園で、数字が書かれていて、数字20がちょうど角にあったことを思い出します。 あなたはおそらくあなた自身のいくつかのアイデアを持っています。 または、別のよくある例-一年中とその年の四季を想像してください-誰かがそれらを四角とみなし、その各面は季節に属し、誰かは円に、他の誰かに属します。

とにかく、GoとWebGLで基本的な同時実行パターンを視覚化する私の試みを紹介しましょう。 これらのインタラクティブな視覚化は、多かれ少なかれ、私の頭の中での見方を反映しています。 これが読者の視覚化とどれほど違うかを聞くのは面白いでしょう。


それでは、最も単純な例である「こんにちは、並行世界」から始めて、私のアプローチの概念を理解しましょう。

こんにちはコンカレントワールド

package main func main() { //     int ch := make(chan int) //     go func() { //  42   ch <- 42 }() // ,    <-ch } 

インタラクティブなWebGLデモへのリンク
ここで青い線はゴルーチンを表し、時間はY軸を「実行」します。「main」と「go＃19」を結ぶ細い青い線は、先祖と子供を示すゴルーチンの生活の始まりと終わりの印です。 赤い矢印は、チャネルにメッセージを送信するイベントを示し、送信された値は署名されています。 実際、「チャネルへの送信」と「チャネルからの読み取り」は2つの別個のイベントであり、バッファー付きチャネルとバッファなしチャネルでは動作が大きく異なりますが、これら2つのイベントを1つとしてアニメーション化します-「チャネルを介した値の送信」。 匿名ゴルーチンの名前にある文字列「＃19」は、実行中のゴルーチンの実際のIDです。 Goroutine IDを公式に認識することはできませんが（識別子が重要な役割を果たす他の同時実行モデルを作成しないように）、そのようなハッカーのケースについてはまだ可能です-これはScott Mansfield の記事「Goroutine IDs」によく書かれています。

タイマー

実際、上記の最も単純なHello、worldを使用して、単純なタイマーを作成できます。 Go標準ライブラリにはtime.Afterやtime.Tickなどの便利な関数がありますが、独自に実装してみましょう-チャンネルを作成し、goroutinを開始し、必要な時間スリープしてチャンネルに書き込み、このチャンネルを呼び出し元に返す関数を作成します。

 package main import "time" func timer(d time.Duration) <-chan int { c := make(chan int) go func() { time.Sleep(d) c <- 1 }() return c } func main() { for i := 0; i < 24; i++ { c := timer(1 * time.Second) <-c } } 

インタラクティブなWebGLデモへのリンク
いいですね しかし、先に進みます。

ピンポン

この興味深い並行性の例は、Googleの有名なSameer Ajmani Advanced Concurrency Patternsレポートから引用したものです。 もちろん、この例はあまり高度ではありませんが、Goの同時実行に精通しているだけの人にとっては、面白くて実証的であるはずです。

したがって、テーブルの役割を果たすテーブルチャネルがあり、int型変数であり、そのストローク数を格納するボールボールがあります。また、「テーブルからボールを​​取り出す」（チャネルから読み取られる）gorutinプレーヤーがあります。彼を打ち負かし（変数を増やす）、「彼をテーブルに投げ戻す」（チャンネルに書き込む）。

 package main import "time" func main() { var Ball int table := make(chan int) go player(table) go player(table) table <- Ball time.Sleep(1 * time.Second) <-table } func player(table chan int) { for { ball := <-table ball++ time.Sleep(100 * time.Millisecond) table <- ball } } 

インタラクティブなWebGLデモへのリンク
この時点で、各アニメーションで使用可能なインタラクティブなWebGLデモのリンクにもう一度注意を向けたいと思います-新しいタブで開くことにより、これらの3Dアニメーションを好きなように移動、回転、増加/減少、表示、および減速することができます/スピードアップして再起動します。

では、2つではなく3つのゴルーチンを実行しましょう。

  go player(table) go player(table) go player(table) 

インタラクティブなWebGLデモへのリンク
この例では、各プレイヤーが順番にテーブルからボールを​​取りますが、あなたは疑問に思うかもしれません-なぜ正確に、誰がこの順序を保証しますか？

ここでの答えは簡単です-Goランタイムには、チャネルから読み取る準備ができているゴルーチン用のFIFOキューが含まれているため、この順序を遵守します。 この場合、各ゴルーチンはボールをテーブルに送った直後にキューに入ります。 ただし、この動作は将来変更される可能性があり、注文に頼る価値はありません。 しかし、今のところはそうであり、3つではなく100のゴルーチンを起動しましょう。

 for i := 0; i < 100; i++ { go player(table) } 

インタラクティブなWebGLデモへのリンク
FIFOの順序がより明確になりましたね。 100万個のゴルーチンを簡単に起動できます（安価であり、大規模なGoプログラムに数十万個のゴルーチンが含まれていてもかまいません）。 他のパターンに移りましょう。

ファンイン

最も有名なパターンの1つは、いわゆるファンインパターンです。 これは、後で説明するファンアウトパターンの反対です。 つまり、 ファンインは、複数のソースから読み取り、すべてを1つのチャネルに多重化する機能です。
例：

 package main import ( "fmt" "time" ) func producer(ch chan int, d time.Duration) { var i int for { ch <- i i++ time.Sleep(d) } } func reader(out chan int) { for x := range out { fmt.Println(x) } } func main() { ch := make(chan int) out := make(chan int) go producer(ch, 100*time.Millisecond) go producer(ch, 250*time.Millisecond) go reader(out) for i := range ch { out <- i } } 

インタラクティブなWebGLデモへのリンク
ご覧のとおり、最初のプロデューサーは100ミリ秒ごとに番号を生成し、2番目のプロデューサーは250ミリ秒ごとに番号を生成し、 リーダーは両方のプロデューサーからすぐに番号を受け取ります。 実際、多重化はメイン関数で発生します。

ファンアウト

ファンインの反対は、 ファンアウトまたはワーカーパターンです。 多くのゴルーチンは1つのチャネルから読み取られ、処理のためにデータを取得して、CPUコア間で作業を効果的に分散します。 したがって、名前は「 workers 」です。 Goでこのパターンを実装するのは非常に簡単です。チャンネルをパラメーターに渡してゴルーチンのパックを実行し、このチャンネルにデータを書き込むと、Goランタイムのおかげで多重化と配信が自動的に行われます。

 package main import ( "fmt" "sync" "time" ) func worker(tasksCh <-chan int, wg *sync.WaitGroup) { defer wg.Done() for { task, ok := <-tasksCh if !ok { return } d := time.Duration(task) * time.Millisecond time.Sleep(d) fmt.Println("processing task", task) } } func pool(wg *sync.WaitGroup, workers, tasks int) { tasksCh := make(chan int) for i := 0; i < workers; i++ { go worker(tasksCh, wg) } for i := 0; i < tasks; i++ { tasksCh <- i } close(tasksCh) } func main() { var wg sync.WaitGroup wg.Add(36) go pool(&wg, 36, 50) wg.Wait() } 

インタラクティブなWebGLデモへのリンク
ここで注目したいことの1つは、並行性です。 gorutins-workersが並行して実行され、チャンネルを次々と「作業」していることに気付くのは簡単です。 このアニメーションから、ゴルーチンがこれをほぼ同時に行うこともわかります。 残念ながら、これまでのところ、ゴルーチンが実際に機能し、ブロックされているアニメーションには表示されていません。また、ここではタイムスケールはすでにエラーエラーのしきい値に近くなっていますが、具体的には、このアニメーションは4コアで実行されているプログラム、つまりGOMAXPROCS = 4 。 この問題についてもう少し詳しく検討します。

それまでの間、もっと複雑なものを試してみましょう-独自のサブワーカーを持つワーカー。

 package main import ( "fmt" "sync" "time" ) const ( WORKERS = 5 SUBWORKERS = 3 TASKS = 20 SUBTASKS = 10 ) func subworker(subtasks chan int) { for { task, ok := <-subtasks if !ok { return } time.Sleep(time.Duration(task) * time.Millisecond) fmt.Println(task) } } func worker(tasks <-chan int, wg *sync.WaitGroup) { defer wg.Done() for { task, ok := <-tasks if !ok { return } subtasks := make(chan int) for i := 0; i < SUBWORKERS; i++ { go subworker(subtasks) } for i := 0; i < SUBTASKS; i++ { task1 := task * i subtasks <- task1 } close(subtasks) } } func main() { var wg sync.WaitGroup wg.Add(WORKERS) tasks := make(chan int) for i := 0; i < WORKERS; i++ { go worker(tasks, &wg) } for i := 0; i < TASKS; i++ { tasks <- i } close(tasks) wg.Wait() } 

インタラクティブなWebGLデモへのリンク
わあ もちろん、より多くの作業者とサブワーカーを実行することもできましたが、アニメーションをできるだけ明確にするようにしました。

はるかに複雑なパターン、サブワーカーとサブワーカー、およびそれ自体がチャネルを介して送信されるチャネルがありますが、ファンアウトのアイデアは明確である必要があります。

サーバー

次の一般的なファンアウトパターンは、 serversです。 それは、ゴルーチンが動的に開始し、必要な作業を実行し、完了するという事実によって区別されます。 そして、このパターンはサーバーの実装によく使用されます-ポートをリッスンし、接続を受け入れ、goroutineを開始します。ゴルーチンは着信要求を処理し、接続をそれに渡します。この時点でさらにリッスンし、次の接続を待ちます。 これは非常に便利で、10K接続に耐える非常にシンプルな効率的なサーバーを実装できます。 次の例を見てください。

 package main import "net" func handler(c net.Conn) { c.Write([]byte("ok")) c.Close() } func main() { l, err := net.Listen("tcp", ":5000") if err != nil { panic(err) } for { c, err := l.Accept() if err != nil { continue } go handler(c) } } 

インタラクティブなWebGLデモへのリンク
この例はあまり興味深いものではありません。実際、ここでは実際に何も起こりません。 もちろん、内部には巨大な複雑さとアルゴリズムが慎重に隠されています。 「シンプルさは複雑です。」

しかし、サーバーにアクティビティを追加してみましょう。たとえば、各ゴルーチンがクライアントのアドレスを書き込むロガーを追加します。

 package main import ( "fmt" "net" "time" ) func handler(c net.Conn, ch chan string) { ch <- c.RemoteAddr().String() c.Write([]byte("ok")) c.Close() } func logger(ch chan string) { for { fmt.Println(<-ch) } } func server(l net.Listener, ch chan string) { for { c, err := l.Accept() if err != nil { continue } go handler(c, ch) } } func main() { l, err := net.Listen("tcp", ":5000") if err != nil { panic(err) } ch := make(chan string) go logger(ch) go server(l, ch) time.Sleep(10 * time.Second) } 

インタラクティブなWebGLデモへのリンク
実証的に十分ですか？ このアニメーションは、接続の数が増え、ロガーがあまり速くない場合、ロガーがすぐにボトルネックになる可能性があることを示しています（たとえば、データをシリアル化して他の場所に送信します）。 しかし、すでにわかっているファンアウトパターンを使用することでこれを解決できます。 書きましょう。

サーバー+ワーカー

ワーカーを備えたサーバーの例は、発表されたばかりのソリューションのわずかに高度なバージョンです。 彼は、いくつかのゴルーチンでロガーを開始するだけでなく、結果（たとえば、リモートサービスへの記録の結果）を使用してロガーからデータを収集します。
コードとアニメーションを見てみましょう。

 package main import ( "net" "time" ) func handler(c net.Conn, ch chan string) { addr := c.RemoteAddr().String() ch <- addr time.Sleep(100 * time.Millisecond) c.Write([]byte("ok")) c.Close() } func logger(wch chan int, results chan int) { for { data := <-wch data++ results <- data } } func parse(results chan int) { for { <-results } } func pool(ch chan string, n int) { wch := make(chan int) results := make(chan int) for i := 0; i < n; i++ { go logger(wch, results) } go parse(results) for { addr := <-ch l := len(addr) wch <- l } } func server(l net.Listener, ch chan string) { for { c, err := l.Accept() if err != nil { continue } go handler(c, ch) } } func main() { l, err := net.Listen("tcp", ":5000") if err != nil { panic(err) } ch := make(chan string) go pool(ch, 4) go server(l, ch) time.Sleep(10 * time.Second) } 

インタラクティブなWebGLデモへのリンク
ロガーのタスクを4つのゴルーチン間で効果的に分散することでサーバーを改善しましたが、ロガーがボトルネックになる可能性があることがわかりました。 数千の接続が1つのチャネルに収束します。 ゴルーチン間で多重化する前。 しかし、もちろん、これは以前のバージョンよりもはるかに大きな負荷で既に起こります。

エラトステネスのふるい

しかし、かなりファンイン/ファンアウトの実験。 より興味深い例を見てみましょう。 私のお気に入りの1つは、レポート「 Go Concurrency Patterns 」にあるゴルーチンとチャネルの「Sieve of Eratosthenes」です。 エラトステネスのふるいは、与えられた限界まで素数を見つけるための古代のアルゴリズムです。 その本質は、見つかった後続の各素数で割り切れるすべての数を順番にストライクすることにあります。 額アルゴリズムは、特にマルチコアマシンではあまり効率的ではありません。

ゴルーチンとチャネルを使用したこのアルゴリズムの実装オプションは、見つかった素数ごとに1つのゴルーチンを実行し、このゴルーチンはそれで除算された数をフィルタリングします。 ゴルーチンの最初の素数が見つかると、メインのゴルーチン（メイン）に送信され、画面に表示されます。 また、このアルゴリズムは最も効率的ではありませんが、驚くほどエレガントです。 コード自体は次のとおりです。

 // A concurrent prime sieve package main import "fmt" // Send the sequence 2, 3, 4, ... to channel 'ch'. func Generate(ch chan<- int) { for i := 2; ; i++ { ch <- i // Send 'i' to channel 'ch'. } } // Copy the values from channel 'in' to channel 'out', // removing those divisible by 'prime'. func Filter(in <-chan int, out chan<- int, prime int) { for { i := <-in // Receive value from 'in'. if i%prime != 0 { out <- i // Send 'i' to 'out'. } } } // The prime sieve: Daisy-chain Filter processes. func main() { ch := make(chan int) // Create a new channel. go Generate(ch) // Launch Generate goroutine. for i := 0; i < 10; i++ { prime := <-ch fmt.Println(prime) ch1 := make(chan int) go Filter(ch, ch1, prime) ch = ch1 } } 

アニメーションを見てみましょう。

インタラクティブなWebGLデモへのリンク
上記のリンクの3D空間でインタラクティブにねじることを忘れないでください。 私はこの例がいかに実例であるかが本当に好きで、3Dでそれを研究することはアルゴリズム自体をよりよく理解するのを助けることができます。 最初のgoroutine（ generate ）が最初の素数（2）をmainに送信し、最初のgoroutineフィルターが開始され、2、3、5、7をふるいにかけます...そして、見つかった新しい素数がmainに送信されるたびに-これは特に良いです上面図から見た。 3Dを含む美しいアルゴリズム。

GOMAXPROCS

ワーカーの例に戻りましょう。 この例をGOMAXPROCS = 4で実行したことを覚えていますか？ これは、これらすべてのアニメーションが描かれているわけではなく、これらが実際のプログラムの本当の痕跡だからです。

はじめに、記憶を更新してGOMAXPROCSを思い出しましょう。

GOMAXPROCSは、コードを同時に実行できるCPUコアの最大数を設定します

実際の作業を行うために、ワーカーのコードを少し変更しました。 プロセッサをロードするだけでなく、スリープします。 次に、それぞれ12コアの2つのプロセッサーを搭載したLinuxマシンで、変更なしでコードを実行しました-最初にGOMAXPROCS = 1で、次にGOMAXPROCS = 24で。

だから。 最初のアニメーションでは、同じプログラムが1番目のコアで実行され、2番目のアニメーションでは24コアで実行されています。


WebGLアニメーション1 WebGLアニメーション24
これらの例では、時間のアニメーションの速度は異なりますが（すべてのアニメーションの高さが一定の時間かかるようにしたかった）、違いは明らかです。 GOMAXPROCS = 1の場合、次のワーカーは、プロセッサコアが解放され、前のゴルーチンがその部分を解決したときにのみジョブを受け取ります（チャネルから読み取ります）。 24個のコアにより、ゴルーチンはほとんどすぐにタスクを解析し、高速化が実現します。

ただし、GOMAXPROCSの増加が常に生産性の向上につながるとは限らず、コア数の増加によって低下することさえあることを理解することが重要です。

ゴルーチンのリーク

並行性の世界から他に何を実証できますか？ 私の頭に浮かぶものの一つは、ゴルーチンのリークです。 過失によって発生する可能性があります 。 たとえば、ゴルーチンを起動したが、範囲外になった場合などです。

初めての（そして唯一の）ゴルーチンリークに遭遇し、恐ろしい写真が頭に浮かび 、文字通り、次の週末に迅速な監視のためにexpvarmonを書きました 。 そして今、この恐ろしい写真をWebGLで視覚化できます。

ご覧ください：

インタラクティブなWebGLデモへのリンク
それを見ることさえ痛いです:)各行はあなたのプログラムのために費やされたコンピューター資源と時限爆弾です。

並行性は並列性ではありません

並行性という言葉はしばしば「並行性」と訳されますが、これは完全に真実ではありません。 実のところ、私は良い翻訳を知りません。だから、翻訳なしでどこにでも書きます。 しかし、並行性と並行性の違いを説明するトピック自体は、ロブ・パイクによる素晴らしい名を冠した報告書を含め、 何度も 公開され ています。 まだ見ていないなら見てください。


要するに：

並行性は、並行して実行される多くのことです。
並行性は、プログラムを構成する方法です。

これらの概念は多少直交していることを理解することが重要です-並行プログラムは並列である場合とそうでない場合があります。 異なるGOMAXPROCSを使用したこの例をもう少し見ました。同じコードが1番目のコア（連続）と24番目のカーネル（並列）の両方で実行されました。

上記のリンクとレポートから多くの仮定を繰り返すことができますが、これはすでに私の前で行われています。 視覚的に表示するようにしてください。

これが並行性です。 多くのことが並行して実行されています。

インタラクティブなWebGLデモへのリンク

これが並列処理です。 さらに多くの並列部分。ただし、何も変わりません。

インタラクティブなWebGLデモへのリンク

しかし、ここにあります-並行性：


そして、ここにあります：


そして、これも並行性です。

これはどのように行われましたか？

これらのアニメーションを作成するために、 gotracerとgothree.jsの 2つのプログラムを作成しました 。 最初のものは次のことを行います：

• Goの例のソースコードのASTツリーを解析し（Goの単純な文法のもう1つ）、同時実行性に関連するイベントに特別な出力を挿入します。ゴルーチンの開始/停止、チャネルへの書き込み/読み取り、チャネルの作成
• 変更されたプログラムを起動します
• 出力を解析し、イベントとタイムスタンプを持つ特別なJSONを生成します

結果のJSONの例：


次に、 gothree.jsは豪華なThree.jsライブラリのパワーを使用して、WebGLを使用してこのデータを3Dで描画およびアニメーション化します。 それを1つのデモページに圧縮する小さなラッパーで完了です。

ただし、このアプローチは非常に限られています。 正しいトレースを取得するには、サンプルを非常に慎重に選択し、チャネルの名前を変更する必要がありました。 このアプローチでは、関数内で異なる方法で呼び出された場合、ゴルーチン間でチャネルを接続する簡単な方法はありません。 タイミングにも問題があります-コンソールへの出力には、ゴルーチンの起動、チャンネルへの書き込み、終了よりも時間がかかることがあるため、いくつかの例では、時間を挿入することで少し引き締まらなければなりませんでした（スリープの例では、アニメーションが少し間違っています）。

Vobschem何か。 それが私がまだコードを開かない主な理由です。 今、 Dmitry Vyukovの実行トレーサーで遊んでいます-チャンネルに送信されたものに関する情報は含まれていませんが、望ましいレベルの詳細を提供しているようです。 おそらく、最も詳細なトレイルを達成するためのいくつかの他の方法があるでしょう、私はさらに探求します。 アイデアがある場合は、Twitterまたはコメントでメールしてください。 このツールが最終的に、例外なくすべてのGoプログラムに適用可能な3D同時実行デバッガーに成長するのは素晴らしいことです。

この記事は元々、 リヴィウのGo Meetup（2016年1月23日） でのレポートの形式でした が、私のブログで英語で公開されました 。 HackerNewsとRedditでも 。