開発者への質問 - 最適化時にすべての計算コアを使用することについて - ページ 4 1234567891011 新しいコメント Andrey Khatimlianskii 2020.01.07 16:01 #31 Boris Egorov: そんなメッセージがあれば、きっと遠くまで行けるはず...。ところで、SlavaはMTの主要な開発者の一人で、アルゴリズムの仕組みをよく知っています。 だから、同じ結果になる標準EAの最適化セットを出せと言ってるんだ。以前はあるパラメータが最適化されていたが、今は別のパラメータが最適化されている。おそらく、遺伝子が意味するものすべてに自動的に切り替わったのでしょう。 建設性を加味すれば、問題はもっと早く解決する。 Sergey Chalyshev 2020.01.07 20:11 #32 Andrey Khatimlianskii: もし本当に変えたいのなら、（私のように）不平を言うだけでなく、カーネルが無効/スタンバイである再現可能な例を開発者に示してはどうでしょうか。 標準的なEAをベースに（プレイアブルであれば）、できるだけ詳細に、自分たちで動作を再現できるようにするといいかもしれません。 というのは、わかりやすいでしょうか。 ローカルエージェントのみ使用、8人中6人が有効、3人は最初のジョブバッチの後すぐに落ちる Andrey Khatimlianskii 2020.01.07 20:55 #33 Sergey Chalyshev: というのは、わかりやすいでしょうか。 ローカルエージェントのみ使用、8人中6人が有効、3人は最初のジョブバッチの後すぐに落ちる そのほうがよっぽど建設的です。 テスターのログと、早く終わったエージェントのログを添付してください。 Sergey Chalyshev 2020.01.07 22:14 #34 Andrey Khatimlianskii: この方がよっぽど建設的です。 テスターのログと、早く終わったエージェントのログを添付してください。 テスター、動作中のエージェント、失敗したエージェントのログ。 ファイル: 20200108.log 9 kb 3000_20200108.log 166 kb 3003_20200108.log 23 kb Andrey Khatimlianskii 2020.01.07 23:10 #35 Sergey Chalyshev: テスター、作業エージェント、失敗エージェントのログ。 あとは@Slavaさんの 回答を待つばかりです。 第3世代以降、遺伝子が一部のコアに関与しなくなったようだ。 01:00:50.723 Tester Best result 5681.165275 produced at generation 1. Next generation 4 意味がないと思った？ Boris Egorov 2020.01.08 05:52 #36 > ところで、Slavaは、MTの主要な開発者の一 人です。 では、スラバ - すべての希望はあなたにあります、私たちは祈り、私たちは声を上げます....動作しないウェブエージェントから私たちを救ってください :-) また、Andrey Khatimlianskiiのログに感謝します。 Slava 2020.01.08 06:19 #37 Boris Egorov: > ところで、Slavaは、MTの主要な開発者の一 人です。 では、スラバ - すべての希望はあなたにあります、私たちは祈り、私たちは声を上げます....ネットワークエージェントが動作していない状態から、私たちを助けてください :-) また、Andrey Khatimlianskiiのログに感謝します。 取り組んでいるところです。2ページ目に約束されたRenat Slava 2020.01.08 06:22 #38 Andrey Khatimlianskii: あとは@Slavaさんの 回答を待つばかりです。 第3世代以降、遺伝子が一部のコアに関与しなくなったようだ。 意味がないと思った？ いいえ。 過去ログにはまだあります。 NQ 3 01:02:43.436 Tester stopped by user エージェントログで確認 FL 0 01:02:43.434 127.0.0.1 tester forced to stop JJ 0 01:02:43.439 Tester 29 of 85 passes processed (29 successfully finished) in 0:00:06.976 Edgar Akhmadeev 2020.01.08 13:35 #39 ダウンタイムには、実は2つの問題があることを指摘したい。 遺伝子の場合、世代計算の終了を待つ期間があります。この場合、ジョブパッケージのリバランスが可能かどうかは定かではありません。 低速最適化では、ジョブを動的に再配置することで、以前に解放されたエージェントのダウンタイムを回避することができます。 開発者がこれをやらなかったために、最適化の初期にジョブが分散してしまうという事態が発生しています。クラウドエージェントを使う場合も同じ分配アルゴリズムが適用されるため、クラウドエージェントから仕事を奪うのは「不適切」という理由から、これを行わなかったそうです。オンプレミスとクラウドのエージェントの方法論は分けて考える価値がある。 一方、開発者は比較的最近になって、早く仕事を終えたエージェントのためにわずかな予備を残すという方法を少し改良しました。しかし、残念ながら、これでいつも救われるとは限りません。また、この積立金はタスクをエージェント数で割った余り なので、0になることもある。 Andrey Khatimlianskii 2020.01.08 20:37 #40 Slava: いいえ。 ログにはもう一つエントリーがあります エージェントのログで確認。 だから、それはその後、最後に。エージェントが脱落したのはもっと前の01:00:50で、ログと映像で確認できます。 1234567891011 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
そんなメッセージがあれば、きっと遠くまで行けるはず...。ところで、SlavaはMTの主要な開発者の一人で、アルゴリズムの仕組みをよく知っています。
だから、同じ結果になる標準EAの最適化セットを出せと言ってるんだ。以前はあるパラメータが最適化されていたが、今は別のパラメータが最適化されている。おそらく、遺伝子が意味するものすべてに自動的に切り替わったのでしょう。
建設性を加味すれば、問題はもっと早く解決する。
もし本当に変えたいのなら、（私のように）不平を言うだけでなく、カーネルが無効/スタンバイである再現可能な例を開発者に示してはどうでしょうか。
標準的なEAをベースに（プレイアブルであれば）、できるだけ詳細に、自分たちで動作を再現できるようにするといいかもしれません。
というのは、わかりやすいでしょうか。
ローカルエージェントのみ使用、8人中6人が有効、3人は最初のジョブバッチの後すぐに落ちるというのは、わかりやすいでしょうか。
ローカルエージェントのみ使用、8人中6人が有効、3人は最初のジョブバッチの後すぐに落ちるそのほうがよっぽど建設的です。
テスターのログと、早く終わったエージェントのログを添付してください。
この方がよっぽど建設的です。
テスターのログと、早く終わったエージェントのログを添付してください。
テスター、動作中のエージェント、失敗したエージェントのログ。
テスター、作業エージェント、失敗エージェントのログ。
あとは@Slavaさんの 回答を待つばかりです。
第3世代以降、遺伝子が一部のコアに関与しなくなったようだ。
意味がないと思った？
> ところで、Slavaは、MTの主要な開発者の一 人です。
では、スラバ - すべての希望はあなたにあります、私たちは祈り、私たちは声を上げます....動作しないウェブエージェントから私たちを救ってください :-)
また、Andrey Khatimlianskiiのログに感謝します。
> ところで、Slavaは、MTの主要な開発者の一 人です。
では、スラバ - すべての希望はあなたにあります、私たちは祈り、私たちは声を上げます....ネットワークエージェントが動作していない状態から、私たちを助けてください :-)
また、Andrey Khatimlianskiiのログに感謝します。
あとは@Slavaさんの 回答を待つばかりです。
第3世代以降、遺伝子が一部のコアに関与しなくなったようだ。
意味がないと思った？
いいえ。
過去ログにはまだあります。
エージェントログで確認
ダウンタイムには、実は2つの問題があることを指摘したい。
遺伝子の場合、世代計算の終了を待つ期間があります。この場合、ジョブパッケージのリバランスが可能かどうかは定かではありません。
低速最適化では、ジョブを動的に再配置することで、以前に解放されたエージェントのダウンタイムを回避することができます。 開発者がこれをやらなかったために、最適化の初期にジョブが分散してしまうという事態が発生しています。クラウドエージェントを使う場合も同じ分配アルゴリズムが適用されるため、クラウドエージェントから仕事を奪うのは「不適切」という理由から、これを行わなかったそうです。オンプレミスとクラウドのエージェントの方法論は分けて考える価値がある。
一方、開発者は比較的最近になって、早く仕事を終えたエージェントのためにわずかな予備を残すという方法を少し改良しました。しかし、残念ながら、これでいつも救われるとは限りません。また、この積立金はタスクをエージェント数で割った余り なので、0になることもある。
いいえ。
ログにはもう一つエントリーがあります
エージェントのログで確認。
だから、それはその後、最後に。エージェントが脱落したのはもっと前の01:00:50で、ログと映像で確認できます。