Seminar:CommonLisp:2004
Franz 社セミナー
- 「2日間みっちり!Lispチュートリアル&Lispセミナー&Lisp事例紹介」(2004/06/10 - 2004/06/11 ) http://jp.franz.com/base/seminar-2004-06-10.html
「2日間みっちり!Lispチュートリアル&Lispセミナー&Lisp事例紹介」
- 会期:2004/06/10 - 2004/06/11
- 会場:新宿(数理システム社セミナールーム)
- 無料(受付は終了)
- 豪華講演者紹介は Franz 社サイト参照
Lisp セミナー(一日目)
Franz 社 CEO
- Lisp とは何だろうか?
- 交通手段に例えると
- Lisp は Jets, C, C++ がプロペラ機、Perl, Python がハンググライダー
- Shiro さんより Jets だと高いよね、という突っ込み。結局この突っ込みには後で答えると言っていたけど答えが無かったような…(ヒアリング力不足のせい?)
- 言語に例えると
和田先生
- 和田先生の Lisp との出会いは 1960 年頃にまで遡る。
- hardest first 難しいところを最初に。なぜなら S 式で適当な入力、出力を作って関数を書けばいいから。
- 構造化エディタは流行らなかった。
- 今見て「スラッシュドット ジャパンのスケッチ感覚でWebサイトをプロトタイピングより、タブレット PC 用のビジュアル Lisp エディタ GTEdit。面白そう。」と感想を抱くこともあるようだけど。
- その後の飲み会で構造化エディタと emacs の括弧修飾のように syntax を理解していこうという発想の両方をやろうという富豪的な発想があるから、VM の方でもやってみたらどう? -> でも OS とかの場合すごく昔に既にやられていてその文献を検索するのができていないだけの可能性が…… -> そのことを考えると、文献あさってエディタで挑んでいる彼らは偉大だよね。
Lisp チュートリアル(一日目)
- CLOS and Metaobject Protocol
- アスペクト指向が不要だという理由。CLOS のメソッド修飾を使えばほとんど同じことができる。
- AllegroServe
- 以前のセミナーとほぼ同じで、Lisp で書かれた Web Server のお話。
- IDE
- ACL 7.0 では Windows 同様に使えるようになるらしい。
- patch は事実上の plugin のようなもの -> Lisp だから当たり前か。でも、コンパクトな自分自身をコンパイルして提供するという発想には注目するものがある。
- Emacs Lisp Interface
- S-式操作をちゃんと活用しようというこれも以前のセミナーと同じ。
- Lisp 開発環境
飲み会
- 昼食と合わせて Gauche:Windows/MinGW および Gauche 本体周りで色々と話が進む。
- Gauche の Windows ネイティブ化および当然要求されるであろう GUI 環境の充実は、前にもあったように教育目的で使いたいという話も出ているので、そこから助成金が出れば開発を進められる。
- cygwin で gtk ライブラリがまだサポートされていないのは、配布しているのかどうかが分からないため -> 調査したところ酒井さんの gtk2 on cygwin が良く使われているようです。
- Gtk2 on Cygwin で日本語入力
- CyGNOME - Cygwin + GNOME
- Windows 日本語版の Gimp は MinGW でビルドされているようです。要求すれば patch も貰えるとのこと。
- 未踏の 3D の Wiki もどこかから資金がでないかな、という話
- Wiki の普遍文法化と BNF
- 日本の Haskell 界の草分け的な存在になる方法
- ドキュメントを書く、今回紹介されていたのや Symbolics を目指している各種 lisp mode に匹敵するくらいの emacs および Haskell:xyzzy のモードを書く、豊福さんが dRuby の Rinda を移植してくれるなら shelarcy さんがその後のメンテナンスはやる
- wxHaskell の話は誰も知らないので静まってしまうらしい。
- 今考えているものは形になったら未踏に出せばいいんじゃないかという話。
- 笹川さんのところで言われている話題を google で探したときに結局笹川さんのページが一番最初に引っかかってしまうのは、ML Editor の評価高くて各所からリンクされているのと、各所からリンクされるべき良い数学の文書がないからではないか?
- SICP の古典物理学について扱った続編の話も振り方を間違えるとリアクションに困る
- フリーソフトウェアはソフトウェア業界を潰すという話は、秘密で Web サーバーを作っていたのを先に Allegro で先にフリーで公開されてしまったことへのルサンチマンがこもっている
- 内緒にせずに作っているって宣言すれば、出来上がるのを待っていただろうに
Lisp 事例紹介(二日目)
- shiro さんの正規表現ライブラリの実装の最適化に関する話
- 前日の飲み会にて、自作のプレゼンテーションツールはうまく動かなかったため、次の機会とのこと
- Regex を動的にも、静的にコンパイルして使えるようにもする
- 6 週間で実装したとか、120 k byte の書き換えとかいう言葉が普通に飛び出す
- フロントエンドにあたるアルゴリズム最適化で 1000 倍スピードアップ、バックエンドにあたるアセンブラコードの最適化で 3 倍スピードアップ
- Regex -> VM マクロ -> 手続き型のチューニングされたコード
- マクロ越しにかりかりチューニングする。マクロがないとやってられない。
- ACL の disassemble 機能
- gensym を付けておくと、disassemble で性能が費やされている場所が分かる
- 自立したネットワーク間の経路障害を自動診断する「ENCORE」
- ルーターにつないですぐ動くセットにしたいけど、そうするとセキュリティに不安が
- ネットワークの自動制御の予定はあるけど、グリッドはまだらしい
- 湯浅先生の Lego の XSLisp
- 絶賛されて、LL3 での発表になったらしい
- 省メモリの美
- Lisp によるヒューマノイドロボットのプログラミング
- EusLisp が本当に成熟した処理系という印象
- 東大では 4 年生の時に配られるノートパソコンに強制インストールされるらしい
- Lisp 上で動きをシミュレートして、それから Lisp でロボットを実際に動かす
- Class を使ってロボットの間接の動き等を抽象化することで、それまでの成果を異なるロボットでも使うことができる。
- 昨日あったように Lisp 処理系では処理中にデバッグしたり、新しくコールすることが当たり前とはいえ、thread の動作確認中のまさにそのプロンプトでコマンド入力しようとする様は LL3 の Reactive Programming のデモを思わせるものがあったけど、聞いてみるとそのあたりに詳しくはないとのこと
- 色々と話したいことがありすぎて時間不足かな
- EusLisp が本当に成熟した処理系という印象
- なぜ Lisp プログラマーは正規表現を必要としないのか
- reader macro で代用できる
- Perl で困ったら(分からなかったら)、Lisp を使え
- ACL 7.0 からは正規表現が入るので、場合によって使い分ければいい
- ILC での発表みたいだとの評
- reader macro で代用できる
お茶会
- 最初の CEO の「Lisp プログラマーはアスペルガー症候群だ」というところで終わってしまって、最後の落ちである救いの部分までいかなかったのがちょっと
- レポートほんとありがとうございます。これはある種の真実をついているようで笑えますね。
- 静的処理系と動的処理系を融合させたくなるわけ
- Lisp の動きながらデバッグというのを見てると、うらやましい。
- 今日のセミナーでも出ていたけど、データベースの使用で Cache が流行っている。
- これからは静的な Store よりも動的な Cache なのか?
- Haskell:AllAboutMonads の =<< について
- destructuring-bind と catamorphism、anamorphism
- 豊福さんの、おぎのさんのところで働きたい、という発言。
- ベンチャーなので数年間はただ働き同然を覚悟してもらわないと
参加者のコメント
- 初日終了しました。熱いものを感じましたが、ちょっと消化不良のものが多かったかも。愛されている言語なのは伝わってきました。MOPの説明が理解できなかったのが悔しいです。
「ACL7.0の新しい正規表現」補足
Shiro: 時間の都合で削った話を書いておきます。 最適化の局面でマクロを利用することについて。
正規表現をVMで実行するにあたって、いくつの「レジスタ」---部分マッチとか 繰り返し回数を保存するもの---を必要とするかは、正規表現のコンパイル時に 定まります。正規表現をLispコードに変換する場合は、必要なだけのレジスタを マシンスタックに取ることが出来ます。しかしVMの場合、VM自体のコンパイル時 には必要なレジスタ数がわかりません。(Lispでalloca()が使えれば良かったんですが)
当初は、実行時にレジスタ用にベクタをアロケートしていました。 最終的には、バックトラック用のVMスタック(fixnumのsimple-vector)の最初の方を レジスタとして使用しています。
しかし、VMスタックのアロケート自身にも時間がかかります。あらかじめ 決まった個数のレジスタをローカル変数としてVM内に取って置く、という方法も 考えられます。例えば16個はVMに取ったレジスタを使い、レジスタ数がそれを 越えた場合はVMスタックを使うと。そうすると、バックトラックの無い正規表現 では、VMスタックベクタのアロケートが省ける分速くなるかもしれません。
Lispで配列そのものをマシンスタックに取ることが出来ないので、 固定したローカル変数を宣言しておくことになります。スピルしていない レジスタへのアクセスは当該ローカル変数へのアクセスに、そうでない場合は VMスタックベクタへのインデックスアクセスになります。 実行時の条件分岐はできるだけ避けたいので、レジスタをアクセスするその時に なって条件判断や演算をしたくはありません。
そこで、ひとつのVM記述から、実行時の使用レジスタ個数がそれぞれ 0個、2個、4個、8個、16個、それ以上(スピル有り)、等の場合に最適化 されたクロージャを生成するようにマクロを変更し、 正規表現コンパイル時に最適なクロージャを返すようにしてベンチマークを 取りました。クロージャのバリエーションも色々変えたりして。 で、結局、現在の方法が一番速いことがわかった次第です。
この試験は、VMループのコード自体に手を加えずに、全て上位のマクロの変更で 行いました。(VMループのコードをトラバースしてレジスタアクセス コードを書き換えるようなマクロを使いました)。 マクロがなかったら、多分テストそのものをあきらめていたんじゃないかと思います。
ちょっといじってベンチマークを取って、という最適化は非常にストレスフルな 作業です。作業効率が悪いとアイディアを試すのが億劫になりますし、限られた 時間内に試せる技法の空間も狭くなります。 実行時間より実装時間を重視する理由として、 「マシン時間よりプログラマ時間の方が高価である」ことが良く言われますが、 本当に実行時間を重視したいなら、実装時間がばかにならないオーダーで 効いて来るのだと思います。