パースペクティブ：MultiClet S1

それでは、次世代のマルチセルラープロセッサであるMultiClet S1についてお話します。 初めて聞いた場合は、これらの記事で建築の歴史とイデオロギーを確認してください。

• 「マルチセルラープロセッサとは何ですか？」
• 「Multiclet R1-最初のテスト」
• 「マルチセルラープロセッサ用のLLVMベースのC / C ++コンパイラ：あるべきかどうか？」

現在、新しいプロセッサは開発中ですが、最初の結果がすでに表示されているので、それが何を可能にするかを評価できます。



最大の変更から始めましょう：基本機能。

特徴。

以下の指標を達成する予定です。

1. セルの数：64
2. 技術プロセス：28 nm
3. クロック周波数：1.6 GHz
4. チップ上のメモリのサイズ：8 MB
5. クリスタル面積：40mm ²
6. 消費電力：6 W

実数は、2019年に製造されたサンプルのテスト結果に基づいて発表されます。 プロセッサは、チップ自体の特性に加えて、最大16 GBのDDR4 3200MHz標準RAM、PCI Expressバス、およびPLLをサポートします。



28 nm製造プロセスは、使用に特別な許可を必要としない最も低い世帯の範囲であるため、選択されたのは彼であることに注意する必要があります。 セルの数によって、128と256の異なるオプションが考慮されましたが、結晶の面積が増加すると、不良品の割合が増加します。 64個のセル、したがって、比較的小さな面積に収まりました。これにより、プレート上に適切な結晶がより多く生成されます。 ICS（この場合はシステム）のフレームワーク内でさらなる開発が可能であり、1つのケースで複数の64セル結晶を組み合わせることができます。



プロセッサの目的とアプリケーションは根本的に変化していると言わなければなりません。 S1は、P1やR1のような埋め込み用に設計されたマイクロプロセッサではなく、計算のアクセラレータです。 GPGPUと同様に、S1ベースのボードは通常のPCのPCI Expressマザーボードに挿入し、データ処理に使用できます。

建築

S1では、「マルチセル」は最小の計算単位です。特定のコマンドシーケンスを実行する4つのセルのセットです。 最初は、コマンドの共同実行のために、マルチセルをクラスターと呼ばれるグループに結合することが計画されていました。1つのクラスターには4つのマルチセルが含まれていなければなりません。 ただし、各セルはクラスター内の他のすべてのセルと完全に接続されており、結合グループが増えると多すぎて、マイクロ回路のトポロジ設計が非常に複雑になり、その特性が低下します。 そのため、合併症は結果を正当化しないため、クラスター分割を放棄することにしました。 さらに、最大のパフォーマンスを得るには、各マルチセルでコードを並行して実行することが最も有益です。 合計で、プロセッサには16個の個別のマルチセルが含まれています。



マルチセルは4つのセルで構成されていますが、4つのセルR1とは異なり、各セルには独自のメモリ、独自の命令ブロック、ALUがあります。 S1の配置は少し異なります。 ALUには、浮動小数点演算ブロックと整数演算ブロックの2つの部分があります。 各セルには個別の整数ブロックがありますが、マルチセルには浮動小数点を持つブロックが2つしかないため、2つのセルのペアがそれらを分割します。 これは主に水晶の面積を減らすために行われました。整数演算とは対照的に、64ビット浮動小数点演算は多くのスペースを占有します。 各セルにこのようなALUがあることは冗長であることが判明しました。コマンドをフェッチしてもALUのロードは提供されず、アイドル状態になります。 ALUブロックの数を減らし、サンプルコマンドとデータのペースを維持しながら、実践が示しているように、問題を解決するための合計時間は実際には変化しないか、わずかに変化し、ALUブロックは完全にロードされます。 さらに、浮動小数点演算は、整数ほど頻繁には使用されません。



プロセッサR1およびS1のブロックの概略図を以下の図に示します。 ここに：

