格安(?)静音サーバーに挑戦

いよいよ、静音サーバーも本格的になってきてしまった。前回に続き、ファンレス静音電源とハードディスクを買い足し、主要部品はそろった。
写真は、主な構成品だ。前回も伝えた通り、マザーボードは VIA EPIA LN10000EG で、オンボード CPU はファンレス C7 1GHz、ツクモの中古売り場で 7999円で購入したもの。ハードディスクは一般的な 3.5インチ シリアルATA 500GB で、同じくツクモの中古売り場で 6780円で購入。
静音電源は、OLIOSPEC で、8480円購入した picoPSU-120WI-25V と言う新品。なお、これには、別途、12-25V の AC アダプターが必要で、これには昔使っていたノートパソコンの電源を流用している。
前回も伝えたように、メモリも別のパソコンで以前使っていた DDR2 512MB の流用品。

マザーボードも電源もファンレスなので、回転部は HDD だけ。流石に静かだ。その上、未だ設定していないが、24時間連続稼働でも、待機中は HDD を富めておけるはず。
少なくとも題名通り「静音サーバー」にはなりそうだ。
「格安」の方は、新規の買いものだけで、2万3千円を超えてしまったので、「格安」とは言えなくなってしまったが。

サーバー用途なので、Debian Linux etch を、GUI 無しでインストール。インストの時だけ、別途、CD-ROM を接続した。一度、ベースシステムがインストできれば、後は、ネットワーク経由でアップデートできるので、CD-ROM は不要になる。
ついでに、Xen もインスト。さてはて、どうなるか？

次は、ケースだが、最初に述べたように、これは、自作を考えている。
ファンレスとは言え、思いの他、マザーボードも HDD も発熱するので、通気性の良いケースが必要だ。
できるだけ、安くあげたい。

格安静音サーバーに再挑戦

２週間前のコンテンツにも書いたが、家庭内サーバーの更新を考えている。前回は、ファンレスの Mini-ITX C3 マザーボードを中古で買ったものの、仕様が古すぎて、使えない事が判明したところまで書いた。
今回は、性凝りもなく、またもファンレスの Mini-ITX マザーボードを試した話だ。

前回と同じく、ツクモの中古売り場で、 VIA EPIA LN10000EG を、7999 円で買った。これは、CPU に 1GHz の C7 を使った現行機種で、大体 15000 円くらいで今でも売られているものだ。現行機種らしく、メモリは DDR2 、HDD I/F は IDE の他、シリアル ATA も用意されている。同じくツクモの中古売り場で、DDR2 の 1G メモリ２枚も購入。LN10000EG には DDR2 が１枚しか付かないのだが、２枚の DDR2 は、メインパソコン Athlon64 X2 用のもの。こっちには、今まで、512Mを2枚付けていたのだが、これを 1G x2枚と交換し、余った 512M のうち、１枚を LN10000EG に使おうと言うケチケチ作戦。

結局、512M のメモリを付けた LN10000EG に前回も使った IDE 接続の CD-ROM ドライブと 20GB の HDD を付けて試験開始。

Debian Linux etch を入れてみると最初から、686 カーネルが入った。C7 が i686 互換なのか、事前にネットで調べたのが、判らなかった。でも、実際に動かして、C7 はi686 互換だとはっきりした。
ついでに Xen を入れると、これも OK 。もちろん、Intel VT とかAMD-V も無いから、完全仮想化ではなく、準仮想化だけど、セキュリティ向上には十分だろう。調子に乗って、Xen の仮想マシンの方 (一般的には「ゲスト OS」なんだが、Xen の場合は、ドメインU と言う) に、アイポ4と言うグループウェアをインストールしたが、これも成功。
流石は、現行機種！ これなら、大容量 HDD とファンレス電源を足せば、ちゃんと静音サーバーになりそうだ。

C7 って CPU、遅くて役に立たないかと思ったが、グラフィック環境の必要ないサーバーなら、大丈夫そうだ。

と、 LN10000EG の良いところばかりを書いたが、悪いところもちゃんと書いておかないとフェアじゃないだろう。

まず、グラフィック環境ならどうかと、Ubuntu 8.04 と CentOS 5.1 を試そうとしたのだが、どちも起動／インストできなかった。どうやら、IDE 接続の CD-ROM や HDD でエラーが起きているようだ。Debian Linux etch なら問題ないのだから、相性問題か？
最新の BIOS が公開されているようだが、これにアップデートすれば解決するかも知れないが、試していない。
まあ、この先は、シリアル ATA をメインに使うだろうから、IDE は重要視していなし。

それから、ファンレスマザーボードと言えども、CPU などは、かなり熱くなる。ファンレスって言うのは、「発熱が少ない」じゃなくて「発熱しても壊れない」って意味じゃないかと思えるほどだ。

まあ、悪いところもあるが、24時間運転の静音サーバーにはなりそうだ。

格安静音サーバーに挑戦

４年ほど前から玄箱を家庭内サーバーに使っているのだが、そろそろ壊れないか不安になって来たので、後継機を考え始めた。

玄箱はCPUに PowerPC 200MHz を使いメインメモリ 64MB の NAS キットなのだが、これに 3.5 インチ 160GB の HDD を入れ、Debian Linux をインストールし、ファイルサーバーだけではなく、各種のサーバーとして使ってきた。
まだ、玄箱が壊れたわけでは無いが、HDDに貯めたデータが無くなると困るので、元気なうちに後継機を用意してバックアップを取ろうと考えたのだ。

では、新しい玄箱を買えば良いと思われるかも知れないが、全く違う方向性を考えた。
多くのアプリケーションは、x86 用のものが配布される。それは、Linux の世界でも変わらない。

で、静音ファンレスの Mini-ITX マザーボードの購入となった。
数週間前、ツクモの中古売り場で、4999円で、Mini-ITX マザーボードが売っていたのだが、その時は買わなかった。
が、その後、考えて「もう一度行って同じ値段で置いてあったら買おう」と思い、先日、再び行ってみた。
なんと、ファンレス Mini-ITX マザーボードは、2999円になっていた。即買いである。FREETECH P6F212 C3/533 と言うものだ。
メモリーは、PC100 / 133 対応。古いタイプのメモリのせいか、128MBまでは安いのだが、256MB 以上だと急に高くなる。PC100 の 128MB が180円だったので、これを二枚買った。合計、3359円だ。

後は、ケース、電源、HDD なのだが、安くあげるために、ケースは自作と考えた。で、電源を探してみる。電源単体で売られているものは、多くは大容量タイプのもので、消費電力の少ない Mini-ITX に向かない。Mini-ITX に向いたファンレスの電源は意外と高価で、8000円くらいする。水城さんに相談したところ、余っている ATX 電源があると言うので貸してもらうことになった。
HDD は、大容量のものを買うかと再びツクモの中古品売り場に向かう。IDE 接続の HDD を探したら「古いマザーボードだと 120GB までしか認識されない可能性がある」とのこと。

せっかく、大容量 HDD を買っても、認識できなかったらつまらないので、まずは家にある HDD で試してみることにする。
試しなので、机の上にマザーボードや電源を広げて接続してみる。Mini-ITXの電源インターフェースは、一般的な 20PIN タイプのATX電源と同じインターフェースである。マザーボードの電源スイッチを接続するピンをショートさせると電源が入った。御世辞にも「静音」とは言いがたい電源のファンの騒音だが、ただで借りているだから良しとする。

一応、BIOS 設定画面が見れるところまで確認したので、玄箱の 160GB HDD を外して接続してみる。
再起動して、BIOS 設定画面を見ると、120GBしか認識していない。がああん。

