SSE AVXのプログラミング

1 ：10/05/26 〜 最終レス ：12/05/28

どうじょ
前スレ
MMX SSE 3D NOW!のプログラミング
http://pc12.2ch.net/test/read.cgi/tech/1085749218/

2 ：

MMXはぶってんじゃねーよ

3 ：

3D NOW!はぶって


よし

4 ：

即死しないといいね。

5 ：

なんか書きこめよ、

6 ：

おい、さっさと俺様に役に立つこと書き込めよ

7 ：

早く書けよ
バカ

8 ：

>>7
即死しなくなるのは 20 くらいだっけ？
君の心意気は買うが、即死しなくなるまで一日一度でよい。

9 ：

>>8
うぜーよてめぇよぉ
誰にけんかうってんだ？
てゆーかさぁ同一人物の書き込みじゃないんだけど？
んなことより、さっさと何か俺の役に立つことを書き込みやがれ

10 ：

>>9
うるせ〜よバ〜カ

11 ：

即死を避けたいのはわかるが、罵倒はさすがにいかがなものか。
それっぽいコードを貼る、といった程度で勘弁してもらいたい。

12 ：

>>9
それはいいんだが、翌日になってから投稿すると、効率よく即死回避できるし、
もしかすると無駄な即死回避投稿する前に誰か何かネタを振ってくれるかも知れない。
だから投稿する前に一日待て。

13 ：

AVX使ってみた奴いる？
ど〜だった？使いやすい？

14 ：

何故？

15 ：

なんか書きこめよ、くずども

16 ：

なんか

17 ：

>>15
無理だろ
たかが１０００レスに６年もかかったんだし
２日に１レスが妥当

18 ：

とりあえず前スレのMMX、SSE2、AMD64比較ベンチのソース
ttp://kawahenteko.hp.infoseek.co.jp/myapp.html

19 ：

すすまねえな

20 ：

インテル(R) Advanced Vector Extensions プログラミング・リファレンス
http://download.intel.com/jp/software/AVE/319433-006JA.pdf
p.86
3.2 YMM ステート管理
> AVX とFMA拡張をサポートするには、OS がYMM ステートを管理する必要がある。
> そうでない場合には、AVXあるいはFMA 拡張命令（VEX エンコーディングによる
> 拡張128 ビットSIMD 命令を含めて）を実行すると#UD 例外が発生する。
原文
Intel(R) Advanced Vector Extensions Programming Reference
http://software.intel.com/file/21558
P.90
3.2 YMM STATE MANAGEMENT
> An OS must enable its YMM state management to support AVX and FMA extensions.
> Otherwise, an attempt to execute an instruction in AVX or FMA extensions(including
> an enhanced 128-bit SIMD instructions using VEX encoding) will cause a #UD exception.

21 ：

http://msdn.microsoft.com/en-us/library/ff545910.aspx
In Windows 7 and Windows Server 2008 R2, both 32-bit and 64-bit versions of the operating system preserve the AVX registers across thread (and process) switches.

22 ：

SSEっていつまでサポートされる？
今後SSEのクロックあたりの実行速度が改善される見込みは？

23 ：

> SSEっていつまでサポートされる？
x86/AMD64がサポートされなくなるまで
>今後SSEのクロックあたりの実行速度が改善される見込みは？
複数のμOPに分解して実行していた命令が、1μOPで実行
できるような改良はありえる

24 ：

ビット論理演算て型によらず結果は一緒だよな？
なんで型ごとにあるんだ？
pxor / xorps / xorps とか。
例外も (対応CPUなら) 同じみたいだし。

25 ：

>>24
もすこしSIMDを勉強したほうがよく寝？

26 ：

>>25
どうしてもわからなくて夜も眠れないから
わかるなら教えてくれ！

27 ：

結果の出し方が違くね？

28 ：

結果の出し方は同じじゃね？

29 ：

整数SIMDブロックとFP-SIMDのブロックのそれぞれに用意されている
演算ユニットを明示的に使うため

30 ：

>>29
何のために？省電力？
パフォーマンスを考えた場合、
xorpd, xorps は PORT5 しか使えず、
pxor はPORT0, PORT1, PORT5 の3つを使える為、
pxor のみで十分だが。

31 ：

パフォーマンスのためだ
異なるブロック間でのデータのやり取りにはペナルティがあるので
各ブロックに演算ユニットが用意されている

32 ：

>>24
歴史的経緯に因る。
pdの追加は謎だけど。

33 ：

ペナルティがあったのって熱湯だけじゃないの？

34 ：

インテル(R) 64 アーキテクチャーおよびIA-32 アーキテクチャー
最適化リファレンス・マニュアル
http://download.intel.com/jp/developer/jpdoc/248966-017JA.pdf
のp.43,.56を読むんだ

35 ：

