同じ動作をさせる条件において、多くの "or"(|)を避けることは可能でしょうか? - ページ 6 12345678910 新しいコメント Boris 2013.02.11 17:05 #51 Meat: borilunad 関数呼び出しは、不必要なブレーキをかけることになります。したがって、最高速度を求めるのであれば、一文字の演算を行う Request() はすべて取り除くべきです。 ループについても同様です。 ループ内での条件チェックは、単に if() をネストしたものよりも常にはるかに遅くなります。 だから、互いに排他的な条件でも、if(A || B || C || D)アクションを使えばよくなるのです。 でも、その条件に含まれる、その時点で多くのデータをチェックする必要があるので、関数呼び出しは避けられないんです。 実験を続けることで、もしかしたら何か得られるかもしれない。しかし、拡散はどうしようもない!:) Alexey Navoykov 2013.02.11 21:23 #52 一般的には、一番早い選択肢はこれでしょう。bool result; if (A) result=true; else if (B) result=true; else if (C) result=true; else if (D) result=true; else result=false; if (result) Action(); ただし、else result=falseの行は、最初の行と組み合わせた方が、速度に影響しない。一般に、A、B、C、Dに単純な条件(すべての数学関数などを呼び出さず、最小限の演算で済む)が含まれていれば、このような最適化による性能向上はあまり期待できません(もちろん、この構造が何千万回と実行されない限り)。 しかしコードのオーバーロードは大きな意味を持つ場合があるのです。私は、あるスレッドで、すべては合理的に処理されなければならないと書きました。 なぜか、あなたのコードは、より重要な場所に満ちているようです。 最適化は、本当に大きな性能向上を与えるでしょう。 あなたは、基本アルゴリズムから始めるべきです。 ほとんどの初心者は、TSまたはオープンオーダーに関するすべての条件を毎ティックで チェックするのがばかばかしいです。しかし、ほとんどの場合、例えば、高値や安値がある値に達したときや、新しいバーが現れたときなど、境界条件だけをチェックすれば十分です。 その後で、さらにチェックを行うことができます。まあ、リソースを大量に消費する計算の他は、これらの計算をDLLに移行することを考える必要がありますね。そうでなければ、クソMQL4で13分も待たされるのは(2~3分で同じ結果が得られるのに)不幸なことだと思います :) Алексей Тарабанов 2013.02.11 21:42 #53 Meat: 一般的には、一番早い選択肢はこれでしょう。 ただし、else result=falseの行は、最初の行と組み合わせた方が、速度に影響しない。一般に、A、B、C、Dに単純な条件(すべての数学関数などを呼び出さず、最小限の演算で済む)が含まれていれば、このような最適化による性能向上はあまり期待できません(もちろん、この構造が何千万回と実行されない限り)。 しかしコードのオーバーロードは大きな意味を持つ場合があるのです。 私は、あるスレッドで、すべては合理的に処理されなければならないと書きました。 なぜか、あなたのコードは、より重要な場所に満ちているようです。 最適化は、本当に大きな性能向上を与えるでしょう。 あなたは、基本アルゴリズムから始めるべきです。 ほとんどの初心者は、TSまたはオープンオーダーに関するすべての条件を毎ティックでチェックするのがばかばかしいです。しかし、ほとんどの場合、例えば、高値や安値がある値に達したときや、新しいバーが現れたときなど、境界条件だけをチェックすれば十分です。 その後で、さらにチェックを行うことができます。 まあ、リソースを大量に消費する計算の他は、これらの計算をDLLに移行することを考える必要がありますね。そうでなければ、クソMQL4で13分も待たされるのは(2~3分で同じ結果が得られるのに)不幸なことだと思います :) 最速のオプションはパコが提案した Alexey Navoykov 2013.02.11 22:12 #54 tara: 最速のオプションはパコが提案した 複数の値を毎回合計する(つまり余分な算術演算を 行う)方が本当に速いと思いますか? 私の変種では、チェックは最初のマッチで終了しますが、あなたが言った変種では - すべての値を合計してから、その合計をチェックするのです。 しかも、その場合、すべての条件を事前に計算する必要があります。では、ここで言うスピードとは、どのようなものなのでしょうか。最も遅いオプションです。 Alexandr Krivoshey 2013.02.12 02:04 #55 とswitch - caseは良くないのでしょうか? Avals 2013.02.12 03:21 #56 高速化したい場合は、ビット演算を 試すとよいでしょう。つまり、すべての変数をint型(false=0)にする。次に、ビット単位のA|B|C...>0 Alexey Navoykov 2013.02.12 04:45 #57 Avals: 高速化したい場合は、ビット演算を試すとよいでしょう。 つまり、すべての変数をint型(false=0)にする。次に、ビット単位のA|B|C...>0 和算と同じように、すべての条件を事前に計算する必要があります。 また、1つの条件だけで十分なのに、なぜすべての条件を計算する必要があるのでしょう? Victor Nikolaev 2013.02.12 04:45 #58 そして、提案されたバリアントを誰も実行速度でチェックしないのですか?ここから スクリプトを使用することができます Igor Chemodanov 2013.02.12 05:12 #59 Meat: 一般的には、一番早い選択肢はこれでしょう。 ただし、else result=falseの行は、最初の行と組み合わせた方が、速度に影響しない。一般に、A、B、C、Dに単純な条件(すべての数学関数などを呼び出さず、最小限の演算で済む)が含まれていれば、このような最適化による性能向上はあまり期待できません(もちろん、この構造が何千万回と実行されない限り)。 しかしコードのオーバーロードは大きな意味を持つ場合があるのです。 私は、あるスレッドで、すべては合理的に処理されなければならないと書きました。 なぜか、あなたのコードは、より重要な場所に満ちているようです。 最適化は、本当に大きな性能向上を与えるでしょう。 あなたは、基本アルゴリズムから始めるべきです。 ほとんどの初心者は、TSまたはオープンオーダーに関するすべての条件を毎ティックでチェックするのがばかばかしいです。しかし、ほとんどの場合、例えば、高値や安値がある値に達したときや、新しいバーが現れたときなど、境界条件だけをチェックすれば十分です。 その後で、さらにチェックを行うことができます。 まあ、リソースを大量に消費する計算の他は、これらの計算をDLLに移行することを考える必要がありますね。そうでなければ、クソMQL4で13分間座って待つのは残念なことです(2~3分で同じ結果が出るかもしれませんが)。 if (A) Action(); else if (B) Action(); else if (C) Action(); else if (D) Action(); その方がさらに速いんです。ある話を思い出した。"ある会社の役員会で、2つの質問があった。1.シンクロファソトロンの建設が決定。2.従業員用自転車駐車場の建設を決定。最初の課題では、1分間のディスカッションが行われました。2回目には、2時間以上の討論が行われました。 Рустам 2013.02.12 07:08 #60 クソMQL4」が嫌な奴は逃げた方がいい、逃げた方が。というのも、彼がここで何をしているのかが不明だからである。 12345678910 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
borilunad 関数呼び出しは、不必要なブレーキをかけることになります。したがって、最高速度を求めるのであれば、一文字の演算を行う Request() はすべて取り除くべきです。 ループについても同様です。 ループ内での条件チェックは、単に if() をネストしたものよりも常にはるかに遅くなります。
だから、互いに排他的な条件でも、if(A || B || C || D)アクションを使えばよくなるのです。
でも、その条件に含まれる、その時点で多くのデータをチェックする必要があるので、関数呼び出しは避けられないんです。
実験を続けることで、もしかしたら何か得られるかもしれない。しかし、拡散はどうしようもない!:)
ただし、else result=falseの行は、最初の行と組み合わせた方が、速度に影響しない。一般に、A、B、C、Dに単純な条件(すべての数学関数などを呼び出さず、最小限の演算で済む)が含まれていれば、このような最適化による性能向上はあまり期待できません(もちろん、この構造が何千万回と実行されない限り)。 しかしコードのオーバーロードは大きな意味を持つ場合があるのです。
私は、あるスレッドで、すべては合理的に処理されなければならないと書きました。 なぜか、あなたのコードは、より重要な場所に満ちているようです。 最適化は、本当に大きな性能向上を与えるでしょう。 あなたは、基本アルゴリズムから始めるべきです。 ほとんどの初心者は、TSまたはオープンオーダーに関するすべての条件を毎ティックで チェックするのがばかばかしいです。しかし、ほとんどの場合、例えば、高値や安値がある値に達したときや、新しいバーが現れたときなど、境界条件だけをチェックすれば十分です。 その後で、さらにチェックを行うことができます。
まあ、リソースを大量に消費する計算の他は、これらの計算をDLLに移行することを考える必要がありますね。そうでなければ、クソMQL4で13分も待たされるのは(2~3分で同じ結果が得られるのに)不幸なことだと思います :)
一般的には、一番早い選択肢はこれでしょう。
ただし、else result=falseの行は、最初の行と組み合わせた方が、速度に影響しない。一般に、A、B、C、Dに単純な条件(すべての数学関数などを呼び出さず、最小限の演算で済む)が含まれていれば、このような最適化による性能向上はあまり期待できません(もちろん、この構造が何千万回と実行されない限り)。 しかしコードのオーバーロードは大きな意味を持つ場合があるのです。
私は、あるスレッドで、すべては合理的に処理されなければならないと書きました。 なぜか、あなたのコードは、より重要な場所に満ちているようです。 最適化は、本当に大きな性能向上を与えるでしょう。 あなたは、基本アルゴリズムから始めるべきです。 ほとんどの初心者は、TSまたはオープンオーダーに関するすべての条件を毎ティックでチェックするのがばかばかしいです。しかし、ほとんどの場合、例えば、高値や安値がある値に達したときや、新しいバーが現れたときなど、境界条件だけをチェックすれば十分です。 その後で、さらにチェックを行うことができます。
まあ、リソースを大量に消費する計算の他は、これらの計算をDLLに移行することを考える必要がありますね。そうでなければ、クソMQL4で13分も待たされるのは(2~3分で同じ結果が得られるのに)不幸なことだと思います :)
最速のオプションはパコが提案した
複数の値を毎回合計する(つまり余分な算術演算を 行う)方が本当に速いと思いますか? 私の変種では、チェックは最初のマッチで終了しますが、あなたが言った変種では - すべての値を合計してから、その合計をチェックするのです。
しかも、その場合、すべての条件を事前に計算する必要があります。では、ここで言うスピードとは、どのようなものなのでしょうか。最も遅いオプションです。
高速化したい場合は、ビット演算を 試すとよいでしょう。
つまり、すべての変数をint型(false=0)にする。次に、ビット単位のA|B|C...>0
高速化したい場合は、ビット演算を試すとよいでしょう。
つまり、すべての変数をint型(false=0)にする。次に、ビット単位のA|B|C...>0
そして、提案されたバリアントを誰も実行速度でチェックしないのですか?
ここから スクリプトを使用することができます
一般的には、一番早い選択肢はこれでしょう。
ただし、else result=falseの行は、最初の行と組み合わせた方が、速度に影響しない。一般に、A、B、C、Dに単純な条件(すべての数学関数などを呼び出さず、最小限の演算で済む)が含まれていれば、このような最適化による性能向上はあまり期待できません(もちろん、この構造が何千万回と実行されない限り)。 しかしコードのオーバーロードは大きな意味を持つ場合があるのです。
私は、あるスレッドで、すべては合理的に処理されなければならないと書きました。 なぜか、あなたのコードは、より重要な場所に満ちているようです。 最適化は、本当に大きな性能向上を与えるでしょう。 あなたは、基本アルゴリズムから始めるべきです。 ほとんどの初心者は、TSまたはオープンオーダーに関するすべての条件を毎ティックでチェックするのがばかばかしいです。しかし、ほとんどの場合、例えば、高値や安値がある値に達したときや、新しいバーが現れたときなど、境界条件だけをチェックすれば十分です。 その後で、さらにチェックを行うことができます。
まあ、リソースを大量に消費する計算の他は、これらの計算をDLLに移行することを考える必要がありますね。そうでなければ、クソMQL4で13分間座って待つのは残念なことです(2~3分で同じ結果が出るかもしれませんが)。
その方がさらに速いんです。
ある話を思い出した。
"ある会社の役員会で、2つの質問があった。
1.シンクロファソトロンの建設が決定。
2.従業員用自転車駐車場の建設を決定。
最初の課題では、1分間のディスカッションが行われました。
2回目には、2時間以上の討論が行われました。