« December 2005 | Main | February 2006 »

January 23, 2006

端末のフリーズ

なんか最近、端末がフリーズすることが多いなぁと思っていたら…。GNU/Linuxがフリーズした時の対処

端末(コンソールやkterm)上でフリーズした時、まず試すこと
ctrl-qを押してみる
認めないぞ、そんな、隣のemacsで検索しようとして入力したCtrl+Sが端末に行っていて固まっていただけなんて…

| | Comments (0) | TrackBack (0)

デッドライン

卒論は余裕。……そんなふうに考えていた時期が、俺にもありました。

卒論が本当にやばい。締め切りは2月7日。なのに本当に何もできていない。さぼったという自覚はないけれど、見通しが甘かったというか、計画性がないというか、自分の能力を過信していた。あまりにやばすぎて、ここ数日はなんだか卒論についてのあれこれが他人事、自分には関係のない世界の出来事のように思えてきた。本当にまずい。

| | Comments (2) | TrackBack (0)

January 13, 2006

ニコンマニュアルの終焉

ニコンがマニュアルカメラ製品及びフィルムカメラ製品の大幅なラインナップ縮小を行ったことが各地に大きな衝撃をもたらしている。以前より店頭在庫状況の推移などから危機がささやかれてはいたが、ついにその不安が現実のものとなってしまった。

今回の発表によれば、フィルムカメラはF6とFM10のみが生産されるという。それ以外のAF/MF機は全て生産終了となる。F6は「F一桁」と呼ばれるAF一眼レフの最高峰であり、一方のFM10は他社製品のOEMという最廉価品である。

MFからAFへの移行に伴ってばっさりとマニュアルシステムを切り捨てたキヤノンと違って、ニコンはAFへの移行に際してもレンズマウントを変更せず、「Gショック」[1]やDXレンズのような一部例外はあれど、基本的には下位/上位相互の互換性を維持し続けてきた。そしてマニュアルカメラの生産から撤退するメーカーが相次ぐ中、ひたすらマニュアル製品の生産と販売を続け、FM3Aのようなすばらしいマニュアルカメラ製品も新たに開発してきた。特に、昨年末に発売された最新のデジタル一眼レフ「D200」が、それまでの普及価格帯デジタル一眼では省略されていた、絞りリングへの対応を盛り込んだことで「過去の製品も重視するニコン」の価値をあらためて示していた矢先のことだけに、ショックは大きい。

俺は完全にデジタルな人間なので銀塩フィルムは全く使わないのだが、カラースライドの美しさは認めるところであるし、デジタル撮像素子は階調表現の面でまだまだフィルムの足下にも及んでいない。何よりも、俺がニコンを使うようになったきっかけはNikon EMというマニュアルのカメラである。

はっきり言って今の時代にフィルムのカメラは売れないであろう。友人が指摘していたが、プロはその場で確認できることと速報性のメリットからほとんどがデジタルに流れており、銀塩を使うのはマニアか芸術的な写真家くらいである。そしていわゆる一般人は普通コンパクトデジカメか[2]、そもそも携帯電話で間に合っている。ニコン信者としては、売れない製品を無理して維持し続けてニコンに倒産されても困るので、今回の決定は黙って納得せざるを得ないのだが、やはりフィルム・マニュアルカメラからの事実上の撤退には一抹の寂しさを禁じ得ない。

もっとも、その中にあっても未だ一部のマニュアルレンズ製品の生産を続けると宣言しているニコンはやはりすごいのかも知れない。

Continue reading "ニコンマニュアルの終焉"

| | Comments (2) | TrackBack (0)

January 12, 2006

蛋白質核酸酵素

その昔「bit」を読んでいたときに、広告の中に「蛋白質 核酸 酵素」という名前の雑誌が紹介されているのを発見して「すごい雑誌もあるもんだなー」と思ったものだが、生協の書籍部に行ったらおいてあった。確かに大学の書籍部なら需要もあるだろう。

bitははるか昔に休刊してしまったのだが、この雑誌は未だ残っているという事実は、ITよりもバイオが流行っているという傾向を示しているのだろうか?

