想像してみる。
まず、IOデータ内で開発していないことが考えられる。
外注か、下請けか、もしかすると国内生産ではないかもしれない。
そして、IOデータ内には、ソースコードが無い可能性がある。
あったとしても、それを解読・修正するスキルを持った人材の欠如といったところが、想像に難しくないところだろう。
2月の前半、GV-SC200系以外のアップデートがあった。
恐らく、今回問い合わせをGV-SC200についてとして行ったため、GV-SC200のアップデートを出せなかったのではあるまいかと、思っている。
たとえば、50枚スピンドルで買ったDVDメディア。
今までは、焼いたあと、空いたタンクに貯めたりしていたんだけど、焼いて終わりになっていた。
タンクは保存には向いているけれど、検索性能に欠ける。
ファイリングすると、検索性能高いけれど、結構かさばる。
不織布だけで保存して検索もそこそこうまくできたらいいのにと思っていた。
去る2/20、土曜日で混んでいることは予想されましたが、行ってきました。
案の定、めちゃ混みでしたが、安さは力。
毎月20日は500円(税込)でとんかつ定食。
ごはん、キャベツ、味噌汁のおかわり自由で500円(税込)。
なんか、Q&Aに載せるらしいけど。
Q&Aに載せると、ハンドルリーク解消・・・されるわけないか。
多分、仕様ですとか載せるんだろ？
アホかと。
高速化ってのは、処理を軽量化する方向でやるのと、そうでない場合があると俺は思う。
前者はたとえば、条件分岐を減らしたり、計算回数を減らしたり、より簡易なコードにすることが多いと思う。
＃Simple is Bestってやつ。
今回(今日)の大幅な高速化は後者。
1位にいくつか数を加えた場合の桁上がりを処理するのは、1位値が10を超える場合のみでいいという、いわゆる打ち切り条件を加えた。
＃条件によっては効果が無いけれど、今回はやる前から処理分岐率50%で、その分の処理を打ち切れるという、かなの効果を見込んでいた。
桁上がり処理は、全桁を確実にループするため、条件によってやらなくていいというのは、メリットだろうと思ったわけだ。
おまけに、その処理は何度も通るため、結果、条件判断に掛るコストよりも大幅な処理速度改善につながったわけだ。
にしても、びっくりするのは、これで限界と思ってた60秒から30秒台まで高速化できたことよりも、処理のほぼ半分も無駄なことやってたこと。
さすがに俺もこれには笑うしかない。
＃その後、もう少し手を入れて、30秒切るところまできました。
環境は、Core2Duo L7500(1.6GHz)のまま。
開根時に多用してる減算をどうにかしたら速くなるんじゃないかということで、加算減算を見直し。
今までは、加算では各桁加算ループと桁上がり処理ループに分けていたんだけど、ループを1回で済ませられるように変更。
減算も、桁下ろしループ、各桁減算ループ、桁上がりループの3ループを1ループ化。
これだけで、60秒を切りそうな勢いで高速化できた。
他にもいろいろと手を入れているものの、減算の変更は一番効いたと思う。
もう少し見直して、余裕で1分切りを目指したいと思う。
＃でも、実用とは言い難いので、別の策を考え中。
プロセス情報を操作する時例外出る場合があるようなので抑制。
ダウンロード
＃そうそう、しきい値10000ってのは結構妥当っぽい(http://technet.microsoft.com/ja-jp/windows/ee787049.aspx)のでそのまま。
＃＃曰く、「特定の時点で 1 万個を超えるハンドルを開いているプロセスは設計がよくないか、ハンドル リークが発生しているかのいずれかである～」だそうな。
当然、まだ回答は無い。
「いましばらく」という言葉は使用者や受け手、場面により、その示すであろう期間が異なる曖昧な言葉であるため、回答で使用すべきじゃないよな。
「○日までに再度ご連絡致します」って書けば、その日までは待とうと思うじゃん。
だめだよ、あの会社。
開根筆算では2桁ずつ下ろしてくる処理がある。
これを省略してみたところ、少し速くなって2や3の開根で80秒を切れるようになった。
これが限界だと思っても、諦めなければ、その先がある。
でも、多分、今のままで1分切るのは難しい。
※A3には =HLMLT(A2,A2) で検算。
多桁開根確認中、数バイトのnewでヒープ破壊の例外発生。
何が原因かは目下不明。
Free Heap block xxxxxxxx modified at yyyyyyyy after it was freed
と言われるので、yyyyyyyyアドレスを見ると、確かに周りと違う値。
参照変数は、別スコープに移動したし・・・飛び地を不用意に書き換える処理は入っていないはず。
OS再起動して再現するようなら調査続行か。
メモリ使用量を減らしたり、演算回数を減らしたりして、処理速度アップを狙ってはいるのだけれど、どうも、方法にも限界はあるし、そもそものクラスのメモリ使用方法自体にもボトルネックがあって、どうにも速くならん。
2の開根で32767桁(文字(整数部や小数点等を含む))、二乗誤差は最小位+1なのはいままで同様。
二乗検算まで含めると結果表示まで、約2分。
そう、何とか2分を切るくらいまでは高速化(とは言えないが)できた。
開根のみであれば、なんとか90秒を切れるようにはなった。
＃非常にうれしいのだが、全く実用的ではない。
しかし、これ以上高速化しても、恐らく1分の壁すら到達できないだろう。
なんにしても、クラスの基本部分を弄るしかないだろうと思っている。
開根くらいでもたついていては、開立や三角関数なんてどんなに時間が掛ることか知れたもんじゃない。
