0

マルチプロセッサシステムでのPOSIXスレッド、マルチプロセッサマシンでのPOSIXスレッドの同時実行、スレッドとプロセス、マルチスレッドとマルチコア/マルチプロセッサなど、いくつかの質問に答えました。それらはどのようにマッピングされますか？ 




これらと他のいくつかのWiki記事に基づいて、入力、処理、出力の3つの基本的な作業を行うシステムを信じています。



    

  • CPUにバインドされた処理の場合、CPUを集中的に使用するスレッドの数（アプリケーションの数*アプリケーションあたりのスレッド）は、プロセッサのコア数の約1〜1.5倍である必要があります。
    • 

  • ボトルネックを取り除くために、入力スレッドと出力スレッドは十分に大きくなければなりません。たとえば、query/query-ackおよびresponse/response-ackモデルに基づく通信システムの場合、I/O待機状態で時間を無駄にしないでください。
    • 

  • 動的メモリの要件が大きい場合は、スレッドよりも多くのプロセスを使用することをお勧めします（メモリの同期を回避するため）。
    


    これらの引数は、アプリケーションに含めるスレッドの数を決定する際にかなり一貫していますか？他のパラメータを調べる必要がありますか？
    • 


    


        

            

                

	
                

            

        


  






            4 


   








    
    




           






	

		

			

				   1 に答える				1
			

		



		



                            





    

        

            

        
        

            1        

        
		




        


       


    
    


「コア数の1〜1.5倍」-これはOS/言語に依存しているようです。たとえば、Windows / C ++では、CPUを集中的に使用するタスクが多数ある場合、最適なのはコアの数の2倍をはるかに超え、パフォーマンスの広がりは非常に小さいようです。そのような環境の場合は、プールに64スレッドを割り当てるだけで、コアの数を気にしないほうがよいようです。



「query/query-ackおよびresponse/response-ackモデル、I / O待機状態で時間を無駄にしないでください」-これは、ほとんどのネットワークの待ち時間が長いこのようなプロトコルでは避けられません。遅延は「ピンポン」プロトコルによって強制されるため、必然的にI/O待機が発生します。非同期I/Oは、この待機をカーネルに移動するだけです-それはまだそこにあります！



「動的メモリの要件が大きいため、スレッドよりも多くのプロセスを使用する方がよい」-実際にはそうではありません。「動的メモリの大きな要件」とは、通常、大きなデータバッファが移動することを意味します。大きなバッファは、参照によってのみ効率的に移動できます。これは、共有メモリスペースがあるため、スレッド間で非常に簡単かつ迅速に実行できます。プロセスを使用すると、厄介で遅いプロセス間通信に悩まされます。



「アプリケーションに含めるスレッドの数を決定する」-まあ、いくつかの面で非常に難しい。未知のアーキテクチャを考えると、設計。言語とOSについて、私が持っている唯一のアドバイスは、すべてを可能な限り柔軟で構成可能なものにすることです。スレッドプールがある場合は、そのサイズを微調整できる実行時パラメーターにします。オブジェクトプールがある場合は、その深さを変更できるように設計してみてください。テストボックスで機能するデフォルト値をいくつか用意し、インストール時または実行中に、特定のシステムに対して特定の変更や微調整を行うことができます。



柔軟で構成可能な設計のもう1つの点は、テスト時に、建築家、設計者、開発者、そして何よりも顧客によって行われた誤った決定、仮定、推測の多くを微調整して修正できることです。

    

    

   
于 2012-04-13T10:33:59.933   に答える