夜行録 - 酔歩.net

PGI の C++ コンパイラでインライン指定したメンバ関数が include 先で衝突する件。
なんでか勝手に解決した

ストラウストラップの3版(p. 284)には、クラス定義内で単純に宣言されるだけでなく、定義されるメンバ関数は、インラインメンバ関数と見なされる、とある。
いや、それは知っていて、というか、昔のコードはその書き方ばっかりですっげー読み難くなっているんだが、別にそうしないとインラインにできない、とは書いてないと思うんだがどうだろう？

ともあれ head ファイル内に書かれていたメンバ関数をクラス定義内定義に変えてやったら、衝突しなくなって IPA もできるようになったのである。よく判らん。

会社のオフィスから、某所に設置した計算サーバ使おうとすると Internet 経由で slogin する(GWマシンに)ことになる。それはいいんだが、作業してて、ふっとほかのこと(ノートとったり)して、気がつくと TCP 的にコネクションが切れてることが頻出。

これはてっきり、プロバイダが ssh で接続しっぱなしなんて普通しないんだからねっ、と勝手に切りまくってんのかと疑ってたんだが全然違った。

調べているうちに、NAT な環境で放置したSSH接続が切断される問題について、という件を発見。なんだルータかよ……
設定いじってやったら切れなくなった。

拾いもののバイナリじゃ、なんでか他所で compile/link した LLVM バイナリが実行時にエラーとなったので、諦めて野良 build。
てゆーか、 OS 古いぞ。 gcc なんて 3.4.6 だし…。ということで、まずは GCC-4.2 の野良 build からorz

GCC-4.2 を $HOME/GCC 以下にインストールする。 enable-languages は c,c++,fortran (gfortran を使うこともいつかあるだろ)。以降、 $PATH と $LD_LIBRARY_PATH に $HOME/GCC/bin と $HOME/GCC/lib64 を追加。とくに後者は、 libstdc++ をリンクしようとして /lib/ を見に行ってコケるケースが頻出する。

[read more]

学生の頃に書いた太古のコードを、この部分だけ書き直せば学生の時に書いた自前テンプレートクラス捨てられるな、ってんで書き直す。

……余計遅くなってるorz
なんで？とことん愚直に書き下してやったつもりなのに？ってんでしばらく足掻く。

はっと気がついて、 STL vector をただの配列にしてやったら旧コードと同程度に速くなった。 Efficient C++ に書いてあったオブジェクトの生成のコストってやつだったんだね。ここまで明白な形で目の当たりにしたのは初めて。

vaio を修理に出しているあいだ、 commit できないと作業したくなくなるんで mac の方で darcs で記録。

方法は、 colinux 上の最新の svn working copy を mac へ。 .svn/ を削除して darcs に import 。こいつを親にして darcs get で working copy 的リポジトリを複数作って別個に機能追加。子同士では darcs pull で merge 。

これで済んでる間は破綻しないんだけどねぇ

ちなみに、会社の某所のクラスターでも hg で同様のことやったけど、やっぱり同期がメドいなぁ…。
working copy は tar 玉で持ってくからいいけど、作業中に共有しとかなきゃならない重要な変更が出てくると、差分で持ってって向うの master で commit して working copy に伝播とか…、きっとそのうち破綻する。

[read more]

手続きがもたついてるのを尻目に本体はさっさと帰ってきた。
HDD はえらい小さいのが入ってたんだな。でも未だに 40G。ファンは、ちょっと口で吹いてみたけど、ちょっと重い気がする・・・がよく判らん。あ、綿埃が飛んだww

そして、3年前に買ったっきり、バックアップはすれどもリストアはしたことがなかった livestate recovery で復旧。パーティション切り直すとこまで含めて、全部自動で完璧に復旧。いいソフトだ。もう売ってないけど。

[read more]

vaio が、さすがに使用環境が過酷だったのか冷却がいまいち怪しくなっていて AirEdge はどう見ても熱暴走してるし、ファンが spin up し損ねてごとごとと妙な音を出したりしたので、完全にくたばる前に修理に出すことに。さすがに Sony の品質管理の優秀さで、ちゃんと３年保証を数ヶ月突破してるんだな、これがまた。

で、カルテに記入して電話すれば回収に来てくれるはずなんだが、電話口で延々ごちゃごちゃと症状を云えだの引っ張ったあげく、異音がするというとああそれは HDD が・・・とか言い張る。ファン交換して欲しいだけなんだから回収してってそれだけやれっつーの・・・・・・。

で、修理箇所をチェックするためにその PC にログインしなければならない。パスワード教えろ云々。結局ダミーアカウントつくって、そのアカウント名／パスワードをカルテに書くということで妥協。だからハードの問題だっつーの

で、まぁ、俺の方が忙しくって会社にいなかったり、疲れてて会社行きたくなかったりはしたものの、会社まで回収に来させることには成功。

[read more]

先日の dSFMT の話の続き。
dSFMT をテキトーに C++ のクラスに書き換えてカプセル化して使っているんだが、 gcc では通るコードが PGI のコンパイラではエラーになるというもの。

どうでもいいけど PGI のコンパイラはエラーが判りにくすぎる。表示してる行番号が読まれるはずのない if def の中だったりとか（CPP 通した後の行数だったりするのか？）。

[read more]

やっと解決した。
コード中で使ってた class ごとに test code を書いていたがちっともはかばかしくなくて、結局、からの main() 関数にからの constructor に・・・ってコードを削りまくっていって探索した。

エラーになっていたのは、メルセンヌ・ツイスターの dSFMT の SSE を利用するコード。 m128 とかそういうデータ構造。
dSFMT は最初に疑ったんだが、よく見たら最適化とか外してチェックしていた。 SSE 使わなきゃ通るようだ。

ちなみに dSFMT は PGI コンパイラでも引っかかってやがる。パフォーマンス勝負させてみたかったのに・・・

llvm だが、ずっとハマっている。
手元の、某自前シミュレーションコードを食わせるとコンパイルはできるんだが実行時にエラーとなると言うもの。

問題は、そのエラーが

ERROR: Constant unimplemented for type: <2 x i64>

とか云うシロモノで、それじゃコードのどこが問題になってるのか判んねーよ！
いや、一応スタックトレースっぽい出力はあるんだが、それみてもやっぱり判んない。直しようがない。どうしたものか・・・。