エントリー

1年ちょっと前、私は人生で非常に重要なことをしました。MicrosoftIDE WebサイトからVisual Studioをダウンロードし、C ++で私の人生で最初のプログラムを書いたのです。 次の6か月間、私はStraustrupの悪名高い本を読み、C ++ジュニア開発者として仕事を得て、PythonのLuaで書き込もうとしましたが、大きな成功を収めませんでした。メモリのそれらの部分ではなく（ところで、常にどこかでリークが発生しました）、複数のスレッド（C ++ 11！）を使用しようとすると、メモリの破損とデッドロックが発生しました。 コードがどのように見えるかについて黙っておく方が良いです。



なんで？ 私の個人的な意見/経験では、命令型言語は、その特性のため、初心者開発者には完全に不適切です。 産業用プログラミングパターンの知識、オペレーティングシステムの動作に関するいくつかの情報、およびコードの基本的な文化がなければ、それらに耐えられる何かを書くことは非常に困難です。 彼らは松葉杖や自転車に自由とスペースを与えすぎますが、機能的な言語は開発者を厳しく制限するため、貧弱なコードを書く機会をあまり与えず、思考と開発を余儀なくさせます。



約6か月前、私は何かを変える時だと気づき、インターネットを検索して30分後にErlangの仕様を見つけました。 記事の中で、著者は上記のすべての問題から「素晴らしい薬」としてErlangを提示しました、そして、一般に、大部分は彼は正しかったです。 だから私はErlangでプログラミングを始め、それからElixirで始めました。

エリクサー言語

ElixirはErlangの上に構築された言語であり、コンパイル結果はErlang VMバイトコードです。 シンプルな構文とメタプログラミングのための強力なツールにより、Erlangと比較して有利です（Lispに精通している人は、引用符と非引用符の構造をすぐに認識します）。 したがって、すべてのErlang機能、そのモジュール、そして最も重要なのはOTPフレームワークが使用可能です。



データ型はErlangと同じです。 データは不変であり、それらのアクションの結果は新しいデータです。 Elixirでは、多くの関数型言語と同様に、「すべてが表現」の原則が機能します。 式は値を返します。



Elixirには、言語とともにインストールされる優れたインタープリターがあります。その中の例を試すことができます。

基本的なデータ型

int、float

1 + 1 # => 2 3 / 2 # => 1.5 1.0 + 3 # => 4.0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

バイナリ

 "Hello"<>" World!" # => "Hello World!" "Hello #{World!}" # => "Hello World!" """ hello """ # => "hello\n"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

原子

その値のみを表す定数で、それ以上のものはありません。 個別の論理型はありません。true、false、nilもアトムであり、言語には対応する規則があります。

 is_atom(true) # => true is_atom(:true) # => true is_atom(:hello) # => true
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

リスト

 [1,2,3,4,"five"]++[6, "seven"] # => [1, 2, 3, 4, "five", 6, "seven"] [1,1,2,3,4]--[1,2,3,5] # => [1, 4]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

歴史的な理由により、Erlangの文字列はバイナリ形式ではなくリスト形式で表されます（Elixirではその逆）。したがって、リストは次のように表すことができます。

 is_list 'this is list' # => true 'lst'++[10000] # => [108, 115, 116, 10000]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

タプル

リスト、メモリ内のデータストレージの編成の違い、それに応じて、データを操作するためのライブラリツールのようなもの。

 {:hello, "world"}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

地図

 %{2 => 2, :c => {1, 2, 3}, "key1" => 1} #      ,  ,     %{a: 1, b: 3, c: "qweqwe"}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

PID

Erlang VMプロセスの識別子。 インタープリターの対話型シェルもプロセスであるため、呼び出されたプロセスのPIDを返すself関数を使用します

 self # => #PID<0.95.0> (     )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

