ぱぱネット（仮）

_ 一身上の都合により

職場の棚と机を整理していたら(謎)ラベルのないフロッピーが200枚ほどでてきた....。PC-9801のテキストGUIライブラリとか、Cバス/VMEバス変換のドライバとか、 ATM-MPEGボードのドライバのソースコードとか、いろいろ入っているはずなんだが もう見る気もおきない。

ルーペ状の機器で、メディアを透かしてみると、中身のダイジェストが覗けるような 拡張現実ツールが欲しいよ。ほとんどドラえもんの道具だけどな...。

_ [ワンセグ野郎] いいかげんベロンと8本もたれさがってるのが嫌になったので...

基板を起こそうかと一瞬考えた。USBターゲットはEZ-USBベースでいいだろう、 ソフトはそんなに大変でもないかなーとか気楽に考えていたんだが、 問題はワンセグチューナチップの方。

_ 問題1: やっぱチップを100個みたいな小ロットで入手する方法がない

昔つきあいがあったイノ****の営業さんにそれとなく聞いてみたんだが無理そうだ。 ロールで2500個とかこられても困る。賞味期限あるしな。

_ 問題2: パッケージがBGA

基板の方は中国の業者を使うと2層までならかなり安く作れるのだが(高周波を扱うので 不安だが基板面積の方は問題なし)。そこへ05BGAチップをマウントする方法がみつからない。位置合わせ等の規格を守って、マーキング等をきちんとあわせないと、自動マウンタが 読んでくれないだろうから、そこまで素人が指定することはできないよなーという印象。 とっても敷居が高い。07QFPまでだな手半田できるのは(笑)

_ 問題3: FPGA部分の設計コスト

1個のCypressのマイコンで、8本のチューナー転送を賄うためには、GPIFだとピン自体足りない。なのでFIFOを使わないとならないが、複数のチップを同期させながら1個のマイコンのバスに転送するためには、少なく見積もっても2000ゲートくらいのFPGAが外部に必要になると思う。この論理を誰が開発するんだと。

_ あくまで脳内のヨタ話なのでマジレスしないで欲しいんだけど

ネットでは部品代だけで概算した結果をみて 「高い!サギだ!」 って騒ぐ人が 良くいるんだけどさ....設計技術、量産技術、品質管理というもののコストを 考慮するという概念はないのかと思うわけよ....ASSYだけじゃないでしょコストは...。

仮に8チャンネルワンセグチューナー基板を作ったところで、 これが何枚売れるかと考えると暗澹たる気持ちになるわけよ。 しかも絶対に日本でしか使えないからね!(あとブラジルか?無理過ぎる)。 EUや北米でも売れるというなら話は別なんだがな....。

だからやはり日本国内でしか意味のないPT1とかFriioとかを、あの小ロットで良く やるよなーという印象なわけです。3万円で5000個売り切ってもたった1.5億の売上でしょ(計算あってるよな?)。 権利団体からの横槍が入る=瞬間不良在庫化のリスクもあった中では、とてもやる気にならない仕事だわね。

そう考えると、月1000台くらいのロットでも、企画さえ通れば余裕で自前生産できた 電気メーカー勤務は、 技術者としては本当にノーリスクハイリターンのパラダイス だった んだなーと。逆に言えば会社としては本当に非効率な構造だったわけだが。余った部品は過剰在庫だもんねえ。

もちろん社内には、アナログ回路・デジタル回路の専門家も沢山いたし、チューナー周辺の 設計ノウハウを持ってる人も沢山いたし。俺はなぜもっと会社に金のあるうちに おもしろいものを無駄遣いしようと考えようとしなかったんだと(笑)ものすごく後悔している。

_ [開発][Linux] Tokyo Cabinet/Tyrantで遊ぶ(2)

テーブル型のストレージをサポートし、制限はあるもののRDBMSと似たような感じに使える(はず)の Tokyo Cabinet。 実際にデータを登録して性能を見てみました。

まず生成条件。64bit有効でアライメント力256バイト(2^8)。CabinetではなくTyrantで接続。