気を取り直して、BIOS のアップデートに挑戦。製造元のホームページを見ると、BIOS の最新のバージョンは Rev.8 だ。それに対して、マザーボードの BIOS は Rev.3 である。ホームページからは、最新版の BIOS プログラムがダウンロードできるのだが、それには、フロッピーディスクで MS-DOS を起動して、実行するように書いてある。しかし、Mini-ITX マザーボードにはフロッピーインタフェースが無いぞ。BIOS のメニューにはあるのだが。
そこで、FreeDOS と言うものを使うことにする。通常使っているパソコンで、FreeDOS の CD-ROM ブートイメージをダウンロードして、CD-R に焼く。使わなくなっていた昔の PC から、 CD-ROM ドライブと 20GB の HDD を外して、 Mini-ITX マザーボードに接続して、再び起動。ちゃんと FreeDOS が起動するので、HDD にインストールする。インスト後、HDD から FreeDOS を起動し、別の CD-R に焼いておいた BIOS 最新版の書き換えプログラムを実行する。見事、書き換え完了。ところが、再び 160GB HDD を接続してみたのだが、やはり、120GB しか認識できなかった。嗚呼、こんなに苦労したのに・・・

こうなると、大容量サーバーの夢は消えたなあ。もちろん、120GB の HDDを最大４台まで接続できるのだが、コスト的に割りが合わない。それより、最新のシリアル ATA 大容量 HDD を買った方が安くつく。

あきらめて、20GB HDD に Debian Linux etch を入れる。サーバー用途なので、デスクトップ系は入れない。
これはアッサリ入った。

調子に乗って、Xen を入れてみる。メモリーが少ないのに Xen を入れてみるのは、仮想化を使ってセキュリティレベルを向上させたいからだ。だが、Xen は起動できない。Xen カーネルどころか、686カーネルも起動できない。
調べてみると、C3 は i586 互換 CPU で、Xen は i686 以降に対応なもんで、C3 じゃダメなんだそうだ。Xen も Intel VT とかAMD-V　だけじゃなくて、色々 CPU を選ぶんだねえ。
ネットで調べてみたけど、最新の C7 CPU は i686 互換なのか、Xen は動くのか、はっきり判らなかった。誰か知っていたら教えてください。

他にも、ファンレスとは言え、意外なほどに CPU やチップセットのヒートシンクが熱くなることが判った。

今回の Mini-ITX は、本格的なサーバーに使うと言うより、ワンポイントリリーフとか遊びに使おうかと思う。

まあ、色々あったけど、静音サーバーを作るコツと言うか、ノウハウが判った。
・使うOSやソフトにもよるけど、i686 互換以降の CPU が良いみたいだ。C7 が i686 互換かどうかは要調査。
　今後は、ATOM や PUMA が出てくるね。
・メモリーは大容量が使いたければ、現在は DDR2 が有利。
・HDDは、古い MB の場合で、IDE の時は、対応している容量に注意。
　しかし、IDE は 1TB を越える容量には事実上対応していないので、シリアル ATA の方が有利。
・ファンレス電源は意外に高い。
・ケースは自作も可能だと思うが、CPU やチップセットは熱くなるので、換気に注意。

3359円の授業料だと思えば、安いものか？　それとも高くついたか？

Kubuntu

Ubuntu 8.04 に、KDE や KDE 4.0 を使えるように Kubuntu を入れてみた。Kubuntu と言っても専用のディストリビューションではなく、日本語板 Ubuntu 8.04 に　Synaptic で追加インストールしただけ。つまり、gnome だけじゃなくて、 KDE や KDE 4.0 も使えるようにしたと言うこと。
インストール自体は意外と簡単で、KDE 4.0 も日本語化すれば、普通に使えて、今も、KDE 4.0 から書き込んでいる。

で、使った感想なんだけど、普通の KDE は普通のままだし、革新的と言われる KDE 4.0 も期待したほど革新的じゃないような気がする。まあ、使い込んだ訳じゃないので、まだ結論を出すのは早すぎるんだろうけど。

Ubuntu 昇格

一ヶ月近く Ubuntu 8.04 を試していて、使い勝手が良いので、「お試し」から「実用」に使う事にした。言わば「昇格」である。
私のパソコンの 320G HDD は、80Gの４つのパーティションに分けていて、Windows XP、Debian 32bit、Debian 64bit を入れている。残った 80G は更に細かいパーティションに分け、色々な OSを入れて試している。以前 Fedora を入れて、数週間試して消したこともある。この一ヶ月弱、この領域に Ubuntu をインストールしていたが、今日、あまり使っていない 64bit 版の Debian を消した 80G に Ubuntu を入れ直した。

使い勝手の良い Ubuntu だが、唯一気になっていたのは、無線LAN の不安定性だったが、まあ、そのうちパッチもあたるだろうと、「正式採用」に踏み切った。もう一つ YouTube 動画は観れるのに、ニコ動が観れなかった件については、既に Debian の方で最新の Adebe Flash Player をインストールすることで解決済みだったので、何とかなるだろうとインストールスタートである。

前回は、リリース直後で攻略本も出ておらず、自己流でインストールせざるを得なかった Ubuntu 8.04 だが、今回は週刊アスキーのムック「カンタン Ubuntu! 」を見ながらの作業だ。

インストールは、前回と同じく、簡単に終わったのだが、無線LAN を「カンタン Ubuntu! 」の通りに設定すると、何と無線LANは安定したまま接続できるではないか！
もちろん、最新版の Adebe Flash Player を入れたら、ニコ動も問題なく観れる。
結局、無線LANについては、私の設定が間違っていただけかなあ？

と言うわけで、Ubuntu の昇格も無事終了。
さて、今後、Debian 32bit 版と Ubuntu のどちらが使用率が高くなるか？
もちろん、私はプライベートでは、ほとんど Windows は使わない。

関数電卓を買う

長いこと使っていた関数電卓が壊れた。
少し、括弧を多用する計算をすると異常になる。
９×（１＋１÷（１＋８））＝
等と入力すると、二つめの「（」を入力したときにエラーが出る。
こんな壊れ方は聞いたことがない。これまで、電卓が壊れるのは液晶にひびが入ったように、物理的に壊れることだけで、今回のように計算途中でエラーが出るような事は初めてだ。長いこと使っていたので、今までも括弧を多用した計算をしていたはずなので、最初から異常だったはずは無い。また、括弧を２つ以上使わなければ正常に計算できる。とすると、構文解釈で必要となるスタックと言うかメモリー領域が壊れたんだろうか？　とは言え、実際はCPUを使ってプログラムを走らせているのだろうから、物理的にメモリーがあるとも思えず、首をひねるばかりである。

とにかく、使えなくなった電卓を後生大事にしていてもしょうがないので、新しい関数電卓を、東京に出たついでに秋葉原で買った。

HP35sが良いと言う人もいたし、ラジオデパートに在庫があることも確認したのだが、普通の日本のメーカーのものにする。
私は、太陽電池式の電卓は使わないので（理由は、電卓で行う軌道解析・制御設計を）、最も安いシンプルなものにしようと見ている内に、ちょっと500円だけ贅沢をして、1980円の電卓を買った。
いや、しばらく、見ないうちに電卓も進歩したものだ。プログラミング機能こそないものの、分数やルート三角関数がそのまま入力でき、その上、微分積分、連立方程式まで解ける。もちろん、微分や積分や方程式の解と言っても数値計算だけで、Mathematicaのような数式処理(私の場合、フリーのMaximaの方が良く使う)ができるわけではないが、それでも十分である。ニュートン方を使って、任意の方程式の近似解まで求まる。いやはや、大したものだ。これで、1980円とは安い。少し、大きくなったのが残念ではあるが。

う〜〜ん、次に買い替える頃（10年くらい先？）には、数式処理もできるようになるかなあ。
それともネットワーク機能が加わるか！？
（だんだん、電卓じゃなくなってくる）

Ubuntu 8.04 3Dデスクトップと仮想化