• CU（コントロールユニット）-命令選択ブロック
• ALU _FX-整数演算の算術論理ユニット
• ALU _FP-浮動小数点演算の算術論理ユニット
• DMS（データメモリスケジューラ）-データメモリ制御ユニット
• DM-データメモリ
• PMS（プログラムメモリスケジューラ）-プログラムメモリ制御ユニット
• PM-プログラムメモリ

アーキテクチャの違いS1：

1. チームは、前の段落のチーム結果にアクセスできるようになりました。 これは非常に重要な変更であり、コードを分岐する際の移行を大幅に高速化できます。 プロセッサP1とR1には、メモリに目的の結果を書き込み、すぐに新しい段落の最初のコマンドでそれらを読み返す以外に選択肢がありませんでした。 チップ上のメモリを使用する場合でも、書き込みおよび読み取り操作はそれぞれ2〜5サイクルかかり、前の段落のコマンドの結果を参照するだけで節約できます。
2. メモリとレジスタへの書き込みは、段落の終わりではなく、すぐに行われるようになりました。これにより、段落の終わりよりも前にコマンドの書き込みを開始できます。 その結果、段落間の潜在的なダウンタイムが短縮されます。
3. コマンドシステムは最適化されています。
   
   
   • 64ビット整数演算を追加：32ビット数の加算、減算、乗算。64ビットの結果を返します。
   • メモリからの読み取り方法が変更されました。現在、 どのコマンドでも、読み取りコマンドと書き込みコマンドの実行順序を維持しながら、データを読み取るアドレスを引数として指定できます。
     
     
     
     また、別のメモリ読み取りコマンドが廃止されました。 代わりに、引数としてメモリ内のアドレスを指定して、load switch（以前はget ）に対してload valueコマンドを使用します。
     
     
     
     

     .data foo: .long 0x1234 .text habr: load_l foo ;      foo load_l [foo] ;    0x1234 add_l [foo], 0xABCD ;       ;   complete
           
           
     
             
             
             
           
     
         
             
             
             
           
           
     
             
             
             
           
     
         
          

     
     
     
   • 2つの定数引数を使用できるコマンド形式が追加されました。
     
     以前は、2番目の引数としてのみ定数を指定できました。最初の引数は常にスイッチの結果へのリンクである必要があります。 この変更は、2つの引数を持つすべてのチームに適用されます。 定数フィールドは常に32ビットなので、この形式では、たとえば、1つのコマンドで64ビットの定数を生成できます。
     
     
     
     それは：
     
     
     
     

      load_l 0x12345678 patch_q @1, 0xDEADBEEF
           
           
     
             
             
             
           
     
         
             
             
             
           
           
     
             
             
             
           
     
         
          

     
     
     次のようになりました：
     
     
     
     

      patch_q 0x12345678, 0xDEADBEEF
           
           
     
             
             
             
           
     
         
             
             
             
           
           
     
             
             
             
           
     
         
          

     
     
     
   • 変更および補足されたベクターデータタイプ。
     
     「パック」データ型と呼ばれていたものは、今では安全にベクトルと呼ぶことができます。 P1およびR1では、パックされた数値の演算は、2番目の引数として定数のみを取りました。つまり、たとえば、ベクトルの各要素が同じ数値で追加された場合、これはインテリジェントに適用できませんでした。 現在、同様の操作を2つの完全なベクトルに適用できます。 さらに、このベクターの操作方法は、LLVMのベクターのメカニズムと完全に一致しており、コンパイラーがベクター型を使用してコードを生成できるようになりました。
     
     
     
     

      patch_q 0x00010002, 0x00030004 patch_q 0x00020003, 0x00040005 mul_ps @1, @2 ;  - 00020006000C0014
           
           
     
             
             
             
           
     
         
             
             
             
           
           
     
             
             
             
           
     
         
          

     
     
     
   
   
   
4. プロセッサフ​​ラグが削除されました。
   
   
   
   その結果、フラグの値のみに基づいた約40チームが削除されました。 これにより、チームの数が大幅に削減され、それに応じてクリスタルの面積が削減されました。 そして、必要な情報はすべてスイッチセルに直接保存されます。
   
   
   
   
   • ゼロフラグの代わりにゼロと比較する場合、スイッチの値のみが使用されるようになりました
   • 符号フラグの代わりに、コマンドのタイプに対応するビットが使用されるようになりました。バイトに7番目、ショートに15番目、ロングに31番目、クアッドに63番目です。 タイプに関係なく、63ビットまで符号が乗算されるという事実により、異なるタイプの数値を比較できます。
     
     
     
     

      .data long: .long -0x1000 byte: .byte -0x10 .text habr: a := load_b [byte] ;     0xFFFFFFFFFFFFFFF0, ;   byte 7    63. b := loadu_b [byte] ;     0x00000000000000F0, ; ..  loadu_b    c := load_l [long] ;     0xFFFFFFFFFFFFF000. ge_l @a, @c ;   "  "  1: ;   31 ,   . lt_s @a, @b ; 1, .. b     complete
           
           
     
             
             
             
           
     
         
             
             
             
           
           
     
             
             
             
           
     
         
          

     
     
     
   • 64ビット演算があるため、キャリーフラグは不要になりました。
   
   
   
5. 段落から段落への移行時間は1メジャーに短縮されました（R1の2-3の代わりに）

LLVMベースのコンパイラ

S1のC言語コンパイラはR1に似ており、アーキテクチャが根本的に変更されていないため、残念ながら前の記事で説明した問題は消えていません。



ただし、新しいコマンドシステムの実装プロセスでは、単にコマンドシステムの更新が原因で、出力コードの量が自動的に減少しました。 さらに、コード内の命令数を削減するマイナーな最適化がさらに多くあり、その一部は既に実行されています（たとえば、単一の命令で64ビット定数を生成する）。 しかし、さらに深刻な最適化を行う必要があり、効率と実装の複雑さの両方の昇順で構築できます。

1. 2つの定数を持つすべての2引数コマンドを生成する機能。
   
   
   
   patch_qを介した64ビット定数の生成は特別な場合ですが、一般的なものが必要です。 実際、この最適化のポイントは、チームが最初の引数だけを定数として置き換えることです。2番目の引数は常に定数であり、これは長い間実装されてきたためです。 これはあまり頻繁なケースではありませんが、たとえば、関数を呼び出してそのアドレスからスタックの先頭に戻りアドレスを書き込む必要がある場合、次のことができます。
   
   
   
   

    load_l func wr_l @1, #SP
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   最適化する
   
   
   
   

    wr_l func, #SP
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   
2. 任意のコマンドの引数を介してメモリアクセスを置換する機能。
   
   たとえば、メモリから2つの数値を追加する必要がある場合、次のことができます。
   
   
   
   

    load_l [foo] load_l [bar] add_l @1, @2
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   最適化する
   
   
   
   

    add_l [foo], [bar]
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   この最適化は以前の最適化の拡張ですが、ここではすでに分析が必要です。このような置換は、ロードされた値がこの追加コマンドで一度だけ使用され、他では使用されない場合にのみ実行できます。 読み取り結果が2つのコマンドのみで使用される場合、メモリから1つの個別のコマンドとして読み取り、他の2つではスイッチを介してそれを参照する方が有利です。
   
   
3. ベースユニット間の仮想レジスタの転送の最適化。
   
   R1では、すべての仮想レジスタの転送はメモリを介して行われたため、メモリへの読み取りと書き込みが非常に多く発生しましたが、段落間でデータを転送する他の方法はありませんでした。 S1では、前の段落のコマンドの結果にアクセスできます。したがって、理論的には、多くのメモリ操作を削除できます。これにより、すべての最適化の中で最大の効果が得られます。 ただし、このアプローチはまだスイッチによって制限されています。63個までの以前の結果は、これまでのところ、仮想レジスタのすべての転送をこのように実装できます。 これを行う方法は簡単な作業ではなく、それを解決する可能性の分析はまだ行われていません。 コンパイラのソースはパブリックドメインに表示される場合があるため、だれかがアイデアを持っていて、開発に参加したい場合は、それを行うことができます。
   
   

ベンチマーク

プロセッサはまだチップ上でリリースされていないため、実際のパフォーマンスを評価することは困難です。 ただし、RTLカーネルコードは既に用意されているため、シミュレーションまたはFPGAを使用して評価を行うことができます。 次のベンチマークを実行するために、ModelSimプログラムを使用したシミュレーションを使用して、正確な実行時間（測定値）を計算しました。 クリスタル全体をシミュレートするのは難しく、時間がかかるため、各マルチセルは完全に独立して動作できるため、1つのマルチセルをシミュレートし、結果に16を掛けました（タスクがマルチスレッド用に設計されている場合）。



同時に、Xilinx Virtex-6でマルチセルモデリングが実行され、実際のハードウェアでプロセッサコードのパフォーマンスがテストされました。

コアマーク

CoreMark-マイクロコントローラーと中央処理装置、およびそれらのCコンパイラーのパフォーマンスを包括的に評価するための一連のテスト。 ご覧のとおり、S1プロセッサはどちらでもありません。 ただし、完全に調停コードを実行することを意図しています。 中央処理装置で実行できるすべての人。 したがって、CoreMarkはS1のパフォーマンスを悪く評価するのに適しています。



CoreMarkには、リンクリスト、マトリックス、ステートマシン、 CRC合計計算の機能が含まれています。 一般に、ほとんどのコードは厳密にシーケンシャルであり（マルチセルハードウェアの並列性の強度をテストします ）、多くの分岐があるため、コンパイラーの機能は最終的なパフォーマンスで重要な役割を果たします。 コンパイルされたコードには短いパラグラフがかなり含まれており、それらの間の遷移速度が向上したという事実にもかかわらず、分岐にはメモリの操作が含まれます。



CoreMark比較チャート：

	Multiclet R1（llvmコンパイラー）	Multiclet S1（llvmコンパイラー）	Elbrus-4C（R500 / E）	テキサス工科大学 AM5728 ARM Cortex-A15	バイカル-t1	Intel Core i7 7700K
製造年	2015	2019年	2014	2018年	2016年	2017年
クロック周波数、MHz	100	1600	700	1500	1200	4500
CoreMark総合スコア	59	18356	1214	15789	13142	182128
コアマーク/ MHz	0.59	11.47	5.05	10.53	10.95	40.47

1つのマルチセルの結果は1147、つまり0.72 / MHzで、R1の結果よりも高くなっています。 これは、新しいプロセッサでのマルチセルラーアーキテクチャの開発の利点について語っています。

ホイートストン

砥石-浮動小数点数を処理する際のプロセッサのパフォーマンスを測定するための一連のテスト。 ここでは、状況ははるかに良好です。コードもシーケンシャルですが、多数のブランチがなく、内部同時実行性が良好です。



Whetstoneは多くのモジュールで構成されているため、全体的な結果だけでなく、特定の各モジュールのパフォーマンスも測定できます。

1. 配列要素
2. パラメータとしての配列
3. 条件付きジャンプ
4. 整数演算
5. 三角関数（tan、sin、cos）
6. 手続き呼び出し
7. 配列参照
8. 標準関数（sqrt、exp、log）

これらはカテゴリに分類されます。モジュール1、2、および6は、浮動小数点演算のパフォーマンスを測定します（行MFLOPS1〜3）。 モジュール5および8-数学関数（COS MOPS、EXP MOPS）。 モジュール4および7-整数演算（FIXPT MOPS、EQUAL MOPS）。 モジュール3-条件付きジャンプ（IF MOPS）。 次の表では、MWIPSの2行目が一般的な指標です。



CoreMarkとは異なり、Whetstoneは1つのコアで比較されますが、この場合は1つのマルチセルで比較されます。 コアの数はプロセッサごとに非常に異なるため、実験の純度のために、メガヘルツあたりの指標を考慮します。



砥石スコアカード：

