Workshop/ReadGHC/2

調整/当日スケジュール

Haskellコンパイラのソースをゴクゴク飲む会 第2回 (MLとerlangも可！) - PARTAKE

議事録

発表資料

次回

3

事前準備のようなざれごとのような

地図を更新し続けた方がいいかも

GHCの全体像がわかりにくいので、勉強会を開く毎に地図と各地のキーとなる概念を更新して置いといた方がいいかも。 そうすれば、途中参加者も地図を見て参加しやすくなる。 (by @khibino )

ネタどうする？

@master_q としては、以下に興味があります。

  • gdb + dwarf
  • RTSから外部ライブラリ依存を削減する
  • IOスケジューラ
  • InCallについて
  • oprofileでサンクの時間コストを測定
[15時49分31秒] Kiwamu Okabe: Java アプリケーションのプロファイル作成 ？？？？？？？
[15時49分49秒] xxx: うん
[15時49分54秒] Kiwamu Okabe: なんと。。。
[15時50分01秒] xxx: あれ、oprofileでもできたはず?
[15時50分15秒] xxx: http://oprofile.sourceforge.net/doc/getting-jit-reports.html
[15時50分29秒] Kiwamu Okabe: MJD!
[15時50分47秒] Kiwamu Okabe: これは、GHC RTSも対応しなければならない流れ。。。
[15時50分52秒] xxx: ぉ
[15時51分10秒] Kiwamu Okabe: スタックトレースが取れないから、微妙にうまくいかない気がするけど。。。
[15時51分41秒] xxx: まぁスタックトレースが取れないというよりかは
[15時51分50秒] xxx: 遅延評価言語でどういうプロファイル取りたいか、って問題ですよね…
[15時52分26秒] Kiwamu Okabe: とりあえず、名前のついているサンクを全部コストセンターにしてしまう、とか
[15時53分00秒] Kiwamu Okabe: ところがどっこい、コストセンターの測定にはログによる測定しかできんという。。。 #orz
[15時53分15秒] xxx: ログによる、とは
[15時54分23秒] Kiwamu Okabe: RTS側にどのサンクにさわったかどうかをログっぽい何かに出力していて、その時間を後で集計して各サンクの時間コストを見てるんだとぼくは理解しています。
[15時55分23秒] Kiwamu Okabe: oprofileは確か割り込み毎にスタックトレースと、あとなんだっけ、を取って関数にかかった時間を割り出しているって聞いたことがあって、割り込みベースだとなんもわかんないなーと思いました。
[15時55分24秒] Kiwamu Okabe: あ。
[15時55分48秒] Kiwamu Okabe: 割り込み毎にどのサンクの状態変化をログしておけばいいのかな。。。
[15時56分06秒] Kiwamu Okabe: 未評価/評価中/評価済み の3ステート
[15時56分27秒] Kiwamu Okabe: でもステート差分を取るほうほうがない。。。
[15時56分34秒] xxx: 割り込みの瞬間にどのサンクを評価中かっていう情報は原理的には取れるのでは
[15時56分41秒] Kiwamu Okabe: はい。取れます。
[15時56分57秒] xxx: その評価中のthunkにchargeすればいいのでは?
[15時57分09秒] Kiwamu Okabe: なんかデキそうな気がしてきました。。。

@kazu_yamamoto さんがIOマネージャを解説できるみたい。

目処が立ったら

[PARTAKE] にイベント立てて、 haskell-jp - Google グループ にメールすること。