今回はジョブ(タスク)並列化処理で性能改善のために行ったことについて説明します。
高速化に大きな影響があったのはスレッドの数とジョブデータに登録するデータ量でした。
これを含め、高速化に関連して試した事を記載します。
ジョブデータ列を作る処理も並列化できそうだったので、OpenMPによるデータ並列化を試しましたが、効果はありませんでした。このforループ内の処理は配列要素への代入処理が1つあるだけなので、分割処理の起動と終了待ちなどの影響度合いが大きくなったのだと思います。この並列化は使用するのをやめました。
スレッド数を4から8に変更
評価環境では8スレッドでの動作が最速でした。
ジョブデータ数は256以上は頭打ち
1度のジョブに与えるデータ数も速度差に大きな影響があり、256件くらいのデータ数が最速でした。
マクロ化も効果あり
末端関数のマクロ化は、ここでも大きな効果がありました。
気になったことは。。。
マルチ・シングル動作のソース共有が難しい
OpenMPによるデータ分割並列化では、#pragma 記述の有無だけで並列動作を切り替えることが可能でしたが、ジョブ並列ではOpenMPによる対策ができず、pthreadを使用しました。プログラム構造の変更も多く、同じソースからコンパイルオプション等により逐次処理と並列処理のコードを区別して生成するのは難しくなりました。
終わらせ方の工夫
OpenMPに任せた時には気にしなかったことに、終了方法があります。サンプルプログラムでは、条件を満たすデータを10件見つけたところで終了する仕様です。実際には、6件しかないので途中で終了することはありませんが、例えば8並列で動作している処理が10件のデータを検出したところで、余分に見つけることなく終了させることができるかは、難しそうです。
EMC組み込みマルチコアサミット2020、セミナー資料より
ジョブ並列化の動作結果は逐次処理と同じでした。
データ並列化の時のように検出順が変わることはありませんでした。
処理的にもその可能性は少ないと思いますが、8並列等で順に処理しますから、付近のデータとの順序は逆転する可能性があります。
逐次処理と全く同じ結果が必ず出ると考えない方が良いでしょう。
次回から、パイプライン処理による並列化をはじめます。
コメントをお書きください