過去の独りごち/独りごとはこちら
過去のJavaアプレットは
こちら

 

4/30 人間、失格

 このサイトも丸一年も放置してしまうし、サイト運営者としても失格です。トホホ。

 それでも一応、サーバーから撤去されない限りはこのサイトはあり続けるんですが。…引越しの予定はありますけどね。

 環境の変化に伴い自宅の電話を止めたので、ISPとしてのサービスを受けずにレンタルサーバーとして使っているものでして、レンタルサーバーの使用料金としてはいささか高額なチャージを要求されてしまってます。

 さて、久々にPCを新調しました。六號機Reffiの完成です。Gauntletの次が続かなかったなんて(血涙)

 ともかくAthlon64x2でデュアルコア生活がはじまりました。あまり期待はしていなかったのですが、バックグラウンドで何か動かしながらでもフォアグラウンドの処理に影響があまり出ない、というのはなかなかに嬉しいものです。ゲームしながらWeb見ててもブラウザの動作が重くなる事をほとんど感じません。

 動画のエンコードや、3DCGのレンダリングをさせながら、他の作業にもPCを使いたいという向きには最適のようです。動画のエンコードをする趣味は無いですし、3DCGもご無沙汰なもので、僕にはあんまり関係ないんですが、多少とはいえ折角多めにお金を出して、良いものを買ったのだから、しばらくぶりにやってみようかなぁという気にもなるのが不思議です。

 そんなわけで、マルチスレッドネタを早速ひとつ。


toPNG.zip
(ソース+バイナリ 271KB)

 BMPファイルの群れをPNGにしたかったんですが、PNGへの変換を1ファイルずつやる様を見て、これはデュアルコアなら、2枚ずつやれば2倍早くなるのではなかろうか、と欲の皮が突っ張った結果です。PNG変換用のスレッドを最大2つ作り(ソースの定数を書き換えれば16でも256でも行けますけど)複数のコアに同時に鞭打って働かせます。

 ためしに、1280x1024サイズのBMP129枚を、もっとも重くなるオプション(フィルタ最適,圧縮率優先設定)で変換したところ、1スレッドでは約78秒、2スレッドでは約40秒と、ほぼ半分の時間で変換できました。しかし、2スレッドで変換してる間は(当然ですが)PCが異様に重くなってしまうので、「ながら作業」が出来なくなってしまいますが…

 それから、SSE対応ということで、SSEネタも…

 いやまあ、SSE対応になったのは以前のPentium4マシンになってからなんですが、ええ。

 
mandelbrot_sse.zip
(ソース+バイナリ 252KB)

 一体何年ぶりだか作った本人も記憶が覚束ないのですが、3DNow!によるマンデルブロ集合描画プログラムが有ったので、それを掘り起こしてSSEに対応してみました。ちなみに、本当に使っているシステムがSSEに対応しているのか?という事を面倒くさがってチェックして無いので、SSE非対応のシステムで動かしたら何が起こるかわかりません…ほんとに。

 今更言う事でも無いのですが、何気にDelphi6もSSE対応インラインアセンブラを搭載していまして、SSEでゴリゴリと楽しく妖しくプログラミングが出来てしまいます。Delphi3の頃がこのプログラムを初めて作った時期だったと思われるのですが、当時はSSEはおろか3DNow!もMMXもインラインアセンブラがサポートしてなかったので、MMX対応用のユニットはH.Gotou氏の作られた物を流用させていただき、3DNow!対応部分だけAMDの技術資料を見ながら自分で書き足して、DW, DB擬似命令をフル活用して3DNow!を必死で使っていた記憶があります。

 おっと、プログラムの生い立ちは別にどうでもいいことでした。今回はSSEで4つのSingle型の演算が出来るようになったという事で、4ピクセル同時に収束計算を行ってます。3DNow!の時は2ピクセル同時演算だったので、全く順当な、ひねりの無い進化というものです。

 結果としては、「ベンチマークモードon」の時、「初期位置に戻す」を選択した際の所要時間を計測したところ、SSE使用時38ms, 3DNow!使用時48ms, インラインアセンブラ非使用時(x87使用時)142ms という結果になりました。x87使用時でも相当に高速です。今、過去のひとりごちを掘り出して調べたところ、K6-2 333MHzでは3DNow!を使っても350msという結果でしたから、時代を感じるというものです。

 しかし、2ピクセルから4ピクセルになっても2倍早くなったというわけでは無いんですね。むしろ、SSEと3DNowのスループットの違いも影響しているんでしょう。K6-2における3DNow!はほとんどの命令が1クロックで実行可能であり、加算、乗算などは2つの実行ユニットを持っていたためパイプラインのストールを考慮しなければ1/2クロックで実行可能だったと記憶しています。

 それに対してSSEは、僕があんまりSSEのことを知らずに適当に書いているので、アルゴリズムの改良に比例した結果が残せませんでした…と。だって、intelのサイトの目に付く所にSSEの読みやすいリファレンスが転がってないんだもの。intelのC/C++コンパイラのイントリンシックとか解説されてもDelphi野郎なので困ります。

 薬品は子供の手の届かないところに、リファレンスマニュアルはデベロッパの手の届くところに、置かれるべきなんです。と、責任転嫁。

 ところで、ここしばらく太宰にハマっています。

 僕は作品より作家に拘って小説を選ぶという、ありがちながら困った癖があるもので、青空文庫に収められている太宰作品を五十音順に読破しにかかっています。代表作を発表年順に拾い読みするのが良いのかもしれませんけれど、名の知れた代表作だけ抜き出して読んでしまうと世間がその作家に対して貼り付けたレッテルを詳細に見ているという程度になってしまうで、それによって自分にとっての作家像を築き上げてしまうのは勿体無い行為ではないでしょうか、と。代表作というのは得てして長編が選ばれますし、時間対効果(どんな?)比を考えると、「とりあえず目に付くものは全部」読んだ方が代表作だけ読むのに比べて良いのではないかとも思えます。

 以前にはまった作家というと、宮沢賢治が特に挙げられるのですが、自然との対話をベースにした、純粋あるいは純朴で、自然の色彩に満ち満ちた宮沢作品とは対照的に、太宰作品は退廃的で官能的な作品もあれば、文学とは何か?という自問自答もあります。

 「人間失格」に代表されるいくつかの「いわゆる太宰文学」では鬱々とした自己否定や漠然とした不安を抱えながら、それに立ち向かえず享楽的な方向へ向かってしまう、意志の弱い人間像がありありと描かれています。現代の都市に生活する我々にちょうど相応しい文学ではないかと、あまり文学作品を読んだことも無いのに思ってしまいました。

 また、「ヘタ」な作品も混ざっているのが面白いところです。日銭稼ぎのために筆名を変えて書いたという「断崖の錯覚」などは太宰自身、この作品を恥としていただけに壮烈極まるヘタさ加減です。ただ、端々に切れ味の鋭いセンテンスが挟まっているのがまたなんとも。いやまぁ、彼が書いたと分からないようにわざとヘタに書いたものの、自身のプライドが許せずにしばしば鋭い爪を現すといったところなのかもしれませんが…宮沢賢治がヘタな文で何か綴っても、クレヨンを力強く握り締めて、一気に書き上げたような素朴な作風が生まれるんですが、この差は一体なんなんだろうと感じます。

 さて、もう一冊。

Taku Hayase(SANDMAN)

戻る