32bit/64bit OSの性能比較とスパコンの性能比較の関係
最近Windows 7とやらが発売され、結構な人が64bit版を導入しているようです。僕は諸事情で32bitですけど。64bitと32bitの違いというと、たくさんのメモリが使えるかどうか、だと思ってる人もいると思います。それはそれで正しいのですが、計算性能でも違います。
ところで最近スパコンの性能というのが話題ですね。例えばGordon Bell C/P 賞を取った長崎大学の結果と比較して、京速計算機がうんぬんという比較です。で、この話題と32bit/64bit OSの性能差というのは密接に関係してるんですよ、というのがこの記事の話です。
まず問題を計算する際には、プログラムを実行するわけですが、プログラム中の命令は大きく2つに分かれます。計算命令とI/O命令です。計算命令というのは、CPUの中で加減乗除などを行うだけの命令で、I/O命令というのはCPUの外部と通信する命令です。I/O命令の例としては、メモリアクセスやネットワークアクセス、GPUへの計算渡し、などが含まれます。プログラム中の命令の中には、計算命令とI/O命令の二つを同時に実行するものもありますが、CPUは実際にはどちらか一方を行っている状態と考えてかまいません(パイプラインとか難しいことを言わないように！)。ここで、計算命令のほうがI/O命令よりも時間がかかっている状況をCPU bound、I/O命令のほうが時間がかかっている状況をI/O boundと呼びます。
さて、32bit/64bit OSの話に戻します。このOSによる違いは何か、というと32bit OSよりも64bit OSの方がI/O boundの問題が速くなる、ということです。具体的なベンチマークは、こんな感じです。例えばData FittingやPiの計算、行列転置などはメモリアクセスがほとんどである、典型的なI/O boundな問題です。一方、このベンチマーク中で若干遅くなっているような、行列積や数値積分問題というのはメモリアクセスが相対的に少ないCPU boundとして知られている問題です。ちなみに一般の数値積分問題では微分方程式の初期値問題などのI/O boundなものもありますが、ここでやられているのはおそらくのような問題だと考えられます。
次にスパコンの話題として、長崎大学のGPUをつないだ話をしますと、N体問題というのを解いているようです。一般のN体問題は、上でCPU boundといった行列積問題とほぼ同じであり、やはりCPU boundです。そしてこういったCPU boundな問題に対しては、GPUが効果的に使えることが知られており、こういう話題をある程度知っている人達は比較的性能に意外な点は無いと捉えているように思われます。ただし、今回の場合はちょっと特殊なとき方をしているので、別エントリで補足します。
その一方で、I/O boundな問題が速くなければ一般の問題というのはほとんど速くならないため、京速計算機にはその点が期待されています。この京速計算機に乗るCPUはSPARC64という、その名のとおり64bit CPUでして、OSも当然のように64bitが使われます・・・多分。で、ただそれでもまだまだI/O boundが解決されない、というのが問題であって、そういう問題はPC clusterなどではとても解決できないのです。
ということで、32bit OSが問題としている点と、PC Clusterや長崎大学のスパコンが問題としている点は実はほとんど同じなんですね。解決案は64bit OSだったり京速計算機だったりと違いますが。
プログラミング言語のコミュニティの成長過程に関する雑感
今から書くのはあくまで個人の感想ね。良し悪しも論じるつもりはないよ。
あるプログラミング言語ができると、まずそれに群がる人たちが出てくる。新し物好きの人たち、アルファギーク(笑)の人たち。今だとGoとかがそれにあたるのかもしれない。その人たちの中で、面白いものを作る能力がある人、そして他の言語で培った能力がある人たち、すでに発言力がある人たちがもてはやされる。
次に、この一時的な盛り上がりがだいぶ落ち着く。そうすると、その言語が本当に好きな人たちが集まってくる。これがコミュニティとして長く続くことになる。「○○ユーザー会」とかって名前がつく。その人たちの中で、初心者にわかりやすくちゃんと文章にしてまとめてくれる人、本を出す人たちが現れ、リーダーシップを発揮する。
そうこうしているうちに、言語が成長を遂げる。言語としては成長だが、シンプルさがなくなることもある。余計な機能のせいでわかりにくくなることもある。変なライブラリが追加されたりする。大体の場合、この段階までで初期のコミュニティのリーダーはいなくなる。なぜなら、そのリーダーにも仕事がある。引越しもするし、管理職になったりもする。元々世話を焼いたり、リーダーシップを取れる人だから、企業でも重宝される。コミュニティは維持されるが、リーダーは何度か変化する。
さらにだんだん時間がたつと、言語の使用人口はだんだん減ってくる。コミュニティのMLの投稿も念に何度かSPAMが来る程度。アンチも沸きにくいレベルになる。今のPerlとか、あるいはもっとひどいところではFORTRANみたいな状態。言語のアップデートは行われるものの、頻度も低いしそれほど注目しても仕方がないというレベル。
とまあ、こんな感じで変化していく、と思うのですよ実際。ずっと続く言語ったって、そもそもそんなに分野の歴史がないしねえ。で、その中でのコミュニティについて考えてみると、その中で活動する人たちは何回も代替わりを行うわけだ。Perlについては見てきたけれど、例えばここ10年で見た場合でも、つまりはPerl5が登場した後であっても、すでに最低2回の代替わりが起きている、と感じている。書籍や雑誌記事の著者とか見てるとすぐわかる。
これが良いことかどうかはわからないけど、少なくともそれくらいの短期間で変わるものだ、という認識をまず持つべきで、そうであれば例えば複数あるコミュニティを統合して一元管理したいだとか、あるいはコミュニティの体質改善だとか、そういった議論を行うこと自体がナンセンスだと感じるはずだ。統合したり、体質改善を行ったらすでにそのころには代が変わっているのだし、そもそも体質改善した張本人がその場にいなくなったりするのだから。
ということを、 http://kaede.to/~canada/doc/are-japanese-perl-document-communities-all-right を読んで思ったという話。以上。
備忘録
http://ushinews.com/?p=148
Windows 7で英語キーボード使う場合は、ベータ版じゃなくても同様の問題が発生するようだ。
正規の方法については、今度Lenovoに聞こうと思うが・・・・
暫定的な解決法としては、
http://poiuy.jugem.jp/?eid=86
に書いてあるが、
レジストリを以下のとおり修正
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters]
"LayerDriver JPN"="kbdlk41a.dll"
"OverrideKeyboardSubtype"=dword:00000081
"OverrideKeyboardIdentifier"="DEC_LK411_ANSI"
とのこと。一応対処はできた。
追記として、Lenovoに聞いたがレジストリ書き換え以外の方法はないらしい。どうにかならんのかね、この仕組み。
レジストリ書き換えの抵抗が無くなって久しいけれど、「正当な方法」が「レジストリ書き換え」で「個人の責任」ってのはどうかと思うんだぜ。
