パスワードを忘れた? アカウント作成
100763 story
インターネット

LISP ベースの「世界最速」 (と作者が信じる) ウェブサーバ 54

ストーリー by reo
LISP 健在 部門より

ある Anonymous Coward 曰く、

John Fremlin 氏は小規模ダイナミックコンテンツ用に設計された自称「世界最速」なウェブサーバ teepeedee2をリリースした (本家 /. の記事John Fremlin's blog の記事より) 。

このサーバは全て LISP で書かれている。Fremlin 氏は昨年 11 月の Tokyo Linux Users Groupでこのプロジェクトを発表しており (pdf)、/.Jer の中には既にご存知の方もいるかもしれない。そこで彼はベンチマーク結果から「関数型プログラミング言語が C に勝ることができる」ことを示したという。

Github の teepeedee2 プロジェクトサイトはこちら

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • この方は (スコア:2, 参考になる)

    by Anonymous Coward on 2009年05月28日 12時13分 (#1574834)

    「世界最速」(と作者が信じる)FTPサーバ teepeedee を C++ で書いた方でもあります。

    • by vn (10720) on 2009年05月28日 12時21分 (#1574839) 日記
      つまり「世界最速男」ってわけ?
      日本の技術カンファレンスでも、ときどき「世界最速のうんちゃら...」とかいう発表があるけど、
      その日いちばんの退屈なプレゼンであることが多い。
      親コメント
      • by Anonymous Coward
        それはこっち [wikipedia.org]
      • by Anonymous Coward

        つまり「おもおか狙い」ってわけ?
        /.Jでも、ときどき「いっぽうロシアでは」とか「ということですね。わかります」とかいうコメントがあるけど、
        そのストーリーいちばんの退屈なコメントであることが多い。

  • by vn (10720) on 2009年05月28日 11時40分 (#1574807) 日記
    仮に使用した LISP 処理系が C で実装されていた場合、C に勝てるとは主張できないのではないか、と思います。
    • by mmgames (37884) on 2009年05月28日 12時53分 (#1574874)

      理論的にはその通りですが、現実的にはそうは言えないと思います。
      C言語でそのまま記述した場合よりも、LISPで記述した方が高速になったのであれば、
      そのLISP処理系の最適化の性能は、比較対象となるC言語で記述されたWebサーバーのプログラマの最適化能力よりも上である、と言えます。

      ただし、その場合であっても、より優秀なC言語のプログラマーにC言語でWebサーバーを記述してもらえれば、
      LISP版を上回ることは理論上は可能です。なぜならLISP版も最終的にはC言語で実装されていますから。

      まあ、タレコミ記事は「LISPでもがんばればCを超える速度も無理じゃない」という雰囲気なので、速度を出すのはCよりも大変なんでしょう。
      それだと John Fremlin 氏 の優秀さはたたえられてもLISPが勝てたとは言えない気がします。

      親コメント
      • by Anonymous Coward
        そうやな~
        そうなると Symbolics を持って来なしゃ~ないな
        そして討ち死に
      • by Anonymous Coward
        どんなプログラマーだって無限の寿命を持ってるわけじゃない。
        CでLispの処理系を最適化する手間(A) + Lispでhttpdを最適化する手間(B) が、Cでhttpdを最適化する手間(C)より少ない工数でできることくらい十分にありえる話だ。(A)は他の用途にも使い回せるし、っつかそもそも最初から(A)は使い回しなのかもしれない。
        ハイブリッドの新車を買うより、中古のコンパクトカーを買う方がエコなのと同じ理屈だ。
        • by mmgames (37884) on 2009年05月28日 17時15分 (#1575115)

          もし、LISPの最適化性能がCの一般プログラマーの最適化手腕以上ならば、
          自動で最適化できるLISPの方が手動で最適化する必要があるCよりも開発効率がよい、と言いたいわけですよね?
          その通りならLISPの勝利だと思いますが、既に書いてあるように「LISPでもがんばればCを超える速度も無理じゃない」って雰囲気なので、
          「普通のLISPプログラマが記述してもCと同等以上」というレベルに到達してないんじゃないかと。だから勝ててないかなと。

          親コメント
        • by vn (10720) on 2009年05月28日 14時09分 (#1574937) 日記

          ハイブリッドの新車を買うより、中古のコンパクトカーを買う方がエコなのと同じ理屈だ。

          わかりにくーい。
          まるで説明になっとらん。

          親コメント
      • by Anonymous Coward

        > 理論的にはその通りですが、
        理論的には、処理系の最適化性能にかかわらずC言語ではできない最適化をLisp(など)ならできる可能性もありますが、現実はそんなに甘くないようです [hatena.ne.jp]。
        理論的にはx86より優れているはずのプロセッサアーキテクチャが(Intel自身のIA-64さえも)ことごとく敗れ去っているようなものですね。

        • by mmgames (37884) on 2009年05月29日 10時36分 (#1575527)

          なるほどなるほど。ものすごく簡単に言えば「高級言語ほど機能が抽象化されているから最適化できる」という訳ですね。

          > 理論的にはx86より優れているはずのプロセッサアーキテクチャが(Intel自身のIA-64さえも)ことごとく敗れ去っているようなものですね。
          こいつは単純に研究時間と研究開発費の差じゃないすか? インテルだってIA64よりもX86に多大な開発費を投じていたかと。
          でも考えてみればx86のオーバーヘッドってx86から内部Riscコードへの変換だけですから案外たいしたこと無いのかも。

          親コメント
          • by Anonymous Coward
            > こいつは単純に研究時間と研究開発費の差じゃないすか? インテルだってIA64よりもX86に多大な開発費を投じていたかと。

            今は開発サイクルの谷間にいるのでぱっとしませんが、AMDのx86もなかなかの高性能ですよ。
          • by Anonymous Coward
            > でも考えてみればx86のオーバーヘッドってx86から内部Riscコードへの変換だけですから案外たいしたこと無いのかも。

            現時点でのx86の一番の難点は、命令境界が先頭から逐次的に走査しないとわからないため、命令の切り出し→並列実行にはコストがかかるという点です。
            もっとも命令の切り出し自体はデータフロー的依存性はないので、原理的には並列度の高いものです。

            命令セットアーキテクチャの審美的な美しさと回路的な効率や単純さは一致しないことのほうが多いですね。(個人的経験です。前者は対称性を重んじるあまりに無理な設計になりがちで、後者はfree parallelism but costly wiringでしょうか)
        • by Anonymous Coward
          > 理論的にはx86より優れているはずのプロセッサアーキテクチャが(Intel自身のIA-64さえも)ことごとく敗れ去っているようなものですね。

          そういう理論があったとは初耳です。ポインタだけでもお教え願えないでしょうか。(マジ)
    • Re:C に勝てる? (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2009年05月28日 12時06分 (#1574830)

      逆だよ、むしろ胸を張って主張出来るよ。
      明確にオーバーヘッドがあるのに、素のCより早いのならば
      それはLISPがプログラマに与えてくれるメリットがとても大きい事を意味する

      親コメント
    • by Anonymous Coward
      つまりLISPの処理系を作ったCの処理系を作ったアセンブリ言語が最強ってことですね。
      • by Anonymous Coward

        今風の最適化をコンパイラにやらせたのと、人ががんばったコードと、どちらが早いのだろう。

    • by Anonymous Coward
      普通はブートストラップしているかと…
    • by Anonymous Coward

      JavaはCより速かった [hatena.ne.jp]というネタもあってだな…

    • by Anonymous Coward

      そういや某社に行っていたころ、Common/Lispの方から来ましたー
      って感じのコンサルタントが入ってきて、「Lispで作れば、スマート
      で高速なシステムが作れるから、Lispにしましょう」とか上の方で
      なにやらやってましたねー。なんとかお引き取り願いましたが。

       個人的には、Lispに適した分野で、小規模なコアモジュールを
      作るにはいいけど、システム全体とかには向かないと思うのですが、
      業務で使っている人の意見を聞きたいところ。

      #CADシステムをLispで書いていいものなのか

    • by Anonymous Coward

      全体プログラム最適化を行う処理系の場合、たとえ出力がCであっても、そのコードはおよそ
      人間が読めるものではないですし、ましてや人が書けるものではないです。
      (たとえばモジュール全体がひとつのC関数になって、Lispレベルの関数呼び出しが全て
      gotoになっている、とか。)

      なので、「手で書いたCに勝てる」と言うのはあながち間違いではないでしょう。
      「機械生成したCコード」まで含むとすると、言語間比較に意味が無くなってしまいます。

      ただし、Lispの場合、簡単にマイ言語を作れて、コンパイル時にマクロ展開で生成される
      「生の」Lispコードはやっぱり人間が直接読み書きるものでは
      なかったりするので、そうなると結局比較しているのはLispではなくマイ言語なのではないか、
      という議論になってしまうかもしれません。

    • by Anonymous Coward
      その論理が罷り通るのであれば、各CPUネイティブの機械語が最速という事になりませんか? hoge言語最速、という主張は盛り上がるものですが、言語の差異について議論する際のテーマとして「処理速度」というのはもう一つピンとこないように感じます。 それを踏まえてなお、という事であれば失礼しました。
      • by Anonymous Coward
        > その論理が罷り通るのであれば、各CPUネイティブの機械語が最速という事になりませんか?

        機械語はポータブルではありません。vn氏のタワゴトに引きずられてナンセンスな極論を口にしないよう気をつけましょう。
  • by duenmynoth (34577) on 2009年05月28日 15時43分 (#1575021) 日記
    どういう理由で最速なのかと
    そこを「判りやすく」説明して欲しいですね

    今話題の低燃費車も、
    数値だけで言えばエアコンその他の便利装備を一切排除したマニュアルの軽自動車が
    価格対性能比で言えば最強なのですが
    実際にはあまり売れていないようですし

    言語の能力として最速なのであればウェブサーバに限定するのは妙ですし
    キャッチーにしたいのであればもっと他に選択肢があったと思うのですが・・・
    • by Anonymous Coward
      > どういう理由で最速なのかと
      > そこを「判りやすく」説明して欲しいですね

      ある限定された問題で最速であったとリンク先のPDFにわかりやすぅく書いてあります。
      大人ならちゃんと読みなさい。
    • by Anonymous Coward

      しかし、せっかくガソリン燃やして獲得した運動エネルギーをブレーキで熱に変えてしまう「エアコンその他の便利装備を一切排除したマニュアルの軽自動車」は燃費はいいかもしれないけど、改善の余地はありそう。

      最強は「エアコンその他の便利装備を一切排除したマニュアルのハイブリッド自動車」なのかな。

  • http://practical-scheme.net/trans/beating-the-averages-j.html [practical-scheme.net]
    >時々、Yahoo Storeは今でもLispを使っているのかと聞かれる。答えはイエスだ。
    >Lispコードはそっくりそのまま、まだある。 Yahooはサーバー側のソフトウェアを
    >、エリック・レイモンドが薦めた5つの言語全てを使って書いている。
    lispを勉強しようかなぁ~
    • by Anonymous Coward
      その記事を見てすぐにlispの勉強を始めずに勉強しようかなぁ〜とスラドに書き込んだ君はルーザー
  • by Anonymous Coward on 2009年05月28日 11時42分 (#1574810)

    PostScriptで書かれたhttpd [pugo.org]なんてのがあったな。FORTH系の言語だから速そうな気がするが。
    そういやAdobeが作ったJavaScriptインタプリタも中間コードがFORTHらしいな。

    • by Anonymous Coward

      > そういやAdobeが作ったJavaScriptインタプリタも中間コードがFORTHらしいな。

      ちょっと違うかも。

      http://www.bluishcoder.co.nz/2008/02/quick-introduction-to-tamarin-tra... [bluishcoder.co.nz]
      > the interpreter is written in Forth. There are .fs files in the 'core' subdirectory that contains the Forth source code. Each 'abc' bytecode is implemented in lower level instructions which are implemented in Forth. The tracing jit operates on these lower level instructions. The system can be extended with Forth code to call native C fun

    • by Anonymous Coward

      PSで書けるならLIPSベースのウェブサーバもアリですね!

      #LISPとLIPSをかけただけ

    • by Anonymous Coward

      広い意味でのFORTHだから速い、とは限りません。

      FORTHのことは疎いのでPSについてだけ言いますと、ありゃ無名関数だのなんだのといったモダン動的言語っぽい機能がてんこ盛りの、かなりの高級言語です。
      #Polymorphic Operatorって…

      暗黙のスタックなどが無いからって必ずしも速くなるわけじゃないですし。

      • by Anonymous Coward

        モダン動的言語っぽい機能があるから速くないとは限りません。
        PostScriptの無名関数は単なる配列です。オペレータは単なるハッシュです。ポリモルフィズムはハッシュの切り替えです。
        こんな割り切りは低級言語だからこそできるのだと思いますよ。

        • by Anonymous Coward
          そうですね。テーブル(=配列、ハッシュ)は強力な仕組みですが、それだけでは高級感はないですね。
          やはりpythonやrubyの高級感はリフレクションにあるのだと思います。PSには多分ないでしょ?
  • by Anonymous Coward on 2009年05月28日 11時54分 (#1574820)
    Linuxのカーネルモードで動くTUX web serverには勝てない予感。
    • by Anonymous Coward

      って動的コンテンツか。C言語だと文字列の連結をうまく書かないと遅くなります。毎回strlenとか(s)printfとか論外。
      文字列の長さを保存しておいて、連結時に配列サイズが足りなくなったら2倍2倍にするのがコツです。
      固定長のバッファで済むならそれが一番ですが、長さ制限かっこ悪いって時代ですからね。

      • Re:最速とはいえ (スコア:1, おもしろおかしい)

        by Anonymous Coward on 2009年05月28日 13時40分 (#1574917)
        > かっこ悪い

        LISPの悪口か?

        # 言ってみたかっただけなのでAC
        親コメント
      • by Anonymous Coward

        静的コンテンツならFreeOcean [e-trees.jp]が最速でしょうからねぇ。
        VHDLもある意味立派な言語ということで・・・

      • by Anonymous Coward

        正しい文字列処理とは文字列の長さを知っておいた上で(strcpyの代わりに)memcpyすることだ

        とUlrich Drepper大先生がおっしゃっておりました。

typodupeerror

吾輩はリファレンスである。名前はまだ無い -- perlの中の人

読み込み中...