mql5言語の特徴、微妙なニュアンスとテクニック - ページ 102 1...9596979899100101102103104105106107108109...247 新しいコメント Nikolai Semko 2018.09.20 18:51 #1011 アレクセイ・ナヴォイコフやりすぎだよ)まず、メッセージキューを経由する。次に、追加でコンバージョン(前後変換)をする必要があります。それに、検証も行われているんですよ。 ちなみに、構造体の大き さは明示的に指定しないほうがよいでしょう。そのためのsizeofがある。そこにメッセージキューがあったのはどこですか?往復の換算はありません。fxsaberの 例と同じユニオンを使用します。バリデーションもない。もちろん、sizeof(...)を使ってもいいのですが、普遍的なものではなく具体的なタスクの実装なので、単純に3桁と短く書くしかなかったのです。おそらく、他のコードをご覧になったのでしょう。 私のバージョンで唯一気に入らないのは、ゼロをバイパスするために行のサイズを2倍にしなければならなかったことです。もっとシンプルな解決策があると背中で感じているのですが、見つかっていないのです。しかし、それでも動作は速くなります。 Alexey Navoykov 2018.09.20 23:03 #1012 ニコライ・セムコ メッセージキューはどこにあったのですか? SetWindowText/GetWindowTextは、メッセージで送信されないのですか? 往復の換算はありません。 もちろん、そうです。何を騒いでいるんだ? for(int i=0; i<56; i++) if(U.a[i]==0) m[2*i+1]=2; else m[2*i]=U.a[i]; Nikolai Semko 2018.09.21 01:26 #1013 アレクセイ・ナヴォイコフ SetWindowText/GetWindowTextは、メッセージで送信されないのですか? そして、あなたはWindowsのメッセージについて話している......だから何?自作DLLを使わずにwindosの異なるプログラム間でデータをやり取りするための高速な代替手段はないのでしょうか? 私の言葉に気分を害されたこと、私の変種が速いことは理解できます。まあ、第一に、私は断言したのではなく、提案しただけです。2つ目は、Memory Mappingと 比較しながら、テストコードで 裏付けをとったことです。 また、仮定の話でも反論しようとするならば、断定的な発言だけで反論するのはやめてほしい。自作DLLなしで端末間のデータ交換をより高速に実装する方法をご指摘いただき、思いとどまることができれば大変ありがたいです。 RAMディスク経由のバリアントがより高速になることは排除しない。しかし、これはRAMディスクのインストールとその設定が必要なため、少し話が違ってきます。 アレクセイ・ナヴォイコフ もちろんです。しかし、このタンバリンを使ったダンスは何なんだ。for(int i=0; i<56; i++) if(U.a[i]==0) m[2*i+1]=2; else m[2*i]=U.a[i]; タンバリンはこれくらいにしましょう。凡庸さである。ちなみに、この些細なことは、刻み目構造の全受信ブロックが90μs(90 000 ns.)で行われるときに、50〜60nsで行われる。つまり、これらの「ダイヤモンド」はデータブロック受信時間のわずか0.06%を占めるにすぎない。しかも、この点が混乱するのは、記憶倍加の観点からだけだと書きました。 このように、小さなデータ構造の交換には、私のバリアントはとても便利でシンプルでスマートな ようです。 fxsaber 2018.09.21 05:41 #1014 ニコライ・セムコ 私のバージョンで唯一気に入らないのは、ゼロが行末と認識されるため、ゼロを回避するために行のサイズを2倍にしなければならなかったことです。もっとシンプルな解決策があるのではと背中で感じているのですが、見つかっていません。しかし、その分、動作は速くなります。 トレーディング、自動売買システム、ストラテジーテストに関するフォーラム ライブラリ:HistoryTicks オートメイテッド・トレーディング さん 2018.03.29 11:09 ソース(Data_String.mqh ファイル)にはクロスプラットフォームの関数があり、文字列に任意のデータを入れたり取り出したりすることができます。例えば、ユーザー イベントの文字列パラメータ(スパラム)を使って、任意のMQLプログラム間で簡単にデータを交換することができます。 #include <fxsaber\HistoryTicks\Data_String.mqh> // https://www.mql5.com/ru/code/20298 void OnStart() { MqlTick Tick; if (SymbolInfoTick(_Symbol, Tick)) { const string Str = DATA_STRING::ToString(Tick); MqlTick Ticks[1]; Ticks[0] = DATA_STRING::FromString<MqlTick>(Str); ArrayPrint(Ticks); } } Nikolai Semko 2018.09.21 11:20 #1015 fxsaber: すごい! CryptEncodeやCryptDecodeの ような関数も知りませんでした。ありがとうございました。 見てみようかな。 しかし、一見するとすべてがハイテクに見えるが、めちゃくちゃ遅い。なぜなら、CryptEncode関数は、ここでタンバリンと名付けられたものよりも2桁も遅く(マイクロ秒対数十ナノ秒)実行されるからだ。 for(int i=0; i<56; i++) if(U.a[i]==0) m[2*i+1]=2; else m[2*i]=U.a[i]; Alexey Navoykov 2018.09.21 12:33 #1016 ニコライ・セムコ私が「私のバージョンは早い」と言ったことに、お気を悪くされたようですね。まあ、まず、断言したわけではなく、仮定したに過ぎないのですが。2つ目は、Memory Mappingと 比較しながら、テストコードで 裏付けをとったことです。私は「速さ」ではなく「既存のすべてのソリューションより速いかも しれない」という意味で、攻撃することなく何度か発言しています。 そしてその発言は極めて公正なものでした。 しかしあなたは、なぜかまずそれを執拗に否定し(「おそらく他のコードを見て いるはずだ」)、「だから何!」と突っ込みを入れるのです。そこで、フライとカツを分けて考えて みましょう。 次に、MemoryMapping(正確にはそのMQLラッパー)に関してですが、私はそれが高速 であるとは一言も言っていません。 さらに、このプロジェクトの議論スレッドで、私はラグを発生させる作者のバグとその修正方法を指摘しました。だから、もし何かをテストするのであれば、誰かが間違った判断をした形ではなく、本来の 形でテストすることです。 fxsaber 2018.09.21 13:23 #1017 ニコライ・セムコZZY しかし、一見するとハイテクだが、めちゃくちゃ遅い。CryptEncode関数は、ここでいうタンバリンよりも2桁(マイクロ秒対数十ナノ秒)遅いからだ。 スピードは何のためにあるのか? Nikolai Semko 2018.09.21 14:51 #1018 アレクセイ・ナヴォイコフ私は「速さ」の話ではなく、「既存のすべてのソリューションよりも速いかもしれない」という話をしたのです。 そしてこの発言は極めて公正なものでした。 ただ、あなたは最初に何らかの理由で頑なに否定し(「おそらく他のコードを見た のだろう」)、そして「だから何!」という立場になるのです。では、フライとカツを分けて みましょう。 第二に、MemoryMapping(正確にはMQLラッパー)に関して、私はそれが高速に動作すると主張したことは一 度もありません。 さらに、このプロジェクトの議論スレッドで、私はラグを発生させる作者のバグとその修正方法を指摘しました。ですから、何かをテストするのであれば、誰かの間違った判断ではなく、ネイティブの形で テストすることです。オッケーです。同意見です。うるさかったな。私が出会ったすべての実装はkernel32.dllを使用していたので、おそらくkernel32.dllの代わりにuser32.dllを使用すると、WinAPI経由で2つのターミナルをリンクするときに速くなることが判明している、と言いたかっただけなのです。 Nikolai Semko 2018.09.21 14:53 #1019 fxsaber: 何のための速度なのか?すみません、質問の意味が分かりませんでした。 ご質問の件ですが、なぜ端末間の ブリッジ速度が必要なのでしょうか? fxsaber 2018.09.21 15:29 #1020 ニコライ・セムコすみません、質問の意味が分かりませんでした。 なぜ、端末間のブリッジデータ交換のスピードが必要なのか、というご質問ですね。はい。 トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム mql5言語の特殊性、ヒントとコツ ニコライ・セムコ さん 2018.09.21 13:20 しかし、これまでのところ、一見すると、すべてのこの、もちろん、ハイテクが、非常識に遅いので、CryptEncode関数は、ここでタンバリンと呼ばれるものよりも遅い(ナノ秒のマイクロ秒対数十)2桁を実行されます。 1...9596979899100101102103104105106107108109...247 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
やりすぎだよ)まず、メッセージキューを経由する。次に、追加でコンバージョン(前後変換)をする必要があります。それに、検証も行われているんですよ。
ちなみに、構造体の大き さは明示的に指定しないほうがよいでしょう。そのためのsizeofがある。
おそらく、他のコードをご覧になったのでしょう。
私のバージョンで唯一気に入らないのは、ゼロをバイパスするために行のサイズを2倍にしなければならなかったことです。もっとシンプルな解決策があると背中で感じているのですが、見つかっていないのです。しかし、それでも動作は速くなります。
SetWindowText/GetWindowTextは、メッセージで送信されないのですか?
往復の換算はありません。
もちろん、そうです。何を騒いでいるんだ?
SetWindowText/GetWindowTextは、メッセージで送信されないのですか?
そして、あなたはWindowsのメッセージについて話している......だから何?自作DLLを使わずにwindosの異なるプログラム間でデータをやり取りするための高速な代替手段はないのでしょうか?
私の言葉に気分を害されたこと、私の変種が速いことは理解できます。まあ、第一に、私は断言したのではなく、提案しただけです。2つ目は、Memory Mappingと 比較しながら、テストコードで 裏付けをとったことです。
また、仮定の話でも反論しようとするならば、断定的な発言だけで反論するのはやめてほしい。自作DLLなしで端末間のデータ交換をより高速に実装する方法をご指摘いただき、思いとどまることができれば大変ありがたいです。
RAMディスク経由のバリアントがより高速になることは排除しない。しかし、これはRAMディスクのインストールとその設定が必要なため、少し話が違ってきます。
もちろんです。しかし、このタンバリンを使ったダンスは何なんだ。
タンバリンはこれくらいにしましょう。凡庸さである。ちなみに、この些細なことは、刻み目構造の全受信ブロックが90μs(90 000 ns.)で行われるときに、50〜60nsで行われる。つまり、これらの「ダイヤモンド」はデータブロック受信時間のわずか0.06%を占めるにすぎない。しかも、この点が混乱するのは、記憶倍加の観点からだけだと書きました。
このように、小さなデータ構造の交換には、私のバリアントはとても便利でシンプルでスマートな ようです。
トレーディング、自動売買システム、ストラテジーテストに関するフォーラム
ライブラリ:HistoryTicks
オートメイテッド・トレーディング さん 2018.03.29 11:09
すごい!
CryptEncodeやCryptDecodeの ような関数も知りませんでした。ありがとうございました。
見てみようかな。
しかし、一見するとすべてがハイテクに見えるが、めちゃくちゃ遅い。なぜなら、CryptEncode関数は、ここでタンバリンと名付けられたものよりも2桁も遅く(マイクロ秒対数十ナノ秒)実行されるからだ。
私が「私のバージョンは早い」と言ったことに、お気を悪くされたようですね。まあ、まず、断言したわけではなく、仮定したに過ぎないのですが。2つ目は、Memory Mappingと 比較しながら、テストコードで 裏付けをとったことです。
私は「速さ」ではなく「既存のすべてのソリューションより速いかも しれない」という意味で、攻撃することなく何度か発言しています。 そしてその発言は極めて公正なものでした。 しかしあなたは、なぜかまずそれを執拗に否定し(「おそらく他のコードを見て いるはずだ」)、「だから何!」と突っ込みを入れるのです。そこで、フライとカツを分けて考えて みましょう。
次に、MemoryMapping(正確にはそのMQLラッパー)に関してですが、私はそれが高速 であるとは一言も言っていません。 さらに、このプロジェクトの議論スレッドで、私はラグを発生させる作者のバグとその修正方法を指摘しました。だから、もし何かをテストするのであれば、誰かが間違った判断をした形ではなく、本来の 形でテストすることです。
ZZY しかし、一見するとハイテクだが、めちゃくちゃ遅い。CryptEncode関数は、ここでいうタンバリンよりも2桁(マイクロ秒対数十ナノ秒)遅いからだ。
スピードは何のためにあるのか?
私は「速さ」の話ではなく、「既存のすべてのソリューションよりも速いかもしれない」という話をしたのです。 そしてこの発言は極めて公正なものでした。 ただ、あなたは最初に何らかの理由で頑なに否定し(「おそらく他のコードを見た のだろう」)、そして「だから何!」という立場になるのです。では、フライとカツを分けて みましょう。
第二に、MemoryMapping(正確にはMQLラッパー)に関して、私はそれが高速に動作すると主張したことは一 度もありません。 さらに、このプロジェクトの議論スレッドで、私はラグを発生させる作者のバグとその修正方法を指摘しました。ですから、何かをテストするのであれば、誰かの間違った判断ではなく、ネイティブの形で テストすることです。
オッケーです。同意見です。うるさかったな。
私が出会ったすべての実装はkernel32.dllを使用していたので、おそらくkernel32.dllの代わりにuser32.dllを使用すると、WinAPI経由で2つのターミナルをリンクするときに速くなることが判明している、と言いたかっただけなのです。
何のための速度なのか?
すみません、質問の意味が分かりませんでした。
ご質問の件ですが、なぜ端末間の ブリッジ速度が必要なのでしょうか?
すみません、質問の意味が分かりませんでした。
なぜ、端末間のブリッジデータ交換のスピードが必要なのか、というご質問ですね。
はい。
トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム
mql5言語の特殊性、ヒントとコツ
ニコライ・セムコ さん 2018.09.21 13:20
しかし、これまでのところ、一見すると、すべてのこの、もちろん、ハイテクが、非常識に遅いので、CryptEncode関数は、ここでタンバリンと呼ばれるものよりも遅い(ナノ秒のマイクロ秒対数十)2桁を実行されます。