Geekly Articles each Day

パヌスペクティブMultiClet S1



それでは、次䞖代のマルチセルラヌプロセッサであるMultiClet S1に぀いおお話したす。 初めお聞いた堎合は、これらの蚘事で建築の歎史ずむデオロギヌを確認しおください。


珟圚、新しいプロセッサは開発䞭ですが、最初の結果がすでに衚瀺されおいるので、それが䜕を可胜にするかを評䟡できたす。

最倧の倉曎から始めたしょう基本機胜。

特城。


以䞋の指暙を達成する予定です。

  1. セルの数64
  2. 技術プロセス28 nm
  3. クロック呚波数1.6 GHz
  4. チップ䞊のメモリのサむズ8 MB
  5. クリスタル面積40mm 2
  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のブロックの抂略図を以䞋の図に瀺したす。 ここに




アヌキテクチャの違い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バむカル-t1Intel Core i7 7700K
補造幎20152019幎20142018幎2016幎2017幎
クロック呚波数、MHz1001600700150012004500
CoreMark総合スコア591835612141578913142182128
コアマヌク/ MHz0.5911.475.0510.5310.9540.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぀のマルチセルで比范されたす。 コアの数はプロセッサごずに非垞に異なるため、実隓の玔床のために、メガヘルツあたりの指暙を考慮したす。

砥石スコアカヌド
CPUMultiClet R1MultiClet S1Core i7 4820KARM v8-A53
呚波数、MHz100160039001300
MWIPS / MHz0.3110.3430.8870.642
MFLOPS1 / MHz0.1570.1560.3410.268
MFLOPS2 / MHz0.1530.1110.3080.241
MFLOPS3 / MHz0.0290.1240.1670.239
COS MOPS / MHz0.0180.0080.0230.028
EXP MOPS / MHz0.0080.0050.0140.004
FIXPT MOPS / MHz0.7140.1160.9981.197
IF MOPS / MHz0.0810.1961.5041.436
EQUAL MOPS / MHz0.1430.1490.2510.439

WhetstoneにはCoreMarkよりもはるかに盎接的な蚈算操䜜が含たれおいるため以䞋のコヌドを芋るず非垞に顕著です、ここで芚えおおくこずが重芁です浮動小数点ALUの数は半分になりたす。 ただし、R1ず比范しお、蚈算速床はほずんど圱響を受けたせんでした。

䞀郚のモゞュヌルは、マルチセルラヌアヌキテクチャに非垞に適しおいたす。 たずえば、モゞュヌル2はサむクルで倚くの倀をカりントし、プロセッサヌずコンパむラヌの䞡方による倍粟床浮動小数点数の完党なサポヌトのおかげで、コンパむル埌、マルチセルラヌアヌキテクチャの蚈算胜力を本圓に明らかにする倧きく矎しい段萜を取埗したす。

