6

私は、概念が、新しい概念からなる創発特性を生成するように設計されたシステムのエージェントであるという NLP 実験をまとめています (創発が何であるかを知らない人のためのリンクはここにあります)。Smalltalk (特に Pharo 方言) は、独立したエージェントとして相互に関連する完全にカプセル化された概念オブジェクトを簡単に作成できるため、この種のアプリケーションに最適であるように思われます。実行中のシステムの状態。

私の懸念は、存在するオブジェクトが多すぎて、すべてが互いにメッセージを送信している場合、システムが窒息し始めるかどうかです。理論的には、私の実装は何百万もの概念オブジェクトを生成する可能性があり、システムがそれほど大きなものを処理できない場合、SmallTalk でこれを処理することに時間を費やしたくありません。

  1. SmallTalk イメージ内のアクティブなオブジェクトの量に関する制限要因 (ハードウェアではなくソフトウェア要因) はありますか?

  2. システムは、何百万ものチャット オブジェクトを持つシステムに存在するメッセージ トラフィックを処理できますか?

よろしくお願いします。

4

2 に答える 2

3

1 について: オブジェクトの数は、VM で使用できる仮想アドレス空間によって制限されます。これは、標準のビルドでは数百 MB しかありません。Object私の現在の Squeak イメージには、アイドル状態の のインスタンスが 350 万以上含まれています。

2 について: 私の Squeak イメージは、最新ではない Intel Core i7 2620M で 1 秒あたり約 2600 万回のメッセージ送信を実行します (ただし、もちろん 1 つのコアのみを使用します)。

しかし、現在のアプローチの結果に満足していただけるとは思えません。あなたはシステムの状態を検査することについて話しました - これは Squeak/Pharo では本当に素晴らしいことです - しかし、何百万ものオブジェクトの状態を (手動で) 検査することはできません。しかし、繰り返しになりますが、私はあなたが何をしているのか正確にはわかりません;)

于 2013-10-31T23:24:17.817 に答える
3

Pharo 内のオブジェクト ポインタの内部作業サイズは、まだ 32 ビットだと思います。64b バージョンの話題がありましたが、64b マシンで 32b VM を実行することと、実際の 64b を介して VM を実行することは別のことです。

したがって、そこには暗黙の制限がありますが、それでも「数百万」のオブジェクトの余地があります。「数億」に到達し始めると、いくつかの制限にぶつかる可能性があります。

最終的に何百万ものオブジェクトを持つことは、実際には問題ではありません。現在は制御のスレッドに移行しており、その場合、Pharo はあまりスレッド化を行いません。したがって、必ずしもオブジェクト自体ではなく、実際に異なるコンテキストをいくつ持つかが問題になります。

何百万ものオブジェクトのチェーンが相互に通信することは、実際には大したことではありません。基礎となる VM に存在するメッセージ パッシング オーバーヘッドに遭遇して、生のパフォーマンスを制限するだけです。Pharo はかなり高速ですが、Java ほど高速ではありません。それがあなたにとって十分に速いかどうかは、あなたが答えることです。

また、Pharo GC が何百万ものライブ オブジェクトをどれだけうまく処理できるかについても語ることはできません。2013 年であることを示唆することしかできません。Squeak (Pharo のベースとなっている) は 90 年代半ばから存在しており、GC 技術は現在かなり成熟しています。この点に関して、Pharo の GC が驚くほどひどいとは思いません。

いくつかのマイクロベンチマークを実行して、自分で試してみるだけです.

于 2013-10-31T23:24:49.067 に答える