最近の（でもないけれど）出来事／落書帳／仲間内のネタ／覚え書き／whatsnew

基本的に落書き帳／メモ帳／備忘録なので、 わりと間違っていたり、 数分後とか後日とかに見たら、 いきなり消えていたり書き換わっていたりとかあります。

Sat,02 Jul,2011

拡張パーティションにインストールした FreeBSD。
普通のスライスにインストールした FreeBSD を起動する場合は、
MBR → boot1(PBR) → boot2（FreeBSD領域の先頭数クラスタ） → loader（FreeBSD領域の /boot/loader） → kernel（FreeBSD領域の /boot/kernel/kernel）
もしくは
boot0(MBR) → boot1(PBR) → boot2（FreeBSD領域の先頭数クラスタ） → loader（FreeBSD領域の /boot/loader） → kernel（FreeBSD領域の /boot/kernel/kernel）
と言う順序で起動するのだけれども （boot0,boot1,boot2,loader は FreeBSD製の起動チェインローダー、 kernel は FreeBSDのカーネル）。
FreeBSD を 拡張スライス内（05:DOS Extended(CHS) か 0F:DOS ExtendedX(LBA)）の 拡張パーティションにインストールすると、 boot1 が boot2 を読み込むのに失敗して起動しない。
しかも、手元で使っているマシンは D2D 領域絡みの仕様のせいで、
MBR（ソフトウェアは任意） → PBR（MS-Windows7のPBR） → BCD（MS-Windows7の ￥Boot￥BCD） → ……
の部分が固定されてしまう。 さて、ここからどうやって 拡張パーティションにインストールした FreeBSD を起動するか。

まず、GRUB4DOS/GRUB を使った場合。
BCD から GRUB4DOS の MBR/PBR イメージは起動できたのだが。 GRUB4DOS から FreeBSD のパーティションを root (hd0,4,a) しようとすると、 「Cannot mount selected partition」 でこける。 GRUB4DOS のマニュアルによると GRUB4DOS は拡張スライスの？ FreeBSD の UFS2 に対応していないそうな。

GRUB2 を使った場合。
BCD から GRUB2 の MBR/PBR イメージを呼び出すと、 「G UB」みたいな感じの表示が出て GRUB2 の起動に失敗する。
そこで。 BCD → GRUB4DOS の MBR/PBR イメージ → GRUB4DOS 本体、 の順で起動し、 GRUB4DOS から GRUB2 の MBR/PBR イメージを呼び出すとこけたが、 GRUB4DOS から GRUB2 の本体を起動すると、GRUB2 の起動ができた。
そして GRUB2 から FreeBSD領域の UFS2内の /boot/loader を呼び出すと、 ちゃんと FreeBSD loader が起動した。   ここで、FreeBSD 標準の loader の場合、拡張パーティションに非対応なので、 ここまできて起動シーケンスが止まってしまう。

でもここまでくれば、 あとは、FreeBSD の loader を拡張パーティション対応に改造するだけ。
そこで、 [FreeBSD-users-jp 91326] （桂島@横浜 氏、Tue, 1 Jan 2008） の loader 改造パッチを元に、 0F:DOS ExtendedX(LBA) にも対応する様に追加改造してやると、 GRUB2 から loader に移った後、 /boot/kernel/kernel を読み込み、 通常起動シーケンスに入り、無事 FreeBSD が起動した。

結果。
MBR（ソフトウェアは任意） → PBR（MS-Windows7のPBR） → BCD（MS-Windows7の起動ドライブの ￥Boot￥BCD） → GRUB4DOS（起動ドライブの ￥GRUB￥grldr.mbr） → GRUB4DOS（任意のドライブの ￥grldr と ￥menu.lst 、通常は起動ドライブに置く） → GRUB2（GRUB4DOS の menu.lst で指定したディレクトリの grub2 と、grub2 生成時に指定したディレクトリの grub.cfg） → FreeBSD loader（grub.cfg で指定した FreeBSD用拡張パーティションの指定ディレクトリの loader） → FreeBSD kernel
と言う、やたら長いチェインロードになった。   ともかくこれで、拡張パーティションにインストールした FreeBSD が起動する様になった。

Sat,25 Aug,2012に続く。

ノートＰＣ 夏モデル
AS3830T の夏モデルが出ていた。値段は８万円弱するけれど。
昨夏モデル〜今春モデルの AS3820T だと筐体がシルバーだったが、 AS3830T だとメタリックブルー（青から若干紺側に寄った感じの色）だった。 結構印象が変わる。 シルバーも悪いとは言わないけれど平凡。 メタリックブルーは色合いも悪くないしちょっと珍しい感じだし、 いいかんじ……。

Sat,16 Jul,2011 追記：
AS3830T 夏モデル、売り切り価格でも￥69,800-、高いな。 AS3820T 昨夏モデルは店頭展示品処分価格で￥49,800- 行ったのに……。 売り切り価格から店頭展示品処分価格になる段で、 ４段くらい下げないと５万円前後にはならない様な……。

MSI の Gシリーズだとかで、 約９万円弱で 15.6inch FullHD が出ていた……気がする。 web カタログでは見つからない……。 多分、GE620-247JP Core i5-2410M だと思う。

ASUS M53SV-SZ2410B 15.6inch FullHD Core i5-2410M ￥129,800-

SONY VAIO だと EB とか CB とか F だと 15.6〜16.4inch で FullHD、 Core i5系を選択すると７〜12万円くらいになったと思う。 Z も FullHD 可能だが20万円以上に吹っ飛んだと思う。

Wed,06 Jul,2011

５ボタンホイールマウス。
サイドボタン握り潰した orz

Fri,08 Jul,2011

Anthy の設計ミス？
変換する文字列の最後に句読点を入れた場合と入れない場合で、 変換結果が変わる事がしばしば有る。
しかもそういう時に限って、 句読点を入れた場合の方が望まない位置で文節を区切っていたりする。

電池。
電池残量０になってから充電を開始したら、 85％充電した所で「異常を検知したので充電中断」になった。 状況から察するに、 満充電完了している筈の時間が経過したのに 満充電が検出されないので強制切断した、 感じ。
で、使っていたら。
半日使ってもまだ 85％のまま。 85％以上での残量検出が狂ったか、 残量検出その物が狂ったか、 本当に消費電力が少ないのか。 さて……。

鉄道債。
３年 0.38％。 ２年前が 1.0％で、どんどん下がっている。

Sun,10 Jul,2011

原作版 Anthy。
またバグを見つけた。
学習データファイルが巨大でメモリが溢れると SIGSEGV で死ぬ。
と言うよりも、原作版 Anthy で、 メモリ確保の際にメモリ不足のチェックをしている箇所って、 見た事無いのですが。

Fri,15 Jul 2011 追記：
バグの箇所が見つからない。
Anthy は何を思ったのか、 メモリの管理を libc に任せずに自前で行っている （私の憶測に依ると、メモリ解放処理を行わなくても ガーベージコレクトで一挙にメモリ解放処理できる様に、 だと思う。根拠は、メモリ解放処理呼び出しの圧倒的な少なさ。 あとは…… もしかしてメモリのアラインメント調整とかおマヌな事考えてる？）。
で、その回りで、ガーベージコレクトで解放済みのメモリに アクセスしていてこけているらしいのだが、 該当メモリを解放している部分が見つからない。

GRUB2。
GRUB2 が grub.cfg を読み込むと、 大量のエラーを吐いて rescue モードに落ちる。 しかも、大量のエラーを吐いた直後に rescue モードの紹介？表示に移ってしまうので、 どんなエラーを表示しているのだか全く判らない。
３〜４時間かかったが、ようやく内容が判明。
デジカメのムービーモードか連写モードで、 なんとかエラーメッセージの内容を把握。 結果、grub.cfg に書かれている全てのコマンドに対して、 「そんなコマンドは知らん」とエラーを出していた。   で、「そんなコマンドは知らん」になる原因は、 grub-mkimage に記述するモジュールに sh を 入れていなかったせいだった。
grub2 の起動時のモジュールディレクトリに入れておくだけでは 駄目らしい。
そんな事、どこのマニュアルにも web サイトにも 書いていないのだが……。

Sat,01 Sep,2012 追記：
MBR が 1st Track に収まらない（grub.cfg が別スライス／パーティションになる） 事を諦めて GRUB2 を MBR に入れる場合は以下の通り。

# /usr/local/bin/grub-mkimage -p /grub -o grub2 sh search ls acpi boot chain configfile echo help minicmd normal biosdisk ufs1 ufs2 fat ntfs ext2 part_msdos bsd linux reboot sleep halt
# grub-mkimage -p /grub -o grub2 sh boot configfile echo help minicmd normal biosdisk ntfs part_msdos
/usr/local/bin/grub-mkimage -p "(hd0,2)/grub" -o grub2 sh search ls acpi boot chain configfile echo help minicmd normal biosdisk ufs1 ufs2 fat ntfs ext2 part_msdos bsd linux reboot sleep halt
sudo cp -p grub2 /boot/grub/core.grub2.img
sudo /usr/local/sbin/grub-setup -c core.grub2.img --directory=/boot/grub --device-map=/boot/grub/device.map /dev/ada0

#
# grub.cfg
#

set root='(hd0,2)'
set menu_color_normal=white/black
set menu_color_highlight=white/green

set default="0"
set timeout=8

if [ -s $prefix/grubenv ]; then
  load_env
fi

menuentry "MS-Windows7" --class mswindows --class os {
        echo Loading MS-Windows7 ...
        insmod chain
        insmod fat
        insmod ntfs
        insmod part_msdos
        set root='(hd0,2)'
        chainloader +1
}

menuentry "FreeBSD" --class freebsd --class bsd --class os {
        echo Loading loader of FreeBSD ...
        insmod bsd
        insmod ufs1
        insmod ufs2
        set root='(hd0,5,a)'
        set kFreeBSD.vfs.root.mountfrom=ufs:/dev/ad4s5a
        set kFreeBSD.vfs.root.mountfrom.options=rw
        kfreebsd /boot/loader
}

menuentry "Debian GNU/Linux" --class debian --class gnu-linux --class linux --class os {
        echo Loading loader of Debian GNU/Linux ...
        insmod linux
        insmod ext2
        insmod xfs
        insmod jfs
        insmod reiserfs
        set root='(hd0,6)'
        linux /vmlinuz root=/dev/sda6 ro acpi_osi=Linux
        initrd /initrd.img
}

menuentry "Debian GNU/Linux (single)" --class debian --class gnu-linux --class linux --class os {
        echo Loading loader of Debian GNU/Linux (single)...
        insmod linux
        insmod ext2
        insmod xfs
        insmod jfs
        insmod reiserfs
        set root='(hd0,6)'
        linux /vmlinuz root=/dev/sda6 ro single acpi_osi=Linux
        initrd /initrd.img
}

menuentry "reboot" {
        echo Reboot ...
        insmod reboot
        reboot
}

menuentry "sleep" {
        echo Sleep ...
        insmod sleep
        sleep
}

menuentry "halt" {
        echo Halt ...
        insmod halt
        halt
}

# [ End of File ]

#
# GRUB4DOS menu.lst
#

timeout 3
default 0

# GRUB2
title GRUB2
root (hd0,1)
kernel /GRUB/grub2

# FreeBSD
title FreeBSD
root (hd0,4,a)
kernel /boot/loader

# Debian GNU/Linux
title Debian GNU/Linux
root (hd0,5)
kernel /vmlinuz root=/dev/sda6 ro acpi_osi=Linux
initrd /initrd.img

# Debian GNU/Linux (single)
title Debian GNU/Linux (single)
root (hd0,5)
kernel /vmlinuz root=/dev/sda6 ro single acpi_osi=Linux
initrd /initrd.img

# MS-Windows
title MS-Windows 7
root (hd0,1)
chainloader +1

# Floppy
title Floppy
root (fd0)
chainloader +1

# Reboot
title Reboot
reboot

# Halt
title Halt
halt

# [ End of File ]

Thu,14 Jul,2011

FreeBSD 8.2-RELEASE/amd64 で alc (Atheros AR8131/AR8132 Gigabit/Fast Ethernet driver) が不安定。
1000baseTX や 100baseTX（全二重／半二重とわず）にすると、 相当な高確率でカーネルレベルでフリーズを起こす。
hw.alc.msi_disable="1" や hw.alc.msix_disable="1" でも駄目。
試行錯誤した結果、10baseT/UTP（全二重／半二重とわず）にすると、 取り敢えず安定して動作する事が判った。
最終段の回線速度を 上流側回線速度より遅くしないといけなのは嫌だなぁ……。 でもノートＰＣだから NIC の交換はできないし……。

MSIって何じゃらほい？
Message Signal Interrupts の略らしい。

10Mbps にしなくても、

にしたら、安定したっぽい。どれか１つでも欠けると駄目。 様子見中。

Sat,16 Jul,2011 追記：
やっぱり駄目だった。 10Mbps にしても MSI を無効にしても、 数時間に１回くらいのペースでフリーズを起こす。

Sun,17 Jul,2011 追記：
仕方がないので、 RELENG_8_2 から RELENG_8 へのバージョンアップを試してみる。

Mon,18 Jul,2011 追記：
今の所、RELENG_8 で安定して動作している。様子見中。

Fri,16 Sep,2011 追記：
あれからずっと、安定動作している。 RELENG_8_2 以降にバグ修正でも入っていたのかな。

acer TimeLineX の珍しい？機能。
店頭デモをいじってみた感じでは、 他の機種や他のメーカーでも搭載しているみたいだけれど。
電気製品は大抵、時間を空けずに 電源 OFF/ON を行うと、 負担がかかってまぁチマチマと悪影響が出る。
で、acer TimeLineX の電源スイッチは、 前回の操作から約５秒以内に操作を行うと、 約５秒経過してから操作が実行される。 嫌でも 電源 OFF/ON 時に時間を空ける様になっている。 個人的には、こう言う機能は初めて見た……。

Sat,16 Jul,2011

各種計算機のベンチマーク結果 を更新。
Core i5-450M にて、 gcc の最適化オプションを色々いじった nbench の結果を追加。
結論だけ言うと、

ホビーショップ。
web で、とある商品の取り扱いのある店舗を 製造メーカーの取り扱い店舗一覧から検索、 とある地帯に４軒有るのを見つけたので行ってみた。
……最初の２軒までは有ったが、残り２軒は見つからなかった。   web で検索した結果、 ３軒目は３年前に撤退閉店、 ４軒目は１年半前に移転していて、 移転先が今回目を付けていたうちの１軒目だった。
ちゃんと更新してよね……。

Sun,17 Jul,2011

アゲハ蝶、ポルノグラフティ、2001.6.27。
サヨナラ、GAO、1992.4.21。

Thu,21 Jul,2011

Firefox の tab_mix_plus 3.8.5以降。
tab_mix_plus の 3.8.4 までは、 通常時はタブのプログレスメーターは非表示で、 読み込み時のみ表示されていた。   が、3.8.5 からは、常時プログレスメーター表示になってしまった。
好みに合わないので修正。   chrome/userChrome.css か stylish にて、 

@namespace url(http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul);

.tabbrowser-tab:not([busy=true]) .tab-text-stack < .tab-progress {
  display: none !important;
}

指定すればよいらしい。

Fri,22 Jul,2011

uim-1.7.0
FreeBSD 8.2-RELEASE/i386 だと bridge-show-with? 'mode が効くのに、 FreeBSD 8-STABLE/amd64 だと bridge-show-with? 'mode が効かず、 常に表示しっ放しになる……。 困った……。
試しに、