>>34
chapterごとにページ振ってあるんだが
何章の何ページだ？

36 ：

へー
ポート間じゃなくてintとfpの間に入るんだ

37 ：

addpd xmm0, xmm1
xorpd xmm0, xmm1
addpd xmm0, xmm1
xorpd xmm0, xmm1
....
と
addpd xmm0, xmm1
pxor xmm0, xmm1
addpd xmm0, xmm1
pxor xmm0, xmm1
....
でパフォーマンスを比べてみた。
●実測
Core2Duo の E8400とT7300では同じタイム。
Corei7 では後者が倍時間がかかった。
●シミュレーション
nehalem / sandy とも同タイム。

38 ：

addpd xmm0, xmm1
mulpd xmm2, xmm3
pxor xmm4, xmm5
pxor xmm6, xmm7
pxor xmm8, xmm9
の繰り返し
のように直後に値を使わない場合は
Corei7 だと pxor の方が実測、シミュレーションとも速い。
Core2Duoはこの場合もまったく同じ。

39 ：

整数演算主体のプロジェクトを
/arch:AVXでビルドしてもあまり速くならないの？

40 ：

SSEとAVX-128bitの組み込み関数は共通なので
コンパイラオプションで生成するバイナリを切り替えられる
整数SIMDの組み込み関数を使っているのなら
多少の性能向上はあると思われる

41 ：

>>40
とんくす

42 ：

エスパーだな。
俺はSSEを使っていないコードかと思った。
それだったら、多分最初の実装だとデコーダをカリカリにチューンはしないだろうから
命令の帯域がクリティカルな人は効果あるんじゃない？としか言えない。
命令長が短くなるのと、三項演算のおかげで退避に使う命令を減らせるからコードが全体的に少しだけ小さくなる。

43 ：

プロジェクトのほんのごく一部にSSE2のintrinsicを使ってます。
さらに/arch:SSEではほとんど速くならず、
/arch:SSE2ではかなり高速化したプロジェクトです。

44 ：

整数演算入ったのSSE2だし

45 ：

VCの/archはFPのスカラーコードで使う命令セットを
指定するのが主な使い方なので性能向上に過度な期待は
しないほうがいい

46 ：

分かりました。どうもありがとうございました。

47 ：

>>37-38
スループットの方は単純に fp logic の実行ポート数じゃん (Core2 は3つ、i7 は1つ)
レイテンシの方は、Core2 の fp logic 命令って実は int スタックらしいよ
だからどっち使っても同じ

48 ：

nehalemでは >>37 は前者の方が速いので、
ペナルティがあると考えるのが妥当かと。
ただ、シミュレーションの結果と一致しないのは気になるが。

49 ：

比較対象が違ってるんだが

50 ：

なにが？

51 ：

Nehalem の fp logic は fp スタックだから
他の fp 命令と繋ぐのはペナルティなし、int<->fp 繋ぐのは2クロックペナルティ
ってことで>>34の資料と一致してるんじゃない
シミュレータは多分

52 ：

"シュミレーター" の検索結果
約 334,000 件 （0.14 秒）

53 ：

>>51
Nehalem のFP/SIMD/SSE2 Move and Logic の Domain は FP と書いてあるんだけど、
これって嘘なの？

54 ：

__m128(fp32x4)の任意の要素に任意の値を書き込みたいんだが、
どういう実装がベストなのかな？↓がベストかな？
__m128 set_elem( __m128& v, const uint32_t index, float32_t e )
{
ALIGN(16) const float32_t mask_table[4*4] =
{
1,0,0,0,
0,1,0,0,
0,0,1,0,
0,0,0,1
};
const __m128 mask = _mm_load_ps( mask_table + index * 4 );
return _mm_or_ps( _mm_and_ps( _mm_set1_ps(e), mask ), _mm_andnot_ps( v, mask ) );
}

55 ：

>>54
言語が何か分かんないけど、
float32_t の 1 でマスク作れるの？
andnot って1個目の引数のnotを取ると思うんだけど、順番あってる？
メモリ経由で、直接変更する要素に e を書くのとどっちが早いかなあ。

56 ：

>>55
すいません、どっちも間違ってましたｗ
まあ、実際1要素だけ書き換えなんて
やらないんでしょうねえ。

57 ：

4レジスタくらいなら直接保持したほうが速いと思う
で、値は1レジスタにまとめて読み込んで積をとる

58 ：

画像フォーマットの(en|de)codingで効果を発揮するのはSSE2までだけで十分だったりするの？
SSE3 SSSE3 SSE4まで使って頑張ってもSSE2までしか使わない場合と大して変わらないとかあるの？

59 ：

>>58
だんごさんはSSSE3が画像処理に意外と便利だと言っていたけど

60 ：

SSSE3 SSE4.1 SSE4.2は無用の長物。

61 ：

