PLOの華麗さと貧しさ - ページ 2 1234567 新しいコメント Renat Fatkhullin 2014.07.05 15:40 #11 Integer:なぜコンパイルの仕組みを理解する必要があるのでしょうか? ただ、良い結果より悪い結果の方が良いと信じて?テストをきちんと書き、誤解を与えないこと。テストに書いてあることと、実際にテストしていることを理解できていないのでは? これは、ドットネットや類似言語の大量教育の結果です。プログラマーは、何が本当に機能するのか、どのように機能するのかを理解しようとは全く思っていないのです。 Victor Nikolaev 2014.07.05 15:51 #12 Renat:テストをきちんと書き、誤解を与えないこと。テストに書いてあることと、実際にテストしていることを理解できていない。 ドットネットやそれに類する言語を大量に教育した結果、そのようなことになってしまったのです。プログラマーは、現実に何がどのように動いているのかを理解しようという気はまったくないのです。みんな、馬のように(見過ぎないように)自分の目に目隠しをするんです。 一方は自分のものを見て、他方は自分のものを見ている。しかし、だからといって、両方が正しいとか間違っているとかいうことではありません。 真実は、どこか近くにある。 開発者はあるものを欲しがり、別のものを手に入れた。課題が達成されたことを意味するものではありません。効果はあるんですけどね。たぶん、期待されていた形でも、望まれていた形でもないでしょう。ユーザーは自分のテストをする(これはかなり予測できる)。そのテストがすべての関係者を満足させるとは限りません。真実はそこにある。操作のスピードが重要すぎる。これは私の気まぐれではなく、人生なのです。そして、それを言葉ではなく、テストで証明しなければならないのです。 Renat Fatkhullin 2014.07.05 16:15 #13 Vinin: 操作のスピードが重要すぎる。これは私の気まぐれではなく、人生なのです。そして、それを言葉ではなく、テストで証明しなければならないのです。私はすぐに、提案されたテストの誤りを指摘した。それから何度かポイントを説明しました。 Renat Fatkhullin 2014.07.05 16:22 #14 仮想メソッドは通常のメソッドよりも必ずコストがかかりますが、最適化コンパイラのテストは、何がどのように折りたたまれて最適化されているかを理解した上で、正しく行う必要があります。この場合、仮想関数を 自動的に正規関数に変換する最適化手法をまだ実装していないため(他のコンパイラは可能な限りこれを行う)、このテストの結果がすぐに変わり、再び誤解を招くことになります(仮想メソッド呼び出しが突然正規関数よりも速くなる可能性があります)。 Victor Nikolaev 2014.07.05 16:35 #15 Renat:仮想メソッドは通常のメソッドよりも必ずコストがかかりますが、最適化コンパイラのテストは、何がどのように折りたたまれて最適化されているかを理解した上で、正しく行う必要があります。この場合、仮想関数を 自動的に正規関数に変換する最適化手法をまだ実装していないため(他のコンパイラは可能な限りこれを行う)、このテストの結果がすぐに変わり、また誤解を招くことになります(仮想メソッド呼び出しが突然正規関数より速くなる可能性があります)。 つまり--この時点では、Integerの言うとおりです。そして、一度に認めることも説明することも不可能だった。それとも、何かが邪魔をしているのでしょうか? Renat Fatkhullin 2014.07.05 16:37 #16 Vinin: つまり--現段階では、インテージが正しいのだ。すぐに認めて説明できないのか。それとも、何か邪魔なものがあるのでしょうか? トピック全体をよく読み直してください。 Dmitry Fedoseev 2014.07.05 16:38 #17 Renat:仮想的な方法は、従来の方法よりも常に高価になりますが、最適化コンパイラのテストは、何が/どのように最小化され、最適化されているかを理解した上で、正しく行う必要があります。この場合、仮想関数を 通常の関数に自動的に変換する最適化手法を実装していないので(他のコンパイラは可能な限りそうしています)、このテストの結果がすぐに変わり、また誤解を招くことになります(仮想メソッドの呼び出しが通常のものより突然速くなる可能性があります)。実は、試されているのはコンパイラではなく、同じ問題を解決するための2つの方法なのです。冷蔵庫がどうウンウン唸っていても、どう凍るかが重要なんです。 Renat Fatkhullin 2014.07.05 16:44 #18 Integer:実は、試されていたのはコンパイラではなく、同じ問題を解決するための2つの方法だったのです。冷蔵庫がどうウンウンと唸っていても、大事なのは凍り方なんです。簡略化され退化したテストケースを提示して、間違ったテストをしたのです。問題ではなく、何もない例として退化したのです。あなたは、ダミーへの直接呼び出しのオプションを大幅に最適化しているコンパイラのオプティマイザに注意を払っていない。 Dmitry Fedoseev 2014.07.05 16:54 #19 Renat:簡略化され退化したテストケースを提示することで、間違ったテストを行っています。これはタスクではなく、まさに無に帰する例です。あなたは、ダミーへの直接呼び出しのオプションを大幅に最適化しているコンパイラのオプティマイザに注意を払っていない。 その後、空でない関数を使った2 種類、ユニークな関数を使った3 種類のテストが行われましたが、結果は同様でした。バリエーション1は、やはりC#で 実施したが、結果は逆だった。 Victor Nikolaev 2014.07.05 16:56 #20 Renat: トピック全体をよく読み直してください。 いつまでも読んでいても仕方ないが、事実を伝えなければならない。テストを実施し、数字を示す。Integerが間違いであることを証明する必要があります。彼(だけでなく)には、そんな結果が必要なのだ。私もよくしゃべりますが、事実無根の話はしないようにしています。Integerのテスト結果を信頼しています。しかし、相反するものはなく、言葉だけであった 1234567 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
なぜコンパイルの仕組みを理解する必要があるのでしょうか? ただ、良い結果より悪い結果の方が良いと信じて?
テストをきちんと書き、誤解を与えないこと。
テストに書いてあることと、実際にテストしていることを理解できていないのでは?
これは、ドットネットや類似言語の大量教育の結果です。プログラマーは、何が本当に機能するのか、どのように機能するのかを理解しようとは全く思っていないのです。
テストをきちんと書き、誤解を与えないこと。
テストに書いてあることと、実際にテストしていることを理解できていない。
ドットネットやそれに類する言語を大量に教育した結果、そのようなことになってしまったのです。プログラマーは、現実に何がどのように動いているのかを理解しようという気はまったくないのです。
みんな、馬のように(見過ぎないように)自分の目に目隠しをするんです。
一方は自分のものを見て、他方は自分のものを見ている。しかし、だからといって、両方が正しいとか間違っているとかいうことではありません。
真実は、どこか近くにある。
開発者はあるものを欲しがり、別のものを手に入れた。課題が達成されたことを意味するものではありません。効果はあるんですけどね。たぶん、期待されていた形でも、望まれていた形でもないでしょう。
ユーザーは自分のテストをする(これはかなり予測できる)。そのテストがすべての関係者を満足させるとは限りません。
真実はそこにある。
操作のスピードが重要すぎる。これは私の気まぐれではなく、人生なのです。
そして、それを言葉ではなく、テストで証明しなければならないのです。
操作のスピードが重要すぎる。これは私の気まぐれではなく、人生なのです。
そして、それを言葉ではなく、テストで証明しなければならないのです。
私はすぐに、提案されたテストの誤りを指摘した。それから何度かポイントを説明しました。
仮想メソッドは通常のメソッドよりも必ずコストがかかりますが、最適化コンパイラのテストは、何がどのように折りたたまれて最適化されているかを理解した上で、正しく行う必要があります。
この場合、仮想関数を 自動的に正規関数に変換する最適化手法をまだ実装していないため(他のコンパイラは可能な限りこれを行う)、このテストの結果がすぐに変わり、再び誤解を招くことになります(仮想メソッド呼び出しが突然正規関数よりも速くなる可能性があります)。
仮想メソッドは通常のメソッドよりも必ずコストがかかりますが、最適化コンパイラのテストは、何がどのように折りたたまれて最適化されているかを理解した上で、正しく行う必要があります。
この場合、仮想関数を 自動的に正規関数に変換する最適化手法をまだ実装していないため(他のコンパイラは可能な限りこれを行う)、このテストの結果がすぐに変わり、また誤解を招くことになります(仮想メソッド呼び出しが突然正規関数より速くなる可能性があります)。
つまり--現段階では、インテージが正しいのだ。すぐに認めて説明できないのか。それとも、何か邪魔なものがあるのでしょうか?
仮想的な方法は、従来の方法よりも常に高価になりますが、最適化コンパイラのテストは、何が/どのように最小化され、最適化されているかを理解した上で、正しく行う必要があります。
この場合、仮想関数を 通常の関数に自動的に変換する最適化手法を実装していないので(他のコンパイラは可能な限りそうしています)、このテストの結果がすぐに変わり、また誤解を招くことになります(仮想メソッドの呼び出しが通常のものより突然速くなる可能性があります)。
実は、試されているのはコンパイラではなく、同じ問題を解決するための2つの方法なのです。冷蔵庫がどうウンウン唸っていても、どう凍るかが重要なんです。
実は、試されていたのはコンパイラではなく、同じ問題を解決するための2つの方法だったのです。冷蔵庫がどうウンウンと唸っていても、大事なのは凍り方なんです。
簡略化され退化したテストケースを提示して、間違ったテストをしたのです。問題ではなく、何もない例として退化したのです。
あなたは、ダミーへの直接呼び出しのオプションを大幅に最適化しているコンパイラのオプティマイザに注意を払っていない。
簡略化され退化したテストケースを提示することで、間違ったテストを行っています。これはタスクではなく、まさに無に帰する例です。
あなたは、ダミーへの直接呼び出しのオプションを大幅に最適化しているコンパイラのオプティマイザに注意を払っていない。
トピック全体をよく読み直してください。