憂鬱な午後のひととき
2020年振り返り
2/25から在宅勤務で結局そこから一度も出社していない.
東京1300人越えか. 和歌山の知事がトップに近いところにいたらここまでにはならなかったかな.
ずっと自宅作業なのでスタンディングディスクや足マットを買って作業環境を整えた.
年末病院で視力検査やもろもろやって正しい度数のレンズを注文.
今までのはかなりきつかったらしい. 頭痛の原因はこれだったのかな.
やってくるのは年明け.
今年前半はEthereumのG2へのハッシュ関数の実装とxbyak_aarch64まわりの作業をしていた.
ハッシュ関数はdraftのバージョンが上がるごとに細かく仕様が変わって無駄に時間を食ったところがあった.
xbyak_*_aarch64はとにかく富岳でのコンパイル時間が長くて辛かった.
いろいろcppに押し出してなんとか耐えられる速度にした.
M1 macはコンパイル時間が短くてよいね. これでSVEに対応していれば.
eltwiseのexpやtanhなどをSVEで実装.
Intelからxbyakへの定期的な要望やissue対応など.
例外を使わないnothrowモードの追加依頼はなかなか面倒だった.
暗号ライブラリもそうだけど対応OSやアーキテクチャが増えると保守的な機能に制限されることが多い.
でも流石に来年はC++11前提にしようかなあ.
mcl/blsは使ってくれる人が増えたので対応環境も増えた.
すぐに陳腐化するのでやりたくないけど必要に迫られてWebpackやReactなども勉強して対応.
独学はやたらと時間を食うので得意な人が手伝ってくれるとありがたいのだが.
ZKPまわりのAPIも要望に応じて増やした.
ARM系がここまで増えるとはなあ. Intelも巻き返してほしいところ.
FreeBSDやOpenBSDもインストールしてみて使い方が全然違うのに驚いた.
ARM入門勉強会, HPC-Phys, 東京理科大談話会などで発表.
CEDEC2020のC++発表の手伝いも.
英語はヒアリングの練習のためずっとやってるけど全然効果ない.
思えば中一のときからNHK基礎英語聞いていたけどさっぱりだった.
根本的に向いてないな.
編集距離の秘匿化アルゴリズムの論文は残念ながら今年は通らなかった.
reject理由に「速すぎる」とあったのはなんだそれはと思った(完全に先方の読み間違い).
せっかくがんばってXeon Platinum 8280で最適化したんだが.
リモートデスクトップ
少し前のWindows Update以降, リモートデスクトップ接続にやたらと失敗する(error code : 0x112f)ようになってうっとうしかったのだが,
これで大丈夫かも. しばらく様子見る.
Windows10 updates RD Dual Monitor and Last Opened Windows issues
gpedit.msc → コンピュータの構成 → 管理用テンプレート → Windowsコンポーネント → リモートデスクトップサービス → リモートデスクトップセッション → リモートセッション環境 → すべてのリモートデスクトップサービスセッションにハードウェアアダプターを使用します を無効に.
うーん, よくなったと思ったが駄目か.
談話会
東京理科大学理工学部数学科の談話会で「楕円曲線と暗号」というタイトルで話しました.
数学で楕円曲線勉強してる人向けに, 暗号でこんなことしているよというのを紹介してほしいということだったのでいろんなトピックを入れようとしたら詰め込みすぎました.
すんません.
楕円曲線と暗号
SHE
レベル2準同型暗号の暗号文で暗号文が確かにmであることを示すZKPを生成するAPIの追加.
mcl on OpenBSD
OpenBSDで落ちるというので調査のために初めてインストール. pkg_addでパッケージインストール.
自分の環境では動いた.
FX-8320Eだと落ちるというのはなんだろうな.
dump_codeはコード生成したものを出力するだけでおかしなコード実行することはないはずなのだが.
社内の成果発表会
一年を振り返る. まあ, いろいろあった.
xbyak_translator_aarch64 on M1 mac 2
最初テストが落ちる理由に悩んだがM1がSVEに対応していなからだった.
gccのaarch64用組み込み関数__builtin_aarch64_get_fpcrがclangに無い.
どうしようかな.
xbyak_translator_aarch64 on M1 mac
ひとまず動くようになった.
intelxed/mbuildのenvがM1 macに対応していなかったのでarm64を追加するpull request.
夜中, ふたご座流星群を見に外に出てみた. 小一時間ねばって一つだけ見えた.
町中で明かりの無いところは難しい.
llvb on mac
sudo DevToolsSecurity -enableでdeveloper modeを有効にする必要あり.
gasはosx-arm-linux-toolchainsを利用することにした.
SCIS2021の準備
やりたいことの数式を書き下せて, 概ね正しそうと判断したので原稿書き.
ぎりぎりできてよかった.
ベンチマーク追加2
質問があったのでもう一つ追加.
i7-8700 CPU @ 3.20GHzでのみ. Xbyak版とLLVM BMI2ありとLLVM BMI2なしバージョン.
xbyak : bmi2あり : bmi2なし = 572 : 666 : 735 usec.
bmi2あり(mulxなど)ならM1 macと互角, bmi2なしだとM1 macが速い結果に.
ベンチマーク追加
もう少し詳しく見る. 一番基本的なモンゴメリ乗算とそれを使ったFp2::mulがペアリングの速度比に大体あってるので不自然な感じはしない.
細かくみるとM1 macはFE(finalExp)がML(Miller loop)に比べて時間がかかってる模様.
これは調べて原因を調べるとよさそう.
M1 macでのmclペアリングベンチマーク
いくつかの環境で比較してみた. xbyakが動かないのでLLVM-IRによるコード生成バージョンで比較(各種CPUに応じてclangが-O3の範囲で最適なコードを生成).
コンパイルオプションは全ての環境で同一. 外部ライブラリには依存していない.
clang++ src/fp.cpp src/bn_c384_256.cpp test/bls12_test.cpp \
-O3 -DNDEBUG -I ./include/ -DMCL_USE_VINT -DMCL_DONT_USE_OPENSSL \
-DMCL_VINT_FIXED_BUFFER -DMCL_MAX_BIT_SIZE=384 -DMCL_USE_LLVM \
src/base64.ll -DCYBOZU_BENCH_USE_GETTIMEOFDAY
試した環境は次の通り
x64-linux ; i7-8700 CPU @ 3.20GHz ; Ubuntu 20.04.1 LTS ; clang 10.0.0-4ubuntu1
x64-2-linux ; Xeon Gold 6238 @ 2.10GHz ; Ubuntu 18.04.5 LTS ; clang version 10.0.1
x64-mac ; i5-8259U 2.3GHz ; macOS Catalina 10.15.7 ; Apple clang version 12.0.0 (clang-1200.0.32.27)
m1-mac ; Apple M1 ; macOS Big Sur 11.0.1 ; Apple clang version 12.0.0 (clang-1200.0.32.28)
bench
| x64-linux | x64-2-linux | x64-mac | x64-binary on m1-mac | arm-binary on m1-mac |
周波数(GHz) | 3.2 | 2.1 | 2.3 | 3.2? | 3.2? |
1CPUでのコンパイル時間(sec) | 17.3 | 21.9 | 28.7 | - | 10.4 |
Fp2::mul(nsec) | 92.1 | 120.5 | 127.1 | 231.5 | 110.9 |
ML(usec) | 247.6 | 306.3 | 308.5 | 562.9 | 265.9 |
FE(usec) | 330.7 | 418.2 | 423.7 | 710.3 | 409.0 |
pairing=ML+FE(usec) | 584.7 | 721.7 | 733.5 | 1274 | 676.23 |
このプログラムはほぼCPUの整数演算処理のみでメモリアクセスは少量.
仮にM1が3.2GHzなら同一クロックのi7-8700よりは遅い. Big Surでのx64エミュレーションは2.3GHzのi5 Macの1.7倍ぐらいの遅さで実行できるという結果.
これだけ見るなら魔法のCPUという感じではないなあ(コンパイル速度とかいろいろ速いけどね).
まあ他のAArch64 CPUに比べると相当速いようだが.
『責任という虚構』(小坂井 敏晶) ちくま学芸文庫
ぼちぼちと読んでる. 分厚い.
半分ぐらい(250ページ)読んだところで, これは「自由意志が虚構」という話なのでは.
後半個別論が展開されるのかな.
xbyak_aarch64のM1 macOS
M1 MacBook Proが届いたのでxbyak_aarch64を調べる.
xbyak自体は動かなかった(多分何かの判定マクロ名が変わってる. 後で調べる).
M1 macOSではmprotectでread/write/exec属性が立てられない.
AArch64ではCPUコード生成のあとコードキャッシュのフラッシュをしないといけないのでready()は必須.
だからCodeGeneratorのコンストラクタでは属性変更せず, mmapするだけ(要MAP_JITフラグ)にして,
ready()でread/exec属性をつけるようにしたら動くようになった.
テストとかはまだ動かない.
マクロとかいろいろ違う模様.
第9回HPC-Phys発表
発表資料expの実装に見るAVX-512とSVEの違い.
発表日の午前中からめちゃくちゃ緊張して辛かった.
質疑応答ができたので, それなりに興味を持っていただけたのかな.
xbyak_translator_aarch64
いろいろ直したいところがあるけど少しずつ.
とりあえずincludeパスの指定を簡単にできるようにした.
AArch64用BrainFuck JITインタプリタの解説
Xbyak_aarch64の使い方の参考になればと書いてみた.
ラベルの扱いの部分はかなりスマートに出来てると思うんだよな.
昔
御意見は光成滋生<herumi@nifty.com>までお願いします