40年の俳優のモデル

俳優のモデルに基づいて構築された高負荷のシステム-これが今日のトレンドです。 ハブに関する記事の不完全なリストがあります。ここでは、ある程度、このモデルまたはその実装の1つが言及されています。たとえば、 1、2、3、3、4、5、6、7です。 俳優に関するウィキペディアの良い記事があります。 残念ながら、それを読んだ後、私はまだ多くの質問があり、その答えは元のソースでしか見つけることができませんでした。 このレビューの結果をあなたの注意を喚起したいと思います。

アクターモデルとは何ですか？

アクターは一連のプラクティス、開発方法論、アーキテクチャパターン、マーケティングの動きですか？



私の大学のコースでは、多くの人と同様に、計算可能性の概念はチューリングおよびポストマシンによって定義されました。 マシンには状態があります-テープ内のすべてのセルの値のセットです。 計算プロセスは一連のマシンステップであり、それぞれが状態を変更します。 マシンの各ステップは、1つの不可分なアクション（操作）のパフォーマンスです。 これを従来の計算モデルと呼びます。



このような計算の解釈は、1つの同じ時点で1つの原子操作のみを実行できる場合、グローバル時間の概念につながります。 このプロパティは、基本的にシングルプロセッサマシンでのマルチスレッドプログラミングの場合に、さまざまな同期プリミティブのプロパティを証明するために使用されます。たとえば、本Gregory R. Andrews Fundamentals of multi-threaded、parallel and distributed programming 。



マルチプロセッサマシンまたは分散システムの場合、通常、グローバル時間の要件は受け入れられません。 したがって、計算可能性の概念を並列計算の場合に一般化する必要があります。 これらの一般化の1つは、アクターモデルです。

どのようにすべてが始まりましたか？

遠い70年代にこのモデルが登場したのは、次世代マシンがマルチプロセッサになり、プログラムに人工知能があるという強い信念によるものです。 1973年、 カールヒューイット 、ピータービショップ、およびリチャードシュタイガーは、「 人工知能のためのユニバーサルモジュラーアクターフォーマリズム 」という記事を発表しました。 この記事では、アクターの概念を紹介し、多くのアプリケーションクラスがアクターモデルの特殊なケースであることを説明しました。 ちなみに、今年は40周年でした！



アクターは、受信したメッセージに応答する計算エンティティの普遍的な抽象化です

1. 他のアクターに有限数のメッセージを送信できますが、
2. 有限数の俳優を作成し、
3. 次のメッセージを受信する動作を選択します。

アクターは、従来のコンピューティングモデルと根本的にどのように異なりますか？

それらの違いは、電話とメッセージをメールで送信する場合と同じです。 最初の場合（これらは世界時間に基づいた計算です）、複数の人が1つの電話番号に到達しようとすると、共有共有リソース（受信者）へのアクセスを求めて競合し始めます。 Office PBX、複数回線電話、コールセンターソフトウェア-これらすべて（同期プリミティブに類似）は、着信コールの効率的な処理を保証するために必要です。 メールの場合、レターの送信者（俳優）は、他の送信者とのアクションを調整する必要があるため、レターを受信者に遅滞なく送信します。 しかし！ ただし、受信者がいつ手紙を読むかはわかりません。

俳優理論の開発に関与しているのは誰ですか？

2つの最大の専門家は、カールヒューイットと弟子のガルA.アガです。 ヒューイットは主に、他の計算アプローチがアクターモデルの特殊なケースであるという厳密な正当性を扱い、アガは分散システムのさまざまなアプリケーションを扱います。

主な結果

結果自体はそれぞれ別の大きな記事のトピックなので、要約とソースへのリンクのみを提供します。



アクターモデルのイベントは、部分的に順序付けられたセットを形成します。 Ordering Lawsと呼ばれるこのセットの公理は、 Actors and Continous Functionals （1977）でCarl HewittとHenry Bakerによって説明されました。 かなりの数の公理がありますが、それらのポイントは、アクターモデルが実際の使用に適していることを正当化することです。



1985年、Gul A. Aghaは、ヒューイットの指揮の下、論文「 Actors：A Model of Concurrent Computations in Distributed Systems」を擁護しました。 Aghaの論文では、アクターをサポートする最小限のプログラミング言語の構文と、アクターを解決するための一連の典型的なタスクと方法について説明しています（第4章）。



アクターモデルの実装に対する実用的なアプローチへのもう1つの重要な貢献は、Phillip HallerとMartin Oderskyによる Inversion Controlのないイベントベースプログラミングの記事です。 Scalaで使用されたアクターシステムの開発に対する新しいアプローチを提案しました。 その本質は、結果の並列記録プログラムが「通常の順次」プログラミングに非常に似ていることです。



たとえば、C＃の開発用に同じパスが選択されました。 C＃5のアクターは次のようになります。

