MMX SSE 3D NOW!のプログラミング

MMX SSE 3D NOW!のプ� ..

2:デフォルトの名無しさん
04/05/28 22:02
2get
>>3どうぞ

3:デフォルトの名無しさん
04/05/28 22:07
2get
>>3どうぞ

4:デフォルトの名無しさん
04/05/28 22:36
またこの手のスレか
またこの手のスレか

5:デフォルトの名無しさん
04/05/28 23:37
VC++6.0SP6用のProcessor Pack早くだせよヴォケ

6:デフォルトの名無しさん
04/05/29 05:13
速くしろよ

7:デフォルトの名無しさん
04/05/29 05:36
/arch:SSE2

8:デフォルトの名無しさん
04/05/29 07:14
>>5
もうでねぇよ

9:デフォルトの名無しさん
04/05/29 12:31
アセンブラスレでいいだろ

10:デフォルトの名無しさん
04/05/29 17:18
>>8
マジ？早く出せよヴォケ！

11:デフォルトの名無しさん
04/05/29 17:56
すぐにアセンブラって言出す奴はアレだな
インテルのコンパイラなんかには
C++のライブラリが含まれているがな。

12:デフォルトの名無しさん
04/05/30 00:08
>>11
それってソース付き？

13:デフォルトの名無しさん
04/06/13 18:02
VC Toolkit 2003 で効率よくSSE2使うコツを話そうぜ。

14:デフォルトの名無しさん ◆TCP/IPmFAM
04/09/26 17:22:39

15:デフォルトの名無しさん
04/10/19 06:28:21
>>13
#include <dvec.h>

16:デフォルトの名無しさん
04/10/23 07:26:59
SSEを使った簡単なプログラムを教えてください。
たとえば1+2はどのように書けばよいのでしょうか？

17:デフォルトの名無しさん
04/10/23 09:13:35
SSE3のスレかと思ったぜ

18:デフォルトの名無しさん
04/10/23 15:39:43
SSE3って何が新しいの？っていうか普及すんの？

19:EXCULTer's / Active metropolis ◆/80RBXpvJA
04/11/12 05:14:46
ＭＡＳＭ３２ｗ

20:デフォルトの名無しさん
04/11/22 16:09:13

21:デフォルトの名無しさん
04/12/08 08:53:11
MMXを使用してフルカラーの画像を拡大縮小するルーチンを書きたいのですが、
どっかに手頃なソースは落ちてないもんでしょうか。
できれば品質ではなくスピード重視のものがいいのですが。

22:21
04/12/08 09:12:25
どうもここら辺が都合が良さげなので調べてみます。

> SDL_Surface * zoomSurface (SDL_Surface *src, double zoomx,
> double zoomy, int smooth);
> Zoomes a 32bit or 8bit 'src' surface to newly created 'dst' surface.
> 'zoomx' and 'zoomy' are scaling factors for width and height. If 'smooth' is 1
> then the destination 32bit surface is anti-aliased. If the surface is not 8bit
> or 32bit RGBA/ABGR it will be converted into a 32bit RGBA format on the fly.
URLﾘﾝｸ(www.ferzkopp.net)

23:21
04/12/08 15:46:22
中身除いてみたらMMX使ってなかったよ... orz
自分で勉強しなきゃ駄目なのかな、とほほ...

24:21
04/12/09 04:08:26
MMXの解説読んでみたら、画像の拡大縮小には
MMXの命令セットは使えそうにもない事が
判明しました。どうすればいいんだ...orz

25:デフォルトの名無しさん
04/12/12 10:16:56
>21-24
ほい＞URLﾘﾝｸ(61.23.56.118)
テストしてないし、補完テーブル作るとこだけ面倒でCだけど。

26:21
04/12/13 07:59:28
おお、いつの間にかレスが! ありがたや、ありがたや。
早速試してみます。

27:デフォルトの名無しさん
05/02/21 12:55:29
MMXでDWORDにアンパックしたやつをDWORDで乗算させるにはどうしたらよいんですか？
pmulはWORDしか対応していないようなので…
誰か助けてください

28:デフォルトの名無しさん
05/02/21 14:44:56
>>27
ヒント
a, b, c, d は16bitの整数で
X = a * 2^16 + b
Y = c * 2^16 + d
とおくと、

X * Y
= (a * 2^16 + b) * (c * 2^16 + d)
= (a*c * 2^32) + ((a*d + b*c) * 2^16) + b*d

あとはお好きなように。

29:デフォルトの名無しさん
05/02/21 14:46:24
あ、^はXORじゃなくて累乗ね

30:デフォルトの名無しさん
05/02/21 16:56:55
素直にシフト使って書けばそんな断りもいらなさそうなものだが。

31:デフォルトの名無しさん
05/02/21 18:01:39
>>28
ありがとうございます。
おちついて調べてみたら、DWORDではなくWORDの乗算でした…
WORDならなんとかなりそうです。

32:デフォルトの名無しさん
05/03/16 05:30:09
>>25
再upして頂く事は出来ませんでしょうか・・・

33:デフォルトの名無しさん
05/07/07 12:01:11
SSEへの最適化のための構造体のアライメントってどうやって調べるのでしょうか？

34:デフォルトの名無しさん
05/07/08 22:12:42
ヒント: offsetof

35:デフォルトの名無しさん
05/07/08 23:23:13
>>33
テキトーにベンチマークプログラム書いて調べるとかｗ
4kB境界に合わせればほぼ確実に最適だと思う

36:デフォルトの名無しさん
05/07/11 14:27:39
3D NOW!使ってるヤシいる？
俺はIntelCPUなのでMMXやSSEしか使ったことがないが。

37:デフォルトの名無しさん
05/07/15 17:42:50
>>36
ノ
pfacc系がとっても便利で気に入っている。

38:デフォルトの名無しさん
05/07/21 16:25:52
>>37
上位と下位の加算か！
いいなあ。MMXやSSEでは使えないもんな。
SSE3には入ったみたいだけど。

39:デフォルトの名無しさん
05/07/21 17:57:27
自分の環境だと初代SSEまでしか使えないorz
新しいコアのAthlon買うかねぇ。

SSEで内積やる時に各積の加算ってどうやってる？
面倒なんでインラインから抜けて普通に書いちゃってるんだけど。

40:デフォルトの名無しさん
05/07/25 19:10:24
>>39
内積やってないけど、抜けたらせっかくのインラインが遅くならない？
俺ならシャッフルして２つ同時に足すかな。

xmm0=(a,b,c,d), xmm1=(e,f,g,h) として、
movaps xmm2, xmm0
shufps xmm0, xmm1, hoge
shufps xmm2, xmm1, hoge

するとこうなる。
xmm0=(e,f,a,b), xmm1=(g,h,c,d)

で、addpsやって同じようにもう１回足せば出るかな。
面倒なのでここまで。すまぬ。

41:デフォルトの名無しさん
05/07/25 19:49:30
やっぱり続き。

