Ethereum 2.0 Development Update #17 - Prysmatic Labs
mentionで飛んできたので見たら私のBLS12-381によるBLS署名の実装が使われてるらしい. ありがたいが, バグってても何か起こると怖いなあ.
Ethereum 2.0 Development Update #17 - Prysmatic Labs
mentionで飛んできたので見たら私のBLS12-381によるBLS署名の実装が使われてるらしい. ありがたいが, バグってても何か起こると怖いなあ.
セキュリティインシデントflatmap-stream@0.1.1とnpm-run-allでの対応
最近Xbyakとかmcl(bls)とか使ってくれてるプロジェクトがちらほらあるけど, 実行時に悪意あるコードを生成するとか, Xbyak側にそういうコードを入れるとかしてもすごく分かりにくいよなあ, どうやって安全性を担保するのだろう. という感じの話をこないだのコンパイラ勉強会のときに雑談してた.
実際, 何十億というお金がかかってるプロジェクトだと個人アカウント狙われたら防げるのかな.
nakameguro_feature.cpp vol.12参加
発表者の都合で@kariya_mitsuruさんが代わりに発表してくださる. std::optionalの話. 初期化方法がいろいろあるとライブラリ作る人は大変だなあ.
ルータ
11ac対応1733+800Mbps無線LANルータWSR-2533DHP2-CBを購入. 約9800円. 前回購入してから約6年. さぞかし無線LANが速くなっただろうと測定したら80Mbps程度で変化無し.
あれ, おかしいなとルータがつながってる先をよくよく見たらもう一つルータが挟まってた. どうやら入居時から設置されていたらしい. なんと長年ルータ2段重ねで使っていたことが判明.
古い方を取り除いたら600Mbps前後出るようになった.
ワイヤレスイヤホン
テレビを見るのに便利そうなので買ってみた. テレビは普通のイヤホンジャックなのでBluetoothのトランスミッター(VIFLYKOO)とBluetoothのワイヤレスイヤホン(EnacFire TWS E19)にした. 遅延が心配だったので安いなかでも速そうなBluetooth 5.0に対応してるやつにした.
実際に試してみるとヘッドフォンより音が軽い. まあそれはよいとしても遅延が気になる. 人がしゃべってる唇と声がずれてて気持ち悪い. 0.1秒はずれてる感じ. 残念ながらこれは使えないなあ. 音だけ聞くのならよいのだけど.
aptX HDより通常のaptXの方が遅延が少ないらしいのでそのモードにできるか後で調べる.
コンパイラ勉強会途中から参加
みんなコンパイラを書こうという話. まじめに書いたことないのでまだ人生fakeだな. fakeのままでもいいけど.
範囲を計算するためのSMTソルバの話は(shinhさんが先に質問してたけど), あれぐらいなら全数計算の方が簡単で速いんじゃないかと思った.
懇親会が早めだったので参加して何人かと食事もできた.
mclの実装詳解書きかけ
社内勉強会で話したメモ.
256bitや384bitは複数のアルゴリズムの速度が拮抗してるのでいろいろ実装して試さないとどれが一番よいのか分からない. 384bit整数同士の乗算はKaratsubaの方が速い予想だったのだが違った.
montSqrで一度乗算した値はstackにメモ化するアイデアもあるけど実装が面倒そうで試してない. 速くなるかなあ.
『「余剰次元」と逆二乗則の破れ』(村田次郎)
面白かった. 近距離(1mm程度)での万有引力の法則がr-2であることがあまり検証されていなかったので, そこで法則が変わってるなら重力が他の3個の力に比べて弱い理由が説明できるかもしれないというADDのモデル(1998).
それを検証するためにコンパクトな実験装置を考えて検証する.
天体レベルで検証されてる法則が近くでは成り立たなくてもよいから理論を作ってみるという発想はすごいな.
本が出てから7年が経過し, 精度があがって今のところ0.1mmまでは法則に変わりはないそうだ(cf. 重力逆二乗則の実験検証 日本物理学会誌 Vol. 73, No. 11, 2018).
Re: clang vs. gcc
どうやらライブラリの差ではないようだ. 同じライブラリでも実行バイナリで差が出る. なんだろう. t.cppは単純なループ. 逆アセンブルするとgccの方がよりinline展開をしてるな. でもそれが(遅くなる方に)こんなに影響するとは思えないし.
for (int i = 0; i < 10000; i++) { pairing(e, P, Q); }
% g++ -o gcc-link t.cpp -L ./lib -lmcl -lgmpxx -lgmp -lcrypto -I ./include/ -O2 time ./gcc-link 2.661u 0.000s 0:02.66 100.0% 0+0k 0+0io 0pf+0w clang++-6.0 -o clang-link t.cpp -L ./lib -lmcl -lgmpxx -lgmp -lcrypto -I ./include/ -O2 time ./clang-link 2.546u 0.004s 0:02.55 99.6% 0+0k 0+0io 0pf+0w
travis-ciのASanでエラー
travis-ciでなぜかエラーがでるようになった.
664==2778==LeakSanitizer has encountered a fatal error. 665==2778==HINT: For debugging, try setting environment variable LSAN_OPTIONS=verbosity=1:log_threads=1 666==2778==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc)
よく分からんが, sudo : trueにしたら動くようになった(cf. Enable ptrace capability in container based builds).
結構前からの現象のようだが, だとすると逆に今まで動いていたのはなぜだろう.
384bit Montgomery乗算
メインのところはあらかた終わった. もうちょっと速くなるかと思ったけどそれほどでも無かった. 2.5Mclk程度.
mclの高速化
mulx + adcx + adoxはレジスタ使用数が減るのでうれしいけどすごく速いというわけではないのがなんとも.
mclの高速化
とりあえずgccの件は保留にして細かい最適化の続き. 1%も変わらない試行錯誤が続く.
clang vs. gcc
今頃気がついたのだけどmclはclang-6でbuildしたほうがgcc-7でbuildするより1割以上速い. かなりの部分がすでにasm化されてるのにこの差は大きい. 何が原因なんだろう. さらっとプロファイルを見る限りではそれほど違いがないように見えるのだが.