劇的に速くなることはマレだと思うが、
あれば便利な命令は結構ある。
互換性を考えると使いにくいけどね。
一般向け商用ソフトでパフォーマンスが重要なものの場合、
SSE2/SSE3/SSSE3/SSE4.1/SSE4.2/AVX/FMA....
と、すごい種類の可能性があって、
これらすべて用の関数を設計、チューニング、評価なんてとても出来ないから、
SSSE3/SSE4.1/SSE4.2 なんかは飛ばされがち。

62 ：

OOPのインターフェースつかってSSEのXXを対応したバージョンと、
それ以外のコードの2種類くらいを用意してあげればいいんじゃね？
環境はユーザー責任でスイッチしてもらう。

63 ：

>>62
それやりたいんだけどさ、C++のメンバ関数をアセンブラでどう書けばいいのかがわからない。
インラインアセンブラで書いたプログラムを64ビット用にコンパイルしようとしたら
cl64.exeはインラインアセンブラには対応してないとかエラーが出てコンパイルできないorz

64 ：

>>63
cl64.exeはインラインアセンブラ非対応。
ml64.exeを使うかintrinsic命令を使うかしかない。
>>62
ユーザーが自分でスイッチは無いな。
普通は実行時に自動判別。
事情により新命令を使ったバージョンしか作らないのなら、
対応してないCPUでの実行時は非対応CPUである旨を表示する。
個人で作った個人用アプリなど、非常に限られた人しか使わないのであれば、
非対応CPUで使ったらいさぎよくOSの例外発生メッセージが出るのもありかも。

65 ：

>>63
ぶっちゃけそのプログラムは64ビットネイティブにする必要はあるのか？

66 ：

>>65
おれは最近は、個人でしか使わない趣味のプログラムはすべて64bitネイティブだよ。
レジスタが倍あるし、いまさら窮屈なレジスタ数で組みたくない。
C++オンリーでもパフォーマンスは上だし。

67 ：

制約が緩くなるのはどう考えても悪いことじゃないな

68 ：

>>66そのきもちはすこしわかる。
68系のデータ8本、アドレス8本の環境から、
86系に移ってきたときには窮屈な思いをしたもんだ。

69 ：

>>65
>>63だが、>>66が全部言ってくれた。
インラインアセンブラで組んだウェーブレット変換のプログラムを
ちょっと64ビットで動かしてみたくなったのさ。

70 ：

CL /FA でアセンブリ出力して、修正、アセンブル、リンクですかのう。

71 ：

>>69
ありがとう
/FAオプションつけてコンパイルしたら、.asmファイルが出てきた
やる気出てきた。
ただ、今はDirectCompute用のプログラム書いてるんだけどね．．．
一応strategyパターン使ってCPU用とGPU用の処理を分けてる。

72 ：

自作のSSEラップクラスとXMMATRIXの行列積について
生成されるコードを見比べてみたところ(VC2010EE)
自作のは並べ替えが甘くメモリ退避が多く、そのせいか命令数が倍ぐらいで
XMMATRIXのに比べて1.5倍ぐらい遅かった。
違いといえばXMMATRIXはイントリンシック命令直書きで
自作のは薄いクラスでラップされているぐらい。畳み込みで
同等のコードが生成されるはずなのに・・
結局、イントリンシック命令は直書きしないと
最適化がオミットされちゃうんですかね？

73 ：

>>72
ラップすればするほどパフォーマンスが落ちるのは当たり前だ。
さらに作者の能力や熱意にも大きく依存する。

74 ：

>>72
メモリのアクセスパターンは重要だよ。命令数が同じでも、キャッシュに乗ってないメモリアクセスが入ると途端に遅くなる。

75 ：

>>73
適当なことを言うなよ。
>ラップすればするほどパフォーマンスが落ちるのは当たり前だ。
なぜ当たり前と言えるんだ？
別にいくらラップしようが__forceinlineをつけて展開すれば
最後に出来上がるものは同じじゃねーか。
事実、全てインライン展開されているのは確認しているし、
そっから先最適化するかしないかは、コンパイラがやるかやらないかでしかない。
結局、コンパイラが何か俺のわからない理由で最適化を打ち切っているようにしか
みえない。
>さらに作者の能力や熱意にも大きく依存する。
同等のコードが生成されるはず、と書いているように
そもそも同じ様式を採用している。
>>73
一応、ベンチマークなんで、同じ条件で回している。

76 ：

>>75
じゃあ勝手に好きなようにやれ

77 ：

>>76
結局ちゃちゃいれて終わりか。
なんつーか、無意味な奴。

78 ：

>>75
確かに、よく分からない理由で
コンパイラが最適化の手をゆるめる事はある
PGOを適用すればレジスタをよりうまく使い回して
メモリアクセスが減るけど
Expressじゃ使えないんだよね

79 ：

