アカウント名:
パスワード:
理論的にはその通りですが、現実的にはそうは言えないと思います。Ｃ言語でそのまま記述した場合よりも、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に負うものかな？
コンパイル時間を無視するのであれば、いくらでも最適化出来ると思いますので、生成されたコードは元のＬＩＳＰ処理系を上回ることは十分可能だと思います。ただし、コンパイル時間は元のＬＩＳＰ処理系の速度に依存するでしょう。
より多くのコメントがこの議論にあるかもしれませんが、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)
コンパイル時間を無視するのであれば、いくらでも最適化出来ると思いますので、
生成されたコードは元のＬＩＳＰ処理系を上回ることは十分可能だと思います。
ただし、コンパイル時間は元のＬＩＳＰ処理系の速度に依存するでしょう。