K.Sasada's Home Page

あー，来年度どうなるんだろ．

うーん，物理的に頭が痛い．

---

諦めて寝たら直った．

色々とまずい．

ソースコード添削システムってあるのかしら．

MS Office の Word だと，修正を綺麗に表示してくれるモードがあるけれども，あんな感じに赤を入れる．

patch か？

竹内先生の最終ゼミだった．長かったなあ．それだけ，OB の人が沢山集まったってことで，やはり慕われている大先生，ということ．

通夜明け．みんな元気だなぁ．

日はまた昇る．

---

今日は修了式です．修了していく皆様，おめでとうございます．

また風邪を引いたっぽい．

---

新しいことをする気力が無くなったのは，年取ったからなのか．ただ単に怠慢だからか．ご迷惑をおかけしてしまいました．申し訳ありません．

---

俺には何が出来るのかなぁ．

---

nahi さんより，年寄り一般とするのは失礼だと言われ，全くその通りなので訂正します．年取ったら新しいことをする気力が無くなる，というのは全くのでたらめで，そういうことを意図するつもりはありませんでした．

---

訃報が届いた．自分がこんなに動揺するとは思わなかった．

---

弱音なんて吐いてる場合じゃないよなあ．

---

世は全てことも無し．

---

礼服買ってきた．AOKIが目の前にあるのは便利だ．活用したくない感じの便利さだけど．

つい，プロジェクターを買ってしまった．

家庭用の静音モデルと言うから期待していたんだけれど，期待したほど静かではなかった．データプロジェクタなんかよりは，もちろん随分静かだけど．

---

http://d.hatena.ne.jp/mindcat/20100320/1269105636

さらっと読んでも全然わからないので，今度頑張って読もう．

GC 本を頂きました．よくまとまってると思います．勉強します．

---

だけど，細かいところで，あれ？　というところがあるので，教科書に使うのには躊躇するかも．参考書としては素晴らしい．もう少し，メモリ管理とか実装に詳しい研究者にも読んでもらえば良かったのにと思わなくもないけれど．いや，そもそもそう言う人が書けないのがいけないのか，とか．少なくとも書きやすい世の中にはなってないよなぁ，とか．

---

YLUG 行きたいなあ．

https://rikunabi-next.yahoo.co.jp/tech/docs/ct_s04100.jsp?p=google_q2&__s=1

Google に入れそうにないなー．

samba がアクセスパターンによって応答が無くなることがあるようだ．これは，一体なんなんだろう．lenny のデフォルトなんだけど．

LAN 環境，100Mbps の switching hub を使っており，大きなファイルコピーは 10MB/s とか出ており，問題のものは 1MB/s とかなので，帯域がないわけではない．

ネットワークチューニングの経験が無いので，何をどういじっていいのかわからん．どのレイヤーかすらわからん．困った．

---

samba 経由じゃなくて，udp 経由でばかすか送るのは問題なさげなので，それでを使うか．いや，それだと一部しか解決しない．

感触としては，あるファイルに対してランダムアクセスするとものすごく遅くなる感じ．

---

ちょっと調べてみると，ランダムアクセスが異様に遅い．

samba 経由．

      user     system      total        real
seq  0.000000   0.015000   0.015000 (  0.388000)
rand  0.015000   0.359000   0.374000 ( 25.807000)

ローカル．

      user     system      total        real
seq  0.010000   0.000000   0.010000 (  0.011367)
rand  0.010000   0.030000   0.040000 (  1.000550)

ちょっと，この遅さは異常だよなぁ．さて，samba なのか，smb なのか．

---

samba じゃなかった！　windows2windows でやってみたら，

      user     system      total        real
seq  0.000000   0.000000   0.000000 (  0.407000)
rand  0.015000   0.343000   0.358000 ( 36.905000)

もっと遅かった！

さて，じゃぁ Windows 側の調整になるんだろうか．さて，何をどういじればいいのか．

---

やはり，1つのファイルに対してランダムアクセスが起こった場合，みたいだなぁ．複数ファイルに対するアクセスなら平気．

---

遅延時間は関係無いようだ．Windows - Windows 間だと問題無い．やっぱり samba なのか？　Vista to Vista でやったので，SMB 2 だとどうのってこともあるのかなぁ．

---

Linux の話なのか，samba の話なのか．どっちなのかなぁ．わからん．

---

違う違う，同時に2つ以上が1つのファイルを見ると，なんか刺さるんだ．さて，これはどこに設定が？

---

fake oplocks を yes にしたらマシになった？　うーん．

どうにも最近胃が痛いというか色々アレでナニなので，もうちょっと中途半端に生きたい．いや，完璧に生きることができれば，それにこしたことはないんだろうけど，無理だからアレでナニなので，なら，えっと．

---

学生さんの PRO の発表だった．内容は置いとくとして，すごくよく練習された発表だった．

質疑応答，最後にもう少し攻めの姿勢があると良かったかな．

色々と駄目だ．

アニメとかで，親友が死んで，それを乗り越えて云々って描写があって，でも，その後すぐ笑ってるのがあって．すぐ笑えるものなんだろうか．幸い，そういう経験は無いんだけど．

