ハクソク

世界を動かす技術を、日本語で。

効率的なコンピュータの「Electron E1」CPU – Armより100倍効率的？

304日前原文(morethanmoore.substack.com)

概要

Efficient Computerは、従来のCPU設計を根本から見直す新興企業。 Electron E1チップはデータフロー制御による静的スケジューリングを採用。 従来のキャッシュやアウトオブオーダー設計を排除し、省電力性能を大幅に向上。 C++やRustなど一般的な言語に対応し、組み込み市場向けに最適化。 今後の課題はツールチェーンの成熟度と実用性、そして市場での信頼獲得。

Efficient ComputerとElectron E1の革新性

  • Efficient Computerは 従来型CPU設計 への疑問から誕生した新興企業
  • Electron E1は 組み込み市場 向けの新規設計プロセッサ
  • データ転送 のエネルギー消費を最小化するため、コントロールフローモデルを排除
  • 静的スケジューリング とデータフロー制御によるアーキテクチャ
  • キャッシュ、アウトオブオーダー、VLIWやDSP設計を用いない 汎用プロセッサ

Electron E1のアーキテクチャ

  • 独自ISA とスマートコンパイラスタックを採用

  • Spatial Data Flow Architecture（空間的データフローアーキテクチャ） を基盤

  • 命令は 中央パイプライン ではなく、各タイル（計算ノード）に割り当て

  • データは必要なタイル間で直接流れる バッファレス構造

  • プログラムカウンタやグローバルスケジューラを持たない設計

    • 各タイルは 演算・論理・メモリアクセス 等の基本動作が可能
    • C++やRustコードを データフローグラフ に変換し割り当て

  • プログラムがチップ容量を超える場合は、 パイプライン再構成 で対応

    • ループや繰り返しパターンは タイルごとの小キャッシュ で効率化

  • タイル間インターコネクトは 静的ルーティング かつバッファレス

    • フロー制御やリトライロジック を排除し、ツールチェーンに責任を委譲

コンパイラとツールチェーン

  • Clangベース のコンパイラフロントエンド
  • C++やRustに加え、 PyTorch・TensorFlow・JAX などMLフレームワークにも対応予定
  • ツールチェーン「 effcc」は、従来はサンドボックスだったが E1公開で本格運用
  • effccは通常のコードを Fabricの空間的データフローモデル に変換
    • グラフ分解、タイル割り当て、構成生成、パイプライン管理を担当
  • コンパイラが 静的に全てを解決 するため、効率性と引き換えに高い知能が求められる

性能・省電力性と市場への影響

  • Electron E1は ARMの組み込みコア比で最大100倍のエネルギー効率 を主張

    • 比較対象は Cortex M33, M85, A5クラス

  • 主な指標は「 operations per joule（1ジュールあたりの演算数）」

  • CEOは「 TOPS per watt」も強調

    • ただしTOPSは AIアクセラレータ 向きの指標であり、汎用CPUの評価には注意が必要

  • 実シリコンの提供、内部ベンチマークの公開、 開発キットの準備 など進展あり

  • 省電力性以外にも メモリフットプリント、割り込み遅延、再構成時間、I/O競合、ソフト互換性 が重要

今後の展望と課題

  • Electron E1は 製品ロードマップの第一歩

    • 次世代E2や大規模版Photon P1も計画中
    • スタンドアロンSoCや IPライセンス提供 も視野

  • 主なターゲットは 航空宇宙、防衛、産業センサ、ウェアラブル、宇宙システム

  • 研究から 製品化段階 へと進みつつあり、信頼性・予測可能性が重視される組み込み市場での挑戦

  • ツールチェーンの成熟度、デバッグ環境、サプライチェーン、長期供給体制など スタートアップとしての課題 も多い

  • 長期供給が必須な組み込み分野での 市場浸透の難しさ

  • もし成功すれば、 従来進化の延長線上にない本当の汎用CPU 誕生の可能性