明示的にいくつかの型変換を行うことは可能です。

 :erlang.tuple_to_list {1,2,3} # => [1, 2, 3] :erlang.integer_to_binary 123 # => "123" :erlang.binary_to_list "abc" # => :abc
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、この言語の快適さの1つは、任意の用語を完全に無痛でバイナリに変換でき、その逆も可能であることです。 1行のデータのシリアル化。

 res = :erlang.term_to_binary [:hello, {"world", '!!!'}] # => <<131, 108, 0, 0, 0, 2, 100, 0, 5, 104, 101, 108, 108, 111, 104, 2, 109, 0, 0, 0, 5, 119, 111, 114, 108, 100, 107, 0, 3, 33, 33, 33, 106>> :erlang.binary_to_term res # => [:hello, {"world", '!!!'}]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

パターンマッチング

データを変数にローカルに割り当てることができます（ここにはグローバル変数と共有メモリはなく、割り当てることはできません）

 x = 1 # => 1 #  x  c 1 x # => 1 #         (  ) x = 1+x # => 2
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、これを行う必要はまったくありません。 変数をまったく使用しない場合、コードはよりシンプルで、より美しく、より表現力豊かです。 厳密に言えば、Elixirの演算子「=」は、命令型言語の通常の意味での割り当てではありません。 ここでパターンマッチングが行われます。 その本質は例で示すのが簡単です。

 %{a: x, b: 1} = %{a: 1, b: 1} # => %{a: 1, b: 1} %{a: x, b: 1} = %{a: 1, b: 2} # => ** (MatchError) no match of right hand side value: %{a: 1, b: 2} %{a: x, b: 1} = %{b: 1} # => ** (MatchError) no match of right hand side value: %{b: 1}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

命令型言語に関しては、パターンマッチングは比較と割り当ての組み合わせです。「=」の左側の値に関連付けられた構造要素は、「=」の右側の対応する構造要素と比較され、関連しません-それらは右側の構造要素の対応する値に関連付けられます。 右側の構造には、値に関連付けられていない要素を含めることはできません。 比較のいずれかがfalseを返す場合、例外がスローされます。



パターンマッチングは、バイナリデータでも実行できます（実行する必要があります）。

 << a :: binary-size(5), rest :: binary >> = "hello, world" # => "hello, world" a # => "hello" rest # => ", world"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ところで、この例に注意してください：

 x = 1 # => 1 x == 1 # => true %{a: x, b: y} = %{a: 12, b: 1} # => %{a: 12, b: 1} x # => 12
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

パターンマッチングが成功しました。例外はありません。 この意味で、Elixirはより厳密な関数型言語（Erlangを含む）とは異なるため、関数内でパターンマッチングを使用すると混乱や混乱が生じることがよくあります。コード; これは避けるべきです。 パターンマッチングの真の威力は、関数宣言とcase式で使用する場合にのみ感じることができます。

関数とモジュール

言語は機能的であるため、言語の主な表現手段は機能です。 関数は、関数として引数として受け入れ、値として返すことができます。 関数はモジュール内で定義されますが、モジュールは他のモジュール内でも定義できます。

 defmodule Some do defp priv_func(arg) do arg<>"Hello from priv_func!" end def pub_func(arg) when is_binary(arg) do arg<>priv_func("Hello from pub_func!\n") end end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このモジュールの外部で呼び出すことができるパブリック関数を定義するには、defを使用する必要があります。また、defpを使用すると、このモジュール内でのみ使用可能な関数をやり直すことができます（Erlangと比べてどれだけ簡単かを参照） 関数名と引数の後には、ガード式と呼ばれる式があります（pub_funcの定義を参照）。関数の範囲を（数学的に）狭めることができます。

 Some.pub_func "Hello from shell!\n" # => "Hello from shell!\nHello from pub_func!\nHello from priv_func!" Some.pub_func 1 # => ** (FunctionClauseError) no function clause matching in Some.pub_func/1 Some.priv_func "Hello" # => ** (UndefinedFunctionError) undefined function: Some.priv_func/1 Some.priv_func("Hello")
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Elixir PLには、ラムダ（匿名関数）を定義するためのほぼ同等の2つの方法があります。

 sum = &(&1+&2) # => &:erlang.+/2 sum.(1,2) # => 3 sum = fn(x,y) -> x + y end # => #Function<12.106461118/2 in :erl_eval.expr/5> sum.(1,2) # => 3
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

