Go言語は最近、ハブで繰り返し議論されてきました。 批判され 、 賞賛されました 。 Intelの私たちはGoを愛しており、このプロジェクトのオープンソース開発に関与しています。 Goも使用している場合、このすばらしい言語で最も効果的なプログラミングの内部構造と問題に興味があるなら、catにようこそ。 この記事では、Goが外部呼び出しメカニズムを実装する方法と、それがどのくらい高速に動作するかについて説明します。

goの作成者が言語を設計するときに従う主な原則は、このプロジェクトを編成することの最大のシンプルさです。 作成者は「デフォルト」で使用可能な「オーバーロード」および過剰な機能を意図的に回避するため、追加の機能はすべて、言語ユーザーが必要に応じてインストールできるユーティリティになります。 したがって、Goは単なるプラットフォームではなく、有用な標準ユーティリティのセットでもあります。 Go自体には最低限必要なものだけが含まれていますが、言語の作成者によって提供された、またはコミュニティによって作成された非常に多くの追加の便利なツールが常に利用可能です。 たとえば、標準ユーティリティにはgo vetがあります。これは、コード内の疑わしい構造をキャッチするのに役立ちます（さらにgo lint 、 errcheck 、 structcheckなどをインストールできます）。 テストユーティリティは、パッケージのテスト、 修正を自動化します-Goの新しいバージョンと変更されたAPIへの移行を支援し、既存のコードに必要な変更を加えます。 Goの作成者は、これらのツールの利便性と使いやすさの面倒をみて、それらのおかげでコードを書くことは簡単で楽しいタスクになります。

とりわけ、作成者はGoプログラムでCライブラリを使用する可能性も提供します。 これは非常に重要です。現時点では、Go-shnyパッケージはすべての場合に存在するわけではなく、ほとんどすべてがCで実装されているためです。 Goでこの豊富なCライブラリをすべて使用するために、cgoユーティリティが作成されました。 Goコードを分析し、必要に応じてGoプログラムをコンパイルするときに、指定されたフラグを使用して接続されたCコードのCコンパイラを呼び出し、CファイルとGoファイルから1つのパッケージを形成します。 その助けにより、CコードはGoに非常に簡単に統合できます（たとえば、 こちらを参照 ）

しかし、Cコールを積極的に使用するGoコードはどの程度効率的に機能するのでしょうか？ これを理解するには、Goランタイムの内部メカニズムについてもう少し学ぶ必要があります。 今後、Cコールの有効性を疑い、さらに分析を行うことができるようになるため、この知識が必要だと言います。

ランタイムの仕組み

Goにはgoroutineがあります-これらはユーザーレベルの「実行のスレッド」です-go-routineは1つのシステムスレッドのフレームワーク内で切り替えられ、それぞれが独自のスタックを持っています。 Goのマルチスレッドモデルの構成には、厳密な理論、つまり相互作用する逐次Hoareプロセス（ CSP ）の理論があり、これは並列システムの機能を正式に記述するために使用されることに注意してください。

Goは、膨大な数（数万から数十万）のgo-routineを作成できることで知られています。 これは、最初にすべてのgo-routineが作成に非常に少ないリソースを必要とするという事実のために可能です-すなわち、それらはすべて小さなスタックサイズ（2Kスタック対標準のLinux / x86-32ストリームの場合は2M）で作成されます。スタックは必要に応じて再割り当てされます。 go-routineの相互作用の手段はチャネルです。

これにより、Cコールがこのシステムにどのように適合するのかという疑問が生じます。 goルーチンの場合と同じように、C関数のニーズに対してスタックが増加しますか？ 彼女が外線電話をかけるとき、どのようにゴールーチンを計画しますか？ 最初は、これはすべて明白ではありません。
最初に、外部呼び出しを行わずに、go-routineの一般的なメカニズムを理解しましょう。 すべてがどのように機能するかを理解するために、通常、文字g 、 m、およびpで示されるGoの内部エンティティを検討します。 おそらく、go-schedulerデバイスに関する記事で誰かがそれらに精通しているでしょう。その翻訳版も入手可能です 。

gはgoルーチンのハンドル構造です。 スタックの現在の境界のデータ、プログラムカウンター、およびこのgo-routineが実行される現在のシステムスレッドのハンドルへのポインターなど、1つのgo-routineに固有のすべての情報が含まれます（ mで示されます） 。 Goルーチンは、スケジューラによって実行されます。スケジューラは、このために適切なタイミングで呼び出されます。たとえば、実行可能なGoルーチンがシステムコールまたはI / O操作を行う場合です。

