--------------------------------------------------------------------------- セッションSC-7 プロセッサアーキテクチャーとリアルタイムシステム 〜ハードリアルタイムシステムにキャッシュを使うの?〜 高野さん,冨山さん 参加者 20名程度 TO セッションの紹介 SWESTも6回目,内容が昔と違ってハードウェアよりからプロセス管理に移っ ていた。 SWで明示的に制御出来ないハードウェアの機能についてSWに与える影響につ いて検討したいと思います。 リアルタイムシステム 正しさが出力の値だけでなく,その時間にも依存するシステム 通常デッドラインを持つ ハードリアルタイムシステム デッドラインが満たされないと,価値が無くなり,あるいは,重大な損害 を与えるシステム。 プログラムの最悪実行時間を正確に見積ることが重要 最悪実行時間の見積もり 基本的に全ての実行パスについて実行時間を見積もる必要がある。 更に悪いことに,最近のプロセッサは複雑 パイプライン キャッシュ 分岐予測 仮想記憶 スーパースカラ アウトオブ・オーダー メモリの性能 << プロセッサの性能 キャッシュがシステムの性能を決める プロセッサとDRAMの性能が広がっているため プログラムの実行時間 実行時間 = CPUの実行時間 + メモリアクセス時間 CPU時間 = 命令数 * クロックサイクル時間 X CPI メモリアクセス時間=アクセス数xクロックサイクル数xミス率xミスペナルティ シングルプロセッサの場合は理想的にはCPI=1実際はCPI=1.5 メモリアクセス数 = 命令数 x 1.2程度 ミスペナルティは、キャッシュの構成やDRAMの性能に依存するが,10〜40 サイクル程度 キャッシュの振る舞い シングルタスク内でもキャッシュの振る舞いを予測するのは困難である。 単純なパス解析では判定できない。 マルチタスクシステムでは,プリエンプションが発生した場合にキャッシュ の中身が変わってしまう可能性があるため,解析が困難で実質無理である。 質問 ハードリアルタイムシステムを設計したことがありますか? どの程度正確に最悪実行時間を見積る必要がありますか? どのように最悪実行時間を見積っていますか? ハードリアルタイムシステムを設計したことがありますか? 3名 挙手した3名に意見 A CDプレイヤー ATAからデータを送り込んでD/Aコンバーターに送るもの。 わざとD/Aコンバーターのバッファを少なくした。 基本的にいまのプロセッサはリアルタイム性がなくなっており,外部に出 している。典型的なものはPCで,ビデオやサウンドカードは外部のハード ウェアでリアルタイム性を確保している。 昔のCD-Rでは,バッファオーバーランエラーが出てしまっていたが,現在 はCD-Rドライブの方でカバーしている。 TO どうやってリアルタイム性を確保したのか A フィルタ処理のDSPを使っているのですが,アセンブラで書いているので,メ モリ速度を元に計算をした。機械的な処理なので,性能は見積もりやすかたっ か。一応見積もりの段階でおおよそ確認してからプロジェクトをスタートし た。M32Rを使って内部のSRAM64kを使ったのでリアルタイム性の確保をした。 命令キャッシュが8Kでプログラムは全てそこに入れようと頑張ったが無理だっ た。 B 二つやった。125u毎に割込みが入ってその間にある処理をしなければならな かった。キャッシュが無かったので計算した。4byteのバッファがあり500u 毎の処理をする必要があった。この割込みを最高優先度の割込みを割り当て て保証した。 TA 32bitRISCが広まってきた. 32bitプロセッサは,プロセッサ屋には昔の話に なっているが,ビジネス的には今ホットになっていると感じる. 最悪実行時間の見積もりに難 プロセッサアーキテクチャの影響 pre-fetch機能付きbufferでもSRAM+DMAでもない 車やMPEGで使われている。 プロトタイプは普通のキャッシュがあるPentiumを使うので,この様なも のはプロトタイプから実装に繋がらない 事例 : 後方監視システム (SWEST3での招待講演内容から) 追い越し車両の検出 追い越し時にアラーム レーン検出 プロセッサのブロック図 SRAM + DMA キャッシュ(I:4k, D:4K) キャッシュをメインで使うように設計,キャッシュの見積もりが甘かった 要求性能 : 30fps プログラムもその程度の性能が出るように設計したが実際は5fpsだった タスク内の分岐レベルの話。 キャッシュのミス率は5%程度だった チューニング 1. コード配置の調整(IF分高速化) 2. FW担当者のアーキテクチャー理解深まり,アドレス計算のSIMD化 3. DMA転送ダブルバッファ化 オリジナルのコードから掛け離れてしまい,コードが汚くなった。 A キャッシュのヒット率はどれぐらい TO 命令なら98%ぐらい TA 逆に命令なら98%ぐらいないとキャッシュを使った意味がない。キャッシュを 考慮したシミュレータを使ったが,流せるサイズが限られているので,実際 に近い条件での性能評価は難しい TO キャッシュのワーストケースの見積もりはシミュレータでいいのか TA 上の方で押さえるのは可能なのか. ヒットしないことを前提にプログラムしては いけないのか。 A それは有り得ない。 TA シミュレーションと実機とのギャップを少なくする方法はないのか A コンパイラでキャッシュを意識したコンパイルをしてくれるのだろうか。 極力アライメントを合わせてくれるとループがキャッシュをうまく使える。 一回しか使わないコードと何回も使うコードを区別してくれてキャッシュw効 率的に使える。 D コンパイラにはそのようなオプションがあるものがある。 TA 特許なら多くありそう。不正確性を上げる方法は多くある。 ノンブロッキングキャッシュがあれば,ある方法はある。 普通のキャッシュなら一回のミスのレイテンシが プロセッサ屋さんは高速化は興味があるため,最悪性能はあまり興味ない。 E 先ほどの例はどのように対処したのか。 TA 木構造で関数を呼び出す。ジャンプして戻って来たときに関数がキャッシュ から追い出されないように,人間が頑張って配置しなおした。 E キャッシュがキャッシュするコードとそうでないものを指定できればうれし い。 TA 一つ一つのタイムスライスレベルなら制御できる。割込みの方が予想が難し いのでないのだろうか。 E ハードリアルタイムで何でもかんでもやってしまおうというのは難しいので, 現実回としては,マルチプロセッサ化をした方が簡単なのではないだろうか。 汎用のプロセッサでハードリアルタイムは無図かし A キャッシュに欲しい機能。ある番地からデータをキャッシュに取り込む機能。 TA SRAMを使えばいいのでは? A SRAMがなく,キャッシュのみを持つプロセッサが多いため困っている。 組込みはループがなく,一直線で進むものがあるため,キャッシュよりSRAM の方が都合が言い場合がある。 ライトバック機能の場合はもっとひどいことが起きる。キャッシュを大きく しても意味がない。 E ハードリアルタイムをするからには,コードを小さくして全てキャッシュに のるようにする必要がある。 TA キャッシュのロック機能。プリフェッチはできないですが,キャッシュに一 回取り込んだ後にパージしないようにロックできる。 TO そのような機能なら,ますますSRAMでいい B リアルタイム性が必要な部分以外の他の部分もある程度早くしたい場合なら, キャッシュは必須。 E マルチプロセッサにしてリアルタイム性の必要な部分を分けないと,いつま でたっても実現は難しい。 TO スクラッチパッドメモリはどうか E 全てがそこに入ればいいのでは。 A 今回のテーマは,キャッシュの乗っているプロセッサでリアルタイム性を確 保したいということなのでしょうか。 TA 普通に売られているプロセッサはキャッシュが多く乗っている。いまあるも のを使わないといけない状況では,しょうがないのでは。 TO 分岐予測やスーパースカラーはソフトウェア設計の手間を省いてくれる。キャッ シュも同様に考えられないか。ソフトウェアの規模が大きくなると細かい最 適化は難しくなる。 最適化が出来る規模は? TA 画像処理等のアルゴリズム系の処理ならなんとかなるが,制御は難しいと思 う。また,その比率で決まる。 A RISCプロセッサでは命令が大きくなっていしまい。Cの一行が一ラインになり そうな気がしてる。 E 画像処理の例のサイズは? TA 忘れました. F エンジン制御の場合,クランク角度に応じて処理する。噴射処理等はクリティ カルでキャッシュは不可能だが,目標値を計算する場合はキャッシュは使え るかも。 TA こういったものは,キャッシュなんか使わずチューニングするのではないだ ろうか。 F そうだが,目標値計算等は,複雑になりすぎてチューニングは不可能じゃな いだろうか。また,割込みが負荷が高い。 G マルチプロセッサにしない理由 F 値段の問題である。 TO 制御するソフトウェアはキャッシュを使っているのか? F 意識していない。許可していない。 TA 割込みのチャネル数が多い。コントローラのカスケード段数が多いため,割 込み性能が下がる。 G 割込みが適切でない用途もあるではないのだろうか TA 技術的なベストでなくとも,文化があるので。 A カメラの入力にCPUでスーパーインポーズをかけている。 外側にメモリは無 く,水平同期信号信号で割込みをかけ,割込みハンドラの頭でDMAのスタート をかけている。 昔だと,性能的にきつかったものが,現在なら32bit 66Mhz M32R 内部 SRAM64kで行っている。OAKS32Rを使っている。 H Amigaというパソコンも割込みとDMAで画面を書いている TO この程度のサイズなので動いているでは。 A キャッシュもMMUも殺してSRAMにしてもらえると非常にうれしい。 B 時間を保証したいのか,ばらついているのがいやなのかどちらだろうか。 TA リアルタイム性をもたせるのに処理量を越えるハードウェアリソースを 持ってくるという方法もあるが,これは現実的でない。 B 何故現実的ではないのか? TA 常にギリギリのところ(例えばコスト,納期,処理量)でやろうとしているため, このような問題が出てきて辛くなる。 A CPUがリアルタイム性能を持っていると,周辺が軽くなって結果的にコストが 下がると考えている。 N リアルタイムを行うということは,ソフトウェアもそれなりに小さいはず。 回りにハードウェアを持つと行くとは,ある程度大きいものでは A ある程度大きいリアルタイムシステムとしては,ページプリンタがある。 A4 30枚/1分 だと結構な処理が要求される。現在はハードウェアで実現して いるが,プロセッサで出来ればそれらが要らなくなりコストダウンが図れる のでは。 N オールマイティーなリアルタイム保証が可能なCPUというのはありえない。 あっても汎用CPUほど売れないと意味がない。 B キャッシュはベストエフォートだから,そもそもそれをリアルタイム性を持 たすのがおかしい。 TA 慶応の山崎先生が紹介されたマルチスレッドのプロセッサ A 命令フェッチはどうしているか。命令のfillが問題なのでキャッシュを使っ ている。 TA マルチスレッドの前提として,バスが空いているという前提がある。 ここで 話している粒度では,マルチプロセッサでは変わらない。 B IキャッシュとDキャッシュを分けて考えてる必要がある。 結論 リアルタイムシステムにはキャッシュは向かない。それよりSRAMが欲しい システム全てがリアルタイム性を持っている分けではないため,そのような ものには有用である。 キャッシュより割込みを早くしてもらいたい。 マルチプロセッサ化する。 外部をハードウェア化する。