２ちゃんねる ■掲示板に戻る■ 全部 1- 最新50 [PR]話し相手はここにいるかも【ASKS?】[PR]

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

1 ：デフォルトの名無しさん：04/05/28 22:00: どうぞ
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.
http://www.ferzkopp.net/~aschiffler/Software/SDL_gfx-2.0/
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
ほい＞http://61.23.56.118/bilinear.zip
テストしてないし、補完テーブル作るとこだけ面倒で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 ：デフォルトの名無しさん：2005/07/07(木) 12:01:11: SSEへの最適化のための構造体のアライメントってどうやって調べるのでしょうか？
34 ：デフォルトの名無しさん：2005/07/08(金) 22:12:42: ヒント: offsetof
35 ：デフォルトの名無しさん：2005/07/08(金) 23:23:13: >>33
テキトーにベンチマークプログラム書いて調べるとかｗ
4kB境界に合わせればほぼ確実に最適だと思う
36 ：デフォルトの名無しさん：2005/07/11(月) 14:27:39: 3D NOW!使ってるヤシいる？
俺はIntelCPUなのでMMXやSSEしか使ったことがないが。
37 ：デフォルトの名無しさん：2005/07/15(金) 17:42:50: >>36
ノ
pfacc系がとっても便利で気に入っている。
38 ：デフォルトの名無しさん：2005/07/21(木) 16:25:52: >>37
上位と下位の加算か！
いいなあ。MMXやSSEでは使えないもんな。
SSE3には入ったみたいだけど。
39 ：デフォルトの名無しさん：2005/07/21(木) 17:57:27: 自分の環境だと初代SSEまでしか使えないorz
新しいコアのAthlon買うかねぇ。

SSEで内積やる時に各積の加算ってどうやってる？
面倒なんでインラインから抜けて普通に書いちゃってるんだけど。
40 ：デフォルトの名無しさん：2005/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 ：デフォルトの名無しさん：2005/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 ：デフォルトの名無しさん：2005/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 ：デフォルトの名無しさん：2005/07/26(火) 12:50:37: なるほど、規則的なシャッフルならアンパックの方がきれいだね。
簡単なコード書いて速さの測定でもしてみるか。
44 ：デフォルトの名無しさん：2005/07/26(火) 14:10:13: まあどっちにしろストールするような気がするけどねorz
2回連続のシャッフルないしアンパックをどうにかしてばらせないかなぁ
45 ：デフォルトの名無しさん：2005/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 ：デフォルトの名無しさん：2005/07/28(木) 18:54:46: >>45
やっぱ要素間演算がないのは皆不満だったらしいね。
便利だけど自分の環境じゃ試せないのが痛いなぁ。

にしてもSSE3は便利なのはいいけどホント遅そうだ。
47 ：デフォルトの名無しさん：2005/07/29(金) 10:06:21: そんなに遅くはないんじゃない？
Prescottはもう死にかけのアーキだし、K8なら速いし。
YonahのSSE3も速くなってると思う。
48 ：デフォルトの名無しさん：2005/07/31(日) 10:18:47: そうかぁ。やっぱSSE3使ってみたいなぁ。
この夏に新しい石のAthlonでも買って試してみるか。

まあPrescottでも流れれば速いのかな？
49 ：デフォルトの名無しさん：2005/08/01(月) 10:26:31: >>48
うん、流れたときの速さは比べるものがないほどだと思う。
リアル128bitでバラバラに動くSIMDは強力。
レジスタ間movapsのレイテンシが6なことなど気にならない。
50 ：デフォルトの名無しさん：2005/08/14(日) 19:40:00: 最悪だ・・・ノートのバッテリーが逝ってしまわれた・・・金が・・・
SanDiegoもVeniceもさようなら～orz
51 ：デフォルトの名無しさん：2005/08/25(木) 14:50:35: sse3の使えない環境でsse3を使ったプログラムを走られたらどうなりますか？
52 ：デフォルトの名無しさん：2005/08/25(木) 15:05:09: Illegal Instruction例外で落ちます。
53 ：デフォルトの名無しさん：2005/08/27(土) 19:01:02: >>51
bochsという強力なエミュなら、どんな環境でもSSE,SSE2,SSE3,x64,3dnowなど
なんでもエミュレートできるぞ。
どんな環境でもって言うのはPowerPCでもSPARCでもってこと。
54 ：デフォルトの名無しさん：2005/10/01(土) 21:24:26: 人いない・・・
55 ：デフォルトの名無しさん：2005/10/03(月) 14:38:06: ほんとにいませんねえ。
今までにSIMDで何を作ったことがあるか書いていくか？
56 ：デフォルトの名無しさん：2005/10/03(月) 16:24:49: 行列の掛け算・・・・
57 ：デフォルトの名無しさん：2005/10/03(月) 18:12:16: いまから拡張命令使ってFirefoxを最適化してみようと思う。
58 ：名無し募集中。。。：2005/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 ：デフォルトの名無しさん：2005/10/03(月) 19:58:56: まずはデータ構造を見直せ。
すべてはそこからだ。
60 ：名無し募集中。。。：2005/10/03(月) 20:13:33: データ構造はCCDのRAWデータだから仕方ないよ
[R][G][R][G]
[G][B][G][B] という配列(今回扱うのは1画素12bit)
61 ：デフォルトの名無しさん：2005/10/04(火) 10:54:24: SSEの整数命令って単にMMX命令のオペランドに
MMXレジスタだけじゃなくてSSEレジスタも使えるようになったってだけ？
しかも64ビットまでしか使えないって罠で利点はemmsなしでOKってだけ？

ここからチラシの裏
FirefoxのビルドしたらAthlonノートでやけどしたｗ
しかし最適化といってもどこから手を付けていいのやら。
テテさんとかどうやってんだろうね。
62 ：デフォルトの名無しさん：2005/10/05(水) 09:08:10: >>61
SSE整数は128bit使ってるよ。
ただ、現状ではMMXが速いことが多いけど。

将来的には演算器が強化されてSSEの方が速くなるだろうし、
x64ではレジスタが倍の16本に増えるというメリットもある。
63 ：デフォルトの名無しさん：2005/10/05(水) 19:29:28: SSE2じゃそうだろうけど初代SSEでもできんの？
64 ：デフォルトの名無しさん：2005/10/06(木) 08:58:39: >>63
初代SSEとは、MMX2のことかい？
65 ：デフォルトの名無しさん：2005/10/15(土) 08:03:38: はやくSSEのスループットが１にならないかなー。
66 ：デフォルトの名無しさん：2005/10/15(土) 14:31:23: SSEの演算器だけ倍速作動とかｗ
67 ：デフォルトの名無しさん：2005/10/16(日) 15:41:44: ある程度トランジスタ割けば、SSEユニットを倍積めるんだろうか。
単純に演算器の数を倍にするの。
68 ：デフォルトの名無しさん：2005/10/22(土) 10:59:10: >>61
チラシの裏
MMXのmovqを使ってメモリコピーを高速化してるよ。
SSE系は使ってないみたい。
69 ：デフォルトの名無しさん：2005/10/22(土) 14:11:26: 現状じゃ128bitのロード・ストアは遅いもんな。

