1

私は 100 人未満のエージェント (20 * 20 ワールド サイズ) で適切に機能するモデルを持っていますが、現在のモデル要件の 1 つは、エージェントのさまざまなグループに対してモデルをテストすることであり、100 人を超えるエージェント (および 40 * 40ワールドサイズ）。各機能を個別に最適化しようとしましたが、残念ながら、モデルの要件を破壊せずに変更できるものは何も残っていません。

現在のバージョンでは、リンクを使用してエージェントの関係を追跡しています。各エージェントが持つことができるリンクの数に制限はありません。そのため、リンクの数は急速に増加します (2000 以上のリンク)。各リンクを更新する必要があります。各インタラクション後の関係値。

私のモデルでのリンクの使用についてもう少し詳しく:

  • エージェントは、ソーシャル インタラクションがある場合、相互にリンクの値と頻度を作成/更新します

    多くのエージェントは、そのエージェントの異常な社会的活動を観察すると、1 つのエージェントとのリンク値と頻度を作成または更新します (これらの活動のさまざまなグループが定義されており、活動の種類に基づいてさまざまなアクションが呼び出されます)。

    エージェントは、同じパッチにある場合、同じ場所にあるエージェント リンクの値を観察し、それに従って、さまざまな種類の社会的相互作用を行う可能性があります。

    特定の年齢層のエージェントは、リンク値とその他の基準に基づいて相手を見つけます。

また、今は思い出せないかもしれませんが、リンクの値は各ティックで何度も呼び出されています。エージェントの有効期間は 4000 で、シミュレーションの長さは 40000 ティックです。エージェントが 100 の場合、実行に 10 ～ 15 分かかります。シミュレーションですが、200 エージェントの場合、わずか 2000 ティックを完了するのに 10 分かかります!

より多くのエージェントのモデルをテストするのに大きな問題があるため、すべてのリンクを削除し、エージェントの各ペアとその関係値と関係の頻度を含むグローバル テーブルを使用することを考えていましたが、リンクの使用は非常に簡単なので、値の設定と取得が困難。

これを行うためのより良い方法について誰か考えがありますか? または、netlogo モデルをスケーラブルにする方法は?

更新: こんにちは、私は何度も何度もチェックしましたが、私のプログラミングスタイルが私のプログラムを遅くしていると確信しています.リンクを非表示に設定しているため、そのうちの1つは本当に愚かです!!! そして、リンクが作成されるたびに hide-link を設定することができました! もう一度尋ねることなく:D

さらに、 out-link neighbors 、 links 、および out-link に対して ask または with を使用したケースを排除しました。たとえば、発信者エージェントと共通の関係を持つ他のエージェントを見つけるためにチェックしていたコードを置き換えました。最初のコードは非常に遅く、はるかに高速に動作する次のコードに置き換えました。

Let Agents_I_Met out-link-neighbors 
if any? other agents-here with [any? out-link-neighbors with [member? self Agents_I_Met ]]
          [
Let Other_Agent one-of other agents-here with [any? out-link-neighbors with [member? self Agents_I_Met ]]
Let CommonAgent one-of Agents_I_Met with [member? Other_Agent in-link-neighbors  ]
...

しかし、それでも他のエージェントに電話する必要がある場合が多いので、半径X内でエージェントに他のエージェントに尋ねるのは大丈夫だと思います!

最後に、私のシステムは、400 人のエージェントと15000 ～ 20000 のリンクに対して、より妥当な時間ではるかにうまく機能します:)

しかし、私はまだ改善の余地があると確信しています。あなたの役に立つ答えをありがとうセス:)

4

1 に答える 1

2

それは良い考えではありません。NetLogo のリンクは効率的に実装されています。それらを代用するものは、高速ではなく低速になる可能性が非常に高くなります。

あなたはこれが NetLogo のせいであることを熱望しているようですが、おそらくそうではありません。問題はほぼ確実に自分のコードの問題であり、作業しているプログラミング言語に関係なく発生する問題です。

