Perl で作る画像類似検索システムの考察
今日はとてもショッキングな出来事がありました。あまりにショックがでかいので何かに没頭しなければ気が紛れそうにありません。と言うわけで全く専門分野でもないし当面使う予定もないのですが、１年ほど前にちょっと気になっていた画像の類似検索についていろいろ調べてみました。 どうやら ImgSeek ってソフトが結構有名らしいです。最新バージョンは 0.86 で Linux Only です。１つ前のバージョン 0.85 は Windows binary があります。 過去にいくつか画像類似検索ソフトを試したような記憶がありますが忘れてしまいました（vector でも結構類似検索ソフトありますね）。まずは windows binary 版をダウンロードしてきて実行してみました。 それなりに使えそうな予感がします。Linux 向けの imgSeek-0.8.6.tar.bz2 をダウンロードしてインストー
ワードサラダ技術について
後半部分が重要で、未来の挙動が現在の値だけで決定され、過去の挙動と無関係である ということです。 さて、実例です。たとえば次の文章を考えてみます。 「通信販売大手セシールは９日、生命保険の販売に本格参入する方針を明らかにした。」 まず形態素解析するとこんな感じになります。 通信 名詞,サ変接続,*,*,*,*,通信,ツウシン,ツーシン 販売 名詞,サ変接続,*,*,*,*,販売,ハンバイ,ハンバイ 大手 名詞,一般,*,*,*,*,大手,オオテ,オーテ セシール 名詞,固有名詞,組織,*,*,*,セシール,セシール,セシール は 助詞,係助詞,*,*,*,*,は,ハ,ワ ９ 名詞,数,*,*,*,*,９,キュウ,キュー 日 名詞,接尾,助数詞,*,*,*,日,ニチ,ニチ 、 記号,読点,*,*,*,*,、,、,、 生命 名詞,一般,*,*,*,*,生命,セイメイ,セイメイ 保険 名詞,一般
/dev/shm に参照系ＤＢを持っていくと I/O 負荷が激減した件（当たり前だけど）
前エントリーから一部の内容を分離して追加記事にしてみました。以下実施したメモリ増設の効果について。 ここ数ヶ月、自宅サーバの負荷がだんだんと上昇してきていて、そろそろ１台で高速にさばききる限界に近づいてきた感があったり。ここ数週間のロードアベレージはこんな感じ。グラフは× 100 の値になってます。CPU のコアが２個なんで、200 までは OK ということでまだ処理しきれているわけではあります。ちなみに mrtg グラフは瞬間値を示しているわけではなく平均値なので瞬間的にはもっと負荷が高いときとかあります。 でも月次処理が走るともっさり感満点。 ※緑：１分平均 ／ 青：１５分平均 実は CPU の処理速度が追いついていないと言うより I/O 周りがボトルネックになっています。 ※緑：読取ブロック数 ／ 青：書込ブロック数 ということで、メモリを２GBプラスして、合計 4GB にして参照系
VMware が頻繁にディスクアクセスして OS 全体が固まる件
こんな現象が発生するようになったのも XP + VMware 5 → Vista + VMware 6ベータ にしてからなのですが、物理メモリもたっぷりのっていて空きメモリもある状態にもかかわらず、VM を起ち上げていると頻繁にディスクアクセスが発生してマシンが数分間フリーズしたかのごとく固まる現象が続いています。 以前物理メモリが 2GB だった時は、まぁ〜しょうがないか〜と思っていたのですが今は 3GB のっていて（ホントは4GBだけど OS が 32bit なのでうまく認識しない・・・）コレは流石にキツイ。ってことで原因を調べてみました。 まずはリソースモニタを起ち上げて VM を使ってディスクアクセスが発生するのを待つ。すぐに発生した。 どうやら VMware の .vmem ってのが頻繁にディスクアクセス（read）を行っている模様。もう少し様子を見てみる。 こんどは頻繁にディス
Image::Magick を使って大量画像のサムネイル画像を一括自動生成
お仕事で素材集 CD-ROM 内の画像ファイル全２万点を全てリサイズして欲しいという依頼が来た。自社のコンテンツに使うためのリサイズ作業です。初めは OPTPiX webDesigner のバッチ処理で何も考えず 50 x 40 px にリサイズ。縦横比が違う画像が一杯なので何とも無惨な画像が数時間後にできあがった・・・orz 仕方がないので、PhotoShop のバッチ機能でトリミング〜リサイズ処理をやってみた。どうやら素材集の jpeg の圧縮パラメータが違うようでリサイズ後の保存時にダイアログが開いて圧縮パラメータをどうするかいちいち聞いてくる。OK ボタンを押すだけなのだが、全然バッチになってない・・・orz 仕方がないのでリターンキーを押下状態にしてセロハンテープを貼り付けて帰宅時に放置。今日の朝に完成しているはずだったけど、しっかりと PC がフリーズしてました・・・orz し
VMware の仮想ディスクを物理ディスク構成に変更する方法
前エントリ「VMware で仮想ディスクのサイズを変更したくなったとき」の最後の項目で、仮想ディスクのパフォーマンスを向上させるために物理ディスク構成の仮想ディスクへ移行する方法を書きましたが、もう少し詳しく書こうと思います。 HDBENCH でパフォーマンスを計測するために、Windows Vista を guest OS とした場合をやったので順に説明をしたいと思います。ちなみにパフォーマンスの結論から先に言うと、Core 2 DUO が VT 対応の CPU だからかもしれませんが、物理ディスク構成の場合、DISK 性能はフルにでていると思われます。ストレス ０ です。 前エントリと同様の手順ですが、VMware の仮想マシン設定から物理ディスクを追加する。PhysicalDrive0 は今使っている Windows が入っている HDD なので、それ以降の PhysicalDriv
VMware で仮想ディスクのサイズを変更したくなったとき :: Drk7jp
VMware 仮想ディスクマネーシャ（VMware Disk Manager）を使用する事で、コマンドラインから、仮想ディスクファイルの作成、管理、変更が可能です。 1) コマンドシンタックス vmware-vdiskmanager.exe -x <拡張後のサイズ> 仮想ディスクファイル.vmdk これで仮想ディスク容量の変更はOKです。これで、仮想環境上からみれる物理ディスクの容量は増えます。 仮想ディスク容量を増やした後どうする？ 上記のコマンドで仮想ディスクを増やしただけでは OS 上から使用可能な容量は増えません。パーティション情報も変更してやる必要があります。商用の Partition Magic とか持っていなくても、GParted Live CD を使えば、パーティション情報を変更することができます。ISOイメージをダウンロードして、VMware の仮想 CD-ROM の「I
Lighttpd 1.5 系がスゴイらしい
はてブで lighty のブログがあることを知ってブログを見てみました。lighty の中の人が書いてます。 ナント、lighty 1.5 系が pre release されているではありませんか！ なんでも、1.5 系は いままでより 80% のスループット向上が見込めると書かれています。激速の lighty が更に高速になるってわけですよ。Σ(ﾟДﾟ； Using Async IO allows lighttpd it overlap file-operations. We send a IO-request for the file and get notified when it is ready. Instead of waiting for the file (as in the normal sendfile()) and blocking the server, we ca
イケてないプログラム（使えない成果物）に見られる３つの共通点
クイックソートの話で書いたとおり、相変わらず Excel - VBA と格闘する日々が続いております・・・orz 「大企業にありがちな問題。委託開発の甘い罠・・・」でも書いたとおり、今まで外注して作ったソフトウェアってほぼ 100% の確率でイケていないものが完成してます。年末に納品されたソフトウェアのできも酷いの何のって・・・ さて、いままで見てきたイケてないプログラムのダメソースに共通して言えることが３点ありまして、 DRY ( Don’t Repeat Yourself ) でない。同じもしくは似たソースのコピペが至る所に散在する。 ロジックに無駄が多すぎ。行き当たりばったりで作った感、満点。 アルゴリズム知らなさすぎ。馬鹿ループ処理で時間かかりすぎ。 のいずれか、もしくは全部が当てはまります。大抵は全部ですね。こういったソースが納品されると、センス無いなぁ〜と思っちゃうわけ。こうい
【続】やはり Perl はメモリ喰いな言語。データ型の内部構造
以前、「やはり Perl はメモリ喰いな言語。データ型の内部構造」という記事を書いたことがあるのですが、自分で書いておきながらしばらく立つと完全忘却してました。時代は変わって、今仕事で運用しているサーバは、64bit 版のＯＳです。 最近になって、DB のテーブルのデータを加工・集計しながら CSV にダンプするってプログラムが、データ数が非常に多いときに、1.5 GByte ほどメモリを食いつぶしているってことに気がつきました。理由は至って簡単なのですが、結構ハマリどころなので備忘録として記事にしておくことにしました。 みなさん、仕事とかでは特にそうだと思うのですが、DBI の処理って何らかのラッパーを書いて使っていると思います。僕は適当に書くとよくやってしまいがちなのですが、イメージ的には、こんな処理の流れのコードを書いていました。 （・・・えっ？そんなへぼコード書いてない？？・・・す
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
