アカウント名:
パスワード:
理論的にはその通りですが、現実的にはそうは言えないと思います。Ｃ言語でそのまま記述した場合よりも、LISPで記述した方が高速になったのであれば、そのLISP処理系の最適化の性能は、比較対象となるＣ言語で記述されたWebサーバーのプログラマの最適化能力よりも上である、と言えます。
ただし、その場合であっても、より優秀なＣ言語のプログラマーにＣ言語でWebサーバーを記述してもらえれば、LISP版を上回ることは理論上は可能です。なぜならLISP版も最終的にはＣ言語で実装されていますから。
まあ、タレコミ記事は「LISPでもがんばればＣを超える速度も無理じゃない」という雰囲気なので、速度を出すのはＣよりも大変なんでしょう。それだと John Fremlin 氏 の優秀さはたたえられてもLISPが勝てたとは言えない気がします。
もし、LISPの最適化性能がＣの一般プログラマーの最適化手腕以上ならば、自動で最適化できるLISPの方が手動で最適化する必要があるＣよりも開発効率がよい、と言いたいわけですよね？その通りならLISPの勝利だと思いますが、既に書いてあるように「LISPでもがんばればＣを超える速度も無理じゃない」って雰囲気なので、「普通のLISPプログラマが記述してもＣと同等以上」というレベルに到達してないんじゃないかと。だから勝ててないかなと。
ハイブリッドの新車を買うより、中古のコンパクトカーを買う方がエコなのと同じ理屈だ。
わかりにくーい。 まるで説明になっとらん。
ハイブリッドの中古車はやめとけってことじゃないの？
> 理論的にはその通りですが、理論的には、処理系の最適化性能にかかわらずC言語ではできない最適化をLisp(など)ならできる可能性もありますが、現実はそんなに甘くないようです [hatena.ne.jp]。理論的にはx86より優れているはずのプロセッサアーキテクチャが(Intel自身のIA-64さえも)ことごとく敗れ去っているようなものですね。
なるほどなるほど。ものすごく簡単に言えば「高級言語ほど機能が抽象化されているから最適化できる」という訳ですね。
> 理論的にはx86より優れているはずのプロセッサアーキテクチャが(Intel自身のIA-64さえも)ことごとく敗れ去っているようなものですね。こいつは単純に研究時間と研究開発費の差じゃないすか？ インテルだってIA64よりもX86に多大な開発費を投じていたかと。でも考えてみればx86のオーバーヘッドってx86から内部Riscコードへの変換だけですから案外たいしたこと無いのかも。
逆にLISPでつくったCコンパイラーがあったとして、そのコンパイラーを使って生成されたコードはLISPに負うものかな？
コンパイル時間を無視するのであれば、いくらでも最適化出来ると思いますので、生成されたコードは元のＬＩＳＰ処理系を上回ることは十分可能だと思います。ただし、コンパイル時間は元のＬＩＳＰ処理系の速度に依存するでしょう。
逆だよ、むしろ胸を張って主張出来るよ。明確にオーバーヘッドがあるのに、素のCより早いのならばそれはLISPがプログラマに与えてくれるメリットがとても大きい事を意味する
今風の最適化をコンパイラにやらせたのと、人ががんばったコードと、どちらが早いのだろう。
JavaはCより速かった [hatena.ne.jp]というネタもあってだな…
そういや某社に行っていたころ、Common/Lispの方から来ましたーって感じのコンサルタントが入ってきて、「Lispで作れば、スマートで高速なシステムが作れるから、Lispにしましょう」とか上の方でなにやらやってましたねー。なんとかお引き取り願いましたが。
個人的には、Lispに適した分野で、小規模なコアモジュールを作るにはいいけど、システム全体とかには向かないと思うのですが、業務で使っている人の意見を聞きたいところ。
＃ＣＡＤシステムをLispで書いていいものなのか
AutoCAD って LISP ベースのような気がする。
LISP関係の話題が出るたびにAutoLISPの話題が出ることが多い気がしますが、 (現在の)AutoCADはほとんどCかC++で書かれてますよ。 拡張言語としてAutoLISPが存在しますが、大規模な拡張機能はCOMを使って作られてます。 私はLISP好きですけど、AutoLISPの仕様は好きじゃないので、全く使ってませんが。
http://d.hatena.ne.jp/kwatch/20080702/1215014534 [hatena.ne.jp]
全体プログラム最適化を行う処理系の場合、たとえ出力がCであっても、そのコードはおよそ人間が読めるものではないですし、ましてや人が書けるものではないです。(たとえばモジュール全体がひとつのC関数になって、Lispレベルの関数呼び出しが全てgotoになっている、とか。)
なので、「手で書いたCに勝てる」と言うのはあながち間違いではないでしょう。「機械生成したCコード」まで含むとすると、言語間比較に意味が無くなってしまいます。
ただし、Lispの場合、簡単にマイ言語を作れて、コンパイル時にマクロ展開で生成される「生の」Lispコードはやっぱり人間が直接読み書きるものではなかったりするので、そうなると結局比較しているのはLispではなくマイ言語なのではないか、という議論になってしまうかもしれません。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家
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: (スコア:0)
逆にLISPでつくったCコンパイラーがあったとして、そのコンパイラーを使って生成されたコードはLISPに負うものかな？
Re:C に勝てる? (スコア:2)
コンパイル時間を無視するのであれば、いくらでも最適化出来ると思いますので、
生成されたコードは元のＬＩＳＰ処理系を上回ることは十分可能だと思います。
ただし、コンパイル時間は元のＬＩＳＰ処理系の速度に依存するでしょう。
Re:C に勝てる? (スコア:1, すばらしい洞察)
逆だよ、むしろ胸を張って主張出来るよ。
明確にオーバーヘッドがあるのに、素のCより早いのならば
それはLISPがプログラマに与えてくれるメリットがとても大きい事を意味する
デメリットも大きい (スコア:0)
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氏のタワゴトに引きずられてナンセンスな極論を口にしないよう気をつけましょう。