開発状況や、アルゴリズム等について日々まとめていきたいと思います – IUEC

いつもお世話になっております。開発担当の矢野と申します。
開発状況や、アルゴリズム等について日々まとめていきたいと思います。なにとぞよろしくお願いいたします。
※ まとめようとして何度も挫折しておりましたが(申し訳ございません)、今回は、しっかりまとめていきたいと思います。

Ver2.1最終版の最終調整を行っております。
今回は復旧機能の大幅強化となりまして、出来る限り自動で早く結果を出せるように工夫しております。
データ復旧の機能は、大きく分類いたしますと、以下の3プロセスを早く処理できれば、総合的にも早くなります。

1:探索・回収
2:分解・並び替え
3:解析・生成

基本的に「地道」な作業です。特に目立つようなトリッキーなどがある訳でもなく(あったら欲しいのですが…)、
黙々と探索して手掛かりを集めて、それらを分解・並び替えして解析できる形に落とし、それらを解析してデータを出します。 ただ、地道なんですが、ここで上手くマネジメントできると、効率が飛躍的に上がるため、それを見つけるために日々没頭しております。
※ 矛盾しているように見えますが、トリッキーではなく、効率面のマネジメントを改善いたします。空いているCPUを働かせます。

最近のパソコンは実行コアが複数実装されておりまして、それらを同時に稼動させる事が出来ます。
基本はシングルスレッド(ただ1つの実行)で探索・分解・解析を行わせれば、間違いなく矛盾は出ず、上手くいきますが、効率は最低ラインです。

しかしながら、例として8つの実行コアがある場合、5つを探索・回収、2つを分解・並び替え、1つを解析・生成に振り分ければ、非常に早くなりますね。

でも、これが中々上手くいかないのです。例えば分解が早過ぎて探索が間に合わなければ、分解を担当したスレッドは待機します。待機というと良さげに見えますが、スピンロックと呼ばれる機構でCPUを空回しして、「遊んでいる状態」となります。
探索が早過ぎて分解が間に合わない場合は、物置(コンテナ)にそのデータが沢山入り込んでしまい、メモリを圧迫してしまいます。

では、事前に調べてから・・、といきたいのですが、その調べる過程にお時間を要しますので意味がありません・・・。
また、各コアにそれらの仕事が丁度良く振り分けられる訳ではなく、あくまでもOSが自由に振り分けてきますので、それに合わせる必要もあります。
それでも、偶然的に見つけたものや、それらの副産物で上手くマネジメントできるようになってきております。

1~3が上手く自動的に動くようになりまして、いよいよ拡張となる4番です。
4:ドライブ故障統計を導入

https://www.iuec.co.jp/