Improve parallel processing (並列処理の高速化)

[kazuminn]

並列HashMapを導入してみようかと思っています。

tokioで並列化されていますが、ただのロックだと、書き込み時にシリアライズ化されてしまうので、遅くなるようです。

並列HashMapの中身が巧妙になっており、2スレッドから同時アクセスが可能で、理論的に性能が2倍になったりするそうです。

仕組みは、hashmap全体をロックしてしまうと一度しか書き込めないので、セグメントごとにロックをして、複数スレッドから書き込めるようにするらしいです。

https://docs.rs/chashmap/latest/chashmap/

やってみて、あんまり変わらなかったら、取り込まない感じで、ちょっとやってみます。

[kazuminn]

MESSAGEはbtreemapからhashmapに変更すると、timelineの処理のパフォーマンスに影響するかもしれないので、よくない。

Btreeの並列はskiplistアルゴリズムらしいけど、
mapなので、以下のskipmapが良いかもしれない。

https://docs.rs/skiplist/0.2.10/skiplist/skipmap/struct.SkipMap.html

タイムラインの実装など私がわかってないので、コード読んだり、調査が必要。

[kazuminn]

jamesさんからの意見をメモしておく。

ロックを使わないで、
各々のスレッドで独立変数用意しちゃって、終わったらマージしちゃえ、という意見も出た。

ロックを取得しているのはスレッド間で共通した変数にアクセス使用しているのが原因なので、スレッドで共通した変数は使いません。
代わりに、スレッド毎別々に用意した配列に検知結果を格納して、スレッド終了時にその配列を戻り値で受け取るようにすれば、ロックを取る必要が無いと思います。

[hach1yon]

なんか、ここのissueを見ると、並列HashMapでも良いような気がしてきました。
並列hashmapだと、コードの修正量が少ないので、それでも良いかも

[kazuminn]

skipmapは、ちゃんと使えるライブラリが断念。（no_stdだったり、ライセンスが無かったり、開発途中だったろ）

並列hashmapはお試し実装中ですが、skipmapより比較的コードの修正量が少ないだけであって、結構修正しなくてはいけない（Rust難しい。何もわからない）

[kazuminn]

DashMapという並列HashMapを実装してみると、最新ルールを使って、ザックさんから前にもらった2GBのevtxが

00:17:28.143 -> 00:15:38.189
00:21:58.924 -> 00:15:24.626

になりました。

パソコンのスペックとして、memory:8GB, 8コア　です。

コードが汚いので、きれいにしてから、プルリクします。
そのとき、ザックさん高スペックのマシンでもテストしてほしい、と思っています。

[YamatoSecurity]

ありがとうございます！
了解です。楽しみにしています。