dbname="$basedir/chest.tct#opts=l#apow=8#dfunit=2"

1行当たりのデータは....ちょっと仕事のデータを使ってしまったので(ぉ) 具体的には説明できないのですが、整数型x8,文字列型x3です。文字列型(UTF-8)で 1行当たりの平均バイト700バイト程度、最大2.1KBです(*けっこう大きい)。 また、整数カラム5つの完全一致でUNIQUEな制約がついています。SQL風に書くと(仮)、

UNIQUE(emptype, bumonid, groupid, nyuusyanendo, zyugyoincode);

みたいな感じです。上記の条件が全部一致した行は重複して登録したくない、ということです。 このデータを571265行登録してみました。

登録条件は以下の通り。

1. noidx: インデックスなし, 重複チェックなし
2. idx: 整数型7種類にDECIMALインデックス,文字列型にQ-GRAMインデックス,重複チェックなし
3. search: 上記のインデックスを生成しながらUNIQUE制約を1行毎にRDBQRYを発行することで実行

結果は以下の通り。横軸は1万行ごと、縦軸は1秒当たりの処理行数です。

既存テーブルを検索してみて無かったら新規登録する という処理は非常にありがちだと 思うのですが、ちょっと実用にならないくらい遅い....あまりの遅さに断念しました。

_ [開発][Linux] いやいやKVSなんだからprimary keyを工夫しなくちゃダメでしょ

そうでした。KVSは基本ハッシュデータベースなので、主キーの取り方で制約を実現できるのです。 つまり、ユニークIDをもらってくるこういう関数よりも、

my $id = $jinji->genuid();

どうせ文字列も使えるのだからキーをsprintfか何かで生成してしまえばよいのだと。

my $id = sprintf("%d_%d_%d_%d_%d", $emptype, $bumonid,
          $groupid, $nyuusyanendo, $zyugyoincode);

これなら被ることはないし、被った場合は後から来たデータで上書きされるだけ。 もちろん「登録しない」ということと「上書き」は全く異なる処理だけど、 今回の用途では問題ないのでやってみた。

通常の連想配列の実装では、ハッシュ関数を通すオーバーヘッドはあるはずだが、 キーの長さはほぼ一定なのだから処理時間も一定のはず、なんだけどなー。 これもあまりに遅いので打ち切った。

_ [開発][Linux] 「上書き」がいけないのかな....

後から来たデータで更新するのを抑止するにはputkeep()関数を使えばよいようです (ニューレコードのみ登録する)。 現実には上記のテストデータは全てユニークだから、UNIQUE制約にひっかかることはないので、 put()関数と違いはないと思っていたのですが....

やっぱり変わりません。 次いこ次。

_ [開発][Linux] 衝突が起きまくっている？

という推測も成り立つ。テーブルデータベースは、 ハッシュテーブルの各要素にBtreeのポインタが入ってる....という実装なのかなあ。 ってことは、ハッシュテーブルが疎になるような設定をしなければならないんだろう。 ざっと基本仕様書読んでbnumは関係ないと勝手に思い込んでいた。 57万件ということは2倍の100万件くらいにしておけばいいかな。

dbname="$basedir/chest.tct#opts=l#bnum=1000000#apow=8#dfunit=2"

やっぱり変わりません。 万策尽きてきた.....

_ [開発][Linux] 諦めて基本仕様書を読み直す

基本に立ち戻ってつらつらと.....

bool tctdbsetindex(TCTDB *tdb, const char *name, int type);
`tdb' specifies the table database object connected as a writer.
`name' specifies the name of a column.
      If the name of an existing index is specified,
      the index is rebuilt.
      An empty string means the primary key.

え？ An empty string means the primary key. ？？ ということはデフォルトでは主キーにもインデックス貼られてないの？？？ そんなバカな....

$jinji->setindex('', $pm->ITLEXICAL);

を追加。

俺にはTokyo Cabinetは使いこなせないようです。

_ [開発][Linux] わかった！！！！！

いままでやってたの全部的外れ！！！！

