Скальперские автоматические системы по праву считаются вершиной алгоритмического трейдинга, но при этом они же являются и самыми сложными для написания кода. В этой статье мы покажем, как с помощью встроенных средств отладки и визуального тестирования строить стратегии, основанные на анализе поступающих тиков. Для выработки правил входа и...
これは正しいアプローチではありません。タスクを一つずつ与えるのではなく、空きリソースがあれば容量を再配分する、つまり、すでに与えられたタスクをキャンセルし、他の人に実行を委ねる必要があるのです。同時に、カーネルに適切な数の新規ジョブを与えるために、各エージェントのパフォーマンスを分析する必要があります。
デタラメばかりでスミマセン
> 既存のジョブをキャンセルして、他の人に実行を委ねる必要があります。
私は、これは現実的ではないと思うし、なぜ、ジョブのバッチを作成する方が簡単なのに、1つのジョブを最初に利用可能なスレッドに与え、それが実行されるまで待ち、最初に利用可能なスレッドに次のジョブを与える（私は、コアプロセッサではなく、単語のスレッドに注意を引く、スレッドの制限は削除されるべきである - それはプログラマの権利ではなく、ユーザーの権利、今ではネットワークスレッドが唯一の本当のコア、ないスレッドを思い出し、人為的に半分のパフォーマンスが低下している））。
>カーネルに必要な数の新しいジョブを実行させるためには、各エージェントのパフォーマンスを分析する必要があります。
と、これは、同じプロセッサのコアと同じ性能で、タスクに応じて、別の速度でカウントするため、まったく必要ありません、あなたはまったく何もカウントすることはできませんときに何かをカウントする必要はないです。
というのはデタラメで、申し訳ない。
> 既に発行されたタスクをキャンセルし、他の人に実行を委ねる。
私は、これは現実的ではないと思いますし、何のために、ジョブのバッチを作成し、1つのジョブを最初に利用可能なスレッドに与え、それが実行されるまで待ち、最初に利用可能なスレッドに次のジョブを与える方が簡単です（コアプロセッサではなくスレッドという言葉に注意してください、スレッドの制限は削除されるべきである - それはプログラマの権利ではなく、ユーザーです、現在ネットワークスレッドはスレッドではなく、実際のコアのみであり、人工的に性能を半分に下げていると思い起こされ)
>カーネルに必要な数の新しいジョブを実行させるためには、各エージェントのパフォーマンスを分析する必要があります。
というのも、1つのプロセッサのコアはタスクによって同じ性能でもカウントする速度が異なるので、何もカウントしないかもしれないのに、なぜそこで何かをカウントしなければならないのでしょうか？
あなたはオプティマイザーの経験が少ないようで、完了したパスの情報が遅れてくること、ジョブが完了した後にエージェントがフレームを送信 すること、それが非常に重いこと、これらすべてがコミュニケーションの遅れにつながり、最適化が遅くなることを理解していないようですね。したがって、課題は一括して発行し、その進捗を監視し、作業完了が近いエージェントには新しい課題を発行する必要があります。
オプティマイザーを使った経験が少ないようで、完了したパスの情報が遅れてくること、ジョブが完了するとエージェントがフレームを送信し、それが非常に重くなること、これらすべてがコミュニケーションの遅れにつながり、最適化が遅くなることを理解していないようですね。したがって、タスクは一括して発行し、作業の進捗を監視する必要があります。つまり、作業の完了が近いエージェントには、新しいタスクを発行します。
>オプティマイザーの使用経験が少ないようですね。
ふざけんなよ6年間連続
>完了したパスの情報は遅くなり、ジョブ完了後にエージェントがフレームを送信し、それが非常に重くなる可能性があります。したがって、課題は一括して発行し、その進捗を監視し、作業完了が近いエージェントには新しい課題を発行する必要があります。
>通信の遅れが生じ、最適化の速度が低下します。
で、そんなことより、今はネットワークが速い。
しかし、1つの貧弱なコアが束の中のジョブを終了させる間、コアをアイドル状態にすると、残りのすべてのコア（数十個）が停止し、コアが停止することなく連続的にカウントし続ける必要があるため、最適化が遅くなるのです
多くのパラメータを最適化したことがないように見えるのですが．とか、実務経験がないのに論じてはいけない
>オプティマイザーを使った経験が少ないようですね。
ふざけんなよ6年連続
>完了したパスの情報は遅くなり、ジョブが完了した後、エージェントは非常に重いことができるフレームを送信し、これらすべては、通信の遅延と最適化を遅くすることにつながる。したがって、課題は一括して発行し、その進捗を監視し、作業完了が近いエージェントには新しい課題を発行する必要があります。
>通信の遅れが生じ、最適化の速度が低下します。
とは関係なく、今はネットワークが速いですから。
しかし、1つの貧弱なコアが束の中のジョブを終了させる間、コアをアイドル状態にすると、残りのすべてのコア（数十個）が停止し、コアは停止せずにカウントを続ける必要があるため、最適化が遅くなるのです
多くのパラメータを最適化したことがないように見えるのですが．とか、実務経験がないくせに反論するなとか・・・。
独善的なエゴイストにはなれない、ネットワークは速い、なんてエゴイストなんだろう。逆に、数十メガバイト、数百メガバイトになるとネットワークは速くない。
原始的なEA最適 化が全てではない-視野を広げ、数学的な計算を駆使する。
あ、それから、これはユーザーの楽しみのためではなく、主に営利目的のプロジェクトなので、タスクのランダムな配分と、その成果の正しい財務会計を考慮した仕組みでなければならないことも覚えておいてください...。
独善的なエゴイストにはなれない、ネットワークは速い、なんてエゴイストなんだろう。逆に、数十メガバイト、数百メガバイトになるとネットワークは速くない。
原始的なEA最適 化が全てではない-視野を広げ、数学的な計算を駆使する。
それと、これは主に営利目的のプロジェクトであって、ユーザーに喜んでもらうためのものではないので、ジョブのランダムな分布とその性能の正しい財務会計を考慮した仕組みでなければならないことを心に留めておいてください......。
メガバイトの数十と数百は何もない、費やされた時間は最小限に抑えられ、ところでそれはこれとは何の関係もありませんが、あなたはとにかくこのトラフィックが渡す必要があります一つずつバッチでそれを書き込む前に考える必要があります。
> 原始的なEA最適 化が全てではない-視野を広げ、数学的な計算を駆使 する。
ホライズンもそうであるように
自分らしさについても。
原始的とは程遠い、何が目的なのか、無知な我々にご教示ください。
時間消費と最適化速度の点で、あなたの取り組みはまったく無茶だと思います。
アレクセイは彼のEAを見ています（彼のEAは数百MBあり、転送に時間がかかります）。
そして、MQはオプティマイザーの使用状況を総合的に判断し、あなたやアレクセイではなく、最も適合するように調整するのです。
少なくとも私の場合は、ローカルコアでタスクが再分配されます。もしどこかで再配布されないのであれば、開発者がそれを考慮できるように、再現例を教えてください。
アレクセイは彼のEAを見ています（彼のEAは数百MBあり、転送に時間がかかります）。
そして、MQはオプティマイザーの使用状況を総合的に判断し、あなたやアレクセイではなく、最も適合するように調整するのです。
少なくとも私の場合は、ローカルコアでタスクが再分配されます。もしどこかで再配布されないのであれば、開発者がそれをも考慮できるように、再現例を教えてください。
私のケースが特殊であることは承知しています。
新しいリモートエージェントが接続された場合、タスクの割り当てに問題があります。これは、他のタスクからリソースが解放された場合に発生します。
アレクセイは彼のEAを見ています（彼のEAは数百MBあり、転送に時間がかかります）。
そして、MQはオプティマイザーの使用状況を総合的に判断し、あなたやアレクセイではなく、最も適合するように調整するのです。
少なくとも私の場合は、ローカルコアでタスクが再分配されます。もしどこかで再配布されないのであれば、開発者がそれも考慮できるように、再現例を教えてください。
>プライベートでも持っているかもしれませんが、本当に "たぶん"
>開発者がそれを考慮できるように、再現する例をあげてください。
然程自分のEAを表示できない、標準的なものには興味がない、再配布されていないことを示すスクリーンショットを作成できる
再分配されれば、問題解決になるのですが
......計算時間が3倍にオプティマイザーがちゃんと動くようになるんだろうか？
二日目は何もカウントされませんが、12ローカルと約30ネットワークコアの数のすべてのコアがアイドル状態である、私は意図的にそれに触れないでください...何を考えているのかわからないが、おそらく人生の意味かコロナウイルスの治療法を探しているのだろう :-)
オプティマイザーは操作性が悪く、動作が鈍いので捨てるべきだと思います
また、最近のMTの決定では、物理コアのみを制限し、各コア - 1ジョブではなく、特定のコアのみにジョブの束を執拗かつ愚直に配布しており、高性能計算の開発者が全く理解していないことを示しています。