10/03/20 18:08:47
>>439
442:デフォルトの名無しさん
10/03/20 18:09:31
>>439
http://homepage1.nifty.com/herumi/prog/prog90.html#PRECISION
443:デフォルトの名無しさん
10/06/25 01:13:02
新しいOpteron(Magny-Cours)で単精度のSSEのコードを走らせたんだけど、異様に遅い。
スカラーのコードの方が遙かに速いんだけど、そんなことってあるのかな？
インテルのCPUなら概ね2倍になるコードなんだけど、2倍どころか1/3にもなりそうな感じだった。
ただ、倍精度になるとスカラーよりも速くなる。
ICCでやったりgccでいろんなオプション試したけど、あんまりかわらないので何が原因かわからずにいる。
これだけで原因がわかるエスパーな人がいると助かるんだが。
444:デフォルトの名無しさん
10/06/25 13:59:28
URLﾘﾝｸ(pc.watch.impress.co.jp)
＞4つ目は省電力機能の拡張だ。Opteron 6100にはIstanbul世代で実装されていなかったC1E(CPUがスリープモードにあるときの電
＞力を減らす機能)が実装されたほか、「AMD Cool Speed Technology」と呼ばれる省電力機能が実装されており、温度センサーで温
＞度が限界を迎えたと判断したとき、プロセッサのPステートをより低い段階へと強制的に移行させる機能だ。これらの機能により、プロセ
＞ッサの電力効率を前世代に比べて高めている。
CPU温度が高くてクロックダウンしてるとか？
分からんけどｗ
445:デフォルトの名無しさん
10/06/25 20:14:14
>>443
ベクトル化が下手かOpteronの単精度がうんこかOpteronが不得意な命令を使っているか、
だと思う。
ICCはインテルCPU用の最適化しかしないという噂だけど、
gccはそんなことないはずだし。
プログラムの一部でもさらす気があるなら
もうちょっと答えられるかも。
C++とIntrinsicライブラリ？
C++とインラインアセンブラ？
C++とアセンブラ？
32bit? 64bit?
446:デフォルトの名無しさん
10/06/25 20:57:24
>>443
スカラーのコード
x87 or SSEのスカラー命令を使うコード?
SSEのコード
コンパイラの設定でSSEを使うようにしたスカラーコード or 並列化したコード?
447:デフォルトの名無しさん
10/06/26 01:45:18
>>444
これさ、一度CPUクーラーのファンを止めて、高負荷で動かしてみたことがあるんだけど、
マザーから警告のアラームがなって、ヒートシンクをさわったらさわれなくなる位めちゃくちゃ熱くなっていたけど、
実行しているプログラムが落ちることなく、動き続けていたから、相当熱くなるような環境でないと、
クロックが落ちることは無いと思う。よく負荷テストとかでPrime95とかいうFFTを馬鹿みたいに立ち上げる様な
ことをしない限りは無いんじゃないかな。
448:デフォルトの名無しさん
10/06/26 01:54:08
>>445
レスサンクス。
使っているのはC++とIntrinsic。最初はインラインアセンブリで書いていたんだけど、
WindowsのVCCも考えて、Intrinsicに変更した。
コードをさらしたいのだけど、さすがにそれは出来ないので、
ちょっとシンプルなコードを書いて比較してみるよ。
何かわかったら書き込んでみる。
なんとなく思っているのは単精度だとシャッフルやらシフトを多用しているんだけど、
倍精度ではデータ幅の関係でそんなにやらなくていいので、Opteronはシャッフルとかシフトに弱いのかなあ？
とか思っている。
>>446
64bitで使っているんで、もはやコンパイラがx87のコードを吐いてくれません。
ちょっと表現が悪かったけど、SSEと言っているのはベクトル化したSIMDコードという意味。
449:デフォルトの名無しさん
10/06/26 04:22:39
>>448
シャッフルのレイテンシ
AMD Family 10h: 3 cycle
Intel Penryn以降: 1 cycle
450:デフォルトの名無しさん
10/06/26 10:40:33
「OpteronとIntel(Core2?)とで挙動が違う」のが問題であるなら、
キャッシュ構成を疑ってみるのはいかが。
Opteronの一次キャッシュって今も2-wayなの？
451:443
10/06/29 01:29:17
ちょこっと調べてみたら、クリティカルな部分は
ループの中に
for(;;)
{
//A,B,Cその他諸々のデータを取ってきて下記を実施
SSEの計算群1 -> 結果をxmm0に最終的に放り込む
SSEの計算群2 -> 結果をxmm5に最終的に放り込む
SSEの計算群3 -> 結果をxmm10に最終的に放り込む
// メモリへの書き込み
A[i] = xmm0;
B[i] = xmm5;
C[i] = xmm10;
}
と言うような感じなんだけど、メモリへの書き込みの段階で偉く遅くなっていた。
>>450が言うようにキャッシュの問題なんだろうけど、解決方法は無いのかな？
Opteronはライトスルーなのかな？
A、B、Cの結果は再利用されることはないので_mm_stream_ps()でやってみたけど、そっちはもっと遅くなった。
452:デフォルトの名無しさん
10/06/29 03:11:14
配列A,B,Cのサイズを
32kBの倍数+64*n(n=1,2,...,511)
に変える
453:デフォルトの名無しさん
10/06/29 19:57:17
>>451
A,B,Cのサイズは？
SSEの計算群1 -> 結果をxmm0に最終的に放り込む
A[i] = xmm0;
SSEの計算群2 -> 結果をxmm5に最終的に放り込む
B[i] = xmm5;
SSEの計算群3 -> 結果をxmm10に最終的に放り込む
C[i] = xmm10;
とやってみるとか。
Cだけ_mm_stream_psにしてみるとか。
454:デフォルトの名無しさん
10/06/29 22:57:53
キャッシュスラッシングが原因だとすると
スカラーコードではA,B,Cは独立した
ループで処理してるのかな？
455:443
10/06/30 02:18:30
>>453
レスありがとう。
実はすでにやってみたけど変わらなかった。
ひょっとしてレジスタが足りなくなって、xmm0とかが、メモリに待避させられているのでは？
と思ったんだけど。
A,B,Cのサイズ自体多次元配列で、すごく大きいけど、ループの中では4K以下になるように処理している。
たとえば
AAA[i][j][k]の3次元配列があった場合、
A = AAA[i][j]
と1次元は配列として扱っている。そしてA[max]が4KB以下になるようにしている。
>>454
スカラーのコードもA,B,Cでループ内で処理している。
やっぱり、スラッシングが原因なのかなあ？
456: ◆0uxK91AxII
10/06/30 18:03:29
とりあえず、境界を合わせて128[bit]ずつnon temporalな書込みをする。
457:デフォルトの名無しさん
10/06/30 19:03:04
Cだけ_mm_stream_psにしても変わらないならA,B,Cだけが原因じゃなさそうだ。
計算群1,2,3で参照しているメモリがA,B,Cとスラッシングしてるんじゃないかな。
なので、こうしたらどうだろう？
for () {SSEの計算群1-> 結果をA[i]}
for () {SSEの計算群2-> 結果をB[i]}
for () {SSEの計算群3-> 結果をC[i]}
これでも計算群1で参照しているメモリがA[i]とスラッシングしてたらお手上げなんだけど。
458:443
10/07/01 01:21:40
>>456
>>457
いろいろと調べてみたら、キャッシュの問題ではなくて、
NUMAノードの設定が問題だったようだ。
メモリの確保をmalloc()ではなく、numa_alloc_onnode()でダイレクトにNUMAノードを指定してあげたら、
ほぼスカラーの倍の速度が得られたよ。
numactlをつかって、--preferred=nodes --localallocとかいろいろといろいろとオプションを
つけてやってみたけど、うまく指定したノードでのメモリ割り当てが出来ていなかったみたい。
いずれにしてもSSEの問題ではなかったので、変な質問をして申し訳ない。
レスしてくれた人ありがとう。
ただ、プリフェッチの指定をしていた部分でNehalemではかなり効果があったのが、
Opteronでは全く効果が無いので、プリフェッチの距離とかはOpteron用に考えないといけない様だ。
459:デフォルトの名無しさん
10/07/01 08:56:52
OpteronのNUMAは諸刃の剣だな。ハマればメモリの許す限りスケールするしな。
ていうかSMP Opteron由来の問題とは俺も気付かなかった。
460:デフォルトの名無しさん
10/07/23 11:32:54
（０００、０００）10
ー１０、８３５
とかいう問題
461:デフォルトの名無しさん
10/07/27 16:59:37
>>458
First touch 問題だね