お気軽全文検索 をやりたかったので安易にQ-GRAMインデックスを張っていたのだが.....仇になった。

以下のサンプルで再現できる。

1. Debianでttserverを起動
2. /tmpにoriginal.txtを置く
3. perlでtyrant.plを起動

tyrant.plはttserverへ接続してテーブルを登録する。キーは数値。 重複チェックはttserverでおまかせ。1行登録するたびに、 original.txtから1行読んで全文検索のインデックスを貼る、というのが サンプルのアルゴリズム。

しかし、このoriginal.txtが添付の数行みたいなものであれば問題ないのだが.... 多彩な文字の組み合わせを含むソースだとバカみたいに素片量が増えてしまい、 登録時間もうなぎ登りになってしまうようだ。手元では2ちゃんねるのdatログを 数十個結合したもの差し替えてみた。つまりヘッダありAAありというテキスト行が3万行 くらい続いているわけ。これで全文検索のインデックスを作成すると、 毎回確実に適当な単語が追加されていく。

グラフの横軸は1万件ごと、縦軸は1万件を登録するのにかかった秒数。

ファイルサイズを見てみよう。

-rw-r--r-- 1 root root 125237504 2010-03-23 19:18 testdb.tct
-rw-r--r-- 1 root root    111360 2010-03-23 19:06 testdb.tct.idx.10.dec
-rw-r--r-- 1 root root  23888640 2010-03-23 19:18 testdb.tct.idx.11.dec
-rw-r--r-- 1 root root    111360 2010-03-23 19:06 testdb.tct.idx.2.dec
-rw-r--r-- 1 root root  14170624 2010-03-23 19:18 testdb.tct.idx.3.dec
-rw-r--r-- 1 root root 534364416 2010-03-23 19:18 testdb.tct.idx.6.qgr ※これ！！
-rw-r--r-- 1 root root    111360 2010-03-23 19:06 testdb.tct.idx.7.dec
-rw-r--r-- 1 root root    111360 2010-03-23 19:06 testdb.tct.idx.8.dec
-rw-r--r-- 1 root root    111360 2010-03-23 19:06 testdb.tct.idx.9.dec

これはひどい......... 本文が格納されているであろうtestdb.tctよりはるかにデカイ... 登録時間を一定にするのは難しいんだろうか？？できれば単語の種類の量じゃなくて、 毎回登録する1行のテキストの長さだけに処理量が比例して欲しいんだけど.... でも俺が同じもの作ったらさらに1/100くらい遅いだろうしなあウムム.....

まあ、適材適所というか、Q-GRAMは使わないほうがいいですね。

_ [Linux] Chromeをインストール

そういや世間ではFirefox4が出たようですね。しかしひねくれものは Google Chromeをインストールするのである(今まで使ってなかったのかよ)。いやWindowsでは当然使ってるけど、開発に使ってるマシンはDebian lenny(ちと古い)で面倒だっただけ。

Google本家 からgoogle-chrome-stable_current_amd64.debをダウンロードしてインストール。共有ライブラリの問題などはないようだ....と思ったら

うーんFlashプラグインが動かない。 Chromeは内蔵してるんじゃなかったのか？と思って「設定」／「高度な設定」／「コンテンツの管理」／「プラグインを個別に無効にする」.... 階層深すぎるだろ！ すっきりさせようとして却って面倒になるUIの典型だなあ....まあURLバーに「about:plugins」って入力した方がはえー。

なるほど。Chromeは既存のブラウザ(Firefox, Iceweaselなど)のディレクトリ設定などをひきついでしまうのか。とりあえずふるーいShockwaveFlashプラグインを無効にし、新しいFlashPlayerをインストールすることにする。 Adobe Labsからflashplayer10_2_p3_64bit_linux_111710.tar.gzというのを探して(x64の tar.gz)....

% tar xvzf flashplayer10_2_p3_64bit_linux_111710.tar.gz
% mkdir -p ~/.mozilla/plugins
% cp libfhashplayer.so ~/.mozilla/plugins

でOKでした。