野心的なアイデア ! - ページ 5 123456789 新しいコメント Igor Makanu 2010.11.11 17:18 #41 Andrei01: 最も簡単なことを知らないから、あなたは勘違いしているのです。 どのアレイのデータも、直線的な順序でメモリに格納される。最初のものから最後のものまで、そして要素 x[15] をアドレス指定するために、コンパイラは配列の先頭のアドレスにシフト 15 を加えて、この変数のアドレスを計算します。2次元の配列、例えばx[2][5]の場合、まず2行目のオフセットを計算し、それに5番目の要素のオフセットを足す、つまり2倍の演算を行うことになります。 x[2] [5] --> x[((2-1)* ArrayRange(x[0])+5)] となります。 x[15]→x(+15)となります。 これはすべてコンパイラレベルですが、静的配列の ArrayRange(x[0]) は常に一定なので、常に計算する必要はなく、一度だけ計算してコンパイル時に保存します。 もしアセンブラをやっているなら、残念ながら、Pentium-Iより古いプロセッサの命令パイプラインの正しいロードに関するロシアのドキュメントを見たことがありませんし、プロセッサの正しいロードは、コンパイラの開発者ではなく、OSとプロセッサアーキテクチャの開発者によっても従事しています。 加算演算の方がプロセッサのクロックサイクルでの実行時間が長くなるのではないかと心配されている方、残念ながら486番プロセッサでは、キャッシュや命令パイプラインのロードに、算術演算や論理演算よりも時間がかかってしまうのです。 SZZY：私は再びアピール - 一次ソースを読み始める、ここでhttps://www.mql5.com/ru/docs/basis/types/classes 開発者mql5は、データの整列を整理する方法を説明し、同じ情報がすべてのコンパイラのためにある、正しくWindowsの呼び出しシステム関数を使用する方法に関する情報がある等 - 私は、OSやプロセッサーの最新の性能に対応したロシアのドキュメントはほとんどなく、大学で教えられるような古いものは、OSやハードウェアの開発段階での現実に対応していない、と言いたいのです。 Andrei01 2010.11.11 17:39 #42 IgorM: x[2] [5] --> x[((2-1)* ArrayRange(x[0])+5)] となります。 x[15]→x(+15)となります。 これはコンパイラレベルの話ですが、静的配列の ArrayRange(x[0]) は常に一定なので、常に計算する必要はなく、コンパイル時に一度計算して保存すれば十分です。 コンパイル段階では、最初の要素のアドレスのみが計算されます。それ以外の要素は、毎回異なるオフセットを介してカウントモードでカウントされます。 2次元配列の場合、列によるオフセットと行番号を掛けた行によるオフセットの2つを数える必要がありますが、もちろん数える過程でも同様です。アセンブラやコンパイラは全く関係なく、実際には計算機資源を正しく利用するための基本的なメモリアドレッシングに過ぎない。 このことから、1次元配列と2次元配列の間でこれほど大きな性能低下があっても、オブジェクトなどより複雑なケースでは、アドレス指定時間がより大幅に遅くなることが容易に理解できるだろう。 Igor Makanu 2010.11.11 18:11 #43 Andrei01: コンパイル時に計算されるのは、最初の要素のアドレスのみです。それ以外の要素は、毎回異なるオフセットを介してカウントモードでカウントされます。 2次元配列の場合、列と行で2つのオフセットを計算する必要があり、行番号を乗じ、もちろんカウント処理でも計算する必要があります。アセンブラやコンパイラは全く関係なく、実際には計算機資源を正しく利用するための基本的なメモリアドレッシングに過ぎないのです。 このことから、1次元配列と2次元配列でこれだけの性能差があっても、オブジェクトなどより複雑なケースでは、アドレス指定時間がさらに遅くなることが容易に理解できるだろう。 現状把握の成功と生産性の低下 コンパイラの最適化、データアクセス設計を自分で行うことに問題はありません。 SZY：オブジェクトは、複雑なケースではない - リンクを作成するためのすべての操作 - コンパイラのレベルで、残念なことに、プロセッサは、オブジェクトかどうかを気にしない、それは "奇跡のプログラマ "がメモリを節約する場合でも、整列データへの相対シフト計算で問題がない - バイトなどの配列でデータを書き込みますが、コンパイラにドキュメントを見ていない、このコードの有効性は鏡でプログラマの独りよがり人相学の反射にのみ表示されます、実際にはそれが偽物です。 Andrei01 2010.11.11 18:22 #44 IgorM: プロセッサはオブジェクトかどうかを気にせず、アラインされたデータに対してオフセットを計算します。 1次元の配列に対して2次元の配列がどれだけ遅くなるかは、コンパイル時ではなく、プログラム実行 時に簡単な例で説明されただけのようです。何度も言うようですが、意味がありません。だから、多かれ少なかれ最適な計算コードを書くという作業は、あまり自分の時間を割いていないことがわかりますし、おそらく必要ないのでしょう。このような場合、OOPはあなたに適した方法で作成されています。:) TheXpert 2010.11.11 18:40 #45 アメーバのカテゴリーで考えているんですね :) . "小さな効率は忘れて、97％くらいを言うべきだ：早まった最適化は諸悪の根 源である。 しかし、その重要な3％のチャンスを逃してはならない」。 このフォーラムで引用されるのは4回目です。 Igor Makanu 2010.11.11 18:57 #46 Andrei01: コンパイルではなく、プログラムの実行過程で、1次元の配列に対して2次元の配列がどれだけ遅くなるか、簡単な例で説明されただけのようです。何度も言うようですが、意味がありません。だから、わざわざ多かれ少なかれ最適な計算コードを書かなくてもいいし、おそらく必要ないのだとわかりますね。このような場合、OOPはあなたに適した方法で作成されています。:) どのような最適化されたコードなのか？コンパイラと仮想マシンの仕組みを全く理解していない プログラマは、各特定のコンパイラにおける物理メモリ要素へのアクセスとアドレッシングがどのように行われているかを調べる必要はない（たとえ斜めであっても、列ではなく、ここでは何もできない） - それは開発者の仕事であり、プログラマがコードに満足しない場合 - 彼は彼のコードを最適化します。 - コードサイズを大きくして、データサイズを小さくして、計算速度を落とすことで - コード内のデータサイズを大きくし、高速化を図ることで - あるいは、別のコンパイラを使用する。 ALL OPTIONSはなくなりました。 OOPは、効率的なコードを書くための別のブランチです。OOPの有効性は、プログラマがアーキテクチャのいくつかの種類の形で数学的モデルを作成できることです - したがって、あなたのコードの偉大な汎用性を達成する、あなたはクラスがデータへの物理アクセスのためのアドレス設定の別のタイプを持っていると思う場合 - あなたは間違っている、その微細な余分なデータ量 - リンクオブジェクトのテーブルが何らかの方法でメモリ内の物理データへのアクセス時間を増加しない、余分なデータは複数で相殺以上であること。 私はショックです - あなたはOOPのたわごとを開始し、その後、多次元および1次元配列のアドレスに関する議論にシフト - あなたはこれをどこかで勉強しましたか、単に - すべての推測と空想？ 多次元配列での 作業は長い鉄のレベルで実装されている - ビデオカードで作業するときに同じZバッファ、ああ、はい、 "羊、鉄の開発者" - あなたに相談していない、と多次元配列のアドレス指定がいかに効果的であるかを学んでいない - すべてのプログラマが二度考えずに多次元配列を使用して、一次元配列での作業時に想像上の効率性のためにコードを増やすことで幸福を探していません。 Alexey Subbotin 2010.11.11 19:40 #47 Andrei01: 情報の信頼性は、それを提示する人によって決まるのでしょうか？良識ある人であれば、情報は主観的なものではなく、客観的なものであることを理解するはずです。:) そして、この問題を理解しようとする人は誰でも、情報は、ついでにその量と同じように、主観的なものであって、客観的なものではないことを理解することになる:))。 Vasiliy Sokolov 2010.11.11 23:15 #48 最近の（特に64ビットの）プログラムの効率は、開発環境やコンパイラによって大きく左右されます。最近のプログラムは、CPUの性能にあまり依存せず、コードの効率性を重視しています。なぜそうなのか、その逆ではないのかを知りたい人は、E・タネンバウムの記念碑的著作「コンピュータ・アーキテクチャ」、特に第5章「Intel IA-64」の項を参照してほしい。古いコンパイラを使った陳腐な手続き型コードでは、通常の開発環境への単純な移行と比較して、これほどの性能向上は望めません。なんというか、アセンブラを例にとると。はい、あるんです。間違いなく、それは永遠に生き続ける。しかし、マルチコアプロセッサや拡張命令セットなどの最新のハードウェアリソースを用いて、通常のIA-64コードを凌駕する性能を持つIA-386コードをアセンブラで書けるとは思えませんね。だからこそ、与えられたものを書き込むべきだという、ひとつの結論が導き出されるのです。.NETを与えられたのなら、それで書かなければならない。他の何千人ものプログラマーに、CILコードのパフォーマンスを上げる方法、スレッドを並列化する方法などを考えさせます。MQL4もそうでしたが、時代は流れてMQL5があります。 MetaQuotesが対応します。どうすれば言語のパフォーマンスを高められるかを考えるようになる。 Andrei01 2010.11.12 03:04 #49 IgorM: プログラマーは、自分のコードに満足できない場合、自分のコードを最適化する。 - コードサイズを大きくし、データサイズを小さくして計算速度を落とすことで - コード内のデータサイズを大きくし、より高速化を図ることで - あるいは別のコンパイラを使用する ALL OPTIONSはなくなりました。 コードの最適化には、実行される初歩的な演算（加算、乗算、メモリアクセス、アドレス計算など）に関して、コード断片がどれだけリソースを消費するかをプログラマが最低限理解することが必要です。これがなければ、原理的に最適化は不可能であり、どんなに優れたコンパイラでも、この貧弱なプログラマには無力であろう。当たり前のことのようですが、なるほど、これは多くのプログラマーにとってもビッグニュースかもしれませんね。:) Andrei01 2010.11.12 03:10 #50 alsu: そして、この問題を理解しようとする人は、情報は量と同じように主観的なものであり、客観的なものではないことに気づくだろう:)) そうですね......いろいろなものを混同して、ガラガラヘビに混ぜないといけませんね。:) 一方は情報源であり、客観的である。もう一方は受信機であり、すべての情報を知覚できるわけではなく、一部しか知覚できないため、主観的である。 123456789 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
最も簡単なことを知らないから、あなたは勘違いしているのです。
どのアレイのデータも、直線的な順序でメモリに格納される。最初のものから最後のものまで、そして要素 x[15] をアドレス指定するために、コンパイラは配列の先頭のアドレスにシフト 15 を加えて、この変数のアドレスを計算します。2次元の配列、例えばx[2][5]の場合、まず2行目のオフセットを計算し、それに5番目の要素のオフセットを足す、つまり2倍の演算を行うことになります。
x[2] [5] --> x[((2-1)* ArrayRange(x[0])+5)] となります。
x[15]→x(+15)となります。
これはすべてコンパイラレベルですが、静的配列の ArrayRange(x[0]) は常に一定なので、常に計算する必要はなく、一度だけ計算してコンパイル時に保存します。
もしアセンブラをやっているなら、残念ながら、Pentium-Iより古いプロセッサの命令パイプラインの正しいロードに関するロシアのドキュメントを見たことがありませんし、プロセッサの正しいロードは、コンパイラの開発者ではなく、OSとプロセッサアーキテクチャの開発者によっても従事しています。
加算演算の方がプロセッサのクロックサイクルでの実行時間が長くなるのではないかと心配されている方、残念ながら486番プロセッサでは、キャッシュや命令パイプラインのロードに、算術演算や論理演算よりも時間がかかってしまうのです。
SZZY：私は再びアピール - 一次ソースを読み始める、ここでhttps://www.mql5.com/ru/docs/basis/types/classes 開発者mql5は、データの整列を整理する方法を説明し、同じ情報がすべてのコンパイラのためにある、正しくWindowsの呼び出しシステム関数を使用する方法に関する情報がある等 - 私は、OSやプロセッサーの最新の性能に対応したロシアのドキュメントはほとんどなく、大学で教えられるような古いものは、OSやハードウェアの開発段階での現実に対応していない、と言いたいのです。
x[2] [5] --> x[((2-1)* ArrayRange(x[0])+5)] となります。
x[15]→x(+15)となります。
これはコンパイラレベルの話ですが、静的配列の ArrayRange(x[0]) は常に一定なので、常に計算する必要はなく、コンパイル時に一度計算して保存すれば十分です。
コンパイル段階では、最初の要素のアドレスのみが計算されます。それ以外の要素は、毎回異なるオフセットを介してカウントモードでカウントされます。
2次元配列の場合、列によるオフセットと行番号を掛けた行によるオフセットの2つを数える必要がありますが、もちろん数える過程でも同様です。アセンブラやコンパイラは全く関係なく、実際には計算機資源を正しく利用するための基本的なメモリアドレッシングに過ぎない。
このことから、1次元配列と2次元配列の間でこれほど大きな性能低下があっても、オブジェクトなどより複雑なケースでは、アドレス指定時間がより大幅に遅くなることが容易に理解できるだろう。
コンパイル時に計算されるのは、最初の要素のアドレスのみです。それ以外の要素は、毎回異なるオフセットを介してカウントモードでカウントされます。
2次元配列の場合、列と行で2つのオフセットを計算する必要があり、行番号を乗じ、もちろんカウント処理でも計算する必要があります。アセンブラやコンパイラは全く関係なく、実際には計算機資源を正しく利用するための基本的なメモリアドレッシングに過ぎないのです。
このことから、1次元配列と2次元配列でこれだけの性能差があっても、オブジェクトなどより複雑なケースでは、アドレス指定時間がさらに遅くなることが容易に理解できるだろう。
現状把握の成功と生産性の低下
コンパイラの最適化、データアクセス設計を自分で行うことに問題はありません。
SZY：オブジェクトは、複雑なケースではない - リンクを作成するためのすべての操作 - コンパイラのレベルで、残念なことに、プロセッサは、オブジェクトかどうかを気にしない、それは "奇跡のプログラマ "がメモリを節約する場合でも、整列データへの相対シフト計算で問題がない - バイトなどの配列でデータを書き込みますが、コンパイラにドキュメントを見ていない、このコードの有効性は鏡でプログラマの独りよがり人相学の反射にのみ表示されます、実際にはそれが偽物です。
プロセッサはオブジェクトかどうかを気にせず、アラインされたデータに対してオフセットを計算します。
1次元の配列に対して2次元の配列がどれだけ遅くなるかは、コンパイル時ではなく、プログラム実行 時に簡単な例で説明されただけのようです。何度も言うようですが、意味がありません。だから、多かれ少なかれ最適な計算コードを書くという作業は、あまり自分の時間を割いていないことがわかりますし、おそらく必要ないのでしょう。このような場合、OOPはあなたに適した方法で作成されています。:)
アメーバのカテゴリーで考えているんですね :) .
"小さな効率は忘れて、97％くらいを言うべきだ：早まった最適化は諸悪の根 源である。 しかし、その重要な3％のチャンスを逃してはならない」。
このフォーラムで引用されるのは4回目です。
コンパイルではなく、プログラムの実行過程で、1次元の配列に対して2次元の配列がどれだけ遅くなるか、簡単な例で説明されただけのようです。何度も言うようですが、意味がありません。だから、わざわざ多かれ少なかれ最適な計算コードを書かなくてもいいし、おそらく必要ないのだとわかりますね。このような場合、OOPはあなたに適した方法で作成されています。:)
どのような最適化されたコードなのか？コンパイラと仮想マシンの仕組みを全く理解していない
プログラマは、各特定のコンパイラにおける物理メモリ要素へのアクセスとアドレッシングがどのように行われているかを調べる必要はない（たとえ斜めであっても、列ではなく、ここでは何もできない） - それは開発者の仕事であり、プログラマがコードに満足しない場合 - 彼は彼のコードを最適化します。
- コードサイズを大きくして、データサイズを小さくして、計算速度を落とすことで
- コード内のデータサイズを大きくし、高速化を図ることで
- あるいは、別のコンパイラを使用する。
ALL OPTIONSはなくなりました。
OOPは、効率的なコードを書くための別のブランチです。OOPの有効性は、プログラマがアーキテクチャのいくつかの種類の形で数学的モデルを作成できることです - したがって、あなたのコードの偉大な汎用性を達成する、あなたはクラスがデータへの物理アクセスのためのアドレス設定の別のタイプを持っていると思う場合 - あなたは間違っている、その微細な余分なデータ量 - リンクオブジェクトのテーブルが何らかの方法でメモリ内の物理データへのアクセス時間を増加しない、余分なデータは複数で相殺以上であること。
私はショックです - あなたはOOPのたわごとを開始し、その後、多次元および1次元配列のアドレスに関する議論にシフト - あなたはこれをどこかで勉強しましたか、単に - すべての推測と空想？
多次元配列での 作業は長い鉄のレベルで実装されている - ビデオカードで作業するときに同じZバッファ、ああ、はい、 "羊、鉄の開発者" - あなたに相談していない、と多次元配列のアドレス指定がいかに効果的であるかを学んでいない - すべてのプログラマが二度考えずに多次元配列を使用して、一次元配列での作業時に想像上の効率性のためにコードを増やすことで幸福を探していません。
情報の信頼性は、それを提示する人によって決まるのでしょうか？良識ある人であれば、情報は主観的なものではなく、客観的なものであることを理解するはずです。:)
プログラマーは、自分のコードに満足できない場合、自分のコードを最適化する。
- コードサイズを大きくし、データサイズを小さくして計算速度を落とすことで
- コード内のデータサイズを大きくし、より高速化を図ることで
- あるいは別のコンパイラを使用する
ALL OPTIONSはなくなりました。
コードの最適化には、実行される初歩的な演算（加算、乗算、メモリアクセス、アドレス計算など）に関して、コード断片がどれだけリソースを消費するかをプログラマが最低限理解することが必要です。これがなければ、原理的に最適化は不可能であり、どんなに優れたコンパイラでも、この貧弱なプログラマには無力であろう。当たり前のことのようですが、なるほど、これは多くのプログラマーにとってもビッグニュースかもしれませんね。:)
そして、この問題を理解しようとする人は、情報は量と同じように主観的なものであり、客観的なものではないことに気づくだろう:))
そうですね......いろいろなものを混同して、ガラガラヘビに混ぜないといけませんね。:)
一方は情報源であり、客観的である。もう一方は受信機であり、すべての情報を知覚できるわけではなく、一部しか知覚できないため、主観的である。