例からわかるように、ラムダの呼び出しは、「。」のみで通常の関数の呼び出しとは異なります。 関数は、ラムダだけでなく、通常の関数でも引数として渡すことができます。 これを行うには、関数名の前に「＆」記号を付けて、アリティを示します。

 defmodule Some do def actor(arg1, arg2, func) do func.(arg1, arg2) end def div(arg1, arg2) do arg1 / arg2 end end sum = &(&1+&2) # => &:erlang.+/2 Some.actor(1,2,sum) # => 3 Some.actor(3,4, &Some.div/2 ) # => 0.75
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Elixir YPとその標準モジュールに関する詳細なドキュメントはここで、Erlang / OTPはここで読むことができます 。

オイラー馬問題の解決

C ++の勉強を始めたばかりで、VMK magistracyの入学試験の準備をしていたら（彼らはクールなコーディング方法を学ぶと信じていました）、入学試験のオプションの1つでこのタスクに出会いました。 それから私はそれを解決できませんでした。 何らかの理由で、昨日、私はそれを再び思い出し、1時間で決定を投げたので、私はこの記事を書くことにしました。



一般に、本質は次のとおりです。「任意のサイズの正方形のチェス盤があり、任意のケージで馬がその上に立っています。ボードにはピースがありません。 チェス盤のすべてのセルを馬で1つずつ正確に訪れた後、またはそれが不可能であることを証明する必要があります。



ボードのサイズと馬の初期位置を決定する特定の条件はないので、退屈で合理的ではない抽象的な数学的結論を出すことはかなり難しく、最も明白な解決策は総当たりです。



まず、関数で操作するデータ構造を決定します。 これにより、より高いレベルの抽象化が実現し、ソリューションが大幅に簡素化されます。 さらに、この方法で定義された構造により、コードの決定性が高まります。

 # structs of data defmodule Position do defstruct first: 1, second: 1 end defmodule GameState do defstruct current_pos: %Position{}, path: [] end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

位置-任意の時点でのボード上の騎士の位置。 ここでは2次元の場合を考えますが、後で見るように、機能コードは、このソリューションを任意の次元の空間に対して非常に簡単に一般化できるように配置されます。

GameState-ゲームの現在の状態は、現在の位置と移動したパスによって一意に決定されます。

ご覧のとおり、構造体フィールドのデフォルト値を定義しているため、クラスコンストラクターのようなものが得られます。 Elixirの構造はマップデータタイプに基づいており、使用/構文の構造に非常に似ています。

 defmodule Some do defstruct a: 1, b: nil end res = %Some{} # => %Some{a: 1, b: nil} is_map res # => true Map.keys res # => [:__struct__, :a, :b] Map.values res # => [Some, 1, nil]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、一般的な形式でソリューションを作成します。 init / 1関数は、引数としてボードのエッジ（この場合は正方形の辺）のサイズを取り、馬の初期位置（したがってゲームの状態）をランダムに決定し、inform_user_about_beginning / 1関数を使用してこれをユーザーに通知し、次にgame / 2関数を呼び出します。考えられる多くの回避策を返し、次にshow_game_results / 2関数を返します。この関数は結果をユーザーに通知します。 演算子「|>」に注意してください。 左側の式を最初の引数として右側の関数に渡すだけです。 問題は解決されましたが、まだ定義されていない関数を決定するために残っています。

 def init(limit) when (is_integer(limit) and (limit > 0)) do :random.seed(:erlang.now) [ %GameState{ current_pos: %Position{ first: :random.uniform(limit), second: :random.uniform(limit)} |> inform_user_about_beginning } ] |> game(limit) |> show_game_results(limit) end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

inform_user_about_beginning関数については、すべてが明確であると思います-引数を受け入れ、画面に表示して、それを返します。

 defp inform_user_about_beginning info do IO.puts "Hello, user, we begin from #{inspect info}" info end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

