2010年8月22日から24日にかけてスタンフォード大学で開催されたHot Chips 22において、カリフォルニア大学サンディエゴ校のNathan Goulding氏は「GreenDroid」と呼ぶ新しい考え方のプロセサについて発表を行った。この発表は、今回のHot Chipsでは唯一の大学からの発表である。

GreenDroidについて発表するGoulding氏

プロセサの世界ではマルチコア化が進んでいるが、そんなにコアがあっても消費電力の制約で動作させられないダークシリコン(敷設してあるが使われていない光ファイバをダークファイバと呼ぶが、それをもじった造語である)になってしまう。そして、微細化が進むにつれて、このダークシリコンの比率がどんどん増えてしまう。

Goulding氏は、このダークシリコン部分を高い電力効率で専用的な処理を行うConservation Core(C-core)と呼ぶ処理機構を作るのに使うべきであると提案している。汎用CPUコアの数を増やすのではなく、 GPUを集積したり、ビデオのエンコーダを入れたりということで、電力効率の高い専用回路を入れるということはすでに行われてきているが、C-coreの考え方は、これらの専用処理ユニットとは異なりもっと汎用的に各種の処理に適用できる。

携帯分野では、まだ、シリコンがあまる状況ではないが、消費電力は最も重要な要素であることは確かである。そして携帯でも遠からずダークシリコンが問題になるという見通しからGoulding氏はAndroidを対象に選んで研究を行っている。

AndroidのソフトウェアスタックとC-coreの適用部分

Androidのソフトウェアスタックは、Linuxカーネルの上にライブラリとDalvik仮想マシンが載り、その上でアプリケーションが動くという構造になっている。この図で黄色い水玉で書いた部分は、それぞれのソフトウェアの中で実行頻度の高いHot Codeを抜き出し、その部分を効率的に実行することが出来るC-coreハードウェアに置き換えるということを示している。

Androidアプリケーションを実行した場合のダイナミックな実行カバレージ

Androidのブラウザ、メールなどの各種アプリを分析した結果、汎用的に使われているコードが全体の実行命令の72%を占め、専用的なコードも含めて4万3000命令をC-coreハードウェア化すれば、実行命令の95%をカバーできるという。

C-coreであるが、ソフトウェアの中から頻繁に実行される部分を抜き出し、それをハードウェア化する。

sumArray(int *a、 int n)
{
  int i = 0;
  int sum = 0;
  for (i=0; i<n; i++) {
    sum += a[i];
  }
  return sum;
}

という配列aの要素の合計を求める関数がHot codeであるとすると、これをC-coreコンパイラでコンパイルすると、次の図のような回路が作られる。

sumArrayをC-core化した場合の回路とシリコン実装

この回路はsum、配列aのアドレス、iとnの値を保持するレジスタと加算器や比較器、そしてa[i]のアドレスのデータをキャッシュから読んでくる簡単なロードユニットからなっており、45nmプロセスで論理合成と自動配置配線で設計すると、0.01平方mmのチップスペースで実現でき、1.4GHzで動作するという。

このような簡単な関数だけでなく、bzip2、cjpeg、mcfなどの9種の実アプリに対してもC-core化を行い、21個のC-coreを自動的に生成することが出来ているという。

9種のアプリケーションのソフトウェア実行とC-core実行のエネルギー効率の比較

そして、これらの9種のアプリケーションをオリジナルのソフトウェアで実行した場合とC-core化して実行する場合のエネルギー効率を比較したのがこの図で、9種のアプリの平均で13.7倍のエネルギー効率を実現している。

そして、これらのC-coreはCPU、D$、I$と一緒に1mm角の1つのタイルに集積され、チップ全体では4×4個のタイルを並べてメッシュのオンチップネットワークで接続するというイメージである。

このようにC-coreでハード化してしまうとソフトウェアに修正が入った場合にどうなるかという問題があるが、それに対しては、CPUからC-coreに条件を設定する機構を設け、その条件を満たした時にCPUに例外を上げて通知し、ソフトウェアの修正部分はCPU側で実行して、また、C-coreが使えるようになったらC-coreのレジスタに値を設定して処理を続行するという。このようにするとエネルギー効率は低下するが、C-coreがまったく使えなくなってしまうわけではない。また、定数だけの修正であれば、CPUから渡すデータやメモリの内容を書き換えてやればC-core自体の変更は必要ない。また、ソフトウェア全体から見ればC-core化されている部分はごく一部で、ハードウェア化されたHot codeが修正される確率は大きくない。

C-coreを持つGreenDroidのタイル

16個のタイルをメッシュネットワークで接続したチップのイメージ

そして、Androidの実行からHot codeを抜き出してC-core化した場合の1命令あたりの消費エネルギーをシミュレーションで求めた結果を次の図に示している。まったくC-coreを使わずソフトウェアをCPUで実行すると91pJ/命令程度のエネルギーを必要とするが、C-coreの面積を大きくする(C-core化する部分を増やす)とエネルギーが減少し、7平方mm程度をC-coreに割り当てるとCPUとC-coreの合計の消費エネルギーは約1/8の12pJに減少する。

C-coreに充てる面積と1命令実行に必要なエネルギーの関係

ソースコードからC-coreを自動的に作るソフトウェアや、FPGAでC-coreを作ってAndroidの実行ができる環境ができており、現在は、Androidのどの部分をC-coreを作るかの最終決定とチップの設計と製造のためのテープアウトに取り組んでいるという。

このようにソースコードを直接実行するハードウェアを自動的に生成してCPUに組み込んでしまうというアプローチが本当にうまく行くのかどうか良くわからない点もあるが、大学での研究としては新しい着眼で、面白いアプローチである。