Successfully reported this slideshow.
Your SlideShare is downloading. ×

WebAssembly向け多倍長演算の実装

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad

Check these out next

1 of 21 Ad

More Related Content

Slideshows for you (20)

Similar to WebAssembly向け多倍長演算の実装 (20)

Advertisement

More from MITSUNARI Shigeo (20)

Recently uploaded (20)

Advertisement

WebAssembly向け多倍長演算の実装

  1. 1. WebAssembly向け 多倍長演算の実装 2021/3/20 Kernel/VM探検隊online part2 光成滋生
  2. 2. • 背景 • ペアリング暗号 • 実装 • x64による多倍長演算の歴史 • wasmでの戦略 概要 2 / 21
  3. 3. • @herumi, https://github.com/herumi/ • Intelや富岳でのJITやAI関係の最適化 • https://gihyo.jp/news/interview/2020/11/1801 • 暗号とセキュリティに関するR&D ← 今日はこちら 自己紹介 3 / 21
  4. 4. • 暗号文の内積や署名の集約などが可能な高機能暗号 • 実装 https://github.com/herumi/mcl 世界最速 (今日の時点) • Win/Linux/Mac/M1/Android/iPhone, Go/C#/Java/Rust binding • 暗号文のまま積和演算 (L2準同型暗号) • https://herumi.github.io/she-wasm 「ペアリング」を使った暗号技術 (1/2) マンガ購入 購入せず カメラ購入 * * 購入せず * * 暗号文を送信 テレビ マンガ 小説 カメラ A * * * * B * * * * C * * * * ... * * * * 暗号文のままクロス集計 マンガ購入 購入せず カメラ購入 80 20 購入せず 10 30 復号 クラウドサーバ 4 / 21
  5. 5. • 署名の秘密分散や集約 (BLS署名) • https://github.com/herumi/bls • EthereumJSのVMの暗号処理部分を担当 • https://github.com/ethereumjs/ethereumjs-monorepo • その他、多数のブロックチェーンプロジェクトで採用 「ペアリング」を使った暗号技術 (2/2) 5 / 21
  6. 6. • 難しいのでスキップ • 詳しい話は http://eprint.iacr.org/2014/401 • 秀和システム『クラウドを支えるこれからの暗号技術』 • http://herumi.github.io/ango ; PDF無料公開 ペアリングって何? 6 / 21
  7. 7. • ペアリングには楕円曲線が必要だ • 楕円曲線には拡大体や有限体が必要だ • 有限体には固定多倍長演算が必要だ • 𝑥, 𝑦, 𝑝を384bit (or 256bit)整数として • 𝑥 ± 𝑦 % 𝑝, 𝑥 ∗ 𝑦 % 𝑝 の計算を多数行う • 足し算や掛け算ってどうやってするの? ← 今日の本題 • しばらくx86-64で解説 • 後半wasmでの方針を解説 • その前に記号 • 𝑥 = [𝑥3: 𝑥2: 𝑥1: 𝑥0]と書くと𝑥0, … , 𝑥3は符号無し64bit整数で 𝑥 = 𝑥3 ∗ 2192 + 𝑥2 ∗ 2128 + 𝑥1 ∗ 264 + 𝑥0を表すことにする ブレイクダウン 7 / 21
  8. 8. • 64bitのレジスタ𝑎, 𝑏の和は65bit • Intel CPUでadd 𝑎, 𝑏は𝑎 += 𝑏;の意味 • 残り1bitはCarryフラグ (CF)で表す ; [CF:a] = a+b • [𝑦1: 𝑦0] + [𝑥1: 𝑥0]は • add 𝑦0, 𝑥0 ; 𝑦0 += 𝑥0, CF= 0 or 1 • adc 𝑦1, 𝑥1 ; 𝑦1 += 𝑥1 +CF ; carryつきのadd • AArch64ではaddsとadcs 2桁の足し算36 + 47 = ? 3 6 + 4 7 ----- 1 3 3 4 ----- 8 3 繰り上がり 8 / 21
  9. 9. • 𝑦3: 𝑦2: 𝑦1: 𝑦0 += [𝑥3: 𝑥2: 𝑥1: 𝑥0] • では73 * 7 = ? • x64のmul命令は64x64→128 mul x ; [rdx:rax] ← x * rax AArch64は上位・下位64bit取得のmul mulとumulh mulしてからcarryつきadd 4桁の足し算 add 𝑦0, 𝑥0 adc 𝑦1, 𝑥1 adc 𝑦2, 𝑥2 adc 𝑦3, 𝑥3 7 3 𝑦1 𝑦0 * 7 𝑥0 ----- ------- 2 1 |𝑦0 𝑥0| 4 9 |𝑦1 𝑥0| ----- --------- 5 1 1 繰り上がり 9 / 21
  10. 10. • mulで128bitのデータを順次足したい • mul命令はCFを破壊する • 8086時代からの流れ • 128bit x 4個のmulをしてからでないとadd/adcできない • レジスタを圧迫する 𝑦3: 𝑦2: 𝑦1: 𝑦0 ∗ 𝑥の問題点 𝑦0𝑥 𝑦1𝑥 𝑦2𝑥 𝑦3𝑥 10 / 21
  11. 11. • CFを破壊しない • mov rdx, x / mulx H, L, y ; [H:L] = x * y mulx登場 (from Haswell) mov rdx, x ; rdx ← x mulx z1, z0, y0 mulx z2, t, y1 add z1, t mulx z3, t, y2 adc z2, t mulx z4, t, y3 adc z3, t adc z4, 0 [y3:y2:y1:y0] * x ---------------------- [z1:z0] [z2: t] [z3: t] [z4: t] ----------------------- [z4:z3:z2:z1:z0] 11 / 21
  12. 12. • 途中に「𝑦𝑥𝑖−1 += 𝑦𝑥𝑖」 • 問題発生! • 𝑦𝑥𝑖を計算するときにCFを使う • 𝑦𝑥1の計算が終わらないと𝑦𝑥0に𝑦𝑥1を足せない • レジスタ圧迫 [𝑦3: 𝑦2: 𝑦1: 𝑦0]*[𝑥3: 𝑥2: 𝑥1: 𝑥0] [y3:y2:y1:y0] x [x3:x2:x1:x0] --------------------------------- [ y x0 ] [ y x 1 ] [ y x2 ] [ y x3 ] ----------------------------------- [z7:z6:z5:z4:z3:z2:z1:z0] 12 / 21
  13. 13. • 問題点はCFが1個しかないこと • 2個あれば𝑦𝑥1を計算しながら𝑦𝑥0に足せる • adcx ; CFつきの加算 • adox ; OFつきの加算 • CFとOFを独立した1bitレジスタとして扱う • [z] += [y] * x • [y] * xの計算にCFを使う • [z] += の計算にOFを使う • 中間レジスタ数低減 • BroadwellやRyzenで対応 adcx, adox登場 [ z ] [y0 x1] [y1 x1] [y2 x1] [y3 x1] ----------------------------------- [z5:z4:z3:z2:z1:z0] adcx adox 13 / 21
  14. 14. • レジスタは32bit/64bit • 加算は64bit + 64bit = 64bit ; carryが無い! • 乗算は32bit * 32bit = 64bit ; 128bit出力が無い! • 素直なCでできる範囲しかない • https://webassembly.github.io/spec/core/binary/instructions.html • carry演算をエミュレートしないといけない • どうやって? • 64bitのxとyを足してcarry発生 • ⇔ c = uint64_t(x+ y) < x • lt_u x, y ; x < yなら1, そうでなければ0 • 他の比較に対する条件つきセット命令やselect命令も さてwasmでは 14 / 21
  15. 15. • T = uint64_tとして • 1個の要素あたり • addが3回, lt_uが2回 (ループ変数の処理は除く) • lt_uは内部的にはcmp + cmov (多分) 多倍長の足し算 T z = x + c; c = z < c; z += y; c += z < y; x T y T c bool x + y c 15 / 21
  16. 16. • T = uint32_t単位で処理する • 32bitのx, yに対して64bitにzext (ゼロ拡張)する • c = (x + y) >> 32; • 1個の要素あたりaddが2回, シフトが1回, zextが2回 • 演算回数は増えるが条件代入は無くなる • マイクロベンチマークでは気持ち64bit版が速い? (微妙) • JITの影響も大きい • 利点 : 32bit単位だとcが1bitより大きくてもよい • まとめて足してからcarry操作をすることでステップ数削減 別の方法 v = uint64_t(x) + y + c; z = T(v); c = T(v >> 32); x T y T c bool x + y c 16 / 21
  17. 17. • 256x256→512の乗算 • 64bit単位で処理したもの(64x64→128は32x32→64で実装) • 32bit配列で処理したもの • (先月試して)32bit単位で処理した方が速くなった • 乗算がプロファイルの全体を占めるので効果が高い • Q. Karatsuba法を使ったら? • (aW + b)(cW + d) = acW^2 + ((a+b)(c+d) - ac - bd)W + bd • 加算が重たいので256bitや384bitでは使わない方が速かった ベンチマーク mul256 mul384 64bit 196 339 32bit 168 275 単位nsec Core i7 3.4GHz 17 / 21
  18. 18. • uint128_tやuint1024_tなどを作れる言語拡張 • typedef unsigned _ExtInt(256) uint256_t; などとして • これだけでmul256やmul384が実装できる!!! • 職人プログラマ不要になる? • C++にも入れようという提案も • https://github.com/herumi/misc/blob/master/cpp/p1889.md clang-11の_ExtInt void mul256(T *pz, const T *px, const T *py) { uint256_t x = *px; uint256_t y = *py; uint512_t z = uint512_t(x) * y; // 符号拡張して乗算 *(uint512_t*)pz = z; } 18 / 21
  19. 19. • x64でのベンチマーク • mclのは職人技(?)による多分最速コード(w/ adox, adcx) • clangはmulxまでしか使わない・レジスタスピルする • wasmでは(--target=wam32) • __multi3 is not found ; リンクできない • clang-8の頃は自分で__multi3を実装して動いてたんだけどな • 仕様が変わった? 未調査(昔はLLVMが落ちていた) 残念なところ clang-11 -Ofast mcl mul256 88.2 53.2 sqr256 82.1 41.4 wasm-ld-11: warning: function signature mismatch: __multi3 >>> defined as (i32, i64, i64, i64, i64) -> void in add.o >>> defined as (i32, i64, i64) -> void in multi3.o 単位clk Core i7 3.4GHz 19 / 21
  20. 20. • C/C++からwasmを生成するコンパイラ emcc (Emscripten)とclang emcc clang 標準ライブラリ 対応 mallocも使える ヘッダが無い (WASIを使う?) 関数export __attribute__((used )) __attribute__( (visibility("default") )) exportの名前 先頭に'_'がつく '_'がつかない 便利機能 -s SINGLE_FILE=1 wasmをbase64で 埋め込んだjsを生成 LLVM IRを 直接扱える 安定度 (個人の感想) 割と枯れてきた 結構仕様が変わる 20 / 21
  21. 21. • 多倍長演算ではcarryの扱いが重要 • x64には便利な命令がいろいろ追加されている • wasmはcarryを扱う命令が無い • 素直にCで記述する範囲でしかできない or で十分 • clangの_ExtIntに期待 • 個人的にはemccがllvm/_ExtIntサポートするまで待ち? まとめ 21 / 21

×