Goランタイムによって作成された各システムスレッドは、構造体mによって記述されます。 Mには、ストリームの内部データが含まれます。その識別子、その中で実行されている現在のgo-routine、状態の説明フィールド（スピン、ブロック、消滅）およびその他のGo固有のフィールドがあります。 しかし、とりわけ興味深いデータがあります。これらは、ストリームに割り当てられたスタックの境界であり、「実行コンテキスト」と呼ばれるものへのポインターです。

実行コンテキストpも特別な構造です。 システムスレッドmは、goルーチンを実行するためにコンテキストを必要とします。 自身の内部で、pは実行の準備ができているgo-routineのローカルキューを格納します。 mがコンテキストp を取得すると、このコンテキストに属するローカルキューからgo-routineを実行できます。 ローカルキューが空の場合、他のpのキューからのワークスティーリングが発生します。 すべてのpが定期的にチェックするグローバルキューもあります。
通常、同時に多数のシステムスレッドが存在することを理解することが重要です。多くの場合、コンテキスト以外のものがあります。 ただし、コンテキストを持つスレッドのみがgo-routineの実行に関与できます。 コンテキストの数は、GOMAXPROCS環境変数によって設定できます。デフォルトでは、プロセッサコアの数と同じです。 コンテキストの数は固定されているため、goルーチンのセット全体は、指定された数のOSスレッドによって多重化されます。

コンテキストを導入するポイントは、異なるOSスレッド間で転送できることであり、ローカルコンテキストキューからの通常のgo-routineは違いに気付かないでしょう。 これはいつ必要になりますか？ 次に、何らかの種類のブロッキングタスクのために現在のスレッドを解放する必要がある場合。 コンテキストを渡すことができないと想像してみましょう。 次に、いずれかのgo-routineがシステムコールを行う場合、ローカルキューに残っているものはアイドル時間を意味します。 また、システムコールはブロックされる可能性があるため、go-routineは無期限にブロックされたままになる可能性があり、これは許可されません。 コンテキストを渡すことでこの問題が解決し、そのような場合でもキューからのgo-routineを実行し続けることができます。 そのため、システムコールを行う前に、コンテキストは他の空きシステムスレッドmに転送され、キューはこの新しいスレッドで妨げられることなく動作し続けます。 システムコールは元のスレッドで実行されますが、実行コンテキストはありません。

そこで、基本エンティティg、m、pを調べ、少しのシステムコールに触れました。 次に、Goでの外部呼び出しの問題について説明します。

外線発信方法

ご覧のとおり、Goでは、実行関数はC関数ではまったく珍しいものです。 したがって、外部呼び出しは、go-routineメカニズム以外の特別な方法で処理する必要があります。 しかし、Goでのシステムコールの処理についてはすでに話し始めていますが、システムコールがC関数内にある場合はどうでしょうか。 これを知ることができないため、Goの観点からの任意のC関数を処理して、その内部のシステム呼び出しが正しく機能するようにする必要があります。 したがって、Go Cコールとシステムコールの処理には、いくつかの共通点が必要です。 それらをより詳細に見てみましょうが、途中で違いに注意します。

syscallと任意のC呼び出しの両方が、別個のシステムスレッドで実行されます。

Cコールを発信するのにどのくらい時間がかかるかを事前に知ることはできません。 システムコールと同じように、ブロックされる可能性があり、他のgo-routineはこれに悩まされるべきではありません。 したがって、C呼び出しは、システム呼び出しのように、コンテキストを別のmに渡した後、常に別のスレッドで実行されます。 呼び出し時にプールに空きmがなかった場合、 mはその場で作成されます。 重要な注意：C関数とシステムコールの両方はコンテキストなしで実行されるため、GOMAXPROCSの制限に該当しません。つまり、GOMAXPROCS = 1の場合でも別のスレッドで実行されます。 このようにして、go-routinesの実行が誰によってもブロックされないことが保証されます。

また、作成されたシステムスレッドは、システムコールまたはC関数の完了後も残り、再利用でき、新しいmは常に、空きスレッドがない場合にのみ作成されることを強調します。

両方ともスタックの「スイッチ」が必要です

ご想像のとおり、go-routineスタックとOSスレッドスタックは同じものではありません。 これは、ゴルーチンがスレッドの数倍であることに加えて、各ゴルーチンのスタックサイズがプログラム中に動的に変化するという考慮事項からすでに明らかです。
実際、OSスレッドスタックに関係なく、go-routineスタックはヒープに割り当てられ、ランタイムによってサポートされます。 最初は、すべてのgo-routineは小さな2Kスタックから始まり、スタックは拡大および縮小できます。 システムスタックはシステムスレッドの最も一般的なスタックですが、m。 システムスタックの境界を格納するために、構造体mには特別なgo-routine g0があります。これは、システムスタックの境界がそのスタックとして格納されるため、特別です。 したがって、Goのシステムスタックで受け入れられている表記法： m-> g0 stack 。

