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の両者を用いたスケジューラを開発中 毎回転送することにした