| | Comments (0) | TrackBack (0)

January 10, 2006

Dual Channel Mode Enabled

俺のマシンのチップセットはIntel 865G。(買った当時の)最新チップセットで、DDR SDRAMのデュアルチャネルに対応する。当然ながらデュアルチャネルを活かすためにメモリは2枚購入し、デュアルチャネルで快適なPCライフを満喫しているのである。……と、今日まで思っていた。

今日、研究室の先輩がマシンを買ってきた。マシンといっても、自作パーツを買ってきたと言うことであって、研究室で組み立てていたわけだが、その様子を見ていたところ、メモリを取り付けるところでふと重大な事実に気づいたのである。

デュアルチャネル対応のメモリスロットは大抵黒と青の2色で塗り分けられていることが多い。メモリバンク1,2,3,4が1と2、3と4で対になって並んでおり、奇数番が青、偶数番が黒といった具合である。

マシンを購入した2年半前、俺はてっきり対になって並んでいる1と2にメモリを挿すとデュアルチャネルになるものと思ってメモリを挿した。その結果何事もなかったかのようにマシンは起動したので、めでたいと思って、何となく「デュアルチャネル速ぇぇ」とか言ったりしていたのだが、今日改めて調べてみたところ……正しくは同じ色のスロットに、つまりスロット1と3に挿すべきだったのである!(AOpenのFAQ…なぜかつながらないのでGoogleキャッシュ)

デュアルチャネルモードで動作した時は画面のように「Dual Channel Mode Enabled」と表示されます。
そんな表示見たことないYO!

ということで、早速家に帰って、メモリの位置を入れ替え。めちゃくちゃ固くて指が痛くなった。もう少しでマザーボードが割れるんじゃないかと心配になりつつも、無事装着完了。起動してみると……出るではないか、"Dual Channel Mode Enabled"。なんてこった。

そんなわけで、ようやく本来の性能を出せるようになったところでベンチマーク……ここで気づいたのだが、以前購入直後に取ったベンチマークは昔のCPU(Pen4 2.4C GHz)のもので、今はCPUが新しく(Pen4 3.0GHz)なってしまっているので厳密な比較ができない。まあ、参考程度に。

使用したのはHDBENCH 3.30。メモリのR/W/RWが、151449/59186/115277→225535/81169/162610に向上。2倍になるわけじゃないのね。FFOベンチも11.45sec→11.22secに向上。

そんなわけで、俺のマシンは購入後2年半を経てようやく本来の性能を発揮できるようになったのであった。マニュアルはちゃんと読もう……。

| | Comments (0) | TrackBack (0)

January 09, 2006

X60欲しい!

卒論がせっぱ詰まってくると逃避本能からかふつふつと物欲がわいてくるのである。

先日、ついにIntel Core Duo(Yonah)が発表された。YonahはIntelが初めて本腰で作った「デュアルコア」CPUであり、Pentium M時代からの性能の高さもあって非常に期待される製品である。CES絡みの記事にちょこっと出ていたが、LenovoがThinkPad T60/X60を発表したので、個人的に興味のあるXシリーズに絞って調べてみた。

・X60: New ThinkPad X60 Ultraportable Notebook models include a three-year limited warranty
・X60s: New ThinkPad X60s ultraportable notebook models come with a three-year limited warranty

X60とX60sの2機種が発売される模様。X60は処理能力重視、X60sは軽量さとバッテリ持ちを重視という印象である。詳しいスペックなどは上記リリース文を参照して欲しい。

X60のCPUはT2400、X60sはL2400である。Intel Core Duoのモデルナンバーの読み方は、Tが通常電圧版、Lが低電圧版ということらしい(超低電圧版は後日出るとのこと)。特筆すべきはどちらもHDDが2.5インチとなっていること。X40に対しては1.8インチHDDを不満点として挙げる人が多かった(俺もその一人だ)が、問題は解消されたことになる(これに関しては詳しく後述)。バッテリ持ちもすごい。X60sは"Up to 8.0 hours"だそうで、相当に期待できる。今度のCentrinoプラットフォーム(Napa)では消費電力が大幅に下がると言うことが期待されていたが、早速その威力が示された形だ。

