以前「LDDQU の怪」で書いたことだけど。
こんな命令追加するぐらいなら、MOVDQU でのメモリ読み込みで同じ処理を行うようにして高速化しろとか考えてしまうのは私だけなのだろうか。<略>
なんとなく Banias 系の Merom が SSE3 対応で出るころには MOVDQU と LDDQU の速度差が無くなってそうな予感もするけど。
で、今回 SSE4 のリファレンスを探しているときに、Intel のサイトで見つけたネタ。「インテル Core マイクロアーキテクチャー向けアプリケーションの準備」からの引用。
[LDDQU 命令]
この命令は、インテル Pentium 4 アーキテクチャーでは非常に有用です。アライメントされていないメモリーアドレスから 16 バイトをロードする場合は、MOVDQU ではなく、LDDQU 命令を使用してください。この命令は 16 バイトではなく 32 バイトを読み込み、キャッシュラインが分割されるのを防ぎます。モバイルでは、lddqu は movdqu の単なるエイリアスですから、モバイル・アプリケーションではパフォーマンス上の利点はありませんが、アライメントされていないデータのロード後にストアしても不利にはなりません。インテル Core マイクロアーキテクチャーは Intel NetBurst マイクロアーキテクチャーとモバイル Pentium アーキテクチャーの良い点を組み合わせていますから、アライメントされていないデータをロードするときは常にこの命令を使うようにしてください。
えーと、この記述だけだと Yohna (Core Duo/Solo) では MOVDQU と LDDQU が同じものということしか判らないので、自分でベンチマーク [ ファイル : lddqu.lzh ] を書いてみたところ……どうみても LDDQU と MOVDQU は同じ内部命令へのエイリアスにしか見えない結果が得られた。
MOVDQA の 4 倍の時間がかかってるということは、LDDQU 使うぐらいなら MOVDQA と PALIGNR を使った方が幸せになれるということなのだろう。多分。つーかこの手の予想が当たっても全然嬉しくないんだがなぁ。
昨晩放映されてた「ゼロの使い魔」と「僕らがいた」を流しながら Intel AP-922 8x8 IDCT コードの SSE4 化検討作業をしているのだけど。ゲラゲラと笑いながらやっているせいでちぃとも作業が進まない。
とりあえず pshuflw と pshufhw & pshufd を使っていた部分を pshufb に単純に置き換えてみたのだけど、悲しいことにかえって遅くなってしまった。Software optimization resources の "4. Instruction tables" あたりの実測値だと pshufb は throughput が 3clk らしいので AP-922 のように列処理につき最低 4 回呼び出す必要があるものだと厳しいか。
後は行処理の方で pmulhrsw を使えないか調べてみて……こちらは多分高速化すると思うのだが、元々のコードが pmulhw で精度を出すためのハックがかなり入ってるせいで pmulhrsw を入れるためにはそいつらを取り除いて本来あるべきだった姿にもどさなきゃならんからなぁ。
AP-922 のアルゴリズム詳細は昔調べて理解したつもりになった記憶があるんだけど、もう忘れてしまっているのが痛いよなぁ。きちんとメモを残しておけばよかった。
昨日遊んでいた Intel AP-922/945 8x8 IDCT コードの SSE4 化検討がとりあえず片付いたので、コードを投棄。[ファイル : idct_ap922_sse4.lzh]
水平方向の IDCT 処理に pshufb が使えないかと試してみたけど、そちらはかえって処理に時間がかかるようになってしまったので、手を入れずに放置。垂直方向の IDCT だけ追加命令の pmulhrsw を使う形で書き直してみた。
結果はというと 8M 回の呼び出しでの処理時間短縮が 10〜20 msec 程度。正直あんまり嬉しくない。精度はほとんど変わらないのでやらないよりもマシなのだけど作業時間に見合う成果かどうかと問われるとビミョー。
MPEG-2 デコーダは今のところ別方面での作業を優先して進めているので、そちらが形になるまでコレを組み込んだ VFAPI Plug-In はでてこない予定。
7/31 に第1期が終了したシュローダー BRICs 株式ファンド [20312061] の運用報告書が届いていたのを、ようやく時間ができたので読んでみた。感想、ひでぇ、こんなのアリ?
いろいろと言いたいことがあるのだけど、白眉は次のフレーズ。
需給環境の悪化や政治的不透明感が漂うブラジル市場や、高値警戒感が燻るインド市場には慎重な投資姿勢を継続しました。以上の考えの下、当期のファンドの運用では、参考指数に対してロシアと中国をオーバーウェイト、ブラジルを中立、インドをアンダーウェイトとする戦略を継続しました。
地域別組み入れ比率が 31.3% (期末時点、3月には 35% を超えていた) でトップのブラジルへの投資態度が「中立」な戦略で「慎重」な投資姿勢ですかそーですか。
組み入れ銘柄を眺めてまたびっくり。インデックスファンドやインデックスファンドのワラントに金突っ込んでるよ。ワラントに関しては詳しくないので評価を差し控えることにして……インデックスファンドの件だけど。
確かに国別比率を 25% 前後で固定して BRICs 内部でインデックス運用してくれるファンドがあれば投資したいと思うけど、それは信託報酬が 1% 以下ならばの話で、知らない間にファンド・オブ・ファンヅになってるような投信に 2% 近い信託報酬を払う気にはなれない。(2% + 投資先インデックスファンドで追加信託報酬なんてありえない)
というわけで、投資比率を 5% まで削減。一昨日注文を出して昨日の基準価額 10,701 で約定。一応は利益が出る形で売却できたから満足することにしよう。
某電波 を形にするべく作業をしているのだけど進みが遅い。構成をいじるので古い VFAPI Plug-In のコードを使えなくなっているという問題はあるのだけど、1ヶ月以上時間を費やしてまだビデオデコーダ単体すらできあがってないのは問題だよなぁ。
これが終わるまではひぐらし祭囃子編とペルソナ3に手を出さずにいようとニンジンを鼻先に吊るして作業をしているのだが……とりあえずこの週末にできる限りを進めよう。枠組みは固まってるのだし心を動かさずにコードを書いてけば進みも速かろう。18 日までにデコーダ単体を片付けること目標。
某電波は MB のパース部分で分岐を可能な限り除去しようとした結果、コピー & ペーストで大量の関数を書かねばならなくなりそうで、煮詰まってしまい目標どおりには終わりそうになくなっている。そんなわけで現実逃避。
「鬼畜王ランス」(1996, アリスソフト) が「配布フリー宣言」を受けて配布可能になったとの事なので、BIN+CUE.zip を配布してみる。
流石に 600M 近いファイルを 10Mbps 共有回線で HTTP 配布する勇気はないので BitTorrent での配布になる。以下、利用手順。
一応約束事のようなので「18 歳未満の方は、上記ダウンロードを行わないでください」を守るようによろしく。
当初推奨していた μTorrent は、サーバー側のシーダーと相性が悪いらしく、頻繁に接続が切断されてスループットが出ないため推奨クライアントを bitCommet のバージョン 0.70 に変更。
bitCommet の最新バージョンは 0.71 だけれども、私が試した限りではトラッカーとの接続ができなかった。0.70 であれば特に問題なく接続・ダウンロードができたので、こちらを推奨。
9/18 更新 - アーカイブ構成変更 (マニュアルPDFおよび配布フリー宣言テキスト追加) に伴い、torrent ファイルへのリンクを変更
当初は簡単にできるだろうと思っていたのだけど、ドキュメントは少ないし、公式ソフトは python 製で --help を実行しても結果が出てくるまでに 5 秒以上待たされるしで嫌になった。そんなわけで、鬼畜王のためにでっち上げた BitTorrent 環境の構築方法をメモとして残しておく。
BitTorrent でのファイル配信のためには、「トラッカー」と「シーダー」が必要になる。「トラッカー」は .torrent ファイルに結び付けられた P2P 環境 (BitTorrent 用語ではスワームとかいうらしい) 情報のマネージメントを担当するソフトウェアで、「シーダー」は「トラッカー」に接続した BitTorrent クライアントのうち、配布ファイルの完全なコピーを保有している物を指す。
一般的な BitTorrent 環境では「トラッカー」として (著作権に触れてるコンテンツもザクザク登録される) 「公開トラッカー」が利用され、「シーダー」にはユーザが利用している BitTorrent クライアントが利用される。が、データセンターに置かれた固定 IP UNIX マシンの root で、合法コンテンツの配信負荷を下げるためだけに BitTorrent を利用したい者は「シーダー」と「非公開トラッカー」をデータセンターの固定 IP マシンで動かしたいと思うはずだ。
このメモはその荊の道を歩もうとする (& スクリプト言語の重さが嫌でネイティブアプリスキーなオールドタイプ) 人間がどのように目標としていた環境を構築したかを記録するものである。
ソフトウェア名 | バージョン | インストール方法 | |
トラッカー | BNBT | Beta 8.1 | /usr/ports/net-p2p/bnbt/ 以下で make install |
シーダー | CTorrent | 1.3.4 (2) | /usr/ports/net-p2p/ctorrent/ 以下で make install |
利用ソフトウェア |
利用したソフトウェアおよびそのバージョンは上記テーブルの通り。後は man bnbt(1) と man ctorrent(1) を参照して設定すればおしまい……と言えればよかったのだが……どちらも man などという高尚なものは用意されていない。以下順に設定を説明していく。
ディレクトリパス | 格納ファイル等解説 |
/usr/local/etc/bnbt/ | bnbt.cfg, users.bnbt, tags.bnbt, dstat.bnbt BNBT の設定ファイル等を格納 ports の標準インストール先 |
/usr/local/etc/rc.d/ | bnbt.sh BNBT の起動スクリプトが格納される ports の標準インストール先 |
/var/log/bnbt/ | YYYY-MM-DD.log 等 BNBT のログファイルを格納 prots の標準インストール先 |
/home/torrent/torrents/ | *.torrent *.torrent ファイルの格納先 bnbt.cfg の allowed_dir および bnbt_upload_dir に設定 |
/home/torrent/archive/ | 不明 bnbt.cfg の bnbt_archive_dir に設定 |
/home/torrent/file/ | 不明 bnbt.cfg の bnbt_file_dir に設定 |
/home/torrent/seeds/ | オリジナルファイル オリジナルファイルの格納先 ctorrent の起動時に保存先として指定 |
ディレクトリ構成 |
BNBT および CTorrent が利用するディレクトリ構成は上記テーブルの形を選択した。設定ファイル等の格納先は ports の標準インストール先をそのまま利用している。*.torrents やオリジナルファイル等の格納先として /home/torrent/ 以下を利用しているのは /home のマウントされているパーテーションの空き容量が最大だったためで深い意味はない。また、格納ファイル不明な archive および files が存在しているが、これは BNBT の設定ドキュメントを見てもどのように使われるのか不明だった項目。設定しない場合 BNBT が正常に動作しなかったのでやっつけで設定している。
BNBT の実際の設定は以下の手順で行った。
出力された bnbt.cfg に加えた変更点を以下に示す。
allowed_dir = /home/torrent/torrents/ # ディレクトリ構成で選択したものを設定 bnbt_archive_dir = /home/torrent/archive/ # 同上 bnbt_comments_file = /home/torrent/comment.bnbt # 不要っポイけどとりあえず設定 bnbt_compression_level = 0 # インストール当初、実行時に警告がでていたので設定 bnbt_file_dir = /home/torrent/file/ # ディレクトリ構成で選択したものを設定 bnbt_force_announce_on_download = 1 # 不要っポイけどとりあえず設定 bnbt_force_announce_url = http://ホスト名:6969/announce # 同上 bnbt_guest_access = 3 # 未登録ユーザによるサインアップ等を禁止 bnbt_static_footer = /usr/local/share/doc/bnbt/footer.html # 標準インストール先を指定 bnbt_static_header = /usr/local/share/doc/bnbt/header.html # 同上 bnbt_upload_dir = /home/torrent/torrents/ # ディレクトリ構成で選択したものを設定 bnbt_keep_dead = 1 # シーダーが 0 でもトラッカーに登録されてる torrent を表示 parse_allowed_interval = 300 # 直接 *.torrent を置かれた場合のために 5 分に一度監視する
上記は変更点のみで、BNBT が標準で出力したものをそのまま利用する設定項目は載せていない。また # 以降のコメント部は実際の bnbt.cfg には記述していない。さらに、「ホスト名」に関しては実際のホスト名に書き換えることを忘れないように。
とりあえずここまで設定が完了し、BNBT の WEB インタフェースが利用可能になった時点で、普通に Windows PC に BitTorrent クライアントをインストールし、*.torrent ファイルの作成、トラッカーへの (WEB アップロードによる) 登録、別 PC からのダウンロードが正常に行えるか確認しておくことを推奨する。ドキュメント読んでも何が必須設定で何がオプショナルな設定なのか判らず、BNBT をまともに動かすまで私はそれなりに苦労したので。
「トラッカー」の設定が完了したら、次は「シーダー」として利用する CTorrent の設定を行う。まず、hoge というファイル名のオリジナルファイルから hoge.torrent ファイルを作成する場合、以下のコマンドを実行する。
ctorrent -t -u http://ホスト名:6969/announce -s hoge.torrent hoge
ここで作成した hoge.torrent を「トラッカー」に登録したら、次は以下のコマンドを実行して「シーダー」を稼動させる。
ctorrent -f -e -1 -s hoge hoge.torrent > /dev/null &
この状態で「トラッカー」の WEB インタフェースを確認し、hoge の Seeders 欄が 0 から 1 に増えていれば「シーダー」の起動および「トラッカー」との接続も成功。後はクライアント PC 側から hoge.torrent でのダウンロードを行って、正常にダウンロードできればシーダーとしての動作も問題ない。
一応 -e オプションの説明をしておく。CTorrent はシーダーとしての稼動後、"-e 時間" オプションで指定した時間が (指定しなければ 72 時間) 経過したら自動的に終了する。純粋に「シーダー」としてのみ稼動させたい場合、サーバーの起動からシャットダウンまで延々走り続けていて欲しい。ドキュメントは無いのでソースを確認してみたところ、-e オプションで cfg_seed_hours にマイナスの数値を設定した場合「シーダー」として延々動き続けるようなので、"-e -1" を設定している。
"-e -1" でサーバーのシャットダウンまでシーダーがバックグラウンドで走り続けるようになったので、次はサーバー起動時に自動的にシーダーを起動させるための設定。とりあえず以下のような起動スクリプトを /usr/local/etc/rc.d/btseed.sh に書いた。
#!/bin/sh # Add the following line to /etc/rc.conf to enble bittrent seeding # # btseed_enable="YES" # . "/usr/local/etc/rc.subr" name="btseed" rcvar=`set_rcvar` command="/usr/local/bin/ctorrent" seed_dir="/home/torrent/seeds" torrent_dir="/home/torrent/torrents" required_dirs="${seed_dir} ${torrent_dir}" load_rc_config "$name" : ${btseed_enable="NO"} : ${btseed_flags=""} for seed in "${seed_dir}/*" do target=`basename ${seed}` command_args="-f -s ${seed_dir}/${target} -e -1 ${torrent_dir}/${target}.torrent > /dev/null &" run_rc_command "$1" done
これで、/etc/rc.conf に btseed_enable="YES" の行を追加すれば、サーバ再起動時にも自動的に ctorrent が「シーダー」として起動するはず。
一応スクリプトの大雑把な解説をしておくと、ディレクトリ構成で選択した /home/torrent/seeds/ ディレクトリ以下にある全ファイルに対して、/home/torrent/torrents/ ディレクトリに存在するはずの、ファイル名+.torrent ファイルのペアを指定して ctorrent を「シーダー」モードで起動することを意図したものになっている。
課題としては、まだ単一ファイルでのテストしかしていないので、複数ファイルの配信を行う場合にホントにこのスクリプトで大丈夫なのか判らない点。seed 毎に pidfile を設定する必要があるかも。
とまあこんな感じで BitTorrent 配信環境を構築した。まだダウンロード数が少ないのでアレだけど、同時接続クライアントが 1 つだけなら通常の HTTP 配信と同じ帯域しか消費せず、同時接続クライアントが増えても消費帯域が増加せず、クライアント側ダウンロード時間も増加しないのは 100M 超のファイルを配布しようという場合に現実的な選択肢なんじゃなかろうか。
現在の問題としてはサーバー側「シーダー」として利用している CTorrent が μTorrent 1.6 と相性悪いらしく、peer 間接続が頻繁に切断されてスループットが出ない点。bitCommet 等別のクライアントを使えば問題は出ないのだけど……個人的には μTorrent の GUI の方が好きなだけに惜しい。どちらの問題なのかが判らんのがなぁ。
後は BNBT/CTorrent 共に root で動いてるところが課題。本来なら torrent とかの制限ユーザを作ってそちらで動かすべきだろう。
最近の BitTorrent クライアントには DHT という「トラッカー」なしで動作するモードが用意されている。DHT では BitTorrent クライアント同士が直接 *.torrent に格納されているハッシュ情報を交換することで「トラッカー」なしでもファイルの共有ができるようになっている。
DHT を有効にしている場合、クライアント同士で直接通信を行い DHT ネットワークを構成する。bitComment 0.70 や μTorrent 1.6 では DHT のノード数に特に制限は設定されていないようで、参加クライアント数の多い DHT ネットワークに接続した場合 DHT ノード数は 200〜 300 に到達することがある。
通常の利用でこれが問題になることはないが、NEC の無線ルータ (Aterm WR7850 等) の内側で BitTorrent の DHT を有効にした場合、NAT テーブル溢れという深刻な問題を引き起こす。DHT では各ノードに対して、最低 1 回は接続を行い、通信する必要が発生する。このとき、ルータの内部では NAT テーブルとよばれるものに、接続元IP:ポートと接続先IP:ポートが登録され、この情報を利用してパケットの中継を行うようになる。
200 から 300 のノードで構成されている DHT ネットワークにルータ (NAT) 経由で接続する場合、NAT テーブルを 400 〜 600 エントリー占有してしまう。通常のルータは NAT テーブルの最大サイズが 4096 〜 65536 程度であるため、400〜600 程度消費しても問題はおきないのだが、NEC 製ルータだけは NAT テーブルのサイズが極端に小さいため、DHT ノード数が 200 程度のネットワークに接続しただけで NAT テーブルを全て消費しきってしまい、それ以降 (NAT テーブルからエントリーがタイムアウトによって消去されるか、ルータを再起動するまで) あらたな外部との通信が一切できなくなってしまう。
この問題を回避するためには、以下の対策のいずれかを実行する必要がある。
個人的には 3 つめの選択肢を推奨したいが、ここの鬼畜王 をダウンロードするだけなら 1 つめの選択肢でも問題は解決できるはずだ。
あ〜、Aterm WR7850 にこんな罠があったとは。またルータ買いなおしか…… (今までの変遷は LinkSys - Corega - NEC という状況 orz)
ファイルを追加。「ランス4.1」(1995, アリスソフト) および「ランス4.2」(1995, アリスソフト) のマルチプラットホーム版 CD イメージを鬼畜王同様に BitTorrent からダウンロード可能にした。
前回同様に、アーカイブの中身は BIN+CUE 形式の CD イメージ。今回からマニュアル PDF と「配布フリー宣言テキスト」をアーカイブの中に追加している。
というわけで複数ファイル配信環境になったのだが、前回 の「シーダー」起動スクリプトはやはり単一ファイル配信時にしか正しく動作してくれなかったので、修正が必要だった。修正後のスクリプトを以下に載せる。
#!/bin/sh # Add the following line to /etc/rc.conf to enble bittrent seeding # # btseed_enable="YES" # . "/usr/local/etc/rc.subr" name="btseed" rcvar=`set_rcvar` command="/usr/local/bin/ctorrent" seed_dir="/home/torrent/seeds" torrent_dir="/home/torrent/torrents" required_dirs="${seed_dir} ${torrent_dir}" load_rc_config "$name" : ${btseed_enable="NO"} : ${btseed_flags=""} for seed in ${seed_dir}/* do target=`basename ${seed}` command_args="-f -s ${seed_dir}/${target} -e -1 ${torrent_dir}/${target}.torrent > /dev/null &" pidfile="/var/run/ctorrent.${target}.pid" run_rc_command "$1" if [ $1 = start ] then echo $! > $pidfile fi done
変更点は、seed ループのリストからダブルクォーテーションが外れたところとか、pidfile を各 seed 毎に明示的に指定して、さらに pidfile を起動スクリプト内部で作成するようにしたところとか。
pidfile の作成部分はもう少しスマートなやり方があるような気もするのだけど、そこまで追求する気力がなかったのでやっつけで対処。
とりあえずこの方法でも配布ファイル数が 100 未満なら何とかなるけど、torrent ファイル 1 つにつき、ポートを 1 つ占有しているので 100 以上のファイル配布には向かないと判断している。
バックグラウンドプロセスとして UI なしで動作する「トラッカー」兼「シーダー」なアプリケーションがあれば理想的なのだけど……未だに発見できていない。せめて複数ファイルでも「シーダー」が 1 つで済むようになればいいのだけど。
rtorrent が UI なしで動いてくれればそれで多分問題は解決するのだけど……ドキュメントを読んだ限りでは望み薄なのがなぁ。
Aterm WR7850 を窓から投げ捨てて、投売りされてた NTT-ME の MN8100WAG の在庫を拾った。でー ISP が DION なおかげで PPPoE の認証オプション either が自動認識じゃない (CHAP しか試そうとしない) 問題を踏んだのと DoS 防御やら SPI やらの誤検出を踏んだ他は特に問題なく、BitTorrent の DHT 有効時の NAT テーブル溢れは解決した。
IEEE802.11a が J52 規格で W52/W53 に対応していない (既にルータからの撤退を発表しているメーカ自身が対応しないと明言している) という問題はあるものの、現状 11g しか使っていないので 11a を無効にすることで対処。
まあ、あれだ。PPPoE で認証方式が標準で CHAP にしか対応してないルータを出してる時点で……ユーザーからの問い合わせが殺到したんだろうなぁ……サポートコストがものすごいことになったんだろうなぁ。そりゃ撤退する羽目になるわ。おまけに設定はコマンド手書きだし。
簡易 DNS 機能 (DHCP 管理下マシンの名前解決および逆引きが可能) とかはごく一部のユーザ (ローカルに UNIX マシンがあって、/etc/host や samba 以外でローカルの名前解決をしたい) には嬉しいのだけど……そんなユーザはホントに極一部だし。
機種選択の際、IO-DATA/BUFFALO で最近のルータ事情を調べてみたのだけど、どうやら NAT テーブルサイズは 4096 が最低ラインだというのは私の誤解で 2048 でも高級品扱いらしい。BAFFALO では NAT セッション数を無線ルータの仕様に載せていないし、有線ルータの側でも 800/2048 の2モデルしか用意されてない。IO-DATA の無線ルータにいたっては……NAT 同時セッション数 253 などという正気を疑いたくなる数字ががががが仕様に書かれているるるるる。
NAT テーブルの最大サイズを小さくすることで稼げるメモリや処理速度なんて微々たるものではなかろーかと思うのだが……世の中コスト削減がきびしいのかね。
一応地道に作成は続けている。まだ MB パーサーを作っている最中なのだが、どうやら最終的に MB パーサーのバリエーションは 80 個になるらしい。ピクチャヘッダの段階で決定可能な分岐は全て除去しようと何も考えずにコードを書いていたらおそろしいことになってしまった。
んで、ここまで作業を進めての感想。ネームスペース使いたい。テンプレート使いたい。今回趣味のコードだしとことん趣味に走って C++ は使わずに C とインラインアセンブラだけで書いているのだけど、既に何度目になったか数え切れないほどの後悔をしている。
実際、時間を吸い取られ始めて3週間目に突入してる MB パーサのように、420/422/444 で共通なロジック部分と個別なコア部分で直交しているところとかはテンプレート使えればもちっと判りやすく書けるのに。流石にコピペはアレすぎるので別ヘッダファイルに書いた同名インライン関数という邪法を使って何とかしようとしているのだが、これはこれで *.c ファイルが (同時にグローバルシンボルも) 増えるっつー欠点があるのがなぁ。
含み+確定損は一ランクステージアップして、100〜120 を彷徨っている。今日の上昇で多少回復したものの、それでも損益分岐点は遠い。そろそろまじめに確定申告での損失繰越の手続き方法を調べるべきかもと考えはじめている。というわけで、8/28 以降の取引履歴。
8 月中の取引に関しては、キャンペーン手数料の 20 万以下 100 円を生かして、塩漬け中の SBI から小遣いを稼ごうという趣旨のもの。このころはそこそこうまく立ち回れていたと思う。
9 月に入ってから、キャンペーン手数料が終了したのでアクティブプランに切り替えたのだけど……手数料を回収するために大きく張って細かく抜こうと方針変更したのがまずかった。特に 9/5 の取引が最悪。それまで親会社のソフトバンクが持ち株を放出したにも関わらず、日経 225 新規採用期待で上昇を続ける形になっていた状況で、どーせ SBI だし簡単に買い戻せるだろうと前場で売却したものの……いよいよ日経平均の銘柄入れ替え発表かということで急騰。採用後においていかれることに恐怖して仕方なく 14:00 に買い戻し。が、蓋を開けてみれば日経 225 平均には不採用で、あわてて買い戻さずとも翌日には買い戻せたという落ちがつく始末。あー今まで SBI の何を見ていたのだろう。この半年間の輝かしい実績を見て、正しく信頼することができていればあわてて買い戻すなどという愚行をせずに済んだはずなのに。翌日は何もする気力が起きなかった。
そんなこんなで、9/7 からはアクティブ手数料なのだから一度の取引で完結させる必要は無いと思い直して、売却・購入共に分割して行うことにした。大きく張ると狼狽しがちになるようなので。
しかし、そんな細かな取引を続けていても底値を這うばかりの SBI の値動きに嫌気がさし、9/19 に SBI 5 株を売れば三菱商事 100 株が買える値段になった際に SBI の保有枚数の 1/4 を売却。三菱商事およびエスペックへ分割して乗り換えることにした。
9/21 にはアコムの配当利回りが SBI の中間配当利回りを超えたのでさらに SBI の保有比率を下げてアコムを増やした。悪材料が続いてるとはいえ、PBR 0.8 倍割れの黒字企業。ここから大きく下げることはないだろうとの判断。
今日の値動きを見る限りだと、アコムへの変更は微妙だけど、三菱商事およびエスペックへの変更は妥当な判断だったらしい。2ch の SBI スレッドでは (特に、日経の上昇を横目に前日比マイナスになったときとか) 怨嗟の叫びがあがってたからなぁ。
ここ一月ほどの間に買って読んだ本とか。
「図書館内乱」と「レインツリーの国」に関して、ハードカバーは場所をとるから嫌いなのだけど、この作者の作品が好きな以上は仕方がないかと言うことで我慢しつつ購入。「図書館戦争」から入って「空の中」と「海の底」もハズレではなかったので。
「図書館戦争」を読み終わったあと、ひとつの物語としての完成と充足を感じていたので「内乱」は蛇足を心配したのだけど、読みはじめればそんな心配は杞憂に終わり、ケラケラと笑いながら楽しんで読むことができた。次が出ればそれも買うだろう。
「レインツリーの国」は笹本 祐一の「妖精作戦」シリーズを読んだことがある人間として読んでしまったので、余計なギミックに囚われているのかもしれないけど十分に楽しめた。
「ローマ人の物語」は、特に 27 巻 [すべての道はローマに通ず・上] を読みながら、ここ1年間ほど、自分が義務を果たしていたかどうか、為すべきことをしていたかどうかについて省みてしまった。当然のこととして義務を果たし、営々と積み重ねること 400 年。街道を築き上げ、それが帝国となった人々。彼らに対して恥じることなく向き合うことができるかどうか。
そういうわけで、精神のバランスを取るべく「ゼロの使い魔」の既刊全てを購入して読んでみたり。最新刊の 9 巻は近場の書店では売り切れていたので、池袋でジュンク堂と西武LIBROととらのあなをめぐって空振り、新宿へ向かって紀伊国屋書店南口店で在庫に邂逅。10/10 に増刷という話だったので、神保町まで回って見つからなければそれまで待つかと思っていたのだけど、新宿で在庫に出会えたのは幸運だった。
「すべての道はローマに通ず」で「このままじゃいけない」とプラス方向に振れていた気持ちを見事に「このままでいいんだ」の中立方向に戻すことに成功。人としては間違っているような気がするけど、仕合せな人生を送り、精神の健康を保つためにはこちらの方が良かろう。