Pen4だけは128bitの方が速いけど、
これも幅が広いから小回り効かなくて遅いのかな。
70 ：デフォルトの名無しさん：2005/11/21(月) 01:03:24: packed byteな乗算命令がなくて(´・ω・`)ｼｮﾎﾞｰﾝ
71 ：デフォルトの名無しさん：2005/11/21(月) 10:15:15: 俺は多倍長データ加算用のSIMD命令がほしい。
72 ：デフォルトの名無しさん：2005/11/23(水) 08:58:42: 勝手に3D NOW!!に対応してくれるコンパイラ無いかな。
73 ：デフォルトの名無しさん：2005/11/23(水) 10:03:48: >>72
対応って自動ベクトルか機能のことをいってるのか？
そうならこいつがあるが
ttp://www.codeplay.com/japanese/vectorc/feat-vec.html
74 ：デフォルトの名無しさん：2005/12/11(日) 10:48:57: CQ出版が15日に出す本が良本ならこのスレも
盛り上がってくれることを信じつつｗｋｔｋ
75 ：デフォルトの名無しさん：2005/12/12(月) 01:08:17: 微妙な本だな。大体一章が10ページくらいのB5判だから、
基本的な触りくらいしか出てないようなﾖｶｿ
インテルのマニュアルの方がよっぽど詳しいのではなかろうか。
76 ：デフォルトの名無しさん：2005/12/12(月) 22:36:34: >>75
そら純正マニュアルに敵う本なんてまずないだろ……
77 ：デフォルトの名無しさん：2005/12/15(木) 10:37:25: 早速買って来たよ。
SSE2の日本語+絵による解説は使えそう。
78 ：デフォルトの名無しさん：2005/12/16(金) 04:01:41: >>77
nyで
79 ：デフォルトの名無しさん：2006/01/02(月) 01:04:22: altivecはここじゃだめですか
80 ：デフォルトの名無しさん：2006/01/05(木) 19:01:14: SIMD命令を使ったトリッキーなコード、意外な使い方ってないですか。
簡単なやつでもいいので。

http://homepage1.nifty.com/herumi/adv/bbslog/bbs11.html
の498,519みたいな。
81 ：デフォルトの名無しさん：2006/01/15(日) 17:20:05: iccでemmintrinつかってるんですが、
__m128 <-> __m128dのキャストをインラインアセンブリ
使わずにできます？
倍精度の仮数部の一部を整数演算で０クリアしたいんです。
82 ：デフォルトの名無しさん：2006/01/15(日) 17:45:45: _m128iを引数とする関数で_m128dをそのままの形で使いたいって事でOK？

__m128d a;
__m128i b;
b = _mm_and_si128(*(__m128i*)&a,b);
83 ：デフォルトの名無しさん：2006/01/15(日) 17:53:53: >>82
メモリアクセスするコードが生成されないか心配。
84 ：デフォルトの名無しさん：2006/01/15(日) 18:27:53: んじゃこっち

union {
　　__m128d a_d;
　　__m128i a_i;
}
__m128i b;
(ry
85 ：デフォルトの名無しさん：2006/01/15(日) 22:13:20: 助言あんがと。
s=_mm_cvtpd_ps(d);
d=_mm_cvtps_pd(s);
てなことを
d=_mm_and_si128(d,mask);
てな感じで済ませたかったけど、
union使って書くと遅くなったんで最適化してくれないっぽ…
入力がfloatの範囲を越えても動かしたいんだけどなぁ
86 ：デフォルトの名無しさん：2006/01/15(日) 22:18:25: インラインでガリガリ書くしかなくね？
87 ：デフォルトの名無しさん：2006/01/15(日) 23:44:17: なるべくアセンブリは避けたかったですが、
inline __m128d round(__m128d d,__m128i mask){
__asm__ __volatile__ ("pand %1,%0" : "+x"(d) : "x"(mask));
return d;
}
で少し速くなりました。
どもども。
88 ：デフォルトの名無しさん：2006/02/06(月) 14:49:39: 720*480のBMPを640*480に縮小するのにMMXを使えないか思案中。
89 ：デフォルトの名無しさん：2006/02/06(月) 16:32:46: 640*480側で8ピクセル（24byte=MMX*3）ずつやればいいかな。
720*480側は普通に読むのと3byteずらして読むのをやって
掛け算で加重して・・・あ、MMXの乗算は16bitだけか。
どのくらいの速度になるだろ。
90 ：デフォルトの名無しさん：2006/02/06(月) 18:01:30: 久しぶりだったから配列のアドレスをmovでeaxに入れようと四苦八苦してしまったorz
今からbmpの構造を思い出そうとしている俺は完全に出遅れかな？
91 ：デフォルトの名無しさん：2006/02/06(月) 18:42:06: >>90
つoffset
92 ：デフォルトの名無しさん：2006/02/06(月) 21:28:47: >>90
つlea
93 ：デフォルトの名無しさん：2006/02/06(月) 22:07:42: >88
バイリニアをMMXで実装するだけ。
しかも480で縦ライン固定なら１時間くらいで出来るんじゃね？
94 ：デフォルトの名無しさん：2006/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 ：デフォルトの名無しさん：2006/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 ：デフォルトの名無しさん：2006/02/09(木) 09:45:01: >>90
変数の中身へのポインタを取得するとアセンブリでは
lea eax,[esp-12]
のようになるから、movは使えないのだね。

int *a;ならmov eax,aできても、int a[4];だとmov eax,aで氏んだからな。
あのときはけっこう悩んだ。
97 ：デフォルトの名無しさん：2006/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 ：デフォルトの名無しさん：2006/02/11(土) 11:51:13: １つの構造体がメモリ上でバラバラになってるな。
それはいいとして、組み込み関数と演算子オーバーロードでよくない？

ただ、俺もそういう言語は欲しいと思っていた。
せっかくCPUに色々な命令があるんだから、命令が見える言語がいいよね。
そういう意味じゃCのシフト演算子とかナイスと思った。
99 ：デフォルトの名無しさん：2006/02/11(土) 19:29:54: Intrinsics使えばｲﾝｼﾞｬﾈ?

最終段で機械任せの最適化するなら、
そのままCでも構わないと思うけど。
100 ：デフォルトの名無しさん：2006/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 ：デフォルトの名無しさん：2006/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：2006/02/17(金) 21:25:43: >101
>使用CPUは何？
　書き忘れていました。CPUはPen4ですが、諸事情(VC6sp6開発)のため
MMXまでの制限になってます。
103 ：デフォルトの名無しさん：2006/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 ：デフォルトの名無しさん：2006/02/17(金) 22:15:40: 画像処理はメモリのアクセス速度がボトルネックだよな～
105 ：デフォルトの名無しさん：2006/02/17(金) 22:30:45: Microsoft Visual C++ Toolkit 2003
ttp://msdn.microsoft.com/visualc/vctoolkit2003/
106 ：デフォルトの名無しさん：2006/02/17(金) 23:09:57: SSEが使えればprefetchがあるんだけどなぁ。
107 ：100：2006/02/18(土) 10:01:35: 　いろいろと助言ありがとうございます。参考にしていろいろ試してみます。

>>103
>後でnasmでも使ってみてください。
　個人で試す分には思いっきりやってみたいところなのですが、
そこまですると引き継ぎが出来なくなって（略）な事になるので……
108 ：デフォルトの名無しさん：2006/02/18(土) 18:14:08: いまどきアーキテクチャー依存のアクセラレータなど流行らん
109 ：デフォルトの名無しさん：2006/02/18(土) 20:32:13: >>97
ivec.h
fvec.h
dvec.h
をインクルード
110 ：デフォルトの名無しさん：2006/02/18(土) 23:38:01: >>109
そういったクラスライブラリじゃなくて言語の拡張仕様に
埋め込んで欲しいって言ってんじゃないの？
111 ：デフォルトの名無しさん：2006/02/19(日) 00:03:31: >>110
そんなことは言ってない
112 ：デフォルトの名無しさん：2006/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 ：2006/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 ：2006/02/19(日) 02:15:47: ここが実現してくれるの待ちましょう。どうも税金の無駄遣い臭いのだが。
115 ：デフォルトの名無しさん：2006/02/19(日) 02:28:09: そういや
・データ読み込み
・同アドレスにデータ書き込み
を行った場合、このデータ書き込みの際にmovntiとか使っても全然
早くならないんだけれども、これって対象アドレスに既にデータが入っている
場合、非テンポラル指定はキャッシュ汚染を防ぐためにやるんだから
キャッシュに入っていては意味が無いって事だよな？
116 ：デフォルトの名無しさん：2006/02/20(月) 13:33:53: >100
vcpp5解凍してml.*をコピーすればSSE2命令くらいまで使えたはず、
ってか俺はVC6SP6で使えてる。
もしくは、VC6インスコ→SP5→vcpp5→SP6でもいけた希ガス。
117 ：デフォルトの名無しさん：2006/02/20(月) 13:37:05: 434 名前：・∀・）っ-○●◎- ◆Pu/ODYSSEY 投稿日：2006/01/11(水) 00:05:58
論破されてやがるざまぁｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
118 ：デフォルトの名無しさん：2006/02/20(月) 14:09:47: >>115
意味ないね。その場合ってロードをプリフェッチすれば
ピーク性能を引き出せるのかな？
119 ：100：2006/02/20(月) 20:02:21: 金曜日にお世話になりました>100 です。
>101 殿のアドバイスを元に、改良版を作成して実験したところ、試行１回あたり
0.01msほど早くなりました（笑
＃640×480サイズ、1万回試行の平均。
MMXレジスタ８本全部使って１６ピクセル分１ループで処理するサンプルも実験
してみましたが（ループ回数削減を企図）、やはりほとんど変わりませんでした。

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

>116 殿
　かなりそれは魅力的な手段ですが……引き継いだ後に環境再構築できる人間が（ｒｙ
120 ：97：2006/02/21(火) 12:50:45: >>111
いや言っている。
どちらかというと言語の標準仕様であってもらいたいね。
件の記法が正式採用されたら最適化エンジンは楽チンにベクトル化出来るし
SIMD使えないときでも依存関係の解析が楽になる。
処理が長いときはスレッド化だってイケる。

どれかの言語がこんな感じの機能を実装したら(あるいは約束したら)、
明日にでもその言語に乗り換えるね。
121 ：デフォルトの名無しさん：2006/02/21(火) 13:18:37: >>119
0.01msか。思ったより効かないな。
prefetchの代替ならmovを使うという手もあるが、この処理の要はmovntqだからな。
後で俺も試してみよう。
122 ：デフォルトの名無しさん：2006/02/21(火) 13:58:35: Win機でのprefetchはいろいろやったけどあまり効かなかった。
効果てきめんな人居る？

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

VTuneとかでメモリアクセスのパターンとか見れば何とかなるか
と評価版を試してみたけど結局うまく行ってない。残念無念
123 ：デフォルトの名無しさん：2006/02/21(火) 14:03:39: 非実用コードで試しても、１割くらい速くなるだけだね。
キャッシュラインは64byteないとほとんど効かないと思う。
124 ：デフォルトの名無しさん：2006/02/21(火) 14:23:50: >>122
PGIの嘘っぽい最適化結果によると
ttp://www.softek.co.jp/SPG/Pgi/TIPS/amd64_em64t.html
だそうな。
125 ：デフォルトの名無しさん：2006/02/21(火) 16:37:15: PGIスレにぎわってないけど、ホントに性能出るもんかねえ？

intelでもオレのケースではまったく効果なかったし（性能クリ
ティカルな部分は全部SIMD化している）、iccで最適化
かけた性能はオレのasmコードにぜんぜんのよばねーし。
126 ：デフォルトの名無しさん：2006/02/21(火) 17:05:03: ハードウェアプリフェッチついてるから、
ソフトウェアプリフェッチの効果薄いのかもね。

メモリアクセスレイテンシ対策にはiccの
#pragma unroll(?)
は段数変えてみると結構効く場合があるね。
127 ：デフォルトの名無しさん：2006/02/21(火) 21:34:42: バタフライ演算が華麗に書けないのは痛いな。他のレジスタにコピーして
別に計算、マスクしてから元のレジスタに加算とか、ステップが余計にかかって
しょうがない。
二次元DCTをFCTで書いたものと、まともにDCTしたものを比べたら、普通の
DCTのほうが幾らか速かったorz
腕が悪い可能性も大だが。

V-Tuneなんつうブルジョアなものは持ってないので、visioでダイヤグラムを
書いて、ペナルティを極力食らわないように組替えてからソースを書きました
とさ。手動最適化マンセー。
128 ：デフォルトの名無しさん：2006/02/21(火) 22:24:19: shuffle命令やSSE3使ってる？
129 ：デフォルトの名無しさん：2006/02/22(水) 10:48:20: SSEすら使ってない。

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

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

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

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

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

掛け算に無符号が付いたMMX2は最初からやっとけと
131 ：デフォルトの名無しさん：2006/02/22(水) 11:50:23: ま、あれか。プログラム起動時にCPUの種類を判別して、それぞれに
最適なルーチンを走らせるというのが普通か。
132 ：デフォルトの名無しさん：2006/02/22(水) 12:27:12: 手動最適化はMMXだけ使って
SSEはコンパイラに丸投げ

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

>129
SSE2/3の命令ってmov系と高精度演算命令系以外になんかあんの？
134 ：デフォルトの名無しさん：2006/02/22(水) 13:47:08: >>133
MendocinoコアCeleronの載ったマシンとか現役で使ってる人が結構いるから
SSEも迂闊に使えないｗｗｗ

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

> SSE2/3
ホラ、あるじゃないか。MMX/3DNOW!を無理矢理二つくっ付けた様な糞命令群が。
このへんは演算ユニットが128bit化するときのための布石と考えてるが。
てか、64bitになるとMMXもそろそろ要らなくなりそうな雰囲気。
飽和演算とか撹拌処理とかやらなくていいなら汎用ALU使ったほうが速度が出るんだよね。
135 ：デフォルトの名無しさん：2006/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 ：デフォルトの名無しさん：2006/02/22(水) 15:29:56: >>134
＞Mendocinoコア
めんどっちーの、と読むのか？
137 ：デフォルトの名無しさん：2006/02/22(水) 19:52:50: 略してマンコア
138 ：デフォルトの名無しさん：2006/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 ：デフォルトの名無しさん：2006/02/23(木) 21:14:55: MMX2って何？SSEで入れられた整数演算？
140 ：・∀・）っ-○●◎- ◆Pu/ODYSSEY ：2006/02/23(木) 21:38:09: もともとはSSEの旧い仮称だった気が。

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

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

精度を保って処理したいなら単精度小数点などで処理するが、リアルタイム
性能を追求するなら整数で処理するしかないかな、と。
まぁ、どうせインテルは本当に便利な命令は用意しない方針のようなので。
142 ：デフォルトの名無しさん：2006/02/23(木) 22:53:27: ソフトウェアパイプライニングとか
手でやってる？コンパイラまかせ？
x64だとレジスタ数も違うし、そもそも
CPUごとにレイテンシ等変わって面倒だよね？
143 ：・∀・）っ-○●◎- ◆Pu/ODYSSEY ：2006/02/23(木) 23:01:45: Athlon系はレイテンシが長いからL/S頻度上げてでも並列化汁
PenMは全般にレイテンシ短いから程々でヨシ
NetBurstはパイプラインの長さの分OoOが強力だからあんまり何も考えないほうが
かえって良かったりするかも。

という風に把握している
144 ：デフォルトの名無しさん：2006/02/24(金) 08:45:35: >>142
JIT付きの実行環境が欲しくなるなあ
145 ：・∀・）っ-○●◎- ◆Pu/ODYSSEY ：2006/02/24(金) 21:27:24: っ[ドトニート]
146 ：デフォルトの名無しさん：2006/02/26(日) 19:46:12: ん、MMX2ってAMDがつけた3D-Now!の前の名称だったのでは？

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

違ったらｽﾏｿ
147 ：デフォルトの名無しさん：2006/02/27(月) 06:55:48: 確かにｸｿ平凡だよな
148 ：デフォルトの名無しさん：2006/02/27(月) 14:28:57: 俺はMMX2ってSSEの中でMMXレジスタを使うものをIntelが呼んでいたんだと
思っていたが、何か違うみたいね。ぐぐっても少ないし。
149 ：・∀・）っ-○●◎- ◆Pu/ODYSSEY ：2006/02/27(月) 21:14:27: >>146
古いソースを漁ってみるに、MMX2はSSEがまだ世に出る前の仮称。
SSE自体もKatmaiが出始めた頃はiSSE（インターネットストリーミングSIMD拡張）と
呼んでたり。

AMDその他CPUメーカーがMMXを使うこと自体にIntelが提訴したのでは。
Intel側の主張は棄却で和解したはず。
150 ：・∀・）っ-○●◎- ◆Pu/ODYSSEY ：2006/02/27(月) 22:06:26: すんまそん、技術自体ではなく名称ですね。
サポートされた拡張命令セットが同一であっても、あくまでカタログ上は
Enhanced 3DNOW!、3DNOW! Professionalなどと称し、SSE、SSE2という商標名は
使ってませんな。
151 ：デフォルトの名無しさん：2006/02/27(月) 22:25:55: 3DNow!はSSE+αなんだからSSEと名乗るのは変じゃないか
152 ：・∀・）っ-○●◎- ◆Pu/ODYSSEY ：2006/02/27(月) 22:34:40: まぁそうなんだけどEnhanced→ProfessionalはIntelが先行して行ったXMMレジスタ周りの
拡張命令のサポートで、AMD独自の拡張命令の追加は無い
やっぱり商標権のトラブル回避の為でしょうな
153 ：デフォルトの名無しさん：2006/04/25(火) 20:19:34: MMXに命令が追加されたときにユーザーが俗にMMX2と読んだだけなんじゃなかったkk手
154 ：デフォルトの名無しさん：2006/04/25(火) 23:21:44: 0x8E574343みたいなHexのデータが延々と続いたデータの
中から、特定のhex列を見つけたいと思ったらアルゴリズムは
別の領域として高速化するのにSSEとかは使えそう？

もし使えそうだったら簡単なサンプル示していただけないでしょうか
155 ：デフォルトの名無しさん：2006/04/25(火) 23:27:01: キャッシュに納まるサイズのデータの中を何度も検索するんじゃなければ
普通にCで書いてもMMX使っても大差ないような気がする。
巨大データ（and 古いCPU）ならむしろ prefetch の有無で変わってくる。
156 ：デフォルトの名無しさん：2006/04/25(火) 23:32:10: えーとCPUはOpteron850とかXeon 3.6Ghz当たりを64コアから512コアぐらいを
想定しています。データは1データあたり1000バイト程度それが秒間900MB/sec
転送されてきますそれをリアルﾀｲﾑで処理しないといけません。そうするとCで
書いても大差ないですか。
157 ：デフォルトの名無しさん：2006/04/26(水) 13:15:35: >154
その程度のサンプルも書けないレベルなら諦めろ。
結局メンテナンス出来ずに回りに迷惑かけるだけだ。
>156みたいな用途ならおとなしくCで書いとけ。
158 ：デフォルトの名無しさん：2006/04/26(水) 19:48:30: 900MB/sのネットワークがなんなのか気になる
159 ：デフォルトの名無しさん：2006/04/28(金) 00:41:23: SSEはレジスタが広いけど、
汎用レジスタで最初の4byte一致したら続きを調べるってすれば実質変わらんしなあ。
「特定のhex列」の登場頻度が高いなら別だけど。
あ、でもこれもSSEで並列にやればいいんだ。hexは1/2バイトなのも考えて。
「特定のhex列」のバイト数は？
2バイト単位くらいで比較して、4bitシフトしてまた比較。
一致するものがあったらそこを普通に調べる。
これなら数倍比較コストが減るんじゃないか。
＃まあ、メモリ帯域ネックから高速化はしないと思うよ。

あとはキャッシュラインをまたぐときに気をつけること。ここもうまくやればSSEが有効か？
ていうかCで書いて速度が足りないから>>154で質問したんじゃないよね？
普通にCで十分な速度だと思うよ。
160 ：デフォルトの名無しさん：2006/04/28(金) 02:39:57: スペック見る限り結構な規模のプロジェクトだし、
そんなプロジェクトで汎用性が無くメンテナンス性の悪いアセンブラを使おうってのが間違ってる。
しかも知識も無いときたら周りに迷惑かけるに決まってる。
や　め　と　け。
161 ：デフォルトの名無しさん：2006/04/28(金) 02:47:22: 昔似たようなことやったけれどあんまり意味が無かった記憶がある。
162 ：デフォルトの名無しさん：2006/04/28(金) 06:53:08: いまやSSEもAltivecもCで書く時代
163 ：デフォルトの名無しさん：2006/04/28(金) 07:43:02: みんな言ってることは正しいと思うけど、
このスレ的にはアセンブラでSIMDを使い無駄な最適化をするべきじゃないか？
164 ：デフォルトの名無しさん：2006/04/28(金) 10:14:38: ＞無駄な最適化
ｗｗｗ
なんかわかるｗ
165 ：デフォルトの名無しさん：2006/05/01(月) 01:01:51: 154タンはいなくなってしまったか。。
166 ：デフォルトの名無しさん：2006/05/02(火) 01:27:50: いやいるし勉強してるんだけど、いまいちよくわからない

もう少し修行してきます
167 ：デフォルトの名無しさん：2006/05/02(火) 19:01:46: >>166
いたか。いつでもいいので修行したら報告ヨロ。
168 ：デフォルトの名無しさん：2006/05/03(水) 10:49:45: とりあえず、gasとnasmどっちでインラインすればいいんだろう
gccだと一択なのかな？
169 ：デフォルトの名無しさん：2006/05/03(水) 20:55:17: SIMDの資料ってみなさんはどこから取得してるのでしょうか？
170 ：デフォルトの名無しさん：2006/05/03(水) 21:29:21: http://www.intel.co.jp/jp/developer/download/index.htm
171 ：デフォルトの名無しさん：2006/05/05(金) 19:42:06: ていうか検索アルゴリズムってどう最適化しても
結局メモリ帯域で頭打ちになるっしょ
172 ：・∀・）っ-○◎● ◆toBASh.... ：2006/05/05(金) 19:52:44: ここを熱心に読んでたことが、私にもありました。
http://developer.apple.com/hardwaredrivers/ve/
173 ：デフォルトの名無しさん：2006/05/05(金) 21:00:21: 黙れキチガイ
174 ：デフォルトの名無しさん：2006/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.... ：2006/05/19(金) 01:26:16: >>174
__m128じゃなくて__m128i使いなよ。ただしSSEじゃなくてSSE「2」ね。
SSEまでなら単精度浮動小数×４までしかサポートされない。

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

#include <dvec.h>

VC++かICCならこれで Iu8Vec16 っていうクラスが使えるはず
176 ：デフォルトの名無しさん：2006/05/19(金) 01:32:07: すいません環境書くの忘れたのですが、
RedhatEL4 gccで作成しています。ｇｃｃだとdvec.hが使えないと
聞いて悩んでいました。
177 ：・∀・）っ-○◎● ◆toBASh.... ：2006/05/19(金) 01:45:07: 確かに使えない。
じゃあこっち
#include <emmintrin.h>

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

http://msdn2.microsoft.com/en-US/library/26232t5c.aspx
とかを参考に。

pcmp系関数でマスクしてpmovmskbで各上位ビットを汎用レジスタに転送して再度比較するのが
スマートかな。
178 ：デフォルトの名無しさん：2006/05/19(金) 02:12:04: >>177
うーんサンプルコードってあるのでしょうか？
179 ：デフォルトの名無しさん：2006/06/13(火) 01:35:19: すみません、ANDPDとANDPSって何か違いがあるんでしょうか？
どっちもxmmレジスタ同士のandを取るだけのような……
180 ：デフォルトの名無しさん：2006/06/13(火) 02:35:31: マシン語コードが違う。命令長は同じ。
動作も同じだと思う。
ニーモニックが2つあるのはいいとして、
なぜマシン語コードも違うのか謎ですな。
181 ：デフォルトの名無しさん：2006/06/13(火) 02:52:35: ANDPSは、SSEまでカバーしていれば使える。
建前上、パックド単精度実数が操作対象。
ANDPDは、SSE2をカバーしていないと使えない。
建前上、パックド倍精度実数が操作対象。
182 ：デフォルトの名無しさん：2006/07/05(水) 10:18:10: 機械語は敷居が高すぎて手を出せないので、C言語だけで3DNOW!やSSE対応の
プログラムは作れないものでしょうか。
183 ：デフォルトの名無しさん：2006/07/05(水) 10:35:41: MMXやSSE命令をラッピングした組み込み関数が用意されている開発環境があるよ
184 ：デフォルトの名無しさん：2006/07/05(水) 12:47:46: なんでもそうだけど、知らないと食わず嫌いで難しそうに思うけど
やってみるとそうでもないもんだよ。
185 ：デフォルトの名無しさん：2006/07/05(水) 13:03:54: >>183
つか、x64やIL向けだとインラインアセンブラ無効だからそれ使うしかない
186 ：デフォルトの名無しさん：2006/07/05(水) 13:08:38: 実際問題mmintrin系組込み関数は構造化設計ができるし、命令スケジューリングの最適化も阻害しないから
結構便利なんだよな
187 ：デフォルトの名無しさん：2006/07/05(水) 14:00:17: 命令スケジューリングっていうか、VC++ の場合inline 使うと
前後でも最適化が一切行われないよね。
188 ：デフォルトの名無しさん：2006/07/05(水) 18:17:51: >>187
される。
まさかとは思うがコンパイルオプションミスったり、
デバッグモードで確認なんかしてないよな？
189 ：デフォルトの名無しさん：2006/07/05(水) 19:45:11: ホントダ・・・誰かに騙されていた！！
簡単に確認できるのに確認しない漏れって・・・orz
190 ：デフォルトの名無しさん：2006/07/06(木) 11:38:10: 最適化されないのはインラインアセンブラ（__asmステートメント）の前後や中身。
inlineとか__inlineキーワードはむしろグローバルな最適化（高速化）のためのもの
191 ：デフォルトの名無しさん：2006/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 ：デフォルトの名無しさん：2006/07/06(木) 17:24:38: インラインアセンブラの部分まで勝手に最適化されたら神認定なんだが。
193 ：デフォルトの名無しさん：2006/07/06(木) 17:47:13: インラインアセンブラの部分を勝手に最適化しやがったらキレるだろ普通。
アセンブラで記述しなきゃいけない部分は何らかの理由があって
わざわざそういうコードにしてるものもあるのに、
それを別の命令に置き換えられたらブチギレですよ。
194 ：デフォルトの名無しさん：2006/07/06(木) 19:04:49: >>191
関数の前半と後半を__asm{nop}でぶった切ったら最適かもぶった切られたよ。
195 ：デフォルトの名無しさん：2006/07/07(金) 11:33:32: 「最適化もぶった切られた」ってのはどういう意味ですか？
後半が素直な100回ループになっちゃったってこと？
196 ：デフォルトの名無しさん：2006/07/07(金) 11:38:45: >>194
コンパイラによって結果は異なってあたりまえだろ。
漏れのとこの VC++ 2005 では __asm{ nop}; 入れてもnpad 1 が間に入るだけで
全く変らないコードが生成された。
197 ：デフォルトの名無しさん：2006/07/07(金) 12:03:47: >>195
__asmをまたいだ最適化はしない、ということかな？
198 ：196：2006/07/07(金) 13:16:40: >>197
そういうことじゃないんじゃないか？漏れのトコでは前述の通り npad 1 の有無だけ。
そもそも__asm 入れなくても「またいだ最適化」みたいなものは無かったし。

単に >>194 の使ってるコンパイラが__asm 入れると最適化しなくなる旧いVCとか
なんじゃまるまいか？
199 ：デフォルトの名無しさん：2006/07/07(金) 13:28:48: >>198
なるほど。
200 ：デフォルトの名無しさん：2006/07/07(金) 18:35:27: >>195
forループではないんだが、FPUレジスタの使い方に無駄が出た。
ある関数の最初の方で別のライブラリの関数にfloatの変数渡して、
いくつか別の浮動小数点の処理した後で変更なしで再びその変数を使うんだが、
この間にnop入れるだけでもう一回メモリから読み出すようになった。

>>196
すまんがforループなんて単純な部分ではなく、しかもVC8での話なんだ。
201 ：デフォルトの名無しさん：2006/07/07(金) 20:27:10: インラインアセンブラ挟んで最適化を期待する方がおかしい気がしますが。
しかも複雑な部分なら尚の事。
202 ：200：2006/07/07(金) 21:27:22: >>201
アンカーがないから俺へのレスってことでOKなのか？
おれは__asmブロックで最適化が阻害されるのは当然だと主張してるのであって
最適化されねーぞなんでだヴォケと言ってるわけじゃないんだが。
203 ：デフォルトの名無しさん：2006/07/07(金) 21:36:42: >>200
その話の真偽はおいといて、
>>191 >>194 を読んでそんな風に理解できるかというと、
それはちょっと無理じゃないか。

漏れは 191 の関数の前半と後半という風に読んじゃたよ。
想像力が無いからかもしれないけど。
204 ：デフォルトの名無しさん：2006/07/07(金) 22:01:59: >202
当たり前の結果にムキになってっから、何か不満でもあるのかと思った。
205 ：デフォルトの名無しさん：2006/07/08(土) 09:25:11: >>81
古い話だけど今のICCには_mm_cast*という命令があってこれでキャストできることに気がついた。
VCLにはない。GCCは普通に(__m128)とかでキャストできる。
206 ：・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6 ：2006/07/08(土) 17:53:16: 浮動小数の2倍とか1/2倍とかやるのに指数部を直接整数として足し算引き算すると確かに速いんだよな

AMDが来年予定してる新リビジョン（K8L）でXMMレジスタの下位・上位QWORDと汎用レジスタ命令の値を
相互に交換する追加されるみたいだけど、これってIntelも採用するかのう？
別のニーモニック割り当てるんだろうな。
207 ：・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6 ：2006/07/08(土) 17:54:25: ×汎用レジスタ命令
○汎用レジスタ
208 ：182：2006/07/13(木) 16:03:54: みなさん、どうもありがとうございました。
3DnowやSSEを使えるようになるのを目標にして、機械語を勉強するのに
良い参考書がありましたら、教えていただけませんか。
NWSAというのを見つけて、解説を読んでいますが未知の言葉が山盛りです。
209 ：デフォルトの名無しさん：2006/07/13(木) 16:14:38: SIMDが載ってる本
x86アセンブラ入門
アセンブラ画像処理プログラミング

載ってない本
独習アセンブラ
アセンブリ言語の教科書
糞級言語プログラマのためのアセンブラ入門
210 ：デフォルトの名無しさん：2006/07/13(木) 16:19:02: >>208
ftp://download.intel.co.jp/jp/developer/jpdoc/24547103_j.pdf
ttp://homepage1.nifty.com/herumi/adv.html
211 ：デフォルトの名無しさん：2006/07/13(木) 23:48:16: 絶対に買ってはいけない本

いまどきのアセンブリ言語

いまどきのアセンブリ言語の教科書
212 ：デフォルトの名無しさん：2006/07/14(金) 00:33:58: 「IA-32 インテルアーキテクチャ・ソフトウェア・デベロッパーズ・マニュアル」
を読んでSSEが難しいようだったら多分それを触る前に覚えることがまだまだある。
213 ：デフォルトの名無しさん：2006/07/14(金) 06:06:27: >>212
そうかな。俺はよくわかんないうちから
MMXでガンガンコード作って覚えたけど。

あのマニュアルを読むのは、ある程度
SSEを使えるようになってからでないときついだろう。
214 ：デフォルトの名無しさん：2006/07/14(金) 10:07:33: >>213
212ではないが、あれ読めないって事は結局x86の構造理解出来てないって事だと思うが。
通常命令での効率的な組み方を勉強する方が先じゃね？
215 ：デフォルトの名無しさん：2006/07/15(土) 06:49:15: Core2に搭載されるISSE4っていったいなんだろう。
216 ：デフォルトの名無しさん：2006/07/21(金) 11:50:31: CASL IIやれば十分だよな
217 ：デフォルトの名無しさん：2006/07/27(木) 15:42:54: 単純な画像変換とかをMMX化SSE化して
デバッガにかけながら読むとテラわかりやすいお。
218 ：デフォルトの名無しさん：2006/07/28(金) 21:22:59: だれか Core2 に搭載される(た) SSE4 のマニュアルを
ダウンロードできるとこ知らない？
www.intel.com とか探しても全然見当たらない。
まだ非公開かな？
それにしてはベンチマークが対応しているのが不思議．．．。
219 ：デフォルトの名無しさん：2006/07/28(金) 21:39:10: 糞団子のページに書いてあるよｗｗｗｗｗｗｗｗｗｗ
220 ：デフォルトの名無しさん：2006/07/28(金) 21:47:56: あれはニーモニックから推測したものでしょ。

TMPGEncだかも対応したよな。
開発者向けには公開してあるってことか？
221 ：デフォルトの名無しさん：2006/07/28(金) 22:00:38: TMPGEncはIntelが金出して最適化してたはず。
222 ：デフォルトの名無しさん：2006/07/28(金) 22:58:59: なるほど。抜け目ないね。
TMPGEncはベンチとしても一般的だからな。
223 ：デフォルトの名無しさん：2006/08/04(金) 10:38:00: 推測っていうか、既にICC9.1でこっそり対応してる。組み込み関数も既に用意されてる。
団子のページ引用率高すぎ
224 ：デフォルトの名無しさん：2006/08/14(月) 07:45:54: C言語のプログラムの途中たった一行だけ、計算式をインラインアセンブラで
MMXやSSE、3DNOWに対応させるというのは可能ですか。
225 ：デフォルトの名無しさん：2006/08/14(月) 09:09:05: たった一行だけのためにemmsを使うのはアフォ
226 ：デフォルトの名無しさん：2006/08/14(月) 13:22:18: 最低でもループの一番内側丸ごと、じゃないかな。
emmsもｄろうけど、SIMDはデータをレジスタに乗っ
けるところが結構食うからね。
227 ：・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6 ：2006/08/14(月) 23:22:34: アンロールしまくれ

SSE2の整数命令ってSSE2非対応CPUはMMXの相当命令として解釈されるから
うまく組めばパスの分岐必要なし
228 ：デフォルトの名無しさん：2006/08/29(火) 01:31:22: gccでintrinsic function使ってSSE2,3の処理書きたいんですけど
3年ぐらい前に書くとアライメント指定しても4byteでまとめられたりして
まともに使えなかった記憶があるんだけど今はどうなんですかね？
229 ：デフォルトの名無しさん：2006/08/29(火) 21:46:08: _mm_malloc()かunion共用体使う
230 ：デフォルトの名無しさん：2006/09/14(木) 14:49:48: SSE4の仕様解析出たな

>>226
SIMDのデータ転送のレイテンシが半端なくでかいのはPen4くらい
AthlonやPenM, Core系は整数と大して変わらない
231 ：デフォルトの名無しさん：2006/09/14(木) 15:00:09: ようするにネトバは糞って事？
232 ：デフォルトの名無しさん：2006/09/14(木) 15:57:07: ネトバカッコイイってほざいてたのは雑音だけ。
SIMDとSIMMを間違えるのも雑音だけ。
233 ：デフォルトの名無しさん：2006/09/14(木) 16:57:41: たるさん…
234 ：・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6 ：2006/09/14(木) 23:04:40: psign*とpalignr間違えてましたすいません。
SSE4って命令部3バイトだからあんまり使えない気が。
XMMレジスタでREXプリフィックス付けたら命令長最低6バイトになる

>>228
ヒープ上に16バイトくらい多めに確保して、返ってきたアドレスに15足して~15でマスク。
Windowsだと、SSEがまともに使えるようになったのがVC7からだと記憶してる。
235 ：デフォルトの名無しさん：2006/09/27(水) 11:49:46: SSE4のレイテンシやスループットの数字って出てる？
236 ：・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6 ：2006/09/27(水) 22:11:16: 非公式ながら、x86の～スレにある。
正式名称はSupplimental-SSE3(SSSE3)になったらしい。

あと、まるも製作所の中の人が色々と考察してた
237 ：デフォルトの名無しさん：2006/09/27(水) 22:28:46: へえ、SSE4じゃなくてSSE3に追加するという形か。
238 ：デフォルトの名無しさん：2006/09/28(木) 20:11:09: 長いからSSE4かTNIでいいよ
239 ：デフォルトの名無しさん：2006/09/28(木) 21:16:13: 追加って話ならSSSEよりSSE3sのが理にかなってわかりやすいなぁ…
240 ：デフォルトの名無しさん：2006/09/28(木) 21:21:57: Enhanced 3D Now! みたいなものだろう。
ただ、次に命令を追加するときに「SSE4」とされるとややこしいな。
241 ：デフォルトの名無しさん：2006/09/28(木) 21:24:32: 次はSSSSE3だな
242 ：デフォルトの名無しさん：2006/09/28(木) 21:31:38: スプラッシュスターSSE3
243 ：デフォルトの名無しさん：2006/09/29(金) 10:58:55: Streaming SIMD Extensions eXtendedにするべきだと思うんだが
244 ：デフォルトの名無しさん：2006/10/05(木) 01:38:11: 今後、SSE4はSSE4と呼べばいいが、
SSE3+SSSE3を総称した呼び名はできるのかな。

命令が普及した後で、SSE3と言ったときに、
SSSE3が含まれるかどうかが不明確になりそう。
245 ：デフォルトの名無しさん：2006/10/05(木) 01:39:39: 総称がSSE3だろ
ﾌﾟﾚｽｺは要らない子
246 ：デフォルトの名無しさん：2006/10/05(木) 01:50:35: そっか。じゃあ、Prescottと最近のK8だけ仲間外れだ。
あれ、Cyrixの系統のやつも載せてたっけ。

今度はSSE3（総称）の中のSSSE3に含まれない命令の
呼び名がないと不便になるなあ。
247 ：デフォルトの名無しさん：2006/10/05(木) 02:10:26: SSSSSEE33
248 ：デフォルトの名無しさん：2006/10/05(木) 02:18:44: SSE3-FP
249 ：デフォルトの名無しさん：2006/10/05(木) 02:23:10: SSE3-Classical
250 ：デフォルトの名無しさん：2006/10/05(木) 02:24:49: SSE3ESS
251 ：・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6 ：2006/10/05(木) 02:50:45: PNIとTNI(MNI)でいいじゃん。

PenrynもPだから困る。
252 ：デフォルトの名無しさん：2006/10/05(木) 14:27:03: >>251
なるほど。
Penryn New Instructionsの略称はどうなるのかね。
まあSSE4と呼べばいいだろう。

ところでこのスレも2年以上になるのだが、
今こういうスレを立てるとしたら、3D Now!の名前は入るだろうか。
まあ、2004年と言えばとっくに3D Now!は下火だったが。
253 ：デフォルトの名無しさん：2006/10/16(月) 18:03:24: >>25
この2年前のソースが見てみたい
254 ：デフォルトの名無しさん：2006/10/16(月) 18:07:15: もう2年になるのか・・・。
少し遅れて来て>>25が取れなかったことを
昨日のように思い出す。
255 ：デフォルトの名無しさん：2006/10/16(月) 21:01:22: ttp://hitokuso.kicks-ass.org/bilinear.zip
２年前のソースをそのまま晒す恥知らずの俺サイコー
256 ：デフォルトの名無しさん：2006/10/16(月) 21:31:14: >>255
こ、更新日時が2004/12/12 10:07！！
俺は特に見たかったわけではないが、>>255はある意味で神。
よかったな、>>32！
257 ：デフォルトの名無しさん：2006/10/16(月) 22:36:18: >>255
すげぇｗ
258 ：デフォルトの名無しさん：2006/11/21(火) 14:43:13: これから、64bitのWindowsが普及してくる（使えるレジスタ倍増）のと、
Core2やK8LでSSE命令のレイテンシは据え置きでスループットが倍になること、
これらによってSSEの使い方がかなり変わってくるだろう。
259 ：デフォルトの名無しさん：2006/11/29(水) 02:30:01: 急にSIMDとかインラインアセンブラ使いたくなってやってみたんだけど、
トイプログラムで

　A: SIMD化+とことんオプション最適化
　B: とことんオプション最適化
　C: SIMD化
　D: 軽くオプション最適化
　E: ベタ書き

で

　A:B:C:D:E = 10:15:30:35:60 ＃速度比

と、実は結構コンパイラオプションのチューニングだけで
いけてしまうことがわかってコンパイラスゴスと思ってしまった。

A:Bでも10:15位の速度比があるのでSSEとか効いてはいるんだけど、
最初はC:Dで止まってて「あんま変わんないなぁ」とか思ってたら
B:Cで15:30とオプションいじるだけで下手なSIMD化を抜いてしまって
驚いた。よほど性能が必要なケース以外は下手に拡張命令使うより
コンパイラお任せで十二分にいい仕事してくれるのな。

自分は拡張命令覚えるよりコンパイラオプション覚えたほうがいい
レベルなのだと痛感しますた・・・
260 ：デフォルトの名無しさん：2006/11/29(水) 03:09:59: 処理内容に依存するからなあ。
どんなの？

SIMD化というのはインラインアセンブラ？
コンパイラに頼るなら組み込み関数という手も。
インラインアセンブラをまたいでは最適化が効かない。

最近はCPUが賢いというのも
コンパイラ有利な要因かも。
261 ：デフォルトの名無しさん：2006/11/29(水) 03:44:25: >259
SIMDで最適化するならデータの配置も最適化しないと意味無いぽ。
てかコンパイラ、サンプルコード、計測方法、コアの情報も無く比だけ提示されてもな、って感じ。
262 ：デフォルトの名無しさん：2006/11/29(水) 16:58:12: 正直、そのデータ配置の最適化ってのがどういうもんなのかよくわかんね・・・
セオリーとかあるの？
263 ：デフォルトの名無しさん：2006/11/29(水) 17:10:13: インテルのマニュアルにSoAとかAoSとかについて書いてある。
264 ：デフォルトの名無しさん：2006/11/29(水) 21:27:32: 何にせよ、どんな処理を高速化したいのか
書いてくれないと話が進まない。
265 ：デフォルトの名無しさん：2006/11/29(水) 22:58:45: >>260
いや、トイプログラムって書いてる通り、1M個くらいのfloat列を
２つ乗算するだけのコード。インラインアセンブラもやったこと
なかったので、最初はインラインアセンブラで書き始めて、途中で
Intel/MS/GNUが全部同じAPIで叩かせてくれると気づいて書き直した。

これまでやったことがなかったので経験のためやってみただけなので、
あまり真剣に取らないで・・・スマソ。

でもコンパイラオプションだけで考えていた以上に性能が接近すると
知ったのは収穫でした。問題の部分に使うクロック数で非SIMDは３倍
程度はかかるかと思ってたから。
266 ：デフォルトの名無しさん：2006/11/29(水) 23:16:32: >>265
そういうのをトイプログラムというのか。
今のCPUだと、floatならSIMDの方が速いと思うが、
float*1M個*2つ＝8MBなので、L2キャッシュに乗らず、
単にメモリがネックになってるだけと思われる。

非SIMDでfloatの乗算をするのに、うまく最適化すれば
Athlon系なら1クロック、Pentium系なら2クロックでできる。
それに対しメモリ帯域は1～2byte/clkだから、
2つのfloatをロードし結果をストアするのに12byteのアクセスを
するのに全然帯域が足りてない。

つまり、ここで必要なのはSIMDでなくプリフェッチ。
>>259のどのコードも、FP演算ユニットは遊んでいたと思われる。
もっとも、SIMDのロードやストアはアクセスの単位が大きいので、
メモリアクセスが効率化されて若干速くなる。
AとBの差はそれだろう。
267 ：・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6 ：2006/11/29(水) 23:43:32: 結果の格納を別の配列にしてるんならmovntpsが有効なのでつ

x87からライトスルー命令は使えないし、やっぱりSSEまんせー
268 ：デフォルトの名無しさん：2006/11/29(水) 23:52:32: >>266
いやそれがですね、-fprefetch-loop-arrays とかいうオプションが
あってまさにそれやってくれてたんですよ。

わざわざ拡張命令使わなくても限定的ながら自動ベクトルかとかも
してるそうで、もうコンパイラ様々というか。
269 ：デフォルトの名無しさん：2006/11/30(木) 00:00:04: >>267
あ、それを忘れてた。

>>268
すごいなコンパイラ。
すると、インラインアセンブラを使うと最適化が効かないから
プリフェッチもしてくれないわけで、それでAがBに勝ったの？

コンパイラの吐いたプリフェッチコードキボンヌ。
270 ：デフォルトの名無しさん：2006/11/30(木) 04:55:32: そもそも機械的な最適化に負けるコード吐いてる次点でSIMDがどうこう言う資格無い。
時々勘違いしてる奴がいるが、アセンブラ化すれば速くなるわけじゃない。
コンパイラで出来ないことをアセンブラで最適化するから速くなる。
MMX/SSE命令並べただけで速くなるならコンパイラだってそうするだろうよ。
271 ：デフォルトの名無しさん：2006/11/30(木) 05:20:08: >>270
コンパイラに負けるから勉強して
SIMDを使えるように頑張るんじゃないか。
272 ：デフォルトの名無しさん：2006/11/30(木) 11:31:10: うん、勉強頑張るのはいいよな。
「コンパイラの最適化で十分」とか結論付けるのは良くないよね。
273 ：デフォルトの名無しさん：2006/11/30(木) 20:51:08: VC8で64bitコードにインラインアセンブラを使えないのが腹立たしい。
MASMだと煩雑だしプリプロセッサも無い。
組み込み関数じゃ思った通りの命令を生成しない。
274 ：・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6 ：2006/11/30(木) 21:58:25: COFF形式でコード吐きだせば別にアセンブラは何だっておｋだよ。
むしろx64対応のアセンブラそのものが少ないのが問題。

x64でプログラミングやるならVC++Std + PSDK + ICCが一番コストパフォーマンスいいと思う。
275 ：デフォルトの名無しさん：2006/11/30(木) 22:14:39: yasm使ったことある人いる？
276 ：デフォルトの名無しさん：2007/01/31(水) 07:50:32: インラインうぜーよ
モジュール分けろやボケが
277 ：デフォルトの名無しさん：2007/02/18(日) 10:10:27: 裏切派遣って知ってる？
元々は正社員だったのに取引先にフリーのほうが稼げるとか騙されて派遣やってるバカのことｗ

前の会社を裏切り、結局派遣先からも騙されてる。
そもそも信頼されてるなら直接契約するか正社員にするはずだが、派遣会社経由って舐められ杉

自分でも騙され裏切れられてることは薄々わかってるから派遣問題の話が出るとウッキー！って逆ギレｗ
278 ：デフォルトの名無しさん：2007/03/03(土) 01:15:50: http://krypton1.at.infoseek.co.jp/x86/x86ext.htm
279 ：デフォルトの名無しさん：2007/03/03(土) 09:39:36: そんなサイトよか光成さんの方がよい
280 ：デフォルトの名無しさん：2007/03/03(土) 13:19:31: >>279
光成さんって?
281 ：デフォルトの名無しさん：2007/03/03(土) 14:24:27: 光成 SSE
でぐぐったらこんなページに出会った。
http://homepage1.nifty.com/herumi/index.html

あー、確かにこれはいいものだわ。
282 ：デフォルトの名無しさん：2007/03/03(土) 15:17:55: >>281
XBYAK
なんじゃこりゃ、すげぇ
283 ：デフォルトの名無しさん：2007/03/04(日) 06:38:58: むしろこのスレで知らない人が居るのに驚いた訳だが
284 ：デフォルトの名無しさん：2007/03/05(月) 10:04:48: 禿同
285 ：デフォルトの名無しさん：2007/03/13(火) 21:08:56: 今更ながら MMX を使用した MMX_MemCpy() を作ってみたが普通の memcpy() と10%も速度が変わらなくて萎えた…
286 ：・∀・）っ-○◎●：2007/03/13(火) 22:33:09: FSBで律速されるからね。
キャッシュ内で使う場合は十分意味ある。
287 ：デフォルトの名無しさん：2007/03/13(火) 22:56:37: >>286の言う通りメモリの速度に依存する。
それに64byteとか128byteごとにキャッシュされるんだから
4byteずつコピーしようが8byteずつコピーしようが殆ど同じ。
重要なのはプリフェッチ。

L1のサイズをきちんと考慮してプリフェッチしてからmemcpy()を繰り返してもいけたりして。
288 ：285：2007/03/14(水) 07:59:02: そうなのか…
8Byte境界なら MM7 レジスタまで使用して64Byte転送するとかやってみたんだが同じなのか。orz
289 ：名無し募集中。。。：2007/03/14(水) 21:13:59: 数%でも高速化されるならそれは凄い事だと思うよ
290 ：デフォルトの名無しさん：2007/03/14(水) 21:42:23: 後は用途によってノンテンポラル関連を使うとかだよな。
291 ：285：2007/03/15(木) 23:32:55: >>289
最初はそう思おうとしたが、さらに速いマシンで実行したら効果がさらに薄くなったんだよつД｀
1Gコピーしても50msも変わんねぇ
292 ：・∀・）っ-○◎●：2007/03/15(木) 23:38:30: そんな大容量のコピーするからこそかわらんのですよ
キャッシュの中でうまく捏ね回すのがSIMDプログラミングの掟
293 ：デフォルトの名無しさん：2007/03/15(木) 23:42:26: 正直単純なメモリ転送を最適化する暇があるなら、転送中ヒマをもてあましてる演算器の活用方法でも考えたほうが。
294 ：デフォルトの名無しさん：2007/03/19(月) 13:38:50: 32bitのDIB(R8G8B8A8)を24bitのDIB(R8G8B8)にアルファブレンドする関数を書いているのですが、
Cでテーブルを使って実装すると、テーブルへのアクセスがボトルネックとなって、
他の処理と比べて重くなってしまいます（テーブルは256x512x4で、L2にも入らない）。
そこでMMXを使ってみようと考えたのですが、
MMX命令を用いた計算方法そのものは分かるものの、
ピクセル単位の異なる二つの画像を、上手くMMXレジスタに配置する方法が分かりません。
どなたかご教授下さいませんか。
＃どちらのDIBも、横幅が8の倍数であることは保障されています。
295 ：デフォルトの名無しさん：2007/03/19(月) 14:25:33: mov ecx, pixelcnt
mov esi, DIB32
mov edi, DIB24
label:
mov mm0, esi
mov mm1, edi
--なんか処理--
add esi, 4
add edi, 3
loop label
後は最初か最後にediからの読み込みに1Byte前後して読んでシフトする処理が必要になるけど、
ループの外で処理すればいいし、テーブル参照するよりゃ速いんじゃね？
296 ：デフォルトの名無しさん：2007/03/20(火) 13:51:06: >>295
どうもありがとうございます。
シフト処理を入れたら上手く配置できて、
二倍近く速度が出るようになりました。
297 ：デフォルトの名無しさん：2007/04/04(水) 17:21:13: >295
どーでもいいけど、
mov mm0, [esi]
mov mm1, [edi]
じゃね？
298 ：・∀・）っ-○◎●：2007/04/04(水) 21:13:55: っていうかmovdじゃね
299 ：デフォルトの名無しさん：2007/04/05(木) 02:13:45: movq な。
300 ：デフォルトの名無しさん：2007/04/05(木) 02:18:01: あ、この場合movqでなくてmovdになるか…。
301 ：デフォルトの名無しさん：2007/04/06(金) 04:15:49: つまり団子は普通に名無しで潜伏してる
302 ：・∀・）っ-○◎●：2007/04/06(金) 21:41:06: イミフ
303 ：デフォルトの名無しさん：2007/05/26(土) 14:50:25: ttp://www.cutt.co.jp/book/4-87783-169-1.html

こんな本が出てるね。初学者にはありがたいかも。
SSSE3やSSE4の解説は載ってないっぽいけど、仕方ないか・・・。
304 ：デフォルトの名無しさん：2007/05/26(土) 20:06:23: 上下で都合2ﾏｿ取ろうっての？ボッタクリ過ぎだろ。
x86アセンブラ入門＋IntelのPDFで十分。
305 ：・∀・）っ-○◎●：2007/05/27(日) 16:37:14: >>303
要らん

操作画面の横でPDF表示する為のサブディスプレイを2万で買ったほうが有意義
306 ：デフォルトの名無しさん：2007/05/27(日) 16:53:13: ひでぇ商売だ
307 ：・∀・）っ-○◎●：2007/05/27(日) 16:59:20: 著者の情報調べてみた
ttp://www.vector.co.jp/vpack/browse/person/an001828.html

最近の作品さっぱり無いな
308 ：デフォルトの名無しさん：2007/05/27(日) 17:41:16: mmxって廃止なの？
代わりに何をつかえばいいの？
309 ：デフォルトの名無しさん：2007/05/27(日) 17:44:22: >>303
不要。
最近のコンパイラは、SSEを自動的に使ってくれる。
むしろ、その最適化にやさしいコードを書いた方がよい。
手動で最適化したところで、大抵数パーセントも上がらない。
310 ：・∀・）っ-○◎●：2007/05/27(日) 18:29:03: SIMD Intrinsicsの解説やってる実践的な本のほうが欲しいな。
それもIntelで十分か。
どうせならAltiVecとかCellのSPUとかも扱って移植性とパフォーマンスを両立する方法とかね。
311 ：デフォルトの名無しさん：2007/05/27(日) 22:26:02: >>310
Intrinsicsの解説自体はコンパイラのドキュメント読めば十分理解できるだろ。
むしろ実践的なアルゴリズムをいかにSIMDに落とし込むかという話のほうが読み応えないか？
312 ：デフォルトの名無しさん：2007/05/28(月) 18:33:00: >>309
アセンブラでSSE使うことが不要というのは言いすぎだと思う。
まあ、結果としてこの本が不要という結論にはなるだろうが。
313 ：デフォルトの名無しさん：2007/05/30(水) 00:27:06: >>310
移植とかは、COINSにお任せしておけば良いのでは
314 ：デフォルトの名無しさん：2007/05/30(水) 00:50:18: 金融SE、プログラマにこの辺やOpenMPのHPC系技術をおぼえてほしいんだがな。
誰もわからんからユーザーの俺がプログラミング。どういうこっちゃ。
315 ：デフォルトの名無しさん：2007/05/30(水) 00:59:53: 金融で、そんなにシングルスレッド性能がいるの？？
316 ：デフォルトの名無しさん：2007/05/30(水) 01:07:04: 金融の一部の分野は大量データの高速計算や
複雑な計算を瞬時に行う必要がある。
317 ：デフォルトの名無しさん：2007/05/31(木) 07:57:11: へー、どんな計算？
318 ：デフォルトの名無しさん：2007/05/31(木) 16:21:28: >>316
こういう奴ってさも物事を大げさに書きたがるが、具体的な例や数字は
一つも書かないから結局何を言っているのかさっぱりわからないんだよな。
319 ：デフォルトの名無しさん：2007/05/31(木) 19:24:02: >>318
こういう想像力の無い奴に物事を説明するのって疲れるんだよな
320 ：デフォルトの名無しさん：2007/05/31(木) 19:56:50: 想像力……ｗｗｗ
321 ：デフォルトの名無しさん：2007/05/31(木) 20:09:35: >>318
デリバのプライシングとか、ALMでのVaR計算とかなんだが詳しく書いても
多分分らんと思うが。
322 ：デフォルトの名無しさん：2007/05/31(木) 20:29:00: 知らないことを想像しろと言われても、ヒントもなしでは結構難しいと思うのだが。
323 ：デフォルトの名無しさん：2007/05/31(木) 20:31:13: リロードしてなかったorz
324 ：デフォルトの名無しさん：2007/05/31(木) 20:37:36: >321
それは具体的な「業務内容」であって、具体的な「例」でも「数字」でも無いと思うんだ。
ここが金融系の板ならそれで通じるかもしれんが、ここはム板だから。
例えば必要精度何桁でどんな数式を秒間何万件処理する必要があるとか、そういうこと。
専門用語でお茶を濁す事は具体例では無い。
325 ：デフォルトの名無しさん：2007/05/31(木) 20:52:19: >>324
たとえば百万件のデータから求める解を得るためにニュートン法等を数種類、複数回駆使ししたり
モンテカルロシミューレーションで数十万回の試行を行ったりといったこと。

これらはスレッド単位の高速化とマルチスレッドでの高速化により絶大な効果が得られる。
しかし高速化の技術を知るエンジニアは極めて少ないのが実情。

ってとこ。
326 ：デフォルトの名無しさん：2007/05/31(木) 21:51:55: モンテカルロ法でSIMD使って絶大な効果ってどんだけ単純なシミューレションだよ。
マルチコア、マルチCPU環境等でマルチスレッドなら同意できるが、
中途半端にSIMD使っても結局速くなった気がするだけ。

がちがちにコーディングする暇があるなら速くなるかもしれないけど
そんなことで工数がホイホイ増えるくらいなら計算機にお金使ったほうがマシ。
327 ：デフォルトの名無しさん：2007/05/31(木) 22:00:56: >>326
高速化するために数学的手法を駆使したMCなんだが
MCがすべて単純な繰り返しと思っているレベルの頭脳では話にならん。
328 ：デフォルトの名無しさん：2007/05/31(木) 22:27:38: >327
お前プログラマじゃないだろ？
具体例の無い説明といい、「ｘｘを駆使」とかいかにも営業が使いそうな言い回しといい、胡散臭すぎる。
329 ：デフォルトの名無しさん：2007/05/31(木) 22:35:50: >>328
流れを読め。

オレ＝>>314
これからこの話題につながってるんだが。

また別にお前に依頼してる訳ではないから具体的に書く必要性もない。
330 ：デフォルトの名無しさん：2007/05/31(木) 23:43:09: 以下、「お前こそ」禁止。
331 ：デフォルトの名無しさん：2007/06/01(金) 00:14:39: うーむ、よくみりゃ誤字ってたな。

>>327
MCが単純って書いた覚えはないよ。
金融工学の問題ってSIMDがクリティカルに利いてくるような
単純な代数計算なのかって話。
332 ：デフォルトの名無しさん：2007/06/01(金) 00:43:42: たとえばExceで用意されているNormdistといった確率分布関数のようなものは
商用ライブラリーを購入する手があるが、処理スピードと精度のトレードオフの調整が利かない。

これをCで組むと四則演算+EXPの多用となる。普通にプログラミングするとかなり遅いがSIMDを使うと大幅に
高速化する。SIMDにEXPがあると良いのだが。
333 ：・∀・）っ-○◎●：2007/06/01(金) 00:59:18: その辺はニュートン法使ったりテーラー展開したり。
Intelが数学用ライブラリ出してなかった？

x87のアレはどうせマクロ命令なので。
ちなみにdivpsとかで得られる商は近似値で精度低い。
334 ：デフォルトの名無しさん：2007/06/01(金) 01:06:33: 標準関数よりニュートンのほうが早いってことあるのか？
ニュートンは方程式を解くのに多用するが初期値問題があるしな。

MKLのEXPは使い方によるだろうが、メモリにデータを貯める必要があるときは高速だろうが
そうでないとメモリアクセスの遅さがネックになってあまり役立たない。
335 ：・∀・）っ-○◎●：2007/06/01(金) 01:12:44: SIMDで組み直せば標準関数のスループット越えることなんてざらにあるよ。
あくまでSIMD使うからこそ意味があるんだけど。
336 ：デフォルトの名無しさん：2007/06/01(金) 01:24:31: へ-そうなんだ。
とすれば試してみる価値あるな。

expのニュートンは簡単そうだし。。。
初期値どうするかな
337 ：デフォルトの名無しさん：2007/06/01(金) 01:33:41: 金融の問題って収束が遅いモンテカルロでどうにかなるのか。
338 ：デフォルトの名無しさん：2007/06/01(金) 01:37:50: 使わないですめばそれにこしたことはない。
解析的に求める方法がなければモンテカルロを使うしかない。
という理由で使われる。
339 ：デフォルトの名無しさん：2007/06/01(金) 09:24:19: 結局金融には直接関係ない部分の話になっちゃったね。
340 ：デフォルトの名無しさん：2007/06/02(土) 00:29:40: >>335
よく考えたら　f(x)=exp(x)で　f'(x)=exp(x)だからexpをニュートンで求めるのは無理だな。
　
テーラー展開でやってみたんだが
・テーラー展開式　exp(x)=∑x^n/n!
・階乗部分をすべて初期値設定
0!:n0=1
1!:n1=1
2!:n2=2
・・・
x:入力値
expsse:求める値

x=_mm_mul_pd(x,x);
expsse=_mm_add_pd((expsse, _mm_div_pd(x, n0));
x=_mm_mul_pd(x,x);
expsse=_mm_add_pd((expsse, _mm_div_pd(x, n1));
x=_mm_mul_pd(x,x);
expsse=_mm_add_pd((expsse, _mm_div_pd(x, n2));
・・・

こんな感じ。for分使わずn=20までやって精度９桁くらいだったかな。
しかし処理時間は非常に遅かった。
時間がなかったのであまり詳しく調べなかったがコーディングに問題あるかな？
341 ：デフォルトの名無しさん：2007/06/05(火) 01:32:46: Visual C++ 2005 で ssse3 の intrinsics が使えるようだ
342 ：・∀・）っ-○◎●：2007/06/05(火) 06:08:53: いつのまにSSSE3まで使えるようになったのか
インラインアセンブラのニーモニックは使えるが
343 ：デフォルトの名無しさん：2007/06/05(火) 14:01:57: >342
お前が>333でネタ振ったんだから責任もって>340のフォローしろや
344 ：・∀・）っ-○◎●：2007/06/05(火) 19:50:20: レイテンシのチェインがある mulpd→divpd→addpd
対象データが複数あるなら複数インターリーブするとスループットが稼げます。
345 ：デフォルトの名無しさん：2007/06/05(火) 20:33:01: >>344
その理論で行けばSPEのスカラも多くはスループット1クロックで処理出来るんだがな。
つーかx86にその理論を適用するにはレジスタが足(ry
346 ：・∀・）っ-○◎●：2007/06/05(火) 20:34:12: レジスタリネーム
347 ：・∀・）っ-○◎●：2007/06/05(火) 20:39:13: XORでゼロクリアしたり（Core 2からSIMDレジスタにも適用）
データ移動（部分データ移動は不可）するとレジスタリネームのヒントになる

SIMDレジスタは内部的に80程度はあるからそこそこいけるんでない？

Cellの演算ユニットはIntelアーキのそれの倍のレイテンシがかかる。
SPEのスカラが性能でないのは、そもそもベクタ化すら出来ないデータを
並列処理でレイテンシ隠蔽するには限界があるから。
348 ：デフォルトの名無しさん：2007/06/05(火) 21:00:36: 演算器が先にストールする。
349 ：デフォルトの名無しさん：2007/06/05(火) 21:06:06: 連投失礼。
レジスタリネームとかって言ってる人のコードの書き方に興味がある。
よっぽどコンパクトな演算じゃない限り演算結果をレジスタから追い出さなきゃいけないと思うんだが。
350 ：デフォルトの名無しさん：2007/06/05(火) 21:36:42: 問題は十分な精度が得られないことだと思う

速度を上げることはそんなに難しくない

定数除算を逆数との乗算に置き換える
↓
a4*x^4 +a3*x^3 +a2*x^2 +a1*x + a0
↓
(((a4*x+a3)*x+a2)*x+a1)*x+a0
↓
tmp=a[N]
for(i=N-1;i>=0;i--) tmp=tmp*x+a[i]
↓
(初期化部分は省略)
LOOP:
mulpd xmm4, xmm0
mulpd xmm5, xmm1
mulpd xmm6, xmm2
mulpd xmm7, xmm3
addpd xmm4, [esi]
addpd xmm5, [esi]
addpd xmm6, [esi]
addpd xmm7, [esi]
add esi, 16
sub ecx, 1
jnz LOOP
351 ：・∀・）っ-○◎●：2007/06/05(火) 21:50:00: いや除算は近似値命令だから乗算に置き換えるだけである程度
精度確保できるんじゃないの？

Intelはx87倍精度は内部的に80ビット精度に展開して処理してるけど
SSEは精度度外視してたような。
精度が必要ならx87のほうがいいかもしれない
352 ：デフォルトの名無しさん：2007/06/05(火) 22:11:04: 近似値なのはrcpps,rsqrtps命令で、
divpsは近似値じゃないんじゃない？
353 ：・∀・）っ-○◎●：2007/06/05(火) 22:21:41: いや近似値。内部的に逆数近似値と乗算してるだけ。
354 ：・∀・）っ-○◎●：2007/06/05(火) 22:22:19: ちなみに本物の除算は何十クロックもかかりますから。
355 ：デフォルトの名無しさん：2007/06/05(火) 22:28:36: >>353
そのソースは？
rcppsのレイテンシとmulpsのレイテンシを足しても
divpsのレイテンシよりずっと短いよ。
インテルの命令セットマニュアルには
rcpps,rsqrtpsの説明には近似値であると明記してあるけど、
divpsには近似値なんて書いてないよ。
356 ：デフォルトの名無しさん：2007/06/05(火) 22:32:08: x87を比較対象にしてるでしょ。
そら80bitなら何十クロックもかかるわな。
357 ：デフォルトの名無しさん：2007/06/05(火) 23:08:46: >>350
スマン、教えてほしい
（アセンブラは苦手なだが)多項式近似のパタンは和算→乗算の繰り返しでやるしかないという認識なのだが
乗算を先に4つやって、あとから和算4つ行うって計算は可能なのか？
358 ：>>357：2007/06/05(火) 23:13:47: >>344
> 対象データが複数あるなら複数インターリーブするとスループットが稼げます。
359 ：デフォルトの名無しさん：2007/06/05(火) 23:31:26: >>358
そういう手があるのか
サンクス
360 ：・∀・）っ-○◎●：2007/06/06(水) 00:30:48: >>340と>>350の式が一致してない気がするの気のせい？
361 ：・∀・）っ-○◎●：2007/06/06(水) 00:31:53: >>355
すまんそうだったかも。
ただ仮数部全部厳密に求めるほど精度なかったと思う
362 ：デフォルトの名無しさん：2007/06/06(水) 00:34:38: >>360
別物。テーラー展開とチェビシェフ系の違い。
363 ：350：2007/06/06(水) 01:01:20: >>360
>>340のテーラー展開式とintrinsicsでの実装が一致していない
364 ：340：2007/06/06(水) 19:11:56: >>344
回答ありがとう。
俺の知識ではいま一つ分らんが命令の並び順に工夫がいるということと
他のデータも同時に処理できたら同時に行うということかな。

>>363
確かに最初がまちがっとる。記述ミスなのできにしないでくだはれ。
ま、exp（）だと近似式でやったほうが速そうだね。
365 ：340：2007/06/06(水) 19:15:18: ところで金融システムをやる人たちはこの辺の技術を
ほとんど知らないのだけれど皆さんはどの分野でやられてるのでしょうか？
366 ：デフォルトの名無しさん：2007/06/06(水) 21:54:11: 信号処理とかゲームじゃないかな。
逆に聞きたいのは、金融の分野で応用効くの？
桁数が必要だろうし、スピードよりも可読性が求められそうじゃ無い？
367 ：340：2007/06/06(水) 23:23:51: 金融では最近一部グリッドが導入されだしたようだけど
HPC分野はほとんど未開拓な状態だと思う。
またSIMDとかMPIなどは外資パッケージソフトの一部では使われている。

SEへの「もっと計算を速くできないか」との要請に対し
自分の無知なことも知らず「莫大な金と時間がかかる」の一点張りで受け入れられないケースが多い。
このため多くのユーザーは高速化は無理なことと思っている。

という状況下、前にも挙げたようにリスク管理やデリバティブ関連などでは高速化へのニーズは高く、
この辺からHPC化が進んでいくと思う。
現時点では、すぐ欲しい計算結果も下手をすると数日かかるといったことが、あたりまえにおこなわれているから・・・
368 ：・∀・）っ-○◎●：2007/06/06(水) 23:36:08: っていうかmsdn2みたけど
VC++だと数学関数はSSE2対応ならSSE2版使ってくれるようになってるみたい？

純正の最適化ルーチンより速くしようと考えるのはぶっちゃけかなり無謀かと。
369 ：340：2007/06/06(水) 23:57:04: exp()はそれほど問題になっていないからいいんだけど
問題は上に書いたことなんだ。

皆さん、金融システムやらないかい？
370 ：デフォルトの名無しさん：2007/06/07(木) 01:16:32: 仕事にする気はないが話題として興味はあるな。
重たいのはDBとかで、SIMD化するようなものでは無いイメージがある。
371 ：デフォルトの名無しさん：2007/06/07(木) 01:19:32: そんなのアプリによるのでは？
372 ：デフォルトの名無しさん：2007/06/07(木) 01:23:59: 書き込みタイミングも全体パフォーマンスには注意が必要
373 ：デフォルトの名無しさん：2007/06/18(月) 23:11:59: 【派遣ネガティブ根性チェック】

3つ以上、チェックがつけばアナタの性格はひん曲がっており、
ネガティブ負け組派遣人生を歩んでいます。

□派遣先正社員の作った糞開発ツールはたとえ腐っててもマンセーして使う
□派遣先の人事権のある社員の意見はたとえ間違っていてもマンセーする
□昼食は必ず派遣先の社員と行くべきだ
□派遣先から「いつまでもここで仕事してくださいね(安い金でｗ)」と言われて嬉しい
□自社で仕事なんてできるわけがない
□派遣労働の問題点の話題が出ると感情剥き出しにして反論する
□派遣労働の問題を指摘する人は嫌いだ
□派遣先には仕事だけでなくプライベートについてもグイグイ引っ張って欲しい
□奢ってくれる派遣先正社員を尊敬する
□自分の月額金額を知らないのは当然だ、単金を聞いてはいけない
□派遣先正社員より自分の生涯収入が低いのは当然だ
□派遣先に尻尾を振り、かわいがってもらうことが大切だ
□チビは派遣先にかわいがってもらいやすから派遣には有利だ
374 ：デフォルトの名無しさん：2007/06/22(金) 00:18:26: ねぇねぇこれSSE使ってかける？

int RSHash(string cr)
{
int b = 378551; //Ramdom Ranges I've chosen (can be modified)
int a = 63689;
int hash = 0; //Output hash
int i; //Temp number that scrolls through the string array

for(i = 0; i < cr.length(); i++) //Loop to convert each character
{
hash = hash * a + cr[i]; //Algorithm that hashs
a = a * b;
}

return (hash & 0x7FFFFFFF); //Returns the hashed string
}
375 ：デフォルトの名無しさん：2007/06/22(金) 00:43:56: PMULUDQか。
2つの文字列を同時に処理するなら使えるかな？
376 ：・∀・）っ-○◎●：2007/06/22(金) 00:54:28: intは32ビットね？

MMX/SSE2の掛け算は16ビット×16ビットまでしかできないから
半端に使ってもかえって遅くなるような。

依存関係がきれいに解決できてpmaddwdが適用できれば速くはなりそうだが。
377 ：・∀・）っ-○◎●：2007/06/22(金) 00:55:54: >>375
ああそっちがあったかど忘れしてた
378 ：・∀・）っ-○◎●：2007/06/22(金) 01:07:24: ループの内側を２倍に引き伸ばすとこうか？

hash = (hash * a * a * b) + (cr[i] * a * b) + cr[i+1];
a = a * b * b;

引き伸ばしていけば並列演算できそうなところは結構あるんだが、さて・・・
ああ頭いてぇ
379 ：デフォルトの名無しさん：2007/06/22(金) 01:46:48: SSE入門したいのですが
みんなどこから手をつけはじめたのですか？
380 ：341：2007/06/22(金) 02:34:18: 使い方
intrin.hをインクルードすることでSSE3のintrinsicsまでは使える
SSSE3のintrinsicsは自前で各命令を定義することで使えようになる

例
#include <intrin.h>
/* MMX */
__MACHINEX86X_NOWIN64(__m64 _mm_abs_pi8(__m64))
__MACHINEX86X_NOWIN64(__m64 _mm_sign_pi8(__m64, __m64))
__MACHINEX86X_NOWIN64(__m64 _mm_alignr_pi8(__m64,__m64, int))

/* XMM */
__MACHINEX86X_NOIA64(__m128i _mm_abs_epi8(__m128i))
__MACHINEX86X_NOIA64(__m128i _mm_sign_epi8(__m128i, __m128i))
__MACHINEX86X_NOIA64(__m128i _mm_alignr_epi8(__m128i,__m128i, int))

問題点
palignr命令の3番目の引数が定数でもエラーにならない
381 ：341：2007/06/22(金) 02:38:44: >>380の訂正
問題点
palignr命令の3番目の引数が『定数でない場合に』エラーにならない
382 ：デフォルトの名無しさん：2007/06/22(金) 15:15:51: >>379
俺も最初はこんなのから始めて動作を確認していった。
（この書き方、aがポインタか配列かって区別がややこしいんだが）

#include<stdio.h>
int main()
{
int i,a[]={12,23,34,45};
__asm{
movdqu xmm0,a
paddd xmm0,xmm0
movdqu a,xmm0
}
for (i=0; i<4; i++) printf("%d\n",a[i]);
return 0;
}
383 ：・∀・）っ-○◎●：2007/06/22(金) 23:23:53: >>381
すまん意味不明。エラーにならないならどんなコード吐くの？
384 ：341：2007/06/23(土) 00:28:50: 定数の場合
0f 3a 0f c1 01 palignr mm0, mm1, 1

定数でない場合
0f 3a 0f c1 ac palignr mm0, mm1, DWORD PTR _i$[ebp]
385 ：デフォルトの名無しさん：2007/06/23(土) 09:10:46: IA-32 SIMDリファレンス買ってみた。

図がいぱい載ってるぞw
386 ：デフォルトの名無しさん：2007/06/24(日) 09:40:42: >>340
exp(x)=2^(y1+y2)と変換する（y1は整数部y2は少数部）
y2を多項式近似で求めると速くできる
10桁程度の精度でよければ7次で可能
>>465
387 ：デフォルトの名無しさん：2007/06/28(木) 12:38:59: >exp(x)=2^(y1+y2)と変換する（y1は整数部y2は少数部）
それをやるならy1は整数、y2は-0.5<=y2<0.5と選んだ方がよさそうだね。
388 ：デフォルトの名無しさん：2007/06/29(金) 01:19:41: ＞＞３８７
そうだね。
ところでｙ１が正のときはビットシフトで行けるんだが
負の時はいい方法ないかね？
389 ：デフォルトの名無しさん：2007/06/29(金) 12:06:17: IA-32SIMDリファレンスブック
こんな本が出てるね
390 ：デフォルトの名無しさん：2007/06/29(金) 13:24:55: >>303-309
391 ：デフォルトの名無しさん：2007/07/03(火) 22:32:30: 書店でぱらっと見た感じではSSSE3まで紹介してるみたいだけど
これでどうやって下巻を書くつもりなんだろう
392 ：デフォルトの名無しさん：2007/07/08(日) 00:12:54: 誰かSSE2にrcppdとrsqrtpdがない理由を合理的に説明してください
393 ：デフォルトの名無しさん：2007/07/08(日) 00:20:39: あえて近似解をDoubleで使う必要はないからだろう
394 ：デフォルトの名無しさん：2007/07/08(日) 01:16:16: SSEのrcpps,rsqrtpsって
｜相対誤差｜≦ 1.5×2^-12
って書いてあるから、
仮数部12bitくらいの精度しかないって事だよね？
395 ：デフォルトの名無しさん：2007/07/08(日) 01:17:58: rcppsからもってけるから。命令数も倍になるがな。
そして倍精度にそんなトランジスタ割けないというのが合理的理由だろう。
396 ：395：2007/07/08(日) 01:27:58: あー失礼。トランジスタを割けないという主張は同じなんだが
仕組みとしてはテーブルを引いてるだけのはず。
だから24bitとか32bit分ものテーブルを用意出来るわけが無い。

倍精度を使うような人は精度重視なわけで、
divpdあるんだからどうしてもやりたいんだったらソフトウェアでrcppsから精度上げてくれ、
マイクロコードを用意するのはバカバカしい、ということ。
397 ：デフォルトの名無しさん：2007/07/08(日) 01:42:11: >>396
能書き垂れてるんだが
結局393と何が違うんだよ
398 ：395：2007/07/08(日) 08:28:15: >>397
違いは無い。ただ393だけ言われても392が納得しづらいだろう。

テーブルの要素数が
12bit->4096
24bit->1677万
だけ必要であると考えれば物理的に無理な事が納得出来る。
399 ：・∀・）っ-○◎●：2007/07/08(日) 13:13:44: まあマイクロコード組み合わせればできなくも無いだろうけど
クロック数かかる上に【近似】解じゃねぇ
400 ：デフォルトの名無しさん：2007/07/09(月) 22:20:07: >>389
この本買ってみたけど、リファレンスいうから命令全部載ってるのかと思ったら載ってなかった
手元にリファレンス的なものがあるといいなと思って買ったのに・・・詐欺だわー超高いし
401 ：薄汚い派遣の国、日本：2007/07/15(日) 21:35:53: 最近、職場で「出戻り寄生派遣」という言葉が囁かれています。
派遣契約を切られたにもかかわらず「次の派遣先でも切られてしまって生活できません」
などと言って泣き落としで再契約した派遣のことです。
今月初め、半年前に切った派遣が出社してきてみんなびっくりしました。
影でコソコソ偉い人に泣きついて再契約したそうです。同じ部署の人には黙って・・・
そんなことまでして自宅の近くの派遣先にこだわって人間として恥ずかしくないのですか。
派遣でスキルアップ、派遣で収入アップとか言うなら一箇所にしがみつかず
複数の会社を渡り歩いてください。
ひとつの会社で派遣向けの単調な仕事をしていたらスキルアップなんてありえないでしょう。
身分不相応な商品のローンを払うために派遣だと当然足りない収入は親にも寄生して、
いつ切られるんじゃないかとビクビクしながら人事権のある人間とだけ仲良くし、
契約終了を通知されれば泣き落とし。悲惨な人生ですね。
氏んだほうがいいんじゃないですか。
402 ：デフォルトの名無しさん：2007/07/19(木) 19:33:12: >>400
http://download.intel.com/jp/developer/jpdoc/IA32_Arh_Dev_Man_Vol1_Online_i.pdf
これでええやん。
あとはビルトイン関数のヘッダ見ればだいたい書けるだろ。
403 ：デフォルトの名無しさん：2007/07/21(土) 21:32:10: 【派遣ネガティブ根性チェック】

3つ以上、チェックがつけばアナタの性格はひん曲がっており、
ネガティブ負け組派遣人生を歩んでいます。

□派遣先正社員の作った糞開発ツールはたとえ腐っててもマンセーして使う
□派遣先の人事権のある社員の意見はたとえ間違っていてもマンセーする
□仕様とは正社員から口伝されるものだ
□口伝された仕様を意図どおり理解できなかったのは自分の責任だ
□昼食は必ず派遣先の社員と行くべきだ
□自分の仕事で問題が発生しても解決するのは派遣の仕事ではない
□派遣先から「いつまでもここで仕事してくださいね(安い金でｗ)」と言われて嬉しい
□自社で仕事なんてできるわけがない
□派遣労働の問題点の話題が出ると感情剥き出しにして反論する
□派遣労働の問題を指摘する人は嫌いだ
□派遣先には仕事だけでなくプライベートについてもグイグイ引っ張って欲しい
□奢ってくれる派遣先正社員を尊敬する
□自分の月額金額を知らないのは当然だ、単金を聞いてはいけない
□派遣先正社員より自分の生涯収入が低いのは当然だ
□チビは派遣先にかわいがってもらいやすから派遣には有利だ
404 ：デフォルトの名無しさん：2007/07/27(金) 18:34:11: SSE2で、ベクトルの各要素ごとに独立なシフト量を設定してシフトを行うことは不可能
という理解で良いですか?
a[0] <<= b[0]
a[1] <<= b[1]
a[2] <<= b[2]
a[3] <<= b[3]
みたいな事がやりたいんですが。
405 ：デフォルトの名無しさん：2007/07/27(金) 20:05:42: >>404
処理速度は劣るが、シフトの代わりに乗算で処理するとか。
406 ：デフォルトの名無しさん：2007/07/27(金) 23:47:27: 残念ながらそれだとスカラーよりも遅くなってしまいました。うーむ
407 ：デフォルトの名無しさん：2007/07/28(土) 09:54:29: そうか。面白そうな問題なので何とかして高速化したいなあ。
408 ：・∀・）っ-○◎●：2007/07/29(日) 02:13:32: >>404
うん無理。AltiVecだとできるんだよねそれ。
409 ：・∀・）っ-○◎●：2007/07/29(日) 02:26:32: 下位ビット落ちるけどこんなのはどう？
cvttpi2ps→指数部操作→cvttps2pi
410 ：341：2007/08/25(土) 01:58:03: VC++ 2008のIntrinsicsは
Intel SSSE3/SSE4.1/SSE4.2とAMD ABM/SSE4aに対応しているようだ
411 ：・∀・）っ-○◎●：2007/08/25(土) 03:04:10: Intelでいうとsmmintrin.hって奴か。

なにSって。
412 ：デフォルトの名無しさん：2007/08/26(日) 11:25:57: 失礼します。

MMXのシフト系の命令って、ソースオペランドに直値、メモリ、MMレジスタのみですよね？

汎用レジスタ（eaxとか）を書いてもうまく動作しなかった気がするんですが、
VC6,VC8ともに、以下のコードがエラーにならず通ってしまいます。

psllq mm0 , eax

何か勘違いしてますか？
413 ： ◆0uxK91AxII ：2007/08/26(日) 13:46:03: >>412
disassembleしてみたまえ。
414 ：デフォルトの名無しさん：2007/08/26(日) 14:50:52: >>413
eaxって書いたところがmm0になってました。

インラインアセンブラのバグ？　VC6のころからそうなのに
VC8でも放置してるのはなんか理由があるのかな。
415 ：・∀・）っ-○◎●：2007/08/26(日) 17:02:22: mm0もeaxも3ビット表現の 0 だもの。
汎用・FP/MM・XMMのレジスタ指定はopcodeで決まるから
416 ：デフォルトの名無しさん：2007/08/26(日) 17:31:27: >>415
逆アセしてmm0に見える理由がそれだとしても、アセンブラの文法
としてeaxって書くべきではないところに、そう書いてエラーにしない
のはおかしいと思いませんか？
417 ：・∀・）っ-○◎●：2007/08/26(日) 17:32:25: movd eax mm0と
movd mm0, eax

だとどうなるかな。opcodeで区別してるはずだが
418 ：デフォルトの名無しさん：2007/08/26(日) 17:44:31: その命令は見た目どおりに動くので、特にいうことはありません。
419 ：デフォルトの名無しさん：2007/08/30(木) 17:09:15: >>404
AMDが発表したSSE5で独立シフト量ができるようになるね。
SIMDのローテート命令まで追加されてる。
http://developer.amd.com/assets/sse5_43479_BDAPMU_3-00_8-27-07.pdf
420 ：デフォルトの名無しさん：2007/09/02(日) 04:12:12: もう32bit fpと整数はAltiVec互換にしてくれよ
AltiVecからSSEに仕方なく移ったマカーな俺にはSSEは使いにくすぎる
421 ：デフォルトの名無しさん：2007/09/02(日) 04:17:13: でもload/storeのアラインメントの扱いが楽なのはちょっといいと思った
422 ：・∀・）っ-＜コ:彡-：2007/09/04(火) 07:15:10: SSE4.1でXMM-汎用レジスタ間のデータ出し入れが簡単になるからシフトやローテートは我慢。
423 ：デフォルトの名無しさん：2007/09/05(水) 23:49:14: >>422
もー出てるなら我慢できるけどさ、まだ出てないじゃん。
424 ：・∀・）っ-＜コ:彡-：2007/09/06(木) 00:47:16: それ言っちゃうとBulldozerはおろかBarcelonaすら出てないが
425 ：デフォルトの名無しさん：2007/10/19(金) 17:12:17: MMXのpmull, pmulhはどういう使い方が想定されているのでしょうか？
なんか使いにくそうに思えるのですが……。
426 ：デフォルトの名無しさん：2007/10/19(金) 19:17:59: >>425
pmull : 16 bit で済む時
pmulh : 小数部 16 bit の固定小数点乗算したい時
427 ：ヽ・´∀｀・,,）っ━━━━━━┓：2007/10/20(土) 01:26:21: xbyakを魔改造するか
428 ：デフォルトの名無しさん：2007/10/24(水) 22:36:46: IA-32 SIMDリファレンスブック＜下＞
http://www.cutt.co.jp/book/4-87783-170-7.html

SSSE3まで
SSE4はない
429 ：デフォルトの名無しさん：2007/10/24(水) 22:52:02: だから高いって。
430 ：デフォルトの名無しさん：2007/10/25(木) 01:49:44: ぼったくりでそれか。マジいらん。
431 ：ヽ・´∀｀・,,）っ━━━━━━┓：2007/10/25(木) 01:55:23: SDK for 45nm Next Generation Intel Core 2 Processor Family and Intel SSE4

にSSE4.1/4.2のマニュアル一式とエミュレーションDLLがついてるからそれで十分。
432 ：デフォルトの名無しさん：2007/10/27(土) 05:20:50: 総和を求めるなど、一つの変数が共通の場合、SSEを使って計算するCコードを教えてください
433 ：ヽ・´∀｀・,,）っ━━━━━━┓：2007/10/28(日) 02:23:19: 総和なら簡単じゃん

__declspec(align(16)) float a[100];
float dest;

//SIMD化前
for (int i = 0; i < 100; i++) {
sum += a[i];
}

//SIMD化後
__m128i sumx = { 0.0f,0.0f,0.0f,0.0f };
for (int i = 0; i < 100; i++) {
sumx = _mm_add_ps(sum, *(__m128*)&a[i*4]));
}
sumx = _mm_hadd_ps(sumx, sum);
sumx = _mm_hadd_ps(sumx, sum);
_mm_store_ss(sum, sumx);
434 ：ヽ・´∀｀・,,）っ━━━━━━┓：2007/10/28(日) 02:24:14: 訂正

//SIMD化後
__m128i sumx = { 0.0f,0.0f,0.0f,0.0f };
for (int i = 0; i < 100; i+=4) {
sumx = _mm_add_ps(sumx, *(__m128*)&a[i]));
}
sumx = _mm_hadd_ps(sumx, sum);
sumx = _mm_hadd_ps(sumx, sum);
_mm_store_ss(sum, sumx);
435 ：デフォルトの名無しさん：2007/10/31(水) 21:29:38: movqに対応する組込み関数ってないん？
436 ：デフォルトの名無しさん：2007/10/31(水) 21:57:18: _mm_loadl_epi64
437 ：デフォルトの名無しさん：2007/10/31(水) 22:03:36: Σ(・ω・ﾉ)ﾉエッ
438 ：デフォルトの名無しさん：2007/11/01(木) 00:19:03: __m128i _mm_loadl_epi64(__m128i*)
__m128i _mm_move_epi64(__m128i)
void _mm_storel_epi64(_m128i*, __m128i)
439 ：デフォルトの名無しさん：2007/11/01(木) 02:28:07: sse4のベンチ見てるとちょっと心配になってくるな。
440 ：ヽ・´∀｀・,,）っ━━━━━━┓：2007/11/01(木) 23:00:54: >>435
MMXのは無い。
__m64 mm0 = a[i]で既にロードに展開される。てか、コンパイラ任せ。
441 ：デフォルトの名無しさん：2007/11/14(水) 19:03:24: x86の話なんですが

64ビット整数のグローバル変数1つを操作する関数が
頻繁に呼ばれるプログラムを作っています。
アセンブラ見ると、32ビットずつ操作しているようなんですが
これをMMXを使っていっぺんに操作するようにすれば、高速化しますか？

高速化するなら、MMX勉強してみようかなと思ってるのですが。
442 ：デフォルトの名無しさん：2007/11/14(水) 19:57:23: しません
443 ：デフォルトの名無しさん：2007/11/14(水) 19:59:23: andとかorとかビット演算だけなら可能性がないとも言えない。
444 ：デフォルトの名無しさん：2007/11/14(水) 22:10:28: >>441
double でやればー?
445 ：ヽ・´∀｀・,,）っ━━━━━━┓：2007/11/14(水) 23:38:44: 関数コールのインライン化のほうがまだ効果あるかもな
446 ：デフォルトの名無しさん：2007/12/22(土) 23:14:35: 2つの4byteのデータを先頭から任意の
ビット数一致しているかチェックするのに
SSEって有効に使えそう？1ビットずつチェック
とかアホ過ぎて

uint32_t chk_bit(uint32_t master, uint32_t src, uint32_t bit){
この中どうしよう。
}
447 ：ヽ・´∀｀・,,）っ━━━━━━┓：2007/12/22(土) 23:53:57: 【この中】
return ((master ^ src) >> (32 - bit)) != 0;
448 ：デフォルトの名無しさん：2007/12/24(月) 00:16:33: xmmレジスタを128bit intとして使う場合，
あるbitが立っているかどうかを高速に調べる方法はありませんか？
SSE4.1でptst命令が導入されますが，それまで待ってられません．
449 ：ヽ・´∀｀・,,）っ━━━━━━┓：2007/12/24(月) 00:30:38: xmm0に調べたい値ががあるとすれば

movdqa xmm1, [pattern]
movdqa xmm2, xmm0
pand xmm2, xmm1
pcmpeqb xmm2, xmm1
pmovskb eax, xmm0
test eax, eax

でeaxが0以外ならビットが立ってる。
450 ：ヽ＞´∀｀＜,,）っ━━━━━━┓：2007/12/24(月) 00:31:51: pmovmskbに訂正してくだしあ＞＜
451 ：デフォルトの名無しさん：2007/12/24(月) 00:46:27: THX
やはりpmovmskbで移すしかありませんか．．．
Nehalemまでは64bit int x 2でやっとくのが吉？
452 ：デフォルトの名無しさん：2007/12/24(月) 11:21:12: ptestはPenrynじゃね？
453 ：デフォルトの名無しさん：2007/12/24(月) 13:14:13: LARGE_INTEGER otime, ntime;
～略～
double dt = (double)((ntime.QuadPart - otime.QuadPart) * (1000.0f / f.QuadPart));

をSSE使ってVC8のインラインアセンブラで書くとどうなりますか？
454 ：デフォルトの名無しさん：2007/12/24(月) 19:38:49: どう考えてもスカラ演算だよね
455 ：デフォルトの名無しさん：2007/12/24(月) 20:04:35: 64bit整数を64bit浮動小数点数に返還するSSE命令は
64bitモードにしかありません
VCでは64bitモード用のプログラムにインラインアセンブラは使えません
456 ：ヽ＞´∀｀＜,,）っ━━━━━━┓：2007/12/24(月) 20:30:13: *intrin.hのマニュアルを見ればいいと思うが
457 ：デフォルトの名無しさん：2007/12/24(月) 20:32:45: SSEで書く利点なくね？
458 ：ヽ＞´∀｀＜,,）っ━━━━━━┓：2007/12/24(月) 20:37:16: 無いな
459 ：デフォルトの名無しさん：2007/12/24(月) 20:58:49: 書けても手間損
460 ：デフォルトの名無しさん：2007/12/24(月) 21:00:24: ファイヤーウォール作る時に
パケット解析するのにSSE使っても
手間になるだけ？
461 ：ヽ＞´∀｀＜,,）っ━━━━━━┓：2007/12/24(月) 21:02:06: そろそろテンプレ作ったほうがいいんじゃないの。
SSEは大量のデータに同じ処理をかけるときにこそ効果を発揮するんであって
細かい所は従来のx86命令のほうがむしろ速い。
462 ：ヽ＞´∀｀＜,,）っ━━━━━━┓：2007/12/24(月) 21:03:24: >>460
そういうのに向いてるって話は聞いたことがない。
463 ：デフォルトの名無しさん：2007/12/24(月) 21:55:34: 単一の64bitや128bit値を何回も計算するときは？
464 ：デフォルトの名無しさん：2007/12/24(月) 21:57:38: 汎用レジスタに納まらないサイズ弄るなら効果あるんじゃないの?
465 ：ヽ・´∀｀・,,）っ━━━━━━┓：2007/12/24(月) 22:04:42: アレはあくまで32ビット値を4つ同時に扱うものであって、多倍長扱うならむしろ64ビットモードで汎用レジスタベースでやったほうがいい。
466 ：デフォルトの名無しさん：2007/12/24(月) 22:15:44: ( ･∀･)つ〃∩ ﾍｪｰﾍｪｰﾍｪｰﾍｪｰﾍｪｰ
467 ：デフォルトの名無しさん：2007/12/25(火) 17:49:27: PADDQとかの事だろうけどC2Dでもレイテンシ2だしね
実装はcarry selectあたりだろうか
468 ：451：2007/12/26(水) 11:18:07: >>452
遅レスだが
ptestはSSE4.1で，PenrynはSSE4じゃなかった？
469 ：デフォルトの名無しさん：2007/12/26(水) 11:52:30: SSE4はSSE4.1とSSE4.2の両方を含む呼称(正確には、という事になった)
Penrynは4.1のみ
Nehalemは4.1と4.2の両方

>>452で合ってるんじゃねーの？
470 ：451：2007/12/26(水) 13:20:32: >>469
どうもその様ですね，THX．
ttp://pc.watch.impress.co.jp/docs/2007/0925/hot507.htm
Penrynならそれほど待たなくて済むなぁ，どうしよう．
471 ：451：2007/12/26(水) 13:22:02: >それほど待たなくて済むなぁ
これは価格が手頃になるのを，って意味です
472 ：デフォルトの名無しさん：2007/12/26(水) 13:25:45: 64bit浮動小数点数の配列があったとき絶対値が最大の要素を
求めたいのですがSSE2を使って高速にできるでしょうか？
普段はVC++を使ってますがより高速化できるならアセンブラ
もつかってみようかと考えてます。OSはVista(64bit)です。
473 ：デフォルトの名無しさん：2007/12/26(水) 13:54:20: >>472
x64用ののVC++だとデフォルトでSSE2を使うようになっている。
下のを cl /c /O2 /FAsc test.c でコンパイルして、test.cod を見てみるとまあまあのコードが生成されているぞ。

double maxabs(double array[], int size)　{
  double ans = 0.0;
  for (int i=0; i<size; i++) ans = __max(ans, abs(array[i]));
  return ans;
}
474 ：デフォルトの名無しさん：2007/12/26(水) 18:30:53: >>473
Cだと「for (int i=0;」のところでエラーになるので
#include <cmath>
#include <cstdlib>
を付け加えてCPPファイルにしてコンパイルしてみました。
movsdx andpd comisd
などが使われていますね。これがSSE2かな？
でもこれが本当に高速なコードかどうかはわからないですね。

インテルでMKLというライブラリを出してますがこれはすごいですね。
試したのは行列計算の一部だけ（LU分解）ですが数値計算の本に載っている
プログラムをVC++でコンパイルしたものより5倍ぐらい高速です。
数学レベルで新アルゴリズムを開発した可能性は低いので実装レベル
の技術が高いと思うのです。
5倍の差は大きいのでSSEなどを勉強して何とか近づきたいのですが
大変かな？
475 ：デフォルトの名無しさん：2007/12/26(水) 18:38:45: dou you make correlated random number?
476 ：451：2007/12/26(水) 20:38:30: >>472
P4用でちょっと古いけど
「ストリーミング SIMD 拡張命令 2(SSE2)を使用した、倍精度浮動小数点ベクトルの最大/最小要素とそのインデックスの検出」http://download.intel.com/jp/developer/jpdoc/w_max_app_j.pdf
477 ：472：2007/12/26(水) 23:15:38: >>476
やりたいのは絶対値の最大なのでちょっと違うけどなかなか参考になります。
最大と最小をもとめて絶対値の大きな方をとる方法と
絶対値を計算しながら最大をもとめる方法がありますね。
まあこの辺はいろいろ実験してみないとどれがいいのかわからないですね。
478 ：ヽ・´∀｀・,,）っ━━━━━━┓：2007/12/27(木) 02:18:53: >>473
VC++だとmaxsdしか使わない予感。

>>473ベースで、arrayの要素が偶数個で128ビット境界にあってるの前提ならこんな感じ
たぶんSSE3くらいは使えるよね？たいしたことに使ってないけど。

#include <pmmintrin.h>
double maxabs(double array[], int size) {
static const union {
__m128d pd;
__int64 a[2];
} mask = { 0x7FFFFFFFFFFFFFFFi64, 0x7FFFFFFFFFFFFFFFi64 };
double ans;
__m128d ans_pd = { 0.0, 0.0 };
for (int i = 0; i < size; i+= 2)
ans_pd = _mm_max_pd( ans_pd, _mm_and_pd(mask.pd, *((__m128d*)&array[i])) );
ans_pd = _mm_hadd_pd(ans_pd, ans_pd);
_mm_store_sd(&ans, ans_pd);
return ans;
}
479 ：デフォルトの名無しさん：2007/12/27(木) 23:05:22: >>474
SIMD化の方が簡単で面白そうだから目につきやすいんだけど、そこは最後の手段なんだよね。

配列同士の四則演算では極力全ての演算をまとめて行って、代入を1回で済ます。
行列なんかの三次元的なループはキャッシュに入る長方形のブロック単位で処理をする。
そういうところが出来てればSIMD化しなくても前者で最大2倍くらい、後者は計り知れない程速くなる。
480 ：474：2007/12/28(金) 23:06:10: >>479
気持ちはわかるけど具体的にはどうやるのかな？
短いので高速化したいプログラムをアップしてみる。
#include <cmath>
double LU(int n, double** a, int* ip)
{
int i,j,k,ii,ik;
double t,u,det,*w;
w=new double[n];
for(k=0;k<n;k++){
ip[k]=k;
for(j=0,u=0;j<n;j++){ t=fabs(a[k][j]); if(t>u) u=t; }
if(u==0){ delete[]w; return 0; }
w[k]=1/u;
}
det=1;
for(k=0;k<n;k++){
u=-1;
481 ：474：2007/12/28(金) 23:08:38: 続き
for(i=k;i<n;i++){
ii=ip[i];
t=fabs(a[ii][k])*w[ii];
if(t>u){ u=t; j=i; }
}
ik=ip[j];
if(j!=k){
ip[j]=ip[k]; ip[k]=ik;
det=-det;
}
u=a[ik][k]; det*=u;
if(u==0){ delete[]w; return 0; }
for(i=k+1;i<n;i++){
ii=ip[i];
t=(a[ii][k]/=u);
for(j=k+1;j<n;j++) a[ii][j]-=t*a[ik][j];
}
}
delete[]w;
return det;
}
最後のforループが3重ループなのでこの付近が一番スピードに関係してそう。
482 ：デフォルトの名無しさん：2007/12/28(金) 23:33:40: キャッシュ効率上げればかんり高速化しそうだね
483 ：479：2007/12/29(土) 23:23:23: 恥ずかしながらLU分解はやった事無いんだけど
3重のループでa[ii]のラインはiに依存して切り替わり、
a[ik]のラインはkに依存して切り替わるでしょ。

a[ik]のラインはkにつき1度しか切り替わらないからキャッシュにずっと入ってるけど、
a[ii]のラインはkが同じでもiが変わったら切り替わってしまう。
a[ii]のラインは最大k回アクセスがあるから、出来れば切り替えたく無い。

そこで折衷案をとって、a[ik]をもう少し頻繁に切り替える代わりにa[ii]をもう少しゆっくり切り替わるようにバランスを取る。

バランスを取るというのはどういう事かと言うと、
二次元の処理で1000x1000の要素があった時に
1ラインずつ処理するのではなく例えば100x100のマスが10x10個あるものとして処理する。
(0, 0)-(999, 0)を処理してから(0, 1)-(999, 1)の処理をするんじゃなくて、
(0, 0)-(99, 0)まで処理して(0, 1)-(99, 1)...(0, 99, 99, 99), (100, 0)-(199, 0)のような処理の仕方。

今回はループが3重だから、書き換えると6重のループになって頭は最高にこんがらがる。
しかもラインがipによって入れ替わるみたいだから、こういう手法が使えるのかよく分らない。ごめん。
ipがどう変わるかを事前に必要なライン数分計算出来ればいいんだろうけど。
484 ：474：2007/12/30(日) 21:31:17: >>483
コメントありがとうございます
少し詳細に480のプログラム（LU1）と
intelのMKLを使った場合(LU2)とをテストしました。

サイズ(n) LU1(VC++) LU2(MKL) 比率
4 0.218μs 1.140μs 0.191
8 0.796μs 2.680μs 0.297
16 4.087μs 7.460μs 0.548
32 0.0246ms 0.0204ms 1.21
64 0.174ms 0.0656ms 2.65
128 1.31ms 0.271ms 4.83
256 10.2ms 1.435ms 7.11
512 82.4ms 9.13ms 9.03
1024 780ms 66.1ms 11.8
2048 7.58s 0.501s 15.1
4096 60.9s 3.79s 16.1
8192 486.5s 29.9s 16.3
CPU：intel Q6700(3.4GHz)

サイズが小さい場合はLU1でもキャッシュの利用効率が高いはずですが
予想どうりLU2との差が小さくなりnがごく小さいときは逆転しています。
たぶんLU2は複雑なやっていてそのため遅くなっているのでしょう。
nが非常に大きくなるとLU1はキャッシュ効率が悪いためLU2に大差をつけられてしまってます。

高速化をめざすならSSEの最適化を考える前にキャッシュ効率を上げる工夫をすべきですね。
となると483のような多重ループのブロック化が必然となるか？
まあ、難しそうなので具体的な方法は少し考えてみます。
うまいアイデアがありましたらまたコメントください。（ややスレ違いになりつつあるが）
485 ：デフォルトの名無しさん：2007/12/30(日) 22:03:51: ここは一応拡張命令のスレだからねえ。
もし移動するならここかな？
ttp://pc11.2ch.net/test/read.cgi/tech/1177808054/l50
486 ：デフォルトの名無しさん：2007/12/30(日) 22:07:51: ソフトウェア・プリフェッチの話を絡めつつやれば
スレ違いにならなずに済むか。
487 ：デフォルトの名無しさん：2008/01/16(水) 18:30:07: xmm の not を一命令で求める方法はありませんか？　~0 との xor は無しで
488 ：487：2008/01/16(水) 20:45:05: 上げときます
489 ：デフォルトの名無しさん：2008/01/16(水) 21:28:47: pandnでもダメだよな。
そうなると、周りの命令と絡めて実質的に１命令で済ますことを考えるくらいか。
490 ：デフォルトの名無しさん：2008/01/17(木) 00:08:24: 無理っぽいねぇ．all 1 の定数を read することを考えれば，
cmpeq xmm0,xmm0 で all 1 を作る方が速いか？
491 ：ヽ・´∀｀・,,）っ━━━━━━┓：2008/01/17(木) 00:58:10: all 1をロードだとレジスタリネーミングされるので先行実行できる可能性がある。
ケースバイケース。
492 ：デフォルトの名無しさん：2008/02/19(火) 10:43:09: メディアンフィルタを作成したいのですが、
コンパイラがSSEを使いやすいコードはどのように書いたらよいのでしょうか？
493 ：デフォルトの名無しさん：2008/02/20(水) 07:38:55: メディアンフィルタで自動ベクトル化は難しいなあ。
ソートアルゴリズムをGPUでやるやつみたいに直線的なものにすればやってくれない事は無いけど。
とにかく一番内側のループがベクトル同士の演算になるように心掛ける事。

121 KB [ ２ちゃんねる３億PV/日をささえるレンタルサーバー \877/2TB/100Mbps]

取りに行ったけどなかった。次は一時間後に取りに行くです。新着レスの表示

掲示板に戻る全部前100 次100 最新50

read.cgi ver 05.0.4.9 2007/06/21
FOX ★ DSO(Dynamic Shared Object)