怒涛の Ubuntu だが、使いやすいので、どんどん進む。
無線LANの問題も続いているのだが、 切れたら「$ sudo /etc/init.d/networking restart」とコマンド打てば復旧することが判った。抜本的解決ではないが、対処療法として何とかなる。

で、3Dデスクトップと仮想化に挑戦。
画像は、その証拠。
Ubuntu の上で、YouTube の動画見ながら、KVMを使った仮想マシンWindowsXPでグーグルニュース見ているところの全体を3Dデスクトップ（CompizFusion）で見ている。右端にシステムモニターを出しているのだが、CPU負荷が滅茶苦茶高い。実は、WindowsXPの中からYouTube の動画見ることもできるのだが、流石に途切れ途切れで使い物にならない。もちろん、UbuntuのFirefox上のYouTube の動画は、3D表示中でも途切れることはない。
ところで、3Dデスクトップの仮想の床に、YouTube の画面が反射して映っているのが、お判りだろうか？
なかなか、おもしろい。

ubuntu 何か安定しないな

昨日、Ubuntu をべた褒めしたばかりだが、今日はちょっと批判。
あれから、3Dデスクトップである CompizFusion を試した。 CompizFusion は、すぐに動いたのだが、その間に無線LANが何度も途切れると言う現象が起きた。同じ無線LAN を WindowsXP でも Debian Linux etch でも使っているが、問題は起きていない。Ubuntu だけの問題と言えよう。
私の使っているパソコンの無線LANはRT61と言うタイプのもので、Debian のカーネル2.6.18では標準対応しておらず、メーカー製のドライバを使っている。Ubuntuのカーネル2.6.24では標準で対応している。どうも、これの調子が悪いのでは無いかなあ。
一度、無線LANが切れると、再起動しないと復旧しないので、始末が悪い。
同じ現象とか、対策法とか、あったら教えて欲しい。よろしく、お願い。

Ubuntu 8.04 インストール

Ubuntu 8.04 をインストールしてしまった。

インストールは、あっけ無く終わった。Debian Linux etch も含めて、過去の Linux や BSD 系のフリーOSに比べると格段の進歩である。
それどころか、ここ半年の間に Windows XP を何度もインストールし直したり、なんの因果か僅か2ヶ月の間に Vista のプリインストールしたノートPCを3台もセッティングしたことに比べても遥かに簡単だった。
冗談じゃなくて、今やプリインストールの Vista マシンを使うより、ubuntu の方が楽にスタートできるって言えるぞ。

サウンドボードは自動認識で、無線LANもSSIDやパスワードなどを設定した後、再起動しただけで接続できた。
nVidia GeForce 6150 のグラフィックカードの設定だけは、ネット上の情報と異なったので、ちょっと時間がかかった。何度か再起動している内に（三度目くらいに）「システム」「システム管理」「ハードウエアドライバ」の中に「NVIDIAの高性能グラフィックドライバ（新しいカード向け）」と言う項目が表れる。これの「有効」をチェックすると、ドライバがダウンロードされる。その後、再起動すると、ちゃんと NVIDIAが動くようになった。

私の Athlon64 X2 の HDD は、320Gで、80G を WindowsXPに、80Gを DebinaLinux etch (32bit)に、80Gを DebinaLinux etch (64bit Xen 3.1.0用)に、40Gを DebinaLinux etch (64bit Xen 3.0.3 用)に使っている。残った 40G にUbuntu 8.04 を入れた。デュアルブートどころか、クイントブートであるが、心配していたブートエラー(ubuntu 6.10 の時に起こった)は、大丈夫だった。

いやはや、起動音といい、デスクトップの背景といい、趣味が良いねえ、ubuntu は。
とにかく、普通に使う分には、アッと言う間にインストールできるので、楽なもんだ。

さて、次は、3D デスクトップとか、仮想化とか、普通でない使い方に挑戦である。

ubuntu

昨日、リリースされたばかりの Ubuntu 8.04 LTS に、早くも日本語ローカライズド Desktop CD がリリースされた。早速、ISO イメージをダウンロードして、CD-R に焼く。
HDD にインストールする前に、とりあえず、ライブCDとして Ubuntu を CD-R から起動してみる。

やあ、これは簡単。
無線LANからサウンドデバイスまで、何から何まで自動認識した。
私の Athlon64 X2 についている無線LANは、今まで Debian Linux etch の標準状態からは認識できず、メーカーサイトからドライバーをダウンロードしなければならかったのだが、Ubuntu 8.04 では何もせずに認識とは、えらい違いだ。

明日は、HDDの空いた領域にインストールしてみようと思う。
ただ、昔、Windows 2000 と Ubuntu 6.10 をデュアルブートしようとして、失敗した経験があるので、ちょっと心配。後は、GeForce 6150 相当のグラフィック機能がちゃんと使えるかだ。

Compiz Fusion

昨年9月に買ったパソコンに Debian Linux etch を入れているのは、以前も書いたが、3Dデスクトップ賭してberylを入れて置いた。と言っても、berylは無駄にCPUパワーを喰うだけで余りスムーズに表示できないので、実際にはほとんど使わなかった。
その間にberylは、喧嘩分かれ（？）していたCompizと再統合して、Compiz Fusionになった（Compiz Fusionに統合されたのは、2007年5月だから、実際は私がパソコンを購入した時は、Compiz Fusionに統合された後だ）

色々、調べてみると、より新しいCompiz Fusionの方が面白そうなので、berylを消して、Compiz Fusionをインストールした。
berylと異なり、Compiz Fusionにはxserver-xglが必要なのだが、Debian Linux etch にはxserver-xglのパッケージが無いので、これを探すのが一番面倒だった。

取り合えずCompiz Fusionは動いたのだが、Fusion Iconが使えなかったり、色々な効果をどう使うのか操作方法が分からなかったり、面白そうなオプションのプラグインのインストール方法が分からなかったりする。だから、確実な事は言えないのだが、ちょっと使った感触だけで言うと、Compiz Fusionは、速度も速くなったようだし、視覚的な効果も面白いので、かなり実用として使えそうな気がしてきた。

私は元々CUI派で、ターミナルプログラムのタスクスイッチとしてマルチウインドウシステムを使っているし、最も使っているアプリケーションは、emacs(XEmacs)とvi(vim)、文章はLaTeXと言う人だ。
それにも関わらず、装飾過多でCPUやメモリ喰いのKDEをデスクトップとして使っている。
CUIには関係ないとは言っても、装飾が綺麗で楽しいなら、それはそれで面白いと思ってしまうのだ。

3Dデスクトップも同じじゃないかと思う。
本来の作業が止まる程、CPUやメモリを喰ったら本末転倒だが、Compiz Fusionは、グラフィックカードの機能・性能を上手く使っているのか、意外とサクサク動く。
私のグラフィックカードは、マザーボードのオンチップのGeForce6150なので、そんなに高性能じゃ無い筈だが、使っていて全く問題は無い。

むしろ、KDEの場合には標準で4つある仮想デスクトップ（仮想画面）の中で何のアプリが動いているか切替えないと分からないのが、Compiz Fusionでは仮想の三次元空間内に、４つの縮小した仮想デスクトップを浮かべて並べてみることができるので、切替えに便利だ。視覚的にも仮想の床に仮想デスクトップが反射して映っているのも気が利いている。
試しに、YouTubeの動画を流してみたら、仮想の三次元空間で縮小した仮想デスクトップの中でもスムーズに動画が動いている。その上、床に反射した鏡像の動画も動いている。
全く別の2つの動画を流してみたら、縮小した2つの仮想デスクトップと、床に写った鏡像、合わせて4つの動画が全てスムーズに動いている。
まあ、良くやれるもんだなあ・・と感心してしまう。普段は、こんな無茶な使い方はしないだろうけど。

デジタル小物

