AMDまたはIntel、およびメモリブランド - ページ 57 1...505152535455565758596061626364...94 新しいコメント Петр 2009.10.01 16:53 #561 joo >> : 特定のハードウェアでテスターがどの程度速く動作するかに興味があります。コードがシンプルであればあるほど、結果に対する影響力は小さくなります。通常のコンパイラでコンパイルしたコードをテスターがガリガリやっている。したがって、スクリプトであろうとExpert Advisorであろうと関係ないのです。しかし、Expert Advisorでは、理想的な条件を得ることはできないので、常に曖昧な部分があります。私の観点では、begemot61さんの提案は面白いですね。しかし、この場合でもExpert Advisorからインジケータを実行する必要はありません。インジケーター内部で時間を計測することができます。 私は、あるハードウェアでのスクリプトの動作速度にはあまり興味がないのです。最適化速度に興味があります。テストが実際のタスクに近ければ近いほど、テストにとっても私（ブタザウルス）にとっても良いのです。 曖昧さをなくすにはどうしたらいいか--解決策はある、それを示した。簡略版として提案されたものもOKです。cfc in」を測定するのとは対照的です。 Andrey Dik 2009.10.01 17:04 #562 オプティマイザーが「頭の中で取引する」というタスクの "現実 "とは？そして、微妙に異なる結果が得られるのは、まさにトレーディング機能なのです。では、なぜオプティマイザーをテストするときにそれらを適用するのでしょうか？ Петр 2009.10.01 17:08 #563 joo >> : オプティマイザーは「頭の中でトレードしている」わけですから、このトレードは「トレードしていない」機能と変わらない、普通の実行なのです。そして、微妙に異なる結果をもたらすのが、まさにトレーディング機能なのです。では、なぜオプティマイザーをテストするときにそれらを適用するのでしょうか？ なぜなら、実際の最適化と同じようにマシンリソースを利用することになるからです。スクリプトはその性質上、これを提供することはできません。また、ライブオプティマイザーを搭載したスクリプトで、シミュレーションによる最適化を考案するのはおかしいでしょう。 Andrey Dik 2009.10.01 17:16 #564 Svinozavr >> : なぜなら、本当の最適化と同じように、マシンリソースに負荷をかけるからです。台本は、その性質上、それができないのです。また、ライブオプティマイザーを搭載したスクリプトで、シミュレーションによる最適化を考案するのはおかしいでしょう。 スクリプトにこだわるのではなく、オプティマイザーをテストするためにはExpert Advisorで取引関数を削除しなければならない、ただそれだけのことなのです。このスレッドについてはモデレーターがすでに問い合わせをしているので、おそらく「オプティマイザにおけるトレーディング関数と非トレーディング関数の違いは、実行時間の面でどうなのか」という疑問を解消したいのだろう。 Петр 2009.10.01 17:20 #565 joo >> : スクリプトにこだわっているわけではなく、テスト用のExpert Advisorではオプティマイザを取引関数から外す必要がある、と言っているのですが、それだけです。モデレーターがこのスレッドに興味を持つ限り、もしかしたら「オプティマイザでトレーディング関数と非トレーディング関数は実行時にどのように異なるのか？ )))何のために支店に興味を持ったのだろう？自分たちも気になっている！？だから、それを明確にする必要がある)))。 冗談抜きで、最も一般的な考察によると、テストに貿易機能がないと、その有効性が低下します。影響を与えるか与えないかは、私たちが調べようとしていることではありません。 Belford 2009.10.01 17:22 #566 Mathemat >> : BelfordのPhenom IIは、スクリプト上ではCore 2 Duoの "blue "シリーズよりはるかにパフォーマンスが悪いが、最適化ではわずかに上回るという、非常に奇妙な挙動を示す。 むしろその逆 ...)) 44 ページで公称CPUモードでの結果を出しています。スクリプト44*2.8=123、EA150*2.8=420。 例：「青」Core 2 Duo E7200 - スクリプト117、Expert Advisor539の場合。 123-117=6 (5%未満、有意ではない) 539-420=119 (20%以上、最適化でPhenom IIが大幅に上回った) 削除済み 2009.10.01 17:30 #567 joo писал(а)>> 特定のハードウェアでテスターがどの程度速く 動作するかに興味があります。コードがシンプルであればあるほど、結果への影響は少なくなります。通常のコンパイラでコンパイルしたコードをテスターがガリガリやっている。したがって、スクリプトであるかExpert Advisorであるかは関係ない。しかし、Expert Advisorでは、理想的な条件を得ることはできないので、常に曖昧な部分があります。私の観点では、begemot61さんの 提案は面白いですね。しかし、この場合でもExpert Advisorからインジケータを実行する必要はありません。インジケーター内部で時間を計測することができます。 これは、特定のケースで結果に影響しないはずのものへの影響を最小限に抑えるために、異なる 合成ベンチマークを使用してハードウェアテストを行う目的です。メモリサブシステム、プロセッサ、バスなどをテストし、総合的な性能指標を導き出す。 トレーダーのマシンの本当の評価は、スクリプト、非トレーディングのExpert Advisors、指標など、いくつかのそのようなベンチマークを作成し、その後の最終的な評価の計算であろう。 ただ、なぜかいつも違うレビューでは、合成テストの結果は、より少ない部分しか書かれていないのです。そして、もっと大きいのは、常にリアルなプログラムのテストです。このようなプログラムのセットは様々ですが、必ず存在します。ちなみに、業界標準のSPECxxxは、合成テストではなく、REALプログラムのコードを混合して構成されています。また、ixbt.comでは合成樹脂の使用を一切拒否していますが、これはまさに玄人好みの馬だからです。 とてもシンプルなことを一つ理解してください。実際の性能テストでは、最新のプロセッサの能力とはかなりかけ離れたものが出てくるのが普通です。一方では前世代のプロセッサーよりもはるかに速く、他方ではさらに高速に動作させることができます。しかし、そのためのプログラムの限界最適化は非常に手間がかかり、（使用するアルゴリズムの関係で）不可能な場合が多いのです。つまり、どんな実際のテストでも、問題のプログラムの典型的な条件下でのプロセッサの性能を示している。つまり、さまざまなボトルネックの影響を見ることができるのです。そして、これらのボトルネックを解消することを提案されていますね。しかし、Expert Advisorを本当に最適化すれば、それらは再び現れるでしょう 削除済み 2009.10.01 17:43 #568 joo писал(а)>> 私はスクリプトにこだわっているのではなく、Expert Advisorでオプティマイザーをテストするために取引関数を削除する必要がある、と言っているのです。モデレーターはすでにこのスレッドに照会しているので、おそらく「オプティマイザーにおけるトレーディング関数と非トレーディング関数の実行時間の違いは何でしょうか？ ジュ 議論に人格を持ち込むべきではないと言われます。 しかし、この場合はこう見てはどうだろう。あなたは構造技術者ですから、強度計算と関係することについては何も反論するつもりはありません。数学についてMathematicsと 議論するつもりもない。また、このフォーラムでトレーディングについて直接話すことも、私の経験は微々たるものなので、できません。 しかし、プロセッサー（コンピューター全般）、その性能、その測定に関しては、私は反論します。私は「機械、複合体、システム、ネットワークの計算」を生業とする技術者だからです。というのも、私は常に、最も低いレベルでの仕組みに興味があるからです。そして、この分野では、どう考えても私が皆さんに一歩リードすることになります。 質問した内容も、一般的には答えがないため、意味がないのです。関数呼び出しから制御が戻るまでの時間は可変値です。つまり、ある特定の2つの関数であっても、一方が他方より速いという状況が起こりうるため、ほとんど比較できないのです。でも、関数の「クラス」全体を比較したいんですよね。 Eugene 2009.10.01 18:04 #569 Svinozavr >> : 私は、特定のハードウェアでスクリプトが動作する速度にはあまり興味がないんです。最適化速度に興味があります。そして、テストが本当の問題に近ければ近いほど、テストにとっても、私（ピッグザウルス）にとっても良いのです。 曖昧さをなくすにはどうしたらいいか--解決策はある、それを示した。簡略版として提案されたものもOKです。"sf.c.in "を測定するのとは対照的です。 私も、主に最適化のスピードに関心があります。トレーディング機能 他の機能と大きな違いはないと思うのですが。 他の機能と比較可能な呼称であること。ただ、中身がどうなっているのかはわかりません。 また、ログを取ることでどのように遅くなるのでしょうか？ ただ、スクリプトの場合は、何らかの理由で浮動小数点演算と整数演算を分けただけなんです。そして、それは誰も驚かなかった。 また、Expert Advisorでは、何かをしているが、それが何であるかには興味がない。なぜだろう？判断が難しいから？ Andrey Dik 2009.10.01 18:10 #570 begemot61 >> : 私も主に最適化のスピードに興味があります。トレーディング機能......他の機能と大きく異なる点はないかと思います。 他の機能と比較可能な呼称であること。ただ、中身がどうなっているのかはわかりません。 また、ログを取ることでどのように遅くなるのでしょうか？ ただ、スクリプトの場合は、何らかの理由で浮動小数点演算と整数演算を分けただけなんです。そして、それは誰も驚かなかった。 また、Expert Advisorでは、何かをしているが、それが何であるかには興味がない。なぜだろう？定義が難しいから？ そうですね、スクリプトの中では、せめてタスクを分離するように心がけました。しかし、提案されたExpert Advisorsでは、すべてが「山」になっているのです。メモリが冷えたからか、CPUの性能が上がったからか、バスが速くなったのか...このマシン、このマシンが速くなった理由を探ってみてください。 1...505152535455565758596061626364...94 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
特定のハードウェアでテスターがどの程度速く動作するかに興味があります。コードがシンプルであればあるほど、結果に対する影響力は小さくなります。通常のコンパイラでコンパイルしたコードをテスターがガリガリやっている。したがって、スクリプトであろうとExpert Advisorであろうと関係ないのです。しかし、Expert Advisorでは、理想的な条件を得ることはできないので、常に曖昧な部分があります。私の観点では、begemot61さんの提案は面白いですね。しかし、この場合でもExpert Advisorからインジケータを実行する必要はありません。インジケーター内部で時間を計測することができます。
私は、あるハードウェアでのスクリプトの動作速度にはあまり興味がないのです。最適化速度に興味があります。テストが実際のタスクに近ければ近いほど、テストにとっても私（ブタザウルス）にとっても良いのです。
曖昧さをなくすにはどうしたらいいか--解決策はある、それを示した。簡略版として提案されたものもOKです。cfc in」を測定するのとは対照的です。
オプティマイザーは「頭の中でトレードしている」わけですから、このトレードは「トレードしていない」機能と変わらない、普通の実行なのです。そして、微妙に異なる結果をもたらすのが、まさにトレーディング機能なのです。では、なぜオプティマイザーをテストするときにそれらを適用するのでしょうか？
なぜなら、実際の最適化と同じようにマシンリソースを利用することになるからです。スクリプトはその性質上、これを提供することはできません。また、ライブオプティマイザーを搭載したスクリプトで、シミュレーションによる最適化を考案するのはおかしいでしょう。
なぜなら、本当の最適化と同じように、マシンリソースに負荷をかけるからです。台本は、その性質上、それができないのです。また、ライブオプティマイザーを搭載したスクリプトで、シミュレーションによる最適化を考案するのはおかしいでしょう。
スクリプトにこだわるのではなく、オプティマイザーをテストするためにはExpert Advisorで取引関数を削除しなければならない、ただそれだけのことなのです。このスレッドについてはモデレーターがすでに問い合わせをしているので、おそらく「オプティマイザにおけるトレーディング関数と非トレーディング関数の違いは、実行時間の面でどうなのか」という疑問を解消したいのだろう。
スクリプトにこだわっているわけではなく、テスト用のExpert Advisorではオプティマイザを取引関数から外す必要がある、と言っているのですが、それだけです。モデレーターがこのスレッドに興味を持つ限り、もしかしたら「オプティマイザでトレーディング関数と非トレーディング関数は実行時にどのように異なるのか？
)))何のために支店に興味を持ったのだろう？自分たちも気になっている！？だから、それを明確にする必要がある)))。
冗談抜きで、最も一般的な考察によると、テストに貿易機能がないと、その有効性が低下します。影響を与えるか与えないかは、私たちが調べようとしていることではありません。
BelfordのPhenom IIは、スクリプト上ではCore 2 Duoの "blue "シリーズよりはるかにパフォーマンスが悪いが、最適化ではわずかに上回るという、非常に奇妙な挙動を示す。
むしろその逆 ...))
44 ページで公称CPUモードでの結果を出しています。スクリプト44*2.8=123、EA150*2.8=420。
例：「青」Core 2 Duo E7200 - スクリプト117、Expert Advisor539の場合。
123-117=6 (5%未満、有意ではない)
539-420=119 (20%以上、最適化でPhenom IIが大幅に上回った)
特定のハードウェアでテスターがどの程度速く 動作するかに興味があります。コードがシンプルであればあるほど、結果への影響は少なくなります。通常のコンパイラでコンパイルしたコードをテスターがガリガリやっている。したがって、スクリプトであるかExpert Advisorであるかは関係ない。しかし、Expert Advisorでは、理想的な条件を得ることはできないので、常に曖昧な部分があります。私の観点では、begemot61さんの 提案は面白いですね。しかし、この場合でもExpert Advisorからインジケータを実行する必要はありません。インジケーター内部で時間を計測することができます。
これは、特定のケースで結果に影響しないはずのものへの影響を最小限に抑えるために、異なる 合成ベンチマークを使用してハードウェアテストを行う目的です。メモリサブシステム、プロセッサ、バスなどをテストし、総合的な性能指標を導き出す。
トレーダーのマシンの本当の評価は、スクリプト、非トレーディングのExpert Advisors、指標など、いくつかのそのようなベンチマークを作成し、その後の最終的な評価の計算であろう。
ただ、なぜかいつも違うレビューでは、合成テストの結果は、より少ない部分しか書かれていないのです。そして、もっと大きいのは、常にリアルなプログラムのテストです。このようなプログラムのセットは様々ですが、必ず存在します。ちなみに、業界標準のSPECxxxは、合成テストではなく、REALプログラムのコードを混合して構成されています。また、ixbt.comでは合成樹脂の使用を一切拒否していますが、これはまさに玄人好みの馬だからです。
とてもシンプルなことを一つ理解してください。実際の性能テストでは、最新のプロセッサの能力とはかなりかけ離れたものが出てくるのが普通です。一方では前世代のプロセッサーよりもはるかに速く、他方ではさらに高速に動作させることができます。しかし、そのためのプログラムの限界最適化は非常に手間がかかり、（使用するアルゴリズムの関係で）不可能な場合が多いのです。つまり、どんな実際のテストでも、問題のプログラムの典型的な条件下でのプロセッサの性能を示している。つまり、さまざまなボトルネックの影響を見ることができるのです。そして、これらのボトルネックを解消することを提案されていますね。しかし、Expert Advisorを本当に最適化すれば、それらは再び現れるでしょう
私はスクリプトにこだわっているのではなく、Expert Advisorでオプティマイザーをテストするために取引関数を削除する必要がある、と言っているのです。モデレーターはすでにこのスレッドに照会しているので、おそらく「オプティマイザーにおけるトレーディング関数と非トレーディング関数の実行時間の違いは何でしょうか？
ジュ 議論に人格を持ち込むべきではないと言われます。
しかし、この場合はこう見てはどうだろう。あなたは構造技術者ですから、強度計算と関係することについては何も反論するつもりはありません。数学についてMathematicsと 議論するつもりもない。また、このフォーラムでトレーディングについて直接話すことも、私の経験は微々たるものなので、できません。
しかし、プロセッサー（コンピューター全般）、その性能、その測定に関しては、私は反論します。私は「機械、複合体、システム、ネットワークの計算」を生業とする技術者だからです。というのも、私は常に、最も低いレベルでの仕組みに興味があるからです。そして、この分野では、どう考えても私が皆さんに一歩リードすることになります。
質問した内容も、一般的には答えがないため、意味がないのです。関数呼び出しから制御が戻るまでの時間は可変値です。つまり、ある特定の2つの関数であっても、一方が他方より速いという状況が起こりうるため、ほとんど比較できないのです。でも、関数の「クラス」全体を比較したいんですよね。
私は、特定のハードウェアでスクリプトが動作する速度にはあまり興味がないんです。最適化速度に興味があります。そして、テストが本当の問題に近ければ近いほど、テストにとっても、私（ピッグザウルス）にとっても良いのです。
曖昧さをなくすにはどうしたらいいか--解決策はある、それを示した。簡略版として提案されたものもOKです。"sf.c.in "を測定するのとは対照的です。
私も、主に最適化のスピードに関心があります。トレーディング機能 他の機能と大きな違いはないと思うのですが。
他の機能と比較可能な呼称であること。ただ、中身がどうなっているのかはわかりません。
また、ログを取ることでどのように遅くなるのでしょうか？
ただ、スクリプトの場合は、何らかの理由で浮動小数点演算と整数演算を分けただけなんです。そして、それは誰も驚かなかった。
また、Expert Advisorでは、何かをしているが、それが何であるかには興味がない。なぜだろう？判断が難しいから？
私も主に最適化のスピードに興味があります。トレーディング機能......他の機能と大きく異なる点はないかと思います。
他の機能と比較可能な呼称であること。ただ、中身がどうなっているのかはわかりません。
また、ログを取ることでどのように遅くなるのでしょうか？
ただ、スクリプトの場合は、何らかの理由で浮動小数点演算と整数演算を分けただけなんです。そして、それは誰も驚かなかった。
また、Expert Advisorでは、何かをしているが、それが何であるかには興味がない。なぜだろう？定義が難しいから？
そうですね、スクリプトの中では、せめてタスクを分離するように心がけました。しかし、提案されたExpert Advisorsでは、すべてが「山」になっているのです。メモリが冷えたからか、CPUの性能が上がったからか、バスが速くなったのか...このマシン、このマシンが速くなった理由を探ってみてください。