システムコールとC関数は、 m-> g0スタックで機能します。 これが、起動する前に「スタックスイッチ」が必要な理由です。 C関数の場合、これはruntime.asmcgocall（）関数内で実行されます。 文字通り、次のことが起こります：

• 現在のSPゴルーチンはspecに保存されます。 構造体のフィールドm。
• SP go-routines：=このシステムスレッドのSP。

システムコールの場合、違いは、最適化の目的で、すべてがシステムスタックで実行されるのではなく、これが明示的に規定されている特定の内部関数のみであるということです（そして、切り替えはsystemstack（）関数内で行われます）。

どちらの場合も、呼び出しルーチンを現在のスレッドmにバインドする必要があります

そのため、C関数を正しく実行するには、システムで実行する必要があります
スタック。 ただし、もう1つ重要な点があります。コントロールがCコードに渡される前に、ストリームが「syshny」になり、新しいgo-routineの計画に使用できないことをランタイムに通知する必要があります。 これはruntime.LockOSThread（）関数を使用して行われます。 これにより、現在のgoルーチンが終了するまで、または現在のgoルーチンがruntime.UnlockOSThread（）を呼び出すまで、このmに他のgoルーチンが割り当てられなくなります。

システムコールまたはC関数から戻る際に多少の遅延があります

C関数またはシステムコールが完了した後、go-routineは常にすぐに実行を継続するとは限りません。 C関数自体の実行前に、コンテキストpが別のスレッドmに転送されたことを思い出してください。 ここで再びGoコードの実行に戻ります。つまり、実行を続行するには、コンテキストを（同じまたは異なる）取得する必要があります。

g-routineスケジューラの現在の実装では、最初に与えたのと同じ実行コンテキストpを取得しようとします。 これが成功した場合（たとえば、そのpが誰にも使用されておらず、アイドル状態にある場合）、作業は継続します（遅延は最小限です）。

pを取得することがすぐに不可能で、他のすべてのpもビジーである場合、goルーチンはブロックされます。 これの理由は、既存のGOMAXPROCSの制限です：同時に$ GOMAXPROCSの go- routineを実行することはできません（つまり、コンテキストがあるだけです）。 、つまり 何らかの種類のブロッキング操作を行います。 C呼び出しから戻った後、go-routineは誰かが自分の自由意志の文脈に「道を譲る」まで待たなければならないことがわかります。 外部呼び出しが頻繁に発生する場合、C呼び出しから戻るときにpが解放されるのを待つと、すべてが台無しになります。

これは、次のコードを記述すると簡単にわかります。

package main import ( "fmt" "sync" "runtime" ) func main() { runtime.GOMAXPROCS(5) var wg sync.WaitGroup wg.Add(1) go func() { defer wg.Done() work() }() for i := 0; i < 10; i++ { go spinlock() } wg.Wait() } func spinlock() { for { } } func work() { fmt.Println("I am working!") } 

ここでは、指定された制限GOMAXPROCS = 5で、無限のサイクルで動作する10のルーチンが作成され、次に画面に何かを表示する別のルーチンが作成されます。 それらがすべて作成された後、そのうち5つがコンテキストを取得して実行されます。 この例を何度か実行すると、作業が最初にコンテキストを取得して解決することに成功した状況をキャッチできます。 しかし、5つの「無限の」go-routineが実行を開始したことが判明した場合、それらはコンテキストに負けず、work（）は実行できません。

C関数呼び出し

Cコール中に発生するイベントの経過をもう一度追跡しましょう。 いくつかのC関数f（）を呼び出します。 これは、図に示す次の呼び出しシーケンスに展開されます。 実線の矢印は関数呼び出しを示し、点線は制御に戻ることを示します。



各ステップで何が起こるか見てみましょう：
ステップ1. Goルーチンを現在のmに保護する（lockOSThread（）を呼び出す）
手順2.システムスレッドのプールからmを選択し（空きmがない場合-新しいスレッドを作成する）、選択したmにコンテキストを転送する
ステップ3. Go-routineスタックをm-> g0に切り替えて、オペレーティングシステムのスレッドスタック
ステップ4. C関数fの呼び出しを準備し、関数自体を直接呼び出します。 準備は、特定のアーキテクチャに対応する呼び出し規約への縮小として理解されます（たとえば、 x86_64では 、関数の引数は対応するレジスタに格納されます）。 C関数による値の戻りも慣例により発生するため、必要に応じてキャストが行われます（x86_64では、レジスタからの戻り値がスタックに移動されます）
ステップ5. OSスレッドスタックから現在のgo-routineのスタックへの逆切り替え（ m-> curg stack）
ステップ6. Exitsyscall（）-内部では、$ GOMAXPROCSの制限に違反することなくGoコードを実行できるようになるまで、関数がブロックされます
ステップ7.実行が可能になり次第-mからgo-routineの固定を解除します（unlockOSThread（））

