Orz日記 by Akio Morita

_ [SAD]SuperKEKB LER Tracking Profile

Google CPU Profilerによる測定結果

Total: 68153 samples
  22354  32.8%  32.8%    22354  32.8% tdrift_
   4828   7.1%  39.9%     4828   7.1% tquad_
   4801   7.0%  46.9%     4801   7.0% tsteer_
   4315   6.3%  53.3%     4315   6.3% ttfrin_
   4228   6.2%  59.5%     4228   6.2% tsolqu_
   4011   5.9%  65.3%     4011   5.9% tmulti_
   2267   3.3%  68.7%     2267   3.3% tbend_
   1745   2.6%  71.2%     1749   2.6% tturn1_
   1353   2.0%  73.2%     1353   2.0% fintrb_
    831   1.2%  74.4%      831   1.2% tmulbs_
    766   1.1%  75.6%      766   1.1% tthin_
    729   1.1%  76.6%      729   1.1% 0x000000020112dee6
    679   1.0%  77.6%      679   1.0% xsin_
    635   0.9%  78.6%      635   0.9% touckf_
    595   0.9%  79.4%      595   0.9% spdrift_
    500   0.7%  80.2%      500   0.7% tsfrin_
    395   0.6%  80.7%      395   0.6% tmultr5_
    303   0.4%  81.2%      303   0.4% spkick_
    302   0.4%  81.6%      302   0.4% tbende_
    287   0.4%  82.1%      287   0.4% bint_
    256   0.4%  82.4%      256   0.4% tintrb_
    238   0.3%  82.8%      238   0.3% 0x000000020112c1fc
    197   0.3%  83.1%      197   0.3% tsteee_
    168   0.2%  83.3%      168   0.2% tcav_
    153   0.2%  83.5%     1307   1.9% _init
    140   0.2%  83.7%      140   0.2% ttfrins_

tdrift(ドリフトスペース)がCPU時間の1/3を占めている

_ [SAD]kblogrdの読み出し速度

afsad1上で 2010/5/31一日分をSAD形式で読み出してみた。(ストア先は、NFSな home directory)

SAD形式(SAD EPOCHな時刻タグ＋レコード名＋データ列)だと格納効率はかなり 低く、5月31日分だけで22GiBの領域を必要とする

_ [FreeBSD][LLVM]FreeBSD 9-CURRENTへ LLVM導入開始

以前からGPL3になった GCCの代わりに GCC 4.2.1を LLVMに置き換える話は あったが、ついに 始まった らしい

デバッカLLDBの開発とか LLVM回りは元気がいいですねぇ

_ [雑記]オカエリナサλ

「はやぶさ」が 7年に渡るおつかいから戻ってきてくれた。

長旅お疲れ様でした＆オカエリナサλ

_ [SAD]Slot演算子に対する構文解析時評価はやはり邪悪だ

SADでは、構文解析時に引数が確定している関数言語的な意味で 純粋な組み込み関数に関しては、構文解析時に評価してしまうという という仕様である。たとえば、

In[1]:= Hold[Plus[1, 1]]
Out[1]:= Hold[2]

のように評価される。

このルールの元では、Slot演算子に対しても中身は確定していないが 1個の Atomであることは確定しているものとして扱うので、 組み込み関数Lengthの引数となるリストの要素として現れたときに 実引数と結合可能かどうかを問わずに評価されてしまう。

しかし、Slot演算子では、 純粋な関数を字句的に展開した式と展開前の式の評価値が異なる

 f = {#1, #2, #3, #4}&;
 g = Length[#]&;

 fg0 = g[f[##]]&;
 fg1 = Length[{#1, #2, #3, #4}]&;

 Print["fg0 -> ", fg0[1,2]];
???General::slot:  Undefined Slot #3 in ({#,#2,#3,#4}&)[1,2]
???General::abort:  Aborted:
Print["fg0 -> ", fg0[1,2]]
                         ^
 ???-FFS-Error-?Undefined command or element: PRINT["fg0
 Print["fg1 -> ", fg1[1,2]];
fg1 -> 4

のような例題が存在できる。 この例では、実行時に純関数(Function)を実引数と結合する際に 仮引数と数が釣り合わない例外が発生しなくなっている。

上記の例題では、例外が発生しているので、評価結果の唯一性が保証 されなくともよいという考え方があるが、次のUnevaluatedを用いた例題では Nullを頭部とする未評価のS式を送り込むという正常系の動作である。

 f = {#1}&;
 g = Length[#]&;

 fg0 = g[f[##]]&;
 fg1 = Length[{#1}]&;

 Print["fg0 -> ", fg0[Unevaluated$[Unevaluated$[Null[a, b, c]]]]];
fg0 -> 3
 Print["fg1 -> ", fg1[Unevaluated$[Unevaluated$[Null[a, b, c]]]]];
fg1 -> 1

以上の考察から、Slot演算子が1個の確定したAtomであるとして評価を最適化 するのは結構邪悪な実装だと思われる。

_ [Fortran]SELECT構文

算術IF文は廃止予定に入っているのは知っていたが、代替となる テーブルジャンプ構文を知らなかったのだが、所謂 switch case構文が Fortran90から入っているらしい。

select case(v)
  case(pattern)
    statements
  case(pattern)
    statements
  case default
    statements
end select
pattern <- pattern_atom , pattern / pattern_atom
pattern_atom <- literal:literal / literal: / :literal / literal

Cのswitch構文と比べると各caseをfall throughしない辺りが大きな違いで、 その代わりcase文に複数の適合が記述出来るようになっている

_ [KEKB]運転終了

1999年に始まったKEKBの運転がついに終了。

トンネル内では、アップグレードに向けた解体作業が始まり、 トンネルの外では、設計＆開発が続きます。

_ [雑記]GCC LTO

4.5.1 or 4.6.0で ELF環境以外での LTOサポートが始まるようですが、 Darwinに関しては x86_64のみです。つまり、32bitモードは 未サポートってことでよいのかな？