評価

MultipleOrderedECとPeriodicExecutionContextの比較を行います。

10.1 簡単なRTシステム

RTC_AとRTC_Bを用意します。RTC_AとRTC_BのonExecuteは以下の通りになっています。

double H[300][300];
for(int k=0;k < 1000;k++)
{
　　for(int i=0;i < 300;i++)
　　{
　　　　for(int j=0;j < 300;j++)
　　　　{
　　　　　　H[i][j] = i*j/20.0-k;
　　　　}
　　}
}

単純にある程度時間のかかる処理を記述しただけで、内容に意味はないです。

各RTCは通信は行いません。

MultipleOrderedECでの直列実行、並列実行とPeriodicExecutionContextの直列実行、実行コンテキストを関連付けせずに独立して実行した場合を比較しました。
各処理時間の平均を以下の表に示します。

表：10.1

直列実行に関してはほとんど差がでませんでした。
MultipleOrderedECでのRTCのロジックの処理時間と待ち時間を除いても、0.001[s]未満のオーバーヘッドしか発生していないことが確認できました。

MultipleOrderedECでの並列実行と実行コンテキストを関連付けしなかった場合の比較すると、0.15[s]ほど差が開いていますが、これは同期か非同期かの違いによるものだと考えられます。
MultipleOrderedECのプログラムをRTCの処理だけをコメントアウトしたところ、待ち時間を除くと0.001[s]未満になったので、原因は同期か非同期かの差であると推測できます。

課題

RTCのロジックで何もしなくてもCPUに負担がかかります。PeriodicExecutionContextでも同様の問題が起きるのですが、周期が小さいとMultipleOrderedECはsleepで待つ時間がほとんどなくなるのでCPUの負担がより大きくなります。なんとか処理を少しでも減らしたいと思います。

実行順序に設定したRTCが実行コンテキストに関連付けされていない場合、その実行は飛ばすようになっておりその際、

CompItr it;
it = std::find_if(m_comps.begin(), m_comps.end(),
                                  find_comp(c->r));

とRTC::LightweightRTObject_varからコンポーネント管理用構造体RTC::PeriodicExecutionContext::Compを取得してから関連付けしたRTCの中から検索しています。RTC::LightweightRTObject_varを用いるのは、実行順序を管理するためのクラスRuleの変数RTC::LightweightRTObject_varにより格納していますが、RTC::PeriodicExecutionContext::Compで直接格納できれば多少処理が速くなるかもしれません。ちなみにPython版ではRTC::PeriodicExecutionContext::Compで格納しています。