マイナビニュース | テクノロジー | スパコン/HPC | ヘッドライン(2009)(1ページ目)

ヘッドライン

2009年12月18日(金)

コンピュータアーキテクチャの話 第170回 分岐予測の干渉

1レベル予測も2レベル予測も条件分岐命令の下位アドレスビットだけを用いて条件分岐命令を識別するので、上位アドレスが異なるが下位アドレスが一致する複数の条件分岐命令を区別できない。

[07:00 12/18]

2009年12月11日(金)

コンピュータアーキテクチャの話 第169回 ローカル履歴を用いる予測方法

前回の図7.1の構造では、ループの最後の回の予測が外れてしまう。最後の1回の予測が外れても、全体としての予測ミス率は1/Nであり、ループ回数Nが大きい場合はあまり成功率は低下しないが、Nが小さい場合には、予測ミスの比率が大きくなってしまう。

[07:00 12/11]

2009年12月04日(金)

コンピュータアーキテクチャの話 第168回 ダイナミックに分岐方向を予測する

最近のプロセサでは、プログラム実行中の振る舞いから、ダイナミックに分岐方向を予測するハードウェアを持つというのが主流となってきている。基本的な考え方は、分岐命令ごとにTaken(分岐成立)、Not Taken(不成立)の履歴をモニタし、Takenが続いていれば、次回もTakenであろうと予測するという方法である。

[07:00 12/4]

2009年11月27日(金)

コンピュータアーキテクチャの話 第167回 条件分岐命令と分岐予測の考え方

条件分岐命令は、平均的には5命令に1回程度の出現頻度であり、条件が確定してから分岐命令を実行し、さらに分岐先の命令をフェッチしてきてデコードできる状態になるまでには、命令フェッチが1次キャッシュにヒットしたとしても5サイクル程度は掛かってしまう。

[07:00 11/27]

2009年11月20日(金)

コンピュータアーキテクチャの話 第166回 タイムスタンプによる要求のロード、ストア要求の格納(2)

しかし、前回示した構成では、アドレスが一致したエントリのうちの最新のものを選ぶために、それのエントリより下側のすべてのエントリでのアドレス一致のORを必要とし、ストアキューのエントリ数を大きくすることは難しい。より多数のエントリを持つ場合は、浮動小数点加算器の結果のノーマライズのところで示したリーディングゼロデテクタと同様な回路を用いるプライオリティエンコーダでアドレス一致したエントリの中の一番新しいエントリ番号を求め、そのエントリのストアデータをフォワードするようにすれば、ある程度、エントリ数の大きな構造を作ることができる。

[17:30 11/20]

2009年11月13日(金)

コンピュータアーキテクチャの話 第165回 タイムスタンプによる要求のロード、ストア要求の格納(1)

先行するストアとのアドレス一致チェックのような構造ではロードキュー、ストアキューの各エントリには命令の発行順を示すタイムスタンプ(Time)を付け、時刻順に上から下方向にロード、ストア要求を格納する。このタイムスタンプはプログラムにおけるロードとストアの前後関係を判定する目的であり、正確な時刻である必要なく一連の番号で良い。

[08:00 11/13]

2009年11月06日(金)

コンピュータアーキテクチャの話 第164回 メモリディスアンビギュエーション

ここまでは、通常の演算命令を対象としてスーパスカラの処理を説明してきたが、メモリをアクセスするロード、ストア命令のスーパスカラ実行には追加の考慮が必要となる。

[08:00 11/6]

2009年10月30日(金)

コンピュータアーキテクチャの話 第163回 リオーダバッファによるリネーム方式

ここまでは、大きな物理レジスタファイルを持つリネーム方式を説明してきたが、リオーダバッファを用いる方式では、論理レジスタと1対1に対応するアーキテクチャレジスタファイルと、仕掛り中の命令の演算結果を保持するリオーダバッファ(Re-order Buffer)と呼ぶ別個のレジスタファイルを用いる。

[08:00 10/30]

2009年10月23日(金)

コンピュータアーキテクチャの話 第162回 命令のコミット

各命令は、デコードが終わりリザベーションステーションに発行された時点で、仕掛り中(In Flight)の命令としてコミット機構にエントリを確保して登録される。コミット機構の各エントリは、その命令の状態や、使用資源、命令の番地(プログラムカウンタの値)などの情報を持っている。

[07:00 10/23]

2009年10月16日(金)

コンピュータアーキテクチャの話 第161回 物理レジスタファイルとリネームレジスタの開放

4命令の並列デコードを行う場合、それぞれの命令が2つのオペランドを持つとすると、8個のオペランドに対してレジスタリネーム表を引き、かつ、図6.18の並列リネーム機構を使って物理レジスタ番号に変換してから物理レジスタファイルにアクセスするので、8個のリードポートが必要となる。また、それらの4つの命令が演算結果を物理レジスタファイルに書き込むので、一般的には4つのライトポートが必要である。