show_game_results関数はもう少し複雑です。 アルゴリズムの結果として、考えられる回避策のリストを取得する必要があります。 当然、空のリストと空でないリストに対して異なるメッセージを表示する必要があります。 1つの関数内でif-elseまたはcase式を使用する代わりに、この場合は、show_game_results / 2関数の2つの別個の句を記述する方が適切です。 これによりコードが簡素化され、視覚的で読みやすくなります。 一般的なルールは次のとおりです。関数が呼び出されると、特定の関数の句は、コードに記述されている順序で移動し始めます。 この場合、この句の関数のすべての引数と、外部から転送された対応する引数のパターンマッチングが実行されます。 パターンマッチングが成功した場合、関数はこの句の式を返し、そうでない場合、次の句が使用されます。 句が発生しない場合、例外がスローされます。

 defp show_game_results([], limit) do IO.puts "FAIL. This is no any way to go through desk #{limit}x#{limit} from this position." end defp show_game_results([%GameState{current_pos: current_pos, path: path} | rest_way], limit) do """ SUCCESS! There are #{length(rest_way)+1} ways to go through desk #{limit}x#{limit} from this position. Here one of them: """ |> IO.puts Enum.each( path++[current_pos] , &(IO.puts "\t#{inspect &1}") ) end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2番目の句に注意してください。リストの先頭と末尾への分割を使用します。これはFPに一般的です。 この場合、このようなパーティションの目的は、関数の引数で直接見つかったトラバーサルパスのリストから最初のトラバーサルパスを取得することです。これにより、関数本体のどこかでこれを行う必要がなくなります。 Elixirでは、Erlang内とリストの両方で、リストは空（[]）にするか、ヘッドとテールに分割することができます（テールはリストです）。

 lst = [1,2,3] # => [1, 2, 3] [a | rest] = lst # => [1, 2, 3] a # => 1 rest # => [2, 3] lst2 = [0 | lst] # => [0, 1, 2, 3] [first|rest] = [0] # => [0] first # => 0 rest # => []
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、2番目の句の最後には、高階関数があります。 実際、ここでのEnum.each / 2関数は、リストのすべての要素を調べ、それ自体が2番目の引数としてとる関数を各要素に適用します（この場合、単に表示します）。 さらに、テキストにはEnumモジュールからの関数がいくつかありますので、これに関する質問はありません。それらがどのように機能するかをすぐに説明します。

 Enum.map( lst, func/1 ) #  ,    func(el),  el -   lst Enum.filter(lst, func/1) #      lst,   func(el) == true Enum.reduce( lst, res, func/2 ) #   Enum.reduce(rest, func(el, res), func/2),  [el | rest] = lst,  Enum.reduce([], some_res, func/2) == some_res
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

不足している関数ゲーム/ 2を定義します。 可能なゲーム状態の空のリストを取得した場合（したがって、バイパスします）-それを返すこと以外は何もすることができません。 リストが空でない場合、トラバーサルが最後に到達したかどうかを確認し、これに応じて、トラバーサルパスのリストを返すか、トラバーサルを続行します。

 defp game([], _limit) do [] end defp game(lst, limit) do case game_over?(lst, limit) do true -> lst false -> Enum.map(lst, &(generate_new_list_and_game_next(&1, limit))) |> List.flatten end end defp game_over?([%GameState{path: path}| _rest], limit) do length(path) == (limit*limit - 1) end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

game / 2関数の2番目の節には、式があります。 一見、スイッチスイッチに似ていますが、実際には、その性質上、ケースはElixirの通常の機能とほぼ同じです。 一番下の行は次のとおりです。

 case (_0) do _1 -> _1 _2 -> _2 ... _n -> _n end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

式0の実行から生じる最初のcから開始して、各句の順次パターンマッチングが実行され、成功した場合、case-コンストラクトはこの句に対応する式を返します。 一致する句がない場合、例外が続きます。