movaps xmm2, xmm0
shufps xmm0, xmm2, hoge
addps xmm0, xmm2

これでOKか？試してないけど。
xmm0=(?,e+f+g+h,?,a+b+c+d) となるはず。

42:デフォルトの名無しさん
05/07/25 23:45:43

>>40-41
なるほど。自分ではこんなん考えてみけどどうだろう。

movaps xmm2, xmm0;　　　xmm2 = (a,b,c,d) xmm0 = (a,b,c,d) xmm1 = (e,f,g,h)
unpcklps xmm2, xmm1;　　 xmm2 = (g,c,h,d)
unpckhps xmm0, xmm1;　　xmm0 = (e,a,f,b)
addps xmm0, xmm2;　　　　xmm0 = (e+g, a+c, f+h, b+d)
movhlps xmm1, xmm0;　　 xmm1 = (c, d, e+g, a+c)
addps xmm0, xmm1;　　　　xmm0 = (c+e+g, a+c+d, e+f+g+h, a+b+c+d)
movlps [dst], xmm0;　　　　下半分だけ取り出す。

43:デフォルトの名無しさん
05/07/26 12:50:37
なるほど、規則的なシャッフルならアンパックの方がきれいだね。
簡単なコード書いて速さの測定でもしてみるか。

44:デフォルトの名無しさん
05/07/26 14:10:13
まあどっちにしろストールするような気がするけどねorz
2回連続のシャッフルないしアンパックをどうにかしてばらせないかなぁ

45:デフォルトの名無しさん
05/07/27 16:10:13
Intelのページに、SSE3を使わないコードと使うコードの例が載ってた。

mulps xmm0, xmm1
movaps xmm1, xmm0
shufps xmm0, xmm1, 0xb1
addps xmm0, xmm1
movaps xmm1, xmm0
shufps xmm0, xmm0, 0x0a
addps xmm0, xmm1

これは１個ずつやっているな。

mulps xmm0, xmm1
haddps xmm0, xmm0
haddps xmm0, xmm0

SSE3はすごいなあ。同じhaddpsを続けただけでできてしまう。
ていうか3D Now!もそうか。K6-2が、はまればすごく速かったのがわかる気がした。

ただ、Prescottではhaddpsのタイミングが13-4なんだよな。
上のコードに7+13+13 = 33clkもかかる。
Athlon64だとhaddpsが5-2、mulpsが5-2。5+5+5 = 15clkかな。

ただ、Pen4ならこの33clkのブロック自体を何個も並列に実行しそう。

２個同時でも
haddps xmm0, xmm1
haddps xmm0, xmm0
これでOK。何者だよっていう簡単さだな。
内積を、どう利用するかによって、移動命令で欲しい形式に落とすのも腕の見せ所。

46:デフォルトの名無しさん
05/07/28 18:54:46
>>45
やっぱ要素間演算がないのは皆不満だったらしいね。
便利だけど自分の環境じゃ試せないのが痛いなぁ。

にしてもSSE3は便利なのはいいけどホント遅そうだ。

47:デフォルトの名無しさん
05/07/29 10:06:21
そんなに遅くはないんじゃない？
Prescottはもう死にかけのアーキだし、K8なら速いし。
YonahのSSE3も速くなってると思う。

48:デフォルトの名無しさん
05/07/31 10:18:47
そうかぁ。やっぱSSE3使ってみたいなぁ。
この夏に新しい石のAthlonでも買って試してみるか。

まあPrescottでも流れれば速いのかな？

49:デフォルトの名無しさん
05/08/01 10:26:31
>>48
うん、流れたときの速さは比べるものがないほどだと思う。
リアル128bitでバラバラに動くSIMDは強力。
レジスタ間movapsのレイテンシが6なことなど気にならない。

50:デフォルトの名無しさん
05/08/14 19:40:00
最悪だ・・・ノートのバッテリーが逝ってしまわれた・・・金が・・・
SanDiegoもVeniceもさようなら～orz

51:デフォルトの名無しさん
05/08/25 14:50:35
sse3の使えない環境でsse3を使ったプログラムを走られたらどうなりますか？

52:デフォルトの名無しさん
05/08/25 15:05:09
Illegal Instruction例外で落ちます。

53:デフォルトの名無しさん
05/08/27 19:01:02
>>51
bochsという強力なエミュなら、どんな環境でもSSE,SSE2,SSE3,x64,3dnowなど
なんでもエミュレートできるぞ。
どんな環境でもって言うのはPowerPCでもSPARCでもってこと。

54:デフォルトの名無しさん
05/10/01 21:24:26
人いない・・・

55:デフォルトの名無しさん
05/10/03 14:38:06
ほんとにいませんねえ。
今までにSIMDで何を作ったことがあるか書いていくか？

56:デフォルトの名無しさん
05/10/03 16:24:49
行列の掛け算・・・・

57:デフォルトの名無しさん
05/10/03 18:12:16
いまから拡張命令使ってFirefoxを最適化してみようと思う。

58:名無し募集中。。。
05/10/03 18:45:09
[word data1][word data2][word data3]・・・
[word data100][word data101][word data102]・・・
こんなふうに並列演算したいデータがメモリ上に並んでいない場合
data1とdata3とdata100とdata102を並列計算したい時って
pinsrw でデータを集める以外にうまいやり方ってない？
movq でメモリから64bit取り出してパックしたほうが早いかな？

59:デフォルトの名無しさん
05/10/03 19:58:56
まずはデータ構造を見直せ。
すべてはそこからだ。

60:名無し募集中。。。
05/10/03 20:13:33
データ構造はCCDのRAWデータだから仕方ないよ
[R][G][R][G]
[G][B][G][B] という配列(今回扱うのは1画素12bit)

61:デフォルトの名無しさん
05/10/04 10:54:24
SSEの整数命令って単にMMX命令のオペランドに
MMXレジスタだけじゃなくてSSEレジスタも使えるようになったってだけ？
しかも64ビットまでしか使えないって罠で利点はemmsなしでOKってだけ？

ここからチラシの裏
FirefoxのビルドしたらAthlonノートでやけどしたｗ
しかし最適化といってもどこから手を付けていいのやら。
テテさんとかどうやってんだろうね。

62:デフォルトの名無しさん
05/10/05 09:08:10
>>61
SSE整数は128bit使ってるよ。
ただ、現状ではMMXが速いことが多いけど。

将来的には演算器が強化されてSSEの方が速くなるだろうし、
x64ではレジスタが倍の16本に増えるというメリットもある。

63:デフォルトの名無しさん
05/10/05 19:29:28
SSE2じゃそうだろうけど初代SSEでもできんの？

64:デフォルトの名無しさん
05/10/06 08:58:39
>>63
初代SSEとは、MMX2のことかい？

65:デフォルトの名無しさん
05/10/15 08:03:38
はやくSSEのスループットが１にならないかなー。

66:デフォルトの名無しさん
05/10/15 14:31:23
SSEの演算器だけ倍速作動とかｗ