コンパイラの最適化を過信しすぎだな。

80 ：

http://msdn.microsoft.com/en-us/library/z8y1yy88.aspx
( ﾟ,_Jﾟ)

81 ：

＞自作のは並べ替えが甘くメモリ退避が多く
＞一応、ベンチマークなんで、同じ条件で回している
自己矛盾にも気付けないらしい。

82 ：

>>81
お前バカだろ、もう出てくるなよ。
つーか、何か言いたいことがあるなら
自分が試した結果を交えて話せ。
糞の役にも立たないんだよ。

83 ：

>>82
悪いけど、コンパイラによる話なんだから該当コンパイラのスレでやってくれ。
空気悪くなって迷惑。
それと、具体的なコードを出さない限り具体的な話なんてできないよ。

84 ：

SSEと番人は相性悪いな
結局ループせず必要な回数だけ命令を並べるほうが速い
以上チラ裏でした

85 ：

>>81
自作:メモリ退避が多い
自作じゃない方:メモリ退避が多くないらしい
どう見ても自作の方が不利ですね。ご指摘本当にありがとうございました。

86 ：

進まないね
もう他のCPUのSIMDの話題もおｋにしない？

87 ：

他のCPUってARMのNEONとかか？

88 ：

SSEのプリフェッチ命令を使っても効果が出ない。
使い方がわからないんだよな。

89 ：

距離を測ってそれに合わせたタイミングで発行すればよろし

90 ：

CPU固有の最適化になるわさ
そらICCも_mm_prefetchを消したくなるわ

91 ：

キャッシュが潤沢で
ハードウェアプリフェッチが効いてる環境だと
ソフトウェアプリフェッチは要らないんじゃないの？

92 ：

Core2,、Core iのハードウェアプリフェッチの動作仕様を書いた
文書はあるのか？

93 ：

１．ループの外でバッファの先頭を指定して_mm_prefetch_ntaする。
２．ループ内で、バッファ先頭から順に読んで処理し、_mm_stream_si128で書き出す。
このとき、CPUが気をきかせて、1ループにかかった時間から最適な距離を判断して、
キャッシュ汚染しないプリフェッチをハードウェアで自動的にしてくれたりする？

94 ：

表記間違えてるけどそこは無視してお願い

95 ：

for(i=0;i<16;i++)
a[i]^=(d[i]+c[i])%16;
このプログラムをSSE2で書きたいのですがわかりません。
教えてください。よろしくお願いします。

96 ：

宿題か？

97 ：

暗号を作っているんですけど高速化したいんです。メインループは
for(k=0;k<500000;k++){
for(j=0;j<16;j++){
for(i=0;i<32;i++){
d[i]^=GF[mlt(FG[a[j]],FG[h[i][FG[b[j]]]])];
}
}
こんな感じなんですがGPGより4倍くらい遅いです。

98 ：

>>95
全部あんろーる
>>97
コンパイラさんに任せてあきらめる

99 ：

あんろーるってなんですか？
128ビット単位なので必要のないループが減らせたら高速化できると思うので
基本的に行列演算の高速化だと思います。

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

OpenGLスレ Part18 (126)
◆◇◆dbMAGICってどうよ？◆◇◆ (802)
VB.NET質問スレ(Part38) (879)
パR、パチスロの基盤のプログラム 2 (482)
プログラミング言語 Cyan (187)
Jython、Groovy、JRuby - どれが一番効率的？ (253)
--log9.info------------------
浮かばれるか沈むか暗黙の【林檎的ID】Part134 (766)
おやすみなさいを言うスレ (129)
椎名林檎の整形地獄 (768)
椎名林檎　『歌詞、聞き間違い』 (384)
【石田】林檎板喧嘩上等スレッドRound8【三成】 (620)
覚せい剤大好き！椎名林檎 (188)
【椎名林檎】pvについて語るスレ【東京事変】 (194)
全板トーナメント94 (164)
イモセンスキモハゲと語りあいましょう★２ (858)
迷惑行為防止スレ３ (832)
【林檎】今聴いている曲晒してけ【事変】 (257)
伊澤一葉 part.85 (972)
【東京事変】浮雲２【guitar】 (100)
【林檎】メディア露出総合雑談スレ part.38 (441)
東京事変 Live Tour 2012 Domestique BonVoyage 17 (547)
椎名林檎は ババァ (105)
--log55.com------------------
beatmaniaIIDX 25 CANNON BALLERS 情報スレ part39
【PS4/XB1/PC/NSW】ストリートファイター30thアニバーサリーコレクションInt'l Part.8
ストリートファイターV 初心者スレ37
ストリートファイターV総合Part201
【PS4/XB1】ドラゴンボールファイターズ part.95
VF3tb 総合スレ No.001
Blade Strangers
【PS4/XB1】ドラゴンボールファイターズ 初心者スレ part.1