次に、関数generate_new_list_and_game_next / 2を定義する必要があります。この関数は、ステップnでゲームの状態を取得し、ステップn + 1でゲーム状態のリストに変換します（結局、馬は任意のセルから0から8の特定の数のセルに移動できますが、手順n）の状態に応じて、このリストをgame / 2関数に渡します。 この関数を作成するには、まず馬の歩き方を知る必要があります。 初期条件に関係なく、アルゴリズムが動作を開始する前であっても、騎士のすべての可能な動きはわかっています（たとえば、女王の場合、これは正しくありません-この場合、多くの可能な動きはボードのサイズに関連しています）。 したがって、ナイトの理論的に可能なすべての動きを計算する作業は、コンパイル時に配置することができます（また、そうすべきです）。 これを行うには、make_permutations / 4関数を別のモジュールに記述します。 最初のdefにはdo-endブロックが含まれておらず、デフォルトの引数を入力するために使用されます。

 defmodule Permutations do def make_permutations( input_set, perm_size, condition, result \\ []) def make_permutations( _input_set, perm_size, condition, result ) when (length(result) == perm_size) do case condition.(result) do true -> List.to_tuple(result) false -> :failed end end def make_permutations( input_set, perm_size, condition, result ) when (length(input_set)+length(result) >= perm_size) do Enum.map( input_set, fn(input_el) -> make_permutations( input_set--[input_el], perm_size, condition, result++[input_el] ) end ) |> List.flatten |> Enum.filter(&(&1 != :failed)) end end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

make_permutations / 4関数では、条件条件を満たすperm_sizeの長さでinput_setセットから要素のすべての順列を取得します。

また、特定の計算の結果を使用するモジュールでは、次のように記述します。

 @horse_ways Permutations.make_permutations([-1, -2, 1, 2], 2, fn(lst) -> Enum.reduce(lst, 0, &(abs(&1)+&2)) == 3 end )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

@-モジュール属性の指定。 モジュール属性によって受け入れられる式は、このモジュールがコンパイルされるときに計算されます。

これで、欠落コードを作成する準備ができました。 ここではすべてが些細なことであり、関数と引数の名前はそれ自体を物語っています

  defp generate_new_list_and_game_next(game_state = %GameState{current_pos: current_pos}, limit) do @horse_ways |> Enum.map( &(generate_new_position(current_pos, &1)) ) |> Enum.filter(&( can_go_here?(game_state, &1, limit) )) |> Enum.map(&( go_here(game_state, &1) )) |> game(limit) end defp generate_new_position( %Position{first: first, second: second}, {delta1, delta2} ) do %Position{first: (first+delta1), second: (second+delta2)} end defp can_go_here?( %GameState{current_pos: current_pos, path: path}, prompt = %Position{first: first, second: second}, limit ) do not(prompt in [current_pos | path]) and Enum.all?([first, second], &( (&1 <= limit) and (&1 > 0) )) end defp go_here( %GameState{current_pos: current_pos, path: path}, prompt ) do %GameState{current_pos: prompt, path: path++[current_pos]} end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

完全なリスト：





実行してみましょう。 次のようなものが得られるはずです。







または、初期条件に不運な場合：







5x5ボードの結果はどのくらいの速さで得られましたか？ 6x6はどうですか？ それほど速くありません。 topが示すように、Erlang VMは1つのコアのみをロードします。







計算を並列化する時間。

並列タスクソリューションの最適化

Erlang VMで新しいプロセスを作成するのは簡単です。 spawnおよびspawn_link関数は、新しいプロセスで関数を開始します。これは引数として取得され、子プロセスのPIDを返します。 この関数が値を返した後、プロセスは終了します。 この場合、子プロセスで例外が発生した場合、spawn_linkを使用すると、親プロセスに転送され、逆の場合も同様です。これにより、プログラムの実行がより決定的になります。

 spawn_link fn() -> IO.puts "hello from #{inspect self}" end # => #PID<0.80.0> spawn_link fn() -> 109 / 0 end # => ** (EXIT from #PID<0.76.0>) an exception was raised spawn fn() -> 109 / 0 end # => #PID<0.85.0>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最適化するための明らかな場所は、コード内のEnum.map/2関数です。リストの各要素を個別のプロセスで処理し、受け取った値から新しいリストを収集するだけです。 これが言語のコアに直接実装されていないのはなぜですか？

考えられる最初の理由は、一般的な場合、純粋な関数がEnum.mapに渡されることを誰も保証しないことです。 悲しいかな、それは計算を行う順序で問題になることがあります。 そのような「汚い」関数は、その結果が（グローバルな意味で）引数に依存するだけでなく、回避されるべきであり、回避できない場合は、少なくとも何らかの形でローカライズされます。

