Smalltalkを並列化する際の難しさは何ですか？

Question

独立したコンピューティングエンジンであるオブジェクトのコアモデル（ストレージはインスタンスクラス、CPUはクラスメソッド）は、スモールトークが大量の並列処理に自然に適合するように見えますコアの数。しかし、これは、現代のプロセッサーのハードウェア機能を利用しない独自のシミュレートされたマルチタスク機能に答えて、Smalltalkがまだまだ非常に弱いところです。

これはなぜですか？主な問題は何ですか？変更可能性は重要ですか、それともSmalltalkにとってより具体的なものですか？

Answer 1

まず、GemStoneがSmalltalkを拡張して並列コンピューティングをサポートできることを実証してみましょう。もちろん、GemStoneは非常に洗練されたシステムなので（ガベージコレクタなど）、他のすべての方言はそのように動作しないため、問題は残ります。

パラレルコンピューティングでは、スレッドセーフなコードが必要です。さもなければ競争状態が常に浮上するだろう。問題は、Smalltalkコードをスレッドセーフにすると、どこでも複雑さが増すことです。例えば、

OrderedCollection >> addLast: anObject 
    lastIndex = array size ifTrue: [self makeRoomAtLast]. 
    lastIndex := lastIndex + 1. 
    ^array at: lastIndex put: newObject 

これらのコードの間に中断が発生すると、受信機の内部状態が矛盾する可能性があります。もちろん、これは、スモールトークが中断をサポートしているため、非並列実行でも起こる可能性があります。しかし、スモールトークがこの機能を使用する方法は、あまり頻繁に起こらず、何らかの形で支配下にあるクリティカルセクションに限られています。

Smalltalkでは、スレッドセーフなコードの追加があまり自然でない理由は、Smalltalkにはイメージがあります。つまり、すべてのクラス、コンパイルされたメソッドなど、すべてのプロセスで共有されるオブジェクトがたくさんあることを意味します。システムとそのアプリケーションによって広範囲に使用されるSmalltalkの動的性質は、事態をさらに困難にします。

私の個人的な経験では、Smalltalkでマルチコア機能を実現する良い方法は、異なるOSプロセス（ヘッドレスイメージのインスタンス）を起動し、Smalltalkセマフォとプロセスを使用してそれらを調整することです。このアプローチでは、すべてのOSプロセスは、Smalltalkプロセスによってメインイメージ（UIを持つイメージ）で表されます。メインイメージとヘッドレスプロセスとの間の通信は、ソケット（または他の任意の機能）に依存することができる。もちろん、デバッグ時には料金を払っています。実際には、何がうまくいかないかを理解するまで、ログファイルに多数のイベントをトレースし、「ヘッドレス」プロセスでデバッガを開くことになります。しかし、デモとしてだけでなく、実際の "産業的に強い"製品のために、行うことができます。

Answer 2

難易度：なし

複数のPharoインスタンスを起動し、ソケット経由で通信するか、最終データを共通ファイルに保存するようにしてください。あなたのOSはそれぞれのインスタンスを管理し、それを送信して別のコアで実行します。 OSProcessモジュールはそのような機能を提供し、HydraやRoarVMのような実装が成功していますが、問題は使用されていません。

実際に並列処理の最も難しいことは、それを使用する人々を得ることです。今日のハードウェアアプリケーションでは、単一コアの100％になることはめったにありません。私はほとんどPharoを10％以上にしました。

また、プログラミングのダイナミックプログラミング言語と同様、スモールトークは開発者のパフォーマンス言語であり、アプリケーションパフォーマンス言語ではありません。

実際にこのような処理の問題が発生した場合は、CやC++のようなアプリケーションのパフォーマンスを重視する言語を使用する必要があります。その言語を使用するのは難しいだけでなく、並列性さえも適切なライブラリであっても正しく行うことは非常に困難です。ハードウェアは非常に奇妙なデザインの賢明であり、あなたが知っておく必要があります。

これが、並列処理がこれらのプログラミング言語に適している理由です。もちろん、C/C++でライブラリを作って、Pharoや他の小さなトークを使っても構いません。 Pythonがこれを行います。 PythonとPharoはGILを使用していて、緑色のスレッドを持っている点で似ています。ちょっとしたことは、VMが直接アクセスできるようにスレッドをメインスレッドに戻さなければならないということですが、ソケット通信、パイプ、共有メモリマップファイルなどのような方法があります。

Pythonの並列ライブラリはすべてC/C++ベースです。

並列性そのものは、たとえ並列性を持っていても、コードが単一スレッドと単一コアで動作するほど遅くなる可能性がありますが、非常に扱いにくい問題です。しかし、これはアプリケーションのパフォーマンスに関する一般的な問題です。ハードウェアの仕組みを知っておく必要があるほど多くのパワーをミルクアウトしたいときです。

今日のハードウェアはスーパーコンプレックスです。言語はあなたの心配の中で最も少ないです。

だからこそSmalltalkでは可能ですが、率直に言えば興味がある人はあまりいません。 Pharoのメーリングリストで、私が過去2年間、たぶん1回か2回頻繁に出てくる並列性に関する質問を見ました。そして並行性に関してさえ、誰かがそれについての質問をすることは非常にまれです。