/usr/ports/textproc/uim/work/uim-1.7.0/xim/ximserver.cpp の 
void InputContext::update_prop_list(const char *str)
にて 
fprintf(stderr,"bridge:%d,%d,%d\n",show_caret_state,show_caret_mode,show_caret_mode_on);
してみたら、常時 
bridge:1,1,1
になっていた。 試しに action.scm の context-propagate-prop-list-update の 
(if (eq? (context-current-mode context) 0)
              (set! bridge-show-input-state-mode-on? #f)
              (set! bridge-show-input-state-mode-on? #t)))
を 
(if (eq? (context-current-mode context) 0)
              (set! bridge-show-input-state-mode-on? #t)
              (set! bridge-show-input-state-mode-on? #f)))
してみたら、常時 
bridge:1,1,0
になっていた。 駄目じゃん。 でも何が駄目なのだろう？ if ……がおかしいならもっと広範囲に被害が出るだろうから、 context-current-mode か context かなぁ？

xorg-7.5
7.4系から 7.5系に更新したら、 fvwm が日本語 TrueType フォント同梱のビットマップフォント部分を 認識しなくなった。 単体のビットマップフォントは認識するのだが……。
GTK/Qt 辺りは同梱ビットマップを認識しているみたいだけれど。 認識しなくなったのは Xaw 辺りなのかなぁ？
仕方がないので、 単体のビットマップフォントにバラして使っているけれど……。

X で HD/HD+/FullHD とか Intel HD とか。
1366x768 にする方法が判らん。 915resolution は、そんなチップ知らん、と言ってくる。 Intel HD を使う方法も判らん。 vesa で表示はできるが、 1024x768 を横に引き伸ばした状態になってしまう……。
Fedora GNU/Linux とか Ubuntu GNU/Linux 辺りは対応したけれども、 BSD系はまだらしい。

Wed,27 Jul,2011 追記：
GNU/Linux では Intel が直々に Linux用 Intel HD対応カーネルドライバを 作って公開しているから、対応が早いらしい。
OpenBSD は有志が突貫して対応したらしいが、 英語情報しかなくてよく判らん。
FreeBSD は有志が Linux用 Intelドライバを移植しているらしい。 Intel_GPU - FreeBSD Wiki。 英語で必要最低限しか書いていない……。 どうやら FreeBSD HEAD/amd64 に更新しないと使えないパッチらしい。 今 FreeBSD HEAD 行くと、9-CURRENT系になっちゃう様な気が……。

acer ASPIRE 3820T-N52B の Inltel HD Graphics な HD LCD を FreeBSD から使う話は Wed,03 Aug,2011、 Thu,04 Aug,2011、 Thu,11 Aug,2011、 Fri,18 Nov,2011、 Sat,28 Jan,2012、 Thu,31 May,2012、 に続く。

死にかけだったディスプレイ。
今までは何とか使えていたが、 今週頭頃から遂に駄目になった。 黒地に白文字を表示すると白縁取りの黒文字に、 黒地に青文字を表示すると青縁取りの白文字に、 黒地に水色文字を表示すると水色縁取りの白文字に、 黒地に黄色文字を表示すると黄色縁取りの白文字に、 白地に黒文字を表示するとにじんだ黒文字に、 白地に黄色文字や水色文字を表示するとそのまま表示、 灰色地に黒文字を表示するとちらつく黒文字に、 白色のベタはそのまま問題無く、 黒色のベタもそのまま問題無く、 灰色のベタは白黒のスノーノイズが入る。 よくわからん法則性だ……。

Sun,24 Jul,2011

ImageMagick 6.7
6.6系から6.7系に更新したら、 複数ファイル閲覧の際に「[scene: 0 frames: 0 ]」とか表示されて、 次画像閲覧すると「[scene: 0 frames: 1 ]」と表示が変わるけれど 表示されている画像は変わらず、 もう一度 次画像閲覧すると「[scene: 1 frames: 1 ]」と表示が変わって ようやく次画像の閲覧になる。
そこからさらに 次画像閲覧すると「[scene: 0 frames: 2 ]」と表示が変わって また先頭画像の閲覧になってしまい、 次画像閲覧すると「[scene: 1 frames: 2 ]」で２枚目、 次画像閲覧すると「[scene: 2 frames: 2 ]」で３枚目、 次画像閲覧すると「[scene: 0 frames: 3 ]」でまた先頭、 になってしまう。
どうやって切るのだろう、この機能。

自転車がパンク。
前回のパンク修理時に、 寿命の近づいた後輪タイヤと長い事使っていたチューブを前輪にまわし、 後輪には国産一流品タイヤと 1.5倍厚チューブを付けていたのだが。
その寿命の近づいていたタイヤが遂に駄目になった。 その影響で、チューブが直接地面に擦れてしまい、 パンクした。
と言う訳で、 前輪を国産二流品（三流品？）タイヤと 1.5倍厚チューブに交換した。 前輪なら後輪ほど負荷がかからないだろうから ランクを下げて安くしてみた。

Tue,26 Jul,2011

ばったり出合う。
閉店時間間際の家電量販店の模型コーナーでばったり。
HG GM CANNON II は店頭在庫がわりとコンスタントに２山有るけれど （減ったり増えたりしているから、売れて追加して、だと思う）、 HG GM III は先々週くらいまで４山くらい有った在庫が 全く無くなっていた上に、在庫補充がされていなかった。
そんなに売れるの速いのかねぇ。
HG GM CUSTOM や HG GM改 も１〜２ヶ月くらいのスパンで 在庫補充がされていない気がする。 売り切れたまま……。
旧ＡＷシリーズのガンダムＸ系の 1/144 が、先々週だか１ヶ月だか前に、 唐突に少量ずつだが在庫補充がされていた。 旧ＡＷシリーズの 1/100 は全く無し。

Sat,30 Jul,2011

ほたる。
平家蛍（糠蛍：ぬかほたる）の写真を撮ってみた。
真っ黒の中に、緑色の小さい丸、に、なっただけだった。

Anthy のブートストラップ用学習データ。
配布用パッケージに単に同梱するだけにとどめるか、 インストール時／初起動時に個人用学習データの先頭に自動的に追加するか、 辞書データとして組み込むか。
考え中。
そういう意味で、暫定版。
今までは、同梱するだけか、先頭に追加するだけか、で 考えていたけれど、 今は、システムの複合語辞書に追加してしまう案に傾き中。

Wed,03 Aug,2011

acer ASPIRE 3820T-N52B の Inltel HD Graphics な HD LCD を FreeBSD から使う話は Fri,22 Jul,2011、 の続き。 Thu,04 Aug,2011、 Thu,11 Aug,2011、 Fri,18 Nov,2011、 Sat,28 Jan,2012、 Thu,31 May,2012、 に続く。

Debian 6.0.2.1 GNU/Linux/amd64 2.6.32-5
本当に 1366x768 で映るか試してみた。 あわよくば VMWare 母艦にして FreeBSD と MS-Windows を同時起動とか。
web の案内にしたがってインストール用 DVD 作って、 起動してインストーラに従ってポチポチ操作したら、 あっさりインストール完了、 但し時間はやたらかかって、確か３時間はかかったと思う。 この辺のインストールの簡単さは BSD系は敵わないねぇ。 せいぜい Dragonfly BSD だっけ？ PC-BSD だっけ？ でもまぁ、用途やユーザ層が違うから敵う必要性も無いと思うけれど。
で、インストール中も、インストール完了後も、 何も設定せずにあっさり 1366x768 で表示された。
そこまでは良かったのだけれども。
GUI なパッケージマネージャを使って、 インストール済のパッケージを削除しようとしても受け付けない、 パッケージの依存関係は問題無さそうなのに。 未インストールのパッケージをインストールしようとすると、 受け付けたり受け付けなかったり。 わけが判らん。
しかも、標準でインストール可能なパッケージに、 Firefox が無いとか、vim が無いとか、kterm が無いとか、 tcsh が無いとか、ksh が無いとか uim-xim が無いとか、 BSD系から来た人には非常に辛い環境だった。 サイト追加しないといけないんだっけ？ Ubuntu 行ってみるか……。

↑ package.debian.org からパッケージを 直接検索してみたら、ちゃんと有るし……。

↑ Synaptics パッケージマネージャを使ったら、 ちゃんと削除もインストールもできた。 なんなんだよ……。

Ubuntu 11.04/10.04LTS GNU/Linux/amd64 2.6.32-33
本当に 1366x768 で映るか試してみた、その２。 web の案内にしたがってインストール用 CD 作って、 起動してインストーラに従ってポチポチ操作していたら、 インストーラーがフリーズ。 カーネルは生きているけど何にも操作を受け付けないので、 仕方なくリブート。
どうやら、 起動して直にインストーラを起動して、 「標準設定から変更する為のダイアログ表示」を行うと、 インストーラがフリーズするらしい。 既知バグか？ 未知バグか？ どちらにせよ、使い物にならない。
試しにライブで起動してみたら、ライブは問題無く動く。 さらに試しに、ライブからインストーラを動かしてみたら、 問題無く動いた。 インストールパーティションの手動設定とか、 ファイルシステムの変更とか、 全く問題無くできた。
なんなんだ、一体……。 変な所で完成度が低いなぁ。

↑ インストール後に GNOME を使っていたら、 突然マウスのクリックを受け付けなくなる事態が頻発。 起動して直にインストーラを起動した時の操作を受け付けなくなるのと、 ほぼ同じ状況。
全く使い物になりません。
Ubuntu 削除して Debian に戻した。

Thu,04 Aug,2011

acer ASPIRE 3820T-N52B の Inltel HD Graphics な HD LCD を FreeBSD から使う話は Fri,22 Jul,2011、 Wed,03 Aug,2011、 の続き。 Thu,11 Aug,2011、 Fri,18 Nov,2011、 Sat,28 Jan,2012、 Thu,31 May,2012、 に続く。

FreeBSD/amd64 8-STABLE & 9-CURRENT-HEAD
トチって、 カーネルは 8-STABLE、 ユーザランドは 9-CURRENT(HEAD)、 と言う状態にしてしまった。
Firefox 等の sem カーネルモジュールを使用するアプリケーションが、 sem_init した時にクラッシュする様になってしまった。
何とかしてカーネルを 9-CURRENT(HEAD) に更新しないと……。

結局、9-CURRENT(HEAD)用 Intel HD graphics 対応パッチは、 正常動作しなかった。 ブラックアウトして、暫くしてカーネルフリーズ。 うーん、作者の所では動いているだろうに、何でだろう。

８月２〜３日頃以降の 9-CURRENT(HEAD)、 なんかファイルロック回り？にバグがあって クラッシュしてデバッガに落ちる……。 ８月１日０時０分版なら大丈夫だった。

追記：
１週間くらいしたら修正されて治っていた。

Sat,06 Aug,2011

救急車の緊急走行。
緊急走行中の救急車を先頭に、十数台の車が数珠つなぎになっていた。 ……。 全車、20km速度超過だろ、それは……。

Tue,09 Aug,2011

FreeBSD/amd64 9-CURRENT-HEAD
またなんかトチったら、こんどは lo0 が消えて、 127.0.0.1 に bind や connect ができなくなった。 なにやったらこんなんなるのだろう……。

qemu にて、VMWare Player用の vmdkディスクイメージを マウントして FreeBSD をゲストで動かす。
vmdk の実占有領域を越える瞬間に、 

g_vfs_done():ada1s1a[WRITE(offset=2109177856, length=131072)]error = 5
とかエラー出してくる。 しかも、そのタイミングが悪いと、本当にファイルが壊れる。 なんなんだよ、一体……。

Wed,10 Aug,2011

qemu で VMWare Player の vmdk を マウントして FreeBSD をゲストで動かす。
なんとか起動ディスクが完成した。 無駄に疲れた……。

Thu,11 Aug,2011

acer ASPIRE 3820T-N52B の Inltel HD Graphics な HD LCD を FreeBSD から使う話は Fri,22 Jul,2011、 Wed,03 Aug,2011、 Thu,04 Aug,2011、 の続き。 Fri,18 Nov,2011、 Sat,28 Jan,2012、 Thu,31 May,2012、 に続く。

FreeBSD/amd64-9-CURRENT(HEAD) on VMPlayer-3.1.4-build-385536 in Debian-6.0.2.1 GNU/Linux-2.6.32-5。
今までネイティブの FreeBSD が Intel HD Graphics未対応な為に 強制 1024x768 表示の、1366x768 強制伸展で表示されていたけれど、 VMPlayer vesaドライバで 1366x768 ネイティブになった。 VMPlayer vmwareドライバだと、何故か 800x600 固定だった。
横伸展に慣れてしまったせいで何もかもが縦長に見える……。
あと、 ネイティブの FreeBSD 起動は１分弱程度だった所が、 Debian 起動 → VMPlayer 起動 → FreeBSD 起動、で、 活動可能になるまで２〜３分程度かかる様になってしまった。 gdm/GNOME 切って fvwm2 で作りなおした方が良いかなぁ？ それとも FreeBSD-9.x-RELEASE で Intel HD Graphics対応するまでの つなぎと割り切って諦めるか。

起動所要時間。
FreeBSD on 実機：起動：40秒。
FreeBSD on 実機：ログイン & X起動：15秒。
FreeBSD on 実機：シャットダウン：15秒。
FreeBSD on VMPlayer：起動：45秒。
FreeBSD on VMPlayer：ログイン & X起動：10秒。
FreeBSD on VMPlayer：シャットダウン：10秒。
Debian on 実機：起動 & gdm3起動：40秒。
Debian on 実機：ログイン & GNOME起動：15秒。
Debian on 実機：ハイバネーション：25秒。
Debian on 実機：ハイバネーション復帰：25秒。
Debian on 実機：シャットダウン：15秒。

VMWare ゲストOS で５ボタンホイールUSBマウスを使う。
これが一番苦労した。
結論：VMWare は３ボタンホイールマウスまでしか対応していない。
対処法：VMPlayer でゲストOS を起動後にマウスを抜き挿しし直して、 単なる USB デバイスとしてホストOS と VMWare に認識させて、 ホストOS と VMWare にマウスとしての認識をスルーさせ、 ゲストOS に USBマウスとして認識させて使う。
副作用：ホストOS で USBマウスが使えない。
副作用の対処法：マウスを２個挿して、 １個をホスト用、１個をゲスト用、にしてしまう。 ノートPC だとタッチパッドが付いているので、 タッチパッドをホスト用、外付けマウスをゲスト用にしてしまう。
副作用その２：VMWare を起動し直す毎に（ハイバネーション復帰も含む） USBマウスを抜き差ししなければならない。
副作用その２の対処法：未だ不明。

VMWare ゲストOS で物理HDD を直接マウントする。
これが二番目に苦労した。
結論：GNU/Linux だと物理HDD へのアクセス権を VMPlayer に与える事が出来ない （/usr/lib/vmware/bin/* 辺りを chown root:disk して chmod u+s とか chmod g+s では駄目だった）。 なので、ゲストOS でもアクセス権が取得できない。
対処法：sudo でルート権限で実行してしまう。
副作用：なんというか、 OS のアクセス権の設計の考え方が間違っていると思うが？ あと、ゲストOS のデータ一式が ~root/vmware/ 以下に行ってしまう。

Mon,15 Aug,2011

ゴーフルかと思ったらゴルシア。
外見はまんまパクリ。 味や食感は……違いが判るほど敏感じゃないし。 取り敢えず、ゴルシアの方が微妙に固くて クリームの匂いと油っけが強い気がする。

Tue,16 Aug,2011

Linux の NICドライバ。
GNU/Linux の間違いじゃないよ。
急にネットワークが死んだと思ったら、 Linuxの NICドライバが死んでいた。
対処法は、NICドライバを rmmod して modprobe しなおす。

OpenBSD の man。
OpenBSD の man を見ていたら。 pthread_condattr_init() と pthread_condattr_destroy() の man が無かった。 OpenBSD で man が欠落なんて珍しい……。

ETF の受益者番号（株主番号）。
2009年に 100株の権利を取って、 2010年は権利を取らず、 2011年に今度は 200株の権利を取ったら、 2009年と同じ株主番号が割り当てられていた。
権利取りに間を開けたり、再取得時に株数が変わったり、しても、 株主番号が変わらない事も有るのね。

Thu,18 Aug,2011

realloc()。
realloc() すると、 アドレスが変わる場合が有る事を忘れてポインタを使ってしまった……。 痛い……。

Anthy にダイクストラ法による双方向探索の文節数最小法を実装してみた。
Tue,28 Sep,2010、 Sun,05 Dec,2010 の続き。

デュアルコア用双方向ダイクストラ法による MBR アルゴリズムを 実装する為の叩き台として、 デュアルコア用ダイクストラ法による双方向探索を用いた 文節数最小法を実装してみた。
左から右への探索は爆速なのだけれども、 右から左への探索が 100倍くらい遅くなった。
原因は、 Anthy の辞書探索部が生成する文節候補リストが、左揃えになっている為。 右から左へ探索する為に、文節区切り位置を探索しながら 左揃えの文節候補リストを右揃えの文節候補リストに変換するのに 無茶苦茶時間を食っている。
と言う訳で、 デュアルコア用双方向探索 MBRダイクストラ法を実装しても、 単純に４倍速にはまるで届かない事が判明。 感触としては、探索アルゴリズムを 「ビタビもどき」から「ダイクストラ法」に変える事による 探索速度の変化（速くなるか遅くなるかは不明）しか得られない模様。   あるいは、変換当初に 左揃えの文節候補リストを右揃えの文節候補リストに変換してしまえば、 探索時間自体は４倍速にはなるけれども、 それで速くなった分より文節候補リストの変換で遅くなった分の方が大きそうだ。   何か一気にモチベーション下がったなぁ……。

Sat,20 Aug,2011、 Mon,22 Aug,2011、 Wed,24 Aug,2011、 Thu,25 Aug,2011 に続く。

Fri,19 Aug,2011

acer ASPIRE 3820T-N52B の内蔵HDD に、 Debian の hdparam とか noflushd とか。
何か HDD の回転音が変なので smartctl で S.M.A.R.T. を見てみたら、 Start_Stop_Count が６万近くとか言うとんでもない値を指していて、 冷や汗物。
hdparam のデフォルト設定を見たら、24秒で HDD 停止とかなっていた。 で、GNU/Linux の syncer が 30秒毎に HDD にアクセスに行っていて、 停止−回転−停止−回転の無限ループをやらかしていた……。 30秒６万回だと 500時間くらい、まぁそんなもんでしょう。
試しに noflushd を入れたが、30秒毎アクセスは止まらなかったので、 速攻 purge。
hdparam で 15分とか off とかに設定してみても、 4〜25秒で HDD が止まるのは変わらず。 hdparam が効いていない。
仕方がないので、 shell script で３秒毎に sync かましたら、 何とか HDD の回転停止が止まった。
さて、３秒毎にアクセスするのと、 30秒サイクルで停止−回転するのと、 どっちがマシなのだろう？

Sat,20 Aug,2011 追記：
見る所を間違えていた。Load_Cycle_Count だ。 で、28万回……もっとヤバい……。
積まれている HDD は Western Digital Scorpio Blue Serial ATA WDC WD2500BEVT-22A23T0。
wdidle3 /R で見てみたら、 Intelli Park が４秒とか設定されていた……。 wdidle3 で /S0 とか /S300 とか /S60 とか /D とか色々試してみたが、 全く効果無し。 wdidle3 /R の表示は変化するけれども、相変わらず４秒でスピンダウンする。   あと ver1.03 だと、 /D すると30分くらいの設定になってしまい、/S0 すると無効化になっていた。 ver1.05 では治っていて、/D で無効化、/S0 はエラー、になっていた。

Fri,02 Sep,2011 追記：
GNU/Linux の場合、３秒毎に sync かますと、 前回の sync 以降にディスクへの書き込みが無い場合 （当然 noatime 付き）でも、 必ず HDD へアクセスをするので（理由は不明）４秒停止が先送りされるが、 ネイティブの FreeBSD の場合、３秒毎に sync かましても、 前回の sync 以降にディスク書き込みが無かった場合には HDD へのアクセスを行わず、４秒目で HDD が停止してしまった。
３秒毎に書き込みを行わないと駄目らしい。   書き込みと言っても、 

#!/bin/sh --
while clear
do
TMPFILE=`/usr/bin/mktmp /var/tmp/unpark.XXXXX`
/bin/rm ${TMPFILE}
/bin/sync
/bin/sleep 3
done
の様に、ファイルを作って消すだけで OK。 ファイルに書き込みを行う必要は無し。 sync は必須で、これが無いと、 30秒毎の syncer がやって来るまで HDDアクセスが行われず、 ４秒停止が発生してしまう。

Sat,20 Aug,2011

Anthy で文節数最小法。
Tue,28 Sep,2010、 Sun,05 Dec,2010、 Thu,18 Aug,2011 の続き。

２点、誤りに気付いた。
まず。 文節数最小法だとヒューリスティックを得る事が出来るので、 Dijkstra法より段違いに速い A* が使える事を 見落としていた。
Fri,26 Aug,2011 追記：ヒューリスティックを求める事ができないので A* は使えない。
それから。 左から右へトライ探索中に文節候補のテーブルを生成する場合と、 左から右へトライ探索を開始する前に 文節候補の直角二等辺三角形の格子状テーブル化する場合で、 計算量のオーダーは同じかもしれない。   さらに。 右から左へトライ探索中に文節候補のテーブルを生成する場合と、 右から左へトライ探索を開始する前に 文節候補の直角二等辺三角形の格子状テーブル化する場合で、 計算量のオーダーは O(n^3) から O(n^2) へ 高速化するのを見落としていた。   ついでに。 文節候補の格子状テーブル化の際に、 メニイコア対応のコードを思い付いた。

取り敢えず、ベンチマークを取ってみる。
Fri,03 Sep,2010 に関連。
学習再生／学習記録、共に無効。 変換内容は毎度お馴染み JNetHack の占いクッキーの先頭100文。

かな漢字変換ソフトの変換結果ベンチマークテスト
系列 モード 文節区切りの誤答数 文節区切り正答中の変換候補誤答数変換所要時間うち文節区切り所要時間

実験版(patch13-testing)MBRビタビ(HID_IDI_IwDT) 5.25 [秒] 3.42 [秒]
実験版(patch13-testing)MBRビタビ(HID_IDI_IwDT) ※ 5.20 [秒] 3.39 [秒]

実験版(patch13-testing)前方３文節最長一致 1.71 [秒] 0.10 [秒]
実験版(patch13-testing)前方３文節最長一致 ※ 1.66 [秒] 0.10 [秒]

開発中版 文節数最小 ダイクストラ 左→右方向 41 14 20.45 [秒] 18.68 [秒]
開発中版 文節数最小 ダイクストラ 左→右方向 ※ 40 14 1.81 [秒] 0.06 [秒]
開発中版 文節数最小 ダイクストラ 右→左方向 41 14 71.20 [秒] 69.40 [秒]
開発中版 文節数最小 ダイクストラ 右→左方向 ※ 40 14 2.69 [秒] 0.94 [秒]
開発中版 文節数最小 ダイクストラ 双方向デュアルコア 92 5 4.66 [秒] 1.98 [秒]
開発中版 文節数最小 ダイクストラ 双方向デュアルコア※ 91 5 2.67 [秒] 0.06 [秒]

開発中版 文節数最小 A* 左→右方向 41 14 1.87 [秒] 0.006 [秒]
開発中版 文節数最小 A* 左→右方向 ※ 40 14 1.84 [秒] 0.006 [秒]
開発中版 文節数最小 A* 右→左方向 41 14 1.64 [秒] 0.007 [秒]
開発中版 文節数最小 A* 右→左方向 ※ 40 14 1.59 [秒] 0.007 [秒]
開発中版 文節数最小 A* 双方向デュアルコア 92 5 1.74 [秒] 0.008 [秒]
開発中版 文節数最小 A* 双方向デュアルコア ※ 91 5 1.69 [秒] 0.008 [秒]

※ 入力から 「金の損失、些細な損失。名誉の損失、多大な損失。騙されて損失、すっからかん」 （１６文節）を削除。何故これがやたら時間を食うのかは不明。 どうやら、他の文章は８〜10文節で納まっているが、 この１文だけ飛び抜けて文節数が多いらしい。
どうも、双方向は、左右からの探索を連結する部分にバグが有るらしい。
文節区切り所要時間以外の所要時間が変動している理由は不明。

文節数最小は爆速なのは良いのだけれども、 変換成績が悪いのと、文節数が増えると急激に遅くなるのが……。
Fri,28 Aug,2011 追記：枝刈りを忘れていたせいだった。

Wed,21 Sep,2011 追記：
OpenBSD にて pthread を使った場合、 複数スレッドを１コアで交互に実行していた。 なので、 双方向デュアルコアは間違いで、 双方向シングルコア状態になっていた。 理由・対処法は今の所不明。

マルチスレッド／マルチプロセスの話は、 Wed,21 Sep,2011、 Thu,22 Sep,2011、 Fri,23 Sep,2011、 Sun,25 Sep,2011、 に続く。

Mon,22 Aug,2011

Anthy で文節数最小法。
とりあえず、処理状況の解析。 

変換内容：「たとえばこんなぶんしょう」
アルゴリズム：文節数最小（文節位置補正付き）、ダイクストラ
※ ヒープなので第１候補は先頭に来るが、２番目以降の並び順は意味が無いので注意。

第１ターン：
    (0)[START]

第２ターン：
    (0)[START] →[たとえば]→(9996)4
               →[たとえ]→(9997)2
               →[た]→(9999)3
               →[たと]→(9998)1

第３ターン：
    (0)[START] →[たとえ]→(9997)2
               →[たと]→(9998)1
               →[た]→(9999)3
               →[たとえば]→(9996)4 →[こ]→(19991)5
               →[たとえば]→(9996)4 →[こん]→(19990)6
               →[たとえば]→(9996)4 →[こんな]→(19989)7

第４ターン：
    (0)[START] →[たと]→(9998)1
               →[たとえば]→(9996)4 →[こんな]→(19989)7
               →[た]→(9999)3
               →[たとえば]→(9996)4 →[こ]→(19991)5
               →[たとえば]→(9996)4 →[こん]→(19990)6
               →[たとえ]→(9997)2 →[ば]→(19993)8
               →[たとえ]→(9997)2 →[ばこ]→(19992)9
               →[たとえ]→(9997)2 →[ばこん]→(19991)10

第５ターン：
    (0)[START] →[た]→(9999)3
               →[たとえば]→(9996)4 →[こんな]→(19989)7
               →[たとえ]→(9997)2 →[ばこん]→(19991)10
               →[たとえば]→(9996)4 →[こ]→(19991)5
               →[たとえば]→(9996)4 →[こん]→(19990)6
               →[たとえ]→(9997)2 →[ば]→(19993)8
               →[たとえ]→(9997)2 →[ばこ]→(19992)9
               →[たと]→(9998)1 →[え]→(19995)11
               →[たと]→(9998)1 →[えば]→(19994)12

第６ターン：
    (0)[START] →[たとえば]→(9996)4 →[こんな]→(19989)7
               →[たとえば]→(9996)4 →[こん]→(19990)6
               →[たとえ]→(9997)2 →[ばこん]→(19991)10
               →[たとえば]→(9996)4 →[こ]→(19991)5
               →[たと]→(9998)1 →[えば]→(19994)12
               →[たとえ]→(9997)2 →[ば]→(19993)8
               →[たとえ]→(9997)2 →[ばこ]→(19992)9
               →[たと]→(9998)1 →[え]→(19995)11
               →[た]→(9999)3 →[と]→(19997)13
               →[た]→(9999)3 →[とえば]→(19995)14
               →[た]→(9999)3 →[とえ]→(19996)15

第７ターン：
    (0)[START] →[たとえば]→(9996)4 →[こん]→(19990)6
               →[たとえば]→(9996)4 →[こ]→(19991)5
               →[たとえ]→(9997)2 →[ばこん]→(19991)10
               →[たと]→(9998)1 →[え]→(19995)11
               →[たと]→(9998)1 →[えば]→(19994)12
               →[たとえ]→(9997)2 →[ば]→(19993)8
               →[たとえ]→(9997)2 →[ばこ]→(19992)9
               →[た]→(9999)3 →[とえ]→(19996)15
               →[た]→(9999)3 →[と]→(19997)13
               →[た]→(9999)3 →[とえば]→(19995)14
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんしょ]→(29978)16
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶ]→(29981)17
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶん]→(29980)18
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんし]→(29979)19
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんしょう]→(29977)20

第８ターン：
    (0)[START] →[たとえば]→(9996)4 →[こ]→(19991)5
               →[たと]→(9998)1 →[えば]→(19994)12
               →[たとえ]→(9997)2 →[ばこん]→(19991)10
               →[たと]→(9998)1 →[え]→(19995)11
               →[た]→(9999)3 →[とえば]→(19995)14
               →[たとえ]→(9997)2 →[ば]→(19993)8
               →[たとえ]→(9997)2 →[ばこ]→(19992)9
               →[た]→(9999)3 →[とえ]→(19996)15
               →[た]→(9999)3 →[と]→(19997)13
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんしょう]→(29977)20
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんしょ]→(29978)16
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶ]→(29981)17
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶん]→(29980)18
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんし]→(29979)19
               →[たとえば]→(9996)4 →[こん]→(19990)6 →[な]→(29983)21

第９ターン：
    (0)[START] →[たとえ]→(9997)2 →[ばこん]→(19991)10
               →[たと]→(9998)1 →[えば]→(19994)12
               →[たとえ]→(9997)2 →[ばこ]→(19992)9
               →[たと]→(9998)1 →[え]→(19995)11
               →[た]→(9999)3 →[とえば]→(19995)14
               →[たとえ]→(9997)2 →[ば]→(19993)8
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんし]→(29979)19
               →[た]→(9999)3 →[とえ]→(19996)15
               →[た]→(9999)3 →[と]→(19997)13
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんしょう]→(29977)20
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんしょ]→(29978)16
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶ]→(29981)17
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶん]→(29980)18
               →[たとえば]→(9996)4 →[こん]→(19990)6 →[な]→(29983)21
               →[たとえば]→(9996)4 →[こ]→(19991)5 →[ん]→(29985)22

第10ターン：
    (0)[START] →[たとえ]→(9997)2 →[ばこ]→(19992)9
               →[たと]→(9998)1 →[えば]→(19994)12
               →[たとえ]→(9997)2 →[ば]→(19993)8
               →[たと]→(9998)1 →[え]→(19995)11
               →[た]→(9999)3 →[とえば]→(19995)14
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶん]→(29980)18
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんし]→(29979)19
               →[た]→(9999)3 →[とえ]→(19996)15
               →[た]→(9999)3 →[と]→(19997)13
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんしょう]→(29977)20
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんしょ]→(29978)16
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶ]→(29981)17
               →[たとえば]→(9996)4 →[こ]→(19991)5 →[ん]→(29985)22
               →[たとえば]→(9996)4 →[こん]→(19990)6 →[な]→(29983)21
               →[たとえ]→(9997)2 →[ばこん]→(19991)10 →[な]→(29984)23

第11ターン：
    (0)[START] →[たとえ]→(9997)2 →[ば]→(19993)8
               →[たと]→(9998)1 →[えば]→(19994)12
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんし]→(29979)19
               →[たと]→(9998)1 →[え]→(19995)11
               →[た]→(9999)3 →[とえば]→(19995)14
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶん]→(29980)18
               →[たとえば]→(9996)4 →[こん]→(19990)6 →[な]→(29983)21
               →[た]→(9999)3 →[とえ]→(19996)15
               →[た]→(9999)3 →[と]→(19997)13
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんしょう]→(29977)20
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんしょ]→(29978)16
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶ]→(29981)17
               →[たとえば]→(9996)4 →[こ]→(19991)5 →[ん]→(29985)22
               →[たとえ]→(9997)2 →[ばこん]→(19991)10 →[な]→(29984)23
               →[たとえ]→(9997)2 →[ばこ]→(19992)9 →[ん]→(29986)24

第12ターン：
    (0)[START] →[たと]→(9998)1 →[えば]→(19994)12
               →[たと]→(9998)1 →[え]→(19995)11
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんし]→(29979)19
               →[た]→(9999)3 →[とえ]→(19996)15
               →[た]→(9999)3 →[とえば]→(19995)14
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶん]→(29980)18
               →[たとえば]→(9996)4 →[こん]→(19990)6 →[な]→(29983)21
               →[たとえ]→(9997)2 →[ばこ]→(19992)9 →[ん]→(29986)24
               →[た]→(9999)3 →[と]→(19997)13
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんしょう]→(29977)20
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんしょ]→(29978)16
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶ]→(29981)17
               →[たとえば]→(9996)4 →[こ]→(19991)5 →[ん]→(29985)22
               →[たとえ]→(9997)2 →[ばこん]→(19991)10 →[な]→(29984)23
               →[たとえ]→(9997)2 →[ば]→(19993)8 →[こ]→(29988)25
               →[たとえ]→(9997)2 →[ば]→(19993)8 →[こん]→(29987)26
               →[たとえ]→(9997)2 →[ば]→(19993)8 →[こんな]→(29986)27

第13ターン：
    (0)[START] →[たと]→(9998)1 →[え]→(19995)11
               →[た]→(9999)3 →[とえば]→(19995)14
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんし]→(29979)19
               →[た]→(9999)3 →[とえ]→(19996)15
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんしょう]→(29977)20
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶん]→(29980)18
               →[たとえば]→(9996)4 →[こん]→(19990)6 →[な]→(29983)21
               →[たとえ]→(9997)2 →[ばこ]→(19992)9 →[ん]→(29986)24
               →[た]→(9999)3 →[と]→(19997)13
               →[たとえ]→(9997)2 →[ば]→(19993)8 →[こんな]→(29986)27
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんしょ]→(29978)16
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶ]→(29981)17
               →[たとえば]→(9996)4 →[こ]→(19991)5 →[ん]→(29985)22
               →[たとえ]→(9997)2 →[ばこん]→(19991)10 →[な]→(29984)23
               →[たとえ]→(9997)2 →[ば]→(19993)8 →[こ]→(29988)25
               →[たとえ]→(9997)2 →[ば]→(19993)8 →[こん]→(29987)26
               →[たと]→(9998)1 →[えば]→(19994)12 →[こ]→(29989)28
               →[たと]→(9998)1 →[えば]→(19994)12 →[こん]→(29988)29
               →[たと]→(9998)1 →[えば]→(19994)12 →[こんな]→(29987)30

第14ターン：
    (0)[START] →[た]→(9999)3 →[とえば]→(19995)14
               →[た]→(9999)3 →[とえ]→(19996)15
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんし]→(29979)19
               →[た]→(9999)3 →[と]→(19997)13
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんしょう]→(29977)20
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶん]→(29980)18
               →[たとえば]→(9996)4 →[こん]→(19990)6 →[な]→(29983)21
               →[たとえ]→(9997)2 →[ばこ]→(19992)9 →[ん]→(29986)24
               →[たと]→(9998)1 →[えば]→(19994)12 →[こんな]→(29987)30
               →[たとえ]→(9997)2 →[ば]→(19993)8 →[こんな]→(29986)27
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんしょ]→(29978)16
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶ]→(29981)17
               →[たとえば]→(9996)4 →[こ]→(19991)5 →[ん]→(29985)22
               →[たとえ]→(9997)2 →[ばこん]→(19991)10 →[な]→(29984)23
               →[たとえ]→(9997)2 →[ば]→(19993)8 →[こ]→(29988)25
               →[たとえ]→(9997)2 →[ば]→(19993)8 →[こん]→(29987)26
               →[たと]→(9998)1 →[えば]→(19994)12 →[こ]→(29989)28
               →[たと]→(9998)1 →[えば]→(19994)12 →[こん]→(29988)29
               →[たと]→(9998)1 →[え]→(19995)11 →[ば]→(29991)31
               →[たと]→(9998)1 →[え]→(19995)11 →[ばこ]→(29990)32
               →[たと]→(9998)1 →[え]→(19995)11 →[ばこん]→(29989)33

第15ターン：
    (0)[START] →[た]→(9999)3 →[とえ]→(19996)15
               →[た]→(9999)3 →[と]→(19997)13
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんし]→(29979)19
               →[たとえ]→(9997)2 →[ばこ]→(19992)9 →[ん]→(29986)24
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんしょう]→(29977)20
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶん]→(29980)18
               →[たとえば]→(9996)4 →[こん]→(19990)6 →[な]→(29983)21
               →[たとえ]→(9997)2 →[ば]→(19993)8 →[こん]→(29987)26
               →[たと]→(9998)1 →[えば]→(19994)12 →[こんな]→(29987)30
               →[たとえ]→(9997)2 →[ば]→(19993)8 →[こんな]→(29986)27
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんしょ]→(29978)16
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶ]→(29981)17
               →[たとえば]→(9996)4 →[こ]→(19991)5 →[ん]→(29985)22
               →[たとえ]→(9997)2 →[ばこん]→(19991)10 →[な]→(29984)23
               →[たとえ]→(9997)2 →[ば]→(19993)8 →[こ]→(29988)25
               →[たと]→(9998)1 →[え]→(19995)11 →[ばこん]→(29989)33
               →[たと]→(9998)1 →[えば]→(19994)12 →[こ]→(29989)28
               →[たと]→(9998)1 →[えば]→(19994)12 →[こん]→(29988)29
               →[たと]→(9998)1 →[え]→(19995)11 →[ば]→(29991)31
               →[たと]→(9998)1 →[え]→(19995)11 →[ばこ]→(29990)32
               →[た]→(9999)3 →[とえば]→(19995)14 →[こ]→(29990)34
               →[た]→(9999)3 →[とえば]→(19995)14 →[こん]→(29989)35
               →[た]→(9999)3 →[とえば]→(19995)14 →[こんな]→(29988)36

第16ターン：
    (0)[START] →[た]→(9999)3 →[と]→(19997)13
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんしょう]→(29977)20
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんし]→(29979)19
               →[たとえ]→(9997)2 →[ばこ]→(19992)9 →[ん]→(29986)24
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんしょ]→(29978)16
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶん]→(29980)18
               →[たとえば]→(9996)4 →[こん]→(19990)6 →[な]→(29983)21
               →[たとえ]→(9997)2 →[ば]→(19993)8 →[こん]→(29987)26
               →[たと]→(9998)1 →[えば]→(19994)12 →[こんな]→(29987)30
               →[たとえ]→(9997)2 →[ば]→(19993)8 →[こんな]→(29986)27
               →[た]→(9999)3 →[とえば]→(19995)14 →[こんな]→(29988)36
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶ]→(29981)17
               →[たとえば]→(9996)4 →[こ]→(19991)5 →[ん]→(29985)22
               →[たとえ]→(9997)2 →[ばこん]→(19991)10 →[な]→(29984)23
               →[たとえ]→(9997)2 →[ば]→(19993)8 →[こ]→(29988)25
               →[たと]→(9998)1 →[え]→(19995)11 →[ばこん]→(29989)33
               →[たと]→(9998)1 →[えば]→(19994)12 →[こ]→(29989)28
               →[たと]→(9998)1 →[えば]→(19994)12 →[こん]→(29988)29
               →[たと]→(9998)1 →[え]→(19995)11 →[ば]→(29991)31
               →[たと]→(9998)1 →[え]→(19995)11 →[ばこ]→(29990)32
               →[た]→(9999)3 →[とえば]→(19995)14 →[こ]→(29990)34
               →[た]→(9999)3 →[とえば]→(19995)14 →[こん]→(29989)35
               →[た]→(9999)3 →[とえ]→(19996)15 →[ば]→(29992)37
               →[た]→(9999)3 →[とえ]→(19996)15 →[ばこ]→(29991)38
               →[た]→(9999)3 →[とえ]→(19996)15 →[ばこん]→(29990)39

第17ターン：
    (0)[START] →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんしょう]→(29977)20
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんしょ]→(29978)16
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんし]→(29979)19
               →[たとえ]→(9997)2 →[ばこ]→(19992)9 →[ん]→(29986)24
               →[たとえ]→(9997)2 →[ば]→(19993)8 →[こんな]→(29986)27
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶん]→(29980)18
               →[たとえば]→(9996)4 →[こん]→(19990)6 →[な]→(29983)21
               →[たとえ]→(9997)2 →[ば]→(19993)8 →[こん]→(29987)26
               →[たと]→(9998)1 →[えば]→(19994)12 →[こんな]→(29987)30
               →[たと]→(9998)1 →[え]→(19995)11 →[ばこ]→(29990)32
               →[た]→(9999)3 →[とえば]→(19995)14 →[こんな]→(29988)36
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶ]→(29981)17
               →[たとえば]→(9996)4 →[こ]→(19991)5 →[ん]→(29985)22
               →[たとえ]→(9997)2 →[ばこん]→(19991)10 →[な]→(29984)23
               →[たとえ]→(9997)2 →[ば]→(19993)8 →[こ]→(29988)25
               →[たと]→(9998)1 →[え]→(19995)11 →[ばこん]→(29989)33
               →[たと]→(9998)1 →[えば]→(19994)12 →[こ]→(29989)28
               →[たと]→(9998)1 →[えば]→(19994)12 →[こん]→(29988)29
               →[たと]→(9998)1 →[え]→(19995)11 →[ば]→(29991)31
               →[た]→(9999)3 →[とえ]→(19996)15 →[ばこん]→(29990)39
               →[た]→(9999)3 →[とえば]→(19995)14 →[こ]→(29990)34
               →[た]→(9999)3 →[とえば]→(19995)14 →[こん]→(29989)35
               →[た]→(9999)3 →[とえ]→(19996)15 →[ば]→(29992)37
               →[た]→(9999)3 →[とえ]→(19996)15 →[ばこ]→(29991)38
               →[た]→(9999)3 →[と]→(19997)13 →[え]→(29994)40
               →[た]→(9999)3 →[と]→(19997)13 →[えば]→(29993)41

第18ターン：
    (0)[START] →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんしょう]→(29977)20 →[END]→(29977)42
               →[たとえ]→(9997)2 →[ばこ]→(19992)9 →[ん]→(29986)24
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんしょ]→(29978)16
               →[たとえ]→(9997)2 →[ば]→(19993)8 →[こん]→(29987)26
               →[たとえ]→(9997)2 →[ば]→(19993)8 →[こんな]→(29986)27
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶんし]→(29979)19
               →[たとえば]→(9996)4 →[こん]→(19990)6 →[な]→(29983)21
               →[たと]→(9998)1 →[え]→(19995)11 →[ばこん]→(29989)33
               →[たと]→(9998)1 →[えば]→(19994)12 →[こんな]→(29987)30
               →[たと]→(9998)1 →[え]→(19995)11 →[ばこ]→(29990)32
               →[た]→(9999)3 →[とえば]→(19995)14 →[こんな]→(29988)36
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶ]→(29981)17
               →[たとえば]→(9996)4 →[こんな]→(19989)7 →[ぶん]→(29980)18
               →[たとえ]→(9997)2 →[ばこん]→(19991)10 →[な]→(29984)23
               →[たとえ]→(9997)2 →[ば]→(19993)8 →[こ]→(29988)25
               →[た]→(9999)3 →[と]→(19997)13 →[えば]→(29993)41
               →[たと]→(9998)1 →[えば]→(19994)12 →[こ]→(29989)28
               →[たと]→(9998)1 →[えば]→(19994)12 →[こん]→(29988)29
               →[たと]→(9998)1 →[え]→(19995)11 →[ば]→(29991)31
               →[た]→(9999)3 →[とえ]→(19996)15 →[ばこん]→(29990)39
               →[た]→(9999)3 →[とえば]→(19995)14 →[こ]→(29990)34
               →[た]→(9999)3 →[とえば]→(19995)14 →[こん]→(29989)35
               →[た]→(9999)3 →[とえ]→(19996)15 →[ば]→(29992)37
               →[た]→(9999)3 →[とえ]→(19996)15 →[ばこ]→(29991)38
               →[た]→(9999)3 →[と]→(19997)13 →[え]→(29994)40
               →[たとえば]→(9996)4 →[こ]→(19991)5 →[ん]→(29985)22

……全探索になっている orz

Thu,25 Aug,2011 追記：
枝刈りするのを完全に忘れていた。ちゃんと枝刈りすると全探索にはならない。


変換内容：「たとえばこんなぶんしょう」
アルゴリズム：文節数最小（文節位置補正付き）、A*
※ ヒープなので第１候補は先頭に来るが、２番目以降の並び順は意味が無いので注意。

第１ターン：
    (0)[START]

第２ターン：
    (0)[START] →[たとえば]→(89996:9996)4
               →[たとえ]→(99997:9997)2
               →[た]→(119999:9999)3
               →[たと]→(109998:9998)1

第３ターン：
    (0)[START] →[たとえば]→(89996:9996)4 →[こんな]→(69989:19989)7
               →[たとえば]→(89996:9996)4 →[こ]→(89991:19991)5
               →[たとえば]→(89996:9996)4 →[こん]→(79990:19990)6
               →[たと]→(109998:9998)1
               →[たとえ]→(99997:9997)2
               →[た]→(119999:9999)3

第３ターン：
    (0)[START] →[たとえば]→(89996:9996)4 →[こんな]→(69989:19989)7 →[ぶんしょう]→(29977:29977)12
               →[たとえば]→(89996:9996)4 →[こんな]→(69989:19989)7 →[ぶんしょ]→(39978:29978)8
               →[たとえば]→(89996:9996)4 →[こんな]→(69989:19989)7 →[ぶ]→(69981:29981)9
               →[たとえば]→(89996:9996)4 →[こんな]→(69989:19989)7 →[ぶん]→(59980:29980)10
               →[たとえば]→(89996:9996)4 →[こんな]→(69989:19989)7 →[ぶんし]→(49979:29979)11
               →[た]→(119999:9999)3
               →[たとえば]→(89996:9996)4 →[こん]→(79990:19990)6
               →[たと]→(109998:9998)1
               →[たとえば]→(89996:9996)4 →[こ]→(89991:19991)5
               →[たとえ]→(99997:9997)2

第４ターン：
    (0)[START] →[たとえば]→(89996:9996)4 →[こんな]→(69989:19989)7 →[ぶんしょう]→(29977:29977)12 →[END]→(29977:29977)13
               →[たとえば]→(89996:9996)4 →[こんな]→(69989:19989)7 →[ぶんしょ]→(39978:29978)8
               →[たとえば]→(89996:9996)4 →[こんな]→(69989:19989)7 →[ぶ]→(69981:29981)9
               →[たとえば]→(89996:9996)4 →[こんな]→(69989:19989)7 →[ぶん]→(59980:29980)10
               →[たとえば]→(89996:9996)4 →[こんな]→(69989:19989)7 →[ぶんし]→(49979:29979)11
               →[た]→(119999:9999)3
               →[たとえば]→(89996:9996)4 →[こん]→(79990:19990)6
               →[たと]→(109998:9998)1
               →[たとえば]→(89996:9996)4 →[こ]→(89991:19991)5
               →[たとえ]→(99997:9997)2

ヒューリスティックが効いて、凄い速さで解を出しています。
まぁ、出した解が正答か否かの問題は有りますが。

Thu,25 Aug,2011 追記：
ビューリスティックが間違っている。
文節数最小では A* を用いる事はできない。

Wed,24 Aug,2011

Anthy で文節数最小法。
文節候補リストのテーブル化のコーディングを追加修正してみた。 双方向における左右からの探索を連結する部分のバグは未修正。
取り敢えず、ベンチマークを取ってみる。 文節候補リストのテーブル化は４コア(2GHz)で並列同時実行。 文節数最小のみ再計測、他は前回のコピー。
Fri,03 Sep,2010、 Sat,20 Aug,2011 に関連。
学習再生／学習記録、共に無効。 変換内容は毎度お馴染み JNetHack の占いクッキーの先頭100文。

かな漢字変換ソフトの変換結果ベンチマークテスト
系列 モード 文節区切りの誤答数 文節区切り正答中の変換候補誤答数変換所要時間うち文節区切り所要時間

実験版(patch13-testing)MBRビタビ(HID_IDI_IwDT) 5.25 [秒] 3.42 [秒]
実験版(patch13-testing)MBRビタビ(HID_IDI_IwDT) ※ 5.20 [秒] 3.39 [秒]

実験版(patch13-testing)前方３文節最長一致 1.71 [秒] 0.10 [秒]
実験版(patch13-testing)前方３文節最長一致 ※ 1.66 [秒] 0.10 [秒]

開発中版 文節数最小 ダイクストラ 左→右方向 41 14 2.08 [秒] 0.17 [秒]
開発中版 文節数最小 ダイクストラ 左→右方向 ※ 40 14 1.91 [秒] 0.11 [秒]
開発中版 文節数最小 ダイクストラ 右→左方向 41 14 53.23 [秒] 51.36 [秒]
開発中版 文節数最小 ダイクストラ 右→左方向 ※ 40 14 1.96 [秒] 0.16 [秒]
開発中版 文節数最小 ダイクストラ 双方向デュアルコア 92 5 1.86 [秒] 0.14 [秒]
開発中版 文節数最小 ダイクストラ 双方向デュアルコア※ 91 5 1.78 [秒] 0.11 [秒]
※ 入力から 「金の損失、些細な損失。名誉の損失、多大な損失。騙されて損失、すっからかん」 （１６文節）を削除。何故これがやたら時間を食うのかは不明。 どうやら、他の文章は８〜10文節で納まっているが、 この１文だけ飛び抜けて文節数が多いらしい。
文節区切り所要時間以外の所要時間が変動している理由は不明。

ダイクストラで速くなった分は、 文節候補リストをテーブル化し、 文節区切り位置探索時には文節候補リストを見ずに テーブルを見た分だけ速くなっている。   と言う事で、差分から求めると、 実消費時間は 50[ms] だが４コアで同時実行している筈なので、 文節候補リストをテーブル化する総所要時間は概ね 200[ms] らしい。

Wed,21 Sep,2011 追記：
OpenBSD にて pthread を使った場合、 複数スレッドを１コアで交互に実行していた。 なので、 双方向デュアルコアは間違いで、 双方向シングルコア状態になっていた。 理由・対処法は今の所不明。

マルチスレッド／マルチプロセスの話は、 Wed,21 Sep,2011、 Thu,22 Sep,2011、 Fri,23 Sep,2011、 Sun,25 Sep,2011、 に続く。

Thu,25 Aug,2011

Anthy で文節数最小法。
何か日替わりな状況になっているけれど。 文節数最小法でメモリリークしていたバグを修正。 ダイクストラ法で枝刈りを忘れていたバグを修正。 双方向探索にて左右からの探索を連結する部分のバグ修正。 で、ベンチマークを取ってみる。 文節候補リストのテーブル化は４コア(2GHz)で並列同時実行。 文節区切り位置候補の双方向探索は２コアで並列同時実行。 一部の結果は以前の計測時のコピー（※印）。 学習の再生機能は未実装。
Fri,03 Sep,2010、 Sat,20 Aug,2011、 Wed,24 Aug,2011 に関連。
学習再生／学習記録、共に無効。 変換内容は毎度お馴染み JNetHack の占いクッキーの先頭100文。

かな漢字変換ソフトの変換結果ベンチマークテスト
系列 モード 文節区切りの誤答数 文節区切り正答中の変換候補誤答数変換所要時間うち文節区切り所要時間

実験版(patch13-testing)MBRビタビ(HID_IDI_IwDT) 19 ※ 23 ※ 5.25 [秒] 3.42 [秒]

実験版(patch13-testing)前方３文節最長一致 31 ※ 15 ※ 1.71 [秒] 0.10 [秒]

開発中版 文節数最小 ダイクストラ 左→右方向 41 14 1.91 [秒] 0.062 [秒]
開発中版 文節数最小 ダイクストラ 右→左方向 41 14 1.91 [秒] 0.063 [秒]
開発中版 文節数最小 ダイクストラ 双方向デュアルコア 41 15 1.91 [秒] 0.065 [秒]
開発中版 文節数最小 ダイクストラ 双方向デュアルコア 41 14 1.91 [秒] 0.065 [秒]
文節区切り所要時間以外の所要時間が変動している理由は不明。
片方向より双方向の方が遅くなっているが、 文節数が多くなると双方向の方が速くなると思う。

「文節区切り正答中の変換候補誤答数」において、 「短剣は」と「探検は」とか、「証券は」と「小剣は」など、 間違えても当然だと思う…… データベースにそういう情報が載っていないのだから。 用例辞書がそのデータベースなのだが、 手作業でメンテナンスしているのでとてもじゃないが追いつかない。

Fri,26 Aug,2011 追記：
双方向が片方向と異なる結果になっていたのは、単なるバグだった。

Wed,21 Sep,2011 追記：
OpenBSD にて pthread を使った場合、 複数スレッドを１コアで交互に実行していた。 なので、 双方向デュアルコアは間違いで、 双方向シングルコア状態になっていた。 理由・対処法は今の所不明。

マルチスレッド／マルチプロセスの話は、 Wed,21 Sep,2011、 Thu,22 Sep,2011、 Fri,23 Sep,2011、 Sun,25 Sep,2011、 に続く。

Sun,28 Aug,2011

FreeBSD 9.0-BETA2 is coming now.

Mon,29 Aug,2011

Anthy で文節数最小法。
文節区切り所要時間の他に、 変換候補一覧生成所要時間も測定してみた。 文節候補リストのテーブル化は４コア(2GHz)で並列同時実行。 文節区切り位置候補の双方向探索は２コアで並列同時実行。 一部の結果は以前の計測時のコピー（※印）。 学習の再生機能は未実装。
Fri,03 Sep,2010、 Sat,20 Aug,2011、 Wed,24 Aug,2011、 Thu,25 Aug,2011 に関連。
学習再生／学習記録、共に無効。 変換内容は毎度お馴染み JNetHack の占いクッキーの先頭100文。

かな漢字変換ソフトの変換結果ベンチマークテスト
系列 モード 変換所要時間うち文節区切り所要時間うち変換候補一覧生成所要時間

実験版(patch13-testing)MBRビタビ(HID_IDI_IwDT) 5.37 [秒] 3.48 [秒] 0.16 [秒]

実験版(patch13-testing)前方３文節最長一致 1.76 [秒] 0.10 [秒] 0.13 [秒]

開発中版 文節数最小 ダイクストラ 左→右方向 1.95 [秒] 0.076 [秒] 0.16 [秒]
開発中版 文節数最小 ダイクストラ 右→左方向 1.95 [秒] 0.076 [秒] 0.16 [秒]
開発中版 文節数最小 ダイクストラ 双方向デュアルコア 1.95 [秒] 0.078 [秒] 0.16 [秒]

Wed,21 Sep,2011 追記：
OpenBSD にて pthread を使った場合、 複数スレッドを１コアで交互に実行していた。 なので、 双方向デュアルコアは間違いで、 双方向シングルコア状態になっていた。 理由・対処法は今の所不明。

マルチスレッド／マルチプロセスの話は、 Wed,21 Sep,2011、 Thu,22 Sep,2011、 Fri,23 Sep,2011、 Sun,25 Sep,2011、 に続く。

PCの重さ。
ふと気になって測ってみた。
PC-9801VX2 (HDD無) が 11.90[kg] だった。
一番重いのは多分 XL2 だろうなぁ、と思う。

Tue,30 Aug,2011

Anthy で文節数最小法。
ろくすっぽデバッグしていませんが、
（Tue,06 Sep,2011 追記：１週間の実地試験を通過）
（Wed,07 Sep,2011 追記：バグ修正）
とにかく文節数最小法を使ってみたい、と言う方へ。   文節数最小法を実装した開発中版。
（開発中版更新に付き削除）
学習の再生機能も含めて必要な機能は実装済み。

注意事項：
confファイル内のオプション名が、いくつか変更になっています。 現行のリリース版や試験版との互換性は有りません （MBRアルゴリズムを使用する（MBR用オプションを参照する）のが、 今までは VITERBIアルゴリズムだけだったが、 今後は DIJKSTRAアルゴリズムでも用いる為）。
BSD系にて uim-xim から uim-anthy を使用する場合、 uim-xim のビルド時に -pthread コンパイルオプションを 追加する必要が有ります。 これを忘れると、uim-xim で日本語を入力した時に刺さります。   uim-xim のビルド時に -pthread コンパイルオプションを 追加する事が出来ない場合、 anthy のビルド時の configure に --disable-pthread オプションを付けるか、 confファイルにて「ENABLE_PTHREAD false」指定するか、 して下さい。

Fri,02 Sep,2011

UV-LED ブラックライト
伊達と酔狂で 365nm 紫外線 LED キーライトを通販で買ったのが、 今日（発注から５営業日目）届いていた。
早速分解。
3Vボタン電池＊２ で電源電圧 6V なのだが、それに LED が直結。 ボタン電池の出力電力／内部抵抗で電流制限している……のか 電流制限していないのだか、野蛮な構造。 とりあえず 6V で 100mA 流れていたので 0.6W（注：光出力ではない）とかいう そこそこ大出力なのだが、 LED はφ5mm の樹脂封入砲弾型で、 せいぜい 0.1W品（注：光出力ではない）に見えるし、 点灯していると、LED を触ると判るぐらい加熱しているし、 紫外線の筈なのに青〜紫の発光をしているのだが……。 しかも電池電圧を測定しながら点灯していると、 見る見る電圧が下がっていくぐらいの無茶っぷり。
3V で点灯するか試してみたが、点灯しなかった。 Vf は結構大きいらしい。   web で類似品のカタログを見てみると、 Vf = 3.2V 〜 3.6V 〜 4.2V、 If = 25mA、 If_pulse = 100mA (Duty Cycle 1/10, Pulse Width 0.1msec)、 くらいらしい。 やっぱり定格越えてドライブしてるよ……。

白色LED マグライト
手持ちの奴は、単三１本からアップコンバータで、 3V 30mA 0.09W（注：光出力ではない）だった。 UV LED に交換しても点灯しないな、これじゃ。

昇圧 DC-DC。
秋月で、単３充電池１本から 5V に昇圧できる物を見つけた。 単価￥500-。送料￥500-。 メール便なら￥80-で遅れるサイズ・重量なのだが……。
それから、 ストロベリー・リナックス と言う所でも、昇圧 DC-DC を￥525-で扱っているらしい。
トランジスタ買ってきて、自分でコイル巻けば、自作はできるものの、 コイル巻きと言う所で脊椎反射の拒絶反応が。

Sun,15 Apr,2012、 Wed,12 Feb,2020、 に続く。

Sat,03 Sep,2011

ホットナイフ。
ニクロムヒーター用セットだと、 概ね￥1,230〜￥1,380-で、替刃が定価￥480？。
セラミックヒーター用だと、 コテが温度設定機能付の千円台後半するヤツで、 替刃が定価￥1,380〜￥1,480-。
素直にニクロムヒーターコテを、 ホットナイフ専用にしてしまう方が 安上がりでしかも堅実（電子工作用と完全に分離）ですな。

ブラックライト
せっかく買ったのに、持って出るのを忘れた。   ホームセンターの蛍光色や夜光塗料の塗装見本で試せなかった……。
取り敢えず、色々当ててみる。
日本円の札だと、 赤色の丸印が黄緑色の強い蛍光、全般の印刷が黄緑色の薄い蛍光、 だった。紫外線印刷しかしていない図柄や文字は無かった。
中国元の札だと、 中央左上に紫外線印刷のみのアラビア数字の金額表示が、 全般に黄緑色と紫色の紙繊維？の切れ端？が、まぶしてあった。   関係ないけれど、中国元の硬貨って、錆びるのね。 １元硬貨が錆びて１元札にこびり付いていた。 錆びる硬貨って……。 中国元高はまだですか……、いつになったら両替すればいいのやら。
パスポートは、 写真のあるページの写真の右側に紫外線印刷の写真が、 先頭数ページの左上に横線が、１本２本。
免許証や保険証は何にも無し。
通帳は、ゆうちょ銀行の印影のホログラムシールの下の白い部分が、 紫外線で黄緑色に発光する様になっていた。 他の銀行は何も無し。
日本郵便の紫外線での配達先印刷は赤色蛍光だった。 てっきり黄緑色だと思い込んでいたのだが。
蛍光灯に当ててみても発光は、しなかった。 ちょっと予想外。 たしか、 1.2GHz 1W だったか 5W だったか 10W だったかを照射した時は、 あっさり光ったのだが。
↑別の蛍光灯に当てたら発光した。 昼光色だと黄緑色、昼白色だと青色、に発光した。
ブラウン管はグレーに発光した。 液晶ディスプレイは何にも無し。
洗濯物はクッキリとした青色に発光した。
VISAカードは、表面の VISAロゴに「Ｖ」の字、 裏面の署名欄に VISA が沢山、書いてあった。 JCBカードは何も無かった。 MasterCard, Amex, DC は持っていないので不明。

xfsdump
3.5GiB に約３分半。

xz
600MB→100MB に Core-i5 2.4GHz １コアで約10分。 Turbo は効いているのだか効いていないのやら不明。 マルチコア対応版は持っていない （そもそもリリースされていたっけ？）。
3.5GiB → 900MiB に約45分。

par2
100MB に約50秒。
900MiB に約７分15秒。

Debian GNU/Linux で xz。
見ていると、プロセスが特定のコアに固定されている様に見える。 BSD系の標準設定だと、 特定のコアに固定せずにラウンドロビンするのだけれど （FreeBSD は cpuset にて固定可能）。   アーカイバだと固定した方が L1/L2 キャッシュの利用効率が良さそうだけれども、 ラウンドロビンで回した方が発熱対策としては良いらしいし、 総合的に見てどちらが良いのだろうね？。

MS-Windows 7 で無線LAN。
最近通りが悪いので、 InSSIDer と言うソフトを使って調整してみた。
基地局を 2.4GHz帯 13ch や 12ch にしたら、 突然通信が切れてそれっきり再接続しなかった。 基地局やPCを再起動しても駄目。 わけが判らないので、 チャンネルを 4〜6ch あたりに設定したら、あっさり再接続した。
どうやらこの東芝のノートPC、 無線LAN の 2.4GHz帯の 12〜13ch は接続できないらしい？   なんじゃそりゃ。

Sun,04 Sep,2011

家電量販店の来店ポイント。
今までは月初から５回は必ず 51ポイント付いていたのだが。 来店ポイントの累計付与ポイント数が、 今までの購入の累計支払額の５％を越えたら、 来店ポイントがランダムで付くようになった。 購入時のポイントが 10％で、来店ポイントが５％だから、 合計 15％か……。

redundant redeclaration
BSD系で stdlib.h と unistd.h の両方を #include すると、 

/usr/include/stdlib.h:181: warning: redundant redeclaration of 'int mkstemp(char*)' in same scope
/usr/include/unistd.h:153: warning: previous declaration of 'int mkstemp(char*)'
等の mk*temp*() の多重定義警告が出るのだが、どうしたものかな。
FreeBSD は両方残したまま多重定義回避の対策をしてあった。
NetBSD は unistd.h での定義をバッサリ削除してあった。
OpenBSD は未対処だった。
GNU/Linux方面だと stdlib.h だけで定義してあった。
まぁ、OpenBSD使いなら、これは問題ではないと判るかな……。

蛍光塗料／夜光塗料（蓄光塗料）
店頭の塗装見本にブラックライト（紫外線）を当ててみた。
蛍光塗料と夜光塗料は、 蛍光塗料の方は光を当てるのをやめるとすぐに発光が止まり、 夜光塗料の方は光を当てるのをやめてもしばらく発光が続く、 と言う違いがあるが、 発光色の偏り方は両者ほとんど同じだった。
黄／緑はわりかし発光が強めで、色は黄緑色に偏りがちだった。
赤／ピンクは中程度の発光で、色は赤みがかったオレンジに偏りがちだった。 はっきり言って、ピンクはピンクじゃない。
橙は中程度の発光で、色は黄色に偏りがちだった。
青は発光が弱めで、色の偏りは無かった。
ガンダムマーカー蛍光ピンクは、もろに赤と橙の中間に偏っていた。 はっきり言って、ピンクじゃない。
ガンダムマーカー蛍光グリーンは、ほぼそのまま、白みがかった黄緑色だった。 案外鮮やかだった。
ガイアノーツ青色は発光が弱く、偏りはわずかに白色で、ほぼ青白だった。
ガイアノーツピンクは中程度の発光で、赤と橙の中間ぐらいに偏っていた。 はっきり言って、ピンクじゃない。
ガイアノーツ赤色は中程度の発光で、これも赤と橙の中間ぐらいに偏っていた。
ガイアノーツ緑色は強めの発光で、ほんのちょっと黄緑色に偏っていた。
ガイアノーツ黄色は非常に強い発光で、偏りは無く、真っ黄色だった。 Sat,05 Oct,2019 追記： 塗ってみたらイエローグリーンになってしまった。
ガイアノーツオレンジは中程度の発光で、偏りは無く、橙色だった。
これで概ね全色制覇したと思うけれど。

篠原涼子、恋しさと せつなさと 心強さと、1994.7.21。

岡村孝子、夢をあきらめないで、1987.2.4。

Tue,06 Sep,2011

C/C++言語の変数定義とスコープ。

if (foo) {
    const int value = func1( hoge );
    return value;
} else {
    const int value = func2( moge );
    return value;
}
こんなんあったとすると、思わず 
if (foo) {
    const int value = func1( hoge );
} else {
    const int value = func2( moge );
}
return value;
と書きたくなってしまう。   もちろん、スコープ外になるので駄目だけど。 
int value;
if (foo) {
    value = func1( hoge );
} else {
    value = func2( moge );
}
return value;
は、const が無くなってしまうので避けたい。 
if (foo) {
    const int value = func1( hoge );
    return value;
}
const int value = func2( moge );
return value;
は、対称性が崩れるから嫌。

Wed,07 Sep,2011

Anthy で文節数最小法。
とにかく文節数最小法を使ってみたい、と言う方へ。   文節数最小法を実装した開発中版。
読み仮名が同じ長さの単文節／単語／単漢字の変換を２回以上行うと、 メモリリークを起こすと共に 解放済みのメモリにアクセスして SIGSEGV してしまう バグを修正。
（開発中版更新に付き削除）

文節数最小法を１週間使ってみたけれど。
ちょくちょく、 無理して文節数を減らしている様な変換候補が出てくる事が有る。
それから、 前方ｎ文節最長一致でも問題になっている 「条件を満たす候補が複数有る場合」の選択が、 文節数最小法でも問題になるくらい頻発している。
たとえば、 「ここではきものを」を変換した時に、 「|ここでは|着物を|」と「|ここで|履物を|」の２つが、 文節数最小の条件を満たしているが、 どちらを変換候補として提示すれば良いのか判断する方法が無い。 これぐらいならば、どちらも等確率でありえるけれど。
「こうほとしてていじすれば」を変換した時に、 「|候補としてて|維持すれば|」と「|候補として|提示すれば|」の２つが、 文節数最小の条件を満たしている。 人間ならばパッと見て、なんとなく後者が望ましい、と判るが、 これをプログラム上のアルゴリズムで判断する方法が無い （その判断する方法の実現を目指したアルゴリズムこそ、 原作版 Anthy が実装を目指した MBR アルゴリズムだと思うけれど、 目指したのはいいもののアレがナニでソレなもんだから……）。

Thu,08 Sep,2011

MBRアルゴリズムの、 Anthy で行っている実装方法の、限界。：かな漢字変換の変換判定
「|まだ|色々|足らないので|」（|まだ|いろいろ|たらないので|）を、 

まだ        ；種別：単語、品詞：#F14：副詞14  、特徴：高頻度語                                  、文節クラス：連用修飾、付属語：（無し）      、付属語クラス：終端。
色々        ；種別：単語、品詞：#T10：名詞10  、特徴：高頻度語＆サ変名詞                        、文節クラス：名詞終端、付属語：（無し）      、付属語クラス：終端。
足らないので；種別：単語、品詞：#R5 ：ラ行五段、特徴：低頻度語辞書に掲載＆高頻度語＆語幹が１文字、文節クラス：動詞連用、付属語：「らないので」、付属語クラス：連用。
として、学習している。
中途の文節の付属語クラスは「終端」でいいのか？、 とか、 「特徴：低頻度語辞書に掲載＆高頻度語」は 低頻度と高頻度って矛盾してないか？ （低頻度単語辞書でハッシュコリジョン起こしていないか？）、 とか、 疑問は有るけれど。 さてどうなのだろう。

Anthy 累計学習量の変化(22KiB)
４年間分の、累計学習データ量の変化グラフ。
どの学習項目に於いても、個人がタイプした４年間程度では まるで飽和しない（天井に届かない）（学習量がまだまだ不足している）事が 見て取れる。
普段使っている感覚では、 日常的によく使う言い回しに関しては、 一応それなりに学習が出来ていると感じるけれど。
半年で多少マシになったかなぁ、で、 １年でそこそこマシか、で、 ２年でまぁ使っていられる、と、 そんな感じ。 普通はそんな長期間の学習は無理ですね……、 精神的に耐えられない。
やっぱりブートストラップ用学習データを活用する方法を ちゃんと考えた方がいいかな……。

MBRアルゴリズムの処理経過の分析。
MBRダイクストラ法による幅優先探索を行ってみたら。
50文字を突っ込んでみたら、30分経っても終わりゃしない。 デバッガで見たら、 メモリ消費が 150MB越え、 トライ木が 180万要素越え、 ヒープが 160万要素越え。
枝刈りを実装せんと駄目だな……。
あるいは深さ優先探索の方が良いのだろうか。
１時間半経ったが終わっていない。 メモリ消費は 220MB越え、 トライ木が 300万要素越え、 ヒープが 260万要素越え。   何が遅いって、どうやら realloc() が遅いらしい。 break かけると必ず realloc() 内の memset()（MALLOC_OPTIONS の J）か memcpy() で引っかかる。
ちょうど２時間半で、limit に引っかかって止まっていた。 メモリ消費は 210MB越え、 トライ木が 390万要素越え、 ヒープが 340万要素越え。

Sun,11 Sep,2011 追記：
深さ優先探索にしたら、 幅優先の４倍、遅くなった。

Sun,11 Sep,2011

Junkmetal。
ギガントマキア(GIGANTOMAKHIA) として復活していたらしい。 ９月１日〜３日でαテストをしていたらしい。
……
最低要求スペックを見て、プレイ前に挫折。
グラフィックアクセラレータのスペックがまるで足らない orz
ノートPC の Intel HD なので交換も出来ない orz
やっぱりこう言うのはゲーム専用機の方が、 PC よりずっと安価で同程度あるいは同程度以上の グラフィックを実現できるから、強いよなぁ……。

VF-MF - ヴァリアブルファイター マスターファイル
書籍＆模型店の割引券を何に使うのが一番得か考えていて、 家電量販店の書籍／模型コーナーだと割引やポイント付与が少ない商品が、 得だよなぁ、と言うわけで、そらなら書籍だろう （注意： 書籍購入用に、金券ショップなりポイント交換なりで、 図書券なりギフト券なりを入手する事が前提に入っている）。 で、検索していたら。
>「@GA_Graphic ドラグナーの進行も目処が立ったので、いよいよヴァリアブルファイターマスターファイル第5弾製作開始です！　発売は…年末くらいにできたらいいな」 らしい。なんとか割引券の有効期限に間に合うかな。
さて、今度の機種は何だろう？
商業的にタイアップで順当に考えると VF-29 とか VF-27 とかだが、 これほどつまらない展開はない。   じゃぁ VF-17/VF-171 は……斜め向いている気が……でもありそうな…… 私の好みではあるが。   YF-19/VF-19 から順当に行くと YF-21/VF-22 だが…… YF-19/VF-19 のバリエーションはよく目にするが YF-21/VF-22 は全然見ないよなぁ……。   VF-14 はアクロバティック過ぎて無いだろうな。   VF-1 から順当に行くと VF-11かな。   VF-9 はありえないだろう。   VF-5000 は……VF-1 から斜めに行った感じだが……期待薄。   VB-6 は……斜め１回転半な感じ。   VF-3000 もありえないだろう。   VF-4 は……VF-1から真っ直ぐだが、マイナー過ぎる気が。   VF-3 は……明後日の方向な感じ。   VF-1SS は……大人の事情でありえない…… そこそこ好きなのだけれどなぁ。   結局、 VF-4, VF-5000, VF-11, YF-21/VF-22, VF-17/VF-171 ……うーん。 VF-11 が、作りやすそうな感じ。

Sun,29 Jan,2012 追記：
VF-0 の事をすっかり忘れていた。 1 から数えると 0 を忘れるのだよなぁ…… orz

雷
サージプロテクタって、 耐圧どのくらいの物を買えば良いのだろう。 目安がまるで判らん。 むしろプロテクタ入れても所詮ギャンブルか お守りにしかならない気がする。
追記：
一般的な、近所への落雷での余波、クラスだと、 最低限、2kV とか 3kV が、目安らしい。 保護後は DC 400V弱が目安らしい。
ホームセンターや家電量販店で売っている コンセントタップや延長コンセントタイプだと、アースに落とせないから、 アースに落とすタイプと比べて、効果がかなり落ちるらしい。

Thu,15 Sep,2011

Anthy で MBRダイクストラ法。
ろくすっぽデバッグしていませんが、 とにかくMBRダイクストラ法を使ってみたい、と言う方へ。   MBRダイクストラ法を実装した開発中版。
（開発中版更新に付き削除）
学習の再生機能も含めて必要な機能は実装済み。

注意事項：
confファイル内のオプション名が、いくつか変更になっています。 現行のリリース版や試験版との互換性は有りません （MBRアルゴリズムを使用する（MBR用オプションを参照する）のが、 今までは VITERBIアルゴリズムだけだったが、 今後は DIJKSTRAアルゴリズムでも用いる為）。
BSD系にて uim-xim から uim-anthy を使用する場合、 uim-xim のビルド時に -pthread コンパイルオプションを 追加する必要が有ります。 これを忘れると、uim-xim で日本語を入力した時に刺さります。   uim-xim のビルド時に -pthread コンパイルオプションを 追加する事が出来ない場合、 anthy のビルド時の configure に --disable-pthread オプションを付けるか、 confファイルにて「ENABLE_PTHREAD false」指定するか、 して、マルチスレッド動作を無効にして下さい。

Anthy で MBRダイクストラ法、ベンチマーク。
文節候補リストのテーブル化は４コア(2GHz)で並列同時実行。 文節区切り位置候補の双方向探索は２コアで並列同時実行。
Fri,03 Sep,2010、 Sat,20 Aug,2011、 Wed,24 Aug,2011、 Thu,25 Aug,2011、 Mon,29 Aug,2011 に関連。
学習再生／学習記録、共に無効。 変換内容は毎度お馴染み JNetHack の占いクッキーの先頭100文。
かな漢字変換ソフトの変換結果ベンチマークテスト
系列 モード文節区切りの誤答数 文節区切り正答中の第１変換候補誤答数合計誤答数合計正答率変換所要時間うち文節区切り所要時間うち変換候補一覧生成所要時間

試験版 MBRビタビ(HID_IDI_IwDT) 14 25 39 61％ 5.48 [秒] 3.56 [秒] 0.163 [秒]

試験版 前方３文節最長一致 35 19 54 46％ 1.79 [秒] 0.100 [秒] 0.126 [秒]

開発中版文節数最小 ダイクストラ 左→右方向,--disable-pthread 40 15 45 55％ 1.83 [秒] 0.0270[秒] 0.147 [秒]
開発中版文節数最小 ダイクストラ 右→左方向,--disable-pthread 40 15 45 55％ 1.84 [秒] 0.0272[秒] 0.147 [秒]
開発中版文節数最小 ダイクストラ 左→右方向,pthread無し 40 15 45 55％ 1.84 [秒] 0.0277[秒] 0.149 [秒]
開発中版文節数最小 ダイクストラ 右→左方向,pthread無し 40 15 45 55％ 1.85 [秒] 0.0280[秒] 0.148 [秒]

開発中版文節数最小 ダイクストラ 左→右方向 40 15 45 55％ 1.97 [秒] 0.0916[秒] 0.159 [秒]
開発中版文節数最小 ダイクストラ 右→左方向 40 15 45 55％ 1.97 [秒] 0.0926[秒] 0.161 [秒]
開発中版文節数最小 ダイクストラ 双方向デュアルコア 40 15 45 55％ 1.97 [秒] 0.0961[秒] 0.161 [秒]

開発中版MBR ダイクストラ 左→右方向,--disable-pthread 14 25 39 61％ 5.22 [秒] 3.29 [秒] 0.169 [秒]
開発中版MBR ダイクストラ 右→左方向,--disable-pthread 14 25 39 61％ 5.51 [秒] 3.59 [秒] 0.172 [秒]
開発中版MBR ダイクストラ 左→右方向,pthread無し 14 25 39 61％ 5.22 [秒] 3.31 [秒] 0.167 [秒]
開発中版MBR ダイクストラ 右→左方向,pthread無し 14 25 39 61％ 5.53 [秒] 3.61 [秒] 0.168 [秒]

開発中版MBR ダイクストラ 左→右方向 14 25 39 61％ 5.77 [秒] 3.77 [秒] 0.185 [秒]
開発中版MBR ダイクストラ 右→左方向 14 25 39 61％ 6.02 [秒] 4.03 [秒] 0.184 [秒]
開発中版MBR ダイクストラ 双方向デュアルコア 14 25 39 61％ 9.68 [秒] 7.68 [秒] 0.184 [秒]

評価：
MBR ダイクストラの変換結果は MBRビタビと完全に一致した。 たぶん、 MBRビタビで用いているバッファがオーバーフローを起こすくらい 複雑な文章を入力すれば、結果は変わる （MBRビタビの実装では、バッファが溢れると 判定途中の時点に於ける評価の低い候補を問答無用で破棄する。 前半の評価が低くて後半で評価が急上昇する様な流れの場合、 評価が急上昇する前に破棄されてしまう事が有る）。   現実問題としては、 そんな複雑な文章をそうそう頻繁にタイプするとは思えない。
pthread のマルチスレッド制御のオーバーヘッドは、 １割と、案外大きいらしい。 pthread を無効化した左→右探索では、 MBRビタビより MBRダイクストラの方が５％程度、辛うじて速くなった。
文節数最小にて、 デュアルコアモードにしても速度が変わらない理由は不明。 MBR ダイクストラ法にて、 双方向デュアルコアモードにすると倍遅くなる理由は不明。 セマフォを取っている期間が長すぎるのだろうか？ それともバグだろうか？ 判定が過剰に厳しくて無駄な捜索が多いのだろうか？

追記：
寡聞にして知らなかったのだが、

らしい。
ja.wikipedia だと、 フィボナッチヒープは最悪時間が大きい、 とあるが……、 裏付けを取るのが面倒だなぁ……。   web の質問箱でも、 理論上は速いが実際のプログラムにすると遅い、 と回答が有るなぁ……。

ついでに：
anthy のライブラリの生成はアレがナニなので、 gprof をかけるのがすごく面倒。

Wed,21 Sep,2011 追記：
OpenBSD にて pthread を使った場合、 複数スレッドを１コアで交互に実行していた。 なので、 双方向デュアルコアは間違いで、 双方向シングルコア状態になっていた。 理由・対処法は今の所不明。

マルチスレッド／マルチプロセスの話は、 Wed,21 Sep,2011、 Thu,22 Sep,2011、 Fri,23 Sep,2011、 Sun,25 Sep,2011、 に続く。

FreeBSD 9系でサウンド。
ふと、今まで試していなかった事を思い出して、試そうとした、が……。 vmplayer上の FreeBSD でも、ネイティブで実行している FreeBSD でも、 どちらでも、 /dev/sndstat は生えてきているのに /dev/dsp0.0 が生えてきていない……。 これじゃぁ音が出ないよ……。
ドライバを入れ直したり、device.hints をいじってみたり、 カーネルを再構築してみたり、してみたが、全く駄目。   やけになって
sudo mknod /dev/dsp0
とやってみたら、/dev/dsp0.0 が生えてきて音が出る様になった。 なんなんだ、一体……。

Fri,16 Sep,2011

姑息、須く、煮詰まる、又は、 辺りは誤用を連発していそうだ……。   技術系物書きだと、 「並びに」「及び」は校正で引っかかる筈だけれど、 「又は」「若しくは」は素通りするからなぁ……。 特許公報を見ても、 「又は」「若しくは」を区別していないのが多いし。

gprof でコールグラフ。
「Jos�� Fonseca's utilitities - Gprof2Dot」、 「ousttrue氏 - 三次元日誌 - 2009-10-17 - gprofでコールグラフ」。 これはちょっと便利そうだ。
cat gmon.txt | gprof2dot.py | dot -Tpng -o output.png

Anthy で MBRダイクストラ法、プロファイリング。
さっそく gprof2dot.py を使ってみた。 画で表現するのがこんなに効果的だとは思わなかった。
anthy.gmon.2011916.png(877KiB)



用例辞書絡みが結構効いていそう。 特に「関数別」に列挙した関数群が効きそう。

Sat,17 Sep,2011

Anthy チューニング。
ベンチマーク結果が日時によってバラつくので、 チューニング前後比較用にベンチマーク再計測。
Fri,03 Sep,2010、 Sat,20 Aug,2011、 Wed,24 Aug,2011、 Thu,25 Aug,2011、 Mon,29 Aug,2011、 Thu,15 Sep,2011 に関連。
学習再生／学習記録、共に無効。 変換内容は毎度お馴染み JNetHack の占いクッキーの先頭100文。

かな漢字変換ソフトの変換結果ベンチマークテスト：チューニング前
系列 モード変換所要時間うち文節区切り所要時間うち変換候補一覧生成所要時間

試験版 MBRビタビ(HID_IDI_IwDT) 5.00 [秒] 3.47 [秒] 0.124 [秒]

試験版 前方３文節最長一致 1.38 [秒] 0.0621[秒] 0.0938[秒]

開発中版文節数最小 ダイクストラ 左→右方向,--disable-pthread 1.48 [秒] 0.0241[秒] 0.111 [秒]
開発中版文節数最小 ダイクストラ 右→左方向,--disable-pthread 1.48 [秒] 0.0239[秒] 0.112 [秒]

開発中版MBR ダイクストラ 左→右方向,--disable-pthread 4.86 [秒] 3.32 [秒] 0.129 [秒]
開発中版MBR ダイクストラ 右→左方向,--disable-pthread 5.14 [秒] 3.60 [秒] 0.128 [秒]

かな漢字変換ソフトの変換結果ベンチマークテスト：チューニング後
系列 モード変換所要時間うち文節区切り所要時間うち変換候補一覧生成所要時間

試験版 MBRビタビ(HID_IDI_IwDT) 4.48 [秒] 3.10 [秒] 0.115 [秒]

試験版 前方３文節最長一致 1.26 [秒] 0.0585[秒] 0.0893[秒]

開発中版文節数最小 ダイクストラ 左→右方向,--disable-pthread 1.35 [秒] 0.0239[秒] 0.0879[秒]
開発中版文節数最小 ダイクストラ 右→左方向,--disable-pthread 1.35 [秒] 0.0239[秒] 0.107 [秒]

開発中版MBR ダイクストラ 左→右方向,--disable-pthread 4.37 [秒] 2.96 [秒] 0.122 [秒]
開発中版MBR ダイクストラ 右→左方向,--disable-pthread 4.60 [秒] 3.20 [秒] 0.121 [秒]

評価：
「エンディアン変換のラッパ（anthy_dic_ntohl()）」の高速化で、 一挙に 10％の高速化を達成。 高速化と言っても、inline にして call - ret ペアを １組削除しただけなのだけれども、 呼び出し回数が 135679947回と半端ではない量なので。   ついでに。 この部分の汎用化は、OS乃至はlibc に任せるべきで、 個別のアプリケーションが手を出すべきではないと思う。 しかも POSIX.1適合なので、 特殊なシステムでない限りは存在する事が保証されているし。
「ハッシュ計算（hash()）」及び 「数値読み込み＆エンディアン変換ラッパ呼び出し（read_int()）」の 高速化は、 各 0.2％（はっきり言って、測定誤差以下）の高速化にとどまった。 高速化の内容は、 static関数の inline化と関数の引数を１つ削除と if文を１セット削除。 被呼回数は hash() 60462814回、 read_int() 109498631回、 なのだけれども、 何でこんなにわずかしか変わらないのやら。 static関数は -O3 で inline化されたっけ？。   ついでに。 内容としては、 盲腸と化した部分、若しくは将来的な汎用化予定の部分の、削除。 エンディアン変換ラッパと同じく、 この部分の汎用化は、OS乃至はlibc に任せるべきで、 個別のアプリケーションが手を出すべきではないと思う。   蛇足。 「ハッシュ計算（hash()）」にて、 ハッシュの有効サイズを 2^n にすれば、 ビットマスクが１つ増えて割算が１つ減るのだが。 ハッシュ呼出側の整合性を取る手間がかかるのと、 それをやってどの程度速くなるのかと言う問題と。 最近のプロセサの割算は昔と比べて格段に速いしねぇ。   蛇足の蛇足。 ハッシュの有効サイズを 8bit なんかにしちゃうと、 掛算と割算が１つづつ減って、 テーブル参照一発で済むから凄い速そうだが、 さて？
前回のプロファイリング結果で、 用例辞書の検索が 30％も消費していたが、 その部分は作成した当初にキリキリ追い込んでいるので、 これ以上の高速化は、Anthy の構造設計を変えないと困難だと思う。

チューニング後のプロファイリング結果。 anthy.gmon.2011917.png(944KiB)
チューニング後のソースアーカイブ。
（開発中版更新に付き削除）

さて、この高速化パッチは、 原作版 Anthy の ml に送付するべきですかね？ それとも既に死に体だから波風立てないべきですかね？

どうでもいいけれど、 amd64, i386 の場合は gas拡張使って高速化、 とか言う考えが思い浮かんでいたり……。 泥沼になるからやらない方が良いけれど。

Tue,27 Sep,2011、 に続く。

ビックカメラのポイント。
おもちゃは全部ポイント５％らしい。
それ以外だと、 近隣に競合店があると10％、 近隣に競合店が無いと５％、 だった。
ヨドバシカメラなら、 アップル製品と SONY VAIO カスタマイズ品を除き、 10％均一なのに……。

声かけ。
自転車で走っていたら、警官の声かけに引っかかった。 今回はパトカーからで、かつ新人警官では無かった。 まぁ新人警官の現場配属にはちょっと早いけれど。 新人警官が現場配属になると、 まずは一斉に声かけする所から始まるからなぁ。
で。
「防犯登録が無い」と言われた。去年までは有ったのに。 どうやら期限切れになっていたらしい。 こうなると、 身分証の確認やら 自転車が自分の物である事がわかる様な何かの言及とか 必要になって面倒だなぁと思ったら。   身分証の確認もする事無くあっさり済んだ。

ざっと調べてみたら、都道府県によって期間が違い、 ５〜１０年あるいは期限無し、らしい。 期限の長い隣の県に行って登録した方が、後々良さそうだ。

さらにどうでもいいけれど。 防犯登録の際には車体に刻印してある番号も登録するので、 防犯シールを剥がされても防犯登録の検索は可能だったりする。 金属への刻印を磨り潰してまで盗む奴はいないだろうし。

死に体
「死に体」（しにたい）って相撲用語だったのね……。 「レームダック」の意味しか知らなかった……。

Mon,19 Sep,2011

PC の機種選定。
AthlonXP 1.4GHz デスクトップ機（2003〜現在）から、 リースの Pentium3M 1.0GHz（2003〜2006）、 リースの CoreDuo 1.666GHz（2007〜2010）、 を経て、今年（2011年）、 Core i5-450M（数字３桁）2.40GHz の２コア４スレッドのノート機に 新調したのだが、今更だが正直、機種選定を少々しくじったと思う。
ノートPC で FPS MMO はコストパフォーマンスが悪すぎるので、 ノート機はクライアント兼開発機に特化し、 FPS MMO はデスクトップ機でプレイする事にして（金無いから無理だけど）。 ノート機をクライアント兼開発機としてみると GPU は CPU内蔵で十分。 開発機としてみると CPUは最低 2.0GHz で、 できれば 2.5GHz前後のクラスが欲しい。 マルチスレッドなソースコードをいじる事も想定すると ４コア若しくは４スレッドは不要だが、２コアは欲しい、 ただ、純粋なマルチコアの状態が必要なので、 １コア２スレッドは駄目で、かつ HyperThreading は不要。 ソースコードやドキュメントの読み書きを行うには ディスプレイは縦1000pixel以上が欲しいが、 今時は HD か HD+ ばっかりで 1280x1024 な機種は無かったり。 Full-HD は一挙に値段が高くなるし、大きく重くなるし。
そうしてみると、 Atom や Celeron や AMD E* は駄目で、 Core i3，Pentium P*，AMD Fusion，Athlon II，Turion II 辺りになるのかな。
で、新調当時に比較した機種一覧を再度見てみると……、 ２コア 2.0GHz 以上の機種で、当時一番安いのが新調した機種だった。
あれから半年以上たって、 対照機（Pentium P*）が値下がり（３万円台半ば〜後半）しつつ、 購入した機種と同クラス機が Core i?-xxx（数字３桁）から Core i?-xxxx（数字４桁）に モデルチェンジして値上がりした、 だけだったのか。   こうしてみると、ズルズルと値下がりし続けるものなんだなぁ……。

Core i
何故 Core i系PC が値上がりしたのか。 ざっと調べて考えてみると、あっさり理由が判明。

となっていて、性能と名称が新旧でズレていた……。 だから同じ Core i5 でも値上がりするのか……。 でも、細かく見ると、旧と同じコア／スレッド数のモデルもあるなぁ……。

新調した機種の中古買取価格。
ずばり、上限￥16,000- だそうで。 １年で新品販売価格￥69,800- からそこまで下がるのか……。

ASUS K53TA-SX0A6、ジョーシン￥44,800-
AMD A6-3400M(Quad-Core) 1.4GHz-2.3GHz, AMD Radeon HD 6720G2(APU-6520G + GPU-6650G CrossFire), 4GiB*1(MAX:4GiB*2), DVD, 500GB, b/g/n, 1000BASE-T, USB2.0*2, USB3.0*1, 15.6inch 1366x768, D-sub & HDMI, 2.6kg
こう言うの好きなんだよなぁ……。 ただ、2kg越えているのと、CPU が標準状態で 1.4GHz なのが、駄目だけれども。 あと、できれば 14inch で 1280x1024 が良いのだけれども。

acer AS3830T-N54D (Core i5-2410M 2.3GHz)、ビック￥54,800-ポイント5,480-
ポイント有効使用率を 100％で換算すると、 私が買った２〜３代前の機種と同じ値段になる……。
あれ、 Core i5-2410M は２コア４スレッド 2.3GHz、 先代の Core i5-450M は２コア４スレッド 2.4GHz、 なのか。GPU と DMIとやらが高速化されているけれど、 CPU本体はほとんど同じなのか。 ……まぁいいか。

Lenovo G570 433473J/43344SJ Pentium B940(2.0GHz)、ビック￥41,800- ポイント4,180-、ヤマダ￥39,800- ポイント3,980-。
CPU が遅い。もう２割速ければ、ちょうどいい感じなのに。 でも 15.6inch か。ちょっと大きいなぁ。

Lenovo G570 43345XJ Core i5-2410M(2.3GHz,2C4T)、ビック￥44,800- ポイント448-。
それでもまだ CPU が遅い。もう１割速く。 あと、HTは不要。 15.6inch なので、ちょっと大きい。

HP 4420s/CT VM118AV-AGXB Core i3-380M 2.53GHz 2C4T L3:3MiB 7200rpm b/g/n USB2.0*3 eSATA*1 HDMI LED 14.0inch ソフ￥39,800-
HP 4420s/CT VM118AV-AIZA Core i5-480M 2.66GHz 2C4T L3:3MiB 7200rpm b/g/n USB2.0*3 eSATA*1 HDMI LED 14.0inch ソフ￥42,800-
HP 4420s/CT VM118AV-AHZY Core i5-480M 2.66GHz 2C4T L3:3MiB 5400rpm b/g/n USB2.0*3 eSATA*1 HDMI LED 14.0inch ソフ￥44,800-
この辺が割と好み。でも、HTは不要。 あと、2kg台後半〜3kg台前半と重いのが難点かも。
VM118AV-AIZA と VM118AV-AHZY の違いが判らん。 HDD の速度が違うのは判ったが、それだと値段が逆じゃないかなぁ。

Wed,21 Sep,2011

pthread でマルチスレッド。
OpenBSD にて pthread を用いてマルチスレッドにした時に、 本当に複数コアを利用しているのかよく判らない。 

#include <stdlib.h>
#include <stdio.h>
#include <time.h>
#include <pthread.h>

#define MAX_THREADS 8
volatile int var = 0;

void* thread_func( void* arg )
{
    printf("%p %d *\n", pthread_self(), ++var );
    {
        struct timespec rqtp;
        rqtp.tv_sec  = 0;
        rqtp.tv_nsec = 0;
        nanosleep( &rqtp, NULL );
    }
LOOP:
    printf("%p %d\n", pthread_self(), ++var );
    goto LOOP;
    return NULL;
}


int main( int argc, char* argv[] )
{
    pthread_t    thread[MAX_THREADS];

    for (size_t i = 0; i < MAX_THREADS; ++i) {
        pthread_create( &(thread[i]), NULL, thread_func, NULL );
    }
    for (size_t i = 0; i < MAX_THREADS; ++i) {
        pthread_join( thread[i], NULL );
    }

    return 0;
}
を実行して top -s 1 してみたけれど、 コア１つしか 100％にならないし、 pthread_self() の表示も１スレッド分しか出てこない。
はて？

Thu,22 Sep,2011 追記：
OpenBSD のマルチスレッドをマルチコアに割り当てる処理は 未完成らしい？ （かなり不確実で信頼性が無い情報）
あと、明示的にスレッド切り替えを行う関数が入っていない。 sleep() とか nanosleep() とか。

Thu,22 Sep,2011、 Fri,23 Sep,2011、 Sun,25 Sep,2011、 Tue,27 Sep,2011、 Sat,01 Oct,2011、 Tue,04 Oct,2011、 に続く。

Thu,22 Sep,2011

マルチスレッド／マルチプロセス、 Wed,21 Sep,2011、 の続き。
printf() を消して、単純計算するだけにしてみた。
その１： 

/*
    スレッド分岐テスト
*/
#include <stdlib.h>
#include <stdio.h>
#include <time.h>
#if defined(__linux__)
# include <sched.h>
#endif
#include <pthread.h>
#if defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__)
# include <pthread_np.h>
#endif
#if defined(__NetBSD__)
# include <sched.h>
#endif


static int INTERVAL = 0;

void* thread_func( void* arg )
{
    const size_t arg_num = (const size_t)arg;
    const int cpu_num = ((arg_num * INTERVAL) & 0x03);
  #if defined(__FreeBSD__)
    if (0 < INTERVAL) {
        cpuset_t mask;
        CPU_ZERO( &mask );
        CPU_SET( cpu_num, &mask );
        const int ret_psa = pthread_setaffinity_np( pthread_self(), sizeof(mask), &mask );
        if (0 != ret_psa) {
            perror("pthread_setaffinity_np:" );
        }
        printf("%p child(%d)\n", pthread_self(), cpu_num );
    } else {
        printf("%p child(-)\n", pthread_self() );
    }
  #elif defined(__NetBSD__)
    if (0 < INTERVAL) {
        cpuset_t* const mask = cpuset_create();
        if (NULL == mask) {
            perror("cpuset_create:" );
        } else {
            cpuset_set( cpu_num, mask );
            const int ret_psa = pthread_setaffinity_np( pthread_self(), sizeof(mask), &mask );
            if (0 != ret_psa) {
                perror("pthread_setaffinity_np:" );
            }
            cpuset_destroy( mask );
        }
        printf("%p child(%d)\n", pthread_self(), cpu_num );
    } else {
        printf("%p child(-)\n", pthread_self() );
    }
  #elif defined(__linux__)
    if (0 < INTERVAL) {
        cpu_set_t mask;
        CPU_ZERO( &mask );
        CPU_SET( cpu_num, &mask );
        sched_setaffinity( 0, sizeof(mask), &mask );
        printf("%p child(%d)\n", pthread_self(), cpu_num );
    } else {
        printf("%p child(-)\n", pthread_self() );
    }
  #else
    printf("%p child(*)\n", pthread_self() );
  #endif

    {
        struct timespec rqtp;
        rqtp.tv_sec  = 0;
        rqtp.tv_nsec = 0;
        nanosleep( &rqtp, NULL );
    }

    int tmp = 0;
    for (int i = 0; i < 0x7FFFFFFF; ++i) {
        tmp += i;
    }
    return NULL;
}


int main( int argc, char* argv[] )
{
    size_t MAX_THREADS = 0;
    for (size_t i = 1; i < argc; ++i) {
        switch (argv[i][0]) {
        case '0':
        case '1':
        case '2':
        case '3':
        case '4':
        case '5':
        case '6':
        case '7':
        case '8':
        case '9':
            if (0 == MAX_THREADS) {
                MAX_THREADS = atoi( argv[i] );
            }
            break;
        case '-':
            if (0 == INTERVAL) {
                INTERVAL = atoi( &(argv[i][1]) );
            }
            break;
        }
    }

    pthread_t    thread[MAX_THREADS];

  #if defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__)
    pthread_set_name_np( pthread_self(), "Parent" );
  #endif

    for (size_t i = 0; i < MAX_THREADS; ++i) {
        pthread_create( &(thread[i]), NULL, thread_func, (void*)i );
      #if defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__)
        {
            char buf[2];
            buf[0] = '0' + i;
            buf[1] = '\0';
            pthread_set_name_np( thread[i], buf );
        }
      #endif
        printf("%p *\n", thread[i] );
    }
    for (size_t i = 0; i < MAX_THREADS; ++i) {
        pthread_join( thread[i], NULL );
    }

    return 0;
}
/* [ End of File ] */
その２： 
/*
    プロセス分岐テスト
*/
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>
#include <time.h>
#if defined(__linux__)
# include <sched.h>
#endif
#include <pthread.h>
#if defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__)
# include <pthread_np.h>
#endif
#if defined(__FreeBSD__)
# include <sys/param.h>
# include <sys/cpuset.h>
#endif


static int INTERVAL = 0;

void* thread_func( void* arg )
{
    const size_t arg_num = (const size_t)arg;
    const int cpu_num = ((arg_num * INTERVAL) & 0x03);
  #if defined(__FreeBSD__)
    if (0 < INTERVAL) {
        cpuset_t mask;
        CPU_ZERO( &mask );
        CPU_SET( cpu_num, &mask );
        const int ret_csa = cpuset_setaffinity( CPU_LEVEL_WHICH, CPU_WHICH_PID, -1, sizeof(mask), &mask );
        if (ret_csa < 0) {
            perror("cpuset_setaffinity:" );
        }
        printf("%d child(%d)\n", getpid(), cpu_num );
    } else {
        printf("%d child(-)\n", getpid() );
    }
  #elif defined(__NetBSD__)
    if (0 < INTERVAL) {
        cpuset_t* const mask = cpuset_create();
        if (NULL == mask) {
            perror("cpuset_create:" );
        } else {
            cpuset_set( cpu_num, mask );
            const int ret_psa = pthread_setaffinity_np( pthread_self(), sizeof(mask), &mask );
            if (0 != ret_psa) {
                perror("pthread_setaffinity_np:" );
            }
            cpuset_destroy( mask );
        }
        printf("%p child(%d)\n", pthread_self(), cpu_num );
    } else {
        printf("%p child(-)\n", pthread_self() );
    }
  #elif defined(__linux__)
    if (0 < INTERVAL) {
        cpu_set_t mask;
        CPU_ZERO( &mask );
        CPU_SET( cpu_num, &mask );
        sched_setaffinity( 0, sizeof(mask), &mask );
        printf("%d child(%d)\n", getpid(), cpu_num );
    } else {
        printf("%d child(-)\n", getpid() );
    }
  #else
    printf("%d child(*)\n", getpid() );
  #endif

    {
        struct timespec rqtp;
        rqtp.tv_sec  = 0;
        rqtp.tv_nsec = 0;
        nanosleep( &rqtp, NULL );
    }

    int tmp = 0;
    for (int i = 0; i < 0x7FFFFFFF; ++i) {
        tmp += i;
    }
    return NULL;
}


int main( int argc, char* argv[] )
{
    size_t MAX_THREADS = 0;
    for (size_t i = 1; i < argc; ++i) {
        switch (argv[i][0]) {
        case '0':
        case '1':
        case '2':
        case '3':
        case '4':
        case '5':
        case '6':
        case '7':
        case '8':
        case '9':
            if (0 == MAX_THREADS) {
                MAX_THREADS = atoi( argv[i] );
            }
            break;
        case '-':
            if (0 == INTERVAL) {
                INTERVAL = atoi( &(argv[i][1]) );
            }
            break;
        }
    }

  #if defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__)
    pthread_set_name_np( pthread_self(), "Parent" );
  #endif

    pid_t pid[MAX_THREADS];

    for (size_t i = 0; i < MAX_THREADS; ++i) {
        pid[i] = fork();
        if (0 == pid[i]) {
          #if defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__)
            {
                char buf[2];
                buf[0] = '0' + i;
                buf[1] = '\0';
                pthread_set_name_np( pthread_self(), buf );
            }
          #endif
            thread_func( (void*)i );
            _exit( 0 );
        }
        printf("%u *\n", i );
    }
    for (size_t i = 0; i < MAX_THREADS; ++i) {
        waitpid( pid[i], NULL, 0 );
    }

    return 0;
}
/* [ End of File ] */
どちらも、 単純にマルチスレッド／マルチプロセスに分岐して、 各スレッド／プロセスで単純計算するだけの物。
Core i5-450M 2.40GHz〜2.66GHz の HT ２コア４スレッドにて、 FreeBSD 9-BETA3 と GNU/Linux 2.6.32 では、 thread版でも fork()版でも、 だった。 Core i5-xxx で FreeBSD 9-BETA3 の場合、 コア番号 0 と 1 が同一コア内の HyperThreading、 コア番号 2 と 3 が同一コア内の HyperThreading、 らしい。 Core i5-xxx で GNU/Linux 2.6.32 の場合、 コア番号 0 と 2 が同一コア内の HyperThreading、 コア番号 1 と 3 が同一コア内の HyperThreading、 らしい。 HyperThreading には負荷超過で ほぼ２コア２スレッド状態になってしまうらしい。
同 Core i5-450M の HT ２コア４スレッドにて、 FreeBSD 9-BETA3 と GNU/Linux にて、 スレッド／プロセスのコア固定を行わない場合と、 FreeBSD 9-BETA3 を VMWare上で動かしつつ スレッド／プロセスのコア固定を行った場合は、 thread版でも fork()版でも、 だった。 こちらも HyperThreading には負荷超過で ２コア２スレッド状態になってしまうらしい。 ハイパースレッディング駄目じゃん。   FreeBSD で分岐数２の時に GNU/Linux より遅くなるのは、 GNU/Linux の場合にコア番号無指定だと、 非ハイパースレッディングになるように自動的にコア固定が行われている （実状の観測結果に依る。明文化された資料は未発見） のに対して、 FreeBSD の場合にコア番号無指定だと、 ハイパースレッディング／非ハイパースレッディング問わず、 ラウンドロビン？で使用コア番号が変化し続ける為。   VMWare上で動かした場合は、 コア番号の非固定／固定、問わず、 非 HyperThreading となる割り当てを実行するらしい？
Phenom X4 2.0GHz ４コアにて、 OpenBSD 4.8 で実行してみた所、 fork()版では、 だったが、 thread版では、 だった。 fork()版ではちゃんと４コアをフルに使っているが、 OpenBSD の thread版では何故か１コアしか使ってくれない。

NetBSD は環境が無いから試せない。

OpenBSD の thread版だけ、 スレッドを幾つに分岐しても、全スレッドで１コアしか使ってくれないのだが、 何故だろう？ 私は何か思い違いをしているのだろうか？

↑ web で検索していたら。
2ch の UNIX板 OpenBSD スレにて 「OpenBSD のマルチスレッドは未完成」 と言う意味の記述を見つけた。 でもタイムスタンプが 2005年……。

Fri,23 Sep,2011、 Sun,25 Sep,2011、 Tue,27 Sep,2011、 Sat,01 Oct,2011、 Tue,04 Oct,2011、 に続く。

Wed 05 Oct,2011 追記：
Intel自身も、HyperThreading による性能向上は 15〜30％程度、 と見ているらしい（ja.wikipedia.org）。

Fri,23 Sep,2011

あさりよしとお

「プロジェクトＴ」は、思いっきりツボにはまった（笑）。
毒舌の数々は、ゲームや漫画やアニメに限らず色々当てはまるよね……。

マルチスレッド／マルチプロセス、 Wed,21 Sep,2011、 Thu,22 Sep,2011、 の続き。
試しに、 改造版anthy の 文節数最小法／MBRダイクストラ法にて、 malloc()/calloc()/realloc()/free() を、 shmget() & shmat() ／ shmdt() & shmctl() に、 pthread_create() を fork() に、 書き換えてみた。
あっというまに共有メモリのセグメントを使い果たし、 立ち行かなくなった。 しかも他のアプリケーションでシェアードメモリが使用不能に陥る 危険な事態になるし。 ipcs & ipcrm 発動……。
結局、 shm の segment を少数だけ確保して、 libc の malloc/calloc/realloc/free と同様に、 複数のメモリブロックに分割して使わないと駄目か……。 でもそれって、 libc のヒープ回りの処理を丸ごとそっくりデッドコピーする事になって、 時間と労力の無駄だよね……。   何か良いライブラリが無いか探してみるか……。

Sun,25 Sep,2011、 Tue,27 Sep,2011、 Sat,01 Oct,2011、 Tue,04 Oct,2011、 に続く。

Sun,25 Sep,2011

マルチスレッド／マルチプロセス、 Wed,21 Sep,2011、 Thu,22 Sep,2011、 Fri,23 Sep,2011、 の続き。
OSSP mm と言うのを見つけた。
web で検索しても 「apache で使っている」 「PHP で使っている」 と言う話しか見つからなかったが、 mm のソースパッケージに mm_test.c と言うサンプルがあったし、 ライブラリ自身のソースコードもそんなに複雑では無くかつ短めだったので、 まぁなんとか使えた。
プロセス間で共有可能なメモリを生成する手法は何種類か実装されていて、 OS なり環境なりに合わせて使う手法を選択しているらしい。   OpenBSD 4.8-RELEASE/amd64 の場合、 テンポラリファイルを作って mmap する事で、 共有メモリを生成していた。   ライブラリのソースコードを見る限りでは、 OS や環境によっては、 ストレートに普通の SHM を使う場合も有るらしい。
まぁ、 テンポラリファイルに mmap してくれた方が、 SHM 使っている最中に事故って ipcs & ipcrm にお世話になるより安全かな。   ipcs & ipcrm が使えないと にっちもさっちも行かなくなる様なソフトは、 一般公開しにくいし。

Tue,27 Sep,2011、 Sat,01 Oct,2011、 Tue,04 Oct,2011、 に続く。

Mon,26 Sep,2011

1348 TOPIX ETF。
なんか後場後半でぶっ飛んでいる……。
どうやら、日銀の ETF 買い入れが有ったらしいが、 それで板をぶち破ってしまったのだろうか？
よくよく見直してみると、 前場中盤で既に乖離率が上方に 1.5％越え始めているし。

Tue,27 Sep,2011

Anthy、OpenBSD でマルチコア対応。
Sat,17 Sep,2011、 の続き。
マルチスレッド／マルチプロセスの話は、 Wed,21 Sep,2011、 Thu,22 Sep,2011、 Fri,23 Sep,2011、 Sun,25 Sep,2011、 に関連。

学習再生／学習記録、共に無効。 変換内容は毎度お馴染み JNetHack の占いクッキーの先頭100文。
OpenBSD 4.8-RELEASE/amd64，Phenom Quad-Core 2.0GHz。

かな漢字変換ソフトの変換結果ベンチマークテスト：シングルプロセスシングルスレッド／シングルプロセスマルチスレッド／マルチプロセスシングルスレッド
系列 モード変換所要時間うち文節区切り所要時間うち変換候補一覧生成所要時間

試験版 MBRビタビ(HID_IDI_IwDT) 4.51 [秒] 3.12 [秒] 0.117 [秒]

試験版 前方３文節最長一致 1.26 [秒] 0.0574[秒] 0.0887[秒]

開発中版文節数最小 ダイクストラ 左→右方向，１プロセス１スレッド，スレッド制御無し 1.36 [秒] 0.0244[秒] 0.108 [秒]
開発中版文節数最小 ダイクストラ 右→左方向，１プロセス１スレッド，スレッド制御無し 1.35 [秒] 0.0246[秒] 0.109 [秒]

開発中版文節数最小 ダイクストラ 左→右方向，文節区切り候補テーブル生成のみマルチスレッド 1.43 [秒] 0.0588[秒] 0.110 [秒]
開発中版文節数最小 ダイクストラ 右→左方向，文節区切り候補テーブル生成のみマルチスレッド 1.47 [秒] 0.0594[秒] 0.115 [秒]
開発中版文節数最小 ダイクストラ 左→右方向，文節区切り候補テーブル生成のみマルチプロセス 6.91 [秒] 5.42 [秒] 0.115 [秒]
開発中版文節数最小 ダイクストラ 右→左方向，文節区切り候補テーブル生成のみマルチプロセス 6.95 [秒] 5.46 [秒] 0.117 [秒]

開発中版文節数最小 ダイクストラ 左→右方向，文節区切り探索時にスレッド制御有り 1.45 [秒] 0.0376[秒] 0.119 [秒]
開発中版文節数最小 ダイクストラ 右→左方向，文節区切り探索時にスレッド制御有り 1.45 [秒] 0.0395[秒] 0.118 [秒]
開発中版文節数最小 ダイクストラ 左→右方向，文節区切り探索時にプロセス制御有り 1.74 [秒] 0.281 [秒] 0.109 [秒]
開発中版文節数最小 ダイクストラ 右→左方向，文節区切り探索時にプロセス制御有り 1.75 [秒] 0.279 [秒] 0.110 [秒]

開発中版MBR ダイクストラ 左→右方向，１プロセス１スレッド，スレッド制御無し 4.36 [秒] 2.94 [秒] 0.123 [秒]
開発中版MBR ダイクストラ 右→左方向，１プロセス１スレッド，スレッド制御無し 4.63 [秒] 3.21 [秒] 0.125 [秒]

開発中版MBR ダイクストラ 左→右方向，文節区切り候補テーブル生成のみマルチスレッド 4.54 [秒] 3.02 [秒] 0.131 [秒]
開発中版MBR ダイクストラ 右→左方向，文節区切り候補テーブル生成のみマルチスレッド 4.78 [秒] 3.25 [秒] 0.135 [秒]
開発中版MBR ダイクストラ 左→右方向，文節区切り候補テーブル生成のみマルチプロセス 15.26 [秒] 13.72 [秒] 0.128 [秒]
開発中版MBR ダイクストラ 右→左方向，文節区切り候補テーブル生成のみマルチプロセス 15.32 [秒] 13.76 [秒] 0.128 [秒]

開発中版MBR ダイクストラ 左→右方向，文節区切り探索時にスレッド制御有り 4.76 [秒] 3.25 [秒] 0.135 [秒]
開発中版MBR ダイクストラ 右→左方向，文節区切り探索時にスレッド制御有り 5.12 [秒] 3.62 [秒] 0.133 [秒]
開発中版MBR ダイクストラ 左→右方向，文節区切り探索時にプロセス制御有り 5.36 [秒] 3.79 [秒] 0.127 [秒]
開発中版MBR ダイクストラ 右→左方向，文節区切り探索時にプロセス制御有り 5.62 [秒] 4.05 [秒] 0.127 [秒]

備考：
「文節区切り探索時にスレッド制御有り」は、 シングルプロセスシングルスレッドで動作し、 セマフォ等の制御のみ行う。
「文節区切り探索時にプロセス制御有り」は、 シングルプロセスシングルスレッドで動作し、 共有メモリとセマフォ等の制御のみ行う。
「マルチプロセス」，「シングルプロセスでプロセス制御有り」での 共有メモリ消費量は、約7.3MiB だった。

評価：
「文節区切り候補テーブル生成」に関して、 「文節数最小法」でのマルチプロセス化のオーバーヘッドは約５秒なのに 「MBRダイクストラ」では約10秒なのは、 「文節数最小法」ではループを１回、回すだけなのに対し、 「MBRダイクストラ」では枝刈りの為にループを２回、回している為。
マルチプロセスの場合、limit に引っかかって、 「Resource temporarily unavailable」が出て、 abort() する場合が有る。
マルチプロセス化のオーバーヘッドはかなり大きく、 既に十分高速な 「文節区切り候補テーブル生成」や 「文節数最小法」では、 マルチプロセス化でマルチコアを使用しても オーバーヘッドの方が大きくなってしまい、 逆効果らしい。
「文節数最小法」の双方向探索をマルチプロセス化しても、 おそらくオーバーヘッドでかえって遅くなりそう。
残りの疑問点は、「MBRダイクストラ」にて 双方向探索をマルチプロセス化した場合に効果が有るかどうか。


FreeBSD 9.0-BETA2/amd64，Core i5 2-core 4-thread 2.4GHz。

かな漢字変換ソフトの変換結果ベンチマークテスト：シングルプロセスシングルスレッド／シングルプロセスマルチスレッド／マルチプロセスシングルスレッド
系列 モード変換所要時間うち文節区切り所要時間うち変換候補一覧生成所要時間

試験版 MBRビタビ(HID_IDI_IwDT) 2.09 [秒] 1.16 [秒] 0.0572[秒]

試験版 前方３文節最長一致 0.87 [秒] 0.0233[秒] 0.0447[秒]

開発中版文節数最小 ダイクストラ 左→右方向，１プロセス１スレッド，スレッド制御無し 0.91 [秒] 0.0161[秒] 0.0545[秒]
開発中版文節数最小 ダイクストラ 右→左方向，１プロセス１スレッド，スレッド制御無し 0.92 [秒] 0.0140[秒] 0.0533[秒]

開発中版文節数最小 ダイクストラ 左→右方向，文節区切り候補テーブル生成のみマルチスレッド 1.88 [秒] 0.913 [秒] 0.0618[秒]
開発中版文節数最小 ダイクストラ 右→左方向，文節区切り候補テーブル生成のみマルチスレッド 1.90 [秒] 0.954 [秒] 0.0610[秒]
開発中版文節数最小 ダイクストラ 左→右方向，文節区切り候補テーブル生成のみマルチプロセス 4.81 [秒] 3.32 [秒] 0.0769[秒]
開発中版文節数最小 ダイクストラ 右→左方向，文節区切り候補テーブル生成のみマルチプロセス 4.71 [秒] 3.26 [秒] 0.0794[秒]

開発中版文節数最小 ダイクストラ 左→右方向，文節区切り探索時にスレッド制御有り 0.97 [秒] 0.0562[秒] 0.0563[秒]
開発中版文節数最小 ダイクストラ 右→左方向，文節区切り探索時にスレッド制御有り 0.98 [秒] 0.0518[秒] 0.0569[秒]
開発中版文節数最小 ダイクストラ 左→右方向，文節区切り探索時にプロセス制御有り 1.66 [秒] 0.251 [秒] 0.0703[秒]
開発中版文節数最小 ダイクストラ 右→左方向，文節区切り探索時にプロセス制御有り 1.66 [秒] 0.271 [秒] 0.0730[秒]

開発中版MBR ダイクストラ 左→右方向，１プロセス１スレッド，スレッド制御無し 2.02 [秒] 1.06 [秒] 0.0592[秒]
開発中版MBR ダイクストラ 右→左方向，１プロセス１スレッド，スレッド制御無し 2.13 [秒] 1.16 [秒] 0.0635[秒]

開発中版MBR ダイクストラ 左→右方向，文節区切り候補テーブル生成のみマルチスレッド 3.19 [秒] 2.17 [秒] 0.0665[秒]
開発中版MBR ダイクストラ 右→左方向，文節区切り候補テーブル生成のみマルチスレッド 3.41 [秒] 2.40 [秒] 0.0664[秒]
開発中版MBR ダイクストラ 左→右方向，文節区切り候補テーブル生成のみマルチプロセス 9.74 [秒] 8.22 [秒] 0.0872[秒]
開発中版MBR ダイクストラ 右→左方向，文節区切り候補テーブル生成のみマルチプロセス 9.73 [秒] 8.31 [秒] 0.0832[秒]

開発中版MBR ダイクストラ 左→右方向，文節区切り探索時にスレッド制御有り 2.67 [秒] 1.45 [秒] 0.0833[秒]
開発中版MBR ダイクストラ 右→左方向，文節区切り探索時にスレッド制御有り 2.79 [秒] 1.54 [秒] 0.0704[秒]
開発中版MBR ダイクストラ 左→右方向，文節区切り探索時にプロセス制御有り 3.39 [秒] 1.68 [秒] 0.0901[秒]
開発中版MBR ダイクストラ 右→左方向，文節区切り探索時にプロセス制御有り 3.46 [秒] 1.84 [秒] 0.0885[秒]

評価：
FreeBSD でも、マルチプロセスはオーバーヘッドが大きいらしい。
「文節区切り候補テーブル生成」をマルチスレッド化しても、 オーバーヘッドの方が大きいらしい。 OpenBSD の時より更に悪化している。
残りの疑問点は、 双方向探索を２スレッド化した場合に効果が有るかどうか。


MBRダイクストラ双方向探索 ２スレッド２コアを実装した時の所要時間を検討してみる。
現在の所要時間の内訳は、概ね下記の程度だと思われる。

推定ばかりで当てにならないが、 まともな時間計測をしていない為なので、それは置いといて。
さて、これを双方向デュアルコアにした場合、どうなるか。
まず、文節区切り以外の所要時間と、 前処理と後処理は変わらない。
双方向化で、 文節区切りの探索でのスレッド処理のオーバーヘッド、 文節区切りの探索、 用例辞書の該当検査、 の所要時間が半分になると期待して。
1.22 + 0.01 + (0.19)/1 + (0.075 + 0.075)/2 + (0.175 + 0.175)/2 + (0.275 + 0.275)/2 + 0.01 = 1.955秒。
片方向シングルスレッド処理より ７％ 0.145秒 速くなる見込みらしい。 100文でこれなので１文だと 0.00145秒 速くなる見込みらしい。
はてさて、実際はどうなることやら。

Sat,01 Oct,2011、 Tue,04 Oct,2011、 Wed,05 Oct,2011、 に続く。

時計
Sat,23 Dec,2006の続き。
４年９ヶ月前に購入した時計が、 電池切れ警告モードになっていた。 さて、あとどのくらい持つのだろう。

Thu,29 Sep,2011

シャーペン、芯を最後まで使い切ると言う物。 Fri,08 Apr,2011、 Sun,24 Apr,2011、 の続き。
「オ・レーヌ MOL-200」￥189-。
落とすと芯が折れる。必ずと言っていいほど折れる。   先端の芯を最後まで掴む部分と、芯を送り出す部分の間に、 隙間が空いているのだが、ここで折れる。 そして隙間に折れた芯が詰まって、次の芯が出せなくなる。   まぁ、こまかい構造の物を落とす方が悪いんだけどさ……。

時計の電池交換(SR920SW)。
ヨドバシカメラだと￥980-。
ビックカメラだと￥980-。
自分でやるか……。

なんか妙に高いな。酸化銀電池だからか。 LR のアルカリマンガン電池より２倍長持ちらしい。 でも値段は 2.8〜３倍……。
ビックは店舗によってポイント率が違う。
ヤマダは何で店舗が違うとこんなに値段が違うんだ？ maxel は無駄に金メッキする必要無い様な……。

Fri,30 Sep,2011

スターウォーズ広告車両。
掴む部分が、ライトセーバーの刃の部分になっていませんか、それ……。

2011年の４に続く。

↑ FENIX HomePage
← G-HAL HomePage
↓ Mail to, メールはこちらへ
↓ Suggestion Box, 投書箱
↓ BBS, 掲示板 UserName:BBS、Password:BBS
(C) 2011 G-HAL