PLOの華麗さと貧しさ - ページ 3

 
Integer:

実は、試されていたのはコンパイラではなく、同じ問題を解決するための2つの方法だったのです。冷蔵庫の音は関係ない、いかに凍らせるかだ。

投げやりな問題で、やかましい...。

仮想関数は 決してインラインではないので、最適化を有効にすると、切り替えがうまくいけば、単純な例で比較する意味がなくなります。それは1つです。

誰がOOPの方が速いなんて言ったんだ?より簡単で、より論理的だが、高速とは言い難い。それは2つです。

嫌なら使うな。

 
Integer:
その後、2-空でない関数、3-一意な関数の2種類のテストを行ったが、結果は同様であった。バリエーション1は、やはりC#で 実施したが、結果は逆だった。

こんな選択肢もあるんですね。そして、それらもインライン方式にフィットし、うまく最適化されています。

C#を使ったバリエーションでは、コード・オプティマイザの働きを誤解して、別の誤解を招くようなエラーが発生します。コードは表示されず、ドットネットコンパイラには、ナッツのようなテスト例の縮退したケースをクラックできる最適化手法が数倍もある。先ほど、簡単なケースで仮想関数を通常の関数に変換する例を挙げました。この最適化(このテストのような単純な場合)も有効にして、あなたも「仮想」メソッドが突然まっすぐなメソッドを追い越す様子を見ることができるでしょう。

 
TheXpert:

投げやりな不具合とノイズ...。

仮想関数は 決してインラインではないので、最適化を有効にすると、切り替えがうまくいけば、単純な例で比較する意味がなくなります。それは1つです。

誰がOOPの方が速いなんて言ったんだ?より簡単で、より論理的だが、高速とは言い難い。それは2つです。

嫌なら使うな。

まあ、全然問題ないんですけどね。あくまでも実験として結果を出し、結論を出しているのです。

好きだ、嫌いだ。fastの代わりにslowを使うのは論理的でない。

 
Renat:

こんな選択肢もあるんですね。そして、それらもインライン化スキームに適合し、うまく最適化されています。

C#を使った例では、コードオプティマイザーの働きを誤解したために起こる、別の誤解を招くようなエラーを示しています。コードは表示されず、ドットネットコンパイラには、ナッツのようなテスト例の縮退したケースをクラックできる最適化手法が数倍もある。先ほど、簡単なケースで仮想関数を通常の関数に変換する例を挙げました。この最適化(このテストのような単純な場合)も有効にして、あなたも「仮想」メソッドが突然まっすぐなメソッドを追い越す様子を見ることができるでしょう。

どんな結果が出ても、間違っている、誤解を招くと思われる。

- 何のために?

- インド人です。

(xf Lone Ranger)

いくらやっても、スイッチ経由の仮想方式より遅くなるのはどうしようもない。試してみたが、残念、うまくいかなかった。

 

ここに付録として、最初のC#のテストがあります。以下はその結果 である。

ファイル:
test.zip  66 kb
 

証拠は向こうからやってくる。あるいはまた、ただの言葉。

大体、私は事実にしか興味がないんです。

OOPが遅いことは既に知っているが、かなり具体的な利便性を提供している

 
Vinin:

証拠は向こうからやってくる。

何を証明する?
 
TheXpert:
何を証明する?
アンドレイ あなたには、デミの間違いを証明したいという思いがあるのですね。では、それを私にください。
 

おもちゃを書くのになぜOOPが必要なのか?)

 

いずれにせよ、この問題が提起されたことは良いことです。

コンパイラとそのオプティマイザの改良に常に取り組んでいます。ここでは、仮想メソッド呼び出しの最適化に集中します(多くの仮想メソッドは直接メソッドに変えることができます)。