秋葉原に行った友人に、1GのSDカードを買ってきてもらった。なんと、790円。安くなったものである。用途は貯めこんだMP3を入れておき、Zaurusで聞くのが主だが、こんな使い方でも「モッタイナイ」と思えないほど安くなっているのが嬉しい。

今年はメインのパソコンを交換すると言う大物を購入したので、小物まで手が回らないのだが、面白そうな小物が続々出ているようだ。先のSDカードもそうだが、メモリの価格の下落が関連する機器のコストを下げている事が大きな要因のようだ。

まずは、先日のコンテンツでも書いた台湾の Eee PC。
HDDを用いず、半導体メモリーだけでモバイルPCを作ったところが面白い。もちろん、国内のSONYや工人舎でもシリコンディスクを使ったモバイルPCは作っているのだが、やたら高い。Eee PC はシリコンディスクの容量を少なくし、OS を Linux にして低コスト化をはかっているところが潔い。Windowsなんかに頼っているとディスクがバカに大きくなるので、こう言った設計も一つの選択だろう。今後、メモリーが安くなるので、更なる低価格化も期待できる。

つぎは、USL-5P。
本来は、LANにUSB機器を接続するアダプターなんだが、中身は Linux マシン。改造すれば、ちょっとしたロボットなどの制御に使えそうだ。ただ、発売後、３年ほど経っているので、すでに旧式化していそうだ。

と思っていたら、つい最近 CG-LBSTD2PU が発売された。
これは、ボード単位で売っている超小型Linuxマシン。最初からロボットなどの制御用なんで嬉しい。ただカーネルが2.4なのが難点。USB接続のCMOSカメラとか使いたい時は、2.6が欲しい。

Nano-ITX のマザーボードでも良いかもしれないが、ここまで来ると、一般的なパソコンに近いか？

アルゴシステムと言うところの製品の「薄型タッチパネルコンピュータ」と言うのも面白そうだ。液晶表示付きのLinuxコンピュータで、本格的な制御機器を作れそうだ。ただ、意外と高いのが難点。

液晶と言えば、携帯電話用のカラー液晶がリーズナブルな値段で秋葉原で出回っている。ちょっと画面が小さいが、SH-TINY などで表示させるにはぴったりだろう。

その他、iPodなど欲しいものは沢山ある。が、なかなか買えない。

Eee PC

そろそろ、Zaurus の後継機も無さそうだし、次のモバイルどうしようかと考えているのだが、Eee PC なんて良いんじゃないかと思っている。

あと、もう少し安くて、軽ければ言うことないのだが。
（今回は短め。ほとんど生存確認）

仮想化 続き

結局、時間の無駄とか言いながら、 Xen による仮想化に挑戦し続け、Debian Linux 上で Windows XP を動かすことに成功した。この前、新しいカーネルでKVMを使った仮想化で Windows を動かすことに成功しているので、「多分、新しい Xen なら動くだろうな」と、Debian Linux ｅｔｃｈ の標準の Ｘｅｎ 3.0.3 を、3.1.0 に変えたら動いたのだ。
ここんとこ色々試したので、傾向を一覧にしてみた。以下、ホストＯＳとは元のＯＳで、ゲストＯＳとは、ホストＯＳ上で仮想化した状態で動かしているＯＳ。なお、Ｘｅｎ の場合、厳密に言えば、全てのＯＳが仮想化されているのだが、ホストＯＳはドメイン０（最初に起動し、Ｘｅｎに対する制御権を持つ唯一のＯＳ）を、ゲストＯＳはドメインＵ（Ｘｅｎに対する制御権を持たないＯＳ。複数可能）と思ってもらいたい。また、AMD-Vは、完全仮想化を実現するためのCPUに付加された「仮想化支援機能」のAMD版。インテルCPUに同等の機能 Intel VT を持つCPUがある。

・VMWarePlayer (on Widows XP)
　・ホストＯＳ： Widows XP ホームエディション
　・ゲストＯＳ： Debian Linux ｅｔｃｈ i386(32ビットモード)
　・仮想化：ソフトウエア（によるはず。AMD-Vは使ってない筈だから）
　・使った感想：
　　・ネット環境も自動設定だし、GUI系も判りやすく、使いやすい、意外と速い。

・VMWarePlayer (on Debian Linux ｅｔｃｈ)
　・ホストＯＳ： Debian Linux ｅｔｃｈ amd64(64ビットモード)
　・ゲストＯＳ： Widows XP ホームエディション
　・仮想化：ソフトウエア（によるはず。AMD-Vは使ってない筈だから）
　・使った感想：
　　・ネット環境も自動設定だし、GUI系も判りやすく、使いやすい。
　　・意外と速いが、Wiondows版の VMWarePlayer の方が速いような気がする。

・KVM (on Debian Linux ｅｔｃｈ)
　・ホストＯＳ： Debian Linux ｅｔｃｈ i386(32ビットモード)
　　・カーネルを testing版の 2.6.22 に交換したもの
　　・グラフィックアクセラレーターや無線LANが使えない。
　　　　・どうやら、新しいカーネルでは、無線LANドライバーに対するAPIが
　　　　　変更になった模様。
　・ゲストＯＳ： Widows XP ホームエディション
　・仮想化：ハードウエアによる完全仮想化（AMD-V使用）
　・使った感想：
　　・速い。GUIも判り易い。使い易い。
　　・残念なのは、無線LANが使えないから、我が家のネット環境では実用に
　　　ならないこと。

・Xen (on Debian Linux ｅｔｃｈ)
　・ホストＯＳ： Debian Linux ｅｔｃｈ amd64(64ビットモード)
　　・Xenを3.1.0に交換。
　・ゲストＯＳ： Widows XP ホームエディション
　・仮想化：ハードウエアによる完全仮想化（AMD-V使用）
　・使った感想：
　　・速い。でも、KVMよりは遅いと思うが、VMWarePlayer よりは速い。
　　・GUIも判りにくい、使いにくい。Xenのせいと言うより、表示を受け持って
　　　いる vncviewer の問題だと思う。
　　・ネットの設定ができずに、ゲストOSから、外部ネットに接続できない
　　　（ホストOSまでは接続できる）
　　　　・ネットについては、今後の課題。できないはずはないから。

・QEMU (on Debian Linux ｅｔｃｈ)
　・ホストＯＳ： Debian Linux ｅｔｃｈ i386(32ビットモード)
　・ゲストＯＳ： Widows XP ホームエディション
　・仮想化：ソフトウエアエミュレーション（CPUそのものを）
　・使った感想：
　　・遅い。使い物にならない。
　　・でも、よく動いたと逆に感心する。

と、まあ、32ビットや64ビット環境がゴチャゴチャになったり、使用感や速度が主観的なものなので、厳密な比較じゃないけど、以上のような結果になった。あまり、厳密な比較を追及すると、ベンチマークだらけになってしまうからねえ。

あくまでも個人的な主観なんだけど、VMWarePlayer は思った以上に健闘しているなあ。さすが、商業ベース。
次は、KVM。まだ、新しい技術なんで、普及はマダマダだけど、使い勝手も良いし、今後のメインストリームになりそうな気がする。
本命のXenは、もうちょっとだなあ。サーバー用が主で、デスクトップ用としては難しすぎるのかな。

将来的には、サーバー用Xen、デスクトップ用 KVM かな、Linuxの世界では。
これは、あくまでも KVM が普及した後の話。それまでは、VMWarePlayer が意外と良い。

なお、この文章自体、VMWarePlayer (on Debian Linux ｅｔｃｈ)上での Windows XP から書き込んでいる。
（Windows XP のライセンスが問題だなあ。本来このマシンのために正規購入したライセンスな上に、同時に2つ以上起動できないのだが、ライセンスは各インストール毎に必要なんだろうか？　今回は試しなので、アクティベーションの必要となる30日過ぎたら消すつもりだけど。仮想マシンにインストールしたOSのライセンス料は仮想の通貨で払っちゃ駄目かな？　鰻の匂いを、小銭の音で払うように）

