PLOの華麗さと貧しさ - ページ 6 1234567 新しいコメント Alexey Navoykov 2014.07.07 17:21 #51 Renat:彼は、実際のプロジェクトにおいて、ダイレクトコールやバーチャルコールは何の効果もないことを示した。コストの大半は、MQLプログラムがほぼすべての時間を費やすシステム関数の呼び出しで発生します。通話を手配するコストは、ペイロードに比べれば微々たるものです。関数名と測定値が書かれた表が引数ですか? テレパシー専門家じゃないんだから、関数のコードを見てからモノを言えよ。 Denis Kirichenko 2014.07.07 17:27 #52 meat:関数名と測定値が書かれた表が論拠ですか? テレパシー専門家じゃないんだから、関数のコードを見てから、別の話をしましょうよ。 実験を完全に無条件で検証するためには、プロファイルされるオブジェクトのコードにアクセスする必要がある...そして、そんなものは存在しないので、検証は条件付きでしか行えない...。同僚のC-4が正直に結論を出せばの話だが...。 Vasiliy Sokolov 2014.07.07 17:27 #53 Renat:実際のプロジェクトでは、ダイレクトコールやバーチャルコールは何の影響もないことを示した。コストの大半は、MQLプログラムが最も時間を費やすシステム関数呼び出しで発生します。通話手配のコストはペイロードに比べれば微々たるものです。+100 はい、そうです!さらに、スプロール化したクラスの機能の一部を他のクラスが担うように書き換える(包含・分解)と、全体のパフォーマンスが上がり、コードに対する制御性が高まることに気づきました。つまり、実際には、Integerや旧来のC言語ファンが証明しようとしていることとは逆に、クラスの数が増え、メソッドの数が増え、逆にパフォーマンスが向上していることがわかる。 Vasiliy Sokolov 2014.07.07 17:33 #54 meat:関数名と測定値が書かれた表が論拠ですか? テレパシー専門家じゃないんだから、関数のコードを見てから、別の話をしましょうよ。 私は誰かを証明したり、納得させたりすることに興味はないんです。信じるか信じないかはあなた次第です。ただ、注意したいのは、ソースコードを持っていても何も出てこないということです。累積の複雑さは同じではない。しかし、その根拠がはっきりしないので、やはり何も証明できないのです。 Dmitry Fedoseev 2014.07.07 17:33 #55 C-4:+100 そうなんです!さらに、スプロール化したクラスの機能の一部を他のクラスが担うように書き換える(包含・分解)ことで、全体のパフォーマンスが上がり、コードのコントロール性が高まることに気づきました。つまり、実際には、Integerや旧来のC言語ファンが証明しようとしていることとは逆に、クラスの数が増え、メソッドの数が増え、逆にパフォーマンスが向上していることがわかる。新しい自己満足のあり方?早く、早くVasily、あなたは私がここで証明しようとしたことを読むべきでしたが、(あなたがどう思おうと、それを証明したのです)。 Alexey Navoykov 2014.07.07 18:57 #56 C-4: ただし、ソースコードがあっても何もわからないことに注意してください。累積の複雑さは同じではない。出典を分析しても、「まあ、そこにある何かが呼ばれている、何かがカウントされている、何かがどこからか引用されている、でも具体的に何がそうなのかはっきりしない、だからまた何も証明されない」と言うでしょう。一般的には、そうですね、おそらく個々の機能ではあまりわからないでしょう。 自分のソフトが他の人にとって豚のようなものであれば、何のために話すのか。実際、私たちが関心を持つのは、仮想メソッドを通過した回数と、それに費やした時間の合計です。 この表には、500万回実行された陰影付きの関数がありますね。なんだかよくわからないけど、一番シンプルな動作でバーチャルな方法なのかもしれない。 しかし、500万は些細なことだ。あなたのプログラムでは重い計算はしていないでしょうから、特に議論することはないでしょう。 仮に30000x300000の連立一次方程式の計算をして、仮想メソッドで行列要素にアクセスしていたとしたら、何か話があるはずです。 Mykola Demko 2014.07.07 22:31 #57 Integer:新しい自己暗示の方法?早く、早くVasily、あなたは結局、私がここで証明しようとしたことを読むべきです(そして、あなたがそれについて考えるものは何でも、それを証明しました)。ドミトリー、私はあなたに賛成でも反対でもない。それを理解するためには、コンパイラの内部構造をインラインで知る必要があるが、この情報をMQ用に公開することは、デコンパイラを書くのを手伝うに等しい。ここで議論している人の中で、そのような情報を持っているのはレナートだけなので、彼の言葉を信じるしかないのです。他に方法はないと思います。もし彼が「テストの設定が間違っている」と言うなら、おそらくそうなのでしょう。 質問が違う、このような場合に正しくテストを設定できるのはMQだけである、それが必要なのだ。テストにはテストを、私の言葉にはあなたの言葉を、と言われるように。そして、あなたは証明不可能なことを証明しようとしている。比較するものがなければ、自分の主張を証明することも反証することもできません。 Renat Fatkhullin 2014.07.08 00:16 #58 ここでデコンパイルは論外です。ただ、残酷なまでに最適化され、線形コードに退化した単純化されたケースをテストしないよう、最適化コンパイラのテクニックを理解し、知る必要があるのです。何もしないで第4世代のコンパイラをリリースしました。まさにその通りです。 Renat Fatkhullin 2014.07.08 00:19 #59 meat:例えば、30000x300000の連立一次方程式の計算をしていて、行列要素へのアクセスが仮想メソッドであった場合、すでに何か話があるはずです。そのような場合、最初のリファクタリングで100倍のスピードアップを図ることができる。そして、バーチャルコールはコスト面では10位となる。つまり、この例は非現実的なのです。 Dmitiry Ananiev 2014.07.08 02:42 #60 じゃあ、全部アセンブリ言語で書こうよ。どうせなら、そのほうが早い。問題がよくわからない。1MBのコードを持つExpert Advisorやインジケータを見たことがない。また、関数の呼び出しにもある程度の時間がかかる。機能も捨てよう大規模なプロジェクトのコントロールは、OOPでより便利になりました。また、コードの実行速度は、ブローカーへのping送信 時間やブローカーからの注文に対するレスポンスほど重要でないことが非常に多いのです。HFTのアルゴリズムをチェックする。最高速度が要求されますが、そこには複雑な計算は見当たりません。PS.A地点からB地点に移動するのに、普通はスーパーカーやスノーモービルは必要ありません。原付で十分です! 1234567 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
彼は、実際のプロジェクトにおいて、ダイレクトコールやバーチャルコールは何の効果もないことを示した。
コストの大半は、MQLプログラムがほぼすべての時間を費やすシステム関数の呼び出しで発生します。通話を手配するコストは、ペイロードに比べれば微々たるものです。
関数名と測定値が書かれた表が引数ですか? テレパシー専門家じゃないんだから、関数のコードを見てからモノを言えよ。
関数名と測定値が書かれた表が論拠ですか? テレパシー専門家じゃないんだから、関数のコードを見てから、別の話をしましょうよ。
実際のプロジェクトでは、ダイレクトコールやバーチャルコールは何の影響もないことを示した。
コストの大半は、MQLプログラムが最も時間を費やすシステム関数呼び出しで発生します。通話手配のコストはペイロードに比べれば微々たるものです。
+100 はい、そうです!
さらに、スプロール化したクラスの機能の一部を他のクラスが担うように書き換える(包含・分解)と、全体のパフォーマンスが上がり、コードに対する制御性が高まることに気づきました。つまり、実際には、Integerや旧来のC言語ファンが証明しようとしていることとは逆に、クラスの数が増え、メソッドの数が増え、逆にパフォーマンスが向上していることがわかる。
関数名と測定値が書かれた表が論拠ですか? テレパシー専門家じゃないんだから、関数のコードを見てから、別の話をしましょうよ。
+100 そうなんです!
さらに、スプロール化したクラスの機能の一部を他のクラスが担うように書き換える(包含・分解)ことで、全体のパフォーマンスが上がり、コードのコントロール性が高まることに気づきました。つまり、実際には、Integerや旧来のC言語ファンが証明しようとしていることとは逆に、クラスの数が増え、メソッドの数が増え、逆にパフォーマンスが向上していることがわかる。
新しい自己満足のあり方?早く、早く
Vasily、あなたは私がここで証明しようとしたことを読むべきでしたが、(あなたがどう思おうと、それを証明したのです)。
ただし、ソースコードがあっても何もわからないことに注意してください。累積の複雑さは同じではない。出典を分析しても、「まあ、そこにある何かが呼ばれている、何かがカウントされている、何かがどこからか引用されている、でも具体的に何がそうなのかはっきりしない、だからまた何も証明されない」と言うでしょう。
一般的には、そうですね、おそらく個々の機能ではあまりわからないでしょう。 自分のソフトが他の人にとって豚のようなものであれば、何のために話すのか。
実際、私たちが関心を持つのは、仮想メソッドを通過した回数と、それに費やした時間の合計です。 この表には、500万回実行された陰影付きの関数がありますね。なんだかよくわからないけど、一番シンプルな動作でバーチャルな方法なのかもしれない。 しかし、500万は些細なことだ。あなたのプログラムでは重い計算はしていないでしょうから、特に議論することはないでしょう。 仮に30000x300000の連立一次方程式の計算をして、仮想メソッドで行列要素にアクセスしていたとしたら、何か話があるはずです。
新しい自己暗示の方法?早く、早く
Vasily、あなたは結局、私がここで証明しようとしたことを読むべきです(そして、あなたがそれについて考えるものは何でも、それを証明しました)。
ドミトリー、私はあなたに賛成でも反対でもない。それを理解するためには、コンパイラの内部構造をインラインで知る必要があるが、この情報をMQ用に公開することは、デコンパイラを書くのを手伝うに等しい。
ここで議論している人の中で、そのような情報を持っているのはレナートだけなので、彼の言葉を信じるしかないのです。他に方法はないと思います。
もし彼が「テストの設定が間違っている」と言うなら、おそらくそうなのでしょう。
質問が違う、このような場合に正しくテストを設定できるのはMQだけである、それが必要なのだ。
テストにはテストを、私の言葉にはあなたの言葉を、と言われるように。そして、あなたは証明不可能なことを証明しようとしている。比較するものがなければ、自分の主張を証明することも反証することもできません。
ここでデコンパイルは論外です。
ただ、残酷なまでに最適化され、線形コードに退化した単純化されたケースをテストしないよう、最適化コンパイラのテクニックを理解し、知る必要があるのです。何もしないで第4世代のコンパイラをリリースしました。
まさにその通りです。
例えば、30000x300000の連立一次方程式の計算をしていて、行列要素へのアクセスが仮想メソッドであった場合、すでに何か話があるはずです。
そのような場合、最初のリファクタリングで100倍のスピードアップを図ることができる。そして、バーチャルコールはコスト面では10位となる。
つまり、この例は非現実的なのです。
じゃあ、全部アセンブリ言語で書こうよ。どうせなら、そのほうが早い。
問題がよくわからない。1MBのコードを持つExpert Advisorやインジケータを見たことがない。
また、関数の呼び出しにもある程度の時間がかかる。機能も捨てよう
大規模なプロジェクトのコントロールは、OOPでより便利になりました。
また、コードの実行速度は、ブローカーへのping送信 時間やブローカーからの注文に対するレスポンスほど重要でないことが非常に多いのです。
HFTのアルゴリズムをチェックする。最高速度が要求されますが、そこには複雑な計算は見当たりません。
PS.A地点からB地点に移動するのに、普通はスーパーカーやスノーモービルは必要ありません。原付で十分です!