LISP ベースの「世界最速」 (と作者が信じる) ウェブサーバ 54
ストーリー by reo
LISP 健在 部門より
LISP 健在 部門より
ある Anonymous Coward 曰く、
John Fremlin 氏は小規模ダイナミックコンテンツ用に設計された自称「世界最速」なウェブサーバ teepeedee2をリリースした (本家 /. の記事、John Fremlin's blog の記事より) 。
このサーバは全て LISP で書かれている。Fremlin 氏は昨年 11 月の Tokyo Linux Users Groupでこのプロジェクトを発表しており (pdf)、/.Jer の中には既にご存知の方もいるかもしれない。そこで彼はベンチマーク結果から「関数型プログラミング言語が C に勝ることができる」ことを示したという。
Github の teepeedee2 プロジェクトサイトはこちら。
この方は (スコア:2, 参考になる)
「世界最速」(と作者が信じる)FTPサーバ teepeedee を C++ で書いた方でもあります。
Re:この方は (スコア:1)
日本の技術カンファレンスでも、ときどき「世界最速のうんちゃら...」とかいう発表があるけど、
その日いちばんの退屈なプレゼンであることが多い。
Re: (スコア:0)
Re: (スコア:0)
つまり「おもおか狙い」ってわけ?
/.Jでも、ときどき「いっぽうロシアでは」とか「ということですね。わかります」とかいうコメントがあるけど、
そのストーリーいちばんの退屈なコメントであることが多い。
Re:この方は (スコア:1)
未熟なプログラマーもまたしばしばその間違いを犯す。
Re: (スコア:0)
それはスベったと言う (-1, オフトピ) (スコア:0)
おもおか狙ってスベる事くらい、いっぱいあるさ。
「フレームのもと」コメントに気の効いた返しをするのがおすすめだよっ
C に勝てる? (スコア:1)
Re:C に勝てる? (スコア:2)
理論的にはその通りですが、現実的にはそうは言えないと思います。
Ｃ言語でそのまま記述した場合よりも、LISPで記述した方が高速になったのであれば、
そのLISP処理系の最適化の性能は、比較対象となるＣ言語で記述されたWebサーバーのプログラマの最適化能力よりも上である、と言えます。
ただし、その場合であっても、より優秀なＣ言語のプログラマーにＣ言語でWebサーバーを記述してもらえれば、
LISP版を上回ることは理論上は可能です。なぜならLISP版も最終的にはＣ言語で実装されていますから。
まあ、タレコミ記事は「LISPでもがんばればＣを超える速度も無理じゃない」という雰囲気なので、速度を出すのはＣよりも大変なんでしょう。
それだと John Fremlin 氏 の優秀さはたたえられてもLISPが勝てたとは言えない気がします。
Re: (スコア:0)
そうなると Symbolics を持って来なしゃ～ないな
そして討ち死に
Re: (スコア:0)
CでLispの処理系を最適化する手間(A) + Lispでhttpdを最適化する手間(B) が、Cでhttpdを最適化する手間(C)より少ない工数でできることくらい十分にありえる話だ。(A)は他の用途にも使い回せるし、っつかそもそも最初から(A)は使い回しなのかもしれない。
ハイブリッドの新車を買うより、中古のコンパクトカーを買う方がエコなのと同じ理屈だ。
Re:C に勝てる? (スコア:2)
もし、LISPの最適化性能がＣの一般プログラマーの最適化手腕以上ならば、
自動で最適化できるLISPの方が手動で最適化する必要があるＣよりも開発効率がよい、と言いたいわけですよね？
その通りならLISPの勝利だと思いますが、既に書いてあるように「LISPでもがんばればＣを超える速度も無理じゃない」って雰囲気なので、
「普通のLISPプログラマが記述してもＣと同等以上」というレベルに到達してないんじゃないかと。だから勝ててないかなと。
Re:C に勝てる? (スコア:1)
わかりにくーい。
まるで説明になっとらん。
Re:C に勝てる? (スコア:1, おもしろおかしい)
ハイブリッドの中古車はやめとけってことじゃないの？
Re: (スコア:0)
> 理論的にはその通りですが、
理論的には、処理系の最適化性能にかかわらずC言語ではできない最適化をLisp(など)ならできる可能性もありますが、現実はそんなに甘くないようです [hatena.ne.jp]。
理論的にはx86より優れているはずのプロセッサアーキテクチャが(Intel自身のIA-64さえも)ことごとく敗れ去っているようなものですね。
Re:C に勝てる? (スコア:2)
なるほどなるほど。ものすごく簡単に言えば「高級言語ほど機能が抽象化されているから最適化できる」という訳ですね。
> 理論的にはx86より優れているはずのプロセッサアーキテクチャが(Intel自身のIA-64さえも)ことごとく敗れ去っているようなものですね。
こいつは単純に研究時間と研究開発費の差じゃないすか？ インテルだってIA64よりもX86に多大な開発費を投じていたかと。
でも考えてみればx86のオーバーヘッドってx86から内部Riscコードへの変換だけですから案外たいしたこと無いのかも。
Re: (スコア:0)
今は開発サイクルの谷間にいるのでぱっとしませんが、AMDのx86もなかなかの高性能ですよ。
Re: (スコア:0)
現時点でのx86の一番の難点は、命令境界が先頭から逐次的に走査しないとわからないため、命令の切り出し→並列実行にはコストがかかるという点です。
もっとも命令の切り出し自体はデータフロー的依存性はないので、原理的には並列度の高いものです。
命令セットアーキテクチャの審美的な美しさと回路的な効率や単純さは一致しないことのほうが多いですね。(個人的経験です。前者は対称性を重んじるあまりに無理な設計になりがちで、後者はfree parallelism but costly wiringでしょうか)
Re: (スコア:0)
そういう理論があったとは初耳です。ポインタだけでもお教え願えないでしょうか。(マジ)
Re:C に勝てる? (スコア:2)
コンパイル時間を無視するのであれば、いくらでも最適化出来ると思いますので、
生成されたコードは元のＬＩＳＰ処理系を上回ることは十分可能だと思います。
ただし、コンパイル時間は元のＬＩＳＰ処理系の速度に依存するでしょう。
Re:C に勝てる? (スコア:1, すばらしい洞察)
逆だよ、むしろ胸を張って主張出来るよ。
明確にオーバーヘッドがあるのに、素のCより早いのならば
それはLISPがプログラマに与えてくれるメリットがとても大きい事を意味する
Re: (スコア:0)
Re: (スコア:0)
今風の最適化をコンパイラにやらせたのと、人ががんばったコードと、どちらが早いのだろう。
Re: (スコア:0)
Re: (スコア:0)
JavaはCより速かった [hatena.ne.jp]というネタもあってだな…
Re: (スコア:0)
そういや某社に行っていたころ、Common/Lispの方から来ましたー
って感じのコンサルタントが入ってきて、「Lispで作れば、スマート
で高速なシステムが作れるから、Lispにしましょう」とか上の方で
なにやらやってましたねー。なんとかお引き取り願いましたが。
個人的には、Lispに適した分野で、小規模なコアモジュールを
作るにはいいけど、システム全体とかには向かないと思うのですが、
業務で使っている人の意見を聞きたいところ。
＃ＣＡＤシステムをLispで書いていいものなのか
Re:C に勝てる? (スコア:2, すばらしい洞察)
-- 哀れな日本人専用(sorry Japanese only) --
Re:C に勝てる? (スコア:2, 参考になる)
LISP関係の話題が出るたびにAutoLISPの話題が出ることが多い気がしますが、
(現在の)AutoCADはほとんどCかC++で書かれてますよ。
拡張言語としてAutoLISPが存在しますが、大規模な拡張機能はCOMを使って作られてます。
私はLISP好きですけど、AutoLISPの仕様は好きじゃないので、全く使ってませんが。
Re:C に勝てる? (スコア:1, 参考になる)
LispはLSI CADの一部分だとか． この種のツールは構造化された大規模なデータ（設計データ＋ライブラリデータ）を扱うので....
SmalltalkなんかはGIS（Geographic Information System，地理情報システム）で使われている事例があったんじゃないかな？
だめな奴は何をやってもだめ (スコア:0)
http://d.hatena.ne.jp/kwatch/20080702/1215014534 [hatena.ne.jp]
本物のプログラマはFortranを使う (スコア:0)
Re: (スコア:0)
全体プログラム最適化を行う処理系の場合、たとえ出力がCであっても、そのコードはおよそ
人間が読めるものではないですし、ましてや人が書けるものではないです。
(たとえばモジュール全体がひとつのC関数になって、Lispレベルの関数呼び出しが全て
gotoになっている、とか。)
なので、「手で書いたCに勝てる」と言うのはあながち間違いではないでしょう。
「機械生成したCコード」まで含むとすると、言語間比較に意味が無くなってしまいます。
ただし、Lispの場合、簡単にマイ言語を作れて、コンパイル時にマクロ展開で生成される
「生の」Lispコードはやっぱり人間が直接読み書きるものでは
なかったりするので、そうなると結局比較しているのはLispではなくマイ言語なのではないか、
という議論になってしまうかもしれません。
Re: (スコア:0)
Re: (スコア:0)
機械語はポータブルではありません。vn氏のタワゴトに引きずられてナンセンスな極論を口にしないよう気をつけましょう。
判断基準 (スコア:1)
そこを「判りやすく」説明して欲しいですね
今話題の低燃費車も、
数値だけで言えばエアコンその他の便利装備を一切排除したマニュアルの軽自動車が
価格対性能比で言えば最強なのですが
実際にはあまり売れていないようですし
言語の能力として最速なのであればウェブサーバに限定するのは妙ですし
キャッチーにしたいのであればもっと他に選択肢があったと思うのですが・・・
Re: (スコア:0)
> そこを「判りやすく」説明して欲しいですね
ある限定された問題で最速であったとリンク先のPDFにわかりやすぅく書いてあります。
大人ならちゃんと読みなさい。
Re: (スコア:0)
しかし、せっかくガソリン燃やして獲得した運動エネルギーをブレーキで熱に変えてしまう「エアコンその他の便利装備を一切排除したマニュアルの軽自動車」は燃費はいいかもしれないけど、改善の余地はありそう。
最強は「エアコンその他の便利装備を一切排除したマニュアルのハイブリッド自動車」なのかな。
Yahooのサーバー (スコア:1)
>時々、Yahoo Storeは今でもLispを使っているのかと聞かれる。答えはイエスだ。
>Lispコードはそっくりそのまま、まだある。 Yahooはサーバー側のソフトウェアを
>、エリック・レイモンドが薦めた5つの言語全てを使って書いている。
lispを勉強しようかなぁ～
Re: (スコア:0)
そういや昔 (スコア:0)
PostScriptで書かれたhttpd [pugo.org]なんてのがあったな。FORTH系の言語だから速そうな気がするが。
そういやAdobeが作ったJavaScriptインタプリタも中間コードがFORTHらしいな。
Re: (スコア:0)
> そういや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
Re: (スコア:0)
PSで書けるならLIPSベースのウェブサーバもアリですね！
#LISPとLIPSをかけただけ
Re: (スコア:0)
広い意味でのFORTHだから速い、とは限りません。
FORTHのことは疎いのでPSについてだけ言いますと、ありゃ無名関数だのなんだのといったモダン動的言語っぽい機能がてんこ盛りの、かなりの高級言語です。
＃Polymorphic Operatorって…
暗黙のスタックなどが無いからって必ずしも速くなるわけじゃないですし。
Re: (スコア:0)
モダン動的言語っぽい機能があるから速くないとは限りません。
PostScriptの無名関数は単なる配列です。オペレータは単なるハッシュです。ポリモルフィズムはハッシュの切り替えです。
こんな割り切りは低級言語だからこそできるのだと思いますよ。
Re: (スコア:0)
やはりpythonやrubyの高級感はリフレクションにあるのだと思います。PSには多分ないでしょ？
最速とはいえ (スコア:0)
Re: (スコア:0)
って動的コンテンツか。C言語だと文字列の連結をうまく書かないと遅くなります。毎回strlenとか(s)printfとか論外。
文字列の長さを保存しておいて、連結時に配列サイズが足りなくなったら2倍2倍にするのがコツです。
固定長のバッファで済むならそれが一番ですが、長さ制限かっこ悪いって時代ですからね。
Re:最速とはいえ (スコア:1, おもしろおかしい)
LISPの悪口か？
# 言ってみたかっただけなのでAC
Re: (スコア:0)
静的コンテンツならFreeOcean [e-trees.jp]が最速でしょうからねぇ。
VHDLもある意味立派な言語ということで・・・
Re: (スコア:0)
正しい文字列処理とは文字列の長さを知っておいた上で（strcpyの代わりに）memcpyすることだ
とUlrich Drepper大先生がおっしゃっておりました。