Canvasでクラウドソーシングのプロジェクトを作る - ページ 33 1...262728293031323334353637383940...45 新しいコメント Roman 2020.01.26 14:48 #321 Реter Konow: その例では、リフレッシュレートは正常です。だからスピードが落ちないんです。 タスクマネージャーでメタトレーダー(32bit)を確認。 もしかしたら、遅延の原因はビットサイズと関係があるのかもしれません。 メタトレーダーは現在、x64にしか対応していないため。 また、開発者によると、32ビット版はもうリリースされないそうです。 非同期データ処理の問題は解決されたのでしょうか？ Алексей Барбашин 2020.01.26 15:12 #322 Roman: タスクマネージャでメタトレーダー(32bit)が表示されるのですが。 もしかして、遅さの原因はシステムの桁数に関係しているのでは？ さて、メタトレーダーは現在、x64のみを対象としています。 また、開発者によると、32ビット版はもうリリースされないそうです。 また、非同期データ処理の問題は解決されたのでしょうか？ 私が紹介したNikolaiの例では、どのオブジェクトを動かす場合でも、特に素早く行うとCPUに負荷がかかることが確認されています。負荷は35〜40％増加します。64ビットプロセッサー、64ビットWindows 7、64ビットMT5でテストを実施しました。 今回の議論でいう非同期処理とはどのようなものでしょうか。 Реter Konow 2020.01.26 15:26 #323 Roman: タスクマネージャーでメタトレーダー(32bit)を確認することができます。 もしかして、遅延の原因は、システムのビット数容量にあるのでは？ 実は、メタトレーダーは現在、x64用にのみカスタマイズされています。 また、開発者によると、32ビット版はもうリリースされないそうです。 また、非同期データ処理の問題は解決されたのでしょうか？ これらの例はすべてMT4でのものです。 MT5はもっと引っ張りますが、間違った再描画（例えばカップ）ではプロセッサにも負荷がかかります（確認済みです）。問題は再描画の頻度と面積にあり、これはぜひとも減らしたいところです。セルを再描画する必要がある場合は、そのセルだけです。そうでなければ、リソースの無駄遣いです（たとえば、1秒間に10回セルを再描画する必要がある場合、キャンバス全体を再描画すると、プロセッサが「死んで」しまい、非現実的になります）。しかし、それはすでに明らかです。 説明しよう。テーブルセルは、ベース、テキスト、アイコンの3つのオブジェクトを持っています。セルの内容が変わると、キャンバスを3回ループさせる必要があります。1サイクル目はベース、2サイクル目はテキスト、3サイクル目はアイコンを再描画します。細胞の面積が3倍になったようなものです。この調子でカンヴァス全体を再描画し続けると、深刻なスローダウンが発生します。そのため、再描画するキャンバス領域上のサイクル数を考慮する必要があります。単純なプリミティブではわからないかもしれませんが、複雑な要素では明らかになります。一部の要素は 10 個のオブジェクトで構成され（ ボタン付きの入力ボックス、出力リスト、ウィンドウ プラットフォーム）、それらを再描画する際にキャンバス配列上で何サイクル行うべきかを計算することが可能である。幸いなことに、この再描画は高い繰り返し率を必要としない。 非同期処理の問題は解決していない。いくつかの案があったが、まだ解決策は見つかっていない。 全体として、Canvas上にGUIを作る場合、別々に再描画可能な要素で構成する必要があります。そうしないと、プログラムがすぐに限界に達してしまい、それ以降は簡単な操作でのラグが目立つようになります。 Roman 2020.01.26 15:39 #324 Алексей Барбашин: 今回の議論でいう非同期データ処理とはどういう意味ですか？ 簡単に言うと、非同期（リソースを追いかける）かマルチスレッド（専用リソース）か、ということですね。 Nikolayの例のコードは見ていませんが、Metatraderでは 非同期やマルチスレッドがないため、ピクセル再描画のコードは同期的に実行 されます。 そして、Peteraの出力データ処理も同様に同期的に行われている可能性が高い。そしてどちらの場合も、やはりすべてサイクル単位で処理されていると思われます。 このため、プロセッサの負荷が高くなります。一度に少ない負荷で高速に応答するためには、データ処理と再描画を並列化する必要があります。 Реter Konow 2020.01.26 15:48 #325 Roman: まあ、簡単に理解すると、非同期（リソース競合）かマルチスレッド（専用リソース）か、ということです。 Nikolayの例のコードは見ていませんが、Metatraderでは 非同期やマルチスレッドがないため、ピクセル再描画のコードは同期的に実行 されます。そして、Peteraの出力データ処理も同様に同期的に行われている可能性が高い。そ して、いずれの場合も、これらはすべてループで処理されることになりそうだ。 そ のため、プロセッサの負荷が高くなります。一度に少ない負荷で高速に応答するためには、データ処理と再描画を並列化する必要があります。 そうでもない))私は、エンジンをリソース経由でユーザーアプリケーションに接続するようにしています。つまり、ユーザーアプリケーションはそのスレッドで計算を行い、そのデータをエンジン（GUIを搭載）に渡すのですが、そのエンジンは別のグラフ上にある可能性があるのです。パラメータイベントを処理し、GUIに出力します。つまり、処理を2つのスレッドに分割するのです。しかし、これから投稿するコンストラクタでは、そうはいきません。アプリケーションは、それ自身の中にエンジンを含み、すべてが1つのスレッドになります。しかし、プロセッサへの負荷は同じになります。速度の関数列への依存度は、単純に高くなります。 Maxim Kuznetsov 2020.01.26 16:04 #326 Реter Konow: そうでもない))私は、エンジンをリソース経由でユーザーアプリケーションに接続するようにしています。つまり、ユーザーアプリケーションはそのスレッドで計算を行い、そのデータをエンジン（GUIを搭載）に渡すのですが、そのエンジンは別のグラフ上にある可能性があるのです。パラメータイベントを処理し、GUIに出力します。つまり、処理を2つのスレッドに分割するのです。しかし、 これから投稿 するコンストラクタでは、そうはいきません。アプリケーションは、それ自身の中にエンジンを含み、すべてが1つのスレッドになります。しかし、プロセッサへの負荷は同じになります。実行する機能の順序に対する速度の依存性は、単純に高くなります。 また始まったよ...約束、発表、おしゃべり。 もう忘れてしまったが、"kernel-engine "はまともなソフトウェアとして公開されていたのか？ それとも、コメントに添付された形でガラクタとして公開されていたのか？ Алексей Барбашин 2020.01.26 16:11 #327 Roman: 簡単に言うと、非同期（リソース競合）かマルチスレッド（専用リソース）か、ということですね。 Nikolaiさんのサンプルコードは見ていませんが、Metatraderでは 非同期やマルチスレッドがないため、ピクセル再描画のコードは同期で 実行されているようです。 そして、Peteraの出力データ処理も同様に同期的に行われている可能性が高い。そして、いずれの場合も、これらはすべてループで処理されることになりそうだ。 そ のため、プロセッサの負荷が高くなります。一度に少ない負荷で高速に応答するためには、データ処理と再描画を並列化する必要があります。 MTの操作はすべて厳密に同期であり、開発者がアプリケーションにスレッドを追加しない限り、これを実際に変更することはできない。 データベースとの連携、Pythonとの連携、Sharpとの連携など、MTの機能を拡張しようとする開発者がいることは、とても驚きです。が、全部同じスレッドでやってくれと申し出る...。とにかくすごいんです。 Реter Konow 2020.01.26 16:12 #328 Maxim Kuznetsov: ああまたか カーネル・エンジンはまともなソフトウェアとして公開されていたのか？ それとも、コメントに添付されたようなガラクタとして公開されていたのか？ よかったね。あなたのような人と格闘することで刺激を受け、いつも負けてしまうのです))私にエネルギーを与えてくれているのに気づいていない。 Алексей Барбашин 2020.01.26 16:13 #329 Maxim Kuznetsov: ああまたか カーネル・エンジンはまともなソフトウェアとして公開されたのか、それともコメント欄に添付されるようなガラクタとして公開されたのか、忘れてしまったくらいです。 マックス、慎重にな。 Roman 2020.01.26 16:17 #330 Реter Konow: そうでもない))私は、エンジンをリソース経由でユーザーアプリケーションに接続するようにしています。つまり、ユーザーアプリケーションはそのスレッドで計算を行い、そのデータをエンジン（GUIを搭載）に渡すのですが、そのエンジンは別のグラフ上にある可能性があります。パラメータイベントを処理し、GUIに出力します。つまり、処理を2つのスレッドに分割するのです。しかし、これから投稿するコンストラクタでは、そうはいきません。アプリケーションは、それ自身の中にエンジンを含み、すべてが1つのスレッドになります。しかし、プロセッサへの負荷は同じになります。ただ、速度の関数列への依存度が大きくなる。 アプリケーション別、GUI別というのはわかった。 しかし、GUIでの出力データの処理は、とにかく同期して行われます。 例えば、アプリケーションがGUIに10000個のエレメントを送り、GUIがこれら全てのエレメントを順次処理する場合です。 これが問題なのです。 GUIでは、入力された要素の処理とその出力を並列化する必要があります。ベース、テキスト、アイコンです。 さらに言えば、1つのセルにつき3つのサイクルがあります。 1...262728293031323334353637383940...45 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
その例では、リフレッシュレートは正常です。だからスピードが落ちないんです。
タスクマネージャーでメタトレーダー(32bit)を確認。
非同期データ処理の問題は解決されたのでしょうか？もしかしたら、遅延の原因はビットサイズと関係があるのかもしれません。
メタトレーダーは現在、x64にしか対応していないため。
また、開発者によると、32ビット版はもうリリースされないそうです。
タスクマネージャでメタトレーダー(32bit)が表示されるのですが。
また、非同期データ処理の問題は解決されたのでしょうか？もしかして、遅さの原因はシステムの桁数に関係しているのでは？
さて、メタトレーダーは現在、x64のみを対象としています。
また、開発者によると、32ビット版はもうリリースされないそうです。
私が紹介したNikolaiの例では、どのオブジェクトを動かす場合でも、特に素早く行うとCPUに負荷がかかることが確認されています。負荷は35〜40％増加します。64ビットプロセッサー、64ビットWindows 7、64ビットMT5でテストを実施しました。
今回の議論でいう非同期処理とはどのようなものでしょうか。
タスクマネージャーでメタトレーダー(32bit)を確認することができます。
また、非同期データ処理の問題は解決されたのでしょうか？もしかして、遅延の原因は、システムのビット数容量にあるのでは？
実は、メタトレーダーは現在、x64用にのみカスタマイズされています。
また、開発者によると、32ビット版はもうリリースされないそうです。
これらの例はすべてMT4でのものです。
MT5はもっと引っ張りますが、間違った再描画（例えばカップ）ではプロセッサにも負荷がかかります（確認済みです）。問題は再描画の頻度と面積にあり、これはぜひとも減らしたいところです。セルを再描画する必要がある場合は、そのセルだけです。そうでなければ、リソースの無駄遣いです（たとえば、1秒間に10回セルを再描画する必要がある場合、キャンバス全体を再描画すると、プロセッサが「死んで」しまい、非現実的になります）。しかし、それはすでに明らかです。
説明しよう。テーブルセルは、ベース、テキスト、アイコンの3つのオブジェクトを持っています。セルの内容が変わると、キャンバスを3回ループさせる必要があります。1サイクル目はベース、2サイクル目はテキスト、3サイクル目はアイコンを再描画します。細胞の面積が3倍になったようなものです。この調子でカンヴァス全体を再描画し続けると、深刻なスローダウンが発生します。そのため、再描画するキャンバス領域上のサイクル数を考慮する必要があります。単純なプリミティブではわからないかもしれませんが、複雑な要素では明らかになります。一部の要素は 10 個のオブジェクトで構成され（ ボタン付きの入力ボックス、出力リスト、ウィンドウ プラットフォーム）、それらを再描画する際にキャンバス配列上で何サイクル行うべきかを計算することが可能である。幸いなことに、この再描画は高い繰り返し率を必要としない。
非同期処理の問題は解決していない。いくつかの案があったが、まだ解決策は見つかっていない。
全体として、Canvas上にGUIを作る場合、別々に再描画可能な要素で構成する必要があります。そうしないと、プログラムがすぐに限界に達してしまい、それ以降は簡単な操作でのラグが目立つようになります。
今回の議論でいう非同期データ処理とはどういう意味ですか？
簡単に言うと、非同期（リソースを追いかける）かマルチスレッド（専用リソース）か、ということですね。
Nikolayの例のコードは見ていませんが、Metatraderでは 非同期やマルチスレッドがないため、ピクセル再描画のコードは同期的に実行 されます。
そして、Peteraの出力データ処理も同様に同期的に行われている可能性が高い。そしてどちらの場合も、やはりすべてサイクル単位で処理されていると思われます。
このため、プロセッサの負荷が高くなります。一度に少ない負荷で高速に応答するためには、データ処理と再描画を並列化する必要があります。
まあ、簡単に理解すると、非同期（リソース競合）かマルチスレッド（専用リソース）か、ということです。
Nikolayの例のコードは見ていませんが、Metatraderでは 非同期やマルチスレッドがないため、ピクセル再描画のコードは同期的に実行 されます。
そして、Peteraの出力データ処理も同様に同期的に行われている可能性が高い。そ して、いずれの場合も、これらはすべてループで処理されることになりそうだ。
そ のため、プロセッサの負荷が高くなります。一度に少ない負荷で高速に応答するためには、データ処理と再描画を並列化する必要があります。
そうでもない))私は、エンジンをリソース経由でユーザーアプリケーションに接続するようにしています。つまり、ユーザーアプリケーションはそのスレッドで計算を行い、そのデータをエンジン（GUIを搭載）に渡すのですが、そのエンジンは別のグラフ上にある可能性があるのです。パラメータイベントを処理し、GUIに出力します。つまり、処理を2つのスレッドに分割するのです。しかし、これから投稿するコンストラクタでは、そうはいきません。アプリケーションは、それ自身の中にエンジンを含み、すべてが1つのスレッドになります。しかし、プロセッサへの負荷は同じになります。速度の関数列への依存度は、単純に高くなります。
そうでもない))私は、エンジンをリソース経由でユーザーアプリケーションに接続するようにしています。つまり、ユーザーアプリケーションはそのスレッドで計算を行い、そのデータをエンジン（GUIを搭載）に渡すのですが、そのエンジンは別のグラフ上にある可能性があるのです。パラメータイベントを処理し、GUIに出力します。つまり、処理を2つのスレッドに分割するのです。しかし、 これから投稿 するコンストラクタでは、そうはいきません。アプリケーションは、それ自身の中にエンジンを含み、すべてが1つのスレッドになります。しかし、プロセッサへの負荷は同じになります。実行する機能の順序に対する速度の依存性は、単純に高くなります。
また始まったよ...約束、発表、おしゃべり。
もう忘れてしまったが、"kernel-engine "はまともなソフトウェアとして公開されていたのか？ それとも、コメントに添付された形でガラクタとして公開されていたのか？
簡単に言うと、非同期（リソース競合）かマルチスレッド（専用リソース）か、ということですね。
Nikolaiさんのサンプルコードは見ていませんが、Metatraderでは 非同期やマルチスレッドがないため、ピクセル再描画のコードは同期で 実行されているようです。
そして、Peteraの出力データ処理も同様に同期的に行われている可能性が高い。そして、いずれの場合も、これらはすべてループで処理されることになりそうだ。
そ のため、プロセッサの負荷が高くなります。一度に少ない負荷で高速に応答するためには、データ処理と再描画を並列化する必要があります。
MTの操作はすべて厳密に同期であり、開発者がアプリケーションにスレッドを追加しない限り、これを実際に変更することはできない。
データベースとの連携、Pythonとの連携、Sharpとの連携など、MTの機能を拡張しようとする開発者がいることは、とても驚きです。が、全部同じスレッドでやってくれと申し出る...。とにかくすごいんです。
ああまたか
カーネル・エンジンはまともなソフトウェアとして公開されていたのか？ それとも、コメントに添付されたようなガラクタとして公開されていたのか？
よかったね。あなたのような人と格闘することで刺激を受け、いつも負けてしまうのです))私にエネルギーを与えてくれているのに気づいていない。
ああまたか
カーネル・エンジンはまともなソフトウェアとして公開されたのか、それともコメント欄に添付されるようなガラクタとして公開されたのか、忘れてしまったくらいです。
マックス、慎重にな。
そうでもない))私は、エンジンをリソース経由でユーザーアプリケーションに接続するようにしています。つまり、ユーザーアプリケーションはそのスレッドで計算を行い、そのデータをエンジン（GUIを搭載）に渡すのですが、そのエンジンは別のグラフ上にある可能性があります。パラメータイベントを処理し、GUIに出力します。つまり、処理を2つのスレッドに分割するのです。しかし、これから投稿するコンストラクタでは、そうはいきません。アプリケーションは、それ自身の中にエンジンを含み、すべてが1つのスレッドになります。しかし、プロセッサへの負荷は同じになります。ただ、速度の関数列への依存度が大きくなる。
アプリケーション別、GUI別というのはわかった。
しかし、GUIでの出力データの処理は、とにかく同期して行われます。
例えば、アプリケーションがGUIに10000個のエレメントを送り、GUIがこれら全てのエレメントを順次処理する場合です。
これが問題なのです。 GUIでは、入力された要素の処理とその出力を並列化する必要があります。ベース、テキスト、アイコンです。
さらに言えば、1つのセルにつき3つのサイクルがあります。