CPU	MultiClet R1	MultiClet S1	Core i7 4820K	ARM v8-A53
周波数、MHz	100	1600	3900	1300
MWIPS / MHz	0.311	0.343	0.887	0.642
MFLOPS1 / MHz	0.157	0.156	0.341	0.268
MFLOPS2 / MHz	0.153	0.111	0.308	0.241
MFLOPS3 / MHz	0.029	0.124	0.167	0.239
COS MOPS / MHz	0.018	0.008	0.023	0.028
EXP MOPS / MHz	0.008	0.005	0.014	0.004
FIXPT MOPS / MHz	0.714	0.116	0.998	1.197
IF MOPS / MHz	0.081	0.196	1.504	1.436
EQUAL MOPS / MHz	0.143	0.149	0.251	0.439

WhetstoneにはCoreMarkよりもはるかに直接的な計算操作が含まれているため（以下のコードを見ると非常に顕著です）、ここで覚えておくことが重要です：浮動小数点ALUの数は半分になります。 ただし、R1と比較して、計算速度はほとんど影響を受けませんでした。



一部のモジュールは、マルチセルラーアーキテクチャに非常に適しています。 たとえば、モジュール2はサイクルで多くの値をカウントし、プロセッサーとコンパイラーの両方による倍精度浮動小数点数の完全なサポートのおかげで、コンパイル後、マルチセルラーアーキテクチャの計算能力を本当に明らかにする大きく美しい段落を取得します。

ポップ

（コンパイラに関係なく）アーキテクチャ自体の特性を反映するために、アーキテクチャのすべての機能を考慮してアセンブラーで記述されたものを測定します。 たとえば、512ビット数（popcnt）の単位ビットをカウントします。 わかりやすくするために、1つのマルチセルの結果を使用して、R1と比較できるようにします。



比較表、32ビット計算サイクルあたりのクロックサイクル数：

アルゴリズム	マルチクレットr1	マルチクレットS1（1つのマルチセル）
Bithacks	5.0	2.625

ここでは新しい更新されたベクトル命令が使用されたため、R1アセンブラーで実装された同じアルゴリズムと比較して、命令の数を半分にできました。 作業速度はそれぞれ、ほぼ2倍に増加しました。

イーサリアム

もちろん、ベンチマークは優れていますが、特定のタスクがあります。計算のアクセラレータを作成することです。実際のタスクをどのように処理するかを知ることは素晴らしいことです。 マイニングアルゴリズムはさまざまなデバイスで実行されるため、比較のベンチマークとして機能するため、最新の暗号通貨はこのような検証に最適です。 イーサリアムと、マイニングデバイスで直接実行されるEthashアルゴリズムから始めました。



イーサリアムの選択は、次の考慮事項によるものでした。 ご存知のように、ビットコインなどのアルゴリズムは専用のASICチップによって非常に効率的に実装されているため、ビットコインとそのクローンをマイニングするためのプロセッサまたはビデオカードの使用は、低パフォーマンスと高電力消費のために経済的に不利になります。 鉱夫のコミュニティは、この状況から逃れようとして、他のアルゴリズム原理に基づいて暗号通貨を開発し、マイニングに汎用プロセッサーまたはビデオカードを使用するアルゴリズムの開発に焦点を当てています。 この傾向は今後も続く可能性があります。 イーサリアムは、このアプローチに基づいた最も有名な暗号通貨です。 イーサリアムをマイニングするための主なツールはビデオカードです。これは、効率（ハッシュレート/ TDP）の点で、汎用プロセッサよりも（数回）先行しています。



Ethashは、いわゆるメモリバウンドアルゴリズムです。 その計算時間は、計算自体の速度ではなく、主にメモリの量と速度によって制限されます。 イーサリアムマイニングでは、ビデオカードが最適ですが、多くの操作を同時に実行する能力はあまり役に立ちません。また、 この記事で明らかに示されているRAMの速度に依存しています 。 そこから、アルゴリズムの動作を示す写真を撮って、これが起こる理由を説明できます。







この記事ではアルゴリズムを6つのポイントに分けていますが、さらに明確にするために3つの段階を区別できます。

1. 開始：元の128バイトのMix 0（ポイント1）を計算するSHA-3（512）
2. 次の128バイトを読み取り、ミキシング機能を介して前のバイトと混合し、合計8キロバイトになるように、Mix配列を64倍再計算します（段落2〜4）
3. 結果の確定と検証