考えられる2番目の理由は、プロセス数の制限です。 このような仮想的な並列実行Enum.mapが何らかの形で再帰的に呼び出されると仮定すると、プロセスの数は雪崩のように増加し始めます。 この点では、Erlang仮想マシンは非常に安定しており、プロセス自体は非常に安価です。 しかし、この世界のすべてには限界があります。

それにもかかわらず、今のところ、並行して（同時に正しく）動作するEnum.mapを独自に記述します（ただし、Enum.mapに転送される関数の純度は、それを使用する人の良心にとどまります）。



正式には、Erlang VMのプロセスは共有データを持たず、完全に分離されており、互いに非同期でのみメッセージを送信できます。 メッセージには、任意のアーラン用語を使用できます。 メッセージはsend / 2関数によって送信され、case式に非常に類似した受信式を使用して受信されます。 違いは、受信式に適切な句がない場合（つまり、メールボックスに予想されるタイプのメッセージがない場合）-例外はスローされず、適切なメッセージが到着するまで式が「ハング」することです（タイムアウトを設定することも可能です） ）

 defmodule Some do def receiver do receive do "hello" -> IO.puts "hello from receiver" receiver "please, die" -> IO.puts "OK ... " end end end child = spawn_link &Some.receiver/0 # => #PID<0.182.0> send child, "hello" # =>   hello from receiver send child, "some message" # =>      send child, "hello" # =>   hello from receiver send child, "please, die" # =>   OK ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、すべてが非常に簡単です。 しかし、私たちがすでに話した「しかし」というものが1つあります。Erlang VMは、数千、数十、数十万ものプロセスを同時にサポートできます。ただし、この数はまだ有限であり、これを考慮する必要があります。そのようなアカウンティングでは、Erlang VM全体に対して1つのカウンタープロセスが必要です。それは非常に単純に配置されています-他のプロセスからの対応するメッセージを受け入れ、1増加、1減少、またはこの値を要求したプロセスに値を送信できる必要があります。共有メモリとグローバル変数がない関数型言語で抽象オブジェクトの状態を保存する方法は？正解は再帰です。

  def parallel_enum_control_system number \\ 1 do receive do %{ from: sender, query: :get_number} -> send sender, number parallel_enum_control_system number :increment -> parallel_enum_control_system number+1 :decrement -> parallel_enum_control_system number-1 some -> IO.puts "WARNING! Unexpected message in parallel_enum_control_system: #{inspect some}" parallel_enum_control_system number end end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、カウンタープロセスのPIDを、カウンタープロセスにメッセージを送信する各プロセスに渡すことは不便です。特に、ParallelEnum.mapが間接的に自分自身を再帰的に呼び出すことができることを考慮します（この場合はそうなります）。 PIDを特定の名前（エイリアス）で登録し、エイリアスを使用してメッセージを送信します。以下のリストは、ParallelEnum.mapが呼び出されたときに何が起こるかを示しています。カウンタープロセスの名前のプロセスが登録されていない場合は、それを開始して登録します。大文字小文字の代わりにifを使用して、この場合はこの式が返す結果は重要ではなく、式は副作用のためだけに実行されることを強調しています。 spawn_linkの代わりにspawnがここで使用されることにも注意してください。これは偶然ではありません。事実は最初は、ParallelEnum.map / 2関数がどこで、いつ、誰によって使用されるかについて何も仮定していませんでした。 Erlang VM 2のどこかでParallelEnum.map/2関数が同時に実行され、そのうちの1つが何らかの理由で例外をスローした場合、カウンタープロセスも低下し、予測できない動作と「健全な」ための明らかな前提条件を作成します現時点でParallelEnum.map/2関数を実行することができなかったプロセス。そのため、カウンタープロセスを他のプロセスにリンクしないでください。予測不可能な動作と「健全な」プロセスのための明確な前提条件を作成しました。これは、現時点で関数ParallelEnum.map/2を実行するだけの幸運ではありませんでした。そのため、カウンタープロセスを他のプロセスにリンクしないでください。予測不可能な動作と「健全な」プロセスのための明確な前提条件を作成しました。これは、現時点で関数ParallelEnum.map/2を実行するだけの幸運ではありませんでした。そのため、カウンタープロセスを他のプロセスにリンクしないでください。

  def map lst, func, limit \\ 2 do if (:erlang.whereis(@controller) == :undefined ) do :erlang.register( @controller, spawn(ParallelEnum, :parallel_enum_control_system, [1]) ) end Enum.map(lst, &(try_make_child(&1, func, limit))) |> Enum.map( &collect_results/1 ) end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ParallelEnum.map/2関数の本体のif-expressionの後に、古典的なmap-reduceがあります（一部の皮肉な、正式にはmap-mapはここにありますが、結論に急がないでください）。したがって、ウィキペディアによると、このパターンは2つのステップで構成されています。

