マルチコアとかCellに期待しすぎです。
肩透かし食らいますよ。
組み込み向けのマルチコアデバイスのペーパをちゃんと読めばわかりますが、マルチメディア系で求められているのは、マルチメディア処理の並列処理化です。
たとえば、MPEG4エンコードしながらMP3デコードとか。
アプリ設計者の視点から言えばもっとわかりやすいかもしれません。
MP3/AACのジュークボックスをガンガンに流しながら、当然ビジュアライゼーションを背景にして、MP4動画の動くサムネイル（だれかうまい名前考えてクサイ）を複数表示する。
いわゆる擦り合わせ開発では、ターゲットのコーデックに合わせた専用チップやDSPを利用するわけです。しかしバスボトルネックが出る。
ならばSoCしてしまえ、というのがトレンドではないですか？
GbE程度ですら、専用バスでマイクロプロセッサはペイロードに関してカヤの外です。
マルチメディア処理をプロセッサに担当させること自体無理があります。それこそx86系にのみ許された贅沢でしょう。さりとて、x86系であっても、バスボトルネックのために、たとえば、２台のDVDドライブから同時に高精細な動画を再生することができませんね。それ以前にビデオカードが同時複数のオーバーレイなんかに対応してませんがな。
メインのプロセッサがプアでなくても、ただ動画を再生するだけのためにCPUパワーを使い果たしてしまうのでは面白くありません。
逆転の発想で、コーデック専門のコプロセッサを内蔵すればメインプロセッサはプアでも構いませんね。
ASICやDSPを内蔵するかコプロセッサにするかは設計によるでしょう。gccが使いたければ、PPC風にしておきます。そうでないならなんでも構わない。
バスの親和性とか後付けでしょ。
日本では、古くから並列プロセッサの研究などがさかんであり、その前知識が普及しすぎなのです。小さいマッチ箱やお菓子の箱に詰めるプロセッサにそんな高尚なもの積んだってロクなアプリ動きません。
必要なのは、
- 動画コーデック
- 音声コーデック
- バスボトルネック最小
ビルディングブロック的にそれらを組み合わせるフレームワークだけです。ビルディングブロックとはファンクションブロックと書けばよいでしょうか。
ようするに、GraphEditのように構成が可変でいてしかもメインプロセッサのパワーを食いつぶさない仕組みさえあれば良いということです。さらに言えば、コーデック自体の中身も可変でないと困ると。
さて、最後に余録です。手続き型言語でデータの流れを記述することは無駄が多いです。
リアルタイムな入力を加工してリアルタイムな出力を吐き出す場合、
y=F(x)
的なシステム記述ができないと困ります。論理回路のレベルでは簡単に実装できるわけですが、なぜかソフトウェアでは書きにくい。それはチューリングの呪いなのかどうか知りませんが。
で、チューリングの遺言の後を追いかけて関数型言語マンセーと、レミング共が崖から飛び降りていきます。
シーケンス制御分野での金字塔IEC 61131-3を参照して下さい。
FBDはビルディングブロック式に制御を記述することができます。これなくしてプラント制御の記述はありえないでしょう。STやILで手続き言語風に制御を記述することができます。SFCがあれば条件遷移をそのまま実装することができます。
＃61131が標準として全世界で普及しているわけではありませんので注意
手続き型言語マンセーの世界では、ミソモクソもまぜまぜして記述しますからぐちゃぐちゃです。マルチスレッド対応C++？後付けフリテンでしょ。もうあきらめなさい。
で、IEC61131では、５つの言語で記述したもの同士が入れ子になれます。SFCの子要素としてSTが走る、というわけです。
こういう人も、きっと過去の歴史的文化遺産に興味が無いんでしょうな。足元の先達の屍が眼にはいらないというか。
まぁグダグダ書いてたって仕方がありませんね。
とにかく。関数型言語で書いたものと、手続き型言語で書いたものが、相互呼び出し
可能で、リンカでリンク可能、だけではだめです。Fortranの過去の資産をC/C++から呼び出して利用する、という間抜けなことをやるようなもんです。ラッパの嵐。すぐにデバッグ不能に陥ります。
さぁCLI周辺で新たな地平が開かれるのか、期待して待ちます。しつこいですが、リンク可能なだけではダメですよ。