まとめと今後への期待

  • Efficient ComputerのE1は CPUアーキテクチャの常識を覆す試み
  • 実用性やツールチェーンの完成度が 普及の鍵
  • 「 Doomは動くのか？」という定番の問いに象徴されるように、 実際のアプリケーション対応 も注目点
  • 今後の詳細情報公開と、 実際の組み込み市場での評価 に期待

Hackerたちの意見

このグリッドベースのアーキテクチャ、Zactronicsのプログラミングゲーム「TIS-100」を思い出すな。

└

私も同じことを思ったよ :-)

これが一般的なコンピューティングに最適化されたARMより100倍効率的である確率：1/100%だね。

これはCGRAだよ。FPGAみたいだけど、セルが大きいんだ。VLIWコアではないと思う。過去の試みと同じように、コードが一つの配列に収まるときは約20倍効率的だと思うけど、コードサイズがちょっとでも大きくなると、グリッドの設定を切り替えなきゃいけなくて、その分時間と電力がめっちゃかかるんだよね。

└

確かに「FPGAっぽい」よね。さらにスイッチングの最適化があるのか気になるな。

└

私の理解では、彼らはグリッド構成のキャッシュを持っていて、グリッドの接続性を変更する際の時間や電力コストを減らそうとしているみたいだね。

└

うん、少し前にFPGAを使ったことがあって、その分野をカジュアルにフォローしてる。一般的なプログラミング言語をFPGAにマッピングしようとした試みはたくさんあったけど、どれも上手くいかなかった。彼らが最初に主張する「これは一般的なCPUで、何でも実行できる」っていうのは、怪しいと思う。CPUはメモリとやり取りしなきゃいけないから、基本的にCPU設計の複雑さの95%はメモリとのやり取りから来てるし、他のデータハザードも扱わなきゃいけない。もしこれが簡略化できるものなら、もうやってるはずだよ。

└

MathstarのFPOA（フィールドプログラマブルオブジェクトアレイ）が似たようなアーキテクチャを持ってたのを思い出した。スタックコンピュータとこれ、さらに非同期プログラミングを組み合わせてこのレベルの最適化を実現したみたいだね。他に見た中で、チップ上のファブリックがかなり良かったのはTileraで、たくさんのチップ上コアを接続するためにパケットスイッチみたいなものを使ってた。動画を見たときの最初の反応は、結局コンパイラに問題を押し付けてるだけじゃないかって思った。これは実際には悪化するし、たくさんの分岐を持つ動的コードにはうまくいかないよね。それに、インテルもイタニウムでこれをやろうとしてたけど、かなりお金を無駄にしたんじゃなかったっけ？全体的には面白いアイデアだけど、「問題を探している解決策」って感じでファイルに入れちゃった。

これはデータフローアーキテクチャだね。ハードウェアの実装はここに書いてあることにすごく似てると思う： https://csg.csail.mit.edu/pubs/memos/Memo-229/Memo-229.pdf。問題はデータの局所性を活かすのが難しくなることと、コンパイル時にできる最適化には限界があることだね。それに、こういうアーキテクチャの動機（例えば、フォン・ノイマン型アーキテクチャのILPの欠如）は、現代のアウトオーダーコアには存在しないんだよね。

└

アウトオーダーコアは、無効化やパイプラインフラッシュ、分岐予測などに、インオーダーコアの10倍以上の論理回路とエネルギーを使ってるんだよね… すべてはパフォーマンスを上げるために。だから、このアーキテクチャはパフォーマンスを犠牲にして、ジュール/命令を減らそうとしてるんだ。パフォーマンスのためにエネルギー使用を増やすわけじゃないよ。

すみませんが、誰か15歳の僕に説明してくれませんか？夜遅いし、また別の迷宮に入るわけにはいかないから、助けてもらえるとありがたいです。よろしく、HNの皆さん、おやすみなさい。

└

おそらく無理だね。これは大学院レベルのコンピュータアーキテクチャだよ。

└

この動画がいい説明になってるよ。 https://youtu.be/xuUM84dvxcY?si=VPBEsu8wz70vWbX4