マップステップ

Mapステップでは、カウンタープロセスに従ってParallelEnumに関連する実行中のプロセスの数を確認します。プロセス数の指定された制限を超えていない場合、子プロセスを作成し、PIDを渡して（結果を返すことができるように）、ワークフローが実行する引数を持つ関数を渡します。制限を超えた場合、親プロセスはそれ自体で式を実行します。



IntermediateResult構造体を使用する理由について少し説明します。プロセスの数に制限がない場合、子プロセスのPIDのリストを収集し、それらが結果で応答するのを待つことができます。しかし、制限により、場合によっては親プロセスが作業を行う必要があります。この構造は、子プロセスからの結果を期待するかどうかを理解するための縮小ステップで役立ちます。

  defmodule IntermediateResult do defstruct child_pid: nil, my_own_result: nil end defp try_make_child(arg, func, limit) do case (get_number_of_processes < limit) do false -> %IntermediateResult{child_pid: nil, my_own_result: func.(arg)} # in this case do work yourself haha true -> %IntermediateResult{child_pid: spawn_link(ParallelEnum, :worker, [self, func, arg]), my_own_result: nil} end end defp get_number_of_processes do send @controller, %{ from: self, query: :get_number } receive do num when is_integer(num) -> num end end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

作業プロセス

複雑なことはまったくありません。開始直後に増分信号をカウンターに送信し、関数を実行して結果を生成プロセスに送信し、完了前に減分信号をカウンターに送信します。

  def worker(daddy, func, arg) do send @controller, :increment send daddy, %{ from: self, result: func.(arg)} send @controller, :decrement end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ステップを減らす

ここでも、すべてが非常に透明です。mapステップの後に取得したIntermediateResult構造は、reduceステップで何をする必要があるかを明確に示しています-完成した結果（親プロセスが作業を行った場合）を取得するか、子プロセスからの結果を含むメッセージを待ちます。

  defp collect_results( %IntermediateResult{child_pid: nil, my_own_result: result}) do result end defp collect_results( %IntermediateResult{child_pid: pid, my_own_result: nil}) do receive do %{ from: incoming_pid, result: result} when (incoming_pid == pid) -> result end end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、たとえばゲーム関数内で、Enum.map関数をParallelEnum.map関数に置き換えることができ、作業は完了です。コードの最終バージョンはここで見られます。

性能試験

したがって、「オイラー馬」の問題は解決され、ソリューションが最適化されます。現在、すべてが迅速に動作し、すべてのプロセッサコアを最大限にロードします。







テストの時間。並列最適化の議論の中で、特定のタスクのプロセス数の制限について正確には何も言われていませんでした。Horse.Solutionモジュールの関数をわずかに変更して、必要なプロセス数と馬の初期位置を一意に設定できるようにします（明確にするため）。5x5ボードのHorse.Solution.init関数の実行時間、1.1の初期位置、およびこの関数を使用するプロセスの最大数の異なる値をテストします。

  def test_of_performance do Enum.each( 1..25, fn(num) -> test_of_performance_process(num) end ) Enum.each( [50, 75, 100, 150, 200, 250, 500, 1000], fn(num) -> test_of_performance_process(num) end ) # to test this, add +P 100000000 flag when starting iex Enum.each( [10000, 50000, 100000, 500000, 1000000, 5000000, 10000000], fn(num) -> test_of_performance_process(num) end ) end defp test_of_performance_process(num) do {res, _} = :timer.tc( fn() -> init(5, num, %Position{}) end ) File.write "./test_results", "#{num} #{res}\n", [:append] end
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

