アカウント名:
パスワード:
ネイティブなマシン語なら当たり前だよね?あとは最適化とかライブラリの出来次第。実際には多少遅くとも同等扱いなんでしょ。
> ネイティブなマシン語なら当たり前だよね?
それは良くある勘違いです.当たり前ではありません.
C/C++のコードに比べるとpythonのコードはコンパイル&最適化が難しいです.難しい理由の一つは,pythonは実行するまで変数の型が決まらないためです.これはネイティブなマシン語を吐くだけでは全く解決できない問題です.
C/C++ふうに言えば,pythonでソースコード中に foo(x) という関数呼び出しがあった場合xの型はint型,unsigned int型,float型,std::string型,struct X,class Y,など無限の可能性があります.当然実行時には型の候補は有限で,実際の型は
> 当然実行時には型の候補は有限で,実際の型は実行時には一つになります,ただし実行されるたびに型が変わる場合もあります.
型推論が重いのは事実だが、アルゴリズム自体は30年前にselfコンパイラで提案されている。
整数オーバーフロー検出も、実行時プロファイルのAOTコンパイラへのフィードバックと値範囲解析とCPUの投機実行により、オーバーフローしなかったパスの速度低下はかなり~完全に抑えられる。これも20年くらい前からある技術。
Cythonとかはその路線。Pythonはあくまでもアノテーションはアノテーションでアノテーションと実際に入ってきた値で実際に入ってきた値を採用する。
別におかしなことを書いてるわけではないんだけど、
> アノテーションは アノテーションで アノテーションと> 実際に入ってきた値で 実際に入ってきた値を
ちょっとクラクラしたw
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
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: (スコア:0)
> 当然実行時には型の候補は有限で,実際の型は実行時には一つになります,ただし実行されるたびに型が変わる場合もあります.
型推論が重いのは事実だが、アルゴリズム自体は30年前にselfコンパイラで提案されている。
整数オーバーフロー検出も、実行時プロファイルのAOTコンパイラへのフィードバックと値範囲解析とCPUの投機実行により、オーバーフローしなかったパスの速度低下はかなり~完全に抑えられる。これも20年くらい前からある技術。
Re:C/C++と同等もしくはそれ以上の性能 (スコア:0)
Re: (スコア:0)
Cythonとかはその路線。
Pythonはあくまでもアノテーションはアノテーションでアノテーションと実際に入ってきた値で実際に入ってきた値を採用する。
Re: (スコア:0)
別におかしなことを書いてるわけではないんだけど、
> アノテーションは アノテーションで アノテーションと
> 実際に入ってきた値で 実際に入ってきた値を
ちょっとクラクラしたw