エラー、バグ、質問 - ページ 1573 1...156615671568156915701571157215731574157515761577157815791580...3185 新しいコメント Alexey Navoykov 2016.05.06 13:02 #15721 Anton Zverev:100Kbのソースプロジェクトは、1325ビルドで1秒以内にコンパイルされます。堅実なOOP、多くの仮想関数と オーバーロード、テンプレート、ポインタ、(可能な限り)const修飾子。DLLとOpenCLはありません。ラグの原因を突き止めたい。コンパイラが早く最適化できるようにするための制約なのかもしれませんね。ラグに遭遇したことは一度もありません。遅くなるkodobaseのソースコードを提供してください。まあ、100Kbは多すぎですよね。 私は1Mbyte近くあります。 あなたと同じものが全部入っている上に、マクロがたくさん入っています。ただし、constがどこにでも設定されているわけではありません。 しかし、特にビルド1159ではすべてがほとんど瞬時にコンパイルされたので、このような異常な遅延の理由にはなりません。ビルド1325では、プロジェクトが全くコンパイルされず、バグが一杯出てくるので、夕方にはテストできません。 同志A100も新しいビルドで一杯バグを報告しています。 私はこれらのバグをつつくのに時間を浪費する気はないので、彼らが作業ビルドをリリースするまで待つつもりです。そのため、ビルド1241を参考にラグについてお伝えしました。 もしテストする機会があれば、最新のビルドと比較してみてください。 しかし、新しいビルドで大幅にスピードアップできるかどうかは疑問です。それどころか、MTの開発者は、コンパイル速度など気にしていません。彼らは、ランタイムからナノ秒を追加して、MQLプログラムの速度がC++と同等であると宣伝したいだけです(ただし、いくつかの抽象例においてのみですが)。私が理解する限り、彼らは最適化効率、つまりコストに見合ったゲームかどうかは気にしていないようです。また、このプロジェクトは大規模なものであり、小規模なものはほとんど公開されていません。 Alexey Navoykov 2016.05.06 13:56 #15722 Renat Fatkhullin:おそらく彼は、テキストのスプールという形で巨大な機能をもっているのだろう。オプティマイザは、このようなコード断片を何度も通過させ、何度もコードを改善しなければならない。オプティマイザは関数のサイズを小さくするだけで、劇的に速度が向上するのです。 最新のビルドは、品質とスピードの両方を常に向上させているので、最新のビルドに切り替える必要があります。巨大な関数はありません。せいぜい150行です(巨大といえるでしょうか)。 また、こう考えてみると、なぜ関数の大きさとコンパイラが小さな関数をたくさん試したことが関係あるのでしょうか。 大きな関数を10回試したとしましょう。しかし、大きな関数を分割することで結果が多少速くなったとしても、コンパイルは10倍(!)遅くなるのです。そして、言語を複雑にすればするほど、このパスが長くなり、プログラマーの時間を消費することになります。また、最適化によってプログラムがどれだけ速くなったか、最適化が完了するまでのプログラマのアイドルタイムと比べて、効率はどうなのか、という当然の疑問があります。もちろん、妥協点を探すこともできますが、上に書いたように異なるコンパイルモードを作る方がはるかに効率的です。 最適化を施したプログラムリリースは最後の最後にしか必要ありません。プログラマの時間の99%は、最適化を全く必要としないコードを書いたりデバッグすることに費やされています。 Vasiliy Sokolov 2016.05.06 14:06 #15723 Alexey Navoykov:ビルドアップデートのたびにコードがコンパイルできなくなるなんて、いつまで続くんだ! しかも、コンパイルできたとしても、以前と同じようには動かない(もっとひどい)。 こんなプログラミング言語、誰が必要とするんだ?... 意味がわからないんですけど。私は、MQLで2万行以上のコードを持つ非常に複雑なプロジェクトを いくつか持っています。新しいビルドは、あっという間にコンパイルされるかもしれません。その間、問題は2つしかありませんでした。一度は私のバグが原因で、もう一度は開発者のバグが原因です。 Vasiliy Sokolov 2016.05.06 14:07 #15724 Alexey Navoykov:最大150行まで これは非常に大きく、誤った機能です。 Alexey Navoykov 2016.05.06 14:21 #15725 Vasiliy Sokolov: 意味がわからないんですけど。私は、MQLで2万行を超える非常に複雑なプロジェクトをいくつも抱えています。新しいビルドは、あっという間にコンパイルされます。その間、問題は2つしかありませんでした。一度は私のバグが原因で、もう一度は開発者のバグが原因です。それなら、ラッキーですね。あなたのコードには、私のコードにあるような構成要素はありません。 何がそんなにおかしいのでしょうか?上の人を2、3ページめくってみて、そこで彼は新しいビルドのバグもたくさん捕まえていて、中には捕まえにくいものもあります。 彼がわざと探していたとでもいうのでしょうか? Renat Fatkhullin 2016.05.06 14:29 #15726 Alexey Navoykov:それなら、ラッキーですね。あなたのコードには、私のコードにあるような構成要素はありません。 何がそんなにおかしいのでしょうか?上のページをいくつかめくってみてください。そこにいる男性も、新しいビルドのバグをたくさん捕まえています。 中には、なかなか捕まえられないバグもあります。 わざと探していたと思いますか?リプレイブルブレーキの例を示してください。残念ながら、今のところ、開発者への直接攻撃など、根拠のない発言をしていますね。機能の大きさやプログラム全体の大きさについて、あなたは間違っています。個々の関数のサイズは、構文木の増加とマルチパス最適化の両方により、各特定関数の最適化に直接かつ非線形に影響する。小さな機能はその場で最適化されます。 Vasiliy Sokolov 2016.05.06 14:34 #15727 Alexey Navoykov:それなら、ラッキーですね。あなたのコードには、私のコードにあるような構成要素はありません。 何がそんなにおかしいのでしょうか?上のページをめくってみてください。そこにいる男性も、新しいビルドのバグをたくさん捕まえています。中には、なかなか捕まえられないバグもあります。 わざと探していたのでしょうか?1) 私のコードに含まれていない、どのような構成要素を使用したのでしょうか。私のコードのサイズは何千行にもなるのに、あなたのコンストラクトは存在しないのですか?きっと、超ユニークなものに違いない?2) 実は、前回のビルドで、クラス同士がリンクする際に発生する内部コンパイラーエラーがありました。開発者のバグでしたが、修正されました。それ以外のエラーは思い出せません。 A100 2016.05.06 14:49 #15728 Vasiliy Sokolov:2) 実は、以前のビルドでは、クラス同士がリンクする際に発生する内部コンパイラーエラーがありました。これは開発チームのバグですが、修正されました。それ以外のエラーは思い出せません。https://www.mql5.com/ru/forum/1111/page1591#comment_2463820また、クラス同士の相互リンクはどこにあるのでしょうか?ここでは、相互参照先を検索したり、使っていないコンストラクトを理解したりするのに便利なように、さらに簡略化しています Ошибки, баги, вопросы www.mql5.com Форум трейдеров ファイル: Test114.mq5 2 kb Vasiliy Sokolov 2016.05.06 15:19 #15729 A100:https://www.mql5.com/ru/forum/1111/page1591#comment_2463820また、ここでクラス同士の相互参照はどこにあるのでしょうか?ここでは、相互参照先を検索しやすくするため、また、どの構成要素が使われていないかを理解しやすくするために、さらに簡略化しました。リバースエンジニアリングをしているのですね。コンパイラの改良には役立つが、実用的なプログラミングという点では応用が利かない。あなたが引用したコードを実際に使うプログラマーを私は一人も知りません。//+------------------------------------------------------------------+ //| Test116.mq5 | //| | //+------------------------------------------------------------------+ bool is( const string type, bool ) { return ( type == "1" || type == "2" || type == "3" || type == NULL ); } bool _is( string type ) { return is( type, false ); } //+------------------------------------------------------------------+ template<typename T> bool __is( T ) { return _is( typename( T )); } //+------------------------------------------------------------------+ #define IS( T ) __is( T(0)) //+------------------------------------------------------------------+ template<typename T> int sh( T t ) { T tt = 0x1; for ( int i = 0; i < 4; i++, tt <<= 1 ) if ( (t & tt) == tt ) return i; return -1; } //+------------------------------------------------------------------+ class D { public: template<typename T1, typename T2> T2 g( T1 t1, T2, int sh = -1 ); }; template<typename T1, typename T2> T2 D::g( T1 t1, T2, int sh ) { sh = sh( t1 ); T2 t2 = T2(t1) >> 1; return (sh( t1 ) & sh) == sh( t1 ) && IS( T2 ) ? 1 : 0; } //+------------------------------------------------------------------+ class M : public D { virtual void f1() { g( 0, 0 ); } }; //+------------------------------------------------------------------+ class A {}; void g( A* ) export {} class B { public: void h() { A a; g( &a ); } }; class C { public: void f() {} }; void OnStart() { C c; c.f(); } //+------------------------------------------------------------------+ Alexey Navoykov 2016.05.06 15:21 #15730 Renat Fatkhullin:再現性のあるブレーキの例を示してくださいよ。残念ながら、今のところ、開発者への直接攻撃など、根拠のない発言ばかりですが...。これは大きなプロジェクトで、ソースコードの総容量は約1Mbと申し上げました。 このブレーキをどうやって実証するのですか? 全てのコードを送るか? それは不可能だとお分かりでしょう。 そして、個々のピースのコンパイルは、もちろんもっと速く進みます。また、「根拠のない主張」とはどういう意味ですか? 最適化コンパイラがずっと遅いということですか? そして、あなたはそれをあまり気にしていないということですか? 何が根拠がないのでしょうか?この全体最適を導入したばかりの昨年10月のディスカッションのリンクはこちらです。https://www.mql5.com/ru/forum/1111/page1424#comment_1981722その人はこう書いている。別のコード - 時間に注意 - それは20倍になっている必要があります。と反応するんですね。これは、MQL5用の新しい最適化コンパイラです(MQL4にはありません)。 より良いターゲットコードと、より長いコンパイル時間の代償を払わなければならないのです。しかし、あなたの回答は、あなたが「より質の高いターゲットコード」と「2倍から10倍のスピードアップ」という神話にしか関心がないことを示しているように思えますが、私は実際の作業プロジェクトでそのようなスピードアップを見たことがありません。上に書いたように、最新ビルド(4月22日)ではコンパイル時にバグが出たのでテストできませんでしたが、新ビルドでのコンパイラの高速化は発表されていないので、そちらでもコンパイル速度は同じように遅いと思います。 Ошибки, баги, вопросы レビュー: 2www.mql5.com Форум трейдеров 1...156615671568156915701571157215731574157515761577157815791580...3185 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
100Kbのソースプロジェクトは、1325ビルドで1秒以内にコンパイルされます。堅実なOOP、多くの仮想関数と オーバーロード、テンプレート、ポインタ、(可能な限り)const修飾子。DLLとOpenCLはありません。
ラグの原因を突き止めたい。コンパイラが早く最適化できるようにするための制約なのかもしれませんね。ラグに遭遇したことは一度もありません。遅くなるkodobaseのソースコードを提供してください。
まあ、100Kbは多すぎですよね。 私は1Mbyte近くあります。 あなたと同じものが全部入っている上に、マクロがたくさん入っています。ただし、constがどこにでも設定されているわけではありません。 しかし、特にビルド1159ではすべてがほとんど瞬時にコンパイルされたので、このような異常な遅延の理由にはなりません。
ビルド1325では、プロジェクトが全くコンパイルされず、バグが一杯出てくるので、夕方にはテストできません。 同志A100も新しいビルドで一杯バグを報告しています。 私はこれらのバグをつつくのに時間を浪費する気はないので、彼らが作業ビルドをリリースするまで待つつもりです。
そのため、ビルド1241を参考にラグについてお伝えしました。 もしテストする機会があれば、最新のビルドと比較してみてください。 しかし、新しいビルドで大幅にスピードアップできるかどうかは疑問です。それどころか、MTの開発者は、コンパイル速度など気にしていません。彼らは、ランタイムからナノ秒を追加して、MQLプログラムの速度がC++と同等であると宣伝したいだけです(ただし、いくつかの抽象例においてのみですが)。私が理解する限り、彼らは最適化効率、つまりコストに見合ったゲームかどうかは気にしていないようです。
また、このプロジェクトは大規模なものであり、小規模なものはほとんど公開されていません。
おそらく彼は、テキストのスプールという形で巨大な機能をもっているのだろう。
オプティマイザは、このようなコード断片を何度も通過させ、何度もコードを改善しなければならない。オプティマイザは関数のサイズを小さくするだけで、劇的に速度が向上するのです。
最新のビルドは、品質とスピードの両方を常に向上させているので、最新のビルドに切り替える必要があります。
巨大な関数はありません。せいぜい150行です(巨大といえるでしょうか)。 また、こう考えてみると、なぜ関数の大きさとコンパイラが小さな関数をたくさん試したことが関係あるのでしょうか。 大きな関数を10回試したとしましょう。しかし、大きな関数を分割することで結果が多少速くなったとしても、コンパイルは10倍(!)遅くなるのです。
そして、言語を複雑にすればするほど、このパスが長くなり、プログラマーの時間を消費することになります。また、最適化によってプログラムがどれだけ速くなったか、最適化が完了するまでのプログラマのアイドルタイムと比べて、効率はどうなのか、という当然の疑問があります。
もちろん、妥協点を探すこともできますが、上に書いたように異なるコンパイルモードを作る方がはるかに効率的です。 最適化を施したプログラムリリースは最後の最後にしか必要ありません。プログラマの時間の99%は、最適化を全く必要としないコードを書いたりデバッグすることに費やされています。
ビルドアップデートのたびにコードがコンパイルできなくなるなんて、いつまで続くんだ! しかも、コンパイルできたとしても、以前と同じようには動かない(もっとひどい)。 こんなプログラミング言語、誰が必要とするんだ?
...
最大150行まで
意味がわからないんですけど。私は、MQLで2万行を超える非常に複雑なプロジェクトをいくつも抱えています。新しいビルドは、あっという間にコンパイルされます。その間、問題は2つしかありませんでした。一度は私のバグが原因で、もう一度は開発者のバグが原因です。
それなら、ラッキーですね。あなたのコードには、私のコードにあるような構成要素はありません。 何がそんなにおかしいのでしょうか?
上の人を2、3ページめくってみて、そこで彼は新しいビルドのバグもたくさん捕まえていて、中には捕まえにくいものもあります。 彼がわざと探していたとでもいうのでしょうか?
それなら、ラッキーですね。あなたのコードには、私のコードにあるような構成要素はありません。 何がそんなにおかしいのでしょうか?
上のページをいくつかめくってみてください。そこにいる男性も、新しいビルドのバグをたくさん捕まえています。 中には、なかなか捕まえられないバグもあります。 わざと探していたと思いますか?
リプレイブルブレーキの例を示してください。
残念ながら、今のところ、開発者への直接攻撃など、根拠のない発言をしていますね。
機能の大きさやプログラム全体の大きさについて、あなたは間違っています。個々の関数のサイズは、構文木の増加とマルチパス最適化の両方により、各特定関数の最適化に直接かつ非線形に影響する。小さな機能はその場で最適化されます。
それなら、ラッキーですね。あなたのコードには、私のコードにあるような構成要素はありません。 何がそんなにおかしいのでしょうか?
上のページをめくってみてください。そこにいる男性も、新しいビルドのバグをたくさん捕まえています。中には、なかなか捕まえられないバグもあります。 わざと探していたのでしょうか?
1) 私のコードに含まれていない、どのような構成要素を使用したのでしょうか。私のコードのサイズは何千行にもなるのに、あなたのコンストラクトは存在しないのですか?きっと、超ユニークなものに違いない?
2) 実は、前回のビルドで、クラス同士がリンクする際に発生する内部コンパイラーエラーがありました。開発者のバグでしたが、修正されました。それ以外のエラーは思い出せません。
2) 実は、以前のビルドでは、クラス同士がリンクする際に発生する内部コンパイラーエラーがありました。これは開発チームのバグですが、修正されました。それ以外のエラーは思い出せません。
https://www.mql5.com/ru/forum/1111/page1591#comment_2463820
また、クラス同士の相互リンクはどこにあるのでしょうか?
ここでは、相互参照先を検索したり、使っていないコンストラクトを理解したりするのに便利なように、さらに簡略化しています
https://www.mql5.com/ru/forum/1111/page1591#comment_2463820
また、ここでクラス同士の相互参照はどこにあるのでしょうか?
ここでは、相互参照先を検索しやすくするため、また、どの構成要素が使われていないかを理解しやすくするために、さらに簡略化しました。
リバースエンジニアリングをしているのですね。コンパイラの改良には役立つが、実用的なプログラミングという点では応用が利かない。あなたが引用したコードを実際に使うプログラマーを私は一人も知りません。
再現性のあるブレーキの例を示してくださいよ。
残念ながら、今のところ、開発者への直接攻撃など、根拠のない発言ばかりですが...。
これは大きなプロジェクトで、ソースコードの総容量は約1Mbと申し上げました。 このブレーキをどうやって実証するのですか? 全てのコードを送るか? それは不可能だとお分かりでしょう。 そして、個々のピースのコンパイルは、もちろんもっと速く進みます。
また、「根拠のない主張」とはどういう意味ですか? 最適化コンパイラがずっと遅いということですか? そして、あなたはそれをあまり気にしていないということですか? 何が根拠がないのでしょうか?
この全体最適を導入したばかりの昨年10月のディスカッションのリンクはこちらです。https://www.mql5.com/ru/forum/1111/page1424#comment_1981722
その人はこう書いている。
別のコード - 時間に注意 - それは20倍になっている必要があります。
と反応するんですね。
これは、MQL5用の新しい最適化コンパイラです(MQL4にはありません)。
より良いターゲットコードと、より長いコンパイル時間の代償を払わなければならないのです。
しかし、あなたの回答は、あなたが「より質の高いターゲットコード」と「2倍から10倍のスピードアップ」という神話にしか関心がないことを示しているように思えますが、私は実際の作業プロジェクトでそのようなスピードアップを見たことがありません。
上に書いたように、最新ビルド(4月22日)ではコンパイル時にバグが出たのでテストできませんでしたが、新ビルドでのコンパイラの高速化は発表されていないので、そちらでもコンパイル速度は同じように遅いと思います。