測定により、作業プロセス数24の最小時間（最大生産性）が示されました。

なぜそんなにたくさん

結局のところ、ローカルマシンのコアははるかに少ないです。Erlang VMプロセスは、通常の意味でのOSプロセスではないためです。スレッドではありません。仮想マシンはそれらを完全にカプセル化し、プロセッサコア全体に負荷を均等に分散します（可能な場合）。

なぜそんなに少ない

Erlang VMプロセスのリソースはごくわずかですが、コストはかかります。プロセス数の増加に伴い、総オーバーヘッドコストも増加し、さらに、約24のプロセスでプロセッサコアに負荷を均等に分散します。仮想マシンは負荷をさらに均等に分散できません。ここでは、実際のプロセッサの物理的な制限に依存します。



私たちの特定のケースでは、カウンタープロセスについて覚えておく価値があります。親プロセスは、子プロセスを作成するのか、それとも作業を行うのかを決定するときに、既に実行中のプロセスの数をカウントプロセスに要求します。ここで、彼はカウンターにメッセージを送信するだけでなく、彼からの回答を待つ必要があります。プロセスは1つのカウンターです。数十万の作業プロセス。ここではすべてが明確だと思います。

1,000,000個のプロセスをマークした後に生産性が再び上昇し始めた理由は、私には謎です。

おわりに

Erlangは、マルチスレッドプログラミングの世界で唯一の現象です。 1987年、まだJavaさえ存在せず、C ++での単純なマルチスレッドプログラミングについて夢を見ることができたとき、エリクソンの開発者はすでに通信業界で使用するフォールトトレラントプログラムを作成していました。 Erlang言語とその仮想マシンは、特定のテレコムタスクを解決するために専ら実用的な目的のために作成されました;長年にわたって、この言語は実際のタスク（Haskellなどとは異なります）で進化しました。開発の過程で、多くのよくデバッグされ文書化されたライブラリで「成長」し、OTP（Open Telecom Platform）フレームワークが登場しました。 ErlangのOTPは、たとえばC ++のQt以上のものです。送受信式を覚えていますか？ Erlang VMには実際にはプロセス間の非同期メッセージングしかありません。大規模プロジェクトでこのような低レベルのコードを書くのはあまり便利ではありません。OTPには低レベルの詳細をカプセル化し、非常にシンプルで便利で直感的なインターフェイスを提供するツールがあります-非同期交換だけでなく、たとえば同期通信、エラー処理ツール/滝など。この記事では、別の大きな記事のトピックであるという理由だけでOTPを使用しませんでした。 Erlang VMの安定性と耐障害性は同等ではありません。異なるプロセス数でパフォーマンスをテストしたとき、最後の値は10,000,000でした。同時に、パフォーマンスはもちろん24に比べて低下しましたが、完全に致命的ではありません。はい、Erlang VMの演算は「少しきつい」ので、しかし、彼らが言うように、高速な算術演算が必要な場合は、Fortranが必要です。この図では、Erlang VMの場合、同時に保守する必要があるプログラムを作成できると言いたいだけです。本当にたくさんのプロセス。例として、Webサーバーまたは同様のものがすぐに思い浮かびます。さらに、Erlang VMのパフォーマンスは悪くなく、原則としてソフトリアルタイムです。一般に、Erlang / Elixir + OTPは、安定した分散された非常に信頼性の高いプログラムを作成するための不可欠なアシスタントになることができます。

UPD：Lispバージョン

数日前、私はLispとJVMを同時に参加させ、Clojureでこのタスクを書き直すことにしました。実際、コードの優雅さ/読みやすさについては議論の余地がありますが、ここでの作業の速度も非常に許容できるという事実です。







コードはこちらです。

Elixirが実際に足を伸ばしている場所をまだ理解したい人のために-Lispの方言に精通することをお勧めします。