##はじめに
自己紹介
株式会社リコーテクノロジー13年勤め、現在はヘテロマルチコア向けのソースコード解析、最適化を行うSilexicaでField Application Engineer として勤めています。
記事内容
並列化によるアプリケーションの複数部分の同時作動
マルチコアシステムの『時間＆コスト』の問題について
##目次
####並列化の課題
####ソフトウェアとハードウェアの組み合わせ
####困難な非決定論的環境
####HWとSWの概念
####静的ソースコード分析
####並列化のギャップ調整
##並列化の課題
マルチコアシステムのプログラミングで最も時間とコストが掛かるのは、多くの場合並列化の問題を解決することです。
並列化はアプリケーションの複数部分が同時に作動した際に、不確実性を引き起こす可能性があり、ソフトウェア開発者にとっては頭を抱える問題でもあります。設計段階でのトラブルが生じやすく、また検証段階でのコスト増加、遅延のような問題を抱えていることになります。
##ソフトウェアとハードウェアの組み合わせ
ハードウェアとソフトウェアのコンポーネント間の意図的および意図しない相互作用を理解することは、アーキテクチャがヘテロジーニアスになり相互接続トポロジが複雑になるにつれて変化しています。これは性能、消費電力またプロジェクトの費用に影響を与えるからです。多くの大学がソフトウェア観点からこの研究をする一方、ハードウエア側から研究している大学は極めて少なく、ソフトウェア/ハードウェアの組み合わせが新たなレベルへと繋がることうを見越し、分析する人は僅かと言っていいでしょう。
現代のシステムはマルチコアマッスル（マルチコアによるハードウエア強化）、そしてヘテロジーニアスにますます依存しているため、デバイスはシステムレベルでのみ発生する並列化関連のバグが生じやすくなってしまいます。これらのバグは、再現、理解また修正が非常に難しく、実際、数日から数ヶ月の使用後、初めてバグが現れるデバイスが出荷されるということを聞くことは珍しくありません。例えばプログラマーにとって見たことのない予期せぬソフトウェアデータ競合や、検証の際、カバーされなかったハードウェア同期プロトコルの規則違反が原因で発生するといったことも挙げられます。
ドライバーや埋め込みアプリケーションなどのハードウェアイベントがソフトウェアに深く相互作用した際、ハードウェアプロトコルからOS特権スペースまた、ユーザーアプリケーションに渡り、バグのある相互作用があらゆるレベルで発生する可能性があります。
##困難な非決定論的環境
並列化は、入力と環境設定、制御とデータフロー、実行スケジュール、コンポーネントなどのさまざまな組み合わせを何度も試して慎重に検討する必要があるため、エンジニアや開発者にとっては困難な非決定論的環境を引き起こすことがよくあります。 （例えば、キャッシュ、CPU内の分岐予測子、また開発者の管理下にない他の要因も多くあることが挙げられます。）
これがさらに複雑化することで、従来のデバッグや通常の侵入型プロファイリング方法はシステム状態を変えバグを隠してしまいます。しかし侵入方法論を考慮できた場合、多くのバグを発見することが可能です。
##HWとSWの概念
並列化を高めるにはソフトウェアとハードウェアの異なる分野からの高度な概念を習得することが必要になってきます。そのため、チーム、地域、予算、プロジェクトの各段階にまたがり、学際的な取り組みに移行されやすくなりますが、組織にその分野の専門家いなかったり、またタイミングがあわなかった場合、いい結果になるとは言えません。
またさらに、システムレベルでの依存関係、並列処理、および決定論について開発者が推論するのに役立つ特殊なたツールの供給が不足しています。
並列性についての理論は、それほど複雑化されてない時代のシステム方法論を今だ使用しおり、非常に頭を悩ます課題となっています。このことから開発者は、システム状態がとる可能性のある数百または数千の可能性を頭に入れながら、自分がまだ知らない要因の影響を予想しなければなりません。
設計時の並列化のバグ回避や、検証時にバグを検出するには、分類モデルの理解し、何度も抽象モデルを生成し、ハードウェアイベントのシミュレート、そしてシステムの決定論に影響を与えるソフトウェアアクションが必要になってきます。例えばミューテックスやOSスケジューラなどのSW同期プリミティブがこれらに該当します。
ソースデバッガやOSカーネルトレーサなどの従来のSWデバッグ方法を利用して依存関係や相互作用を理解するには侵入型性のため限界があり、この段階で開発者をサポートするために利用できる特殊な製品はまだほとんどありません。
HWシステムのSWモデルである、仮想プラットフォームといわれるシミュレーションなどは、設計およびデバッグ段階でいくつかの興味深いテクノロジーが役立っていることがあります。
##静的ソースコード分析
非侵入型環境でシステムレベルのHW / SWの相互作用分析は、誤ったシステム状態の検査と操作に役立つと証明されています。しかしながら、仮想プラットフォームはもちろんのことデバッグスクリプト、追加プラグインのカスタマイズ、展開、および維持にはコスト が掛かることも実状です。
またClang / LLVM 安全性分析拡張などといったPOSIXスレッドのようなSW環境の主流な並列をサポートする、コンパイル時のSW静的ソースコード分析のサブセットなども他の例として挙げられます。これはソフトウェア開発者がバグの回避や検出をする際のサポートをしていますが、静的解析には、すべての依存関係の正確な解決の欠如、C/C ++のような言語でのすべてのポインターアクセスの参照を外すことが不可能です。そして他のシステムレベルのイベントとの相関関係の欠如しているため、ソースコードセントリックのみの見方をしてしまう、といった制約があります。つまり静的解析は役に立ちますが、万全の解決策とは言えないのです。
##並列化のギャップ調整
Silexicaは、並列化のギャップを埋めるために、テクノロジの正しい組み合わせの開発に多くの年月を費やしてきました。SLXプログラミングツールは、静的情報と実行トレースからの動的データを関連付けるために使用されるClang / LLVMに基づくにしたソースコード解析エンジンによって強化されています。このSLXプログラミングツールは、静的および動的関数呼び出し、またデータアクセスの依存性、アクセス頻度、呼び出し回数、その他多数を明らかにすることを手助けします。また、スレッド化と同期のセマンティクスを理解し、アプリケーションフローで起こりえる影響を計算します。
SLXでは、create/joinの関係、スレッド間の共通関数、同期機能の使用、クリティカルセクション、共有変数、アクセス保護など、スレッド間の依存関係を識別することが可能になります。
最後に、マイクロアーキテクチャ内の利用可能なプロセッサ数などのハードウェア中心の特性を考慮するために、SLXはアプリケーション同期と通信パターンの抽象動作シミュレーションを可能にします。これにより、「既存スレッドのスケジューリングはどのように行われるか」や「スレッドが他のスレッドで待機するタイミング」「プラットフォームリソースでの矛盾やボトルネックが起こったら」といった「what-if」の質問をに対して的確に応えることができます。
困難な問題を避け、統合時の作業を短縮するためにも、現在の方法論を検討し、可能な限り早い段階で並列化の問題に目を向けることをお勧めします。