スレッド数決定問題3

　この記事は、スレッド数決定問題2の続きです。引き続き、並列処理における、生成スレッド数の決定問題を語ります。
　前回述べたように、コア数と同数のスレッド数が基本ですが、これはあくまでも基本です。並列処理システムを構築する際には、より深く考えなくてはなりません。先ず考えるべき事は、システムの特性です。
　システムの特性を大別すると、大量のデータを処理するバッチ処理と、ユーザーの指示に基づき、少量のデータを処理する対話処理に分類できます。バッチ処理か、対話処理なのかによって、最適なスレッドのあり方は事なります。システム規模で考えた場合、大概は2つの側面を共に持っていますが、重視する目的と局面により、処理特性が存在していますので、分類に従って検討する事が出来ます。
　バッチ処理の場合、データ処理件数が重要です。つまり、短時間でどれだけ大量のデータを処理する事を重要視します。この場合、データの並列処理という形が最適です。データの並列処理とは、大量のデータを複数のスレッドに分割して、並列処理を行う並列処理の方式です。データの並列化を行う事により、単位時間当たりのデータ処理件数を増やす事が出来ます。
　データの並列処理を行う際には、スレッド数はコア数よりも少し多くする方が良い場合も多々あります。この理由は、OSのスケジューラの動作原理にあります。前にも述べましたが、OSごとにスケジューラは異なります。しかし、基本思想は似ております。
　現代的なOSは、基本的にラウンドロビンスケジューラをもとに改良を加えたスケジューラを使用しています。簡潔に言うと、ラウンドロビンスケジューラとは、スレッドまたはプロセスに、クォンタムと呼ばれる実行を許可する一定の時間間隔を割り当てる方式のスケジューラです。時間を使いきったスレッドは、たとえ処理途中であっても停止され、違うスレッドが実行されます。こうする事により、飢餓状態（常に実行をまっている状態）になるスレッドを無くし、公平に処理が実行されるようになります。
　ラウンドロビン法による公平なスケジュールは、汎用目的には良いものです。しかし、バッチの処理の場合、とにかく処理件数を上げるのが目的となりますので、如何にして多くのデータを処理させるかが問題となります。公平にスケジュールされると、データを処理しないスレッドの実行権が渡されますので、これを如何にして避けるかが課題となります。そこで、考えられる一つの方法として、スレッド数を少し多く生成し、CPUが割り当てられる確率を増やす事が考えられます。例えば、実行可能状態スレッドの数が10で、データを処理するスレッドが1つだけの状態ならば、選ばれる確率は10％です。選ばれなければ、処理は実行されず、単位時間当たりのデータ処理件数が減ります。そこで、データを処理するスレッドを5個に増やせば、選択される確率が約35.7％に上昇します。選択される確率が増えれば、単位時間当たりに処理できるデータ数がアップします。
　具体的に、バッチ処理で、どれぐらいのスレッド数を割り当てるかについては、分割によるオーバーヘッドを考慮して決める事になります。前にも述べましたが、並列アルゴリズムは、直列アルゴリズムと比べると、余分な処理が必要となります。ですから、多く分ければ分けるほど、そのオーバーヘッドの割合が大きくなります。オーバーヘッドが大きくなりすぎれば、余計にデータ処理件数が減ります。従って、実際に測定しながら、最適なスレッド数を微調節する必要があります。
　長くなったので続く・・・