気分的にはX60はX32系の後継、X60sはX41系の後継という感じであるが、どうやら両方とも筐体はほぼ共通であるようだ。少なくとも写真と、Footprint size (268 mm x 211 mm)は共通。ただし重量が異なる。X60は1.43kg(4セルバッテリ時)、X60sは1.2kgとある。X60sはデフォルトで8セルバッテリを積んでいながらなぜこんなにも軽いのだろう?X60sのリリース文をよーく読んでみると、

HDDs: 40, 60, 80, and 100 GB (2.5-in 5,400 rpm), 100 GB (2.5-in 7,200 rpm), 30, 40, and 60 GB (1.8-in 4,200 rpm Japan only)
と書いてあって、2.5in.と1.8in.を選べるようだ。最近発表されたNECのVersaPro UltraLiteのようなものかもしれない。重さに関して"Beginning at"と書かれているのは、1.8in. HDDにした場合のことなのだろうか。最初1.2kgでバッテリが8時間持って2.5インチHDDが使えると思って狂喜乱舞していたのでちょっとトーンダウンだが、まだ正確なところはわからないし、肝心の日本での発表がまだなので、もう少し様子を見たいところだ。

ざっとスペックを見る限り、X60及びX60sが、X32やX41と比べてはるかに高性能で魅力的な製品になっていることは間違いない。モバイルノートにデュアルコアCPUが載る時代がついに来た。このインパクトは、3年前のCentrino登場よりも大きいかもしれない。日本での正式発表と発売が待たれる。

なお、いくつか検索して見つけた中ではLenovo、ThinkPad X60発表が最も有用であったのでここに紹介させていただく。

| | Comments (0) | TrackBack (0)

January 08, 2006

STLコンテナとSSE

「vector<double>に対してSSEを適用したいんだけど」と某氏に相談されたので、相談料代わりにネタにさせていただく。

x86はデータのalignmentに対してはかなり制約が緩やかで、大抵の場合は(性能上のペナルティはあるにせよ)alignmentを無視していても正しく動作する。ただし、SSE命令は例外で、16byte alignといったalignmentを要求する命令がある。(違反すると何らかのexceptionが起きる)

vectorは勝手にメモリを確保してくれるので普段は便利なのだが、SSEを適用しようとすると、「勝手に確保された」メモリが果たしてalignmentを守っているか?という疑念が生じるわけだ。対策としては4つ考えられる。

1.alignmentを満たすallocatorを自前で書き、vector<double, aligned_allocator<double> >のようにして使う。一番正統だがallocatorをきちんと書くのは結構大変そう。
2.SSEを使うときだけalignmentを守った別のdouble配列にコピーする。SSEによる高速化が顕著で、配列サイズが小さくないと意味がない。よく考えるととっても意味のない方法に思えてきた。
3.vectorを諦めてaligned配列を手動管理する。現実的。
4.SSEを諦める。ある意味現実的。

ちなみにvectorのメモリの連続性については連続である、ということで決着済みなのでまあ連続であるとしてよいだろう。

ちょっと調べてみたところ、STLPortのallocatorはソースをちょびっといじるとalignmentを設定できるようだ。それから、allocatorを書くのもそれほど大変ではなさそう?真の意味でのallocator(フリーリストの管理やら云々)をするともちろん大変だけど、alignmentを揃えるだけで、後は既存のoperator newなんかを使い回そうと考えれば、インターフェースを定義するだけなので簡単かも知れない。

| | Comments (0) | TrackBack (0)

C++のリファレンス

Microsoftの「Get! Visual Studio 2005」キャンペーンに釣られて入手などしてみた。VS.NET 2005 AcademicはStandard相当であり、ProfessionalのAcademic割引はない見込みである。よってこれがProfessionalを安く入手する唯一の機会となるわけだが、StandardとProfessionalを比べて、うれしい点は64bitコンパイラがついてくることくらいか。まあこの先64bitコンパイラを持っていないのもどうかと思うので、安いしよしとしよう。