RAMからランダムな128バイトを読み取るには、予想よりはるかに時間がかかります。 2048台のコンピューティングデバイスと最大メモリ帯域幅211.2 GB / sのMSI RX 470グラフィックカードを使用する場合、各デバイスに装備するには1 /（211.2 GB /（128 b * 2048））= 1241 ns、または約1496が必要です所定の周波数でサイクルします。 ミキシング関数のサイズを考えると、受信した情報を再計算するよりもビデオカードのメモリを読み取るのに数倍時間がかかると想定できます。 その結果、アルゴリズムのステージ2には多くの時間がかかり、ステージ1および3よりも多くの時間がかかります（主にSHA-3で）。 このビデオカードのハッシュレートを見ることができます：理論上の26.375メガシャシー（メモリ帯域幅によってのみ制限）対実際の24メガシャシー/秒、つまり、ステージ1と3は10％の時間しかかかりません。



S1では、16個のマルチセルすべてが並行して異なるコードで動作できます。 さらに、8つのマルチセル用の1つのチャネルに沿って、デュアルチャネルRAMがインストールされます。 Ethashアルゴリズムのステージ2での計画は次のとおりです。1つのマルチセルがメモリから128バイトを読み取り、それらの再カウントを開始し、次に次のマルチセルがメモリを読み取り、再カウントします。 1つのマルチセルは、128バイトのメモリを読み取った後、配列を再計算するために7 * [128バイトの読み取り時間]を持っています。 このような読み取りには16サイクル、つまり 再集計のために112の測定が行われます。 ミキシング関数の計算にはほぼ同じクロックサイクルがかかるため、S1はメモリ帯域幅とプロセッサパフォーマンスの理想的な比率に近くなります。 2番目の段階では時間が無駄にならないため、アルゴリズムの残りの部分は、パフォーマンスに実際に影響するため、可能な限り最適化する必要があります。



SHA-3（Keccak）の計算速度を評価するために、C言語プログラムが開発およびテストされ、それに基づいてアセンブラーでの最適なバージョンが現在作成されています。評価プログラミングは、1つのマルチセルが1550クロックサイクルでSHA-3（ケッカ）計算を実行することを示しています。したがって、1つのマルチセルで1つのハッシュを計算するための合計時間は、1550 + 64 *（16 + 112）= 9742サイクルになります。1.6 GHzの周波数と16個の並列マルチセルで、プロセッサのハッシュレートは2.6 MHash / sになります。

加速器	MultiClet S1	NVIDIA GeForce GTX 980 Ti	Radeon RX 470	Radeon RX Vega 64	NVIDIA GeForce GTX 1060	NVIDIA GeForce GTX 1080 Ti
価格		650ドル	180ドル	500ドル	300ドル	700ドル
ハッシュレート	2.6 MHash / s	21.6 MHash / s	25.8 MHash / s	43.5 MHash / s	25 MHash / s	55 MHash / s
TDP	6 W	250 W	120 W	295 W	120 W	250 W
ハッシュレート/ TDP	0.43	0.09	0.22	0.15	0.22	0.21
プロセス技術	28 nm	28 nm	14 nm	14 nm	16 nm	16 nm

MultiClet S1をマイニングツールとして使用する場合、20個以上のプロセッサを実際にボードにインストールできます。この場合、このようなボードのハッシュレートは既存のビデオカードのハッシュレートと同じかそれよりも高くなりますが、S1を搭載したボードの消費電力は、16および14 nmの地形標準を備えたビデオカードの消費電力よりも半分になります。



結論として、現在の主なタスクは、マルチセルラー暗号通貨マイナーおよびスーパーコンピューターマイナー向けのマルチプロセッサーボードの製造であると言わなければなりません。消費電力とアーキテクチャが小さいため、任意のコンピューティングに適した競争力が実現する予定です。



プロセッサはまだ開発中ですが、アセンブリ言語でプログラミングを開始したり、コンパイラの現在のバージョンを評価したりできます。アセンブラー、リンカー、コンパイラー、および機能モデルを含む最小限のSDKがすでにあり、それらを使用してプログラムを開始およびテストできます。