└

もちろん。シンプルな伝統的CPUは、時間の中で一つずつ命令を実行していると考えられるよ[1]。命令を取得して、デコードして、算術や論理演算、またはメモリ操作を行って、命令が完了したと見なされるんだ。エフィシエントアーキテクチャはCGRA（粗粒度再構成可能アレイ）で、時間ではなく空間で命令を実行するんだ。コンパイル時に、エフィシエントコンパイラはプログラム内のすべての「展開された」命令（とデータ）で構成されたグラフを見て、それをハードウェアユニットに空間的にマッピングする方法を決定するよ。もちろん、グラフが一度にハードウェアに収まらない場合もあるから、その場合は時間をかけてバッチで実行するために分割する必要があるんだ。でも、重要な違いは、空間的なアンローリングが行われていることなんだ。これにより、命令やデータを取得してデコードする作業の多くが省かれるから、いいことだよ。ただし、プログラムはほとんど静的でなければならない、つまりCPUに比べてデータ依存の分岐やループが非常に限られることを意味するんだ。だから、コンパイラがC++やRustなどをサポートしていると主張しても、通常考えるようなポインタや動的に割り当てられたオブジェクトはサポートしていない可能性が高いよ。[1] ほとんどの現代のCPUは実際には一つずつ命令を実行しているわけじゃないから、それはプログラミングを簡単にするための抽象化なんだ。内部では、シングルコアCPUでもいろんな再配置や同時実行が行われていて、主にメモリのアクセスがオンチップのレジスタやキャッシュよりも遅いことを隠すためなんだ。

└

大きなコアがほぼ独立して並列に動いている代わりに、すごく小さなALUコアがたくさんあって、それを使って長いカスタムパイプラインを構成できるんだ。各ステップは必要に応じて広くしたり狭くしたりできる。大きなコアに何度も命令をストリーミングする代わりに、カスタムパイプライン回路を設定して、それぞれがデータを使い切るまで動かす感じ。さらに、各パイプラインが必要とする操作（タイル）の数によって、複数のパイプラインを並列で動かすチャンスもあるよ。

グリーンアレイのGA144にすごく似てるね！残念ながら、独自の奇妙なFORTH方言がないと、E1は前のモデルほど市場での traction を得られないんじゃないかな。

└

それが私の最初の考えでもあったよ。相互接続されたノードの配列ってアイデアがすごく好きなんだ。生物的な何かを感じるし、トポロジーや隣接の拡散について考えるのが魅力的だね。

これは特定のケースでは価値があると思うけど、今日の多くの組み込みデザインを考えると、CPUやマイクロが本当にこれらのシステムでのエネルギーホグなのかな？私たちは骨伝導スピーカー付きのEEGヘッドバンドを作っているから、電力の観点では、スピーカーやLEDがマイクロコントローラーよりも桁違いに高いんだ。画面があるものでは、その画面が全ての電力を吸い取るし、無線通信機器などもそうだよね。もっとエネルギー効率の良いCPUが違いを生む特定のユースケースがあるのは分かるけど、人間インターフェースがあってCPUがボトルネックになるようなものは思いつかないな。ただ、私が完全に間違っている可能性もあるけど。

└

人間インターフェースはもちろんだけど、産業用センサーIoTの中には、無線を起動する価値があるかどうかを判断するために、非自明なエッジ処理を行うものもあるかもしれないね。そこでは役立つと思う。低消費電力のLCDや電子ペーパーのディスプレイを持つスマートウォッチでも、プロセッサが電力チャートでより目立つようになるかもしれない。もしセル数が限られているなら、コプロセッサとして機能する可能性もあるかな？最適化されたチップでDSP作業を行って、コードサイズが大きいことが分かったら高価な無線ソフトデバイスに引き渡すとか。

└