[06:00 10/16]

2009年10月09日(金)

コンピュータアーキテクチャの話 第160回 物理レジスタ番号をタグとして用いる

Tomasulo構造では、リザベーションステーションの番号をタグとして用いていたが、レジスタリネーミングを行う場合は、リネームされた物理レジスタ番号をタグとして用いる方が簡単である。

[08:00 10/9]

2009年10月02日(金)

コンピュータアーキテクチャの話 第159回 リネーミング処理

スーパスカラプロセサでは、並列にデコードする命令グループの最初の命令から順に、結果を格納する物理レジスタ番号を割り当てる必要がある。しかし、最大4命令を並列にデコードするマイクロアーキでも、条件分岐命令などが出てくると次に実行する命令が分からず途切れてしまい、常に4命令を並列デコードできるとは限らない。

[07:00 10/2]

2009年09月25日(金)

コンピュータアーキテクチャの話 第158回 レジスタリネーミング(2)

リネーミングを行うためには、論理レジスタ数より多くの物理レジスタを必要とする。どのくらい余裕を持たせるかは物量と性能のトレードオフであるが、32個の論理レジスタを持つRISCアーキテクチャのプロセサの場合、64~80個程度の物理レジスタを用意するのが一般的である。そして、論理レジスタに対して、それがどの物理レジスタにリネームされているかを記憶するリネーム表と、どの物理レジスタが空きであるかを管理するフリーリスト(Free List)という構造を用いる。

[09:00 9/25]

2009年09月18日(金)

コンピュータアーキテクチャの話 第157回 レジスタリネーミング(1)

命令の実行結果は、プログラムに書かれた命令順に実行したものと同じにならなければいけないが、これが実現できれば、原理的には命令の発行(Issue)、実行(Execute)、完了(Complete)の順序はプログラム順である必要はない。特に、実行時間の長い命令の後に、その結果に依存しない命令がある場合は、その命令を先に実行するOut of Order実行により性能が改善できることを見てきた。

[07:00 9/18]

2009年09月11日(金)

コンピュータアーキテクチャの話 第156回 Tomasuloアルゴリズム(2)

次のFADD命令はADDER側のリザベーションステーションのRA1エントリに格納される。ここでF2はBusyではないので値を読み出してRA1のOP2部に格納できるが、FDIVの結果を待っているF1は、Busyビットが"1"であり、値を読むことは出来ない。したがって、この場合はF1のTag部に格納されているRM1をリザベーションステーションRA1のタグ部に書き込む。そして、結果を格納するレジスタF4のBusyビットを"1"にセットし、タグ部にはRA1を格納しておく。そして、このFADD命令はオペランドが揃うまで、実行は開始されない。

[08:00 9/11]

2009年09月04日(金)

コンピュータアーキテクチャの話 第155回 Tomasuloアルゴリズム(1)

1966年に発表されたIBMの初期のスーパーコンピュータである「System 360 model 91」は、後に「Tomasuloアルゴリズム」と呼ばれることになるアウトオブオーダ実行機構を実装していた。Robert Tomasulo氏のアイデアは、処理結果を格納するレジスタについて、その論理的なレジスタ番号と物理的にデータを保持する実体としてのレジスタを分離した点が卓越している。

[08:00 9/4]

2009年08月21日(金)

コンピュータアーキテクチャの話 第154回 スコアボード方式による管理(2)

スコアボードは3種類のテーブルを持っている。命令状態テーブルは、デコードされた各命令が前回記したIssue、 Read Operands、 Execute、 Write Backの4つのステージのどこの段階にあるかを示している。論理的にはこのテーブルは、Write Backを終わって完了した命令が上から取り除かれ、新たにデコードされた命令が下に追加されるFIFO(First In First Out)構造である。

[10:00 8/21]

2009年08月07日(金)

コンピュータアーキテクチャの話 第153回 スコアボード方式による管理(1)

アウトオブオーダ実行の歴史は、実はかなり古く、1963年に登場した当時のスパコンである「CDC6600」で採用されていた。CDC6600は4つの浮動小数点演算パイプライン、5つのメモリアクセスパイプライン、7つの整数計算パイプラインを備えており、 単純にプログラム順に命令を発行するだけでは、とてもこれらの合計16本の実行パイプラインを効率的に動かすことは出来ない。そこで、浮動小数点演算やメモリアクセスなどの実行時間の長い命令の実行中に、依存関係の無い命令は並列的に実行してしまう「スコアボード」と呼ぶマイクロアーキテクチャにより、この問題を解決している。

[10:00 8/7]

2009年07月30日(木)

コンピュータアーキテクチャの話 第152回 アウトオブオーダ実行とその問題点