仮想化

結局、この週末もパソコンをいじっていた。
Debian Linux の Xen 上での Windows XP に上手く行かなかったので、KVM を試してた。KVM と言っても JAVA の仮想マシンでは無く、LINUX のカーネルレベルで、Xen の完全仮想化と同じ機能を持つと言うもの。
KVM のためには、新しいカーネルが必要で、Debian Linux etch のカーネルでは古くてダメ。
で、testing (etch の次のシステム)から、カーネルと KVM 関連のパッケージだけインストールする。
残念ながら、この新しいカーネルでは、無線LANと nvidia のドライバーが使えない。

で、KVM 上に Windows XP をインストールしたのだが、今度は上手く行った。
さすがにハードウェアで完全仮想化しているだけあって、速い。ハードウェアによる完全仮想化でもパフォーマンスは半分程度に落ちているはずなのだが、実用上まったく問題無いほど速い。

KVMが使えるカーネルは、Debian Linux 用としては安定しているとは言いがたいし、先にも述べた通り無線LANと nvidia のドライバーが使えないので、今後、メインで使うかどうかわからない。Debian Linux のリリース版のカーネルが新しくなるのは、2年位かかるのだろうなあ。
それまで、危険覚悟で新しいカーネルを入れるか、完全仮想化が私のコンピュータで動く事が判った事に満足して、しばらく止めるか。悩みどころである。

もうちょっと、大きなメモリーを買っておけば良かったかな？

時間の無駄

新しいパソコンを買って色々試して居るのだが、そろそろ時間を無駄にしているような気がして来た。

まず、デュアルコア対応プログラミングだが、OpenMP を使うと偏微分方程式の数値計算が速くできると思ったら大間違いで、シングルコアの時より遅くなって居る。たぶん私の使い方が間違って居るのだろうが、原因は調査中だ。

仮想化については、VMware Player を使って、Windows XP 上で、Debian Linux etch を動かす事には成功して居る。
逆に、Xen を使って、Debian Linux etch 上で、Windows XP を動かす事には成功して居ない。
Fedora 7 だと仮想化が簡単に使えると聞いたので、ハードディスクの空き容量に Fedora 7 を入れようと思うと入らない。今まで、考えなしに OS をインストールしたので、XP や Debian (32bit と 64 ビット)とスワップ領域で、基本パーティションの上限４つを使い切って居たので、ハードディスクに空きがあっても使えなかったのだ。
拡張パーティションに作り替えて・・など画策もしたが、結局、Debian の２つは色々と試してゴチャゴチャしてきたので、いっそ消してインストールし直すことにした。

計画的にパーティションを作れば、XP と Debian (32bit と 64 ビット)、Fedra 7 の４つを入れることは可能だ。
だが、結局、Fedora 7 で、Xen を試したが、Windows XP をインストールできなかった。
エラーメッセージの出方は違ったが、結局は、Debian の Xen と同じ原因だと思われる。完全仮想化された Windows XP からハードディスク（仮想化されている）をアクセスするとエラーが出るのだ。高い頻度でエラーが出る訳ではないようだが、XP のインストール を途中で止めてしまう。
準仮想化された Linux からのハードディスクアクセスでは問題が出なかったから、完全仮想化だけの問題と思われる。
これほど明確な不具合なら、私のところ以外でも問題になっていそうなものだが、ネット上では見つからなかった。私の使って居るシステム（Athlon64X2 CPU や nVidia のチップセット、SATA2のHDD）に特有な相性の問題なのだろうか？

Xen はあきらめて、Debian を使える状態に戻そうとすると、今度は、64ビット環境で nvidia のグラフィックドライバーが正常に動作しない。以前上手く行かなかった32ビット 環境での nvidia のグラフィックドライバーが上手く行くのに、今度は何度試しても64ビット環境で上手く行かない。

とまあ、こんな風に、せっかくの週末を潰してしまった。苦労した割りには何の進歩も無い。逆に使える状態だった Debian Linux 64 ビット環境での nvidia のグラフィックド ライバーが使えなくなったくらいだ。

ああ、時間を無駄にした。
こんな事なら、小惑星ネタのコンテンツでも書けば良かった。

デュアルコア対応プログラミング OpenMP 編

先日、「デュアルコア対応プログラミング」のコンテンツを書き込んだ時は、Cなどのコンパイル言語でのデュアルコア対応プログラミングは未完成であった。
今回は、ちゃんとコンパイル言語でデュアルコアに対応し、高速で計算するプログラムを作ることに成功したので、報告する。
課題は、先日と同じく円周率を求める計算だが、デュアルコアを有効に使って計算するプログラムは下のようになった。

#include 

main()
{
  int i;
  int n = 1000000000;
  double s = 0.0;
  system("date");
#pragma omp parallel for reduction(+:s)
  for (i = 0;i < n;i++)
    s += (4.0 / (4 * i + 1) - 4.0 / (4 * i + 3));
  printf("%lf\n",s);
  system("date");
}

「えっ、これだけ！？」
そう思うだろう。
ごく普通の C プログラムだ。ただ、「＃」で始まる一行のみが、普通の C ではない。
たった一行でデュアルコアどころかクワッドコア、オクタコアの様なマルチコアに対応したプログラムになる。
意外なほど、簡単にマルチコア対応のプログラミングは可能なのだ。その秘密は OpenMP だ。

先日の「デュアルコア対応プログラミング」をアップした後、私なりに高速の計算をデュアルコアで行う方法を探して居た。
前回、C++ でのスレッド(pthread)を使って、プログラミングしたところ、シングルコアでの計算よりも時間がかかった。調べてみたところ、「マルチコアＣＰＵのための並列プログラミング」（秀和システム ISBN：4-7980-1462-1）と言う本に pthread を使った「デュアルコア対応プログラミング」が詳しく載っている。ところが、この本を書店でパラパラとめくってみたところ、これは大変な手間だと言うことが判った。とりあえず、その場は買わずに保留とした。

その後、ネット上で調べてみると、OpenMP と言う機能を使うと、比較的簡単にマルチコアでの並列計算ができると言うことが判った。しかし、OpenMP と言う機能は、コンパイラが対応して居なければならない。マイクロソフトやインテル製コンパイラで対応して居るようだが、高価だったり、Linux では使えなかったり、AMD の CPU に対応して居なかったら嫌だな・・と思って居たら、ごく最近 gcc でも OpenMP に対応したようである。

今年の５月にリリースされた gcc 4.2 から、OpenMP に正式対応したらしい。残念ながら今年４月にリリースされた Debian Linux etch の gcc は 4.1 である。
そこで、まず、最新の gcc をインストールするところから始める。非安定板の sid には、gcc 4.2 のパッケージがあるようだが、不安なので、ソースから構築することにした。

なお、32ビット環境の Debian にはインストールできたが、64ビット環境だとエラーが出て構築できなかった。従って、以降の話は 32ビット環境での話である。

まず、GCCソースコードの在処から、gcc-4.2.1.tar.bz2 をダウンロード。

$ cd ~/work
$ tar jxvf gcc-4.2.1.tar.bz2
$ cd gcc-4.2.1/
$ mkdir dist;cd dist
$ CONFIG_SHELL=/bin/bash; export CONFIG_SHELL
$ ../configure --prefix=/usr/openmp --enable-languages="c,c++"
$ make
$ su
# mkdir /usr/openmp
# make install
# cd /usr/openmp/bin/
# mv c++ c++-4.2.1
# mv cpp cpp-4.2.1
# mv g++ g++-4.2.1
# mv gcc gcc-4.2.1
# mv gccbug gccbug-4.2.1
# mv gcov gcov-4.2.1