---

久々に秋葉原に勤めていてよかった，という買い物が出来た．いやはや．まぁ，通販でもいいといえばいいんだが．

1ヶ月くらい家で腹筋をちょっとするようにしてたら，腹筋をするのが大分楽になってきた．1ヶ月程度で，それなりに変わるものなんだねぇ．

---

http://www.atdot.net/fp_store/f.fcd4zk/file.g.png

5000 までやってみた．綺麗な曲線．さて，これは...．

---

http://www.atdot.net/fp_store/f.3oe4zk/file.g.png

意外な結果．dlopen の方が速い．

backtrace を高速化するための仕組みを入れようかと．

Ruby の例外オブジェクトを生成するとき，必ずバックトレースを生成する．例外でプログラムが終わったときに，ファイル名，行番号，メソッド名（とか）の文字列のこと．しかし，例外をフロー制御に使っているような場合は必ずしもバックトレースを必要としない．というわけで，読みやすいバックトレースを作るのを，本当に必要な時まで遅延しましょう，という変更．

使用前．

ruby 1.9.2dev (2010-03-10 trunk 26862) [x86_64-linux]
      user     system      total        real
depth(0)  1.740000   0.020000   1.760000 (  1.756486)
depth(1)  1.840000   0.010000   1.850000 (  1.857154)
depth(2)  1.920000   0.030000   1.950000 (  1.942580)
depth(3)  1.980000   0.030000   2.010000 (  2.018608)
depth(4)  2.120000   0.010000   2.130000 (  2.125965)
depth(5)  2.250000   0.020000   2.270000 (  2.270989)
depth(6)  2.310000   0.050000   2.360000 (  2.354864)
depth(7)  2.430000   0.010000   2.440000 (  2.447995)
depth(8)  2.530000   0.010000   2.540000 (  2.527528)
depth(9)  2.580000   0.040000   2.620000 (  2.623037)

使用後．

ruby 1.9.2dev (2010-03-09 trunk 26858) [x86_64-linux]
      user     system      total        real
depth(0)  0.560000   0.010000   0.570000 (  0.575656)
depth(1)  0.570000   0.030000   0.600000 (  0.594750)
depth(2)  0.590000   0.020000   0.610000 (  0.612217)
depth(3)  0.610000   0.020000   0.630000 (  0.628146)
depth(4)  0.630000   0.010000   0.640000 (  0.646106)
depth(5)  0.680000   0.030000   0.710000 (  0.700762)
depth(6)  0.690000   0.020000   0.710000 (  0.718797)
depth(7)  0.710000   0.030000   0.740000 (  0.731572)
depth(8)  0.730000   0.020000   0.750000 (  0.752139)
depth(9)  0.720000   0.040000   0.760000 (  0.761257)

Linux 2.6.26-2-amd64 #1 SMP Thu Nov 5 02:23:12 UTC 2009 x86_64 GNU/Linux

depth はメソッド呼び出しの深さ．バックトレースだから，深ければ深いほど時間がかかる．

テストプログラム．

def depth n, &b
  if n == 0
    b.call
  else
    depth n-1, &b
  end
end

def backtrace_bench n, max
  depth(n){
    max.times{
      begin
        raise
      rescue => e
        # p e.backtrace
      end
    }
  }
end

max = 100_000

require 'benchmark'

Benchmark.bm{|x|
  10.times{|depth|
    x.report("depth(#{depth})"){
      backtrace_bench depth, max
    }
  }
}

1点非互換があって，例外生成時に Exception#set_backtrace が呼ばれなくなってしまう．これは，いいんだろうか？

---

プログラムする暇が無い，という前に，やれって感じだなぁ，と思ってやってみた．まだまだなんとかなる．ということにしておきたい．

---

もうちょっとだけ速くした．

使用前．

      user     system      total        real
depth(0)  1.780000   0.000000   1.780000 (  1.784426)
depth(1)  1.870000   0.020000   1.890000 (  1.884557)
depth(2)  1.930000   0.040000   1.970000 (  1.969664)
depth(3)  2.040000   0.020000   2.060000 (  2.055784)
depth(4)  2.120000   0.030000   2.150000 (  2.154413)
depth(5)  2.280000   0.030000   2.310000 (  2.297813)
depth(6)  2.360000   0.000000   2.360000 (  2.373175)
depth(7)  2.440000   0.030000   2.470000 (  2.467323)
depth(8)  2.500000   0.050000   2.550000 (  2.551120)
depth(9)  2.650000   0.000000   2.650000 (  2.647281)
jump(0)  1.940000   0.030000   1.970000 (  1.968903)
jump(1)  2.090000   0.010000   2.100000 (  2.093892)
jump(2)  2.180000   0.030000   2.210000 (  2.210758)
jump(3)  2.280000   0.030000   2.310000 (  2.301449)
jump(4)  2.400000   0.010000   2.410000 (  2.418277)
jump(5)  2.560000   0.020000   2.580000 (  2.582737)
jump(6)  2.680000   0.020000   2.700000 (  2.690582)
jump(7)  2.750000   0.030000   2.780000 (  2.786941)
jump(8)  2.900000   0.010000   2.910000 (  2.902881)
jump(9)  2.970000   0.030000   3.000000 (  3.002575)