これまでに述べてきたプロセサは、(CやC++などの高級言語ではなく、それらをコンパイルした機械語レベルの)プログラムに書かれた通りの順序で命令を実行するプロセサである。しかし、プログラムの中での命令の順序を変えて、出来る命令から先にやるというマイクロアーキテクチャが考えられた。この方式は、命令として記述された順序を崩して実行するので「Out of Order実行」と呼ばれる。

[06:00 7/30]

2009年03月14日(土)

コンピュータアーキテクチャの話 第151回 スーパースカラ方式における命令デコードの留意点

1サイクルに2命令を並列にデコードし、実行可能なハードウェア構成としても、データ依存性や構造ハザードにより1命令しか実行できない場合があり、常に1サイクルに2命令を実行できるわけではない。プログラムの中でどのような命令が連続して並んでいるかに依存するのであるが、一般的に言って、2つの整数演算ユニットを持ち、2命令を並列にデコードするスーパスカラ方式のマシンでは、単純なスカラ実行の場合と比べて1.5倍くらいの性能向上が得られる。

[09:00 3/14]

2009年03月07日(土)

コンピュータアーキテクチャの話 第150回 複数命令の並列実行 - スーパースカラ方式による命令実行

これまでに述べてきたプロセサは、機械語の命令を1サイクルに1つずつ実行するものであり、IPC(Instruction Per Cycle)は1.0を切ることはできない。そこで、さらに性能を向上させるために1サイクルに2つ以上の命令を実行するという方法が考えられた。2つ以上のスカラ命令を並行して実行する方式で、並行して複数の演算が行われるがベクトルデータの処理ではなく、それぞれは異なるスカラデータの演算であるので、「スーパスカラ(Super Scalar)実行」と呼ばれる。

[11:00 3/7]

2009年02月28日(土)

コンピュータアーキテクチャの話 第149回 リタグで格納場所を移動

OSがキャッシュの青の領域のラインに書き込みを行い、アプリケーションが緑の領域のキャッシュラインをアクセスすると、そこには目的のデータは無いのでタグは一致せず、キャッシュミスになる。そして2次キャッシュにアクセスが行われることになる。結果として1次キャッシュとしては同じデータが(ページサイズ分だけアドレスが異なる)別のキャッシュラインに格納されるのであるが、これをリタグと呼んでいる。

[09:00 2/28]

2009年02月21日(土)

コンピュータアーキテクチャの話 第148回 キャッシュサイズを大きくするためには

ただし、この方式ではキャッシュのサイズはページサイズより小さいことが必要である。つまり、Intelの4KBページの場合は、キャッシュのサイズは最大4KBにしか出来ない。もちろん、この方式でも、ページサイズを大きくすればそれに比例してキャッシュサイズも大きくすることができる。昔、メインメモリのサイズが4MBしか無かった時代は、4KBのページで1,024ページであったが、ページを256KBにすると16ページしか無くなってしまう。

[09:00 2/21]

2009年02月07日(土)

コンピュータアーキテクチャの話 第147回 仮想アドレスキャッシュと物理アドレスキャッシュ

ページテーブルを使って、プログラムの世界のアドレスと実メモリのアドレスの変換を行うとメモリの利用率を改善することができる。しかし、ここでデータや命令キャッシュを使う場合、インデックスとしてプログラムの世界のアドレスであるVirtual Addressを使うのか、実メモリのアドレスであるPhysical Addressを使うのかという選択が出てくる。

[09:00 2/7]

2009年01月31日(土)

コンピュータアーキテクチャの話 第146回 TLBの構造とTLBミスへの対応法

2wayセットアソシアティブ方式のTLBの構造は、仮想アドレス(Virtual Address)の中位の部分をインデックスとしてTLBをアクセスし、上位仮想アドレス(VA H)の一致を検査し、一致したWayの物理アドレスと属性を使用する。また、どちらのwayもヒットしなかった場合(TLBミス)は、メモリ上のページテーブルを読んで物理アドレスと属性を得る。そして、その内容をTLBに登録する。

[09:00 1/31]

2009年01月17日(土)

コンピュータアーキテクチャの話 第145回 フラグメンテーションとその解決法

通常の実行状態では命令セグメントは書き込み不可で良いが、新しいプログラムをメモリに書き込む場合には命令セグメントに書き込みを行うことが必要であり、書き込み不可では困る。

[10:00 1/17]

2009年01月07日(水)

コンピュータアーキテクチャの話 第144回 メモリの管理機構

初期のコンピュータは1つのプログラムを実行するだけであったが、性能が向上するにつれて、複数の人のプログラムを短い時間単位で切り替えて、見かけ上、同時並行的に実行するTime Sharing System(TSS)という使用法が出てきた。このような使い方をする場合、複数のユーザのプログラムをメモリ上において実行するのであるが、ここで問題が出てくる。

[12:00 1/7]

バックナンバー

人気記事

一覧

イチオシ記事

新着記事