Path: news.ccsf.jp!news.tomockey.net!feeder.erje.net!2.eu.feeder.erje.net!news.uzoreto.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: YAMAGUTIseisei Newsgroups: tw.bbs.edu.computer-science,hk.test,japan.test Subject: =?ISO-2022-JP?B?GyRCRUU7UkYsRz5AXzdXP14zNU1XGyhCIDcyMDE5MTAyMDAt?= =?ISO-2022-JP?B?MDExMTkxMDIwMCAbJEJIRxsoQg==?= Followup-To: tw.bbs.comp.sources Date: Mon, 25 Nov 2019 13:10:16 +0000 Organization: X-PlsDntToRmsMatzYktJlgTtiRbistAnd: http://j.mp/2K8Eo4k?#__Sponsor_-_CellBE Lines: 715 Message-ID: <5DDBD2B8.2090205@hello.to> References: <54C4B4E9.4080503@hello.to> <5545F912.9020803@hello.to> <5550CDAB.8040405@hello.to> <5558C89B.4050103@hello.to> <5561E704.9000208@hello.to> <55645EAA.9040304@hello.to> <55745BE2.5000100@hello.to> <55ACFE56.7040602@hello.to> <55E2830C.9070303@hello.to> <55EBB467.40803@hello.to> <55F4C0BC.5050308@hello.to> <560130D5.4030103@hello.to> <560131AA.9080804@hello.to> <57CC1878.8040106@hello.to> <59B5507B.2050905@hello.to> <5AE59DD3.70407@hello.to> <5AEF6019.9040802@hello.to> <5B549B9B.1090408@hello.to> <5B6E4792.4060600@hello.to> <5B6F16C6.9020808@hello.to> <5B900C52.6070707@hello.to> <5B9D4169.10803@hello.to> <5BBA1756.5020801@hello.to> <5BDEBB5B.9020307@hello.to> <5C28DFDA.7010603@hello.to> <5C3B5446.6010209@hello.to> <5C497BFF.9090207@hello.to> <5C4F2D42.20508@hello.to> <5C697A9B.4020107@hello.to> <5C8688FA.6040107@hello.to> <5CC5C378.9080003@hello.to> <5D21CF77.5010203@hello.to> <5D6D2AF3.4060303@hello.to> <5D9A7735.9040705@hello.to> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Injection-Info: reader02.eternal-september.org; posting-host="a1ca285ea4a2cbf4bf79336dc875c22c"; logging-data="27765"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19jOXZryUfEzxN/t9D0dHsE" User-Agent: Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.8.1.17) Gecko/20080930 Thunderbird/2.0.0.17 ThunderBrowse/3.82 Mnenhy/0.7.6.0 Cancel-Lock: sha1:VXZbdISsuh1Zm0PKEEMlNob4XzQ= In-Reply-To: <5D9A7735.9040705@hello.to> Xref: news.ccsf.jp japan.test:3390 YAMAGUTIseisei wrote: > PR : シンギュラリティ系有料メールマガジン発行を構想致しております > 無料メールマガジン版 ( 別途有料版開始時打切 ) > http://mailux.com/mm_dsp.php?mm_id=MM53D8AF3589BC7 > > > 設計概要自体の代りに周辺情報 ( 論文翻訳等 ) をお届け致しております > > > > Google 翻訳 http://arxiv-vanity.com/papers/1612.00530/ > > ? ry として提供しているので、PDFを詳しく読む必要 ry 。 > arXiv Vanityは、 arXivの学術論文をレスポンシブWebページとしてレンダするので、PDF に煩わされる必要はありません。 > arXiv.orgでこの論文を読んでください。 > > > ? PEZY ‐ SC ry > PEZY-SCプロセッサ上の不規則格子反復法のためのデータ圧縮アルゴリズムの実装と評価 > > Naoki Yoshifuji  , Ryo Sakamoto † , Keigo Nitadori ‡ and Jun Makino ァ >  Fixstars , 〒141-0032 東京都品川区大崎1-11-1大町西タワー18F GateCity > Eメール： yoshifujiATfixstars > † Fixstars , 〒141-0032 東京都品川区大崎1-11-1 18F GateCity大崎ウエストタワー > 電子メール： sakamotoATfixstars > 現在の住所：101-0052 東京都千代田区神田小川町1-11 5F千代田小川町クロスタ5Fペジーコンピューティング > 現在の E メール ： sakamotoATpezy ? プレゼントメール > ‡ RIKEN AICS , 650-0047 兵庫県神戸市中央区港島南町7-1-26 > Eメール： keigoATriken > ァ 657-8501神戸市灘区六甲台1-1神戸大学理学研究科惑星学専攻 ? 惑星学科 > 電子メール： jmakinoATpeople.kobe-u.ac. 抄録 不規則格子上の反復法は、複雑な幾何学を持つ偏微分方程式を解くために、計算科学および工学のすべての分野で広く使用されてきました。 それらは、比較的低い計算コストで複雑な形状を表現するための柔軟性を提供する。 しかし、過去20年間における高性能プロセッサの進化の方向性は、比較的低いメモリ帯域幅のために、不規則グリッド上の反復法の計算効率の深刻な低下を引き起こした。 データ圧縮は、原則として、反復方式に必要なメモリメモリ帯域幅を削減し、それによって効率を向上させることができます。 例としてHPCGベンチマーク用に生成された行列を使用して、PEZY-SCプロセッサにいくつかのデータ圧縮アルゴリズムを実装しました。 ? ry 帯域幅のために理論上の限界に近い値です。 HPCGベンチマークのSpMV（Sparse Matrix-Vector Multiplication）部分では、データ圧縮なしの最良の実装では11.6Gflops /チップを達成しました。これはメモリ帯域幅に沿った理論上の限界に近い値です。 データ圧縮を使った私たちの実装は32.4Gflopsを達成しました。 HPCGで使用されるグリッドは幾何学的に規則的であり、したがってその圧縮効率が非常に高いため、これはもちろんかなり極端なケースです。 ? しかし、実際 ry 。 とは言え、実際のアプリケーションでは、特に解像度が高い場合は、グリッドの大部分を規則的なジオメトリにすることが可能です。 ? ry データ ry 。 註記しますがデータ圧縮/解凍サブルーチンを追加する以外は、プログラムの構造を変更する必要はありません。 ? ry なると考えています。 したがって、データ圧縮は、不規則なグリッドの使用に依存する多くのアプリケーションのパフォーマンスを向上させるために非常に有用な方法になると我々は信じます。 索引用語 -有限要素解析、スパース行列、データ圧縮 I. はじめに 本稿では、PEZY-SCプロセッサ上でのスパース行列とベクトルの乗算（以下、SpMV乗算）の実装と性能について述べる。 特に、パフォーマンスに対するさまざまなデータ圧縮方式の影響に焦点を当てます。 スパース行列とベクトルの乗算は、不規則グリッドを使用する多くの実際のアプリケーションの中で最も時間がかかる部分です。 最もよく知られている例は、構造解析と他の多くのCAEアプリケーションのためのFEM（有限要素法）です。 不規則なグリッドは、複雑な形状を持つオブジェクトの分析を可能にするために不可欠です。 ? ry が、一般的に不規則なグリッドははるか ry 数の自由でより ry します。 規則的なグリッドを複雑な形状に適用することは不可能ではありませんが一般的には、不規則なグリッドは遥かに少ない数の freedoms で、より正確な結果を提供します。 ? ry 乗算で合理的な効率 ry 。 しかしながら、現代のHPCシステム上でのSpMV乗算に於ては合理的効率さえ達成することは非常に困難になっています。 ? この問題には主に2つの理由 ry 。 この困難には 2 つの主たる理由があります。 最初のものはメモリ帯域幅です。 ? ry ます。 行列Aとベクトルxの乗算を考えます、 ｙ ＝ Ａ ｘ 。 （1） ? 実際のアプリケーションでは、行列Aは大きすぎてキャッシュメモリに収まりません。 現実のアプリケーションでは、行列Aは、キャッシュメモリに収めるには大き過ぎます。 ? ry yははるかに小さいので、常に広範囲のデータを再利用する可能性があります。 一方、ベクトルxとyそれらは遥かに小さく、そしてそれらの為の広範囲データ再利用の実現性が常にあります。 ? ry 、ＳｐＭＶ動作のため ry の主な部分 ry 。 したがって、 SpMV オペレーションのためのメモリアクセスの支配的部分は、（スパース）行列Ａの読み取りである。 ? ry Aのゼロ以外の要素数 ry 。 行列Aの正確なデータサイズは、使用されるデータ形式によって異なりますが、 A の要素である所の非ゼロなものの個数より小さくすることはできません。 ? Aの 1つの非ゼロ要素あたり ry 。 A の非ゼロ要素 1 つあたりの浮動小数点演算の数は2です。 したがって、データフォーマットが倍精度フォーマットである場合、2つの浮動小数点演算ごとに8バイトのメモリ読み取りが行われます。 ? つまり、「 ry 。 言換えれば、「必須」B / F（byte per flops）数は8/2 = 4です。 ? ここでは、インデックス用に読み込まれたメモリを無視したことに ry 。 インデックス用に読込まれるメモリを我々が無視している事に注意してください。 ? FLLアプリケーション ry 50100 ry 。 FEM アプリケーションで行列を保存するのに最も効率的な形式であるELL形式を使用すると、必要な帯域幅は50〜100％増加する可能性があります。 ? 従って、Ｂ ／ Ｆ数に関して要求 ry 幅は、６ ry 。 従って、要求されるメモリ帯域幅の B/F 数表現は、６から８の間であり得る。 ? ry かなりの部分を ry 。 1980年代のベクトルマシンのハードウェアB / F数は4から12の間だったので、1980年代にはベクトルスーパーコンピュータはSpMV動作のメモリ帯域幅要求の少なくともかなりの割合をサポートできるメモリサブシステムを持っていました。 http://webcache.googleusercontent.com/search?q=cache:arxiv.org/pdf/1612.00530#2 1 http://www.hpcg-benchmark.org/custom/index.html?lid=155&slid=288 ? マシン ry 秒あたりの浮動 ry 演算の理論上のピーク性能で割った ry 。 ここでは、マシンのハードウェアB / F数は、1秒当り浮動小数点演算数で測定された浮動小数点演算ピーク性能理論値で割った、バイト/秒での理論的な（または測定された）メモリ帯域幅として定義されます。 1980年代のベクトルマシンは、SpMV乗算のために浮動小数点ユニットをビジー状態に保つのに十分なメモリ帯域幅を持っていました。 しかし、最近のHPCシステムで使用されているマイクロプロセッサのB / F数ははるかに少なくなっています。 ? ry 、Kコンピュータ ry 。 たとえば、京コンピュータのB / F数は0.5であり、これは今日の標準ではかなり例外的に高いです。 ? ry of around 0.2. 最近のXeonベースのシステムでは、B / F値は約0.2です。 ? ry around or less than 5%. 必要なB / F数が6の場合、これは現代のHPCシステムの理論上の最大効率が約5％以下になることを意味します。 ? ry マシンのHPLパフォーマンスの測定値 ry パフォーマンスの測定値の比率 ry 。 実際、2016年6月のHPCGベンチマーク 1 のトップ10リストのマシンでのHPLパフォーマンス測定値とHPCGパフォーマンス測定値との間の比率は0.4〜5％の範囲であり、Xeonベースのシステムの数は2〜3％です。 ? ry は、明らかにそれらに対するSpMV乗算の非常に低い効率の主な理由です。 したがって、現代のHPCシステムの低メモリ帯域幅は、それらでのSpMV乗算の非常に低い効率の筆頭理由である事が明白である。 第二の理由は、現代の設計者がやや広い幅（４〜８ワード）のＳＩＭＤ演算装置を採用する傾向があることである。 ? ry 、ベクトルまたは行列のいずれかの要素 ry 。 不規則行列に対するSpMV演算の計算カーネルは、ベクトルのか行列のかどちらかの要素への間接アクセスを必要とします。 ワイドSIMDユニットを搭載した最新のプロセッサでの間接アクセスのパフォーマンスは非常に低いです。 一部のプロセッサは、間接メモリアクセス用のSIMD操作をサポートしていません。 間接メモリアクセスのためのSIMD命令を持つマシン上でさえ、それらのスループットは単純なSIMDロード/ストア命令よりはるかに低いです。 一部のマシンでは、この非効率によってSpMV操作のパフォーマンスがさらに低下する可能性があります。 ? ry は、要素ごと（EbE）の方法です。 必要なメモリ読み取りを減らすための1つの方法は、 EbE ( element-by-element : 要素ごと ) メソッドです。 ? ry では、スパース行列Aは、各要素の元の ry データからその場で構築 ry 。 EbE法では、各要素の、元の物理データと位相データとから、オンザフライでスパース行列 A が構築されます。 ? すべての要素 ry は生成 ry を減らす ry 。 その全要素の総データ量は、生成された行列のサイズよりもかなり小さいので、メモリアクセスの量を我々は減らすことができます。 行列のオンザフライ構成の計算コストがかなり高い場合でも、EbE法に移行することで総計算時間を大幅に減らすことができます。 EbE法は、計算コストが増加しても実際の計算速度を大幅に向上させることができるため、多くのFEMアプリケーションで広く使用されるようになりました。 必要とされるメモリアクセス量を減らすのに潜在的に有用であり得る別の方法は、何らかのデータ圧縮アルゴリズムを使用して行列を圧縮することである。 ただし、HPCアプリケーションでのデータ圧縮の使用に関する多くの研究論文があるにもかかわらず、SpMV乗算へのデータ圧縮の適用に関する研究はほとんどないようです。 ? ry するためには、1つの行列要素あたり ry データ圧縮解除アルゴリズム ry 。 考えられる理由の 1 つは、実際の高速化を達成する際の、行列要素 1 つあたりの浮動小数点演算の数が2つだけなので、圧縮データ解凍アルゴリズムは非常に効率的でなければならないことです。 ? 解凍アルゴリズムが２、３以上の命令を必要 ry それは総費用のかなり ry 。 ほんの幾つかでなく更なる命令をもしも解凍アルゴリズムが必要とするならば、それはトータルコストのかなりの増加を引き起こすでしょう。 ? ry に、一般に、解凍アルゴリズムはいくつかのテーブル ry 操作、すなわち現代 ry 特に効率的ではない間接的なメモリアクセスを必要 ry 。 さらに、現代のマイクロプロセッサにとって特に非効率的な、テーブルルックアップ操作即ち間接メモリアクセスをいくつか、一般に解凍アルゴリズムは必要とする。 一方、システムのハードウェアB / F数が極端に小さい場合は、データの圧縮/解凍を使用することで、SpMVの乗算でパフォーマンスが大幅に向上する可能性があります。 本稿では、HPCGベンチマーク[ 4 ] 、 [ 5 ]のSpMV部分におけるZettaScaler-1.5スーパーコンピュータ[ 7 ]の性能について、データの圧縮/解凍を使用した場合と使用しない場合について報告します。 ZettaScaler（以前はExaScalerと呼ばれていました）システムは、第一世代のPEZY-SC 1024コアプロセッサチップをベースにしています。 2014年11月のTOP500リストに掲載され、Green500リストの第2位にランクされています。 2015年6月のGreen500リストでは、3つのExaScalerシステムが上位3つのランクを占めました。 ? ry されたシステムは ry の数を大幅 ry 。 ＃1にリストされたそのシステムは、7 Gflops / Wを超えるワットあたりの性能を達成し、2014年11月のGreen500リストの＃1システムの値を大幅に上回りました。 2016年6月現在、Green500リストでは依然としてナンバー1の地位を維持しています。 データ圧縮アルゴリズムのテストベッドとしてZettaScalerシステムを使用したのは、ハードウェアのB / F数が0.05程度とかなり低いためです。 ? ry 将来プロセッサに ry 。 したがって、近い将来に於てのプロセッサの為に役立つようなアルゴリズムのテストベッドとして理想的です。 ? さらに、その ry 。 付加えると、そのプロセッサコアはSIMDユニットを持っていません。 したがって、データ圧縮を使用してSpMV乗算をかなり高速化することができます。 ZettaScalerシステムは、GPGPUがPCIeインターフェースを介してIntel Xeonプロセッサーに接続され、XeonプロセッサーがInfinibandネットワークを使用して接続される、最新のGPGPUベースのシステムとかなり似ています。 ただし、ZettaScalerシステムには2つの独自の機能があります。 ? 最初のものはもちろん物理的に共有されたメモリと階層的なキャッシュを ry 。 1 つ目は勿論、物理共有メモリと階層的キャッシュとを持った1024コアMIMDプロセッサであるPEZY-SCプロセッサチップの使用です。 ? 日本 ry 。 それは日本のベンチャー企業、PEZY Computingによって開発されました。 2つ目の特長は、フルオロカーボン（3M Fluorinert FC-43）を使用した液浸冷却システムです。 ZettaScalerシステムでは、高密度実装を実現するために、Xeonプロセッサ用のマザーボードとPEZY-SCプロセッサ用のプロセッサカードを設計しました。 ? ry チップの接合部温度を低下させる ry 的な操作が ry 。 液浸冷却の使用は、ＰＵＥ数を減少させ、さらにプロセッサチップの連接部温度をも又減少させるという潜在的な利点を有し、その結果、よりエネルギー効率的に優れたオペレーションがもたらされる。 ただし、ZettaScalerシステムの1ワットあたりのパフォーマンスが高いことの主な理由は、PEZY-SCプロセッサ自体の設計です。 ? ry プロセッサは、TSMC ry 使用して、それぞれ完全 ry を備えた1024個のMIMDコアを ry ダイに統合します。 PEZY-SCプロセッサは、完全にパイプライン化された倍精度乗算加算（MAD）ユニットを各々備えた MIMD コア × 1024 個をサイズ400mm ^ 2のダイに、TSMCの28HPMプロセスを使用して統合しています。 http://webcache.googleusercontent.com/search?q=cache:arxiv.org/pdf/1612.00530#3 公称消費電力は733 MHzクロックでの動作でわずか65 Wです。 ? ry 倍精度稠密 ry 低い（わずかに低い）にも ry 達成HPLでは50％以上。 少なくともHPLベンチマーク、またはより具体的にはDGEMM演算（倍精度密行列乗算）の場合、理論上のピーク性能と比較した効率は依然としてかなり低い ( HPL では、 50 % よりも僅かに良好 ) にもかかわらず、PEZY-SCプロセッサはワットあたり非常に優れた性能を達成した。 一方、PEZY-SCプロセッサは階層型（ただし非コヒーレント）のキャッシュと物理的に共有されたメモリを備えたMIMDメニーコアプロセッサであるため、アプリケーションの移植は比較的簡単です。 また、OpenCLのかなりよく設計されたサブセットであるPZCLもサポートされています。 ? ry 最初のPEZY ry 性能を紹介し、これまでの研究では通常 ry 適用した。 本稿では最初に、これまでの研究での通常の最適化を適用した PEZY-SCプロセッサでのHPCGの性能を示す。 次に、オンザフライでのデータ圧縮および解凍を使用したSpMV操作の「最適化された」実装のパフォーマンスについて説明します。 この論文は以下のように構成されています。 まず、セクションIIでは、PEZY-SCプロセッサとZettaScalerシステムの概要を説明します。 セクションIIIでは、PEZY-SCプロセッサ上でのHPCGの実装について説明します。 セクションIVでは、パフォーマンス結果を示します。 最後に、セクションVで 、私たちが実装したデータ圧縮/解凍アルゴリズムとPEZY-SC上で測定された性能を提示します。 セクションVIでは、論文を要約し、研究開発の今後の方向性について議論します。 II PEZY-SCプロセッサチップとZettaScalerシステム ? ry プロセッサとZettaScalerシステムのアーキテクチャの概要 ry 。 このセクションでは、PEZY-SCプロセッサのと ZettaScaler システムのとのアーキテクチャ概要を説明します。 サブセクションII-Aでは、PEZY-SCプロセッサの概要を説明します。 サブセクションII-Bでは、ZettaScalerシステムの概要を説明します。 A. PEZY-SCプロセッサ ? ry ]は、 1024 ry コアと3 ry メモリを統合 ry 。 PEZY-SCプロセッサ[ 6 ]、[ 7 ]は、 3レベルのキャッシュメモリを備えた、 1024個のMIMDコアを統合しています。 ? ry では、プロセッサ ry 始めて、ボトムアップの構造について説明 ry 。 このセクションではその構造について、プロセッサコアから始めて、ボトムアップに説明します。 各PEZY-SCコアは、1サイクルにつき1回の倍精度MAD操作または2回の単精度MAD操作を実行できます。 ? 通常 ry を採用しています。 それは通常のロードストアアーキテクチャを持ちます。 ? ry コアは、4方向（8方向にする ry 備えた非常 ry デュアル発行のインオーダー ry 。 このコアは非常に単純なデュアルイシューの、 4 ウェイ（8 ウェイにすることも可能）のSMTを備えたインオーダコアです。 したがって、インオーダーコアが使用されていても、データキャッシュのレイテンシがパフォーマンスに与える影響は比較的小さくなります。 PEZY-SCプロセッサコアのかなり異例な機能の1つは、各コアが16KBのローカルメモリを持ち、そのコアからしかアクセスできないということです。 ? ry データを ry 。 それは別々のローカルアドレス空間を持ち、コアによって繰り返し使用されるデータ、を格納するために使用することができます。 ? ry 提供するため、特 ry では、高い効率を達成するためにこの ry ストレージを利用 ry が不可欠です。 このローカルメモリは非常に高い帯域幅を持つ最大のオンチップストレージ（合計16MB）を提供するのでこのローカルストレージを、高効率達成アドバンテージを得る為に利用することが、特に計算集約型のアプリケーションでは不可欠です。 ? ry 、ＤＧＥＭＭ動作の性能 ry オンチップ記憶装置との間 ry 。 例えば、 DGEMM 演算の性能に関して、必要なメモリ帯域幅と必要なオンチップストーリッジとの間にはよく知られたトレードオフがある。 したがって、このローカルメモリの使用はDGEMMの高効率を達成するために不可欠です。 2つのコアが2KBの1つのL1Dキャッシュを共有します。 L2Dキャッシュのサイズは64KBで、1つのL2Dキャッシュは16個のコアで共有されています。 PEZYの用語では、L2Dキャッシュを共有するコアは「市」を形成します。 L3Dキャッシュのサイズは2MBで、16の「市」が1つのL3Dキャッシュを共有して「県」を形成しています。 ? ry 各都道府県 ry 。 したがって、各県は256コアで構成され、1つのPEZY-SCチップは4県で構成されています。 最後に、チップはDDR3またはDDR4 DRAMのいずれかの8チャネルに接続されています。 したがって、ＰＥＺＹ  ＳＣプロセッサは３つのレベルのキャッシュメモリを有する。 これらのキャッシュメモリはコヒーレントではありません 。 ? コアは、明示 ry のみ他のコア ry データを読み ry 。 同じL2Dキャッシュを共有するコアは、他コアによって書き込まれたデータ、を明示的なフラッシュ操作及びバリア同期の後でのみ読み取ることができます。同じことがL3Dキャッシュとメインメモリにも当てはまります。 ? フラッシュ同期命令とバリア同期命令の両方がキャッシュ ry 。 フラッシュのとバリア同期のとの両方の命令が、キャッシュの各レベルに提供されます。 ? ry 対しても使用できます。 正確には、バリア命令は1つのコア（複数のスレッド）に対してのものでもあります。 明らかに、このキャッシュコヒーレンシの除去はプロセッサ設計を非常に単純化し、そして３レベルのキャッシュを有する１０２４コアプロセッサを構成することを可能にした。 L1、L2、およびL3データキャッシュのラインサイズは、64、256、および1024バイトです。 ラインサイズを変更することで、PEZY-SCプロセッサの設計者は、L2およびL3データキャッシュの帯域幅を非常に高く保ちました。 L2Dキャッシュの帯域幅はL1Dのそれと同じです、そして、L3Dはそれらのおよそ半分を提供します。 アプリケーションプログラマの観点からは、キャッシュコヒーレンシの欠如は、HPCアプリケーション（またはそれらのコンピューティングカーネル）に関する限り、厳しい制限を課すようには思われません。 ? ry にとって、プログラマーはプロセッサ ry 瞬間を知って ry 。 多くのアプリケーションに付いては、プロセッサが通信する必要がある瞬間をプログラマは知っています。 さらに、彼らは高効率を達成するためにコア間の通信を最小にしようとします。 したがって、チューニングの観点から、キャッシュコヒーレンシの欠如は、コア間のトラフィックを制御するプログラマの能力と見なすことができます。 ? さらに、そうでなければコアＡがコアＢが更新したと期待するものが実際 ry ので、バリア同期は通信 ry である。 更に、バリア同期は、それがなければ、コア B が更新した、とコア A が期待するもの、が実際にはまだ更新されていないかもしれないので、通信の前にほとんど常に必要である。 ? ry のフラッシュ ry 同期は ry 。 したがって、効率的なハードウェアサポートの、フラッシュおよびバリア同期、は非常に便利です。 命令用キャッシュもマルチレベルです。 ? 私のキャッシュでは、回線サイズと帯域幅は基本 ry 。 I キャッシュでは、ラインサイズと帯域幅とが基本的にすべてのレベルで同じです。 ? すべてのコアが同じで比較的小さなカーネルを実行 ry 。 比較的小さい同じカーネル、を全コアが実行している限り、この構造はうまく機能します。 各PEZY-SCチップには32レーンのPCIe（Gen3）インタフェースがあり、統合された2つのARM 926プロセッサによって制御されます。 ? ry プロセッサのＤＭＡまたはＰＩＯ読み ry 込みのいずれかによって ry プロセッサのメイン ry 。 ＰＣＩｅインターフェースは、ホストプロセッサ PIO 読み取り／書き込みか DMA かのどちらかによって、ＰＥＺＹ  ＳＣプロセッサのメインメモリとホストプロセッサとの間でデータを転送するために使用され得る。 PEZY-SCプロセッサは、OpenCLの方言であるPZCLと呼ばれる言語をサポートしています。 OpenCLのほとんどの機能をサポートしていますが、パフォーマンスが重要な場合は特に制限がいくつかあります（もちろんほとんど常にそうです）。 最高の効率を達成するには、作成されるソフトウェアスレッドの数は、ハードウェアスレッドの最大数（チップあたり8192）と同じでなければなりません。 もう1つの違いは、キャッシュがコヒーレントではないという事実から来ています。 http://webcache.googleusercontent.com/search?q=cache:arxiv.org/pdf/1612.00530#4 正しい結果を保証するために、適切なレベルのキャッシュをフラッシュする関数を手動で挿入する必要があります。 小さなコンピューティングカーネルの場合、これはそれほど難しくありませんが、もちろん修正が難しいバグの原因になる可能性があります。 ? 1台のPEZY-SCプロセッサには8チャネルのDDR4 DRAMが搭載されているため、DDR4クロック ry 。 >PEZY-SC プロセッサ 1 つは、 DDR4 DRAM チャネルを 8 つ持っており、DDR4クロックが1333 MHzの場合、理論上のピークメモリ帯域幅は85 GB /秒です。 実際の読み取り帯域幅は約75 GB /秒、STREAMコピーのパフォーマンスは40 GB /秒です。 書き込み帯域幅が読み取り帯域幅の1/2であるため、コピー性能は低くなります。 L1、L2、およびL3キャッシュの読み取り帯域幅（チップ合計）は、それぞれ2000、2000、および700 GB /秒です。 B. ZettaScalerシステム 現在の世代のZettaScalerシステム（ZettaScaler-1.5）は複数のコンピューティングノードで構成され、各ノードは1つのXeon（E5-v3）プロセッサと4つのPEZY-SCプロセッサで構成されています。 ? ry PEZY-SCプロセッサは特別 ry 基板にも搭載 ry 。 Xeonプロセッサは特別に設計されたマザーボードに搭載され、PEZY-SCプロセッサも又特別に設計されたモジュール基板に搭載されています。 ホストXeonプロセッサと1つのPEZY-SCプロセッサ間の接続は、8レーンのGen3 PCIeチャネルです。 コンピューティングノード間のネットワークは、標準のFDR Infinibandです。 ? ry 「Shoubu」 ry 。 ZettaScalerシステムの最大の既存の構成は、理研ACCCに設置された「菖蒲」と呼ばれる320ノードシステムです。 より小さなシステムが理研AICSと同様にKEKに設置されている。 ZettaScalerシステムの非常にユニークな特徴は、フッ化炭素（3M Fluorinert FC-43）冷却剤による浸漬冷却の使用です。 以前に使用された油性冷却剤と比較して、フルオロカーボン冷却剤は取り扱いの容易さ、安全性（それは不燃性）、およびより小さい熱膨張係数のようないくつかの利点を有する。 主な欠点は価格と潜在的な温室効果であるが、後者は実際に使用される特定の冷却剤の高い気化温度のためにそれほど厳しくない。 III HPCGベンチマークの概要とPEZY-SCへの実装 ? ry プロセッサへの参照実装について ry 。 このセクションでは、HPCGベンチマーク自体とPEZY-SCプロセッサでのリファレンス実装とについて簡単に説明します。 ? ry の実装 ry 。 サブセクションIII-Aでは、HPCGベンチマークについて説明し、サブセクションIII-Bでは、PEZY-SCでのHPCGの我々の実装について説明します。 Iii-a HPCGベンチマーク ? その ry よると、HPCG ry ]は、セクション ry に、「計算 ry の比率が低く、多く ry 計算を代表するパフォーマンス ry 。 セクションIで既に説明したように、HPCGベンチマーク[ 4、5 ]はその設計者によると「計算とデータアクセスとの比率の低さを伴った多くの重要な科学計算の代表」のパフォーマンスを測定するように設計されています。 このように、それは不規則グリッド上でのMultigridソルバー付きCGを使用したFEMの主要な操作を模倣しています。 残念なことに、現在入手可能なHPCGの公式仕様[ 5 ]はかなり古く、そこで説明されているアルゴリズムと現在のベンチマークコードで使用されているものはまったく異なります。 以下では、最初に[ 5 ]に従い、次に加えられた変更を要約します。 数学的観点からすると、HPCGで解決される問題は、27点ステンシルを使用してサイズ（ n x n p x 、 n y n p y 、 n z n p z ）の正方格子上で離散化された3D拡散方程式です。 （ n x 、 n y 、 n z ）は各MPIプロセス上のグリッドのサイズ、 （ n p x 、 n p y 、 n p z ）はMPIプロセスグリッドです。 したがって、MPIプロセスの総数は、 n p x n p y n p zです。 ? ry Gauss-Seidel前提条件付きCG ry 。 元の仕様では、HPCGは対称Gauss-Seidel前処理付きCG反復を使用してこの問題を解決しており、ユーザーはこの基本的なCGアルゴリズムを変更することはできません。 特に、大規模な3D問題を解決したい場合に不可欠なマルチグリッド法は含まれていません。 したがって、当然のことながら、これは現在の仕様で変更されています。 ? ry 幾何学的マルチグリッド前処理装置が ry 。 ４段Ｖサイクル幾何マルチグリッド前処理が使用される。 ? ry 主要な操作、特にSymGS ry Waxpbyの ry 。 HPCGベンチマークで測定されるのは、主要な演算、特に、SymGS、SpMV、制限、延長、DotProduct、およびWaxpby 、のコンピューティング速度の加重平均です。 通常、ComputeSPMVとComputeSYMGSの2つの関数が総計算時間を左右し、パフォーマンスを決定します。 Iii-B PEZY-SCでのHPCGの実装 ? ry の参照実装 ry 。 PEZY-SC上でのHPCGのリファレンス実装は非常に簡単です。 ? ry の手順が ry ）。 次の6つのプロシージャがPEZY-SCに移植されました（PZCL言語を使用して書き直されました） : * SymGS 対称 Gauss-Seidel ? 対称性 * SpMV * Restriction 制限 * 延長補間 * ドット積 * ベクトルの線型和 ( Waxpby ) ? ry に保存されます。 行列データとベクトルデータの両方がPEZY-SCのメモリに保持されます。 そのため、ホストXeonプロセッサとPEZY-SCプロセッサの間では、コンバージェンスチェックなどのために転送される少量のデータと、ノード間で交換される境界データだけが交換されます。 PZCLを使った書き換えはとても簡単です。 ? ry 、スレッドの総数が実際には使用可能なハードウェアスレッドの数と同じ ry 。 前述したように、現在気をつける必要がある主な点は、スレッド総数と有効ハードウェアスレッド数とが実際に同じであることです。 ? ry 代数ブロック多色順序付け[ ry 。 格子の規則的な構造を直接利用する変更は最適化段階では許されないので、代数ブロック化多色順序付け[ 8 ]はSymGS部分に使用されます。 表１は、１回のＣＧ反復で実行される操作を示す。 4段階のVサイクルマルチグリッド法が使用されているため、SymGSルーチンは反復ごとに7回、SpMVは4回呼び出されます。 http://webcache.googleusercontent.com/search?q=cache:arxiv.org/pdf/1612.00530#5 ? 繰り返す 操作 bufを送る ry 繰返し 処理 Buff er送信 p z サイクル 3 FillZero ↓ 3 SymGS P → X X → P ↓ ( 訳注 : V サイクル前処理前半 ? ) 3 SpMV P → X X → P ↓ ( 訳注 : V サイクル前処理前半 ? ) 3 Restriction 制限 ↓ ( 訳注 : V サイクル前処理前半 ? ) FillZero 3 SymGS P → X X → P ↑ ( 訳注 : V サイクル前処理後半 ? ) 3 延長補間 ↑ ( 訳注 : V サイクル前処理後半 ? )  SymGS P → X X → P CG ? 対称性 ドット積 CG ?ドットプロダクツ ベクトルの線型和 ( Waxpby ) CG SpMV P → X X → P CG ドット積 CG ?ドットプロダクツ ベクトルの線型和 ( Waxpby ) CG ベクトルの線型和 ( Waxpby ) CG ドット積 CG ?ドットプロダクツ 表１： １回のＣＧ反復中の動作および通信。 PとXはそれぞれPEZY-SCとXeon、 pは方向ベクトル、 zは前処理済み残差ベクトルを表します。 Iv HPCGベンチマーク結果 Iv-a 測定された性能 ? ry に搭載されている「Ajisai」 ry 。 理研AICSに設置されている「紫陽花」ZettaScalerシステムでHPCGの性能を測定しました。 合計64個のXeonノードにそれぞれ4つのPEZY-SCプロセッサがあります。 最大32台のPEZY-SCプロセッサでパフォーマンスの測定を行いました。 1つのMPIプロセスに1つのPEZY-SCプロセッサを割り当てます。 したがって、4つのMPIプロセスが各Xeonプロセッサ上で実行されます。 PEZY-SCプロセッサのコアクロックは733 MHzです。 メモリクロックは1333 MHzです。 ホストCPUは2.3 GHzクロックで8コアのXeon E5-2618L v3です。 ? ry 32 GB or DDR4 memory, ry . ? ry 32 GBまたはDDR 4 ry 。 各PEZY-SCプロセッサは32 GBのDDR 4メモリ、ホストXeonプロセッサは128 GBです。 32 PEZY-SCプロセッサでは、HPCG 3.0評価で達成されたパフォーマンスは168.06 Gflopsです（HPCG 2.4評価では189.15 Gflops）。 使用される問題サイズは、 （ ７０４、７０４、３５２ ）の大域的問題サイズに対して、 ４ ラ ４ ラ ２プロセッサグリッドを有する１７６ ラ ３ローカルグリッドである。 この特定の問題サイズについて、HPCGは正確に50回の反復後の収束を報告しました。 実行時間の内訳を図1に示します。 ? いつものように、 ry 。 通例通り、SpMVとSymGSが実行時間を左右します。 これら2つのセクションの速度は、それぞれ238.4 Gflopsと217.6 Gflopsです。 MPIプロセスごと（またはPEZY-SCプロセッサごと）のパフォーマンスを計算すると、7.45 Gflopsと6.80 Gflopsです。 SymGS, 56.34% SpMV, 25.86% ドット積 , 6.22% ベクトルの線型和 ( WAXPBY ) , 5.91% 延長補間 , 4.00% Restriction 制限 , 1.67% 図1： HPCGベンチマークコードのセクションに費やされた計算時間の割合 比較のために、1つのPEZY-SCプロセッサで同じコードのシングルプロセスパフォーマンスを測定しました。 MPIプロセスあたりの問題サイズは同じです。 SpMVおよびSymGSセクションの速度は、それぞれ9.47 Gflopsおよび8.08 Gflopsです。 ? ry 約20％になります。 したがって、並列実行のため（主に通信オーバーヘッドのため）、オーバーヘッドは約 20 ( 訳注 : 四捨五入 ? ) % だと見て取れます。 ? シングルプロセスと32プロセスのパフォーマンス ry 結果、並列化のオーバーヘッド ry であることがわかりました。 並列化時オーバーヘッドは無視できないもののかなり小さいこと、そしてシングルノードのパフォーマンスが全体のパフォーマンスを決定する主な要因であることとを、シングルプロセスのと 32 プロセスのとのパフォーマンス値を比較した結果は示しています。 Iv-B リファレンス実装のパフォーマンス分析 このセクションでは、私たちのリファレンス実装の達成されたパフォーマンス、特にシングルチップ計算のパフォーマンスが合理的に最適化されているかどうかを説明します。 ? ry を簡単に ry 。 説明を単純にするために、分析をSpMVに限定します。 ? ry された性能数はそれほど ry 、我々はSpMVの分析がハードウェアとソフトウェアの振る舞いを議論するのに十分であると信じる。 SpMVとSymGSの達成されたパフォーマンス値はそれほど変わらないので、ハードウェアのとソフトウェアのとの振舞いを議論する為には SpMV の分析で充分であると我々は信じる。 ? ry 、最高レベルでの動作に対して１１．６ ry 。 ＰＥＺＹ  ＳＣプロセッサ上でのＳｐＭＶ動作のシングルチップ性能は、最高域での演算としては１１．６Ｇｆｌｏｐｓである。 ? ry SpMV操作につき ry SpMVの性能は帯域幅に制限があります。 行列は非常に大きく、行列の各非ゼロ要素は1回のSpMV演算に付き1回しか使用されないため、SpMV性能即ち帯域幅制限です。 1つの要素は、1つの4バイト整数と1つの8バイト浮動小数点数で表され、この要素に対して2つの浮動小数点演算が実行されます（1回の乗算と1回の加算）。 したがって、 x Gflopsの速度を達成するために必要なメモリ読み取り帯域幅は、単純に（ x / 2 ） ラ 12 = 6 x GB / sで与えられます。 したがって、11.6 Gflopsは70 GB /秒の読み取りパフォーマンスを意味します。 PEZY-SCプロセッサの理論上のピークメモリ帯域幅は85 GB /秒であり、実際に測定された読み取りパフォーマンスは約75 GB /秒です。 したがって、SpMVで達成可能なピーク性能は約12.5 Gflopsです。 11.6 Gflopsのパフォーマンスは、達成可能なパフォーマンスに非常に近いことがわかります。 このようにして、HPCGをPEZY-SCプロセッサに正常に移植したと結論付けることができ、SpMV操作では、外部メモリのスループットによって決まる理論上の限界に非常に近いパフォーマンスを達成できます。 ? したがって、これでデータ参照の ry 優れた参照実装ができました。 従って、データ圧縮の効果を測定できる良好なリファレンス実装を我々は今持っています。 http://webcache.googleusercontent.com/search?q=cache:arxiv.org/pdf/1612.00530#6 V データ圧縮/解凍を用いたSpMV乗算の実装とその性能 ? ry 、基本的なCGアルゴリズムや前提条件アルゴリズムを変更 ry 。 このセクションでは、ベーシックCGアルゴリズム又は前処理アルゴリズムを変更せずに、必要なメモリ帯域幅を削減する可能性を調べます。 ? ry ように、明示的に禁止されていない必要 ry ための１つの実際的な可能性は、 ry 。 必要なメモリ帯域幅を減らすための、明示的禁止されていない１つの実際的可能性は、セクションＩで論じた様にオンザフライデータ圧縮／解凍の使用である。 ? ry 、無損失と損失の両方 ry 。 HPCでのデータ圧縮の使用は現在活発な研究分野であり、ロスレスと不可逆との両方の多くの方法が提案されています[ 10 ] 。 ? ry 、記憶およびチェックポイント ry 。 データ圧縮の使用に関するこれまでの提案の多くは、ストーリッジ及びチェックポイントのためのものであるが、キャッシュおよびメインメモリ上でのデータ圧縮の使用についての多くの研究もある［ １１、１２、１３ ］ 。 これまでのところ、メインメモリまたはキャッシュメモリのレベルでデータ圧縮を使用することは、HPCではあまり一般的ではありません。 多くの場合、圧縮/解凍操作の計算コストは高すぎます。 しかしながら、ＰＥＺＹ  ＳＣプロセッサ上でのＣＧ反復における疎行列のアクセスの場合には、圧縮技術が有利であり得ると予想するいくつかの理由がある。 まず、圧縮データが何度も再利用されます。 ? したがって、圧縮 ry は比較的重要 ry 。 従って相対的には、圧縮操作のコストは重要ではありません。 高速で効率的な解凍アルゴリズムがまだ必要です。 第二に、PEZY-SCプロセッサは完全にMIMDでマルチスレッドのプロセッサであり、非常に多数の独立したメモリアクセスを同時に生成することができます。 ? この機能は、 ry データ圧縮解除技法 ry 。 このフィーチャは、テーブルベースのデータ解凍技法にとって特に重要です。 ＰＥＺＹ  ＳＣプロセッサの１０２４個のコアのそれぞれは、サイクルごとに１つのロード命令を実行することができる。 ? ry 備えた最新の ry 2つの負荷がかかる可能性があります。 一方、ワイドSIMD実行ユニットを備えた現代的マイクロプロセッサのコアでは、通常、1サイクルに1つまたは2つのロードをイシューする事ができます。 ? y 、データ圧縮解除の ry 。 これらのプロセッサのコアの数は32未満なので、PEZY-SCはテーブルルックアップで1桁以上速くなる可能性があり、その結果、圧縮データ解凍のパフォーマンスが大幅に向上します。 PEZY-SCプロセッサ上でのSpMV操作の単純化された実装のために、高速圧縮/解凍アルゴリズムのいくつかの実装をテストしました。 ? ry ベンチマークに表示されるもの ry 。 ? ry されます。 これまでのところ、最良の結果は単純なテーブルベースの圧縮によって達成されています。 このアルゴリズムでは、最初にマトリックス全体がスキャンされ、マトリックス要素内のすべての固有値がリストされて昇順にソートされます。 ? 私たちは、値テーブルこのリストを呼び出しVとIの番目の要素VがあるV 私は。 このリストを値テーブル V と私たちは呼び、 V の i 番目の要素は vi である。 したがって、ｖ ｉ ＜ ｖ ｉ ＋ １である。 ? ry 要素も昇順に並べ替えられます。 次に、行列の各行について、ゼロ以外の要素をも昇順ソートします。 これで、要素の実際の値でソートされた列インデックスのリストができました。 このリストをソート列リストS iと呼ぶ。 ? さて、各v iについてV、ソート ry 「端末」インデックス ry 。 さて、V の各 vi に付いて、ソートされた非ゼロ要素のリスト内のその値の最後の位置を計算し、その値を記録して「終端」インデックスのリスト T iを作成します。 ? 行の元のELL形式 行に付いてのオリジナル ELL フォーマット 値 -1 -1 26 -1 -1 列 45 49 50 51 65 値テーブル 値 -1 26 ? 行の圧縮式 行に付いての圧縮表現 S i 45 49 51 65 50 T i 3 4 図2：データ圧縮アルゴリズム ここでの暗黙の前提は、値テーブルのサイズが小さいということです。これはHPCGには確かに当てはまりますが、CGメソッドの一般的な用途には必ずしも当てはまるとは限らない可能性があります。 ? ry が頻繁に表示されます。 一方、物理的特性が一様な領域に一定サイズの要素を使用すると、同じ値の要素がかなり頻繁に現れます。 したがって、たとえ値テーブルのサイズを小さくするように制限したとしても、私たちの圧縮方法は元の行列の行の大部分でうまくいく可能性が非常に高いです。 ? ry 場合、１ノード当たりのＳ ｉのサイズは２７であり、 ry 。 ＨＰＣＧ ＳｐＭＶ演算における行列の場合、Ｓ ｉのサイズは 27/node であり、Ｔ ｉは２であり得る。 したがって、行列の1行は、324バイトの元のサイズから（ 27 + 2 ） ・ 4 = 116バイトに圧縮されます。 次のようにして、S iのリストをさらに圧縮できます。 まず、列インデックスの実際の値を対角要素に対する相対値に変換します。 ? ry パターンをテーブルに登録してデータ圧縮を実行します。 次に、この列インデックスの相対変位のパターンをデータ圧縮実行の為にテーブルに登録します。 ? ry ノードは相対変位に対して同じインデックス ry 。 大部分のノードは、同じ相対変位インデックスパターンを持つので、この圧縮はインデックス配列のサイズを4 Nバイトに効果的に減らすことができます。ここで、Nは行列の次元です。 したがって、ノードあたり116バイトではなく、ノード ( ? 訳注 : 行列内のノード , 行 , Si ) あたり12バイトになりました。 この表に行列要素自体の値を登録すれば、おそらくサイズをさらに3分の1に減らすことができ、結果としてノードあたり4バイトになります。 ファイナルテーブルに単純なランレングス圧縮を適用することで、おそらくデータをさらに圧縮できます。 圧縮方法 測定された性能 理論的パフォーマンス オリジナル 11.6GF 12.5GF ? 元の データ表 15.9GF 34.8GF データ表+インデックス表 32.4GF 326GF ? データ+索引表 表ＩＩ：ＳｐＭＶ動作に適用されたデータ圧縮アルゴリズムの効果 これまでのところ、最初の2つの圧縮方式を実際に実装しました。 結果を表2に示します。 データ配列のみを圧縮する最初のアプローチでは、理論的には約3倍のスピードアップが得られ、実際には50％のスピードアップが実現されます。 インデックス配列とデータ配列の両方が圧縮されている2番目のものは、理論的には約25倍のスピードアップを達成し、実際には約2.8倍のスピードアップを達成するはずです。 ? ry のは、理論的 ry ために、最も ry コストを無視 ry 。 実際のスピードアップが理論的限界よりはるかに小さいのは、最も内側のループでかなり大きなアドレスオフセットで現在間接的にアクセスされている入力ベクトルのアクセスコストを我々が、理論的限界を見積もる為に無視するためです。 http://webcache.googleusercontent.com/search?q=cache:arxiv.org/pdf/1612.00530#7 ベクトルと行列を並べ替えると、パフォーマンスをさらに向上させることができます。 ? ry 、データと索引の圧縮の概念コード ry 。 リスト1は、データのと索引のとの圧縮のコンセプトコードを示しています。 ファクトインデックスとデータは圧縮されているため、それらの実際の値はテーブルルックアップ操作によって取得されます。 したがって、広いＳＩＭＤ命令セットを有する現代のマイクロプロセッサでは、間接アクセス動作のスループットが一般に低いので、圧縮アルゴリズムを用いて妥当な性能を達成することは困難であろう。 ? ry に重要です。 PEZY-SCプロセッサの完全MIMD、非SIMDの性質は、実際のスピードアップを達成するためにクリティカルです。  for(int i=0;i < n; i++){ ? 私 ? 私 y[i] = 0; const int type = columnDiffType[i]; int idx = 0; for(int valueIdx = 0; valueIdx < valueCount; ? 用 valueIdx++){ const double a ij = value[valueIdx]; ? ダブル for(;idx < valueIdxEnd[i][valueIdx]; idx++){ const int j = i + columnDiff[type][idx]; const double x j = x[j]; ? ダブル y[i] += a ij  x j; } } } リスト1：データとインデックスの両方の配列を圧縮したサンプルコード ただし、ここでの問題はサイクルあたりの独立したメモリアクセスの数であり、SIMDアーキテクチャとMIMDアーキテクチャの違いではありません。 ? ry プロセッサの収集／分散機能 ry 。 現代のＳＩＭＤマイクロプロセッサのスキャッタ/ギャザ機能は明らかにまだ初期段階にあり、そして将来改良されるかもしれない。 VI 概要 本稿では、1024コア、MIMDのウルトラメニーコアPEZY-SCプロセッサをアクセラレータとして用いたZettaScalerシステムにおけるSpMV乗算に対するデータ圧縮/伸長アルゴリズムの効果について報告する。 例として、HPCGベンチマークコードによって生成された行列を使用しました。 ? 通常、最適化 ry 。 通常、良く最適化されたHPCGの実装のパフォーマンスは、プロセッサ（またはアクセラレータ）の外部メモリのシーケンシャルリードアクセスの帯域幅によって制限されます。 PEZY-SCプロセッサの場合、読み取り帯域幅の理論上の限界は85 GB /秒であり、実際の測定帯域幅は75 GB /秒です。 したがって、SpMVおよびSymGSの動作のパフォーマンスは約10 Gflopsに制限されています。 達成された実際の性能はこの数に近い。 データとインデックスの圧縮による理論上の高速化は25倍もの大きさです。 SpMV操作では、実際には2.8倍の高速化が達成されました。 ? ry 小さいにもかかわらず、データ ry と、実際にはPEZY-SC ry パフォーマンスが改善されることを実証 ry 。 実際に達成された改善は理論上の最大値よりもはるかに小さいものの、データ圧縮/解凍を使用すると、 PEZY-SCプロセッサでのSpMV乗算のパフォーマンスの改善が実際に可能である事を我々は実証しました。 したがって、データ圧縮/解凍の使用は、現在および将来の高性能プロセッサ上のFEMアプリケーションにおけるSpMV操作のパフォーマンスを向上させるために非常に有用な技術となると結論します。 ? 了承 謝辞 著者は、HPCGを移植して調整している間に我々が遭遇した多くの問題を解決する際に非常に助けになってくれたPEZY Computing / ExaScalerの人々に感謝します。 本稿の対象となる研究の一部は、文部科学省の次世代超高速コンピュータシステムの開発と改善のためのプログラムで、特定の先端大規模研究施設の運営に対する助成金の下で資金提供されています。 参考文献 * [1] HPCG。チーム。（2015年11月）2015年11月HPCGの結果です。 [オンライン]。 入手可能： http://www.hpcg-benchmark.org/custom/index.html?lid=155&slid=282 * [2] X.チャン、C。ヤン、F。リウ、Y。リウ、Y。ル、 並列処理のためのアルゴリズムとアーキテクチャ： 第14回国際会議、ICA3PP 2014、大連、中国、2014年8月2427日。 、パートI。Cham：Springer International Publishing、2014、ch。 Tianhe-2でのHPCGの最適化とスケーリング：初期の経験、2841ページ。 [オンライン]。入手可能： http://dx.doi.org/10.1007/978-3-319-11197-1 3 * [3] J. Park、M。Smelyanski、K. Vaidyanathan、A。Heinecke、D。D。Kalamkar、X。Liu、MMA Patwary、Y。Lu、およびP. Dubey、 ? 「 ry 勾配の効率的 ry 実装ベンチマークと非 ry 応用、」 「高性能共役勾配ベンチマークの効率的な共有メモリ実装とその非構造化行列への応用」、 ハイパフォーマンスコンピューティング、ネットワーキング、ストレージおよび分析のための国際会議の議事録、SER。SC '14。米国ニュージャージー州ピスカタウェイ： ＩＥＥＥプレス、２０１４年、９４５９５５頁。 [オンライン]。入手可能： http://dx.doi.org/10.1109/SC.2014.82 * [4] JJ Dongarra、A。Heroux、Michael、およびP. Luszczek、 「HPCGベンチマーク：高性能コンピューティングシステムをランク付けするための新しい測定基準」、 ? ry システム工学部、コンピュータ工学科。Rep ry テネシー大学、電子工学とコンピュータサイエンス科。Rep。15-736、2015。 [オンライン]。入手可能： http://www.eecs.utk.edu/resources/library/594 * [5] A. Heroux、Michael、JJ Dongarra、およびP. Luszczek、 「HPCG技術仕様」、 Sandia National Laboratories、Tech。Rep。SAND2013-8752、2013。 [オンライン]。入手可能： http://software.sandia.gov/hpcg/doc/HPCG-Specification.pdf * [6] PEZY Computing、KK、「PEZY-SCデータシートRev 0.1」（2014年） * [7] 石井T. （2015年8月） ? ペジーSCの紹介 PEZY-SCの御紹介 [オンライン]。入手可能： http://accc.riken.jp/wp-content/uploads/2015/09/ishii.pdf * [8] T. Iwashita, H. Nakashima and Y. Takahashi, ? ry おける並列マルチスレッドスパース三角ソルバーのための代数ブロックマルチ ry 、 "ICCG法におけるスパース Triangular Solver のための並列マルチスレッドな代数ブロック化マルチカラー順序付け法"、 並列分散処理シンポジウム（IPDPS）、 2012 IEEE 26th International、上海、２０１２年、４７４４８３頁。 ? 土井： ry doi ：10.1109 / IPDPS.2012.51 * ［９］ Ｗ．Ｈａｃｋｂｕｓｃｈ、Ｂ．Ｎ．Ｋｈｏｒｏｍｓｋｉｊ、およびＲ．Ｋｒｉｅｍａｎｎ、 ? 「ｈ行列 ry 直接シュール補完法」、 「 H 行列近似に基づくドメイン分解による直接 Schur 補元法」、 「コンピューティングおよび可視化における科学」、ｖｏｌ。8、いいえ。３、ｐｐ．１７９１８８，２００５。 ［オンライン］。入手可能： http://dx.doi.org/10.1007/s00791-005-0008-3 * [10] SW Son、Z. Chen、W. Hendrix、A。Agrawal、W. keng Liao、およびA. Choudhary、 「エクサスケールコンピューティング時代のためのデータ圧縮 - 調査」、 ? ry vol。1。1、いいえ。2014年2月2日。 Supercomputing frontiers and innovations、vol。1、 no.2、 2014。 [オンライン]。入手可能： http://superfri.org/superfri/article/view/13 * [11] H。金子、 「ラストレベルキャッシュデータ圧縮のための周期的パターンコーディング」、 IEICE Trans。基礎編、vol。96、いいえ。12、pp。2351-2359、2013。 [オンライン]。入手可能： http://ci.nii.ac.jp/naid/130003385283/en/ * [12] AR AlameldeenとDAウッド、 「高性能プロセッサのための適応型キャッシュ圧縮」、 ? ry シンポジウム論文集、 ry 第31回コンピュータアーキテクチャ国際シンポジウムの議事録、ser。ISCA '04。ワシントンDC、米国： IEEE Computer Society、2004年、212頁。 [オンライン]。入手可能： http://dl.acm.org/citation.cfm?id=998680.1006719 * ［１３］ Ｍ．ＥｋｍａｎおよびＰ．Ｓｔｅｎｓｔｒｏｍ、 「ロバストなメインメモリ圧縮方式」、 第３２回コンピュータアーキテクチャに関する年次国際シンポジウムの議事録、ｓｅｒ。ISCA '05。ワシントンDC、米国： IEEE Computer Society、2005年、7485ページ。 [オンライン]。入手可能： http://dx.doi.org/10.1109/ISCA.2005.6 LaTeXMLによって生成された[ロゴ] 私たちが作っている新しいツールについて知りたいですか？随時更新するために私たちのメーリングリストにサインアップしてください。 申し込む Andreas JanssonとBen Firshmanによって、LaTeXMLの助けを借りて構築されました。 GitHubに貢献してください。 ? 親切にYLDが後援しました。 YLDが親切にスポンサードしました。 > -- > フリーソフトウエア関連ボランティアの皆様に感謝申上げますと共に > 当原稿執筆編集の甚大コストへの御配慮に厚く御礼申上げます > 三菱 UFJ 銀行 平針支店 ( 普 ) 0111481 ヤマグチセイセイ > 郵便局 218普2449768 ヤマグチセイセイ > Yahoo pt 1362821068616323 Rakuten pt 1100-3310-4065-1717 > http://yahoo.jp/HsDIGs?#_2TB_0S03224 -- YAMAGUTIseisei ( str_h__namae = { :sei => "山口" , :mei => "青星" } ) http://hello.to/seisei/ mailto:seisei@.68..net tel:081-70-5152-1104 heiwa furiisekkusu 1tu 訂正 : HarmonyOS ロンチイベント ファーウェイデベロッパカンファレンス 2019 >全シナリオ対応な分散 OS の、もう1つの利点は共有エコシステムを持つことです。