キャンバスがカッコいい! - ページ 16 1...91011121314151617181920212223...93 新しいコメント Renat Fatkhullin 2019.01.15 21:37 #151 現在のプロセッサレベルでは、二重計算のブレーキは忘れることができます。ラグがない。 また、整数値への変換による最適化の方法は、すでに本当に時代遅れです。数学で得をするよりも、変換で何倍も損をすることになる。 64ビットコードと我々のコンパイラを考慮すると、二重計算に基づくタスクのクラスでは、整数のことは忘れるべきでしょう。 以下は、Nikolaiの最適化の試みの過去のサンプルです: https://www.mql5.com/ru/forum/1111/page2164#comment_6796332 コンパイラは、64ビットの2つの二重根を異なる式から 計算し、128ビットの1つのアセンブラコマンドにまとめることに成功した。二重計算をする場合、整数型にジャンプ/変換することは強くお勧めしません。変換には野生のCPUオーバーヘッドがあります(私たちのものではありません)。 Ошибки, баги, вопросы 2018.03.11www.mql5.com Общее обсуждение: Ошибки, баги, вопросы Renat Fatkhullin 2019.01.15 21:42 #152 Nikolai Semko:何も丸くしなくてもいいんです。 以下、例としてスクリプトを紹介します。 まず、デフォルトのパラメータ(アンチエイリアスのかかった円、座標と寸法がdouble型)で実行します。 を実行し、パラメータ typ = not_smoothed_circles (非平滑化円、座標とサイズは int 型 - CCanvas クラスのもの) を指定して実行します。それはとてもうまくいった。 2100x550ピクセルのキャンバスでアンチエイリアシングなしで347fps、アンチエイリアシングありで97fpsでした。 ちなみに、ウィンドウの更新レートリミッターは500fpsを設定しています。これは、グラフィックスでどれだけのパフォーマンスを発揮できるかを示しています。 fxsaber 2019.01.15 21:42 #153 Renat Fatkhullin:現在のプロセッサのレベルでは、二重計算のブレーキを忘れることができます。ブレーキがないんです。 また、整数値への変換による最適化の方法は、すでに本当に時代遅れです。数学で得をするよりも、変換で何倍も損をすることになる。 64ビットコードと我々のコンパイラを考慮すると、二重計算に基づくタスクのクラスでは、整数のことは忘れるべきでしょう。 以下は、Nikolaiの最適化の試みの過去のサンプルです: https://www.mql5.com/ru/forum/1111/page2164#comment_6796332 コンパイラは、異なる式からの 2つの64ビット二重根の計算を1つの128ビットアセンブラコマンドにまとめることに成功した。二重計算をする場合、整数型にジャンプ/変換することは強くお勧めしません。変換には野生のCPUオーバーヘッドがあります(私たちのものではありません)。ティックを整数ベースにすれば、Testerの動作が速くなることはほぼ間違いないでしょう。 Алексей Тарабанов 2019.01.15 22:35 #154 Artyom Trishkin:いいえ、それはモーフィングではありません。モーフィングと呼ぶには無理がありますね。 実は、自分で実物を作るのが面倒で、例のフォルダの中にあったんです。モーフィング、文字通り、憮然としている。 Алексей Тарабанов 2019.01.15 22:48 #155 fxsaber:ティックを整数化すれば、テスターの動作が格段に速くなることはほぼ間違いないでしょう。エレーナ・ユリエヴナが言ったように、馬に明らかだ。 Renat Akhtyamov 2019.01.15 23:03 #156 Nikolai Semko:Doomをベースに、@fxsaberさんの アドバイスで。 アルゴリズムは、このサイトの ものを少し修正して使いました。 本当にカッコイイ!ニコライさんは、何を使って絵を描いているのですか? Renat Fatkhullin 2019.01.15 23:06 #157 fxsaber:刻みを整数化すれば、Testerの動作が格段に速くなることはほぼ間違いないでしょう。いいえ。まずは、そのことに気づいてください。 はすべてintsに変換する必要があります。データ変換時のラグが大きいメモリ消費を抑える各操作で100%の確率でオーバーフローが発生し、システムが完全に死亡する。インジケータを読み、ダブりなくイントで動作するように提供された開発者を無視するようになる。そして、ダブとイントの速度の差はもうありません。信じがたいが、そうだ。無駄に上の根拠を挙げたりはしてません。そこでニコライは、あらかじめ計算されたルートテーブルを使って最適化手法を適用しようとしたが、プロセス上でダブルルートをリアルタイムに計算することに負けた。 Artyom Trishkin 2019.01.15 23:08 #158 Алексей Тарабанов:モーフィング、文字通り「死」です。ここで議論するほどのことでもないが、モーフィング(変身) 死んだ人をどこで見るのか、酔いを覚ますのか...。 Алексей Тарабанов 2019.01.15 23:17 #159 Artyom Trishkin:ここで議論するほどのことでもないが、モーフィング(morphing- 変身) 死んだ人を見るところ - 酔いを覚ます...。形態素解析は、死んだ細胞の解析である。まず殺して、顕微鏡で観察するんです。 fxsaber 2019.01.15 23:18 #160 Renat Fatkhullin:いいえ。#define BENCH(A) \ { \ const ulong StartTime = GetMicrosecondCount(); \ A; \ Print("Time[" + #A + "] = " + (string)(GetMicrosecondCount() - StartTime)); \ } template <typename T> T Tester( const int Amount = 1 e7 ) { T Sum = 1; T Price = 1; for (int i = 0; i < Amount; i++) { Price = 1 - Price; Sum += (Sum > Price) ? 1 : 0; } Print(Sum); return(Sum); } void OnStart() { BENCH(Tester<int>()); BENCH(Tester<double>()); } ダブルintはダブルの2倍の速度 10000001 Time[Tester<int>()] = 25523 10000001.0 Time[Tester<double>()] = 51253 1...91011121314151617181920212223...93 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
現在のプロセッサレベルでは、二重計算のブレーキは忘れることができます。ラグがない。
また、整数値への変換による最適化の方法は、すでに本当に時代遅れです。数学で得をするよりも、変換で何倍も損をすることになる。
64ビットコードと我々のコンパイラを考慮すると、二重計算に基づくタスクのクラスでは、整数のことは忘れるべきでしょう。
以下は、Nikolaiの最適化の試みの過去のサンプルです: https://www.mql5.com/ru/forum/1111/page2164#comment_6796332
コンパイラは、64ビットの2つの二重根を異なる式から 計算し、128ビットの1つのアセンブラコマンドにまとめることに成功した。二重計算をする場合、整数型にジャンプ/変換することは強くお勧めしません。変換には野生のCPUオーバーヘッドがあります(私たちのものではありません)。
何も丸くしなくてもいいんです。
以下、例としてスクリプトを紹介します。
まず、デフォルトのパラメータ(アンチエイリアスのかかった円、座標と寸法がdouble型)で実行します。
を実行し、パラメータ typ = not_smoothed_circles (非平滑化円、座標とサイズは int 型 - CCanvas クラスのもの) を指定して実行します。
それはとてもうまくいった。
2100x550ピクセルのキャンバスでアンチエイリアシングなしで347fps、アンチエイリアシングありで97fpsでした。
ちなみに、ウィンドウの更新レートリミッターは500fpsを設定しています。これは、グラフィックスでどれだけのパフォーマンスを発揮できるかを示しています。
現在のプロセッサのレベルでは、二重計算のブレーキを忘れることができます。ブレーキがないんです。
また、整数値への変換による最適化の方法は、すでに本当に時代遅れです。数学で得をするよりも、変換で何倍も損をすることになる。
64ビットコードと我々のコンパイラを考慮すると、二重計算に基づくタスクのクラスでは、整数のことは忘れるべきでしょう。
以下は、Nikolaiの最適化の試みの過去のサンプルです: https://www.mql5.com/ru/forum/1111/page2164#comment_6796332
コンパイラは、異なる式からの 2つの64ビット二重根の計算を1つの128ビットアセンブラコマンドにまとめることに成功した。二重計算をする場合、整数型にジャンプ/変換することは強くお勧めしません。変換には野生のCPUオーバーヘッドがあります(私たちのものではありません)。
ティックを整数ベースにすれば、Testerの動作が速くなることはほぼ間違いないでしょう。
いいえ、それはモーフィングではありません。モーフィングと呼ぶには無理がありますね。
実は、自分で実物を作るのが面倒で、例のフォルダの中にあったんです。
モーフィング、文字通り、憮然としている。
ティックを整数化すれば、テスターの動作が格段に速くなることはほぼ間違いないでしょう。
エレーナ・ユリエヴナが言ったように、馬に明らかだ。
Doomをベースに、@fxsaberさんの アドバイスで。
アルゴリズムは、このサイトの ものを少し修正して使いました。
ニコライさんは、何を使って絵を描いているのですか?
刻みを整数化すれば、Testerの動作が格段に速くなることはほぼ間違いないでしょう。
いいえ。
まずは、そのことに気づいてください。
モーフィング、文字通り「死」です。
ここで議論するほどのことでもないが、モーフィング(変身) 死んだ人をどこで見るのか、酔いを覚ますのか...。
ここで議論するほどのことでもないが、モーフィング(morphing- 変身) 死んだ人を見るところ - 酔いを覚ます...。
形態素解析は、死んだ細胞の解析である。まず殺して、顕微鏡で観察するんです。
いいえ。
ダブルintはダブルの2倍の速度