評価

本節では，提案フレームワークの性能が妥当な範囲であることについて述 べる．以降，

3.5.1

項で筆者が想定する組込みシステムと性能要求について 述べる．

3.5.2

項で

3.5.1

項の性能要求を満たすことを示す．

3.5.3

項で，他 の

COP

言語と比較することで，提案フレームワークの優位性を示す．3.5.4 項で，構成可能にしたことによる効果を示すために，

COP

の各機能を実現 するために必要なヒープメモリ使用量を示す．

ベンチマーク環境は表

3.2

の通りである．開発対象は

COP

言語の一つで ある

Subjective-C

と比較を行うために

MacOS

とする．

3.5.1 想定する組込みシステムと性能要求

筆者が想定する組込みシステムは，本章冒頭で述べた掃除機ロボットのよ うに，稼働を止めずに実行時のコンテキストによって全体の振る舞いを変 更するようなシステムである．組込みソフトウェアにおける振る舞い変更 では，ハードウェアの切り替えも行われることが想定される．提案フレーム ワークでは，最低限の目標として，ハードウェアの切り替えよりも早い程度 の性能を目指す．ハードウェア切り替えの目安として，

FPGA

のハードウェ アの再構成にかかる時間は

10

ミリ秒単位である．これは，レイヤアクティ ベーションが従来の

COP

と同程度の性能であれば十分に達成できる．

また，メソッドディスパッチにかかる時間は，組込みソフトウェアにおけ る周期実行を守るために重要である．本研究の想定では，周期はミリ秒単位

表3.2 ベンチマーク環境

26 PDF26+LJK6LHUUDώʖζϥϱ

&38 *+],QWHO&RUH'XR ϟϠϨ *%0+]''5

;FRGHώʖζϥϱ%

FODQJώʖζϥϱ

֋൅؂ڧ

第

3

章

RTCOP: C++

ベースのコンテキスト指向プログラミングフレーム

ワーク

48

で設定し，

1

回の周期でメソッドディスパッチが

100

回以内であるとする．

目標はメソッドディスパッチを

100

回実行したときの時間が

1

ミリ秒を超え ないこととする．

3.5.2 性能要求に対する評価

本項では，レイヤアクティベーションとメソッドディスパッチにかかる実 行時間を計測し，提案フレームワークが妥当な範囲内の性能であることを示 す．メソッドディスパッチについては，

C++

と性能比較を行うことで，ど の程度性能に影響を与えているかも明らかにする．計測には，

sys/time.h

の

gettimeofday

関数を用いる．また，コンパイラによる最適化は無効とする．

具体的な評価方法は以下の通りである．準備として，1つのベースクラス と，

3

つのレイヤとそれらのレイヤに対応するパーシャルクラスを用意する．

ベースクラスは，int型のメンバ変数と，それをインクリメントするベース メソッドを持つ．また，パーシャルクラスは上記メソッドをベースとする パーシャルメソッドを持つ．パーシャルメソッドで実行される処理もベース メソッド同様に，ベースクラスが持つメンバ変数のインクリメントである．

手順としては初めに，

0

〜

3

つのレイヤをアクティベートし，レイヤードな クラスをインスタンス化する．その後，メソッドを呼び出してから返ってく るまでの処理を

100

万回行う．この

100

万回のループを

10

回繰り返して，

1

回ごとにかかる時間を計測する．計測結果を

100

万で割ることによって，1 回のメソッドディスパッチにかかる時間を割り出す．最終的な結果は

10

回 の繰り返しの平均とする．また，結果の偏りを明らかにするために，標準偏 差も示す．また，ベース言語からの増加率を調べるために，上記の性能評価 をベース言語である

C++

の仮想関数のメソッドディスパッチに対しても行 う．レイヤの代わりに子のクラスを

1

つ用意し，パーシャルメソッドの代わ りに，仮想関数の呼び出し・実行にかかる時間を計測する．

レイヤアクティベーションの性能評価では，1つのレイヤに対して，アク ティベーションとディアクティベーションを

1

回ずつ実行し，完了するまで の時間を計測する．この計測でも上記と同様に，100万回ループを

10

回繰 り返して，平均値と標準偏差を示す．また，計測に使うクラスが持つメソッ

第

3

章

RTCOP: C++

ベースのコンテキスト指向プログラミングフレーム

ワーク

49

表3.3 メソッドディスパッチの計測結果

!""# #$"% #"&

# !& $ ##" # %"""

' !!'% #(&$ %!&'

#!' #$$' !(%#

# #%"( #!"#& &

'

# $( #($ %&

) *+,-. / 01

23456789 :6;+

表3.4 レイヤアクティベーションの計測結果

ϟλρχ਼ ࣰߨ࣎ؔ>ИV@ ඬ६ยࠫ>ИV@

57&23఑Ҍ

6XEMHFWLYH&

ドの個数は

0

から

3

つまでとし，それぞれの個数におけるアクティベーショ ン性能の違いも明らかにする．

上記の計測結果を表

3.3，表 3.4

に示す．表

3.3

から，メソッドディスパッ チにかかる時間は

C++

の仮想関数のディスパッチから

6%

