nfsのキャッシュをローカルHDDに取る
うちはnfsを使ってhomeフォルダを各ユーザごとにマウントすることで，マシンが変わっても環境が変わらないようにしているんだけど，いろんな人が同時に触るとちょっと回線に負荷がかかって困る．
そこで，各マシンのローカルHDDにキャッシュを取ることにした．
使ったのはcachefilesdなるもの．取り敢えずfedora16に入れた．
CentOSとfedora16,18でyumで入れられることは確認済
1.ソフトのインストール
yum install -y cachefilesd
2.configの編集 (dirは/home/hpcl以下"以外"で．2-4はお好みで．)
vim /etc/cachefilesd.conf
1) dir キャッシュの作成先(dfコマンドでディスク使用量を確認するとよい)
2) brun 空き容量がこれ以上なら通常動作
3) bcull 空き容量がこれ以下ならキャッシュを間引く
4) bstop 空き容量がこれ以下ならキャッシュをやめる
3.サーバ接続設定にオプションを追加
vim /etc/fstab
例：192.168.1.1:/home nfs auto,fsc,soft 0 0
4.ソフトの起動
chkconfig cachefilesd on
service cachefilesd start
5.再起動
6.確認
1)キャッシュの作成先を辿って行くと@04みたいなファイルがある
2) cat /proc/fs/nfsfs/volumesのFSCがyesになっている
(1),(2)がOKなら問題なし！
ログアウト後もジョブを継続する
sshでジョブを実行中にうっかり抜けたり，ネットワークが不調になっても大丈夫なように，ログアウト後もジョブを継続するようにした．
nohupコマンドで何とか出来るらしい．
nohup sh ./abc.sh &
こうやるとログアウト後でも平気．
だけど標準出力が変な所($HOME/nohup.out)に吐かれるという仕様なので，
nohup sh ./abc.sh > a.log &
とかやっておけばOK．
いつか使ってみたい．タイル型ウインドウマネージャ
なかなか忙しくてネタが集まらない日々．
取り敢えず今日はメモだけ．
タイル型ウインドウマネージャっていうのはウインドウマネージャって名前がついてるけど，実際はほぼGUIすべてを取り仕切っている．っていうかGUI．
僕が入れたことあるのはXmonadだが，Fedoraのログイン画面にXmonadって出てきてgnome3じゃない画面が出てきて混乱する自体が発生して涙目．
Xmonad自体はyumでインストールできる．
Linuxはデスクトップにしか無いし，ノートPCはWindows+cygwinなので，なんか面白いの無いかなーとか思って探してたらWIndows用のタイル型ウインドウマネージャを発見．
https://github.com/Tzbob/python-windows-tiler
使い方は以下を参考．
http://d.hatena.ne.jp/uhiaha888/20121125/1353824257
Xmonadは混乱したけど，こっちを今度入れて少し慣れてみようかとか思っている所存
Linux テキストファイル 列結合
後輩に今日聞かれたので書いておく．
自分の環境でありがちな実験データとかで
hoge1.txt >>
name1 size1 time1
name2 size2 time2
hoge2.txt >>
name1 size1 time3
name2 size2 time4
みたいになってる結果のファイルがたくさんあったり，1000行あったりする．
join使えばいいじゃん！って思うかもしれないけど，実際のところ列は10個位あるからtimeしか欲しくないとか，execelに持って行く時面倒だ！とか文句があるので，
awk '{print $2}' hoge1.txt > tmp1
awk '{print $2}' hoge2.txt > tmp2
paste tmp1 tmp2 > result
こうすれば
result.txt >>
time1 time3
time2 time4
とかになる．
シェルスクリプトでプログラムの計測とかをするために
研究室を見てると，みんなシェルスクリプトを書いてるみたいだけど，シェルスクリプトのfor文には2種類ある事を知らない人が多いみたい．
僕はあんまり機会がなくて(2)は使わないんだけど，有効なので紹介する．
(1)よくあるfor文
for ( (n=0 ; n<100 ; n++ ) )
do
echo cat $n.txt
done
(2)カウンタに文字式を使う
for文の中は上と同じものだったとして，
do
echo $n
done
for文の条件式をこのように書くと
$ for n in 1 2 3
>> 1 2 3 (本当は開業されるけど省略)
$ for n in $(ls | grep *.txt)
>> hoge.txt fuga.txt hige.txt
$for n in $(cat hoge.txt)
>> セパレータで区切られたhoge.txt内の文字列を出力
$for n in $(awk '{print$1}' hoge,txt)
>> セパレータで区切られたhoge.txt内の第一フィールドの文字列を出力
こんな感じ．知らない人は使って．
OpenMPのスケジューリング方式"runtime"は速いのか！？
OpenMPにはstatic, dynamic, guided,auto,runtimeと5つのスケジューリング方式がある．細かいことは本記事の末尾のリンク先に任せるが，今回のテーマはruntime．
runtimeは実行時に実行ファイルが環境変数を読みに行ってstatic, dynamic, guidedの3つのうちどれにするかを切り替える方式．
runtimeを今まで使ってないなかったのは内部の挙動がわからないからで，
疑問1) #pragma omp句はプリプロセッサがpthreadに変換するはずなのに，実行時に実行ファイルが環境変数を読みに行って挙動を切り替えるというのは，どういう実行ファイルが生成されているんだ．という疑問．
疑問2) そして切り替えのせいで実行時間はどのくらい伸びるんだ．という疑問
今日は時間もないので，疑問(1)はさておき，取り敢えず使い方と(2)．まず使い方は
#pragma omp parallel for schedule(runtime)
とつけて,
OMP_SCHEDULE="static"
export OMP_SCHEDULE
とやる．
わかったところで疑問(2)をやる．
純粋なスケジューリング方式ごとの差は僕の選んだ問題依存だから問題によって異なる．
対象問題：
細かいことは研究に抵触するので避けるが，研究に使っている疎行列ベクトル積．1000回の平均時間
結果(桁が小さいので1000倍した時間，単位は秒)
static 0.72
runtime(static) 0.74
dynamic 2.60
runtime(dynamic) 2.62
guided 0.72
runtime(guided) 0.75
結果，やっぱりちょっとだけ遅かった．最大でguidedの+4%だから差は小さいけど，多少は違うみたい．
実行ファイルのサイズもちょっと違っていてstaticの約2.5MBと比べて，
dynamic +256byte
guided -72KB
runtime +5KB
と，まぁどうでもいい値だけど5KBくらい多かった．っていうかguidedってファイルサイズ小さいんだね．
ということで，アプリケーションの人とかはruntime使ってもいいと思うけど，1%でも早くしたい細かいチューニング屋さんはruntimeは駄目かもしれない．