Goの作成者は、コールバックを作成する機能も提供することに注意してください。 コールバックは次のように発生します。Goコードから、C関数の呼び出しが行われ、引数としてGo関数へのポインターが渡されます。 プロセス内のこのC関数は、渡されたポインターに従ってGo関数を呼び出します。

少なくとも、前の部分で検討したケースは、pの待機の遅延がコールバックの有効性に大きく影響することを示唆しています。 これがなぜそうなのかを詳しく見てみましょう。 Cコールで何が起こっているかを把握しましたが、Cから内部Goコードを実行するために、次のアクションが実行されます。

1. 新しいgo-routineが作成されます
2. その後、スタックはスイッチバックされます（システムから新しいgo-routineのスタックに）
3. 新しいgo-toルーチンにはpが必要です。 したがって、外部呼び出しから戻るときと同じように、ブロックされ、一部のpが解放されるまで待機します。

したがって、コールバックの場合、Cコールからの復帰で既に考慮されている遅延（free pの期待による）に加えて、同じ性質のもう1つの遅延があります。 待機時間pがオーバーヘッドに2倍の貢献をすることがわかります。

それがうまくいくか。 オーバーヘッド

したがって、go-routinesからの外部呼び出しから生じるコストの性質をもう一度示してみましょう。

状況1. Goルーチンは、C関数から戻った後にpが解放されることを期待しています。
この状況では、心配することは何もないように思われます。 しかし、多くのgo-routineがあり、それらからのC呼び出しが頻繁に発生することを想像してみてください（たとえば、お気に入りのライブラリのラッパーを作成し、Goのすべての規範に従って、多くのgo-routineを使用してみましょう）。 複数のCコールを使用すると、これらの遅延は、まず可能性が高くなり、次に長くなります。

状況2.次の外部呼び出しで、残りのgo-routineを実行するための十分な空きスレッドがありませんでした。
この場合、新しいスレッドが強制的に作成され、実行コンテキストがスレッドに転送されます。 このため、最も単純なC関数でさえ、OSストリームを作成するオーバーヘッドと同等の大幅な遅延で実行されます。 この種の遅延は、プログラムの動作中に予測することはできません。これは、フローが必要に応じて作成されるためです。

これらのコストを評価するために、2つの可能な状況でgルーチンから空のC関数を呼び出すのにかかった時間を測定できます。
1）新しいスレッドが作成される状況。
2）既存のストリームが再利用される場合。
これが私たちがしたことです。 以下は、データを取得した簡単なプログラムです。

 package main // Run program as ./program pb=<int> // where pb means P_blocked - number of Ps to be in a spinlock. // Program prints to console time (in nanoseconds) elapsed by one C call that is done in goroutine import "fmt" import "time" import "flag" import "sync" // int empty_c_foo() {} //    import "C" func spin_lock() { for { } } func main() { var wg sync.WaitGroup wg.Add(1) pb_ptr := flag.Int("pb", 3, "number of Ps that will be in spinlock") flag.Parse() P_blocked := *pb_ptr for i := 0; i < P_blocked; i++ { // «»   go spin_lock() } go func() { // C.empty_c_foo() //   2 defer wg.Done() time1 := time.Now() C.empty_c_foo() time2 := time.Now() fmt.Println(int64(time2.Sub(time1))) }() wg.Wait() } 

パラグラフ1では、最初に呼び出された1つの空のC関数の時間を測定するだけで十分です-これが最初の外部呼び出しになるため、それが発生した時点で、プールに空きmがないことが保証されます。つまり、必要なストリームが作成されます。 ケース2では、プログラムは似ていますが、Cコールの繰り返しに対してすでに測定が行われています。最初のコールでmがすでに作成されるため、コストが大幅に削減されると予想されます。

「ロードされた」ランタイムをシミュレートするために、一定の数のgo-routineが作成され、無限のサイクルで占有されました。その数はP_spinlocked = 5、10、15、...、35で示され、そのような値ごとに100,000のプログラムが開始され、測定が行われました。 プログラムは、Intel®Xeon®CPU E5-2697 v2 @ 2.70GHzで実行されました。 48コア、パラメーターGOMAXPROCS = 40のマシンでは、マシンは排他的に使用されていました。