ほど増加してい る．どちらも仮想関数テーブルによってメソッドディスパッチを行っている が，元々の仮想関数のアドレスから離れるため，キャッシュミスなどが起こ りやすくなり，その分実行時間が増加したことが考えられる．また，レイヤ 数はメソッドディスパッチの実行時間に影響を与えないことが分かった．表

3.4

から，レイヤアクティベーションにかかる時間は，メソッドの個数が

1

つ増えるたびに大体

0.04

から

0.07

μ

s

ほど増加する．

第

3

章

RTCOP: C++

ベースのコンテキスト指向プログラミングフレーム

ワーク

50

提案フレームワークが妥当な範囲内の性能であるかについては，ベンチ マーク環境と組込みソフトウェアの実行環境との差を考慮する必要がある．

表

3.2

より，ベンチマーク環境は

CPU

のクロック周波数が

1.86GHz

だが，

組込みシステムでは数

MHz

ということもあり得る．仮に

1.86MHz

のクロッ ク周波数であると考えた場合，同じ処理を行うのに

1000

倍の時間がかかる．

表

3.3, 3.4

の結果に

1000

倍した場合，メソッドディスパッチはさらに

100

倍しても約

0.68ms

である．レイヤアクティベーションはパーシャルメソッ ドの個数が増えるたびに増加する時間を

0.07ms

とすると，

1

つのレイヤに パーシャルメソッドが

100

個あったとしても

7ms

程度である．

3.5.1

項で示 した性能を満たしていることから，提案フレームワークが妥当な範囲内の性 能であるといえる．

3.5.3 ^他の COP 言語と比べた際の優位性

本項では，他の

COP

言語と機能，性能を比較することで，提案フレーム ワークの組込みソフトウェア開発における優位性を明らかにする．

機能面の比較

機能面について，

COP

言語に必要な要素は

3.3

節で述べた通り，振る舞い の変種，レイヤ，アクティベーションである．提案フレームワークでは，振 る舞いの変種としてパーシャルクラス・メソッドを宣言・定義でき，それら をまとめるモジュールとしてレイヤを記述できる．また，レイヤをアクティ ベート・ディアクティベートするための命令や，多くの

COP

言語とに用意 されている

proceed

命令を備える．これらのことから，

COP

言語に必要な 最低限の機能を備えているといえる．

他の

COP

言語と比べると，提案フレームワークには，2.4節で示したイ ベント駆動方式のレイヤアクティベーションのような，コンテキストを判断 し，レイヤをアクティベーションするための専用のモジュールは無い．これ については，今後の課題としている．

表

3.1

の機能をすべて無効にした場合に

COP

言語であるといえるのかに ついては，

proceed

以外の機能は提案フレームワーク固有の機能であったり，

第

3

章

RTCOP: C++

ベースのコンテキスト指向プログラミングフレーム

ワーク

51

ほとんどの

COP

言語にはない機能なので，無効にしても他の

COP

言語の 記述能力には劣らない．

proceed

については，無効にすることで複数のレイ ヤを組み合わせることが困難となり，他の

COP

言語に比べ記述能力が劣る こととなるが，

RAM

の削減効果が見込まれるため，アプリケーション次第 では有用である．

その他機能面で気をつけたいこととして，提案フレームワークがベースメ ソッドとして扱えるのは，仮想関数だけである点が挙げられる．この制約の ために，仮想関数以外の関数に対してレイヤの振る舞いを追加できない．こ れについて，筆者は元々の

C++

が仮想関数の変更しか認めていないため妥 当であるという立場をとっている．

性能比較

他 の

COP

言 語 と の 性 能 比 較 と し て ，

3.5.2

項 で 示 し た 方 法 に よ り ，

Subjective-C

³²⁾ の性能評価を行う．

Subjective-C

は

Objective-C

をベース とした

COP

言語である．

Objective-C

はネイティブコンパイラを前提と し，メモリ管理をガベージコレクションではなく参照カウンター方式の

autorelease

を標準ライブラリで使用する．これらのことから，動的性質が

強い言語ではあるので

C++

よりはある程度は性能面で劣る傾向があるが，

他の

COP

言語よりも比較的性能が良いことが期待できるため，提案フレー ムワークとの比較対象とした．

Subjective-C

の計測には，提案フレームワー ク同様に，

sys/time.h

の

gettimeofday

関数を用いる．

上記の結果を表

3.3

，表

3.4

に示す．メソッドディスパッチについては，

提案フレームワークが

0.004

μ

s

速く，ベース言語からの増加率も少ない．

レイヤアクティベーションについては，RTCOPの方が実行時間が短く，メ ソッドが増えた時の増加時間も少ないため，性能が上である．

これらの結果について，Subjective-Cの実装では，Objective-Cのリフレ クション機能を用い，レイヤアクティベーション時にメソッドのディスパッ チ先を決定しているため，メソッドディスパッチにかかる時間は短めであ る．一方，レイヤアクティベーションでは，全てのメソッドのディスパッチ 先の決定を

Objective-C

のリフレクション機能を用いて行っているため，時

ドキュメント内 九州大学学術情報リポジトリ (ページ 58-66)