AMDまたはIntel、およびメモリブランド - ページ 73

 
begemot61 >> :

なぜか。シビアなものの計算速度にも興味津々

まあ、これで3人になりましたね。まだ少ない。

 
joo >> :

あなたの考えがとてもよくわかりました。しかし、テスターへの負荷のかけ方が間違っているのだと思います。一方、私が言いたいことは、あなたは理解していないようですね。でも、そんなことはどうでもいいんです、大体において。いわば「現場」でのオリエンテーションは、最後の専門家でも十分可能です。

OKです。まともな夫の詭弁ではないですよね?)))また、私のインジケータは(突然ですが、見たことがあります)公開実行でもかなりリソースを消費するので、具体的にコードの実行速度に興味があります。

 

グラサンも カウントが速くなるのは大歓迎だと思います。

 
joo >> :

いいえ。みんな、オプティマイザーの仕事とは別に、MTのリソース集約的な作業を見てないだけ。そして、たとえそうであっても、日常業務で使うことはない。少なくとも、ほとんどの人がそうです。でも、気にしないでください。MT5を待ちます。そこのコードの速さは、肉眼で確認できます。そして、CUDAもあります。nVidiaのサイトからツールキットをダウンロードしましたので、これから勉強します。また、そのコードをDLLに転送することも問題ありません。

CUDAに関しては、計算が10~100倍に加速された例を見たことがあります。一部の医療用アプリケーション向け。また、大学ではすでにCUDAのプログラミングが教えられています。しかし、それはとても面倒な仕事です。つまり、C言語も似たようなものですが、タスクを正しく分割し、GPUの特殊性を考慮し、整数計算を行う必要があるのです。非常に低レベルなプログラミングであることがわかります。また、すべてのタスクが簡単にこのタイプに還元され、半年後にも実利を得られるとは限りません。ただし、例えば整数行列の演算は、ほぼ完璧にCUDAに変換されます。
 
begemot61 >> :
CUDAについては、計算が10倍から100倍に加速された例を見たことがあります。一部の医療用アプリケーション向け。また、大学ではすでにCUDAのプログラミングが教えられています。でも、とても面倒なんです。つまり、C言語も似たようなものですが、タスクを正しく分割し、GPUの特殊性を考慮し、整数計算を行う必要があるのです。非常に低レベルなプログラミングであることがわかります。また、すべてのタスクが簡単にこのタイプに還元され、半年後に実利を得ることができるわけではありません。ただし、例えば整数行列の演算は、ほぼ完璧にCUDAに変換されます。

分散コンピューティング環境であるOpenCLプロジェクトが あります。AMDやnVidiaなど、ほぼ全員が関わっている。そこには、より高い抽象度があるのです。リンク先にはコードサンプルがあり、ご覧の通りC言語(C99規格)です。

 

ソースは勉強しました、午後には報告します、もう寝る時間です。

その結果は、多かれ少なかれ明らかです。

 

私の発見を簡単に述べてみる。

Expert Advisorを最適化 する際、テスターは数十MBのメモリを使用します。例えば、私の場合、1年分のfxt-fileにオープンごとの議事録が入っていて、約36MBあります。この履歴はメモリに保存され、多かれ少なかれランダムにアクセスされる。このモードでは、メモリは「理想的な」ケースで処理できるデータ量をプロセッサに提供するのに十分な速度を提供しません。ここで重要な役割を果たすのが、キャッシュである。

ここからが一番面白いところです。

1) キャッシュミスの場合、メモリアクセスの速度とレイテンシが重要な役割を果たすのは明らかである。ここで、プロセッサーは2つのグループに分けられる。

a) AtomとCore 2 - メモリコントローラは「ノースブリッジ」(North Bridge - NB)チップセット内にあります。

b) その他はすべて、(プロセッサに)統合されたメモリコントローラ(ICP)付き。

この場合、グループaのプロセッサはグループbのプロセッサに大きく負ける可能性があります。とはいえ、Core i7 ICPはAMDプロセッサーに比べればはるかに効率的です。これが、Core i7の文句なしの勝因の一つです。

2) キャッシュが効果的に待ち時間を隠すためには、できるだけ大きく、連想性があり(CPU-Zのスクリーンショットではx-way)、本質的な待ち時間が少ないことが必要である。

そして、ここではキャッシュ量に応じた速度でプロセッサが明確に並んでいます(他の条件はすべて同じです)。

- 最も遅いCPUは512KBのキャッシュを持つCeleronです(Atomは考慮に入れていません - そのアーキテクチャは性能よりも経済性を重視して設計されています)。

- Athlon - キャッシュサイズが小さいので、ICPによる影響が少ない。

- Celeron 900、1MBキャッシュ搭載。

- Core 2プロセッサでキャッシュ3〜6MB、キャッシュ量の多いモデルは少し的外れ。

- Phenom IIでは、6MBのキャッシュ(しかも最大48ウェイ!)がICPと組み合わされています。

- 3チャンネルRPC(一般に非常に高速)、最大8MBのL3キャッシュ(これも非常に高速)など、最も先進的なものをすべて兼ね備えています。

オーバークロックするとPhenomの効率が下がり、Core i7の効率が上がる理由については。

これらのプロセッサでは、ICPとL3キャッシュが別々にクロック駆動されている(一方、L1/L2キャッシュは常にCPUの周波数で動作している)。

しかし、Belford 氏のオーバークロックの方法は、L3キャッシュをオーバークロックせずに、CPUの倍率を上げる(彼はBE - Black Editionシリーズのプロセッサを持っているが、通常は上の 倍率が制限されている)ものである。

