【PAIP】9 Efficiency Issues (その4)

• 9.5 Instrumentation: Deciding What to Optimize
  
• LispはRADに適した言語だよ。
  
• だから動くものは手早くできるよ。
  
• その後、効率を改善する、というのはいいアイデアだよ。
  
• そのとき、どこを改善するかを見極めるのがポイントだよ。
  
• それぞれの関数が何回呼ばれているのかは最小限必要だよ。それを関数のプロファイリングと呼ぶよ。
  
• たいていのLispはプロファイリング機構はビルトインでもってるよ。まずはそれを使いなさいな。
  
• ここでやってみせるのは、あんたのLispでそれが欠落している場合のためと、関数をいじくるやり方を見せるのが目的よ。
  
  
• なるほど。
  
  
• ちなみに、aclにはあるのかな? と調べてみる。あった。
  Runtime analyzer
  
  
• こういう感じでシンボルを使えちゃうのが、CLっぽいなぁ。
  

  
  (defun profile1 (fn-name)
    "Make the function count how often it is called"
    ;; First save away the old, unprofiled function
    ;; Then make the name be a new function that increments
    ;; a counter and then calls the original function
    (let ((fn (symbol-function fn-name)))
      (setf (get fn-name 'unprofiled-fn) fn)
      (setf (get fn-name 'profile-count) 0)
      (setf (symbol-function fn-name)
        (profiled-fn fn-name fn))
      fn-name))
  

  
  
  
• 9.6 A Case Study in Efficiency: The SIMPLIFY Program
  
• 9.5で作ったProfilerをつかいながら、9.4までの4つの観点でSIMPLIFYをチューニングしていく。
  
• テストデータを用意して、その正解をチューニング前のアプリを使って計算して、それらの組をテストケースとしてしまう。テストの半自動生成。面白い。仕様通りかはわからないが、チューニングの過程でズレがないことはわかる。
  
• 最終的に130倍の性能がでるのは圧巻。
  

ああ，ついに300ページ越え！！ 314P！
これでCLのよい書き振りってこんなんよ、というのはわかっていると思っていいはずだ！

今後の山予想。。。

• １１，１２　：Prolog山
  
• １３　　　　：OO山
  
• １４　　　　：知識表現&推論山
  
• １５〜２１　：本山 (エキスパートシステム〜自然言語処理)
  
• ２２〜２５　：Lisp仕上げ山 (Schemeのインタプリタとコンパイラを作成?)
  

高い。。。途方もなく高く感じる。。。こつこつ。