投稿

butterfly search 4.1 をリリースしました。

butterfly search 4.1 をリリースしました。  リリース先:   https://www.vector.co.jp/soft/winnt/util/se437071.html (vectorさんでの審査後に公開されます。執筆時点では旧バージョンが公開されています) 変更点は処理速度と安定化になります。クラッシュする事が減っていると思います。 ■技術的な話 ・ファイル名の検索 高速化に関してはファイル名のみを検索した際に、CPUを12ケ割り当てるようにしました。 これにより12倍速になっているはずです。 それでも、Everythingの検索のほうが速いです。ファイル名はインデックス化していないので勝てないです。 ・ファイルアクセス CFileを使用してアクセスしていますが、CFileが遅いことに今更気が付きました。 CFileの呼び出しを減らすことでwriteの速度は2倍くらい向上しています。 ちなみにCStringは極悪なほど遅いので、速度を求める処理にCStringを使用してはいけません。

TCMallocのメモ

 butterfly search(以下BF)ではmallocを多用しているのでGoogleのTCMallocを使用してみた。 TCMallocはGoogle独自のC/C++用メモリアロケータである。 ■結果 インデックス作成時間 TCMalloc未使用 2時間4分 TCMalloc使用  2時間19分 (12スレッド  メモリ確保量1GB×12スレッド=12GB ) 結論としては性能劣化でしたが、特筆すべきはTCMallocのメモリ開放性能。TCMallocはまじ高速。通常より20倍くらい速そう。(きちんと測定できておらず申し訳ない) BFはreallocを呼ぶ割合が多いことに気づきました。したがって上記の結果は参考にすらならないと思います。申し訳ありません。(2023.8.4追記) ■今後 CPUの数が12では並列度が足りないのかも。もっと高性能なCPUを入手したら再チャレンジしてみよう。 ブログでTCMallocの性能を公開している人がいるが、ぜひマルチスレッド時の性能を測ってほしい。TCMallocのコンセプトはマルチスレッド時の性能ですからね。シングルスレッドの性能で速いとか言われても。 ブログでTCMallocの性能を公開している人がいるが、ぜひ解放時の時間も含めて語ってほしい。 mallocしたらfreeするよね。普通。 TCMallocはチューニング可能との事なのでいつかやってみようかと。 TCMallocはWindowsとの相性が悪いのかもしれない。であればGoogleとしてはどうしようもないね。

butterfly search 4.0 をリリースしました。

 リリース先:   https://www.vector.co.jp/soft/winnt/util/se437071.html (vectorさんでの審査後に公開されます。執筆時点では旧バージョンが公開されています) 大きな変更点としては、処理速度の改善があげられます。 コンパイラをVisual Studio 2022にして、アプリを32bit→64bit化しています。 これによってボトルネックだったメモリの使用上限2GB(4GB設定だけど実際には2GBくらい/理由は後述)が無くなりました。 ポインタサイズが2倍(データ量が2倍)になり、PCに求めるスペックも2倍になりました。 結果的には思ったより時間短縮にはなりませんでしたが、今後CPUのスレッド数が増えれば時間短縮になっていくと思います。 動作するスレッド数はメモリの搭載量に比例して変化するように作ってあります。 現在は最大12スレッドで動作するようになっています。12の理由は私が使用しているPCがRyzen 5 1600(12スレッド)だからです。 機能面としては、日付のヒートマップ画面の追加があります。何月何日に何が起きたのかを2次に展開した形で確認できると思います。年号(大正、昭和とか)も認識するはずです。こちらは現在もバグばかりの状態なので今後に期待していただければと思います。 ■技術的な話 32bitアプリの延命措置として/LARGEADDRESSAWAREオプションをよく使用すると思います。 /LARGEADDRESSAWAREオプションをコンパイル時に使うと2GB→4GBまでメモリを使用できるようになると書いてあります。ですがこれは、実際にはメモリを一度も開放しない場合の話。malloc()後free()しないのであれば4GB近くまで使えますが、 malloc()とfree()は繰り返しますよね。そうすると仮想アドレスが断片化するので、大きなサイズの仮想アドレスの確保がうまくいかなくなります。 例えるなら電話番号0000から9999までの1万回線を連続して所持したいという希望があった時、設備にも余裕があったとしても古い電話帳では連続した空きは見つかりませんね。そんな感じです。

SVN リビジョン1000はありません 「No such revision xxxxx」

イメージ
butterfly searchのソースをコミットしようとしたらTortoiseSVNが 「リビジョン1000はありません」って言ってくるじゃないですか。 もうこのカメちゃんったら、寂しがりやさんなのね。。。 惨事が起きていると理解し、SVNのリポジトリが壊れたことが分かったのだけれども、SVNのリポジトリはGoogleドライブに置いているだよね。Googleドライブが壊れる訳ないよね。 症状としては、リビジョン1000のコミットではエラーが出ないけど、その次の1001のコミットで1000に関してのエラーがでる。 処置としては、、、  リビジョンを999に戻して、SVNのリポジトリをGoogleドライブ(Gの仮想ドライブ)に置かない。でとりあえず復旧しました。仮想ドライブ上では操作しても復旧できませんでした。 SVNはリビジョン1000毎にフォルダを作るのだけれど、それがGoogleドライブ上ではうまく行かないって事なんだろうな。butterfly searchで検索Gドライブを検索させるとエクセプションが発生するのでGoogleドライブが提供している何かのAPIに問題があると思われる。 障害発生時のバージョン情報 TortoiseSVN TortoiseSVN 1.14.5, Build 29465 - 64 Bit , 2022/09/24 08:31:31 ipv6 enabled Subversion 1.14.2, -release Google ドライブ バージョン: 73.0.4.0