使用後．

      user     system      total        real
depth(0)  0.470000   0.020000   0.490000 (  0.488838)
depth(1)  0.490000   0.010000   0.500000 (  0.506408)
depth(2)  0.510000   0.020000   0.530000 (  0.521655)
depth(3)  0.510000   0.020000   0.530000 (  0.537505)
depth(4)  0.540000   0.010000   0.550000 (  0.552983)
depth(5)  0.590000   0.000000   0.590000 (  0.601377)
depth(6)  0.610000   0.020000   0.630000 (  0.620294)
depth(7)  0.610000   0.020000   0.630000 (  0.632522)
depth(8)  0.640000   0.010000   0.650000 (  0.650134)
depth(9)  0.640000   0.020000   0.660000 (  0.658325)
jump(0)  0.610000   0.010000   0.620000 (  0.617857)
jump(1)  0.620000   0.030000   0.650000 (  0.651153)
jump(2)  0.670000   0.010000   0.680000 (  0.684131)
jump(3)  0.690000   0.030000   0.720000 (  0.715261)
jump(4)  0.730000   0.010000   0.740000 (  0.743219)
jump(5)  0.790000   0.040000   0.830000 (  0.827856)
jump(6)  0.830000   0.020000   0.850000 (  0.855170)
jump(7)  0.870000   0.020000   0.890000 (  0.887924)
jump(8)  0.900000   0.030000   0.930000 (  0.920674)
jump(9)  0.930000   0.010000   0.940000 (  0.950215)

jump ってのは，実際に上の方まで飛ぶような場合．

def depth n, &b
  if n == 0
    b.call
  else
    depth n-1, &b
  end
end

def backtrace_bench n, max
  depth(n){
    max.times{
      begin
        raise
      rescue => e
        # p e.backtrace
      end
    }
  }
end

def jump_bench n, max
  max.times{
    begin
      depth(n){
        raise
      }
    rescue
    end
  }
end

max = 100_000

require 'benchmark'

Benchmark.bm{|x|
  10.times{|depth|
    x.report("depth(#{depth})"){
      backtrace_bench depth, max
    }
  }
  10.times{|depth|
    x.report("jump(#{depth})"){
      jump_bench depth, max
    }
  }
}

---

調べていたら，なかなか面白いグラフが出来た．

http://www.atdot.net/fp_store/f.9te2zk/file.g.png

何か，面白い話になるかなあ．

http://www.atdot.net/fp_store/f.0go2zk/file.g.png

これも面白いと思う．なんでこんなふうになるんだろうか？

研究室でコーディング大会．トップはPerlを使ったK君．悔しい．

お題は，「竹内関数を n 段インライン化したプログラムを生成するプログラム」．

意外と難しかった，というか，文字列でゴニョゴニョしてる時点でやっぱ駄目だよなぁ．

VGA ケーブルというのは，意外と駄目になるらしい．先日も2本ほど交換した．というわけで，補充したいと思ったけれども，校費は今の時期使えないんだよねぇ．どうしたものか．

---

電子メール書いたし，郵政省メールも書いた．あとは...．

竹内先生の最終講義について，まとめておこうと思う．

素敵な最終講義でした．

---

懇親会．司会をさせて頂くことに．

• 開会（東大・竹内先生）
• 乾杯（工学院大学・小柳先生）
• とりあえず飯　本当はすぐに祝辞に入りたかったんだけど，飯を前につらかろう，と思って，とりあえずよそってもらおう，と思ったら，マジで歓談モードになってしまった．
• 祝辞
• 東大・武市先生
• 早大・後藤先生
• 東大・石塚先生
• COINS協会（元電通大）・渡辺先生
• 歓談
• 質疑応答（あれ，プレゼントとどっちが先だったっけ）
• 4月からどこにいくんですか？
• 私が竹内先生レベルになるためには何年かかるでしょうか？
• 人生云々（聞き取れず）
• プレゼント　やり方を失敗した．時間とりすぎ．
• 学生発表
• 川島君（相変わらず空気を読まない）
• 荒川君（相変わらずうまくまとめる）
• 閉会（東大・竹内先生，東大・石川先生）

なんというか，大変盛り上がったというか．

---

運営の話は略．

---

色々反省点があるのだけれど，質疑応答で出しゃばりすぎてしまったのも大変申し訳なかったです．でも，「あと数ヶ月」というお返事は，実は涙が出るほど嬉しかった．いや，数ヶ月でなんとかしろよ，ということだと思うんだけど．

• 10:00 出勤
• 14:00 出勤 (2)，もろもろ
• 15:00 発表練習
• 17:00 会議
• 22:30 会議終わり

なんというか．人間はまだまだがんばれる．

---

今日は，甘いものを補給したから平気だったのかな．

花粉症がしんどい．でも，帰途につくと平気．さて，何が原因か．