残念ながら、構築に成功したのは、32ビット環境だけだ。64ビット環境だと、libc.a libc.so が無いと言ってエラーで止まる。あるのだが。

/etc/ld.so.conf に下記の一行を追加する。

/usr/openmp/lib

その後、次のコマンドでライブラリーを設定する。

# /sbin/ldconfig

~/.bashrc に下記の一行を追加する。

export PATH=/usr/openmp/bin:$PATH

上記のような方法だと、gcc 4.2 は、/usr/openmp/ 　の中にインストールされる。アンインストールする時は、/usr/openmp/ ごと消してしまい、PATH や ld の設定を戻すこと。

・サンプルプログラム　その4：testDualCore04.c

コンパイルは簡単で、次のようにオプション「-fopenmp」を付けるだけだ。

$ gcc-4.2.1 -fopenmp -o testDualCore04 testDualCore04.c
$ ./testDualCore04.c
2007年 10月  1日 月曜日 19:34:48 JST
3.141593
2007年 10月  1日 月曜日 19:34:58 JST

システムモニターで見ながら、プログラムを走らせると、面白いように２つの CPU の使用負荷が上がる。もちろん、無駄に CPU が使われて居る訳ではなく、シングル CPU での計算の２倍の速度だ。

先のプログラムの「＃」で始まる一行は、続く「for 文」を複数の CPU コアに処理を振り分ける事を意味する。

今回の円周率の計算は、極めて並列計算に合った特殊な例かもしれない。しかし、OpenMP を使うと意外に簡単にマルチコアを有効に使った並列計算プログラムが作れることが判ったことが大きな収穫だ。

デュアルコアで小惑星探査軌道計算

いよいよ、デュアルコアで小惑星への探査軌道の計算をやってみた。

この辺から、ダウンロードした 603個（2月に計算した時は 430個だった）の小惑星の軌道要素から、計算する。
元々のプログラムは、シングルコア用で、図の左のようなフローになっている。
603個のNEO毎に、30年間を10日毎に軌道計算して位置を求め、その往復に必要なΔVを計算している。
図の中で、赤線で書いた部分が非常に計算量が多く、フォートランのプログラムをコンパイルしている。
黒線の部分は、意外と計算量が少ないが、プログラムを頻繁に変更するので、Ruby で処理している。Ruby の部分は、当然インタープリタだ。
Rubyのメインルーチンから、フォートランをサブルーチンとして呼び出しているような構造になっているわけだ。サブルーチン代わりと言え、当然、プログラムの呼び出しだから、別プロセスを起動している。

システムモニターを見ながら、左側のプログラムを走らせたところ、２つのCPUコアが５０％強程度で動いていた。これは、各コアに、Rubyとフォートランのプロセスが割り当てられたのではなく、大量に発生するフォートランプログラムのプロセスが、その度毎に違うコアに割り当てられたからだと思われる。

さて、デュアルコア用にプログラムを変更したのが、図の右側である。
比較的複雑な構造になっているのは理由がある。
当初、603個のNEOを半分にして、302個を一つのコア、残り301個のNEOをもう一つのコアに割り当てて、二つのプロセスを起動すれば良いと思っていた。しかし、上手く行かない。

603個のNEOを計算しても、全てのNEOを同等に軌道計算しているわけではない。
有人探査を目的としているので、往復に1年半以上必要な小惑星は計算していないのだ。
小惑星の軌道は、地球に近いからと行って、必ずしも短時間で往復できるわけではない。
地球と小惑星の位置の関係から、近い軌道でも、往復しやすいタイミングは限られている。
（何十年ぶりの火星の大接近とか言うでしょ）
だから、計算対象の30年間で、そもそも、往路に1年半以上かかるNEOは復路計算は行っていない。
往復両方計算している小惑星はむしろ少数派だ。

603個のNEOの内、1年半で往復できると判断できたのは、105個だけだ。
これら105個のNEOに関しては、繰り返し繰り返し計算されている。

いきなり603個のNEOを計算するのは大変なので、最初、10個とか20個から始めた。
最初の10個には、105個のNEOは一つも含まれていなかった。ところが、11個目から20個目には、2個の有望なNEOが入っていたのだ。
20個のNEOを計算試験では、最初のプログラムは、一つのコアに最初の10個、もう一つのコアに11個目から20個目を割り当てた。
システムモニターを見ながら走らせたのだが、プログラムの問題は明らかだった。
最初のコアは、すぐに計算が終わったのだが、もう一つのコアは何時までも終わらない。
結局、シングルコア用のプログラムから、ほとんど改善されていない。

今回、少数だったので、たまたま小惑星が偏っただけかも知れない。小惑星の総数が増えたら、もっと均一に分散するかもしれない。だが、ランダムな分散と仮定しても、必ずしも二つに分けたときに偏りが減るわけでない。また、計算しなければ、有望かどうかわからないので、予め計算が均一になるように分けることもできない。

そこで、プログラムを分け、2つのスレッドを走らせた。この2つのスレッドは Ruby 1.8 なので、本当のスレッドではなく、エミュレーションのようなものだ。スレッド間ではメモリーを共有できるので、603個の小惑星の何処まで計算したか判る。
2つのスレッドは、それぞれ、小惑星を一つだけ計算する別プロセスを起動する。起動されたプロセスは、それぞれ別のコアに割り当てられる。プロセスが終了すると、次の小惑星が割り当てられる。これによって、一つのコアに処理が集中することを避けた。

計算結果は、次のようになった。
小惑星30個の計算：
・モバイルセレロン 450MHz Linux sarge 686 2時間38分38秒＝9518秒 （シングルコア用プログラム）
・Athlon64 X2 4200+ Linux etch 686（32ビット版） 12分46秒＝766秒 （デュアルコア用プログラム）
・Athlon64 X2 4200+ Linux etch amd64（64ビット版） 14分52秒＝892秒 （デュアル用プログラム）

意外な事に、32ビット版の方が16％も速い。
普通、64ビットの方が、「アクセスできるメモリー容量が大きい」とか「汎用レジスタが8個から、16個に増えている」とかで、シミュレーションなどの計算には向いていると言われている。今回、前者のメモリー容量は関係ないが、レジスタ数で64ビットの方が有利かと思っていたが、結果は逆だった。
64ビットの方が、プログラム容量が増えるとか、各変数のビット数が増えて、オーバーヘッドなどで不利になるのかも知れない。

最後に、603個のNEO全てを計算した。もちろん、担当するのは、32ビット版だ。
・Athlon64 X2 4200+ Linux etch 686（32ビット版） 3時間18分54秒＝11934秒 小惑星603個

うーん、速い。ちなみに、同時に Webや動画を見ても、全くストレスが無い。
モバイルセレロンの12倍だ。前の試験よりも差が開いたのは、メモリー容量の差だと思う。小惑星のデータはかなり大量だが、モバイルセレロンのPCには、192MB のメモリしか載っていない。片や、Athlon64 X2 の方は １GBだ。
仮に比例関係が成立すると、モバイルセレロンなら、41時間11分27秒もかかることになる。（いや、2月に計算した時は、実際、そのくらいかかったし。あの時は430個だったけど）

デュアルコアは、やはり速いのう。

私のやり方は、少し特殊なケースなのかも知れない。
流体シミュレーションのように、もっと密接に結びつく場合には、今回のようなやり方は通用しないだろう。
だが、私の経験では、こう言ったやり方に当てはまる大量計算も、それなりにあると思う。

何かの参考になれば、幸いだ。

デュアルコア対応プログラミング

いつ迄もグダグダとコンピュータを語ってもしょうも無いので、そろそろ本命の高速計算をやってみる。
いきなり有人小惑星探査の軌道解析を走らせても、デュアルコアに対応したプログラムでは無いので意味が無い。