butterfly search 3.0b をリリースしました。

 butterfly search 3.0b をリリースしました。 リリース先:   https://www.vector.co.jp/soft/winnt/util/se437071.html (vectorさんでの審査後に公開されます。執筆時点では旧バージョンが公開されています) 大きな変更点としては、インデックスに登録する条件を増やしました。 今までインデックスのキーとして登録していなかった単語同士の組み合わせも 登録するようにしました。これにより今まで苦手だった、よく登場するけどその組み合わせはあまりないという条件、 例えば「0+0」の検索がまともな速度で動作する様になりました。英語の文章検索も速くなっています。 これによる副作用としては、キーの数が1.5倍くらい増え、インデックスの作成時間も1.5倍くらい長くなりました。 ■「0+0」の場合 ・3.0aまで  → 「0」,「+」の2つをインデックスに登録。 ・3.0bから  → 「0」,「+」の2つをインデックスに登録しさらに、       「0+」,「0+0」,「+0」の3つをハッシュ化後にインデックスに登録。 ■「This is a Pen.」の場合 ・3.0aまで  → 「THIS」,「IS」,「A」,「PEN」,「.」の5つをインデックスに登録。 ・3.0bから  → 「THIS」,「IS」,「A」,「PEN」,「.」,「 」の5つをインデックスに登録しさらに、      「THIS 」,「 IS」、「IS 」,「 A」「A 」,「 PEN」「PEN.」,      「THIS IS」「 IS 」,「IS A」,「 A 」,「A PEN」,「 PEN.」の14つをハッシュ化後にインデックスに登録。  ■「今日はいい天気ですね。」の場合 ・3.0aと3.0bで違い無し  → 「。」、「い」、「いい」、「いい天」、「い天」、「い天気」、「す」、「すね」、    「すね。」、「で」、「です」、「ですね」、「ね」、「ね。」、「は」、「はい」、    「はいい」、「今」、「今日」、「今日は」、「天」、「天気」、「天気で」、「日」、    「日は」、「日はい」、「気」、「気で」、「気です」の29つをインデックスに登録。

良い○○○○は偶数サイズ

イメージ
■はじめに 先日、AI(人工知能)の本を読んでいたら、将棋ソフトは三駒関係という評価手法よって劇的に強くなったとの事。3つの並びが価値を生むという事だ。 そういえばこの前、4文字熟語のランキング作ったけど特に反応無かったな。。。 とりあえず今回は、butterfly searchを使用してある特徴を持つ3つの数字の並びを抽出し、その1つ目の頻度を表にしました。(ノイズ多々ありです) ■おっぱい集計結果 抜粋 全体 まず、タイトルにある良いおっぱいとは何ですかという事ですが、これは、WIKIにあるおっぱい事。WIKIにある記事は良い記事なので、そこに存在するものは良いもの。そこで観測したおっぱいは良いおっぱい。 ■最大 観測された最大値は、ミリア・ファリーナさんの415cm ■考察 まず、今回最大の気付きは良いおっぱいは偶数という点。 単純に合計しても、 偶数サイズのおっぱい:11063 回 奇数サイズのおっぱい:8140 回 これを「おっぱい偶数の法則」と名付ける。 但し、一番頻度が高いのは奇数の83cm、1852回。 ■おっぱい偶数の法則 奇数サイズのおっぱいは偶数サイズに引き寄せられるとしか考えられない。 それとも1つ1つが奇数で2つ合わさるので偶数ということなのか。 なぜか?下記のようなことが起きているのかと思われる。 正規分布からのずれ 大きさ 考察 ↑人気 80 1つの大台。無理をしてでも到達したい感は認める。 ↓不人気 81 下一桁の1ってなに? 中途半端がいけない。 普通 82 問題なし。 ↑超人気 83 素数。神聖な感じ。おっぱい偶数理論がここで一旦破綻。 ↓不人気 84 4っていう数字のイメージが悪い。 ↑人気 85 五十日(ごとおび)は道路も混むし、四捨五入すれば90に届く。 ↑人気 86 helloという語呂がよい。 ↓不人気 87 それなら88に統合。85を境に大雑把感が増すので素数のミステリアス感がない。 ↑人気 88 ぞろ目。これは末広がりで縁起も良い。 ↓不人気 89 一歩手前。79と80では大きく違うが89と90は同じで良い。90へ統合。 ↑人気 90 大きすぎて雑。乱雑なおっぱいがここに集まる。 ※諸説無し。(この研究は今ここで始まったばかり) ■確認(再現)方法 ①wikiのテキストをダウンロードし解凍 https://dumps

butterfly search 3.0 をリリースしました。

butterfly search 3.0 をリリースしました。 リリース先:   https://www.vector.co.jp/soft/winnt/util/se437071.html (vectorさんでの審査後に公開されます。執筆時点では旧バージョンが公開されています) 大きな機能追加として、日時情報の抽出が挙げられます。 ドキュメントを跨いで時系列に情報を表示する事が出来ます。 butterfly searchは、「抽出」、「ソート」、「表示」という構造を持っており、「抽出」を変える事で もっといろいろな可能性がある事に気が付きました。 Ver3.0にしたのは、その可能性に気が付いた為です。 まだまだ雑な動きをしますが、少しずつ直していきます。 ーーーーーーーーーーーーーーー 質問を頂きましたので画面サイズの変更方法をアップ(動画)します。 ーーーーーーーーーーーーーーー