##はじめに
自己紹介
株式会社リコーテクノロジー13年勤め、現在はヘテロマルチコア向けのソースコード解析、最適化を行うSilexicaでField Application Engineer として勤めています。
記事内容
現在でもスプレッドシート(Excel)が、プログラミングの主流ツールとして使われています。ですがプログラミングの複雑さは増加の一途を辿っており、組込みエンジニアは、設計の際に経験に基づいた推測からコードのカット＆エラーを繰り返しています。SLXを始めとする最新のソフトウェアプログラミングツールを使用し、プログラムデザインを効率化する重要性についてお話をします。
##次世代プロセッサ
需要に先駆けて次世代プロセッサやSoCに様々な機能や特徴が追加されていたことはあまり昔のことではないように感じます。新しいプロセッサがリリースされた際には、組み込みソフトウェアデベロッパ達が、製品の差別化を目的として、新しい機能を活用する画期的な方法を常に考えていたことも思い出しますね。
さて、昨今全くもって状況は変わりました。ソフトウェアエンジニア達は、日に日に増えるコンピューティングパワーへの需要を満たすためのソリューションを探し、日々奮闘しています。半導体パッケージにいくつのコアを詰め込むことが出来るのか？と考える日々です。自動運転、AI、および5Gなどは、ソフトウェア開発者がセミプロバイダーに対して、更なるコンピューティングパワー持った製品を提供するよう求めている例の一部です。
自動運転やAIといったバーティカル市場を考えた時に、将来の事まですべてきちんとした計画を持って物事が動いているように感じます。現代のマルチコアSoCの容量だけでなく、将来的なメモリー容量ですら既にどう消費していくかが決まってる、といった具合に。
しかし現実組込みプログラムデベロッパーには、次世代機能向けのコードを生成しつつ、半導体とコードリファクタリングを通じた既存システムの最適化が求められています。つまり、未来のプログラミングだけに集中することは出来ず、現在のシステム最適化も同時に進めることも求められており手一杯な状態です。もちろん既存のシステム最適化は複雑な作業の為むしろ仕事の多くが未来ではなく現在に向いてしまっていることも多くあります。例えば、自動車において分散型コンピューターが中央演算処理装置に取って代わられた AUTOSAR ClassicからAUTOSAR Adaptiveへの移行。これは、単純に半導体サプライヤーに対して、新たな組み込みコンピューターの提供を強制するだけに終わってしまいました。
##膨大な時間の消費と作業
より多くのコアがSoCに追加され、より多くのソフトウェアが統合されるにつれて、ソフトウェアデベロッパはシステムの最適化に多くの時間を費やすことになります。たくさんのコアがあるということは、プロセス、タスク、スレッドを分散するためにより多くのオプションを生み出します。下の順列の式を思い出すことで、どれほどの選択肢を考えなくてはならなくなるのかを考えていただけると思います。
nCr = n！ / r！（n-r）！
つまり、利用可能なコア数とマッピングされるソフトウェアタスクの数に応じてさまざまな組み合わせがあり、その選択肢は簡単に数千に到達します。
また、その際に課題になるのはマッピングではなく、テストマッピングが問題になります。タスクをコアに正しく配置し、システムをテストするには複雑なツールが必要になります。タスクの依存関係、メモリアクセスの負担、チャネルのオーバーヘッド、ソフトウェアの依存関係などを複合的に解析が出来るツールであり、ゼロサムゲームではないため非常に複雑です。
あるコアから別のコアにタスクを移すことで、メモリオーバヘッド、チャネル負荷、可変アクセスなど、その他の多くの依存関係性から遅延時間が発生する可能性があります。これにより、パフォーマンスに問題が生まれたり、タスクが放置されてしまったり、といった状況が生まれることがあります。EDAツールがハードウェアエンジニアの大きな助けになったのに対し、ソフトウェア開発者には開発ツールが多くないことからハードウェア開発者に比べてやや難しい状況に置かれているでしょう。
EDAツールは、設計の複雑化にも対応しハードウェア開発者の生産性を向上させました。その一方で、ソフトウェア開発ツールの発展は全く進んでいません。
いまだに、スプレッドシートを使用してタスクマッピングとスケジューリングを導き出していることからもわかると思います。シンプルな問題を解決するのに、スプレッドシートはおそらく完璧なツールでしょう。しかし、問題はもはや一次元的な問題ではなく、多次元的です。ルービックキューブによく似ています。それでも、今日利用可能なツールは、過去に使用されたものと同じ直線的な考え方しか出来ないツールです。
つまり誰かが新しく何かを始める際には、仮説を作り検証しなければならない、ということです。
##「what-if」分析を行うツール
仮説が証明されることにより物事は学問的になり、普遍化します。証明されていない仮定は依然として仮定です。現状、ソフトウェアデベロッパーには、メモリアクセス、通信チャネルなどのオーバーヘッド負担を伴うタスクマッピングやスケジューリングをテストするための「what-if」分析を行うツールがないので、仮定を検証することは困難です。
仮に、比較的簡単な質問であっても経験則から答えるのは難しいでしょう：例えばプログラムには4つのコアが最適なのか、8つのコアが最適なのか。また、パフォーマンス、パケット処理、および処理を改善するために、タスクをどのように配置すべきだろうか。といった質問です。
組み込みソフトウェアデベロッパーにとって、使用される可能性のあるツールは、コストがかかりすぎるか、遅いか、スケーラビリティがないか、または利用できないかのいずれかでしょう。
そのような現状を踏まえて、仮説(ソフトウェアにおける新たな試み、様々な「What-if」)に対し検証が行える数少ないツールであるSLXを導入するというのは、単純に現在の開発環境を改善するというメリットに加え、仮設の普遍化が期待できます。