まずは、小手調べとして、比較的簡単な計算でデュアルコアを活したプログラムの作り方を研究してみた。
課題としたのは、円周率の計算だ。図で示した数式のように計算して円周率を求める。この計算式は、古くからある方法で、式自体は簡単だが、多数の桁を求めると非常に時間がかかる方法だ。現在、円周率の多数桁を求めるためには、もっと良い計算式を使って高速に求めて居る。
今回は、円周率を求めること自体が目的ではなく、むしろ沢山の計算をさせてみたいので、この式を使った。全く同じ計算をシングルコアやデュアルコアにさせて、効果を試そうと言う訳だ。
２つあるコアに、一つおきの項毎に計算させ、両方の計算が終わった後、集計しようと言うわけである。

さて、実際にデュアルコアを効果的に使うためのプログラムは、どう作れば良いのだろう。
いろいろやってみて、何とかなったのだが、成功だけを示すよりも、失敗事例も示した方が役に立つかも知れないので、失敗も含めて報告する。なお、この後、特に明言されていなければ、プログラムを実行した環境は、Athlon64 X2 4200+ Debian Linux etch の64ビット環境でマルチコア対応カーネルである。

マルチスレッドを使ってプログラミングすると、スレッド毎に CPU コアが割り当てられると聞いたので、ruby のマルチスレッド機能を使ってプログラムしてみた。
・失敗プログラム　その１：testDualCore01.rb

プログラム自体は、動くには動くが、マルチスレッドでもシングルスレッドでもパフォーマンスが同じだ。システムモニターで見ると、 CPUコア は一つしか使っていない。
ネット上で調べると、ruby の最新バージョン（1.8.x）では、ネイティブ・スレッドに対応しておらず、ソフトウエアでエミュレーションしているような状態だないそうだ。ネイティブ・スレッドの対応は、次のバージョンである 1.9 かららしい。

ruby によるマルチスレッドはあきらめて、 C++ でのスレッドを使おうと思ったのが、次のプログラムである。
・失敗プログラム　その２：testDualCore2.cpp

このプログラムを走らせた状態をシステムモニターで見ると、CPUコアが２つとも１００％使われている。
「やったね」と思って、パフォーマンスを測るのだが、何処かおかしい。
なんと、スレッドを使わず、CPUコアを一つだけ使って計算している方が、マルチスレッドを使った場合よりも速いのだ。
どうやら、単純にマルチスレッドを使ってプログラミングしただけでは、有効にデュアルコアを活用できないようだ。（無駄に活用することはできるが）
マルチスレッドは、スレッド間でメモリを共有できるのが良いのだが、それが逆に悪さをしているのかも知れない。二つのコア間で、メモリの同期を取る必要があるなら、動作はむしろ遅くなる可能性がある。
本来、マルチスレッドを使って上手くプログラミングすれば、デュアルコアを有効に使える筈だ。この時は、明確に使用するメモリを分ける必要があるのだろう。

どうやれば、スレッド間でメモリを明確に分けるのか、調査するのも面倒になったので、fork を使って、プロセス自体を分離することにした。
これが次のプログラムである。（プログラム中パイプを使って通信しているので、「fork」ではなく「open」で子プロセスを起動している）
・成功プログラム　その３：testDualCore03.rb

再び、ruby を使っている。プログラムを見れば判るが、引き数に何も入れなければデュアルコア対応、引数に「-1」を入れるとシングルコアプログラムである。

このプログラムは上手く動作した。
次がその結果である。
・モバイルセレロン 450MHz Linux sarge i386(32bit環境)
　・シングルコア用 334秒　デュアルコア用 334秒
・Athlon64 X2 4200+ Xp Home (ruby はRuby-mswin32)
　・シングルコア用 68秒　デュアルコア用 34秒
・Athlon64 X2 4200+ Linux etch i386 (カーネル名 486 32ビット環境 シングルコアのみ)
　・シングルコア用 54秒　デュアルコア用 57秒
・Athlon64 X2 4200+ Linux etch i386 (カーネル名 686 32ビット環境 マルチコア対応)
　・シングルコア用 58秒　デュアルコア用 29秒
・Athlon64 X2 4200+ Linux etch amd64 (カーネル名 amd64 64ビット環境 マルチコア対応)
　・シングルコア用 57秒　デュアルコア用 29秒

とまあ、こんな結果になった。
総括すると、次のようになる。
・XP Homeよりも Linux の方が、やや速い。
・マルチコアに対応したOSだと、約２倍の速度が得られる。
・シングルプロセスのみなら、むしろマルチコア非対応のカーネルの方が速い。
・32ビットと64ビット環境では、有意な差は無い。
・デュアルコア有効状態のAthlon64 X2 4200+ は、モバイルセレロン 450MHz の約 10 倍速い。

ところで、ついでにYouTube で動画を再生しながら、プログラムを走らせてみた。
・Athlon64 X2 4200+ Xp Home (ruby はRuby-mswin32)
　・シングルコア用 73秒　デュアルコア用 39秒
・Athlon64 X2 4200+ Linux etch i386 (カーネル名 686 32ビット環境 マルチコア対応)
　・シングルコア用 60秒　デュアルコア用 37秒
・Athlon64 X2 4200+ Linux etch amd64 (カーネル名 amd64 64ビット環境 マルチコア対応)
　・シングルコア用 62秒　デュアルコア用 33秒

シングルコア用プログラムでは、ほとんど劣化していない。これは、CPUコアの一つで動画を再生、もう一つで円周率の計算をしているからだ。
流石にデュアルコア用プログラムでは、多少遅くなっているのだが、これは仕方が無い。
動画の方だが、XP Home でのデュアルコア用プログラムを除いて、全く問題無く再生できた。
それに対して、XP Home でのデュアルコア用プログラムの時は、グダグダで、飛び飛びの再生で、頻繁に停止する。

動画再生中の時のデュアルコア用プログラムの時、初めて、64ビットと32ビット環境の差が出た。
ところが、これは、グラフィックカード性能によるものである。現状、32ビット環境では、グラフィックカード専用ドライバのインストールに成功しておらず、64ビットのときのみ、GeForce ドライバを使っている。
64ビット環境で、32ビットとの時と同じく VESA ドライバーを使うと、動画再生時に 32ビットと同じ性能になる。

と言う訳で、やっとデュアルコア用プログラミングのやり方が少し判って来た。
プロセスではなく、スレッドを使った方が、オーバーヘッドが少ない筈だが、そっちの方は今後の課題である。

ところで、何故、ruby を使っているのか、不思議に思う人もあるかも知れない。
高速の計算なら、普通、コンパイラ言語だろう。
私の場合、本当に高速なところは、CやC++、フォートランと言ったコンパイラ言語を使うのだが、多数のパラメーターを振って、そのプログラムを呼び出すのに ruby を使うことが多い。小惑星探査軌道計算も、そうである。

今度は、小惑星探査の軌道解析を、デュアルコアを有効に使って計算したいと思う。

パソコンを買った理由

新しいパソコンを買った直接的な理由は、以前書いた通りで軌道解析などの計算を高速でしたかったからなのだが、もう一つ理由がある。新しいアーキテクチャを試したかったからだ。

パソコンのアーキテクチャは、もう15年以上も停滞したままだった。CPU は、i386 で 32 ビット化した後、進化が止まっていた。もちろん、486 とか Pentium とか、浮動小数点プロセッサが内蔵されたり、高速化されたりしたが、抜本的なアーキテクチャは i386 のままだった。パソコン自体のアーキテクチャも PC/AT のまま変化が無かった。これもメモリーが増えたり、バスの転送速度が高速化したりしたが、基本は昔のままだった。いくら高速になり、メモリーや HDD 容量が増えても、それは量的な変化であり、質的な変化とは思えなかった。
だから、私は、15年前に世間一般よりも早く PC/AT のデスクトップ・パソコンを手に入れて以来、新しいデスクトップ・パソコンは欲しいと思わなかったのだ。

