エラー、バグ、質問 - ページ 1952

新しいコメント
 
Stanislav Korotky:

コンパイラは、ここでは役に立ちません - テスト - 戻り値のローカルオブジェクトが複製され、その後釘付けになります。この場合、最適な手はありません。


スピードテストは実施されましたか？それともオブジェクト生成の 診断だけ？もし2番目なら、もちろんコードから何も削除されません。なぜなら、あなた自身がチェックでこれを防いでいるからです。

 
Alexey Navoykov:


スピードテストは実施されましたか？それとも、オブジェクト 作成の事実を診断しているだけなのでしょうか？後者であれば、あなた自身がチェックで防いでいるのですから、もちろん何も削られることはないでしょう。

どうですか？私のチェックは、コンストラクタとデストラクタに設定されたトレースのみで構成されています。余分なコピーが作成され、削除されるのであれば、それは最適化が行われていないことの十分な証明になります。

 
Alexey Navoykov:


速度測定テストは実施されましたか？それとも、オブジェクト 作成の事実を診断しているだけ？2番目の場合は、もちろん何も切り取られません。あなた自身がチェックでこれを防いでいるからです。

まあ、線が動かせないと、もっと複雑な物も動かせませんからね。

 
Stanislav Korotky:

どうですか？私のチェックは、コンストラクタとデストラクタに設定されたトレースのみで構成されています。もし、余分なコピーが作成され、削除されるのであれば、それは最適化されていないことの十分な証拠になると思います。

オプティマイザは、あなたのトレースを含むフラグメントを引き裂くことはできない)。ロジックに影響を与えないものだけを切り取ることができます。
 

OnTesterInitで、各入力パラメータに最適化範囲を設定できるようになりました。そして、テスターは自らパステーブルを生成し、Agent/Packageの数に分割してAgentに送ります。このテーブルは、現在、いかなる方法でも編集することはできません。

しかし、最適化においては、まず重要なパラメータを変更し、次に別のパラメータを変更する、といったパスを気にすることは、実はよくあることです。もし、生成されたパスのテーブルを編集（要素（入力パラメータのセット）の場所を変更）したり、自分で生成したりすることが可能であれば、最も興味深いパスが最初にAgentsに行き、次にあまり関心のないパスが行くように、必要な優先度を設定することができるだろう。


そこで、OnTesterInitにデフォルトのパステーブルを変更する機能を追加することを提案します。

long PassesTotal(); // количество проходов в таблице для Оптимизации

// Получает список входных параметров соответствующего прохода
int PassesGet( const int Index,  MqlParam& Parameters[] );


// Прописывает список входных параметров для соответствующего прохода,
// если индекс не меньше размера таблицы, то идет дозапись в конец таблицы и размер ее увеличивается на единицу
int PassesSet( const int Index, const MqlParam& Parameters[] );
 
Alexey Navoykov:
オプティマイザーは、あなたのトレースを含むセクションをカットすることができません )作品のロジックに影響を与えないものしか切り出せないのです。

さて、話題は終わり;-)。この場合の最適化は、戻り値が 発生するそのコードの場所だけで起こりうるものであり、決してコンストラクタに書かれていることに依存するものではないと思います。

C++11 標準： 特定の条件を満たす場合、そのオブジェクトのコピー/移動コンストラクタやデストラクタに副作用があっても、クラス オブジェクトのコピー/移動構築を省略する実装が許可されます。このような場合、実装では、省略されたコピー/移動操作のソースとターゲットを、単に同じオブジェクトを参照する2つの異なる方法として扱い、そのオブジェクトの破壊は、最適化がなければ2つのオブジェクトが破壊されたであろう時間のうち遅い方に発生します。

 
Stanislav Korotky:

さて、話題は終わり;-)。私の考えでは、この場合の最適化は、値を返す コードの場所でのみ行われる可能性があり、コンストラクタに書かれている内容には一切関係ありません。

とにかく、MQLコンパイラは、私が思っていたほど賢いとは言い難いというのが残念です )簡単な例を作ってみたところ、どこにも使われない、何もしないダミーオブジェクトを作っても、コンパイラはそれを気にしないことが判明しました。全く最適化されていない。スピードだけで判断しています。そして、なぜか新しいビルドでは古いビルドより動作が遅くなる。

以下は、簡単なコードです。

class A { };

void OnStart()
  {
    uint starttick= GetTickCount();
    for (int i=0; i<1 e8; i++)
    { 
      A a;
    }
    Print(GetTickCount()-starttick," ms");
  }
 
Alexey Navoykov:

MQLコンパイラは、私が思っていたほど賢くないということを、残念ながら認めざるを得ません )全くスマートでないとさえ言える)


何もないところから作られたナンセンスなものではなく、多くの人が使う本物のものを最適化するようにチューニングできないか、と考えたことはありますか？

 
Stanislav Korotky:

さて、話題は終わり;-)。私見では、この場合の最適化は、値を返す コードの場所でのみ行われ、コンストラクタに書かれた内容には一切依存しないと思います。


コピーコンストラクタが導入されたのは2年後です。
RVO（戻り値最適化）、NRVO（名前付き戻り値最適化）の次は...。

 
Sergey Dzyublik:

薄利多売のデタラメではなく、多くの人が使う本物を最適化するために研ぎ澄まされるかもしれないと考えたことはありますか？

多くの人が使っている本当のもの」とは何でしょうか？
1...194519461947194819491950195119521953195419551956195719581959...3185
新しいコメント
理由: