« August 2007 | Main | October 2007 »

September 26, 2007

告知

10月9日、新宿ロフトプラスワンの「なぞなぞ宇宙講座4〜この世界で人は生きていけるのか?〜」に出演する。
詳細は、ここを

| | Comments (0) | TrackBack (0)

September 24, 2007

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

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

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

システムモニターを見ながら、左側のプログラムを走らせたところ、2つのCPUコアが50%強程度で動いていた。これは、各コアに、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 の方は 1GBだ。
仮に比例関係が成立すると、モバイルセレロンなら、41時間11分27秒もかかることになる。(いや、2月に計算した時は、実際、そのくらいかかったし。あの時は430個だったけど)

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

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

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

| | Comments (0) | TrackBack (1)

September 23, 2007

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

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

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

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

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

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

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

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

どうやれば、スレッド間でメモリを明確に分けるのか、調査するのも面倒になったので、fork を使って、プロセス自体を分離することにした。
これが次のプログラムである。(プログラム中パイプを使って通信しているので、「fork」ではなく「open」で子プロセスを起動している)
・成功プログラム その3: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だと、約2倍の速度が得られる。
・シングルプロセスのみなら、むしろマルチコア非対応のカーネルの方が速い。
・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 を使うことが多い。小惑星探査軌道計算も、そうである。

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

| | Comments (0) | TrackBack (0)

September 22, 2007

パソコンを買った理由

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

パソコンのアーキテクチャは、もう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ビットとマルチコアと仮想化支援機能が、パソコンの飛躍を生むパラダイムシフトになるのか? 楽しみである。

| | Comments (0) | TrackBack (0)

September 17, 2007

Athlon64 X2 に Debian Linux Etch をインストール

新しく買ったパソコンに Debian Linux Etch をインストールした。
今年4月にリリースされた Debian Linux Etch は、今までの 32ビット版 i386 アーキテクチャだけではなく、64 ビットの AMD64 にも正式に対応して居る。どちらをインストールしようか悩んだが、結局、両方ともインストールしてしまった。320GB の HDD を四分割して、80GB を XP Home に、80GB を 32ビット版 LINUX に、80GB を 64ビット版 LINUX に割り当てた。残りの 80GB を何に使うかは未だ考えて居ない。
新しい 64ビット版 LINUX に苦労するかと思いきや、意外な事に 32ビット版の方が大変だった。

インストール前から、不安な点は「デュアルコア」「GeForce 互換オンボード・グラフィックチップ」「無線LAN」「オンボード・サウンドチップ」である。

簡単に解決した順に書くと、まずはサウンドチップはカーネル標準で対応して居て全く問題なく音が出た。

無線LANは、カーネル標準では対応しておらず、OS のインストールは有線LAN経由で行わざるを得なかった。しかし、一旦 Debian Linux がインストールされた後は、無線 LAN チップのメーカーのホームページからドライバのソースコードがダウンロードでき、これをコンパイルしたら、使えるようになった。ただ、32ビット環境だと少し不安定なようで、起動直後は接続しても、いつの間にか切れることがある。64ビット環境では全く問題ない。

次はデュアルコアの対応だ。
32ビット用の Debian Linux Etch i386 をインストールしたら、デフォルトでインストールされたのはシングルコア用のカーネルだった。マルチ CPU 用には最後に「smp」と言う名前の付くカーネルが良いらしいのだが、smpの付いたカーネルはインテル用だけで、私の使って居る Athlon64X2 に使えそうなのは無かった。
32ビット版は、ひとまず置いておいて 64ビット用の Debian Linux Etch amd64 をインストールしたところ、デフォルトのカーネルで、マルチコアに対応して居た。ところが、このカーネルの名前に smp の名前が無い。それに、このカーネルの名前、さっき 32ビット版でカーネル名の一覧を表示した時に同じ名前があったぞ。
32ビット環境に戻して、カーネルに amd64 と言う名前が無い付いたものを入れてみた。すると、CPU が二つとも動くでは無いか。う~~ん、どのカーネルがデュアルコアに対応して居るか、ちゃんと書いて欲しいな(探せば書いてあるんだろうなあ、英語で)

最後は、「GeForce 互換オンボードグラフィックチップ」。デフォルトでインストールされるドライバは全く役に立たないので、標準機能のみの VESA ドライバーに切り替えて、その場をしのぐ。一応 VESA ドライバーでも普通に使う分には問題ない。が、グラフィックカードのアクセラレータ機能は一切使って居ない。その後、チップ・メーカーの nVIDIA から供給されて居るドライバをインストールし直す。64ビット環境では、メーカー製のドライバのお陰で、表示が素早くなった。もちろん、3D 表示にも対応して居て、beryl と言う 3D デスクトップもスムーズに動作する。
ところが、32ビット環境では上手くインストールできない。これは、シングルコア用カーネルでもデュアルコア用カーネルでも同じ状況だ。仕方が無いので、未だに、32ビット環境では VESA ドライバーを使って居る状態だ。

おまけだが、FLASH もインストールしてみた。これが無いと YouTube で動画も観れない。32ビット環境では、すんなりインストールできたものの 64 ビット環境にはインストールできなかった。
やはり、64 ビット環境にも使用に制約があるのだなあと思って居たら、32ビット FLASH を 64 ビット環境で使う方法をネット上で見つけてしまった。試してみると上手く行く。YouTube で動画を観ながら、3D デスクトップをグルグル回しても全くストレス無く表示できる(3D 回転中、動画の裏側が見えるのが御愛嬌だ)。

と言う訳で、現状は 64 ビット環境は苦労どころか、32 ビット環境より、ずっと快適に使える状態にある。

と、こんな事ばかりして、なかなか本題の小惑星への軌道計算などに取り掛かれないのであった。

| | Comments (4) | TrackBack (0)

September 09, 2007

パソコン購入

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

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

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

軌道要素の判って居る 460個の NEO (後で、はやぶさチームの人に聞いたら、その3倍以上あるそうだ)を、片っ端から往復に必要な日数とΔVの関係を計算した。地球と目的の 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 抜きにしたら、もっと安くなる。

実は、自作パソコンを作るのは初めてなので、慎重に組み始めた。が、あっけないほど簡単に組み立てが終わった。相性問題も無かったようで、Windows XP のインストールも、すぐに終わった。

ところが、画面を見ると赤色が全く出ていない。古いパソコンとかCRTモニターを出して調べるが、新規購入のパソコンも液晶モニターも個々には問題ない。だが、新しいパソコンと液晶モニターの組合せだけが異常だ。
結局、液晶モニターのコネクタの接触不良だと判り、接点復活剤をかけて直った。

今のところ、Windows XP しか入ていないが、この範囲では上手く動いている。XP Home はマルチプロセッサには対応していないので、ちょっと心配したが、ちゃんとデュアルコアは効果的に働いているようだ。

肝心の LINUX をインストールしていないので、64ビットや仮想化支援機能の方は確認していない。試したいことは色々あるので、結果が出たら報告したい。

| | Comments (4) | TrackBack (0)

« August 2007 | Main | October 2007 »