この 15年間、パソコンはモバイルとインターネットの方向に進化していたんだと思う。だから、私の買ったものは、サブノート・パソコンだったり、Zaurus だったり、玄箱だったりした。

だが、数年前、i386 以降進化が止まっていた CPU アーキテクチャに新たなる変化が訪れた。それが、64ビット化とマルチコアだ。この64ビット化とマルチコア（デュアルコア）には、AMD 特に Athlon64 X2 の功績が大きい。
もちろん、64ビット化は、AMD が始めた訳じゃ無くて、以前から、DEC や HP やインテルだってやって来たことだと言うことは認識している。マルチコアだって、AMD が最初じゃ無いだろう。そもそも Athlon64 X2 自体が、AMD の中では、先行して64ビット・マルチコア化していたハイエンド CPU の Opteron を安価にした普及版との位置付けだ。
だが、それが分った上で尚かつ Athlon64 X2 の功績は認めざるを得ないと思うのだ。

Athlon64 X2 が出る以前の64ビットとマルチコアは、高いだけで色物の域を出ていなかった。少なくとも私にとっては、そうだ。将来性も不安で、コストに見合った性能向上も期待できず、それ以上にソフトが対応していなければ意味の無い64ビットとマルチコアは無用の長物に過ぎない。
ところが、Athlon64 X2 の登場は、リーズナブルなコストと低い発熱量のため普及し、それがソフトの対応に反映し、さらに普及へ拍車をかけた。その結果、64ビットとマルチコアは色物から、次世代の本命になった。

Athlon64 X2 の快進撃は、インテルをして大名跡の Pentium を止め、Core Duo、Core 2 Duo の投入に踏み切らざるを得ないほどだった。
Core 2 Duo 登場後、Athlon64 X2 は、インテルにトップを奪い返されるのだが、これが更なる波及を生む。AMD は Athlon64 X2 の価格を思い切り下げたのだ。
この事は、AMD にとって苦汁の選択だったのだろう。が、我々のような貧乏人のユーザーにとっては福音となった。ついに64ビット・デュアルコアCPUが、我々の手の届く値段に落ちて来たのである。
今回、Athlon64 X2 を購入したのは、コストパフォーマンスが良いこともさることながら、例え短期間と言え、巨人インテルに一矢を報いた勇者に敬意を表したのは言うまでもない。

64ビットとマルチコアCPUは、i386 以降停滞していたアーキテクチャを、久しぶりに進歩したと言い切れるほど大きな変化なのだろうか？
i386 が、それまでの CPU と違うのは、実は 16ビットから32ビットへの拡張ではない。MMUが内蔵され、メモリー保護と仮想化の実現が、その後の OS (Windows や UNIX)の出現を呼んだのだと思っている。ほぼ同時期に同じく MMU を内蔵した 68030 が登場するのだ、Mac を除いて広く普及にすることは無かった。これは「美しいアーキテクチャが必ずしも勝つ訳ではない」事の証明であろう。

では、64ビットとマルチコアは、i386 にとっての MMU 内蔵と言うほどの大きな変革なのだろうか？
実を言うと、それを言い切れるだけの確実な証拠は未だ無い。

64ビットは、直接アクセスできるメモリー容量が多くなるとかレジスタ数が増えるとかのメリットはあるものの、言ってしまえば量的な変化に過ぎないのかも知れない。
マルチコアは、どうだろう。動作するCPUが一つなのか二つなのかは、或る意味、量的な変化だ。しかし、単数なのか複数かは質的な意味もあるかもしれない。いずれはグレープのように超並列コンピュータに進化する第一段階と位置付けることができるなら大きな意味を持つだろう（ちなみに開発中の最新 GRAPE-DR は、一つのチップ上に 1024 コアを持ち、それを 2000 チップ、総計 200 万コアが同時に計算すると言う）。

実は、64ビットとマルチコアに隠れているが、もう一つの革新的技術である「仮想化支援機能」こそが、本命なのかも知れないと思い始めている。仮想化支援機能とは、i386 での仮想化機能から取り残された CPU の小さな一部分までをも仮想化する機能である。この機能により、完全な仮想化が可能になる。i386 アーキテクチャでは、アプリケーションプログラム・レベルでは仮想化できたが、OS レベルまで仮想化する事はできなかった。
仮想化支援機能のあるデュアルコア CPU なら、一つのコアに Windows を割り当てて、もう一つのコアに Linux を割り当てて同時に動かすことが可能になる。

ユーザーが一人しか居ない状態で、二つの OS を同時に動かして何の意味があるかと思う人も多いだろう。だが、20年以上も前に、「大型計算機のように多数のユーザーが時分割(TSS)して使うならともかく、一人しかユーザーの居ないパソコンに TSS によるマルチタスクを動かすことに何の意味があるのか」と議論したことを思い出す。当時、個人ユースにマルチタスクの意味があるとは思えなかった。しかし、現在ではマルチタスクなしにパソコンは考えられないし、そのマルチタスクを可能にする MMU こそが、i386 アーキテクチャの根底である。

さあ、私の見込み通り、64ビットとマルチコアと仮想化支援機能が、パソコンの飛躍を生むパラダイムシフトになるのか？　楽しみである。

パソコン購入

パソコンを買った。
前回パソコン買ったのは2000年だったから、
今世紀初のパソコン購入である。
デスクトップ・パソコンに限れば、15年ぶりの購入だ。

デュアルコアである。
高速である。

今回のパソコン購入の切っ掛けは、2月にさかのぼる。
3連休を利用して、小惑星有人探査の軌道計算をした。
（小惑星有人探査なんて、本業じゃ認められないので、自宅にて個人所有のパソコンで計算する）

軌道要素の判って居る 460個の NEO (後で、はやぶさチームの人に聞いたら、その3倍以上あるそうだ)を、片っ端から往復に必要な日数とΔＶの関係を計算した。地球と目的の NEO との位置関係もあるので、30年間に渡って、10日毎に出発日をずらしながら計算した。

計算は、7年前に購入したサブノート(ThinkPad)、CPU は モバイル・セレロン 450MHz で行った。
連休を全て潰して計算できた。
その間は、Web を見たり、メールしたりできない。
その上、後で NASA の人に、この30年間じゃなくて、60年後に、もっと良いタイミングがあると聞いた。（腹立つなあ）

と言う訳で、「高速で計算できること」と、「計算中に他の作業ができるようにデュアル・コア」が欲しくなって、今回のパソコン購入となった。

購入したパソコンの構成は、次の通りだ。
・CPU： AMD Athlon 64 X2 4200+
・キューブ型ベアボーン
　　オンボード GeForce 6150 グラフィック機能
・メモリー： 1GB
・HDD： 320GB
・光学ドライブ：マルチドライブ
・キーボード／マウス
・14インチ液晶モニター
・OS： Windows XP Home

これで、7万9千円だ。ベアボーンは展示品で、値引きしてもらっているが、それでもデュアルコアのパソコンのフルセットで、この値段で買えるとは大したもんだ。

上記の構成を見て、「どれだけ高速計算に特化したパソコンだろう？」と期待した人は、がっかりしたかもしれない。私のパソコンの構成は、デュアルコアとしては最低限のものだろう。

今回は、CPUが「64ビット・デュアルコア・仮想化支援機能」の3つを満たす範囲で、最も低コストの構成にした。ただ、経験上、ケースが重く動かせないと使わなくなるので、ミニタワーではなく、キューブにした。また、私は本来 LINUX 使いで、Windows XP は必要ないが、家族が使うので、購入した。ケースをミニタワーにして、OS 抜きにしたら、もっと安くなる。

実は、自作パソコンを作るのは初めてなので、慎重に組み始めた。が、あっけないほど簡単に組み立て