このページの本文へ

ロードマップでわかる!当世プロセッサー事情 第538回

AtomベースのSmall CoreがTremontと判明 インテル CPUロードマップ

2019年11月25日 12時00分更新

文● 大原雄介(http://www.yusuke-ohara.com/) 編集●北村/ASCII

  • この記事をはてなブックマークに追加
  • 本文印刷

Tremontの内部構造は
従来のAtomとはまるで別物

 さて本題。このTremontであるが、今年10月に開催されたLinley Fall Processor Conference 2019において、インテルは“Introducing Intel Tremont Microarchitecture”と題して内部構造を説明したので、この内容を解説しよう。

 まず基本的なアーキテクチャーであるが、まるで従来と別物に進化している。おさらいの意味で振り返ると、Atomのアーキテクチャーは、下表のように進化してきた(ここでissueはALUのみで、FPUは勘定に入れていない)。

Atomのアーキテクチャー推移
アーキテクチャー 命令同時デコード数 命令発行数 命令の実行順
Bonnell(45nm) 2-way Decode 2-issue In-Order
Saltwell(32nm) 2-way Decode 2-issue In-Order
Silvermont(22nm) 2-way Decode 3-issue Out-of-Order
Airmont(14nm) 2-way Decode 3-issue Out-of-Order
Goldmont(14nm) 3-way Decode 4-issue Out-of-Order

 そもそも最初のBonnellは1 x86命令/サイクルの構成で、2-issueというのはALUとAGUが1つづつのシンプルな構成である。

 これはロードをともなうALU命令を1サイクルで処理できるように、という話であって、IPCは1命令/サイクルが目標。そのままでは性能が低すぎるので2GHz動作にすることで、その前に利用されていたBanias/Dothanと同等以上の性能を確保するというアプローチだったが、性能の低さは否めなかった。

 これがSilvermontでOut-of-Orderを実装、限定的に2 x86命令/サイクルの処理性能を目指し、Airmont/Goldmontでこれを細かく改良した形だ。

 最新のGoldmont/Goldmont+ではデコーダーが3命令/サイクルに拡充されたものの、実行ユニットの数はそれほど増えていない(Goldmont+では分岐処理用にJEUというユニットが追加されたが、ALUそのものは2つのまま)ので、おおむね2 x86命令/サイクルという性能そのものは変わらない。

 以上を念頭に置いてTremontの構成を見ると、まるで別物である。

Tremontの構成。Decodeは後述するとして、Execution Portが10ポートで、うち3ポートがFPUなので、整数演算は7ポートとなる。ほぼGoldmontから倍増している

 まずFront End。従来とまったく異なる、3-way Decoder×2という、おそろしく強力な構成である。

命令キャッシュそのものはUnifiedだが、これを見る限り3ポート(L2→InstCache、InstCache→Decode #1、InstCache→Decode #2)構成のようだ

 さらに言えば、IP Queue(これはx86ベースの命令キュー)とInstruction Queue(これはMicroOpベースの命令キュー)も2組づつ用意されている。

 これは要するにハイパースレッディングを前提に、同時に2つのスレッドのデコードを行なえるシステムを実装したということだ。その2つのスレッドを最大で3命令/サイクルで処理できるというわけだ。

 ちなみに、気になるのは“Single Cluster Mode”なるモードの搭載で、言葉通りに読めば、ハイパースレッディングを無効にして、最大で6命令/サイクルのデコードが可能なモードもあるように見える。

2つのスレッドを最大で3命令/サイクルで処理できる。最大で6命令/サイクルのデコードが可能なモードもあるように見えるこれが、例えばBIOSでパッと切り替えられるような実装になっているかどうかは謎

 “on product targets”というのは、現在のAtomは単にローエンドのモバイル製品(や一部NUCなどの製品)のみならず、ネットワーク機器や組み込み機器などにも使われているからだ。

 こうした用途の中にはマルチスレッド性能が不要なのでシングルスレッド性能を上げてほしい、というものも存在するので、こうした特定用途向けにSingle Cluster Modeが利用可能、という話であろう。

 当然これだけ強力なデコーダーをちゃんと動かすためには、分岐予測やフェッチのメカニズムも相応に強化する必要がある。

2つのスレッドは別々の動きをするので、プリフェッチも当然Out-of-Orderで動くようにしないと間に合わなくなる、というのは理解できる

 とはいえ、こうなってくるともはやSmall Coreとは言い難いレベルな感じもしなくもない。ただ“Core class branch prediction”というのは現在、つまりSkylakeベースとなるCoffeeLakeやCometLake、あるいはSunnyCoveなどのCoreではなく、もう少し昔(SandyBridgeあたり?)の構成に近い、という意味かと思われる。

カテゴリートップへ

この連載の記事

注目ニュース

ASCII倶楽部

プレミアムPC試用レポート

ピックアップ

ASCII.jp RSS2.0 配信中

ASCII.jpメール デジタルMac/iPodマガジン