そのため、マルチスレッドのパフォーマンスを向上させるために Python インタープリターからグローバル インタープリター ロック (GIL) を削除しようとする試みに関するこの記事を読んでいて、興味深いことに気付きました。
GIL の削除が実際に事態を悪化させた場所の 1 つは、メモリ管理であることが判明しました。
フリースレッドでは、参照カウント操作はスレッド セーフを失います。したがって、このパッチは、カウントを更新するためのアトミック操作とともに、グローバル参照カウント ミューテックス ロックを導入します。Unix では、ロックは標準の pthread_mutex_t ロック (PyMutex 構造内にラップ) と次の関数を使用して実装されます...
...Unix では、単純な参照カウント操作が 3 つ以上の関数呼び出しに置き換えられ、さらに実際のロックのオーバーヘッドが発生することを強調する必要があります。はるかに高価です...
...参照カウントのきめの細かいロックがパフォーマンス低下の主な原因であることは明らかですが、ロックを取り除いたとしても、参照カウントのパフォーマンスは何らかの余分なオーバーヘッド (関数呼び出しなど) に非常に敏感です。 .)。この場合でも、パフォーマンスは GIL を使用した Python の約 2 倍遅くなります。
以降：
参照カウントは、フリースレッドのメモリ管理手法としては非常に厄介です。これはすでに広く知られていましたが、パフォーマンスの数字はそれをより具体的な数字にしています. これは間違いなく、GIL 除去パッチを試みる人にとって最も困難な問題です。
問題は、参照カウントがスレッドにとって非常に厄介である場合、Objective-C はどのようにそれを行うのでしょうか? 私はマルチスレッドの Objective-C アプリを書いたことがありますが、メモリ管理のオーバーヘッドはあまり気になりませんでした。彼らは何か他のことをしていますか？グローバルロックではなく、オブジェクトごとのロックのようなものですか? Objective-C の参照カウントは実際にスレッドに対して技術的に安全ではありませんか? 私は並行処理の専門家であり、実際に多くのことを推測することはできませんが、知りたいと思っています。