AES高速化をもう少し
割と最速だったJavaで作ったAES実装もJDKのAESがOpenSSLかなにかのハードウェア実装を使うようになったおかげで数倍の差がついてしまった。KCyper-2がまだよくわからないのでAESをつついてみたりPKIの方を見たり。 Intel CPU にはAES NI というAESの計算補助的なものがあり、AMD Ryzen 2600X でも使えるようになっていて速くなる。OpenSSLが対応しているのでJavaでもOpenSSL経由でいつのまにか使えるようになっていて、高速処理ができている。 AES NIもたぶん途中の計算をまとめられるだけまとめてあらかじめ計算しておき配列に押し込んで高速化をする手法。 ソフト的にも高速化していくと同じような実装になって普通に解説されているような実装の数十倍はやくなる。 特に競ってみようというわけではないが、いろいろなハッシュや暗号を実装してみるなかでAESも乗せてみたついでに高速化もしてみたというのが前回くらい。32bitまとめるところで高速化ができたが、64bitにしてみたらもう少し速くなった気がするのでそのあたりで止めておいた。 decode側は最適化をどうやればいいのかと思っていたら、計算順を変えることでencodeと同じように最適化できることもわかったので割と高速な方にすることはできた。encodeと同じように64bit化したらencode以上に速くなった。 AES-CBC Ryzen 7 5800X で 初期値 1400Mbps、JavaのJITが効いてくると1650Mbpsくらいまで速くなる印象。AES-NIだと初期値2500Mbpsくらいなのでかなり追いついている。AES単体だとまだまだ差は大きいが今は未計測。 元になるAESのコードが跡形もなくなってきているので、原型を留めたコードを別に残しておかないと何の参考にもならないなと。 速度比較、AES単体ではなく若干実用的なAES-CBCで比較してみることにして、JDKのコードと2倍くらいの差まで迫ることができる。ということはJDKのCBCが遅いのか。CBCで64bit演算してそのままAESに持っていくことで高速化できている感じ。JDKはそのあたりが遅い印象。 最近の主流はCBCからGCMかなんかになってきているようなので、そっちも実装したいが仕様だけ見てコード自