static async Task SavePage(string file, string a) { using (var stream = File.AppendText(file)) { var html = await new WebClient().DownloadStringTaskAsync(a); await stream.WriteAsync(html); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、 awaitキーワードは、対応するメソッドを非同期に呼び出し、応答を受信したときに計算に戻ることを意味します。



2011年、Gul A. AgaとKarmaniは、アクターシステムの実装における長年の経験をまとめ、最も一般的な実装方法を説明しました。 彼らは彼をFog Cutterと呼んだ。 確かに、ヒューイットはこのようなアーキテクチャを繰り返し批判しています。たとえば、 こことここで。批判の本質は、これがアクターモデル全体を完全に実装しないモデルの特定のケースの可能な実装の1つにすぎないという事実に要約されます。



実際、 俳優セマンティクスの基礎の論文phdで、ウィリアムデュグラスクリンガー（カールヒューイットの学生）は、俳優モデルには無限の非決定性があり、チューリングマシンは非決定性に制限されていることを示しています。 このことから、彼とカールヒューイットは、アクターモデルには実装できるがチューリングマシンには実装できないアルゴリズムがあると結論付けています。 したがって、チューリングの計算可能性を実装する「通常の」コンピューターにアクターモデルを実装しようとすると、アクターモデルの特定のケースのみが実装されるという事実につながります。

スプーン一杯...

1988年、Prolog言語の作成者であるRobert Kowalskiは、「計算は論理的な結論によってグループ化できる」という論文を提唱しました。 これは、逐次計算および一部の並列モデルに当てはまります。 しかし、1988年に、ヒューイットとアガは、 Guarded Horn句の言語の記事を発表しました。それらは演ductive的で論理的ですか？ 、アクターモデルの場合、これは次の意味で真実ではないことを示しました。プログラムの現在の状態は、前の状態から演ductive的に従わない場合があります。 これが実際に意味すること：アクターモデルに基づくプログラムのデバッグは、シーケンシャルプログラムの場合ほど効果的ではありません。

なぜ関数型言語なのか？

並列プログラミングに関しては、なぜ関数型言語が発生するのですか？ この質問に答えるために、小さなC ++の例を考えてみましょう。

 int j = 0; for(int i =0; ; ++i) { ++j; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードにはI / O操作が含まれていないため、別のスレッドが同じプロセッサコアでそのコードを実行できるようにするには、オペレーティングシステムのスレッドスケジューラがスレッドの切り替えを強制するのを待つ必要があります。 これは、システム関数が別のスレッドで呼び出されたとき、またはタイマーからのイベントによって発生する可能性があります。 デフォルトでは、タイマーイベントは15.6 msごとに1回発生し、この時間を1 msに短縮しない理由を説明します。 命令型のスタイルを使用すると、プロセッサのすべてのリソースを単独で使用しようとする「貪欲な」プログラムを作成できますが、これに影響を与える手段は限られています。



このプログラムは、末尾再帰によって書き換えられます。

 void cycle(int i, int& j) { ++j; cycle(i+1, j); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このような自由な解釈のための関数型プログラミング言語のファンを許してください。しかし、私の目標はアイデアを実証することだけです。



ループの繰り返しは、関数呼び出しに置き換えられました。 各関数の呼び出しポイントで、コンパイラがコードを埋め込み、現在のスレッドの実行に必要な時間を計算し、必要に応じて別のスレッドに切り替えるとします。 これで、ナノ秒以内に1つのスレッドから別のスレッドに切り替えることができます。 同じ考えにより、たとえばErlangのように軽量スレッドを実装できます。



これらのプロパティの場合、関数型言語は、並列処理とリアルタイムの反応が必要な場所で使用すると便利です。

命令型言語のリハビリテーション

非常に高速な応答が必要な場合、関数型言語は競合を超えていますが、要求の処理中にデータベースに移動する必要があり、それからの応答時間が約50-100ミリ秒である場合、または多くの計算を実行する必要がある場合、つまり、多くの関数呼び出しを行う場合。 実行時間の計算と各呼び出しへのスレッドの切り替えに関連するオーバーヘッドが感じられ、この場合は命令型言語がより効果的です。 これを確認するには、 benchmarksgame.alioth.debian.orgをご覧ください。 このサイトでは、異なる言語で作成されたプログラムのパフォーマンスを測定し、同じ問題の解決策を比較することを提案しています。 比較の例を次に示します。reverse -complement 、 mandelbrot 、 regex-dna 、 pidigits 。



まず、予約を行います。まず、これらは単なるテストです。あまり真剣に受け止める必要はありません。 一方、お気に入りのプログラミング言語の状況に満足していない人は、自分の解決策を提案し、力のバランスを変えることができます。 第二に、私は、命令型言語が明確な利点で勝つリンクのみを引用しました。なぜなら、私の目標は、並列処理の編成に関連するオーバーヘッドに関するいくつかのパラグラフで表されたアイデアを説明するだけだからです。



別の興味深い観察結果は、命令型言語でのアクターモデルの実装です。通常は、機能的なErlangを超えるテストです。 繰り返しますが、私は予約をします。Erlangがコンピューティング、つまり即座の応答が必要な場所が苦手であることは誰もが知っていますが、これはオーバーヘッドの考えをもう一度確認するだけです。



メタファーを1つ挙げましょう。長距離ランナー、マラソンランナー、短距離ランナー、スプリンターがいます。 いくつかは平均速度が低い（スプリンターに比べて）耐久性を必要とし、2つ目は（マラソンランナーに比べて）非常に短い時間で最大のパフォーマンスを必要とします。 残念ながら、筋肉とはまったく異なる特性が必要なため、スプリントとマラソンの距離で同等に高い結果を示すことは、単に生理学的に不可能です。 これらのランナーは、その数字によっても際立っています。マラソンランナーはドライで筋骨たくましく、スプリンターはアスレチックで筋肉質です。

第5世代のコンピューター

並列プログラミングがそれほど単純ではないというもう1つの確認は、第5世代のコンピューターを作成するプロジェクトです。



前世紀の80年代、日本では第5世代のコンピューターを作成する試みが行われました。 このプロジェクトは、未来が並列コンピューティング、大規模データベース、大規模データベースの論理処理にあるという信念によって再び開始されました。



80年代の価格で5億ドルを費やしました。 プロジェクトは10年続き、完全に失敗しました！ 並列プログラムは、シングルスレッドのプログラムと比べてパフォーマンスに大きな利点はありませんでした。 そして何十年もの間、Intelはシングルスレッドプロセッサを手に入れてきました。 そして、プロセッサの製造業者がクロック速度の増加に関する技術的な制限に直面したときのみ、並列処理のアイデアが再び人気を集め始めました。

アクターモデルの実装へのアプローチ

上記のパフォーマンスの問題、およびヒューイットが、スレッドもメッセージキューもよく知られている構造もアクターモデルの一部ではないことを一貫して強調しているという事実は、さまざまなアイデアと実装方法につながっています。



3つの方向が区別されます。

• 新しいプログラミング言語。 このニッチは関数型言語に占有されています。 代表的な例：アーラン。
• 既存の言語の拡張。 たとえば、Scala、C＃。 OderskyとHallerのアイデアが使用されます。これにより、「馴染みのあるスタイル」で並列プログラムを作成できます。
• 既存の言語のライブラリ。

結論として、2つの観察

並列コンピューティングの信念。

70年代の記事を読みます。将来はマルチプロセッサシステム、人工知能にあります。 80年代：未来はマルチプロセッサシステム、大規模データベース、論理データ処理に属し、現在：未来は多数のコア、ビッグデータ、クラウドコンピューティング、データマイニングを備えたプロセッサに属します。 40年前の現在の状況と予測を類推することは難しくありません。 これはすべて、ロバとニンジンに関する動機づけに関するトレーニングの例に似ています。 私たちは大切な目標に近づくための一歩を踏み出し、目標に近づくにつれて目標は遠ざかりますが、それが私たちを発展させ前進させます。

一方で無視し、他方で批判。

私が初めて俳優のモデルに出会ったとき、それは比較的最近でした。 私は質問がありました-なぜ私は以前彼女について知りませんでした。 私は特にタネンバウム、グレゴリー・アンドリュース、 企業アプリケーションの統合パターンなどの本を見ました-それらはすべてメッセージングの概念に多くのスペースを与えますが、誰も俳優とヒューイットのモデルについて一言も言いません。 しかし、ヒューイットやアガを読んだとき、計算の伝統的なモデルを批判することに多くの時間が費やされています。 俳優は単に無視しているようです。 プログラミングでも同じことが起こります。命令型プログラミングの世界では、関数型については事実上何も知られていません。少なくとも最近まで、関数型プログラミングの世界では非難されているようです。 たぶん誰かがこれが起こった理由を考えているのでしょうか？

次は？

この記事に興味がある場合は、次のような一連の記事を書く予定です。

• アクターと連続機能のアクター 。
• 「 アクター：分散システムにおける同時計算のモデル」で提示されたアイデアの要約Gul A. Agha論文。
• 反転制御アプローチを使用したOdersky イベントベースプログラミングの長所と短所。
• スプーン1杯に戻って...-すでに実装され、実際にテストされている2、3の独自のアイデア、アクターモデルに従って実装されたシステムの信頼性とフォールトトレランスを向上させる方法。

記事に提案があれば、私は聞いてうれしいです。

PS

この記事は私のレポートの1つに基づいています



物語は、俳優から5分ほどで始まります。