これが典型的な腕時計型ウェアラブルのように、ほとんどの時間スリープしている低消費電力コントローラーと競争できるとは思えない。でも、ループが何度も実行される場合、ファブリックを設定するためのコストはやる価値があるかもしれない。例えば、ウェイクアップワード検出の連続音声ストリームや、補聴器、EEGからの連続信号みたいな感じ。一般的なCPUを1MHzで動かす代わりに、ファブリックを使ってループを展開するんだ。すべての個別操作に100個のビルディングブロックを使う。命令を一つずつ実行するのではなく、各ビルディングブロックで各サイクルに一つの操作を実行できるパイプラインがある。だから、計算は1/100のクロックで動かせる。例えば、受信データの10kHzサンプリングレートみたいにね。クロックの各ティックがデータをパイプラインを通して一歩ずつ進める。マーケティングがどう考えているかは分からないけど、「ビルディングブロックの10x10グリッドを作ろう、全部使えばクロックは1/100にできる… バン！最大100倍効率的だと主張しよう！」って感じかな。彼らのコスト削減の見積もりがもっと詳しいことを願ってるけど。

タイル間のインターコネクトは静的にルーティングされていて、バッファもない。コンパイル時に決まるんだ。フロー制御やリトライロジックがないから、もし2つのデータパスが衝突する場合、コンパイラがコンパイル時に解決しなきゃいけない。これがデザインの中で一番面倒な部分に思える。静的スケジューリングをうまくやるのはすごく難しい。小さなことが終わるのを待つために、全てを止めなきゃいけない状況も出てくる。静的スケジューリングが95%の時間はうまくいくけど、5%のケースで何か面倒なことが起きることもある。動的な振る舞いやデータ移動ができないと、小さなコーナーケースがシステム全体の動作に影響を与える。面白いことに、ハードウェア設計でもこの問題が見られるよ！ロジックゲート間の全てのパスは、ターゲットクロック周波数に達するために最大の長さが必要なんだ。しばしば、動作のコーナーケースに関連する長いパスがあって、解決するのにかなりの手間がかかることがある。

└

読み間違えたかな？それともこれって基本的にクロックがないの？過去には非同期設計（ARM6コアの）もあったけど、あまり注目されなかったよね。

純粋な好奇心からなんだけど、これってコプロセッサとして機能するのかな？一番非効率的な手続きを取り出して、ファブリック用にコンパイルする感じ？それとも、コアやプロセッサ間でデータを送るために余分なプロセスが必要になって、得られるものが全部失われちゃうのかな？2Dってどんな感じなの？ファブリックにコンパイルするのは難しいルーティングが必要そうだし、3Dだとルーティングがもっとコンパクトになる気がする。

└

3Dって何を意味してるのか、どう使われるのか気になるな。例えば[0]のようなものであれば、これは低消費電力のマイクロコントローラーだから、3Dではないって自信を持って言えるよ。この技術は主に高価なHPC/AIチップで使われてるし、3Dスタッキングのロジックダイはあまり一般的じゃない（もし反例があれば教えてほしい）。メモリダイのスタッキングはHBMのようにもっと一般的だよ。提案されたコプロセッサは、実際には従来のCPUとの3D統合から恩恵を受けるかもしれない。インターコネクトやメモリチャネルの数が、データを処理要素にもっと直接ルーティングできる可能性があるからね。こういうのは、[1]の「2.5D」スタッキングで提案されていて、HBM（3D）が128チャネルのFPGAに接続されている。

└

もしかして、プログラムのグラフについて言ってるのかな？それがハイパーグラフとして表現される方がいいのか、2Dレイヤー内の特定のレギュラーエッジと2Dレイヤー間のハイパーエッジを持つ形で？もしそうなら、いい質問だね。答えは分からないけど、特定のデータのローカリティを助けて、データの移動や混雑の問題を減らすための便利な抽象レイヤーになると思うよ。

100倍効率的って、どんなコストで？もしPentium 2より遅いなら、埋め込みユーザー以外は誰も欲しがらないよね…。

└

組み込みプロセッサの販売数はデスクトップCPUの何倍も多いから…結局のところ、たくさんの人がそれを欲しがるってことだね。