ほとんどの NetLogo シミュレーションでは、実行時間はエージェントの数に比例して増加します。つまり、エージェントの数が 2 倍になります。あなたが与えた数字から、エージェントの数の二乗に比例して時間がかかるコードを書いたように思えます。(エージェントの数は指数関数的かもしれませんが、多項式の時間を要するコードを誤って作成する方がはるかに一般的です。)

これには、次の 2 つの方法が考えられます。

  • 実装しているアルゴリズムは、本質的に計算に多項式時間を要するアルゴリズムです。
  • 実装しているアルゴリズムは、線形時間で実行されるようにコーディングできますが、誤って多項式時間でコーディングしてしまいました。

私のコードが線形時間で実行されない原因は何ですか?

モデル内のすべてのエージェントをループするコード内のすべてのループを調べて、自問する必要があります。このループの本体に一定時間内に実行できないものはありますか?

すべてのエージェントをループするプリミティブには、 と が含まaskれwithます。したがって、最も一般的な間違いは、次のように書くことです。

ask turtles [
  ... turtles with [ ... ] ...
]

コードについて他に何も知らなくても、これを見て、それが発生するモデルが遅いモデルになることがわかります。これは、上記のコードの実行に多項式時間が必要なためです。可能なすべてのタートルのペアは の両方を実行するwithため、たとえば 100 個のタートルがある場合、コードの実行には 10,000 ステップかかります。2 倍の数のタートルがある場合、コードの実行には 40,000 ステップかかります — タートルの数を 2 倍にすると、ランタイムは 2 倍ではなく 4 倍になります。

有向リンクの代わりに無向リンクを使用するで、この形式のコードがモデルの速度低下の原因であることを既に確認しました。

したがって、このようにネストされたループがあるモデル内の場所を見つける必要があります。ここで、両方のループのサイズはエージェントの総数に比例します。(2 つのループは必ずしもaskandwithであるとは限りません。また、同じ手順ではない場合もあります。)

そして、これを行っている場所を見つけたら、本質的にこれほど時間がかかる計算を行っているのか、それとも不必要に遅い形式で誤ってコーディングしたのかを把握する必要があります。後者の場合は、修正してください。前者の場合は、要件を再考する必要があります。

そして、それはあなたの要件に問題があるようです。「現在のバージョンでは、エージェントの関係を追跡するためにリンクを使用しています。各エージェントが持つことができるリンクの数に制限はありません」と書いています。リンクの数はタートルの数に比例しますよね？つまり、多項式ランタイムを使用してプログラムを作成するために、ネストされたループは必要ありません。リンクの数はすでにタートルの数の 2 乗に比例しているため、一度でもを実行するとask links [ ... ]、あなたは死んでしまいます。

それを修正する方法の例として、各タートルが持つことができる関係の数に一定のサイズを設定することを検討してください。これにより、モデルを線形時間で実行できるようになります。

ただし、偶発的な問題についてコードを精査してはならないという意味ではありません。本質的な速度低下と偶発的な速度低下の両方の問題を抱えている可能性があります。誤って実行した可能性があります。その場合、実行時間はタートルの数の 3 乗として、ask links [ ... ask turtles ...またはask turtles [ ... ask links ...実行した場合はask links [ ... ask links ...4 乗として増加します。

このアドバイスは、特に NetLogo に固有のものではありません。NetLogo で遅いプログラムを簡単に作成できるのは、NetLogo ですべての種類のプログラム (遅いプログラムを含む) を簡単に作成できるからです。特に、NetLogo を使用すると、ループを非常に簡単に記述できます。コードの短いスニペットはturtles with [color = red]ループですが、非常に短く簡単に記述できるため、必ずしもループのように見えたり感じたりするとは限らないため、パフォーマンスへの影響を見落としがちです。

于 2013-11-10T13:15:48.260 に答える