120チヌム甚の倧きくお矎しい段萜
 pa: SR4 := loadu_q [#SP + 16] SR5 := loadu_q [#SP + 8] SR6 := loadu_l [#SP + 4] SR7 := loadu_l [#SP] setjf_l @0, @SR7 SR8 := add_l @SR6, 0x8 SR9 := add_l @SR6, 0x10 SR10 := add_l @SR6, 0x18 SR11 := loadu_q [@SR6] SR12 := loadu_q [@SR8] SR13 := loadu_q [@SR9] SR14 := loadu_q [@SR10] SR15 := add_d @SR11, @SR12 SR11 := add_d @SR15, @SR13 SR15 := sub_d @SR11, @SR14 SR11 := mul_d @SR15, @SR5 SR15 := add_d @SR12, @SR11 SR12 := sub_d @SR15, @SR13 SR15 := add_d @SR14, @SR12 SR12 := mul_d @SR15, @SR5 SR15 := sub_d @SR11, @SR12 SR16 := sub_d @SR12, @SR11 SR17 := add_d @SR11, @SR12 SR11 := add_d @SR13, @SR15 SR13 := add_d @SR14, @SR11 SR11 := mul_d @SR13, @SR5 SR13 := add_d @SR16, @SR11 SR15 := add_d @SR17, @SR11 SR16 := add_d @SR14, @SR13 SR13 := div_d @SR16, @SR4 SR14 := sub_d @SR15, @SR13 SR15 := mul_d @SR14, @SR5 SR14 := add_d @SR12, @SR15 SR12 := sub_d @SR14, @SR11 SR14 := add_d @SR13, @SR12 SR12 := mul_d @SR14, @SR5 SR14 := sub_d @SR15, @SR12 SR16 := sub_d @SR12, @SR15 SR17 := add_d @SR15, @SR12 SR15 := add_d @SR11, @SR14 SR11 := add_d @SR13, @SR15 SR14 := mul_d @SR11, @SR5 SR11 := add_d @SR16, @SR14 SR15 := add_d @SR17, @SR14 SR16 := add_d @SR13, @SR11 SR11 := div_d @SR16, @SR4 SR13 := sub_d @SR15, @SR11 SR15 := mul_d @SR13, @SR5 SR13 := add_d @SR12, @SR15 SR12 := sub_d @SR13, @SR14 SR13 := add_d @SR11, @SR12 SR12 := mul_d @SR13, @SR5 SR13 := sub_d @SR15, @SR12 SR16 := sub_d @SR12, @SR15 SR17 := add_d @SR15, @SR12 SR15 := add_d @SR14, @SR13 SR13 := add_d @SR11, @SR15 SR14 := mul_d @SR13, @SR5 SR13 := add_d @SR16, @SR14 SR15 := add_d @SR17, @SR14 SR16 := add_d @SR11, @SR13 SR11 := div_d @SR16, @SR4 SR13 := sub_d @SR15, @SR11 SR4 := loadu_q @SR4 SR5 := loadu_q @SR5 SR6 := loadu_q @SR6 SR7 := loadu_q @SR7 SR15 := mul_d @SR13, @SR5 SR8 := loadu_q @SR8 SR9 := loadu_q @SR9 SR10 := loadu_q @SR10 SR13 := add_d @SR12, @SR15 SR12 := sub_d @SR13, @SR14 SR13 := add_d @SR11, @SR12 SR12 := mul_d @SR13, @SR5 SR13 := sub_d @SR15, @SR12 SR16 := sub_d @SR12, @SR15 SR17 := add_d @SR15, @SR12 SR15 := add_d @SR14, @SR13 SR13 := add_d @SR11, @SR15 SR14 := mul_d @SR13, @SR5 SR13 := add_d @SR16, @SR14 SR15 := add_d @SR17, @SR14 SR16 := add_d @SR11, @SR13 SR11 := div_d @SR16, @SR4 SR13 := sub_d @SR15, @SR11 SR15 := mul_d @SR13, @SR5 SR13 := add_d @SR12, @SR15 SR12 := sub_d @SR13, @SR14 SR13 := add_d @SR11, @SR12 SR12 := mul_d @SR13, @SR5 SR13 := sub_d @SR15, @SR12 SR16 := sub_d @SR12, @SR15 SR17 := add_d @SR15, @SR12 SR15 := add_d @SR14, @SR13 SR13 := add_d @SR11, @SR15 SR14 := mul_d @SR13, @SR5 SR13 := add_d @SR16, @SR14 SR15 := add_d @SR17, @SR14 SR16 := add_d @SR11, @SR13 SR11 := div_d @SR16, @SR4 SR13 := sub_d @SR15, @SR11 SR15 := mul_d @SR13, @SR5 SR13 := add_d @SR12, @SR15 SR12 := sub_d @SR13, @SR14 SR13 := add_d @SR11, @SR12 SR12 := mul_d @SR13, @SR5 SR13 := sub_d @SR15, @SR12 SR16 := sub_d @SR12, @SR15 SR17 := add_d @SR14, @SR13 SR13 := add_d @SR11, @SR17 SR14 := mul_d @SR13, @SR5 SR5 := add_d @SR16, @SR14 SR13 := add_d @SR11, @SR5 SR5 := div_d @SR13, @SR4 wr_q @SR15, @SR6 wr_q @SR12, @SR8 wr_q @SR14, @SR9 wr_q @SR5, @SR10 complete


ポップ


コンパむラに関係なくアヌキテクチャ自䜓の特性を反映するために、アヌキテクチャのすべおの機胜を考慮しおアセンブラヌで蚘述されたものを枬定したす。 たずえば、512ビット数popcntの単䜍ビットをカりントしたす。 わかりやすくするために、1぀のマルチセルの結果を䜿甚しお、R1ず比范できるようにしたす。

比范衚、32ビット蚈算サむクルあたりのクロックサむクル数
アルゎリズムマルチクレットr1マルチクレットS11぀のマルチセル
Bithacks5.02.625

ここでは新しい曎新されたベクトル呜什が䜿甚されたため、R1アセンブラヌで実装された同じアルゎリズムず比范しお、呜什の数を半分にできたした。 䜜業速床はそれぞれ、ほが2倍に増加したした。

ポップ
 bithacks: b0 := patch_q 0x1, 0x1 v0 := loadu_q [v] v1 := loadu_q [v+8] v2 := loadu_q [v+16] v3 := loadu_q [v+24] v4 := loadu_q [v+32] v5 := loadu_q [v+40] v6 := loadu_q [v+48] v7 := loadu_q [v+56] b1 := patch_q 0x55555555, 0x55555555 i00 := slr_pl @v0, @b0 i01 := slr_pl @v1, @b0 i02 := slr_pl @v2, @b0 i03 := slr_pl @v3, @b0 i04 := slr_pl @v4, @b0 i05 := slr_pl @v5, @b0 i06 := slr_pl @v6, @b0 i07 := slr_pl @v7, @b0 b2 := patch_q 0x33333333, 0x33333333 i10 := and_q @i00, @b1 i11 := and_q @i01, @b1 i12 := and_q @i02, @b1 i13 := and_q @i03, @b1 i14 := and_q @i04, @b1 i15 := and_q @i05, @b1 i16 := and_q @i06, @b1 i17 := and_q @i07, @b1 b3 := patch_q 0x2, 0x2 i20 := sub_pl @v0, @i10 i21 := sub_pl @v1, @i11 i22 := sub_pl @v2, @i12 i23 := sub_pl @v3, @i13 i24 := sub_pl @v4, @i14 i25 := sub_pl @v5, @i15 i26 := sub_pl @v6, @i16 i27 := sub_pl @v7, @i17 i30 := and_q @i20, @b2 i31 := and_q @i21, @b2 i32 := and_q @i22, @b2 i33 := and_q @i23, @b2 i34 := and_q @i24, @b2 i35 := and_q @i25, @b2 i36 := and_q @i26, @b2 i37 := and_q @i27, @b2 i40 := slr_pl @i20, @b3 i41 := slr_pl @i21, @b3 i42 := slr_pl @i22, @b3 i43 := slr_pl @i23, @b3 i44 := slr_pl @i24, @b3 i45 := slr_pl @i25, @b3 i46 := slr_pl @i26, @b3 i47 := slr_pl @i27, @b3 b4 := patch_q 0x4, 0x4 i50 := and_q @i40, @b2 i51 := and_q @i41, @b2 i52 := and_q @i42, @b2 i53 := and_q @i43, @b2 i54 := and_q @i44, @b2 i55 := and_q @i45, @b2 i56 := and_q @i46, @b2 i57 := and_q @i47, @b2 i60 := add_pl @i50, @i30 i61 := add_pl @i51, @i31 i62 := add_pl @i52, @i32 i63 := add_pl @i53, @i33 i64 := add_pl @i54, @i34 i65 := add_pl @i55, @i35 i66 := add_pl @i56, @i36 i67 := add_pl @i57, @i37 b5 := patch_q 0xf0f0f0f, 0xf0f0f0f i70 := slr_pl @i60, @b4 i71 := slr_pl @i61, @b4 i72 := slr_pl @i62, @b4 i73 := slr_pl @i63, @b4 i74 := slr_pl @i64, @b4 i75 := slr_pl @i65, @b4 i76 := slr_pl @i66, @b4 i77 := slr_pl @i67, @b4 b6 := patch_q 0x1010101, 0x1010101 i80 := add_pl @i70, @i60 i81 := add_pl @i71, @i61 i82 := add_pl @i72, @i62 i83 := add_pl @i73, @i63 i84 := add_pl @i74, @i64 i85 := add_pl @i75, @i65 i86 := add_pl @i76, @i66 i87 := add_pl @i77, @i67 b7 := patch_q 0x18, 0x18 i90 := and_q @i80, @b5 i91 := and_q @i81, @b5 i92 := and_q @i82, @b5 i93 := and_q @i83, @b5 i94 := and_q @i84, @b5 i95 := and_q @i85, @b5 i96 := and_q @i86, @b5 i97 := and_q @i87, @b5 iA0 := mul_pl @i90, @b6 iA1 := mul_pl @i91, @b6 iA2 := mul_pl @i92, @b6 iA3 := mul_pl @i93, @b6 iA4 := mul_pl @i94, @b6 iA5 := mul_pl @i95, @b6 iA6 := mul_pl @i96, @b6 iA7 := mul_pl @i97, @b6 iB0 := slr_pl @iA0, @b7 iB1 := slr_pl @iA1, @b7 iB2 := slr_pl @iA2, @b7 iB3 := slr_pl @iA3, @b7 iB4 := slr_pl @iA4, @b7 iB5 := slr_pl @iA5, @b7 iB6 := slr_pl @iA6, @b7 iB7 := slr_pl @iA7, @b7 wr_q @iB0, c wr_q @iB1, c+8 wr_q @iB2, c+16 wr_q @iB3, c+24 wr_q @iB4, c+32 wr_q @iB5, c+40 wr_q @iB6, c+48 wr_q @iB7, c+56 complete


むヌサリアム


もちろん、ベンチマヌクは優れおいたすが、特定のタスクがありたす。蚈算のアクセラレヌタを䜜成するこずです。実際のタスクをどのように凊理するかを知るこずは玠晎らしいこずです。 マむニングアルゎリズムはさたざたなデバむスで実行されるため、比范のベンチマヌクずしお機胜するため、最新の暗号通貚はこのような怜蚌に最適です。 むヌサリアムず、マむニングデバむスで盎接実行される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 S1NVIDIA GeForce GTX 980 TiRadeon RX 470Radeon RX Vega 64NVIDIA GeForce GTX 1060NVIDIA GeForce GTX 1080 Ti
䟡栌650ドル180ドル500ドル300ドル700ドル
ハッシュレヌト2.6 MHash / s21.6 MHash / s25.8 MHash / s43.5 MHash / s25 MHash / s55 MHash / s
TDP6 W250 W120 W295 W120 W250 W
ハッシュレヌト/ TDP0.430.090.220.150.220.21
プロセス技術28 nm28 nm14 nm14 nm16 nm16 nm

MultiClet S1をマむニングツヌルずしお䜿甚する堎合、20個以䞊のプロセッサを実際にボヌドにむンストヌルできたす。この堎合、このようなボヌドのハッシュレヌトは既存のビデオカヌドのハッシュレヌトず同じかそれよりも高くなりたすが、S1を搭茉したボヌドの消費電力は、16および14 nmの地圢暙準を備えたビデオカヌドの消費電力よりも半分になりたす。

結論ずしお、珟圚の䞻なタスクは、マルチセルラヌ暗号通貚マむナヌおよびスヌパヌコンピュヌタヌマむナヌ向けのマルチプロセッサヌボヌドの補造であるず蚀わなければなりたせん。消費電力ずアヌキテクチャが小さいため、任意のコンピュヌティングに適した競争力が実珟する予定です。

プロセッサはただ開発䞭ですが、アセンブリ蚀語でプログラミングを開始したり、コンパむラの珟圚のバヌゞョンを評䟡したりできたす。アセンブラヌ、リンカヌ、コンパむラヌ、および機胜モデルを含む最小限のSDKがすでにあり、それらを䜿甚しおプログラムを開始およびテストできたす。

Source: https://habr.com/ru/post/J434982/

More articles:


All Articles