Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
VSP専用プロセッサ設計 と実行エンジンについて 松本 直樹(@PiBVT) 2020/02/08 カーネル/VM探検隊@関西 10回目
Slide 2
Slide 2 text
Agenda ● 自己紹介 ● VSP専用プロセッサ設計について ● 並列実行エンジン Iyokan について
Slide 3
Slide 3 text
自己紹介 松本 直樹 (@PiBVT) 京都大学工学部情報学科3回生 未踏プロジェクトでの担当 ● VSP専用プロセッサ設計 ● 実行エンジンの基本設計,試作実装
Slide 4
Slide 4 text
VSP専用プロセッサ設計について VSPはプロセッサ設計が必要 暗号処理はゲートレベルで行われる -> プロセッサ設計は平文と同様のものが利用できる FHEゲートの演算のコスト -> 出来る限りゲート数が少ない設計が必要
Slide 5
Slide 5 text
VSP専用プロセッサ設計について 出来る限り少ないゲート数,省ROM,RAM -> 専用のISAとそのプロセッサ設計を開発することに ※ROM,RAMはそれぞれ512byteでも20,000ゲート以上あるた め、全体のゲート規模にかなり影響がある
Slide 6
Slide 6 text
時系列でみるVSP専用プロセッサ設計 2019年6月 プロジェクト開始 7月 rv32k-garnet 開発中止 8月 rv16k-amethyst(RV16Kv2準拠 マルチサイクル)完成 9月 rv16k-aquamarine(RV16Kv2準拠 5段パイプライン)完成 10月 cahp-diamond(CAHPv3準拠 5段パイプライン)完成 2020年1月 cahp-emerald(CAHPv3準拠 スーパースカラ)完成
Slide 7
Slide 7 text
cahp-emeraldについて ● VSP専用プロセッサ第5世代設計 ● CAHPv3(16bit/24bit混合命令長) 準拠 ● 5段パイプライン ● 最大2命令同時発行インオーダースーパースカラ ● 約8,000ゲート(cahp-diamond が約4,000 ゲート) ● IPC 1.1(cahp-diamondが0.78) ● このままだと不採用の危機(ゲート規模的に)
Slide 8
Slide 8 text
cahp-emeraldのアーキテクチャ 5段パイプライン・インオーダースーパースカラ
Slide 9
Slide 9 text
混合命令長のつらさ ● 16bit/24bitで偶数倍長の関係にないため、アライメントをまたぐ命 令アクセスが起こる ● ジャンプでの命令フェッチで余計なストールが発生する ● ゲート規模が膨らむ
Slide 10
Slide 10 text
● 32bitブロックでのROMアクセスを行ったとしてもブロック間をまたぐ 命令が存在する -> ブロック間をまたぐ命令アクセスを実現する機構が必要 混合命令長のつらさ その1
Slide 11
Slide 11 text
一度読み込んだブロックをキャッシュに保持し、ブロックをまたい だアクセスを実現 -> ジャンプが起きると....?
Slide 12
Slide 12 text
並列実行エンジン Iyokan について ● 回路情報を元にFHEゲートを評価する並列実行エンジン ● TFHEpp(CPU)/cuFHE(GPU)を暗号処理のバックエンドとして利 用可能 ● verilogファイルからの回路合成は外部ツール(yosys)を利用
Slide 13
Slide 13 text
ゲートの評価順には依存関係がある ● ネットリスト上のゲートは上流から下流へと順に評価する
Slide 14
Slide 14 text
ネットリストをDAG(有向非循環グラフ)で表現 1. 上流ノードを持たないノードを評価待ちとする 2. 評価待ちのノードを評価 3. 辺経由で下流のノードに評価済みであることを通知 4. 入力の上位ノードすべてが評価済みならノードを評価待ちとする 5. 評価待ちノードが存在する場合、2へ戻る
Slide 15
Slide 15 text
CPU/GPU対応 ● CPU対応はライブラリのTFHEppで簡単に実現 -> しかし、AVX2等を使っても遅い -> V100などを用いたGPGPUで高速化した例がある ● GPU対応で、ホスト,デバイス間のメモリ一貫性は? -> 毎回転送? -> すべてGPUオンメモリ?
Slide 16
Slide 16 text
CPU/GPU対応 ● ゲートの出力値を保持する変数は高々数100KB ● 一度転送すれば暗号処理自体は10ms程度処理にかかる ● H2D,D2Hのメモリ転送の影響は限りなく小さい ● かなりのCPUバウンドな処理のため、MPIでもスケールする...? ● CPUとGPUの両者を用いたスケジューラを開発中 毎回転送することにした