ダウンロード時に「CD1」「CD2」というボタンがあって、それをクリックするとダウンロードできるのだが、どうもFirefoxとは相性が悪いらしく、application/octet-streamな謎の412KBのデータが落ちてくる。実はこれがダウンロード用の実行ファイルなので、適当にdisc1.exeなどとリネームして実行するとダウンロードできる。unno氏は何も言っていなかったがOperaだと大丈夫なのかな?

さて、VS.NET 2005であるが、以前から指摘されている通りC++、特にSTL関連のヘルプがめちゃくちゃ使いにくい。何度もリンクを辿らされる上に気づいたら元の場所に戻っていたりして、欲しい情報にはたどり着けないことが多く、ストレスがたまる。そこでC++についてはMSDNのヘルプを諦め、外部のサイトを使うことにしている。

よく使うのはC/C++ Referenceとその翻訳版、あるいはC++ Referenceといったところ。後者はIOstreamのクラス継承図があって大変わかりやすい。

書籍では前にも挙げたC++標準ライブラリチュートリアル&リファレンスがよいと思うのだが、書いたとおり絶版であり入手困難。最近では、C++ライブラリクイックリファレンスあたりはどうなのだろうか?詳しく読んだことはないが、地下で誰か持っていたような。「リファレンス」というからには説明的要素は少ないのだろうか。とすると微妙かも。

ところで最大の問題は最近C++を使う機会が全くないため、C++の細かな作法をすっかり忘れてしまっている点にあるわけだが。例えば、coutで16進表示する方法(printfの%x)とか、std::sortにcomparatorを渡せることだとか。カーネル開発もC++でやりたいもんだねぇ…。

追記。

あれ? そういえば、もう2005年じゃないじゃん。
本当だ。

| | Comments (2) | TrackBack (0)

January 07, 2006

優先順位

コーディングのはまりどころを日記に書くのが流行っているようなので便乗。

慣れない言語では演算子の優先順位に対する誤解や認識不足から謎のコンパイルエラーやバグに悩まされることがある。例えばOCamlでは、「関数適用が何にもまして強い」という性質がC等の経験者には特異に感ぜられ、最初の頃は結構苦労した。

ではCなら大丈夫かというとそんなことはなく、Cでも優先順位で間違いを冒すことは時たまある。最もわからないのがビット演算子の強さだ。ここ数日はまっていたコードは次のようなものだ。(実際には、このコードに問題があるということにすら全く気づかず、あれこれprintkをはさんでvm_flagsの値がおかしいことを突き止めてからようやくこのコードに思い至ったわけだが)

unsigned long flags = vm_flags | (vm_flags & VM_SHARED) ? VM_REMOTE : 0;

意図していたのは、
vm_flags | ((vm_flags & VM_SHARED) ? VM_REMOTE : 0)
という結合。しかし、実際には
(vm_flags | (vm_flags & VM_SHARED)) ? VM_REMOTE : 0
と解釈される、らしい。まるまる2日つぶしてしまった……。

ところで先日、"spinlock recursion"なる恐ろしげなエラーメッセージを見た。やはり何度かは強烈なkernel panicを出さないとカーネルいじってる気がしないよね。

| | Comments (5) | TrackBack (0)

January 02, 2006

初夢

明けましておめでとうございます。今年も不定期ながら日々の妄想を書きつづっていきたいと思っております。

さて、とりあえず初夢とやらを見たので覚えている範囲で書いておこう。

なぜか舞台は高校の時のクラス。Y中氏が模試の問題っぽいのを配っている。「なんたらかんたら(やたら長くて難しそうな名前)数学」と表紙にあって、「だから俺は数学とは金輪際関わらないことにしたんだってばー」とか文句を言っている。みんながそれなりに問題に見入っているのでしょうがないから自分も開いてみると、なんかコンピュータサイエンス系の超簡単そうな問題が並んでいる。これならさすがにできるんじゃねぇ?、と思う。

覚えてるのはここまで。この前や後にもきっと意味不明なエピソードがある気がするが、記憶の彼方である。なんか別におもしろいわけでもなく、ただただ意味不明な夢だなぁ…。

| | Comments (0) | TrackBack (0)

« December 2005 | Main | February 2006 »