新しいスレッドが作成されたときのC呼び出しの実験結果

番号P_spinlocked =	5	10	15	20	25	30	35
％排出量>平均+ 3番目の偏差	0.28％	0.36％	0.31％	0.31％	0.30％	0.27％	0.28％
平均	2537	2438	2518	2534	2626	2686	2719
標準偏差	201	470	200	224	346	369	393
中央値	2512	2523	2493	2500	2540	2590	2613
最大	58182	65798	59543	58243	55700	66620	59600
最低	972	870	1011	909	1005	975	937

ストリームが既に作成されている場合のC呼び出しの実験結果

番号P_spinlocked =	5	10	15	20	25	30	35
％排出量>平均+ 3番目の偏差	0.06％	0.09％	0.10％	0.12％	0.13％	0.15％	0.16％
平均	1123	1126	1137	1172	1250	1283	1313
標準偏差	183	212	226	300	433	456	492
中央値	1086	1076	1080	1086	1099	1117	1123
最大	68461	73383	53756	49751	50581	47844	86258
最低	391	354	364	348	313	340	351

まず、ケース1とケース2のCコール期間の分布を比較します（ランタイムP_spinlocked = 35の負荷が等しい場合）。 ここに期待される結果が表示されます-新しいストリームを作成する場合、時間が長くなります。 平均値は約2倍異なり、1ケースと2ケースでそれぞれ約2600 nsと〜1200 nsです。



以下の各ケースの図は、低負荷（P_spinlocked = 5）および高負荷（P_spinlocked = 35）（排出量を除く）の期間の分布を個別に示しています。

ランタイムの負荷が徐々に増加することで、ランタイム環境の作業に関連するコストがどのように増加するかを確認できました。負荷が増加すると、平均値のスムーズなシフトが観察されます。 これは、以下のヒストグラムからも明確に見ることができます。ロードされたランタイム（P_spinlocked = 35）の場合、ヒストグラムはアンロード（P_spinlocked = 5）と比較して高い値に向かって「侵食」し、ランタイムの複雑さが一定でないことを示しますgo-routineの数。



また、両方のケースで、かなりの排出量の割合の割合（〜50,000 ns以上）があることに注意する必要があります。 （これは奇妙です。2番目のケースではストリームがすでに作成されており、大幅な遅延はないはずですが、それでも最初のケースと同じ順序の放出があります。明らかに、理由はスレッドの作成に関係しないオペレーティングシステムの機能にあります）
下のヒストグラム（y軸に沿った対数目盛）は、実行時間P_spinlocked = 10の負荷が等しい両方の場合の、外れ値を含むすべてのポイントを示しています。ここでは、取得したすべての値の外れ値のシェアを推定できます。


実験以外では、ガベージコレクターの貢献は残ります。 私たちの実験では、強制的にオフにしました。 実際の条件では、プログラムの実行を定期的に完全に停止する、非決定性の一部に寄与します（いわゆる世界停止段階）。 Go開発者は、作業を改善し、プログラムの関連する一時停止を最小限に抑えることに大きな注意を払っています。 Go 1.5では、コレクターの作業が大幅に最適化されています -完全停止の時間が10ミリ秒を超えないことが保証されています。これは非常に良いことです。

おわりに

外線通話は非常に費用がかかります。 さらに、ランタイム自体は、ガベージコレクターが無効になっている場合でも、外部呼び出しの実行で予期しない大幅な遅延を引き起こす可能性があります。ガベージコレクターが無効になっている場合、「ロード」を作成するgo-routineはメモリで動作しないため、スタックの追加を引き起こしません。 「ロード」ゴルーチンは、スケジューラーの呼び出しを引き起こす可能性のある高価な操作を行いません-つまり、それらはまだ再スケジュールされていません。 実際には、実際にロードされたgo-routineを使用すると、値の広がりが大幅に増加します。

スレッドの作成による遅延は、たとえば、プログラムの開始時にスレッドの一部を作成することで回避できます。 ただし、無料のコンテキストの待機時間は予測不能なままであり、頻繁に外部呼び出しを行うと増加するだけなので、悲しい事実を認める必要があります-gogoルーチンからのcgoの積極的な使用は、プログラムの全体的な有効性に悪影響を与え、時々それだけに頼る価値があります もちろん、大きな遅延の可能性は非常に小さいですが、ソフトリアルタイムシステムであっても、Goでの外部呼び出しの使用が問題になる可能性があります。