想像してみる。
まず、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分の壁すら到達できないだろう。
なんにしても、クラスの基本部分を弄るしかないだろうと思っている。
開根くらいでもたついていては、開立や三角関数なんてどんなに時間が掛ることか知れたもんじゃない。
激しく表示制御をすると落ちるのは、タスクバー表示制御で何らかの問題が発生するからのようだということで、少し修正。
で、ドライバ側にも問題があるのか知らんけど、SEG CLIPの終了に失敗する場合がある。
そのときは、処理を中断する。
＃本当にどうにかしろっつうの＞IO。
で、そうなっちまった時にはデバイスを抜いて再挿入すれば、復活するっぽい。
手作業ウザし。
合法ダウンロードはこちらから。
書き忘れてたけど動作確認はXPのみ。
要.NET Framework 3.5。
記事へのIOデータからのアクセスを確認！
その後の、リファラ無しの石川県(*.infoweb.ne.jp)からのアクセスも、無関係ではないだろうと思いつつ。
既出の対策ツール、ウィンドウをそのまま出してるのもどうかと思ったので、タスクトレイに入れてみた。
単なる監視だけでタスクバーを圧迫するのもどうかと思ったし。
タスクトレイのアイコンをクリックするとウィンドウ表示・非表示されるはず。
＃初期値の設定が難しいので、最初のクリックがノーカウントになるようですが。
＃あと、あまり激しくクリックすると、落ちるようなので、注意。
終了はウィンドウを[Ｘ]で終了するか、タスクトレイアイコンを右クリックして「終了」。
最小化で隠す処理は未実装。
そんなことより、しきい値を変更できるようにしたほうがいいかもね。
＃予約録画時抑制もできればいいんだけど。
公開されたようです。
Addin for Excel 95-2007 Basic Edition ダウンロードページ
Addin for Excel 95-2007 Free Edition ダウンロードページ
不具合修正されてますので、是非。
ハンドルリークを仕様とか言っちゃうダメなサポートのある会社の続き。
＃もう、伏せない。
サポートがダメだから、個人的に何とかしないとならん。
「ハンドルリークは仕様だから適宜再起動してください」では、何のサポートにもなっていないことを、IOデータは自覚すべき。
＃ま、自覚できてりゃもう少しマシな回答するんだろうけどな。
と、言ってもはじまらん。
とりあえず、再起動しないわけにはいかない。
しかし、いちいち、ハンドルカウントを確認して、再起動するのは面倒この上ない。
ずっと考えていたけど、無いんですよね、必要な場面って。
昨日からの続き。
そして、構造体にコンストラクタを用意したところ、構造体を取り込んだ共用体でコンパイルエラーが発生する罠。
曰く、「共用体メンバに既定のコンストラクタを持たせることはできません」だそうな。
じゃぁ、既存構造体から新たに継承したクラスを作って・・・とかやると大手術になってしまうので、仕方ないからそれは次期バージョンにて考慮。
今回は、newでサーチしてnewや変数宣言など、構造体メモリを確保している箇所で片っ端から初期化してやろうと思う次第。
＃必要な個所だけ。
他に、実はnewしているのは決まってExcelに返すデータをエクスポートする箇所なので、それらを一か所に集約してやろうかと。
これで今回の原因は撲滅できるはず。
100%確実ではないけれども、再現させる方法だけは見つけたので。
Windows 7を起動して、評価に使用したExcel95ブックをExcel2007で開くだけ。
すると、再計算50%を過ぎたところあたりでExcelがエラー(動作を停止)を起こす。
ここら辺が微妙なんだけど、50%のときもあれば、そうでない場合もあり。
2回目には起こらないので、都度OS再起動が必要。
ところが、通常、プロセスの異常時には、「デバッグしますか？」のダイアログが出るのだけれど、このExcel2007は自動修復するのか、デバッガでアタッチするとプロセスが終了してしまう。
困ったことナリ。
デバッグモードでは再現したことがないので、あたりをつけようにも・・・
とりあえず全エクスポート関数の大部分をtry～catchで囲んでみたのだけれども、状況は好転せず。
なんだか変。
Windows7やVistaで動作確認しようと、アドインを設定して、気を良くしてHLDIV(10,3)とかやるとExcel停止・・・
なんでやねん！
デバッグしようとしても痕跡なし。
じゃぁとVS2008からデバッグ実行すると、全く落ちず。
そうこうしてるうちにExcel停止が再現しなくなる。
なんだこりゃ？
本当に、あまりこういうことは書きたくないわけよ。
処理を簡素化するためにコンピュータ使うわけだから、そこに無用なイライラがあっちゃいけないはずなのに、無くならないのはこの業界がおかしいせいだと常々思っているってのはさておき。
バッチ処理のアプリなら、都度起動終了なので、大して問題じゃないけど、ウィンドウアプリの大半は、ユーザによる終了が無い限りはずっと動き続けるもの。
それをハンドルリークが仕様です、ご了承ください、ってな問い合わせ回答しちゃうようなメーカーがあるとは、ユーザーはどう受け止めればよいのでしょうかね？
ハンドルはリソースなので、OSとしても限りある資源、がっぱがっぱ使い放題された日にゃ、他のアプリケーションで何か不具合が起こってもおかしくないわけですよ。
重要。
でも、検算するのがとても大変なのは多桁演算の宿命。
だから、大体正しければいい、というものでもない。
除算の評価結果を見ていて、変なことに気付いた。
検算をするとどうもおかしい。
筆算してみても、自分が間違えてる可能性もある。
Windows付属の電卓はかなりの桁数計算できるが、それと比較すると、やはりどうも多桁計算側がおかしいようだ。
使用メモリ量と演算回数を削減したんだけど、Excel95落ちるようになっちゃいました・・・
多分、どこかで例外発生しているってことなんだろうけど。
おっかしいなぁ・・・って、よく見たら凡ミス。
直したら動くようにはなったけど、やはり重い。
＃加算・減算だけでなく、内部で加算処理をしている乗算も重い場合がある。
リソース絡みだと思いたい。
Excel95のリソース制約は一番厳しいので、Excel95で動けばExcel2003でも動く。
＃Excel2007からは別物だけど。
VirtualPC上のとあるXP。
デュアルコアだから倍速？
こんなのってはじめて。
そういや、x64CPU使うとx86Dualとして動作するとか広報したOSってあったよな～
なんか、すごく重い。
今のところ原因不明。
Excel95で桁数多い場合に発生中。
Excel2003では発生しないようだした。
Excel95では同じ計算でも発生するときと、しないときがあるようだ。
数としてはあってもいいんだけど、-0が返るパターンがあったので、符号補正を入れて修正。
別に、1文字2文字で困る文字数じゃないから放置してもいいんだけど、0と-0が違うかっていうと十進数演算の中では同じなので、だったら符号不要ということで。
多桁計算にも一応、四捨五入丸め処理を入れている。
というのは既出だが、Excelに文字数制限があるため。
つまり、表現上、数に制限が生まれるわけで、普通の有効桁と同じ扱いと思ってくれればいい。
除算した場合、循環小数なんかはその限界まで延びるのだけれど、そこで四捨五入が必要になる。
掛け算でも桁が多ければ丸める必要がある。
多分、浮動小数点絡みだと思うんだけど、微妙に異なるらしい。
それも、Excelのバージョンによって、微妙さも違うときた。
これにより、計算結果を評価するのがとても面倒なんですが・・・
どうやって評価しようかと、そんなところで躓く。
因みに、やってびっくりしたのが、=1.5*1.3-1.95って計算、Excel95でやると、2.22E-16になるんだぜ・・・。
どうしてやろうか。
多桁乗算を使って、=VALUE(HLMLT(1.5,1.3))-1.95を計算すると、Excel95でも、0が返るんだけどな。
C/C++(非.NET)でHTTPSクライアントをつくるとき、OpenSSL使わなきゃできないと思い込んでいたんだけど、ことWindowsに関して言えば、OpenSSLをインストールしなくても、IEとかで普通にHTTPSアクセス出来てるので、単なる思い込みだった。
マルチプラットホーム対応するならば別だけど、Windows専用ならば、MSXMLを使えばできるっぽい。
Windows2000以降になるようだが、IServerXMLHTTPRequestなオブジェクトを使うと、HTTPSコンテンツを取得できたので、これは素敵過ぎる。
MSXMLを使う利点は、MSXMLに不具合があっても、WindowsUpdate(MicrosoftUpdate)で対応できる点。
＃つまり、MSXMLを利用するアプリケーション開発側の対応は不要ということ。
一応、オレオレエンタープライズなオレオレワイルド証明書を使ってるこのブログサイト(https://blog.fne.jp)のコンテンツも取得できたので、こいつは使える。
＃エンタープライズルート証明書のインストールは必要です(多分)。
乗算と除算、ずっと考えていた方法でできそうだったので、気合い入れて実装しちゃいました。
まだ評価していないけれど。
加算・減算・乗算・除算の4関数を軽く動作確認。
処理速度にはちょっと満足できないけれど、処理結果にはほぼ満足。
小数点以下数万桁の数に意味はあるのかと問われれば、あると答える根拠を持ち合わせているわけでは無い。
けれど、逆に本当に無視していい数なんてあってよいものかと考えたら、小数点以下数万桁でも無視するのは忍びない。
だから、できるだけ多くの桁を利用したい、そのための多桁計算関数。
そして、リソースを喰い尽くす罠。
さて、どのEditionに組み込んで、バージョンをいくつにするか、決めなきゃな。
とりあえず、今回はBasicEdition(有料版)かなぁ。
因みに、まだまだ追加予定の関数はありますよ。
