アカウント名:
パスワード:
ネイティブなマシン語なら当たり前だよね?あとは最適化とかライブラリの出来次第。実際には多少遅くとも同等扱いなんでしょ。
> ネイティブなマシン語なら当たり前だよね?
それは良くある勘違いです.当たり前ではありません.
C/C++のコードに比べるとpythonのコードはコンパイル&最適化が難しいです.難しい理由の一つは,pythonは実行するまで変数の型が決まらないためです.これはネイティブなマシン語を吐くだけでは全く解決できない問題です.
C/C++ふうに言えば,pythonでソースコード中に foo(x) という関数呼び出しがあった場合xの型はint型,unsigned int型,float型,std::string型,struct X,class Y,など無限の可能性があります.当然実行時には型の候補は有限で,実際の型は
>それくらい今のpython処理系はクソなのです.処理系というか、言語仕様からの"実行"の難しさだよね。それを分かったうえで、木に竹を接ぐようなことをしている。やっている連中は面白いからやっているのだろうけど、まったく筋が悪いことをやっているような気がするけどx86アーキテクチャと同じでそこにニーズがあるからやっていられるんだろうなぁこんなことまあ、袋小路に入らないで行き着く先を見てみたいですけどね。
言語比較のベンチマークで非jitのluaが馬鹿みたいに速いのはなんでだろう。勝っているのがluajitぐらいなのが不思議でならない。
他のVMが基本的にスタックマシンなのに対し、Lua VMはレジスタマシンになっているから、という説明は見かけるね。複合データ型も配列(連想配列)だけに特化して、今どきっぽいモノはシンタックスシュガーでごまかすことで、内部処理を最適化しているように見えます。何より、処理系が小さいので今どきのx86だとキャッシュがよく効くということもあるかも。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
C/C++と同等もしくはそれ以上の性能 (スコア:0)
ネイティブなマシン語なら当たり前だよね?
あとは最適化とかライブラリの出来次第。
実際には多少遅くとも同等扱いなんでしょ。
Re: (スコア:5, すばらしい洞察)
> ネイティブなマシン語なら当たり前だよね?
それは良くある勘違いです.当たり前ではありません.
C/C++のコードに比べるとpythonのコードはコンパイル&最適化が難しいです.
難しい理由の一つは,pythonは実行するまで変数の型が決まらないためです.これはネイティブなマシン語を吐くだけでは全く解決できない問題です.
C/C++ふうに言えば,pythonでソースコード中に foo(x) という関数呼び出しがあった場合
xの型はint型,unsigned int型,float型,std::string型,struct X,class Y,など無限の可能性があります.
当然実行時には型の候補は有限で,実際の型は
Re:C/C++と同等もしくはそれ以上の性能 (スコア:0)
>それくらい今のpython処理系はクソなのです.
処理系というか、言語仕様からの"実行"の難しさだよね。
それを分かったうえで、木に竹を接ぐようなことをしている。
やっている連中は面白いからやっているのだろうけど、
まったく筋が悪いことをやっているような気がするけど
x86アーキテクチャと同じでそこにニーズがあるからやっていられるんだろうなぁ
こんなこと
まあ、袋小路に入らないで行き着く先を見てみたいですけどね。
Re: (スコア:0)
言語比較のベンチマークで非jitのluaが馬鹿みたいに速いのはなんでだろう。
勝っているのがluajitぐらいなのが不思議でならない。
Re: (スコア:0)
他のVMが基本的にスタックマシンなのに対し、Lua VMはレジスタマシンになっているから、という説明は見かけるね。
複合データ型も配列(連想配列)だけに特化して、今どきっぽいモノはシンタックスシュガーでごまかすことで、内部処理を最適化しているように見えます。何より、処理系が小さいので今どきのx86だとキャッシュがよく効くということもあるかも。