一方、Core i7(XEを除く)のオーバークロックは、ベース周波数(BCLK)を上げることでのみ可能です。これは、L3キャッシュを持つIC(Core ixではこれをUncoreと呼ぶ)のオーバークロックにもなる。

つまり、Belfordの PhenomのL3速度は常に2009.1MHzに固定されているわけだ。そしてYuraZでは、並の2.13GHzから、4GHzにオーバークロックすると3.2GHzまで加速する。(CPU BCLK×20、アンコアBCLK×16)。そして、CPU周波数が3.33GHzのXeonに対して、Uncoreは2.66GHzで動作する。

その点、Core i7のL3キャッシュは2.13GHzでもPhenomのL3キャッシュの2GHzより明らかに高速に動作する。また、当然ながら3.2GHzとはるかに高速で、このテストにおけるCore i7の優れたスケーラビリティを保証しています。

今は、詳しい調査をしていないので、憶測の域を出ないのですが。しかし、 最適化速度はキャッシュのサイズと性能に強く依存 し、プロセッサの周波数にはやや劣るようです。

 
Docent >> :

私の発見を簡単に述べてみる。

Expert Advisorを最適化する際、テスターは数十MBのメモリを使用します。例えば、私の場合、1年分のfxt-fileにオープンごとの議事録が入っていて、約36MBあります。この履歴はメモリに保存され、多かれ少なかれランダムにアクセスされる。このモードでは、メモリは「理想的な」ケースで処理できるデータ量をプロセッサに提供するのに十分な性能を発揮しません。ここで重要な役割を果たすのが、キャッシュである。

ここからが一番面白いところです。

1) キャッシュミスの場合、メモリアクセスの速度とレイテンシが重要な役割を果たすのは明らかである。ここで、プロセッサーは2つのグループに分けられる。

a) AtomとCore 2 - メモリコントローラは「ノースブリッジ」(North Bridge - NB)チップセット内にあります。

b) その他はすべて、(プロセッサに)統合されたメモリコントローラ(ICP)付き。

この場合、グループaのプロセッサはグループbのプロセッサに大きく負ける可能性があります。とはいえ、Core i7 ICPはAMDプロセッサーに比べればはるかに効率的です。これが、Core i7の文句なしの勝因の一つです。

2) キャッシュが効果的に待ち時間を隠すためには、できるだけ大きく、連想性があり(CPU-Zのスクリーンショットではx-way)、本質的な待ち時間が少ないことが必要である。

そして、ここではキャッシュサイズに依存した速度という点で、プロセッサが明確に並んでいます(他の条件はすべて同じです)。

- 最も遅いCPUは512KBのキャッシュを持つCeleronです(Atomは考慮に入れていません - そのアーキテクチャは性能よりも経済性を重視して設計されています)。

- Athlon - キャッシュサイズが小さいので、ICPによる影響が少ない。

- Celeron 900、1MBキャッシュ搭載。

- Core 2プロセッサでキャッシュ3〜6MB、キャッシュ量の多いモデルは少し的外れ。

- Phenom IIでは、6MBのキャッシュ(しかも最大48ウェイ!)がICPと組み合わされています。

- と最速のCore i7は、ここですべての最も進歩的な - 3チャネル(と一般的に非常に高速)RPCと8 MBの最大の(そして再び非常に高速)L3キャッシュを兼ね備えています。

オーバークロックするとPhenomの効率が下がり、Core i7の効率が上がる理由については。

これらのプロセッサでは、ICPとL3キャッシュが別々にクロック駆動されている(一方、L1/L2キャッシュは常にCPUの周波数で動作している)。

しかし、Belford氏のオーバークロックの方法は、L3キャッシュをオーバークロックせずに、CPUの倍率を上げる(彼はBE - Black Editionシリーズのプロセッサを持っているが、通常は上の倍率が制限されている)ものである。

一方、Core i7(XEを除く)のオーバークロックは、ベース周波数(BCLK)を上げることでのみ可能です。これは、L3キャッシュを持つIC(Core ixではこれをUncoreと呼ぶ)のオーバークロックにもなる。

つまり、PhenomのL3速度は常に2009.1MHzに固定されているわけだ。そしてYuraZでは、並の2.13GHzから、4GHzにオーバークロックすると3.2GHzまで加速する。(CPU周波数BCLK×20、アンコアBCLK×16)。そして、CPU周波数が3.33GHzのXeonに対して、Uncoreは2.66GHzで動作する。

その点、Core i7のL3キャッシュは2.13GHzでもPhenomのL3キャッシュの2GHzより明らかに高速に動作する。また、当然ながら3.2GHzとはるかに高速で、このテストにおけるCore i7の優れたスケーラビリティを保証しています。

今は、詳しい調査をしていないので、憶測のレベルです。しかし、最適化速度はキャッシュのサイズと性能に強く依存し、プロセッサの周波数にはやや劣るようです。

ありがとうございます。とても説得力があると思います。私もそう思います。

 
Docent >>: Но похоже, что скорость оптимизации сильно зависит от объема и быстродействия кэша, и несколько меньше от частоты процессора.

少し説明します。最適化のスピードはプロセッサの周波数よりも キャッシュのサイズや性能に依存 すると考えてよいでしょうか。

 
HideYourRichess писал(а)>>

少し説明します。最適化速度はプロセッサの周波数よりも キャッシュのサイズや性能に依存 すると考えてよいのでしょうか?

それが判明したのです。しかし、今のところまだ仮定 であり、私の投稿ではそのことを強調しました