67:デフォルトの名無しさん
05/10/16 15:41:44
ある程度トランジスタ割けば、SSEユニットを倍積めるんだろうか。
単純に演算器の数を倍にするの。

68:デフォルトの名無しさん
05/10/22 10:59:10
>>61
チラシの裏
MMXのmovqを使ってメモリコピーを高速化してるよ。
SSE系は使ってないみたい。

69:デフォルトの名無しさん
05/10/22 14:11:26
現状じゃ128bitのロード・ストアは遅いもんな。

Pen4だけは128bitの方が速いけど、
これも幅が広いから小回り効かなくて遅いのかな。

70:デフォルトの名無しさん
05/11/21 01:03:24
packed byteな乗算命令がなくて(´・ω・`)ｼｮﾎﾞｰﾝ

71:デフォルトの名無しさん
05/11/21 10:15:15
俺は多倍長データ加算用のSIMD命令がほしい。

72:デフォルトの名無しさん
05/11/23 08:58:42
勝手に3D NOW!!に対応してくれるコンパイラ無いかな。

73:デフォルトの名無しさん
05/11/23 10:03:48
>>72
対応って自動ベクトルか機能のことをいってるのか？
そうならこいつがあるが
URLﾘﾝｸ(www.codeplay.com)

74:デフォルトの名無しさん
05/12/11 10:48:57
CQ出版が15日に出す本が良本ならこのスレも
盛り上がってくれることを信じつつｗｋｔｋ

75:デフォルトの名無しさん
05/12/12 01:08:17
微妙な本だな。大体一章が10ページくらいのB5判だから、
基本的な触りくらいしか出てないようなﾖｶｿ
インテルのマニュアルの方がよっぽど詳しいのではなかろうか。

76:デフォルトの名無しさん
05/12/12 22:36:34
>>75
そら純正マニュアルに敵う本なんてまずないだろ……

77:デフォルトの名無しさん
05/12/15 10:37:25
早速買って来たよ。
SSE2の日本語+絵による解説は使えそう。

78:デフォルトの名無しさん
05/12/16 04:01:41
>>77
nyで

79:デフォルトの名無しさん
06/01/02 01:04:22
altivecはここじゃだめですか

80:デフォルトの名無しさん
06/01/05 19:01:14
SIMD命令を使ったトリッキーなコード、意外な使い方ってないですか。
簡単なやつでもいいので。

URLﾘﾝｸ(homepage1.nifty.com)
の498,519みたいな。

81:デフォルトの名無しさん
06/01/15 17:20:05
iccでemmintrinつかってるんですが、
__m128 <-> __m128dのキャストをインラインアセンブリ
使わずにできます？
倍精度の仮数部の一部を整数演算で０クリアしたいんです。

82:デフォルトの名無しさん
06/01/15 17:45:45
_m128iを引数とする関数で_m128dをそのままの形で使いたいって事でOK？

__m128d a;
__m128i b;
b = _mm_and_si128(*(__m128i*)&a,b);

83:デフォルトの名無しさん
06/01/15 17:53:53
>>82
メモリアクセスするコードが生成されないか心配。

84:デフォルトの名無しさん
06/01/15 18:27:53
んじゃこっち

union {
　　__m128d a_d;
　　__m128i a_i;
}
__m128i b;
(ry

85:デフォルトの名無しさん
06/01/15 22:13:20
助言あんがと。
s=_mm_cvtpd_ps(d);
d=_mm_cvtps_pd(s);
てなことを
d=_mm_and_si128(d,mask);
てな感じで済ませたかったけど、
union使って書くと遅くなったんで最適化してくれないっぽ…
入力がfloatの範囲を越えても動かしたいんだけどなぁ

86:デフォルトの名無しさん
06/01/15 22:18:25
インラインでガリガリ書くしかなくね？

87:デフォルトの名無しさん
06/01/15 23:44:17
なるべくアセンブリは避けたかったですが、
inline __m128d round(__m128d d,__m128i mask){
__asm__ __volatile__ ("pand %1,%0" : "+x"(d) : "x"(mask));
return d;
}
で少し速くなりました。
どもども。

88:デフォルトの名無しさん
06/02/06 14:49:39
720*480のBMPを640*480に縮小するのにMMXを使えないか思案中。

89:デフォルトの名無しさん
06/02/06 16:32:46
640*480側で8ピクセル（24byte=MMX*3）ずつやればいいかな。
720*480側は普通に読むのと3byteずらして読むのをやって
掛け算で加重して・・・あ、MMXの乗算は16bitだけか。
どのくらいの速度になるだろ。

90:デフォルトの名無しさん
06/02/06 18:01:30
久しぶりだったから配列のアドレスをmovでeaxに入れようと四苦八苦してしまったorz
今からbmpの構造を思い出そうとしている俺は完全に出遅れかな？

91:デフォルトの名無しさん
06/02/06 18:42:06
>>90
つoffset

92:デフォルトの名無しさん
06/02/06 21:28:47
>>90
つlea

93:デフォルトの名無しさん
06/02/06 22:07:42
>88
バイリニアをMMXで実装するだけ。
しかも480で縦ライン固定なら１時間くらいで出来るんじゃね？

94:デフォルトの名無しさん
06/02/07 10:21:03
//横のドット数が9と4の倍数の24bitBMPに対し、横を8/9に縮める
void resize(unsigned char *p,int w,int h)
{
　int i,j,k,n;
　n=w/9*h;
　for (k=0; k<n; k++){
　　for (j=0; j<8; j++){
　　　for (i=0; i<3; i++){
　　　　p[(k*8+j)*3+i]=((8-j)*p[(k*9+j)*3+i]+(1+j)*p[(k*9+j+1)*3+i]+4)/9;
　　　}
　　}
　}
}
9ピクセル*n回の処理。まずCで書いて動作することを確かめた（もはや十分な速度だな・・・）。
MMXもこれと同じ方針で行く。

MMXには除算命令がないので乗算で代用。
精度も16bitだから、8bitの数値に対してはほとんど問題ない。

MMX版のコードは、次のように設定して次レスのコードをn回ループさせる。
short m[48]={8,8,8,7,7,7,6,6,6,5,5,5,4,4,4,3,3,3,2,2,2,1,1,1,1,1,1,2,2,2,3,3,3,4,4,4,5,5,5,6,6,6,7,7,7,8,8,8};
n=w/9*h;
eax=m、esi=edi=p
mm5={4,4,4,4} ;=9/2
mm6={7282,7282,7282,7282} ;=10000h/9
mm7={0,0,0,0}

速度は、素通し（HDDのBMPをコピーするだけ）が156ms、MMXが175ms、C版が241ms。
720*480のBMPを5個変換するのにかかった時間（PentiumM）。
まあ、ディスクキャッシュにヒットしなかったら、ずっと遅くなるけど。
本来なら非SIMDアセンブラとの比較もしたいところだが、ここまで。
3個の出力を調べて、MMX版とC版の出力は全て一致していた。

95:デフォルトの名無しさん
06/02/07 10:21:34
xor ecx,ecx
lp0:
movq mm0,[esi+ecx]
movq mm1,mm0
punpcklbw mm0,mm7
punpckhbw mm1,mm7
pmullw mm0,[eax+ecx*2]
pmullw mm1,[eax+ecx*2+8]

movq mm2,[esi+ecx+3]
movq mm3,mm2
punpcklbw mm2,mm7
punpckhbw mm3,mm7
pmullw mm2,[eax+ecx*2+48]
pmullw mm3,[eax+ecx*2+48+8]

paddw mm0,mm2
paddw mm1,mm3
paddw mm0,mm5
paddw mm1,mm5
pmulhw mm0,mm6
pmulhw mm1,mm6
packuswb mm0,mm1
movq [edi+ecx],mm0
add ecx,8
cmp ecx,24
jnz lp0

add esi,27
add edi,24
;MMXでバイリニアてのはどうやるの？

96:デフォルトの名無しさん
06/02/09 09:45:01
>>90
変数の中身へのポインタを取得するとアセンブリでは
lea eax,[esp-12]
のようになるから、movは使えないのだね。

int *a;ならmov eax,aできても、int a[4];だとmov eax,aで氏んだからな。
あのときはけっこう悩んだ。

97:デフォルトの名無しさん
06/02/11 09:08:17
SIMDで計算したいブロックを高級言語で明示できないかな。
たとえば、C言語風の妄想言語...
struct complex_t {
　　 float r, i;
};
foo() {
　　 complex c[4];
　　 VEC( float re : [ c[0].r, c[1].r, c[2].r, c[3].r ], float im : [ c[0].i, c[1].i, c[2].i, c[3].i ] ) {
　　　　 float t = re * re - im * im;
　　　　 im = 2 * re * im;
　　　　 re = t;
　　 }
とか書くと、VECブロックの中が自動的にSIMD命令で構成される。
( SIMD未対応のCPU向けのときは、通常の命令になる )
SIMDで実行するのだから、VECブロック中には分岐はかけず、
ループも固定回数ループだけ。

どう？この妄想言語。

98:デフォルトの名無しさん
06/02/11 11:51:13
１つの構造体がメモリ上でバラバラになってるな。
それはいいとして、組み込み関数と演算子オーバーロードでよくない？

ただ、俺もそういう言語は欲しいと思っていた。
せっかくCPUに色々な命令があるんだから、命令が見える言語がいいよね。
そういう意味じゃCのシフト演算子とかナイスと思った。

99:デフォルトの名無しさん
06/02/11 19:29:54
Intrinsics使えばｲﾝｼﾞｬﾈ?

最終段で機械任せの最適化するなら、
そのままCでも構わないと思うけど。

100:デフォルトの名無しさん
06/02/17 21:01:05
8bitビットマップ(グレースケール)から32bitビットマップへの変換を、MMX使って
実装しようとしているのですが、思っていたよりも早くならずに難渋しています。
　適当なやり方しているのは自覚しているのですが、同じく適当にＣで書いたルーチン
と、リリース版の最適化コミで速度変わらずってのはかなり凹みました。
　どこかもっと最適化する場所があるのでしょうか？　ご存じの方ご教授願います。

void testcopy( void *dst, const void *src, int size )
{
　　int size2 = size >> 1;
　　if(size2 != 0){
　　　　__asm{
　　　　　　mov edi, dst;
　　　　　　mov esi, src;
　　　　　　mov ecx, size2;
　　　　loop_mp:
　　　　　　movq mm0, [esi];
　　　　　　punpcklbw mm0, mm0;
　　　　　　punpcklbw mm0, mm0;
　　　　　　movq [edi], mm0;
　　　　　　lea esi, [esi + 2];
　　　　　　lea edi, [edi + 8];
　　　　　　dec ecx;
　　　　　　jnz loop_mp;
　　　　　　emms;
　　　　}
　　}
}

101:デフォルトの名無しさん
06/02/17 21:20:54
>>100
使用CPUは何？

lea esi, [esi + 2] はadd esi,2 のが無難だと思う。Pen4ならaddのが速い。
movqは8byteだから最後の2byte読むときに6byte余計に読んでしまうのが気持ち悪い。
速度の面からも、読み取りを2byte毎じゃなく4byteか8byteにするべき。
MMX2が使えるならpshufwを使ってもいいかな。

movd mm0, [esi];
punpcklbw mm0, mm0;
movq mm1,mm0
punpcklbw mm0, mm0;
punpckhbw mm1, mm1;
movq [edi], mm0;
movq [edi], mm1;
add esi,4;
add edi,16;
sub ecx,2;
jnz loop_mp;

即興で作って試してないけど、こんなのでどうでしょ。

102:100
06/02/17 21:25:43
>101
>使用CPUは何？
　書き忘れていました。CPUはPen4ですが、諸事情(VC6sp6開発)のため
MMXまでの制限になってます。

103:デフォルトの名無しさん
06/02/17 21:39:40
そういえば、これ処理が軽いからメモリ速度がボトルネックになるね。
おそらくCで書いたルーチンでもメモリ帯域を使い切っているに近いと思う。

ありえん話だが、メモリがL1キャッシュくらい速い環境ならば
>>100氏はCコンパイラに大勝していただろう。

あと、このように毎回実行する余計な処理が4命令もあるので、
ループをアンロールすれば少し速くなると思う。
lea esi, [esi + 2];
lea edi, [edi + 8];
dec ecx;
jnz loop_mp;

>>102
SP6か。それは残念。後でnasmでも使ってみてください。
Pen4だとALUが速くてMMXが遅いからな。

104:デフォルトの名無しさん
06/02/17 22:15:40
画像処理はメモリのアクセス速度がボトルネックだよな～

105:デフォルトの名無しさん
06/02/17 22:30:45
Microsoft Visual C++ Toolkit 2003
URLﾘﾝｸ(msdn.microsoft.com)

106:デフォルトの名無しさん
06/02/17 23:09:57
SSEが使えればprefetchがあるんだけどなぁ。

107:100
06/02/18 10:01:35
　いろいろと助言ありがとうございます。参考にしていろいろ試してみます。

>>103
>後でnasmでも使ってみてください。
　個人で試す分には思いっきりやってみたいところなのですが、
そこまですると引き継ぎが出来なくなって（略）な事になるので……

108:デフォルトの名無しさん
06/02/18 18:14:08
いまどきアーキテクチャー依存のアクセラレータなど流行らん

109:デフォルトの名無しさん
06/02/18 20:32:13
>>97
ivec.h
fvec.h
dvec.h
をインクルード

110:デフォルトの名無しさん
06/02/18 23:38:01
>>109
そういったクラスライブラリじゃなくて言語の拡張仕様に
埋め込んで欲しいって言ってんじゃないの？

111:デフォルトの名無しさん
06/02/19 00:03:31
>>110
そんなことは言ってない

112:デフォルトの名無しさん
06/02/19 00:40:17
俺も妄想言語は考えてるよ。つーかみんな一度は考えてるんじゃないかなぁ

multivalue<　float,　3　>　m0(　1.0f,　2.0f,　3.0f),　m1(　5.0f,　5.0f,　4.0f),　m2;

simd　foreach(　float　v0　in　m0,　float　v1　in　m1,　float　r0　in　m2)
{
float　t　=　v0　*　v0　+　v1　*　v1;　
if(　t　>　0.9f)
r0　=　t;
else
r0　=　0.0f;
}

分岐は、通るブロックは全て実行して最後論理積って形になるかなぁ。
誰か作って、C++へのコンバータでいいからさ。

113:・∀・）っ-○●◎- ◆Pu/ODYSSEY
06/02/19 02:01:05
どうみてもivec.h/fvec.h/dvec.hの使い方慣れたほうが楽です

F32vec4 m0(1.0f, 2.0f, 3.0f, 0.0f);
F32vec4 m1(5.0f, 4.0f, 4.0f, 0.0f);
F32vec4 m2 = m0 * m0 + m1 * m1;
m2 = select_gt(m2, F32vec4(0.9f, 0.9f, 0.9f, 0.9f), m2, F32vec4(0.0f, 0.0f, 0.0f, 0.0f));

114:・∀・）っ[http://www.coins-project.org/] ◆Pu/ODYSSEY
06/02/19 02:15:47
ここが実現してくれるの待ちましょう。どうも税金の無駄遣い臭いのだが。

115:デフォルトの名無しさん
06/02/19 02:28:09
そういや
・データ読み込み
・同アドレスにデータ書き込み
を行った場合、このデータ書き込みの際にmovntiとか使っても全然
早くならないんだけれども、これって対象アドレスに既にデータが入っている
場合、非テンポラル指定はキャッシュ汚染を防ぐためにやるんだから
キャッシュに入っていては意味が無いって事だよな？

116:デフォルトの名無しさん
06/02/20 13:33:53
>100
vcpp5解凍してml.*をコピーすればSSE2命令くらいまで使えたはず、
ってか俺はVC6SP6で使えてる。
もしくは、VC6インスコ→SP5→vcpp5→SP6でもいけた希ガス。

117:デフォルトの名無しさん
06/02/20 13:37:05
434 名前：・∀・）っ-○●◎- ◆Pu/ODYSSEY 投稿日：2006/01/11(水) 00:05:58
論破されてやがるざまぁｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

118:デフォルトの名無しさん
06/02/20 14:09:47
>>115
意味ないね。その場合ってロードをプリフェッチすれば
ピーク性能を引き出せるのかな？

119:100
06/02/20 20:02:21
金曜日にお世話になりました>100 です。
>101 殿のアドバイスを元に、改良版を作成して実験したところ、試行１回あたり
0.01msほど早くなりました（笑
＃640×480サイズ、1万回試行の平均。
MMXレジスタ８本全部使って１６ピクセル分１ループで処理するサンプルも実験
してみましたが（ループ回数削減を企図）、やはりほとんど変わりませんでした。

　処理画像サイズを大きくしても、0.1msほどの違いしか出ないことを考えると、
「メモリ速度がネックになる」という>103、>104 殿の指摘にハマっていそうです。
　他の作業指示が飛んできたので、現状でこれ以上の追求は出来なくなって
しまいましたが、メモリ速度や最適化の意義などについて深く考える良い機会に
なりました。折を見てまたいろいろ試してみたいと思います。

>116 殿
　かなりそれは魅力的な手段ですが……引き継いだ後に環境再構築できる人間が（ｒｙ

120:97
06/02/21 12:50:45
>>111
いや言っている。
どちらかというと言語の標準仕様であってもらいたいね。
件の記法が正式採用されたら最適化エンジンは楽チンにベクトル化出来るし
SIMD使えないときでも依存関係の解析が楽になる。
処理が長いときはスレッド化だってイケる。

どれかの言語がこんな感じの機能を実装したら(あるいは約束したら)、
明日にでもその言語に乗り換えるね。

121:デフォルトの名無しさん
06/02/21 13:18:37
>>119
0.01msか。思ったより効かないな。
prefetchの代替ならmovを使うという手もあるが、この処理の要はmovntqだからな。
後で俺も試してみよう。

122:デフォルトの名無しさん
06/02/21 13:58:35
Win機でのprefetchはいろいろやったけどあまり効かなかった。
効果てきめんな人居る？

別のCPUでうまいこと使って爆発的に速くなった経験はあるから、
ちゃんとはまれば効果があることは理解してるんだけど失敗続き…

VTuneとかでメモリアクセスのパターンとか見れば何とかなるか
と評価版を試してみたけど結局うまく行ってない。残念無念

123:デフォルトの名無しさん
06/02/21 14:03:39
非実用コードで試しても、１割くらい速くなるだけだね。
キャッシュラインは64byteないとほとんど効かないと思う。

124:デフォルトの名無しさん
06/02/21 14:23:50
>>122
PGIの嘘っぽい最適化結果によると
URLﾘﾝｸ(www.softek.co.jp)
だそうな。

125:デフォルトの名無しさん
06/02/21 16:37:15
PGIスレにぎわってないけど、ホントに性能出るもんかねえ？

intelでもオレのケースではまったく効果なかったし（性能クリ
ティカルな部分は全部SIMD化している）、iccで最適化
かけた性能はオレのasmコードにぜんぜんのよばねーし。

126:デフォルトの名無しさん
06/02/21 17:05:03
ハードウェアプリフェッチついてるから、
ソフトウェアプリフェッチの効果薄いのかもね。

メモリアクセスレイテンシ対策にはiccの
#pragma unroll(?)
は段数変えてみると結構効く場合があるね。

127:デフォルトの名無しさん
06/02/21 21:34:42
バタフライ演算が華麗に書けないのは痛いな。他のレジスタにコピーして
別に計算、マスクしてから元のレジスタに加算とか、ステップが余計にかかって
しょうがない。
二次元DCTをFCTで書いたものと、まともにDCTしたものを比べたら、普通の
DCTのほうが幾らか速かったorz
腕が悪い可能性も大だが。

V-Tuneなんつうブルジョアなものは持ってないので、visioでダイヤグラムを
書いて、ペナルティを極力食らわないように組替えてからソースを書きました
とさ。手動最適化マンセー。

128:デフォルトの名無しさん
06/02/21 22:24:19
shuffle命令やSSE3使ってる？

129:デフォルトの名無しさん
06/02/22 10:48:20
SSEすら使ってない。

お客は5、6年位前のスペックでも結構平気で使ってるからな。
SSE3対応の石にせよ、この国ではすでにデスクトップ市場を越えたノート市場で
最近出始めたばかりで、使えないことのほうが多い。

Intel　Macあたりが対象なら、あんま考えなくていいけど。

まぁMMXまでは完全に存在を前提に書いたりするがな。
MMX非対応の石はどのみち絶対性能が不足するので切り捨ててる。

つか、SSE2/3って、本当にごく特殊な演算を除けば、MMXの有無程にはパフォーマンスに影響ないんだよな。

130:デフォルトの名無しさん
06/02/22 11:00:13
>>129
＞SSE2/3って、本当にごく特殊な演算を除けば、MMXの有無程にはパフォーマンスに影響ない
同意

ＭＭＸでの高性能化に比べてＳＳＥ以降はかなりがっかりなのだ。
ＭＭＸと同程度に努力したが同じ率での高速化はしなかったよ。

掛け算に無符号が付いたMMX2は最初からやっとけと

131:デフォルトの名無しさん
06/02/22 11:50:23
ま、あれか。プログラム起動時にCPUの種類を判別して、それぞれに
最適なルーチンを走らせるというのが普通か。

132:デフォルトの名無しさん
06/02/22 12:27:12
手動最適化はMMXだけ使って
SSEはコンパイラに丸投げ

そんなシナリオを想定してある感じ

133:デフォルトの名無しさん
06/02/22 13:04:07
MMXはまぁ当然として、SSEはP3/AthlonXPからだっけ？
x86の浮動小数点命令は使いにくいからSSEでの最適化は欠かせないなぁ。
3D Now! の話題が全く無いのは互換性割り切るほど速度出ないからか。

>129
SSE2/3の命令ってmov系と高精度演算命令系以外になんかあんの？

134:デフォルトの名無しさん
06/02/22 13:47:08
>>133
MendocinoコアCeleronの載ったマシンとか現役で使ってる人が結構いるから
SSEも迂闊に使えないｗｗｗ

もっとも、うちは基本的に整数演算か倍精度実数演算しか滅多に使わない
人なんで、パックド単精度ってそんなに有り難味が無い。
pmovmskbとかmaskmovqとかもそれなりに便利だけど、わざわざ別々の最適化コード
書いてディスパッチするだけの労力に見合った効果も得にくいんだよな。

> SSE2/3
ホラ、あるじゃないか。MMX/3DNOW!を無理矢理二つくっ付けた様な糞命令群が。
このへんは演算ユニットが128bit化するときのための布石と考えてるが。
てか、64bitになるとMMXもそろそろ要らなくなりそうな雰囲気。
飽和演算とか撹拌処理とかやらなくていいなら汎用ALU使ったほうが速度が出るんだよね。

135:デフォルトの名無しさん
06/02/22 15:08:51
>>100のコードと、>>119で使われたと思われるコードで測定してみた。＠PenM
640*480*16で、43.7msと43.2msくらい。1%程度の違いしかない。
最初からL2ヒットであれば>119が倍近く速いので、やはりメモリネック。

ストアに対してprefetchntaを使うと30.8ms。効いてます（ライトスルーのP4では効かないかも）。
ていうかプリフェッチなんかせずにストアをmovntqにすると18.1ms（これはP4でもOKだと思う）。
単純な処理の割に、MMXが効かずSSE（MMX2）が効くというヤツであった。

>>119
仕事で使っているみたいだから無理だとは思うけど、>>100のコードのmovq [edi], mm0;の行を
_asm _emit 0x0f _asm _emit 0xe7 _asm _emit 0x07;//movntq [edi], mm0 のマシン語コード
このように書き換えればmovntqが使えますぜ。
俺の環境だと20.0ms。たった１行書き換えただけで倍以上速くなるのは気持ちいい♪

>>115
prefetchntaが最速だった。
ロードなしのmovntや、ストアなしのprefetchロード、というならもっと速いが、
ロードとストアを両立させようとすると、prefetchntaという結論になる。

136:デフォルトの名無しさん
06/02/22 15:29:56
>>134
＞Mendocinoコア
めんどっちーの、と読むのか？

137:デフォルトの名無しさん
06/02/22 19:52:50
略してマンコア

138:デフォルトの名無しさん
06/02/23 20:53:08
>135 殿
　アドバイスありがとうございます。
　実験してみましたところ、おおよそ速度が4倍にアップしました。
　こりゃすげえ！　と思ったのですが、上長には却下されました。
『だれもわからねぇYo！』だそうで。
　さすがにMMX2まで扱おうとすると、VC6ではやりづらいですね。
上長の上の人に結果まとめてレポしてみて、環境更新するよう具申してみることにします。

　ちなみに、こちらの環境で一番速かったのは、>101殿のアドバイス
を受けたもの(>119報告のもの)の改造版でした。

void test4( void *dst, const void *src, int size )
{　int size2 = size >> 2;
　　if(size2 != 0){　__asm{
　　　　　mov　　　　　　edi,　　dst;
　　　　　mov　　　　　　esi,　　src;
　　　　　mov　　　　　　ecx,　　size2;
　　　loop_mp:
　　　　　movd　　　　 mm0,　　[esi];
　　　　　punpcklbw　　mm0,　　mm0;
　　　　　movq　　　　 mm1,　　mm0;
　　　　　punpcklbw　　mm0,　　mm0;
　　　　　punpckhbw　　mm1,　　mm1;
　　　　　_asm _emit 0x0f _asm _emit 0xe7 _asm _emit 0x07;
　　　　　_asm _emit 0x0f _asm _emit 0xe7 _asm _emit 0x4f _asm _emit 0x08;
　　　　　add　　　　　　esi,　　4;
　　　　　add　　　　　　edi,　　16;
　　　　　sub　　　　　　ecx,　　1;
　　　　　jnz　　　　　　 loop_mp;
　　　　　emms;
　}}
}

139:デフォルトの名無しさん
06/02/23 21:14:55
MMX2って何？SSEで入れられた整数演算？

140:・∀・）っ-○●◎- ◆Pu/ODYSSEY
06/02/23 21:38:09
もともとはSSEの旧い仮称だった気が。

今はへるみ氏あたりが初代AthlonでサポートされたEnhanced 3DNOW!とで
共通で使える拡張命令（要するにSSEのMMX整数演算拡張）を総称して
そう言ってるような。

案外午後な人書き込んでるかもしれんね。

141:デフォルトの名無しさん
06/02/23 22:22:04
浮動小数点形式にすればバタフライ演算は可能になるが、そのかわり
一度に演算できるデータは少なくなる。
16bit整数でバタフライ演算すれば同時に処理できるデータは8点に増えるが、
同じレジスタ内に0以上1未満の整数値(シフト処理したもの)と1以上の
整数値が混在する場合は、バタフライ演算で同時に演算できない。
該当するデータはいったん別のレジスタで処理しなければ成らないため
ステップ数が増える。

精度を保って処理したいなら単精度小数点などで処理するが、リアルタイム
性能を追求するなら整数で処理するしかないかな、と。
まぁ、どうせインテルは本当に便利な命令は用意しない方針のようなので。

142:デフォルトの名無しさん
06/02/23 22:53:27

ソフトウェアパイプライニングとか
手でやってる？コンパイラまかせ？
x64だとレジスタ数も違うし、そもそも
CPUごとにレイテンシ等変わって面倒だよね？

143:・∀・）っ-○●◎- ◆Pu/ODYSSEY
06/02/23 23:01:45
Athlon系はレイテンシが長いからL/S頻度上げてでも並列化汁
PenMは全般にレイテンシ短いから程々でヨシ
NetBurstはパイプラインの長さの分OoOが強力だからあんまり何も考えないほうが
かえって良かったりするかも。

という風に把握している

144:デフォルトの名無しさん
06/02/24 08:45:35
>>142
JIT付きの実行環境が欲しくなるなあ

145:・∀・）っ-○●◎- ◆Pu/ODYSSEY
06/02/24 21:27:24
っ[ドトニート]

146:デフォルトの名無しさん
06/02/26 19:46:12
ん、MMX2ってAMDがつけた3D-Now!の前の名称だったのでは？

MMXを機能拡張したCPUをAMDが出したとき、インテルが「MMXはうちの登録商標
だから使うな」とAMDを訴え、AMDは「マルチメディアエクステンションなんて
平凡な名称だ」と反発していたような。

違ったらｽﾏｿ

147:デフォルトの名無しさん
06/02/27 06:55:48
確かにｸｿ平凡だよな

148:デフォルトの名無しさん
06/02/27 14:28:57
俺はMMX2ってSSEの中でMMXレジスタを使うものをIntelが呼んでいたんだと
思っていたが、何か違うみたいね。ぐぐっても少ないし。

149:・∀・）っ-○●◎- ◆Pu/ODYSSEY
06/02/27 21:14:27
>>146
古いソースを漁ってみるに、MMX2はSSEがまだ世に出る前の仮称。
SSE自体もKatmaiが出始めた頃はiSSE（インターネットストリーミングSIMD拡張）と
呼んでたり。

AMDその他CPUメーカーがMMXを使うこと自体にIntelが提訴したのでは。
Intel側の主張は棄却で和解したはず。

150:・∀・）っ-○●◎- ◆Pu/ODYSSEY
06/02/27 22:06:26
すんまそん、技術自体ではなく名称ですね。
サポートされた拡張命令セットが同一であっても、あくまでカタログ上は
Enhanced 3DNOW!、3DNOW! Professionalなどと称し、SSE、SSE2という商標名は
使ってませんな。

151:デフォルトの名無しさん
06/02/27 22:25:55
3DNow!はSSE+αなんだからSSEと名乗るのは変じゃないか

152:・∀・）っ-○●◎- ◆Pu/ODYSSEY
06/02/27 22:34:40
まぁそうなんだけどEnhanced→ProfessionalはIntelが先行して行ったXMMレジスタ周りの
拡張命令のサポートで、AMD独自の拡張命令の追加は無い
やっぱり商標権のトラブル回避の為でしょうな

153:デフォルトの名無しさん
06/04/25 20:19:34
MMXに命令が追加されたときにユーザーが俗にMMX2と読んだだけなんじゃなかったkk手

154:デフォルトの名無しさん
06/04/25 23:21:44
0x8E574343みたいなHexのデータが延々と続いたデータの
中から、特定のhex列を見つけたいと思ったらアルゴリズムは
別の領域として高速化するのにSSEとかは使えそう？

もし使えそうだったら簡単なサンプル示していただけないでしょうか

155:デフォルトの名無しさん
06/04/25 23:27:01
キャッシュに納まるサイズのデータの中を何度も検索するんじゃなければ
普通にCで書いてもMMX使っても大差ないような気がする。
巨大データ（and 古いCPU）ならむしろ prefetch の有無で変わってくる。

156:デフォルトの名無しさん
06/04/25 23:32:10
えーとCPUはOpteron850とかXeon 3.6Ghz当たりを64コアから512コアぐらいを
想定しています。データは1データあたり1000バイト程度それが秒間900MB/sec
転送されてきますそれをリアルﾀｲﾑで処理しないといけません。そうするとCで
書いても大差ないですか。

157:デフォルトの名無しさん
06/04/26 13:15:35
>154
その程度のサンプルも書けないレベルなら諦めろ。
結局メンテナンス出来ずに回りに迷惑かけるだけだ。
>156みたいな用途ならおとなしくCで書いとけ。

158:デフォルトの名無しさん
06/04/26 19:48:30
900MB/sのネットワークがなんなのか気になる

159:デフォルトの名無しさん
06/04/28 00:41:23
SSEはレジスタが広いけど、
汎用レジスタで最初の4byte一致したら続きを調べるってすれば実質変わらんしなあ。
「特定のhex列」の登場頻度が高いなら別だけど。
あ、でもこれもSSEで並列にやればいいんだ。hexは1/2バイトなのも考えて。
「特定のhex列」のバイト数は？
2バイト単位くらいで比較して、4bitシフトしてまた比較。
一致するものがあったらそこを普通に調べる。
これなら数倍比較コストが減るんじゃないか。
＃まあ、メモリ帯域ネックから高速化はしないと思うよ。

あとはキャッシュラインをまたぐときに気をつけること。ここもうまくやればSSEが有効か？
ていうかCで書いて速度が足りないから>>154で質問したんじゃないよね？
普通にCで十分な速度だと思うよ。

160:デフォルトの名無しさん
06/04/28 02:39:57
スペック見る限り結構な規模のプロジェクトだし、
そんなプロジェクトで汎用性が無くメンテナンス性の悪いアセンブラを使おうってのが間違ってる。
しかも知識も無いときたら周りに迷惑かけるに決まってる。
や　め　と　け。

161:デフォルトの名無しさん
06/04/28 02:47:22
昔似たようなことやったけれどあんまり意味が無かった記憶がある。

162:デフォルトの名無しさん
06/04/28 06:53:08
いまやSSEもAltivecもCで書く時代

163:デフォルトの名無しさん
06/04/28 07:43:02
みんな言ってることは正しいと思うけど、
このスレ的にはアセンブラでSIMDを使い無駄な最適化をするべきじゃないか？

164:デフォルトの名無しさん
06/04/28 10:14:38
＞無駄な最適化
ｗｗｗ
なんかわかるｗ

165:デフォルトの名無しさん
06/05/01 01:01:51
154タンはいなくなってしまったか。。

166:デフォルトの名無しさん
06/05/02 01:27:50
いやいるし勉強してるんだけど、いまいちよくわからない

もう少し修行してきます

167:デフォルトの名無しさん
06/05/02 19:01:46
>>166
いたか。いつでもいいので修行したら報告ヨロ。

168:デフォルトの名無しさん
06/05/03 10:49:45
とりあえず、gasとnasmどっちでインラインすればいいんだろう
gccだと一択なのかな？

169:デフォルトの名無しさん
06/05/03 20:55:17
SIMDの資料ってみなさんはどこから取得してるのでしょうか？

170:デフォルトの名無しさん
06/05/03 21:29:21
URLﾘﾝｸ(www.intel.co.jp)

171:デフォルトの名無しさん
06/05/05 19:42:06
ていうか検索アルゴリズムってどう最適化しても
結局メモリ帯域で頭打ちになるっしょ

172:・∀・）っ-○◎● ◆toBASh....
06/05/05 19:52:44
ここを熱心に読んでたことが、私にもありました。
URLﾘﾝｸ(developer.apple.com)

173:デフォルトの名無しさん
06/05/05 21:00:21
黙れキチガイ

174:デフォルトの名無しさん
06/05/19 01:02:05
組み込み関数を利用してSSEプログラミング勉強しようと頑張ってみたのですが
以下のようなクラスを用意して、一度に16バイトずつuchar型のデータを判別しようと
しましたが、このchar型のデータをSSEで計算するにはどうしたらいいのでしょうか

class CHARVector {
union {
__m128 vec;
struct {
unsigned char c1, c2, c3, c4;
unsigned char c5, c6, c7, c8;
unsigned char c9, c10, c11, c12;
unsigned char c13, c14, c15, c16;
};
};
// ...
};

175:・∀・）っ-○◎● ◆toBASh....
06/05/19 01:26:16
>>174
__m128じゃなくて__m128i使いなよ。ただしSSEじゃなくてSSE「2」ね。
SSEまでなら単精度浮動小数×４までしかサポートされない。

C++ラッパー１から作るくらいなら最初から用意してある物使ったほうがいい。

#include <dvec.h>

VC++かICCならこれで Iu8Vec16 っていうクラスが使えるはず

176:デフォルトの名無しさん
06/05/19 01:32:07
すいません環境書くの忘れたのですが、
RedhatEL4 gccで作成しています。ｇｃｃだとdvec.hが使えないと
聞いて悩んでいました。

177:・∀・）っ-○◎● ◆toBASh....
06/05/19 01:45:07
確かに使えない。
じゃあこっち
#include <emmintrin.h>

__m128i共用体メンバに m128i_u8[16] ってのがある。
あとは

URLﾘﾝｸ(msdn2.microsoft.com)
とかを参考に。

pcmp系関数でマスクしてpmovmskbで各上位ビットを汎用レジスタに転送して再度比較するのが
スマートかな。

178:デフォルトの名無しさん
06/05/19 02:12:04
>>177
うーんサンプルコードってあるのでしょうか？

179:デフォルトの名無しさん
06/06/13 01:35:19
すみません、ANDPDとANDPSって何か違いがあるんでしょうか？
どっちもxmmレジスタ同士のandを取るだけのような……

180:デフォルトの名無しさん
06/06/13 02:35:31
マシン語コードが違う。命令長は同じ。
動作も同じだと思う。
ニーモニックが2つあるのはいいとして、
なぜマシン語コードも違うのか謎ですな。

181:デフォルトの名無しさん
06/06/13 02:52:35
ANDPSは、SSEまでカバーしていれば使える。
建前上、パックド単精度実数が操作対象。
ANDPDは、SSE2をカバーしていないと使えない。
建前上、パックド倍精度実数が操作対象。

182:デフォルトの名無しさん
06/07/05 10:18:10
機械語は敷居が高すぎて手を出せないので、C言語だけで3DNOW!やSSE対応の
プログラムは作れないものでしょうか。

183:デフォルトの名無しさん
06/07/05 10:35:41
MMXやSSE命令をラッピングした組み込み関数が用意されている開発環境があるよ

184:デフォルトの名無しさん
06/07/05 12:47:46
なんでもそうだけど、知らないと食わず嫌いで難しそうに思うけど
やってみるとそうでもないもんだよ。

185:デフォルトの名無しさん
06/07/05 13:03:54
>>183
つか、x64やIL向けだとインラインアセンブラ無効だからそれ使うしかない

186:デフォルトの名無しさん
06/07/05 13:08:38
実際問題mmintrin系組込み関数は構造化設計ができるし、命令スケジューリングの最適化も阻害しないから
結構便利なんだよな

187:デフォルトの名無しさん
06/07/05 14:00:17
命令スケジューリングっていうか、VC++ の場合inline 使うと
前後でも最適化が一切行われないよね。

188:デフォルトの名無しさん
06/07/05 18:17:51
>>187
される。
まさかとは思うがコンパイルオプションミスったり、
デバッグモードで確認なんかしてないよな？

189:デフォルトの名無しさん
06/07/05 19:45:11
ホントダ・・・誰かに騙されていた！！
簡単に確認できるのに確認しない漏れって・・・orz

190:デフォルトの名無しさん
06/07/06 11:38:10
最適化されないのはインラインアセンブラ（__asmステートメント）の前後や中身。
inlineとか__inlineキーワードはむしろグローバルな最適化（高速化）のためのもの

191:デフォルトの名無しさん
06/07/06 15:49:58
>>190
漏れもそう思ってだんだけど、Visual Studio 2005 の C++ で実験してみると
同じ関数内の __asm 後のコードもきっちり最適化されてるわけですよこれが・・・

char a[100]; for (int i = 0; i < 100; i++) a[i] = i; int sum = 0; for (int i = 0; i < 100; i++) sum += a[i];
で、全てC++で書いても最初の初期化のトコを __asm で書いても、後者の加算のループは
5つずつ加算する20回のループに展開されますた。

192:デフォルトの名無しさん
06/07/06 17:24:38
インラインアセンブラの部分まで勝手に最適化されたら神認定なんだが。

193:デフォルトの名無しさん
06/07/06 17:47:13
インラインアセンブラの部分を勝手に最適化しやがったらキレるだろ普通。
アセンブラで記述しなきゃいけない部分は何らかの理由があって
わざわざそういうコードにしてるものもあるのに、
それを別の命令に置き換えられたらブチギレですよ。

194:デフォルトの名無しさん
06/07/06 19:04:49
>>191
関数の前半と後半を__asm{nop}でぶった切ったら最適かもぶった切られたよ。

195:デフォルトの名無しさん
06/07/07 11:33:32
「最適化もぶった切られた」ってのはどういう意味ですか？
後半が素直な100回ループになっちゃったってこと？

196:デフォルトの名無しさん
06/07/07 11:38:45
>>194
コンパイラによって結果は異なってあたりまえだろ。
漏れのとこの VC++ 2005 では __asm{ nop}; 入れてもnpad 1 が間に入るだけで
全く変らないコードが生成された。

197:デフォルトの名無しさん
06/07/07 12:03:47
>>195
__asmをまたいだ最適化はしない、ということかな？

198:196
06/07/07 13:16:40
>>197
そういうことじゃないんじゃないか？漏れのトコでは前述の通り npad 1 の有無だけ。
そもそも__asm 入れなくても「またいだ最適化」みたいなものは無かったし。

単に >>194 の使ってるコンパイラが__asm 入れると最適化しなくなる旧いVCとか
なんじゃまるまいか？

次ページ