MMX SSE 3D NOW!のプログラミング
レス数が950を超えています。1000を超えると書き込みができなくなります。
0001デフォルトの名無しさん
NGNG0002デフォルトの名無しさん
NGNG>>3どうぞ
0003デフォルトの名無しさん
NGNG>>3どうぞ
0004デフォルトの名無しさん
NGNGまたこの手のスレか
0005デフォルトの名無しさん
NGNG0006デフォルトの名無しさん
NGNG0007デフォルトの名無しさん
NGNG0008デフォルトの名無しさん
NGNGもうでねぇよ
0009デフォルトの名無しさん
NGNG0010デフォルトの名無しさん
NGNGマジ？早く出せよヴォケ！
0011デフォルトの名無しさん
NGNGインテルのコンパイラなんかには
C++のライブラリが含まれているがな。
0012デフォルトの名無しさん
NGNGそれってソース付き？
0013デフォルトの名無しさん
NGNG0014デフォルトの名無しさん ◆TCP/IPmFAM
NGNG0015デフォルトの名無しさん
NGNG#include <dvec.h>
0016デフォルトの名無しさん
NGNGたとえば1+2はどのように書けばよいのでしょうか？
0017デフォルトの名無しさん
NGNG0018デフォルトの名無しさん
NGNG0019EXCULTer's / Active metropolis ◆/80RBXpvJA
NGNG0020デフォルトの名無しさん
NGNG0021デフォルトの名無しさん
NGNGどっかに手頃なソースは落ちてないもんでしょうか。
できれば品質ではなくスピード重視のものがいいのですが。
002221
NGNG> 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/
002321
NGNG自分で勉強しなきゃ駄目なのかな、とほほ...
002421
NGNGMMXの命令セットは使えそうにもない事が
判明しました。どうすればいいんだ...orz
0025デフォルトの名無しさん
NGNGほい＞http://61.23.56.118/bilinear.zip
テストしてないし、補完テーブル作るとこだけ面倒でCだけど。
002621
NGNG早速試してみます。
0027デフォルトの名無しさん
05/02/21 12:55:29pmulはWORDしか対応していないようなので…
誰か助けてください
0028デフォルトの名無しさん
05/02/21 14:44:56ヒント
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
あとはお好きなように。
0029デフォルトの名無しさん
05/02/21 14:46:240030デフォルトの名無しさん
05/02/21 16:56:550031デフォルトの名無しさん
05/02/21 18:01:39ありがとうございます。
おちついて調べてみたら、DWORDではなくWORDの乗算でした…
WORDならなんとかなりそうです。
0032デフォルトの名無しさん
05/03/16 05:30:09再upして頂く事は出来ませんでしょうか・・・
0033デフォルトの名無しさん
2005/07/07(木) 12:01:110034デフォルトの名無しさん
2005/07/08(金) 22:12:420035デフォルトの名無しさん
2005/07/08(金) 23:23:13テキトーにベンチマークプログラム書いて調べるとかｗ
4kB境界に合わせればほぼ確実に最適だと思う
0036デフォルトの名無しさん
2005/07/11(月) 14:27:39俺はIntelCPUなのでMMXやSSEしか使ったことがないが。
0037デフォルトの名無しさん
2005/07/15(金) 17:42:50ノ
pfacc系がとっても便利で気に入っている。
0038デフォルトの名無しさん
2005/07/21(木) 16:25:52上位と下位の加算か！
いいなあ。MMXやSSEでは使えないもんな。
SSE3には入ったみたいだけど。
0039デフォルトの名無しさん
2005/07/21(木) 17:57:27新しいコアのAthlon買うかねぇ。
SSEで内積やる時に各積の加算ってどうやってる？
面倒なんでインラインから抜けて普通に書いちゃってるんだけど。
0040デフォルトの名無しさん
2005/07/25(月) 19:10:24内積やってないけど、抜けたらせっかくのインラインが遅くならない？
俺ならシャッフルして２つ同時に足すかな。
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やって同じようにもう１回足せば出るかな。
面倒なのでここまで。すまぬ。
0041デフォルトの名無しさん
2005/07/25(月) 19:49:30movaps xmm2, xmm0
shufps xmm0, xmm2, hoge
addps xmm0, xmm2
これでOKか？試してないけど。
xmm0=(?,e+f+g+h,?,a+b+c+d) となるはず。
0042デフォルトの名無しさん
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; 下半分だけ取り出す。
0043デフォルトの名無しさん
2005/07/26(火) 12:50:37簡単なコード書いて速さの測定でもしてみるか。
0044デフォルトの名無しさん
2005/07/26(火) 14:10:132回連続のシャッフルないしアンパックをどうにかしてばらせないかなぁ
0045デフォルトの名無しさん
2005/07/27(水) 16:10:13mulps 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。何者だよっていう簡単さだな。
内積を、どう利用するかによって、移動命令で欲しい形式に落とすのも腕の見せ所。
0046デフォルトの名無しさん
2005/07/28(木) 18:54:46やっぱ要素間演算がないのは皆不満だったらしいね。
便利だけど自分の環境じゃ試せないのが痛いなぁ。
にしてもSSE3は便利なのはいいけどホント遅そうだ。
0047デフォルトの名無しさん
2005/07/29(金) 10:06:21Prescottはもう死にかけのアーキだし、K8なら速いし。
YonahのSSE3も速くなってると思う。
0048デフォルトの名無しさん
2005/07/31(日) 10:18:47この夏に新しい石のAthlonでも買って試してみるか。
まあPrescottでも流れれば速いのかな？
0049デフォルトの名無しさん
2005/08/01(月) 10:26:31うん、流れたときの速さは比べるものがないほどだと思う。
リアル128bitでバラバラに動くSIMDは強力。
レジスタ間movapsのレイテンシが6なことなど気にならない。
0050デフォルトの名無しさん
2005/08/14(日) 19:40:00SanDiegoもVeniceもさようなら〜orz
0051デフォルトの名無しさん
2005/08/25(木) 14:50:350052デフォルトの名無しさん
2005/08/25(木) 15:05:090053デフォルトの名無しさん
2005/08/27(土) 19:01:02bochsという強力なエミュなら、どんな環境でもSSE,SSE2,SSE3,x64,3dnowなど
なんでもエミュレートできるぞ。
どんな環境でもって言うのはPowerPCでもSPARCでもってこと。
0054デフォルトの名無しさん
2005/10/01(土) 21:24:260055デフォルトの名無しさん
2005/10/03(月) 14:38:06今までにSIMDで何を作ったことがあるか書いていくか？
0056デフォルトの名無しさん
2005/10/03(月) 16:24:490057デフォルトの名無しさん
2005/10/03(月) 18:12:160058名無し募集中。。。
2005/10/03(月) 18:45:09[word data100][word data101][word data102]・・・
こんなふうに並列演算したいデータがメモリ上に並んでいない場合
data1とdata3とdata100とdata102を並列計算したい時って
pinsrw でデータを集める以外にうまいやり方ってない？
movq でメモリから64bit取り出してパックしたほうが早いかな？
0059デフォルトの名無しさん
2005/10/03(月) 19:58:56すべてはそこからだ。
0060名無し募集中。。。
2005/10/03(月) 20:13:33[R][G][R][G]
[G][B][G][B] という配列(今回扱うのは1画素12bit)
0061デフォルトの名無しさん
2005/10/04(火) 10:54:24MMXレジスタだけじゃなくてSSEレジスタも使えるようになったってだけ？
しかも64ビットまでしか使えないって罠で利点はemmsなしでOKってだけ？
ここからチラシの裏
FirefoxのビルドしたらAthlonノートでやけどしたｗ
しかし最適化といってもどこから手を付けていいのやら。
テテさんとかどうやってんだろうね。
0062デフォルトの名無しさん
2005/10/05(水) 09:08:10SSE整数は128bit使ってるよ。
ただ、現状ではMMXが速いことが多いけど。
将来的には演算器が強化されてSSEの方が速くなるだろうし、
x64ではレジスタが倍の16本に増えるというメリットもある。
0063デフォルトの名無しさん
2005/10/05(水) 19:29:280064デフォルトの名無しさん
2005/10/06(木) 08:58:39初代SSEとは、MMX2のことかい？
0065デフォルトの名無しさん
2005/10/15(土) 08:03:380066デフォルトの名無しさん
2005/10/15(土) 14:31:230067デフォルトの名無しさん
2005/10/16(日) 15:41:44単純に演算器の数を倍にするの。
0068デフォルトの名無しさん
2005/10/22(土) 10:59:10チラシの裏
MMXのmovqを使ってメモリコピーを高速化してるよ。
SSE系は使ってないみたい。
0069デフォルトの名無しさん
2005/10/22(土) 14:11:26Pen4だけは128bitの方が速いけど、
これも幅が広いから小回り効かなくて遅いのかな。
0070デフォルトの名無しさん
2005/11/21(月) 01:03:240071デフォルトの名無しさん
2005/11/21(月) 10:15:150072デフォルトの名無しさん
2005/11/23(水) 08:58:420073デフォルトの名無しさん
2005/11/23(水) 10:03:48対応って自動ベクトルか機能のことをいってるのか？
そうならこいつがあるが
ttp://www.codeplay.com/japanese/vectorc/feat-vec.html
0074デフォルトの名無しさん
2005/12/11(日) 10:48:57盛り上がってくれることを信じつつｗｋｔｋ
0075デフォルトの名無しさん
2005/12/12(月) 01:08:17基本的な触りくらいしか出てないようなﾖｶｿ
インテルのマニュアルの方がよっぽど詳しいのではなかろうか。
0076デフォルトの名無しさん
2005/12/12(月) 22:36:34そら純正マニュアルに敵う本なんてまずないだろ……
0077デフォルトの名無しさん
2005/12/15(木) 10:37:25SSE2の日本語+絵による解説は使えそう。
0078デフォルトの名無しさん
2005/12/16(金) 04:01:41nyで
0079デフォルトの名無しさん
2006/01/02(月) 01:04:220080デフォルトの名無しさん
2006/01/05(木) 19:01:14簡単なやつでもいいので。
http://homepage1.nifty.com/herumi/adv/bbslog/bbs11.html
の498,519みたいな。
0081デフォルトの名無しさん
2006/01/15(日) 17:20:05__m128 <-> __m128dのキャストをインラインアセンブリ
使わずにできます？
倍精度の仮数部の一部を整数演算で０クリアしたいんです。
0082デフォルトの名無しさん
2006/01/15(日) 17:45:45__m128d a;
__m128i b;
b = _mm_and_si128(*(__m128i*)&a,b);
0083デフォルトの名無しさん
2006/01/15(日) 17:53:53メモリアクセスするコードが生成されないか心配。
0084デフォルトの名無しさん
2006/01/15(日) 18:27:53union {
__m128d a_d;
__m128i a_i;
}
__m128i b;
(ry
0085デフォルトの名無しさん
2006/01/15(日) 22:13:20s=_mm_cvtpd_ps(d);
d=_mm_cvtps_pd(s);
てなことを
d=_mm_and_si128(d,mask);
てな感じで済ませたかったけど、
union使って書くと遅くなったんで最適化してくれないっぽ…
入力がfloatの範囲を越えても動かしたいんだけどなぁ
0086デフォルトの名無しさん
2006/01/15(日) 22:18:250087デフォルトの名無しさん
2006/01/15(日) 23:44:17inline __m128d round(__m128d d,__m128i mask){
__asm__ __volatile__ ("pand %1,%0" : "+x"(d) : "x"(mask));
return d;
}
で少し速くなりました。
どもども。
0088デフォルトの名無しさん
2006/02/06(月) 14:49:390089デフォルトの名無しさん
2006/02/06(月) 16:32:46720*480側は普通に読むのと3byteずらして読むのをやって
掛け算で加重して・・・あ、MMXの乗算は16bitだけか。
どのくらいの速度になるだろ。
0090デフォルトの名無しさん
2006/02/06(月) 18:01:30今からbmpの構造を思い出そうとしている俺は完全に出遅れかな？
0091デフォルトの名無しさん
2006/02/06(月) 18:42:06つoffset
0092デフォルトの名無しさん
2006/02/06(月) 21:28:47つlea
0093デフォルトの名無しさん
2006/02/06(月) 22:07:42バイリニアをMMXで実装するだけ。
しかも480で縦ライン固定なら１時間くらいで出来るんじゃね？
0094デフォルトの名無しさん
2006/02/07(火) 10:21:03void 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版の出力は全て一致していた。
0095デフォルトの名無しさん
2006/02/07(火) 10:21:34lp0:
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でバイリニアてのはどうやるの？
0096デフォルトの名無しさん
2006/02/09(木) 09:45:01変数の中身へのポインタを取得するとアセンブリでは
lea eax,[esp-12]
のようになるから、movは使えないのだね。
int *a;ならmov eax,aできても、int a[4];だとmov eax,aで氏んだからな。
あのときはけっこう悩んだ。
0097デフォルトの名無しさん
2006/02/11(土) 09:08:17たとえば、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ブロック中には分岐はかけず、
ループも固定回数ループだけ。
どう？この妄想言語。
0098デフォルトの名無しさん
2006/02/11(土) 11:51:13それはいいとして、組み込み関数と演算子オーバーロードでよくない？
ただ、俺もそういう言語は欲しいと思っていた。
せっかくCPUに色々な命令があるんだから、命令が見える言語がいいよね。
そういう意味じゃCのシフト演算子とかナイスと思った。
0099デフォルトの名無しさん
2006/02/11(土) 19:29:54最終段で機械任せの最適化するなら、
そのままCでも構わないと思うけど。
0100デフォルトの名無しさん
2006/02/17(金) 21:01:05実装しようとしているのですが、思っていたよりも早くならずに難渋しています。
適当なやり方しているのは自覚しているのですが、同じく適当にＣで書いたルーチン
と、リリース版の最適化コミで速度変わらずってのはかなり凹みました。
どこかもっと最適化する場所があるのでしょうか？ ご存じの方ご教授願います。
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;
}
}
}
0101デフォルトの名無しさん
2006/02/17(金) 21:20:54使用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;
即興で作って試してないけど、こんなのでどうでしょ。
0102100
2006/02/17(金) 21:25:43>使用CPUは何？
書き忘れていました。CPUはPen4ですが、諸事情(VC6sp6開発)のため
MMXまでの制限になってます。
0103デフォルトの名無しさん
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が遅いからな。
0104デフォルトの名無しさん
2006/02/17(金) 22:15:400105デフォルトの名無しさん
2006/02/17(金) 22:30:45ttp://msdn.microsoft.com/visualc/vctoolkit2003/
0106デフォルトの名無しさん
2006/02/17(金) 23:09:570107100
2006/02/18(土) 10:01:35>>103
>後でnasmでも使ってみてください。
個人で試す分には思いっきりやってみたいところなのですが、
そこまですると引き継ぎが出来なくなって（略）な事になるので……
0108デフォルトの名無しさん
2006/02/18(土) 18:14:080109デフォルトの名無しさん
2006/02/18(土) 20:32:13ivec.h
fvec.h
dvec.h
をインクルード
0110デフォルトの名無しさん
2006/02/18(土) 23:38:01そういったクラスライブラリじゃなくて言語の拡張仕様に
埋め込んで欲しいって言ってんじゃないの？
0111デフォルトの名無しさん
2006/02/19(日) 00:03:31そんなことは言ってない
0112デフォルトの名無しさん
2006/02/19(日) 00:40:17multivalue< 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++へのコンバータでいいからさ。
0113・∀・）っ-○●◎- ◆Pu/ODYSSEY
2006/02/19(日) 02:01:05F32vec4 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));
0114・∀・）っ[http://www.coins-project.org/] ◆Pu/ODYSSEY
2006/02/19(日) 02:15:470115デフォルトの名無しさん
2006/02/19(日) 02:28:09・データ読み込み
・同アドレスにデータ書き込み
を行った場合、このデータ書き込みの際にmovntiとか使っても全然
早くならないんだけれども、これって対象アドレスに既にデータが入っている
場合、非テンポラル指定はキャッシュ汚染を防ぐためにやるんだから
キャッシュに入っていては意味が無いって事だよな？
0116デフォルトの名無しさん
2006/02/20(月) 13:33:53vcpp5解凍してml.*をコピーすればSSE2命令くらいまで使えたはず、
ってか俺はVC6SP6で使えてる。
もしくは、VC6インスコ→SP5→vcpp5→SP6でもいけた希ガス。
0117デフォルトの名無しさん
2006/02/20(月) 13:37:05論破されてやがるざまぁｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
0118デフォルトの名無しさん
2006/02/20(月) 14:09:47意味ないね。その場合ってロードをプリフェッチすれば
ピーク性能を引き出せるのかな？
0119100
2006/02/20(月) 20:02:21>101 殿のアドバイスを元に、改良版を作成して実験したところ、試行１回あたり
0.01msほど早くなりました（笑
＃640×480サイズ、1万回試行の平均。
MMXレジスタ８本全部使って１６ピクセル分１ループで処理するサンプルも実験
してみましたが（ループ回数削減を企図）、やはりほとんど変わりませんでした。
処理画像サイズを大きくしても、0.1msほどの違いしか出ないことを考えると、
「メモリ速度がネックになる」という>103、>104 殿の指摘にハマっていそうです。
他の作業指示が飛んできたので、現状でこれ以上の追求は出来なくなって
しまいましたが、メモリ速度や最適化の意義などについて深く考える良い機会に
なりました。折を見てまたいろいろ試してみたいと思います。
>116 殿
かなりそれは魅力的な手段ですが……引き継いだ後に環境再構築できる人間が（ｒｙ
012097
2006/02/21(火) 12:50:45いや言っている。
どちらかというと言語の標準仕様であってもらいたいね。
件の記法が正式採用されたら最適化エンジンは楽チンにベクトル化出来るし
SIMD使えないときでも依存関係の解析が楽になる。
処理が長いときはスレッド化だってイケる。
どれかの言語がこんな感じの機能を実装したら(あるいは約束したら)、
明日にでもその言語に乗り換えるね。
0121デフォルトの名無しさん
2006/02/21(火) 13:18:370.01msか。思ったより効かないな。
prefetchの代替ならmovを使うという手もあるが、この処理の要はmovntqだからな。
後で俺も試してみよう。
0122デフォルトの名無しさん
2006/02/21(火) 13:58:35効果てきめんな人居る？
別のCPUでうまいこと使って爆発的に速くなった経験はあるから、
ちゃんとはまれば効果があることは理解してるんだけど失敗続き…
VTuneとかでメモリアクセスのパターンとか見れば何とかなるか
と評価版を試してみたけど結局うまく行ってない。残念無念
0123デフォルトの名無しさん
2006/02/21(火) 14:03:39キャッシュラインは64byteないとほとんど効かないと思う。
0124デフォルトの名無しさん
2006/02/21(火) 14:23:50PGIの嘘っぽい最適化結果によると
ttp://www.softek.co.jp/SPG/Pgi/TIPS/amd64_em64t.html
だそうな。
0125デフォルトの名無しさん
2006/02/21(火) 16:37:15intelでもオレのケースではまったく効果なかったし（性能クリ
ティカルな部分は全部SIMD化している）、iccで最適化
かけた性能はオレのasmコードにぜんぜんのよばねーし。
0126デフォルトの名無しさん
2006/02/21(火) 17:05:03ソフトウェアプリフェッチの効果薄いのかもね。
メモリアクセスレイテンシ対策にはiccの
#pragma unroll(?)
は段数変えてみると結構効く場合があるね。
0127デフォルトの名無しさん
2006/02/21(火) 21:34:42別に計算、マスクしてから元のレジスタに加算とか、ステップが余計にかかって
しょうがない。
二次元DCTをFCTで書いたものと、まともにDCTしたものを比べたら、普通の
DCTのほうが幾らか速かったorz
腕が悪い可能性も大だが。
V-Tuneなんつうブルジョアなものは持ってないので、visioでダイヤグラムを
書いて、ペナルティを極力食らわないように組替えてからソースを書きました
とさ。手動最適化マンセー。
0128デフォルトの名無しさん
2006/02/21(火) 22:24:190129デフォルトの名無しさん
2006/02/22(水) 10:48:20お客は5、6年位前のスペックでも結構平気で使ってるからな。
SSE3対応の石にせよ、この国ではすでにデスクトップ市場を越えたノート市場で
最近出始めたばかりで、使えないことのほうが多い。
Intel Macあたりが対象なら、あんま考えなくていいけど。
まぁMMXまでは完全に存在を前提に書いたりするがな。
MMX非対応の石はどのみち絶対性能が不足するので切り捨ててる。
つか、SSE2/3って、本当にごく特殊な演算を除けば、MMXの有無程にはパフォーマンスに影響ないんだよな。
0130デフォルトの名無しさん
2006/02/22(水) 11:00:13＞SSE2/3って、本当にごく特殊な演算を除けば、MMXの有無程にはパフォーマンスに影響ない
同意
ＭＭＸでの高性能化に比べてＳＳＥ以降はかなりがっかりなのだ。
ＭＭＸと同程度に努力したが同じ率での高速化はしなかったよ。
掛け算に無符号が付いたMMX2は最初からやっとけと
0131デフォルトの名無しさん
2006/02/22(水) 11:50:23最適なルーチンを走らせるというのが普通か。
0132デフォルトの名無しさん
2006/02/22(水) 12:27:12SSEはコンパイラに丸投げ
そんなシナリオを想定してある感じ
0133デフォルトの名無しさん
2006/02/22(水) 13:04:07x86の浮動小数点命令は使いにくいからSSEでの最適化は欠かせないなぁ。
3D Now! の話題が全く無いのは互換性割り切るほど速度出ないからか。
>129
SSE2/3の命令ってmov系と高精度演算命令系以外になんかあんの？
0134デフォルトの名無しさん
2006/02/22(水) 13:47:08MendocinoコアCeleronの載ったマシンとか現役で使ってる人が結構いるから
SSEも迂闊に使えないｗｗｗ
もっとも、うちは基本的に整数演算か倍精度実数演算しか滅多に使わない
人なんで、パックド単精度ってそんなに有り難味が無い。
pmovmskbとかmaskmovqとかもそれなりに便利だけど、わざわざ別々の最適化コード
書いてディスパッチするだけの労力に見合った効果も得にくいんだよな。
> SSE2/3
ホラ、あるじゃないか。MMX/3DNOW!を無理矢理二つくっ付けた様な糞命令群が。
このへんは演算ユニットが128bit化するときのための布石と考えてるが。
てか、64bitになるとMMXもそろそろ要らなくなりそうな雰囲気。
飽和演算とか撹拌処理とかやらなくていいなら汎用ALU使ったほうが速度が出るんだよね。
0135デフォルトの名無しさん
2006/02/22(水) 15:08:51640*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という結論になる。
0136デフォルトの名無しさん
2006/02/22(水) 15:29:56＞Mendocinoコア
めんどっちーの、と読むのか？
0137デフォルトの名無しさん
2006/02/22(水) 19:52:500138デフォルトの名無しさん
2006/02/23(木) 20:53:08アドバイスありがとうございます。
実験してみましたところ、おおよそ速度が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;
}}
}
0139デフォルトの名無しさん
2006/02/23(木) 21:14:550140・∀・）っ-○●◎- ◆Pu/ODYSSEY
2006/02/23(木) 21:38:09今はへるみ氏あたりが初代AthlonでサポートされたEnhanced 3DNOW!とで
共通で使える拡張命令（要するにSSEのMMX整数演算拡張）を総称して
そう言ってるような。
案外午後な人書き込んでるかもしれんね。
0141デフォルトの名無しさん
2006/02/23(木) 22:22:04一度に演算できるデータは少なくなる。
16bit整数でバタフライ演算すれば同時に処理できるデータは8点に増えるが、
同じレジスタ内に0以上1未満の整数値(シフト処理したもの)と1以上の
整数値が混在する場合は、バタフライ演算で同時に演算できない。
該当するデータはいったん別のレジスタで処理しなければ成らないため
ステップ数が増える。
精度を保って処理したいなら単精度小数点などで処理するが、リアルタイム
性能を追求するなら整数で処理するしかないかな、と。
まぁ、どうせインテルは本当に便利な命令は用意しない方針のようなので。
0142デフォルトの名無しさん
2006/02/23(木) 22:53:27ソフトウェアパイプライニングとか
手でやってる？コンパイラまかせ？
x64だとレジスタ数も違うし、そもそも
CPUごとにレイテンシ等変わって面倒だよね？
0143・∀・）っ-○●◎- ◆Pu/ODYSSEY
2006/02/23(木) 23:01:45PenMは全般にレイテンシ短いから程々でヨシ
NetBurstはパイプラインの長さの分OoOが強力だからあんまり何も考えないほうが
かえって良かったりするかも。
という風に把握している
0144デフォルトの名無しさん
2006/02/24(金) 08:45:35JIT付きの実行環境が欲しくなるなあ
0145・∀・）っ-○●◎- ◆Pu/ODYSSEY
2006/02/24(金) 21:27:240146デフォルトの名無しさん
2006/02/26(日) 19:46:12MMXを機能拡張したCPUをAMDが出したとき、インテルが「MMXはうちの登録商標
だから使うな」とAMDを訴え、AMDは「マルチメディアエクステンションなんて
平凡な名称だ」と反発していたような。
違ったらｽﾏｿ
0147デフォルトの名無しさん
2006/02/27(月) 06:55:480148デフォルトの名無しさん
2006/02/27(月) 14:28:57思っていたが、何か違うみたいね。ぐぐっても少ないし。
0149・∀・）っ-○●◎- ◆Pu/ODYSSEY
2006/02/27(月) 21:14:27古いソースを漁ってみるに、MMX2はSSEがまだ世に出る前の仮称。
SSE自体もKatmaiが出始めた頃はiSSE（インターネットストリーミングSIMD拡張）と
呼んでたり。
AMDその他CPUメーカーがMMXを使うこと自体にIntelが提訴したのでは。
Intel側の主張は棄却で和解したはず。
0150・∀・）っ-○●◎- ◆Pu/ODYSSEY
2006/02/27(月) 22:06:26サポートされた拡張命令セットが同一であっても、あくまでカタログ上は
Enhanced 3DNOW!、3DNOW! Professionalなどと称し、SSE、SSE2という商標名は
使ってませんな。
0151デフォルトの名無しさん
2006/02/27(月) 22:25:550152・∀・）っ-○●◎- ◆Pu/ODYSSEY
2006/02/27(月) 22:34:40拡張命令のサポートで、AMD独自の拡張命令の追加は無い
やっぱり商標権のトラブル回避の為でしょうな
0153デフォルトの名無しさん
2006/04/25(火) 20:19:340154デフォルトの名無しさん
2006/04/25(火) 23:21:44中から、特定のhex列を見つけたいと思ったらアルゴリズムは
別の領域として高速化するのにSSEとかは使えそう？
もし使えそうだったら簡単なサンプル示していただけないでしょうか
0155デフォルトの名無しさん
2006/04/25(火) 23:27:01普通にCで書いてもMMX使っても大差ないような気がする。
巨大データ（and 古いCPU）ならむしろ prefetch の有無で変わってくる。
0156デフォルトの名無しさん
2006/04/25(火) 23:32:10想定しています。データは1データあたり1000バイト程度それが秒間900MB/sec
転送されてきますそれをリアルﾀｲﾑで処理しないといけません。そうするとCで
書いても大差ないですか。
0157デフォルトの名無しさん
2006/04/26(水) 13:15:35その程度のサンプルも書けないレベルなら諦めろ。
結局メンテナンス出来ずに回りに迷惑かけるだけだ。
>156みたいな用途ならおとなしくCで書いとけ。
0158デフォルトの名無しさん
2006/04/26(水) 19:48:300159デフォルトの名無しさん
2006/04/28(金) 00:41:23汎用レジスタで最初の4byte一致したら続きを調べるってすれば実質変わらんしなあ。
「特定のhex列」の登場頻度が高いなら別だけど。
あ、でもこれもSSEで並列にやればいいんだ。hexは1/2バイトなのも考えて。
「特定のhex列」のバイト数は？
2バイト単位くらいで比較して、4bitシフトしてまた比較。
一致するものがあったらそこを普通に調べる。
これなら数倍比較コストが減るんじゃないか。
＃まあ、メモリ帯域ネックから高速化はしないと思うよ。
あとはキャッシュラインをまたぐときに気をつけること。ここもうまくやればSSEが有効か？
ていうかCで書いて速度が足りないから>>154で質問したんじゃないよね？
普通にCで十分な速度だと思うよ。
0160デフォルトの名無しさん
2006/04/28(金) 02:39:57そんなプロジェクトで汎用性が無くメンテナンス性の悪いアセンブラを使おうってのが間違ってる。
しかも知識も無いときたら周りに迷惑かけるに決まってる。
や め と け。
0161デフォルトの名無しさん
2006/04/28(金) 02:47:220162デフォルトの名無しさん
2006/04/28(金) 06:53:080163デフォルトの名無しさん
2006/04/28(金) 07:43:02このスレ的にはアセンブラでSIMDを使い無駄な最適化をするべきじゃないか？
0164デフォルトの名無しさん
2006/04/28(金) 10:14:38ｗｗｗ
なんかわかるｗ
0165デフォルトの名無しさん
2006/05/01(月) 01:01:510166デフォルトの名無しさん
2006/05/02(火) 01:27:50もう少し修行してきます
0167デフォルトの名無しさん
2006/05/02(火) 19:01:46いたか。いつでもいいので修行したら報告ヨロ。
0168デフォルトの名無しさん
2006/05/03(水) 10:49:45gccだと一択なのかな？
0169デフォルトの名無しさん
2006/05/03(水) 20:55:170170デフォルトの名無しさん
2006/05/03(水) 21:29:210171デフォルトの名無しさん
2006/05/05(金) 19:42:06結局メモリ帯域で頭打ちになるっしょ
0172・∀・）っ-○◎● ◆toBASh....
2006/05/05(金) 19:52:44http://developer.apple.com/hardwaredrivers/ve/
0173デフォルトの名無しさん
2006/05/05(金) 21:00:210174デフォルトの名無しさん
2006/05/19(金) 01:02:05以下のようなクラスを用意して、一度に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;
};
};
// ...
};
0175・∀・）っ-○◎● ◆toBASh....
2006/05/19(金) 01:26:16__m128じゃなくて__m128i使いなよ。ただしSSEじゃなくてSSE「2」ね。
SSEまでなら単精度浮動小数×４までしかサポートされない。
C++ラッパー１から作るくらいなら最初から用意してある物使ったほうがいい。
#include <dvec.h>
VC++かICCならこれで Iu8Vec16 っていうクラスが使えるはず
0176デフォルトの名無しさん
2006/05/19(金) 01:32:07RedhatEL4 gccで作成しています。ｇｃｃだとdvec.hが使えないと
聞いて悩んでいました。
0177・∀・）っ-○◎● ◆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で各上位ビットを汎用レジスタに転送して再度比較するのが
スマートかな。
0178デフォルトの名無しさん
2006/05/19(金) 02:12:04うーんサンプルコードってあるのでしょうか？
0179デフォルトの名無しさん
2006/06/13(火) 01:35:19どっちもxmmレジスタ同士のandを取るだけのような……
0180デフォルトの名無しさん
2006/06/13(火) 02:35:31動作も同じだと思う。
ニーモニックが2つあるのはいいとして、
なぜマシン語コードも違うのか謎ですな。
0181デフォルトの名無しさん
2006/06/13(火) 02:52:35建前上、パックド単精度実数が操作対象。
ANDPDは、SSE2をカバーしていないと使えない。
建前上、パックド倍精度実数が操作対象。
0182デフォルトの名無しさん
2006/07/05(水) 10:18:10プログラムは作れないものでしょうか。
0183デフォルトの名無しさん
2006/07/05(水) 10:35:410184デフォルトの名無しさん
2006/07/05(水) 12:47:46やってみるとそうでもないもんだよ。
0185デフォルトの名無しさん
2006/07/05(水) 13:03:54つか、x64やIL向けだとインラインアセンブラ無効だからそれ使うしかない
0186デフォルトの名無しさん
2006/07/05(水) 13:08:38結構便利なんだよな
0187デフォルトの名無しさん
2006/07/05(水) 14:00:17前後でも最適化が一切行われないよね。
0188デフォルトの名無しさん
2006/07/05(水) 18:17:51される。
まさかとは思うがコンパイルオプションミスったり、
デバッグモードで確認なんかしてないよな？
0189デフォルトの名無しさん
2006/07/05(水) 19:45:11簡単に確認できるのに確認しない漏れって・・・orz
0190デフォルトの名無しさん
2006/07/06(木) 11:38:10inlineとか__inlineキーワードはむしろグローバルな最適化（高速化）のためのもの
0191デフォルトの名無しさん
2006/07/06(木) 15:49:58漏れもそう思ってだんだけど、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回のループに展開されますた。
0192デフォルトの名無しさん
2006/07/06(木) 17:24:380193デフォルトの名無しさん
2006/07/06(木) 17:47:13アセンブラで記述しなきゃいけない部分は何らかの理由があって
わざわざそういうコードにしてるものもあるのに、
それを別の命令に置き換えられたらブチギレですよ。
0194デフォルトの名無しさん
2006/07/06(木) 19:04:49関数の前半と後半を__asm{nop}でぶった切ったら最適かもぶった切られたよ。
0195デフォルトの名無しさん
2006/07/07(金) 11:33:32後半が素直な100回ループになっちゃったってこと？
0196デフォルトの名無しさん
2006/07/07(金) 11:38:45コンパイラによって結果は異なってあたりまえだろ。
漏れのとこの VC++ 2005 では __asm{ nop}; 入れてもnpad 1 が間に入るだけで
全く変らないコードが生成された。
0197デフォルトの名無しさん
2006/07/07(金) 12:03:47__asmをまたいだ最適化はしない、ということかな？
0198196
2006/07/07(金) 13:16:40そういうことじゃないんじゃないか？漏れのトコでは前述の通り npad 1 の有無だけ。
そもそも__asm 入れなくても「またいだ最適化」みたいなものは無かったし。
単に >>194 の使ってるコンパイラが__asm 入れると最適化しなくなる旧いVCとか
なんじゃまるまいか？
0199デフォルトの名無しさん
2006/07/07(金) 13:28:48なるほど。
0200デフォルトの名無しさん
2006/07/07(金) 18:35:27forループではないんだが、FPUレジスタの使い方に無駄が出た。
ある関数の最初の方で別のライブラリの関数にfloatの変数渡して、
いくつか別の浮動小数点の処理した後で変更なしで再びその変数を使うんだが、
この間にnop入れるだけでもう一回メモリから読み出すようになった。
>>196
すまんがforループなんて単純な部分ではなく、しかもVC8での話なんだ。
0201デフォルトの名無しさん
2006/07/07(金) 20:27:10しかも複雑な部分なら尚の事。
0202200
2006/07/07(金) 21:27:22アンカーがないから俺へのレスってことでOKなのか？
おれは__asmブロックで最適化が阻害されるのは当然だと主張してるのであって
最適化されねーぞなんでだヴォケと言ってるわけじゃないんだが。
0203デフォルトの名無しさん
2006/07/07(金) 21:36:42その話の真偽はおいといて、
>>191>>194 を読んでそんな風に理解できるかというと、
それはちょっと無理じゃないか。
漏れは 191 の関数の前半と後半という風に読んじゃたよ。
想像力が無いからかもしれないけど。
0204デフォルトの名無しさん
2006/07/07(金) 22:01:59当たり前の結果にムキになってっから、何か不満でもあるのかと思った。
0205デフォルトの名無しさん
2006/07/08(土) 09:25:11古い話だけど今のICCには_mm_cast*という命令があってこれでキャストできることに気がついた。
VCLにはない。GCCは普通に(__m128)とかでキャストできる。
0206・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6
2006/07/08(土) 17:53:16AMDが来年予定してる新リビジョン（K8L）でXMMレジスタの下位・上位QWORDと汎用レジスタ命令の値を
相互に交換する追加されるみたいだけど、これってIntelも採用するかのう？
別のニーモニック割り当てるんだろうな。
0207・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6
2006/07/08(土) 17:54:25○汎用レジスタ
0208182
2006/07/13(木) 16:03:543DnowやSSEを使えるようになるのを目標にして、機械語を勉強するのに
良い参考書がありましたら、教えていただけませんか。
NWSAというのを見つけて、解説を読んでいますが未知の言葉が山盛りです。
0209デフォルトの名無しさん
2006/07/13(木) 16:14:38x86アセンブラ入門
アセンブラ画像処理プログラミング
載ってない本
独習アセンブラ
アセンブリ言語の教科書
糞級言語プログラマのためのアセンブラ入門
0210デフォルトの名無しさん
2006/07/13(木) 16:19:02ftp://download.intel.co.jp/jp/developer/jpdoc/24547103_j.pdf
ttp://homepage1.nifty.com/herumi/adv.html
0211デフォルトの名無しさん
2006/07/13(木) 23:48:16いまどきのアセンブリ言語
いまどきのアセンブリ言語の教科書
0212デフォルトの名無しさん
2006/07/14(金) 00:33:58を読んでSSEが難しいようだったら多分それを触る前に覚えることがまだまだある。
0213デフォルトの名無しさん
2006/07/14(金) 06:06:27そうかな。俺はよくわかんないうちから
MMXでガンガンコード作って覚えたけど。
あのマニュアルを読むのは、ある程度
SSEを使えるようになってからでないときついだろう。
0214デフォルトの名無しさん
2006/07/14(金) 10:07:33212ではないが、あれ読めないって事は結局x86の構造理解出来てないって事だと思うが。
通常命令での効率的な組み方を勉強する方が先じゃね？
0215デフォルトの名無しさん
2006/07/15(土) 06:49:150216デフォルトの名無しさん
2006/07/21(金) 11:50:310217デフォルトの名無しさん
2006/07/27(木) 15:42:54デバッガにかけながら読むとテラわかりやすいお。
0218デフォルトの名無しさん
2006/07/28(金) 21:22:59ダウンロードできるとこ知らない？
www.intel.com とか探しても全然見当たらない。
まだ非公開かな？
それにしてはベンチマークが対応しているのが不思議．．．。
0219デフォルトの名無しさん
2006/07/28(金) 21:39:100220デフォルトの名無しさん
2006/07/28(金) 21:47:56TMPGEncだかも対応したよな。
開発者向けには公開してあるってことか？
0221デフォルトの名無しさん
2006/07/28(金) 22:00:380222デフォルトの名無しさん
2006/07/28(金) 22:58:59TMPGEncはベンチとしても一般的だからな。
0223デフォルトの名無しさん
2006/08/04(金) 10:38:00団子のページ引用率高すぎ
0224デフォルトの名無しさん
2006/08/14(月) 07:45:54MMXやSSE、3DNOWに対応させるというのは可能ですか。
0225デフォルトの名無しさん
2006/08/14(月) 09:09:050226デフォルトの名無しさん
2006/08/14(月) 13:22:18emmsもｄろうけど、SIMDはデータをレジスタに乗っ
けるところが結構食うからね。
0227・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6
2006/08/14(月) 23:22:34SSE2の整数命令ってSSE2非対応CPUはMMXの相当命令として解釈されるから
うまく組めばパスの分岐必要なし
0228デフォルトの名無しさん
2006/08/29(火) 01:31:223年ぐらい前に書くとアライメント指定しても4byteでまとめられたりして
まともに使えなかった記憶があるんだけど今はどうなんですかね？
0229デフォルトの名無しさん
2006/08/29(火) 21:46:080230デフォルトの名無しさん
2006/09/14(木) 14:49:48>>226
SIMDのデータ転送のレイテンシが半端なくでかいのはPen4くらい
AthlonやPenM, Core系は整数と大して変わらない
0231デフォルトの名無しさん
2006/09/14(木) 15:00:090232デフォルトの名無しさん
2006/09/14(木) 15:57:07SIMDとSIMMを間違えるのも雑音だけ。
0233デフォルトの名無しさん
2006/09/14(木) 16:57:410234・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6
2006/09/14(木) 23:04:40SSE4って命令部3バイトだからあんまり使えない気が。
XMMレジスタでREXプリフィックス付けたら命令長最低6バイトになる
>>228
ヒープ上に16バイトくらい多めに確保して、返ってきたアドレスに15足して~15でマスク。
Windowsだと、SSEがまともに使えるようになったのがVC7からだと記憶してる。
0235デフォルトの名無しさん
2006/09/27(水) 11:49:460236・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6
2006/09/27(水) 22:11:16正式名称はSupplimental-SSE3(SSSE3)になったらしい。
あと、まるも製作所の中の人が色々と考察してた
0237デフォルトの名無しさん
2006/09/27(水) 22:28:460238デフォルトの名無しさん
2006/09/28(木) 20:11:090239デフォルトの名無しさん
2006/09/28(木) 21:16:130240デフォルトの名無しさん
2006/09/28(木) 21:21:57ただ、次に命令を追加するときに「SSE4」とされるとややこしいな。
0241デフォルトの名無しさん
2006/09/28(木) 21:24:320242デフォルトの名無しさん
2006/09/28(木) 21:31:380243デフォルトの名無しさん
2006/09/29(金) 10:58:550244デフォルトの名無しさん
2006/10/05(木) 01:38:11SSE3+SSSE3を総称した呼び名はできるのかな。
命令が普及した後で、SSE3と言ったときに、
SSSE3が含まれるかどうかが不明確になりそう。
0245デフォルトの名無しさん
2006/10/05(木) 01:39:39ﾌﾟﾚｽｺは要らない子
0246デフォルトの名無しさん
2006/10/05(木) 01:50:35あれ、Cyrixの系統のやつも載せてたっけ。
今度はSSE3（総称）の中のSSSE3に含まれない命令の
呼び名がないと不便になるなあ。
0247デフォルトの名無しさん
2006/10/05(木) 02:10:260248デフォルトの名無しさん
2006/10/05(木) 02:18:440249デフォルトの名無しさん
2006/10/05(木) 02:23:100250デフォルトの名無しさん
2006/10/05(木) 02:24:490251・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6
2006/10/05(木) 02:50:45PenrynもPだから困る。
0252デフォルトの名無しさん
2006/10/05(木) 14:27:03なるほど。
Penryn New Instructionsの略称はどうなるのかね。
まあSSE4と呼べばいいだろう。
ところでこのスレも2年以上になるのだが、
今こういうスレを立てるとしたら、3D Now!の名前は入るだろうか。
まあ、2004年と言えばとっくに3D Now!は下火だったが。
0253デフォルトの名無しさん
2006/10/16(月) 18:03:24この2年前のソースが見てみたい
0254デフォルトの名無しさん
2006/10/16(月) 18:07:15少し遅れて来て>>25が取れなかったことを
昨日のように思い出す。
0255デフォルトの名無しさん
2006/10/16(月) 21:01:22２年前のソースをそのまま晒す恥知らずの俺サイコー
0256デフォルトの名無しさん
2006/10/16(月) 21:31:14こ、更新日時が2004/12/12 10:07！！
俺は特に見たかったわけではないが、>>255はある意味で神。
よかったな、>>32！
0257デフォルトの名無しさん
2006/10/16(月) 22:36:18すげぇｗ
0258デフォルトの名無しさん
2006/11/21(火) 14:43:13Core2やK8LでSSE命令のレイテンシは据え置きでスループットが倍になること、
これらによってSSEの使い方がかなり変わってくるだろう。
0259デフォルトの名無しさん
2006/11/29(水) 02:30:01トイプログラムで
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化を抜いてしまって
驚いた。よほど性能が必要なケース以外は下手に拡張命令使うより
コンパイラお任せで十二分にいい仕事してくれるのな。
自分は拡張命令覚えるよりコンパイラオプション覚えたほうがいい
レベルなのだと痛感しますた・・・
0260デフォルトの名無しさん
2006/11/29(水) 03:09:59どんなの？
SIMD化というのはインラインアセンブラ？
コンパイラに頼るなら組み込み関数という手も。
インラインアセンブラをまたいでは最適化が効かない。
最近はCPUが賢いというのも
コンパイラ有利な要因かも。
0261デフォルトの名無しさん
2006/11/29(水) 03:44:25SIMDで最適化するならデータの配置も最適化しないと意味無いぽ。
てかコンパイラ、サンプルコード、計測方法、コアの情報も無く比だけ提示されてもな、って感じ。
0262デフォルトの名無しさん
2006/11/29(水) 16:58:12セオリーとかあるの？
0263デフォルトの名無しさん
2006/11/29(水) 17:10:130264デフォルトの名無しさん
2006/11/29(水) 21:27:32書いてくれないと話が進まない。
0265デフォルトの名無しさん
2006/11/29(水) 22:58:45いや、トイプログラムって書いてる通り、1M個くらいのfloat列を
２つ乗算するだけのコード。インラインアセンブラもやったこと
なかったので、最初はインラインアセンブラで書き始めて、途中で
Intel/MS/GNUが全部同じAPIで叩かせてくれると気づいて書き直した。
これまでやったことがなかったので経験のためやってみただけなので、
あまり真剣に取らないで・・・スマソ。
でもコンパイラオプションだけで考えていた以上に性能が接近すると
知ったのは収穫でした。問題の部分に使うクロック数で非SIMDは３倍
程度はかかるかと思ってたから。
0266デフォルトの名無しさん
2006/11/29(水) 23:16:32そういうのをトイプログラムというのか。
今の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の差はそれだろう。
0267・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6
2006/11/29(水) 23:43:32x87からライトスルー命令は使えないし、やっぱりSSEまんせー
0268デフォルトの名無しさん
2006/11/29(水) 23:52:32いやそれがですね、-fprefetch-loop-arrays とかいうオプションが
あってまさにそれやってくれてたんですよ。
わざわざ拡張命令使わなくても限定的ながら自動ベクトルかとかも
してるそうで、もうコンパイラ様々というか。
0269デフォルトの名無しさん
2006/11/30(木) 00:00:04あ、それを忘れてた。
>>268
すごいなコンパイラ。
すると、インラインアセンブラを使うと最適化が効かないから
プリフェッチもしてくれないわけで、それでAがBに勝ったの？
コンパイラの吐いたプリフェッチコードキボンヌ。
0270デフォルトの名無しさん
2006/11/30(木) 04:55:32時々勘違いしてる奴がいるが、アセンブラ化すれば速くなるわけじゃない。
コンパイラで出来ないことをアセンブラで最適化するから速くなる。
MMX/SSE命令並べただけで速くなるならコンパイラだってそうするだろうよ。
0271デフォルトの名無しさん
2006/11/30(木) 05:20:08コンパイラに負けるから勉強して
SIMDを使えるように頑張るんじゃないか。
0272デフォルトの名無しさん
2006/11/30(木) 11:31:10「コンパイラの最適化で十分」とか結論付けるのは良くないよね。
0273デフォルトの名無しさん
2006/11/30(木) 20:51:08MASMだと煩雑だしプリプロセッサも無い。
組み込み関数じゃ思った通りの命令を生成しない。
0274・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6
2006/11/30(木) 21:58:25むしろx64対応のアセンブラそのものが少ないのが問題。
x64でプログラミングやるならVC++Std + PSDK + ICCが一番コストパフォーマンスいいと思う。
0275デフォルトの名無しさん
2006/11/30(木) 22:14:390276デフォルトの名無しさん
2007/01/31(水) 07:50:32モジュール分けろやボケが
0277デフォルトの名無しさん
2007/02/18(日) 10:10:27元々は正社員だったのに取引先にフリーのほうが稼げるとか騙されて派遣やってるバカのことｗ
前の会社を裏切り、結局派遣先からも騙されてる。
そもそも信頼されてるなら直接契約するか正社員にするはずだが、派遣会社経由って舐められ杉
自分でも騙され裏切れられてることは薄々わかってるから派遣問題の話が出るとウッキー！って逆ギレｗ
0278デフォルトの名無しさん
2007/03/03(土) 01:15:500279デフォルトの名無しさん
2007/03/03(土) 09:39:360280デフォルトの名無しさん
2007/03/03(土) 13:19:31光成さんって?
0281デフォルトの名無しさん
2007/03/03(土) 14:24:27でぐぐったらこんなページに出会った。
http://homepage1.nifty.com/herumi/index.html
あー、確かにこれはいいものだわ。
0282デフォルトの名無しさん
2007/03/03(土) 15:17:55XBYAK
なんじゃこりゃ、すげぇ
0283デフォルトの名無しさん
2007/03/04(日) 06:38:580284デフォルトの名無しさん
2007/03/05(月) 10:04:480285デフォルトの名無しさん
2007/03/13(火) 21:08:560286・∀・）っ-○◎●
2007/03/13(火) 22:33:09キャッシュ内で使う場合は十分意味ある。
0287デフォルトの名無しさん
2007/03/13(火) 22:56:37それに64byteとか128byteごとにキャッシュされるんだから
4byteずつコピーしようが8byteずつコピーしようが殆ど同じ。
重要なのはプリフェッチ。
L1のサイズをきちんと考慮してプリフェッチしてからmemcpy()を繰り返してもいけたりして。
0288285
2007/03/14(水) 07:59:028Byte境界なら MM7 レジスタまで使用して64Byte転送するとかやってみたんだが同じなのか。orz
0289名無し募集中。。。
2007/03/14(水) 21:13:590290デフォルトの名無しさん
2007/03/14(水) 21:42:230292・∀・）っ-○◎●
2007/03/15(木) 23:38:30キャッシュの中でうまく捏ね回すのがSIMDプログラミングの掟
0293デフォルトの名無しさん
2007/03/15(木) 23:42:260294デフォルトの名無しさん
2007/03/19(月) 13:38:50Cでテーブルを使って実装すると、テーブルへのアクセスがボトルネックとなって、
他の処理と比べて重くなってしまいます（テーブルは256x512x4で、L2にも入らない）。
そこでMMXを使ってみようと考えたのですが、
MMX命令を用いた計算方法そのものは分かるものの、
ピクセル単位の異なる二つの画像を、上手くMMXレジスタに配置する方法が分かりません。
どなたかご教授下さいませんか。
＃どちらのDIBも、横幅が8の倍数であることは保障されています。
0295デフォルトの名無しさん
2007/03/19(月) 14:25:33mov esi, DIB32
mov edi, DIB24
label:
mov mm0, esi
mov mm1, edi
--なんか処理--
add esi, 4
add edi, 3
loop label
後は最初か最後にediからの読み込みに1Byte前後して読んでシフトする処理が必要になるけど、
ループの外で処理すればいいし、テーブル参照するよりゃ速いんじゃね？
0296デフォルトの名無しさん
2007/03/20(火) 13:51:06どうもありがとうございます。
シフト処理を入れたら上手く配置できて、
二倍近く速度が出るようになりました。
0297デフォルトの名無しさん
2007/04/04(水) 17:21:13どーでもいいけど、
mov mm0, [esi]
mov mm1, [edi]
じゃね？
0298・∀・）っ-○◎●
2007/04/04(水) 21:13:550299デフォルトの名無しさん
2007/04/05(木) 02:13:450300デフォルトの名無しさん
2007/04/05(木) 02:18:010301デフォルトの名無しさん
2007/04/06(金) 04:15:490302・∀・）っ-○◎●
2007/04/06(金) 21:41:060303デフォルトの名無しさん
2007/05/26(土) 14:50:25こんな本が出てるね。初学者にはありがたいかも。
SSSE3やSSE4の解説は載ってないっぽいけど、仕方ないか・・・。
0304デフォルトの名無しさん
2007/05/26(土) 20:06:23x86アセンブラ入門＋IntelのPDFで十分。
0306デフォルトの名無しさん
2007/05/27(日) 16:53:130307・∀・）っ-○◎●
2007/05/27(日) 16:59:20ttp://www.vector.co.jp/vpack/browse/person/an001828.html
最近の作品さっぱり無いな
0308デフォルトの名無しさん
2007/05/27(日) 17:41:16代わりに何をつかえばいいの？
0309デフォルトの名無しさん
2007/05/27(日) 17:44:22不要。
最近のコンパイラは、SSEを自動的に使ってくれる。
むしろ、その最適化にやさしいコードを書いた方がよい。
手動で最適化したところで、大抵数パーセントも上がらない。
0310・∀・）っ-○◎●
2007/05/27(日) 18:29:03それもIntelで十分か。
どうせならAltiVecとかCellのSPUとかも扱って移植性とパフォーマンスを両立する方法とかね。
0311デフォルトの名無しさん
2007/05/27(日) 22:26:02Intrinsicsの解説自体はコンパイラのドキュメント読めば十分理解できるだろ。
むしろ実践的なアルゴリズムをいかにSIMDに落とし込むかという話のほうが読み応えないか？
0312デフォルトの名無しさん
2007/05/28(月) 18:33:00アセンブラでSSE使うことが不要というのは言いすぎだと思う。
まあ、結果としてこの本が不要という結論にはなるだろうが。
0313デフォルトの名無しさん
2007/05/30(水) 00:27:06移植とかは、COINSにお任せしておけば良いのでは
0314デフォルトの名無しさん
2007/05/30(水) 00:50:18誰もわからんからユーザーの俺がプログラミング。どういうこっちゃ。
0315デフォルトの名無しさん
2007/05/30(水) 00:59:530316デフォルトの名無しさん
2007/05/30(水) 01:07:04複雑な計算を瞬時に行う必要がある。
0317デフォルトの名無しさん
2007/05/31(木) 07:57:110318デフォルトの名無しさん
2007/05/31(木) 16:21:28こういう奴ってさも物事を大げさに書きたがるが、具体的な例や数字は
一つも書かないから結局何を言っているのかさっぱりわからないんだよな。
0319デフォルトの名無しさん
2007/05/31(木) 19:24:02こういう想像力の無い奴に物事を説明するのって疲れるんだよな
0320デフォルトの名無しさん
2007/05/31(木) 19:56:500321デフォルトの名無しさん
2007/05/31(木) 20:09:35デリバのプライシングとか、ALMでのVaR計算とかなんだが詳しく書いても
多分分らんと思うが。
0322デフォルトの名無しさん
2007/05/31(木) 20:29:000323デフォルトの名無しさん
2007/05/31(木) 20:31:130324デフォルトの名無しさん
2007/05/31(木) 20:37:36それは具体的な「業務内容」であって、具体的な「例」でも「数字」でも無いと思うんだ。
ここが金融系の板ならそれで通じるかもしれんが、ここはム板だから。
例えば必要精度何桁でどんな数式を秒間何万件処理する必要があるとか、そういうこと。
専門用語でお茶を濁す事は具体例では無い。
0325デフォルトの名無しさん
2007/05/31(木) 20:52:19たとえば百万件のデータから求める解を得るためにニュートン法等を数種類、複数回駆使ししたり
モンテカルロシミューレーションで数十万回の試行を行ったりといったこと。
これらはスレッド単位の高速化とマルチスレッドでの高速化により絶大な効果が得られる。
しかし高速化の技術を知るエンジニアは極めて少ないのが実情。
ってとこ。
0326デフォルトの名無しさん
2007/05/31(木) 21:51:55マルチコア、マルチCPU環境等でマルチスレッドなら同意できるが、
中途半端にSIMD使っても結局速くなった気がするだけ。
がちがちにコーディングする暇があるなら速くなるかもしれないけど
そんなことで工数がホイホイ増えるくらいなら計算機にお金使ったほうがマシ。
0327デフォルトの名無しさん
2007/05/31(木) 22:00:56高速化するために数学的手法を駆使したMCなんだが
MCがすべて単純な繰り返しと思っているレベルの頭脳では話にならん。
0328デフォルトの名無しさん
2007/05/31(木) 22:27:38お前プログラマじゃないだろ？
具体例の無い説明といい、「ｘｘを駆使」とかいかにも営業が使いそうな言い回しといい、胡散臭すぎる。
0329デフォルトの名無しさん
2007/05/31(木) 22:35:50流れを読め。
オレ＝>>314
これからこの話題につながってるんだが。
また別にお前に依頼してる訳ではないから具体的に書く必要性もない。
0330デフォルトの名無しさん
2007/05/31(木) 23:43:090331デフォルトの名無しさん
2007/06/01(金) 00:14:39>>327
MCが単純って書いた覚えはないよ。
金融工学の問題ってSIMDがクリティカルに利いてくるような
単純な代数計算なのかって話。
0332デフォルトの名無しさん
2007/06/01(金) 00:43:42商用ライブラリーを購入する手があるが、処理スピードと精度のトレードオフの調整が利かない。
これをCで組むと四則演算+EXPの多用となる。普通にプログラミングするとかなり遅いがSIMDを使うと大幅に
高速化する。SIMDにEXPがあると良いのだが。
0333・∀・）っ-○◎●
2007/06/01(金) 00:59:18Intelが数学用ライブラリ出してなかった？
x87のアレはどうせマクロ命令なので。
ちなみにdivpsとかで得られる商は近似値で精度低い。
0334デフォルトの名無しさん
2007/06/01(金) 01:06:33ニュートンは方程式を解くのに多用するが初期値問題があるしな。
MKLのEXPは使い方によるだろうが、メモリにデータを貯める必要があるときは高速だろうが
そうでないとメモリアクセスの遅さがネックになってあまり役立たない。
0335・∀・）っ-○◎●
2007/06/01(金) 01:12:44あくまでSIMD使うからこそ意味があるんだけど。
0336デフォルトの名無しさん
2007/06/01(金) 01:24:31とすれば試してみる価値あるな。
expのニュートンは簡単そうだし。。。
初期値どうするかな
0337デフォルトの名無しさん
2007/06/01(金) 01:33:410338デフォルトの名無しさん
2007/06/01(金) 01:37:50解析的に求める方法がなければモンテカルロを使うしかない。
という理由で使われる。
0339デフォルトの名無しさん
2007/06/01(金) 09:24:190340デフォルトの名無しさん
2007/06/02(土) 00:29:40>>335
よく考えたら f(x)=exp(x)で f'(x)=exp(x)だからexpをニュートンで求めるのは無理だな。
テーラー展開でやってみたんだが
・テーラー展開式 exp(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までやって精度９桁くらいだったかな。
しかし処理時間は非常に遅かった。
時間がなかったのであまり詳しく調べなかったがコーディングに問題あるかな？
0341デフォルトの名無しさん
2007/06/05(火) 01:32:460342・∀・）っ-○◎●
2007/06/05(火) 06:08:53インラインアセンブラのニーモニックは使えるが
0343デフォルトの名無しさん
2007/06/05(火) 14:01:57お前が>333でネタ振ったんだから責任もって>340のフォローしろや
0344・∀・）っ-○◎●
2007/06/05(火) 19:50:20対象データが複数あるなら複数インターリーブするとスループットが稼げます。
0345デフォルトの名無しさん
2007/06/05(火) 20:33:01その理論で行けばSPEのスカラも多くはスループット1クロックで処理出来るんだがな。
つーかx86にその理論を適用するにはレジスタが足(ry
0346・∀・）っ-○◎●
2007/06/05(火) 20:34:120347・∀・）っ-○◎●
2007/06/05(火) 20:39:13データ移動（部分データ移動は不可）するとレジスタリネームのヒントになる
SIMDレジスタは内部的に80程度はあるからそこそこいけるんでない？
Cellの演算ユニットはIntelアーキのそれの倍のレイテンシがかかる。
SPEのスカラが性能でないのは、そもそもベクタ化すら出来ないデータを
並列処理でレイテンシ隠蔽するには限界があるから。
0348デフォルトの名無しさん
2007/06/05(火) 21:00:360349デフォルトの名無しさん
2007/06/05(火) 21:06:06レジスタリネームとかって言ってる人のコードの書き方に興味がある。
よっぽどコンパクトな演算じゃない限り演算結果をレジスタから追い出さなきゃいけないと思うんだが。
0350デフォルトの名無しさん
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
0351・∀・）っ-○◎●
2007/06/05(火) 21:50:00精度確保できるんじゃないの？
Intelはx87倍精度は内部的に80ビット精度に展開して処理してるけど
SSEは精度度外視してたような。
精度が必要ならx87のほうがいいかもしれない
0352デフォルトの名無しさん
2007/06/05(火) 22:11:04divpsは近似値じゃないんじゃない？
0353・∀・）っ-○◎●
2007/06/05(火) 22:21:410354・∀・）っ-○◎●
2007/06/05(火) 22:22:190355デフォルトの名無しさん
2007/06/05(火) 22:28:36そのソースは？
rcppsのレイテンシとmulpsのレイテンシを足しても
divpsのレイテンシよりずっと短いよ。
インテルの命令セットマニュアルには
rcpps,rsqrtpsの説明には近似値であると明記してあるけど、
divpsには近似値なんて書いてないよ。
0356デフォルトの名無しさん
2007/06/05(火) 22:32:08そら80bitなら何十クロックもかかるわな。
0357デフォルトの名無しさん
2007/06/05(火) 23:08:46スマン、教えてほしい
（アセンブラは苦手なだが)多項式近似のパタンは和算→乗算の繰り返しでやるしかないという認識なのだが
乗算を先に4つやって、あとから和算4つ行うって計算は可能なのか？
0359デフォルトの名無しさん
2007/06/05(火) 23:31:26そういう手があるのか
サンクス
0362デフォルトの名無しさん
2007/06/06(水) 00:34:38別物。テーラー展開とチェビシェフ系の違い。
0364340
2007/06/06(水) 19:11:56回答ありがとう。
俺の知識ではいま一つ分らんが命令の並び順に工夫がいるということと
他のデータも同時に処理できたら同時に行うということかな。
>>363
確かに最初がまちがっとる。記述ミスなのできにしないでくだはれ。
ま、exp（）だと近似式でやったほうが速そうだね。
0365340
2007/06/06(水) 19:15:18ほとんど知らないのだけれど皆さんはどの分野でやられてるのでしょうか？
0366デフォルトの名無しさん
2007/06/06(水) 21:54:11逆に聞きたいのは、金融の分野で応用効くの？
桁数が必要だろうし、スピードよりも可読性が求められそうじゃ無い？
0367340
2007/06/06(水) 23:23:51HPC分野はほとんど未開拓な状態だと思う。
またSIMDとかMPIなどは外資パッケージソフトの一部では使われている。
SEへの「もっと計算を速くできないか」との要請に対し
自分の無知なことも知らず「莫大な金と時間がかかる」の一点張りで受け入れられないケースが多い。
このため多くのユーザーは高速化は無理なことと思っている。
という状況下、前にも挙げたようにリスク管理やデリバティブ関連などでは高速化へのニーズは高く、
この辺からHPC化が進んでいくと思う。
現時点では、すぐ欲しい計算結果も下手をすると数日かかるといったことが、あたりまえにおこなわれているから・・・
0368・∀・）っ-○◎●
2007/06/06(水) 23:36:08VC++だと数学関数はSSE2対応ならSSE2版使ってくれるようになってるみたい？
純正の最適化ルーチンより速くしようと考えるのはぶっちゃけかなり無謀かと。
0369340
2007/06/06(水) 23:57:04問題は上に書いたことなんだ。
皆さん、金融システムやらないかい？
0370デフォルトの名無しさん
2007/06/07(木) 01:16:32重たいのはDBとかで、SIMD化するようなものでは無いイメージがある。
0371デフォルトの名無しさん
2007/06/07(木) 01:19:320372デフォルトの名無しさん
2007/06/07(木) 01:23:590373デフォルトの名無しさん
2007/06/18(月) 23:11:593つ以上、チェックがつけばアナタの性格はひん曲がっており、
ネガティブ負け組派遣人生を歩んでいます。
□派遣先正社員の作った糞開発ツールはたとえ腐っててもマンセーして使う
□派遣先の人事権のある社員の意見はたとえ間違っていてもマンセーする
□昼食は必ず派遣先の社員と行くべきだ
□派遣先から「いつまでもここで仕事してくださいね(安い金でｗ)」と言われて嬉しい
□自社で仕事なんてできるわけがない
□派遣労働の問題点の話題が出ると感情剥き出しにして反論する
□派遣労働の問題を指摘する人は嫌いだ
□派遣先には仕事だけでなくプライベートについてもグイグイ引っ張って欲しい
□奢ってくれる派遣先正社員を尊敬する
□自分の月額金額を知らないのは当然だ、単金を聞いてはいけない
□派遣先正社員より自分の生涯収入が低いのは当然だ
□派遣先に尻尾を振り、かわいがってもらうことが大切だ
□チビは派遣先にかわいがってもらいやすから派遣には有利だ
0374デフォルトの名無しさん
2007/06/22(金) 00:18:26int 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
}
0375デフォルトの名無しさん
2007/06/22(金) 00:43:562つの文字列を同時に処理するなら使えるかな？
0376・∀・）っ-○◎●
2007/06/22(金) 00:54:28MMX/SSE2の掛け算は16ビット×16ビットまでしかできないから
半端に使ってもかえって遅くなるような。
依存関係がきれいに解決できてpmaddwdが適用できれば速くはなりそうだが。
0378・∀・）っ-○◎●
2007/06/22(金) 01:07:24hash = (hash * a * a * b) + (cr[i] * a * b) + cr[i+1];
a = a * b * b;
引き伸ばしていけば並列演算できそうなところは結構あるんだが、さて・・・
ああ頭いてぇ
0379デフォルトの名無しさん
2007/06/22(金) 01:46:48みんなどこから手をつけはじめたのですか？
0380341
2007/06/22(金) 02:34:18intrin.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番目の引数が定数でもエラーにならない
0382デフォルトの名無しさん
2007/06/22(金) 15:15:51俺も最初はこんなのから始めて動作を確認していった。
（この書き方、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;
}
0384341
2007/06/23(土) 00:28:500f 3a 0f c1 01 palignr mm0, mm1, 1
定数でない場合
0f 3a 0f c1 ac palignr mm0, mm1, DWORD PTR _i$[ebp]
0385デフォルトの名無しさん
2007/06/23(土) 09:10:46図がいぱい載ってるぞw
0386デフォルトの名無しさん
2007/06/24(日) 09:40:42exp(x)=2^(y1+y2)と変換する（y1は整数部y2は少数部）
y2を多項式近似で求めると速くできる
10桁程度の精度でよければ7次で可能
>>465
0387デフォルトの名無しさん
2007/06/28(木) 12:38:59それをやるならy1は整数、y2は-0.5<=y2<0.5と選んだ方がよさそうだね。
0388デフォルトの名無しさん
2007/06/29(金) 01:19:41そうだね。
ところでｙ１が正のときはビットシフトで行けるんだが
負の時はいい方法ないかね？
0389デフォルトの名無しさん
2007/06/29(金) 12:06:17こんな本が出てるね
0390デフォルトの名無しさん
2007/06/29(金) 13:24:550391デフォルトの名無しさん
2007/07/03(火) 22:32:30これでどうやって下巻を書くつもりなんだろう
0392デフォルトの名無しさん
2007/07/08(日) 00:12:540393デフォルトの名無しさん
2007/07/08(日) 00:20:390394デフォルトの名無しさん
2007/07/08(日) 01:16:16｜相対誤差｜≦ 1.5×2^-12
って書いてあるから、
仮数部12bitくらいの精度しかないって事だよね？
0395デフォルトの名無しさん
2007/07/08(日) 01:17:58そして倍精度にそんなトランジスタ割けないというのが合理的理由だろう。
0396395
2007/07/08(日) 01:27:58仕組みとしてはテーブルを引いてるだけのはず。
だから24bitとか32bit分ものテーブルを用意出来るわけが無い。
倍精度を使うような人は精度重視なわけで、
divpdあるんだからどうしてもやりたいんだったらソフトウェアでrcppsから精度上げてくれ、
マイクロコードを用意するのはバカバカしい、ということ。
0397デフォルトの名無しさん
2007/07/08(日) 01:42:11能書き垂れてるんだが
結局393と何が違うんだよ
0398395
2007/07/08(日) 08:28:15違いは無い。ただ393だけ言われても392が納得しづらいだろう。
テーブルの要素数が
12bit->4096
24bit->1677万
だけ必要であると考えれば物理的に無理な事が納得出来る。
0399・∀・）っ-○◎●
2007/07/08(日) 13:13:44クロック数かかる上に【近似】解じゃねぇ
0400デフォルトの名無しさん
2007/07/09(月) 22:20:07この本買ってみたけど、リファレンスいうから命令全部載ってるのかと思ったら載ってなかった
手元にリファレンス的なものがあるといいなと思って買ったのに・・・詐欺だわー超高いし
0401薄汚い派遣の国、日本
2007/07/15(日) 21:35:53派遣契約を切られたにもかかわらず「次の派遣先でも切られてしまって生活できません」
などと 言って泣き落としで再契約した派遣のことです。
今月初め、半年前に切った派遣が出社してきてみんなびっくりしました。
影でコソコソ偉い人に泣きついて再契約したそうです。同じ部署の人には黙って・・・
そんなことまでして自宅の近くの派遣先にこだわって人間として恥ずかしくないのですか。
派遣でスキルアップ、派遣で収入アップとか言うなら一箇所にしがみつかず
複数の会社を渡り歩いてください。
ひとつの会社で派遣向けの単調な仕事をしていたらスキルアップなんてありえないでしょう。
身分不相応な商品のローンを払うために派遣だと当然足りない収入は親にも寄生して、
いつ切られるんじゃないかとビクビクしながら人事権のある人間とだけ仲良くし、
契約終了を通知されれば泣き落とし。悲惨な人生ですね。
氏んだほうがいいんじゃないですか。
0402デフォルトの名無しさん
2007/07/19(木) 19:33:12http://download.intel.com/jp/developer/jpdoc/IA32_Arh_Dev_Man_Vol1_Online_i.pdf
これでええやん。
あとはビルトイン関数のヘッダ見ればだいたい書けるだろ。
0403デフォルトの名無しさん
2007/07/21(土) 21:32:103つ以上、チェックがつけばアナタの性格はひん曲がっており、
ネガティブ負け組派遣人生を歩んでいます。
□派遣先正社員の作った糞開発ツールはたとえ腐っててもマンセーして使う
□派遣先の人事権のある社員の意見はたとえ間違っていてもマンセーする
□仕様とは正社員から口伝されるものだ
□口伝された仕様を意図どおり理解できなかったのは自分の責任だ
□昼食は必ず派遣先の社員と行くべきだ
□自分の仕事で問題が発生しても解決するのは派遣の仕事ではない
□派遣先から「いつまでもここで仕事してくださいね(安い金でｗ)」と言われて嬉しい
□自社で仕事なんてできるわけがない
□派遣労働の問題点の話題が出ると感情剥き出しにして反論する
□派遣労働の問題を指摘する人は嫌いだ
□派遣先には仕事だけでなくプライベートについてもグイグイ引っ張って欲しい
□奢ってくれる派遣先正社員を尊敬する
□自分の月額金額を知らないのは当然だ、単金を聞いてはいけない
□派遣先正社員より自分の生涯収入が低いのは当然だ
□チビは派遣先にかわいがってもらいやすから派遣には有利だ
0404デフォルトの名無しさん
2007/07/27(金) 18:34:11という理解で良いですか?
a[0] <<= b[0]
a[1] <<= b[1]
a[2] <<= b[2]
a[3] <<= b[3]
みたいな事がやりたいんですが。
0405デフォルトの名無しさん
2007/07/27(金) 20:05:42処理速度は劣るが、シフトの代わりに乗算で処理するとか。
0406デフォルトの名無しさん
2007/07/27(金) 23:47:270407デフォルトの名無しさん
2007/07/28(土) 09:54:290409・∀・）っ-○◎●
2007/07/29(日) 02:26:32cvttpi2ps→指数部操作→cvttps2pi
0410341
2007/08/25(土) 01:58:03Intel SSSE3/SSE4.1/SSE4.2とAMD ABM/SSE4aに対応しているようだ
0411・∀・）っ-○◎●
2007/08/25(土) 03:04:10なにSって。
0412デフォルトの名無しさん
2007/08/26(日) 11:25:57MMXのシフト系の命令って、ソースオペランドに直値、メモリ、MMレジスタのみですよね？
汎用レジスタ（eaxとか）を書いてもうまく動作しなかった気がするんですが、
VC6,VC8ともに、以下のコードがエラーにならず通ってしまいます。
psllq mm0 , eax
何か勘違いしてますか？
disassembleしてみたまえ。
0414デフォルトの名無しさん
2007/08/26(日) 14:50:52eaxって書いたところがmm0になってました。
インラインアセンブラのバグ？ VC6のころからそうなのに
VC8でも放置してるのはなんか理由があるのかな。
0415・∀・）っ-○◎●
2007/08/26(日) 17:02:22汎用・FP/MM・XMMのレジスタ指定はopcodeで決まるから
0416デフォルトの名無しさん
2007/08/26(日) 17:31:27逆アセしてmm0に見える理由がそれだとしても、アセンブラの文法
としてeaxって書くべきではないところに、そう書いてエラーにしない
のはおかしいと思いませんか？
0417・∀・）っ-○◎●
2007/08/26(日) 17:32:25movd mm0, eax
だとどうなるかな。opcodeで区別してるはずだが
0418デフォルトの名無しさん
2007/08/26(日) 17:44:310419デフォルトの名無しさん
2007/08/30(木) 17:09:15AMDが発表したSSE5で独立シフト量ができるようになるね。
SIMDのローテート命令まで追加されてる。
http://developer.amd.com/assets/sse5_43479_BDAPMU_3-00_8-27-07.pdf
0420デフォルトの名無しさん
2007/09/02(日) 04:12:12AltiVecからSSEに仕方なく移ったマカーな俺にはSSEは使いにくすぎる
0421デフォルトの名無しさん
2007/09/02(日) 04:17:130422・∀・）っ-＜コ:彡-
2007/09/04(火) 07:15:100423デフォルトの名無しさん
2007/09/05(水) 23:49:14もー出てるなら我慢できるけどさ、まだ出てないじゃん。
0424・∀・）っ-＜コ:彡-
2007/09/06(木) 00:47:160425デフォルトの名無しさん
2007/10/19(金) 17:12:17なんか使いにくそうに思えるのですが……。
0426デフォルトの名無しさん
2007/10/19(金) 19:17:59pmull : 16 bit で済む時
pmulh : 小数部 16 bit の固定小数点乗算したい時
0427ヽ・´∀｀・,,）っ━━━━━━┓
2007/10/20(土) 01:26:210428デフォルトの名無しさん
2007/10/24(水) 22:36:46http://www.cutt.co.jp/book/4-87783-170-7.html
SSSE3まで
SSE4はない
0429デフォルトの名無しさん
2007/10/24(水) 22:52:020430デフォルトの名無しさん
2007/10/25(木) 01:49:440431ヽ・´∀｀・,,）っ━━━━━━┓
2007/10/25(木) 01:55:23にSSE4.1/4.2のマニュアル一式とエミュレーションDLLがついてるからそれで十分。
0432デフォルトの名無しさん
2007/10/27(土) 05:20:500433ヽ・´∀｀・,,）っ━━━━━━┓
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);
0434ヽ・´∀｀・,,）っ━━━━━━┓
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);
0435デフォルトの名無しさん
2007/10/31(水) 21:29:380436デフォルトの名無しさん
2007/10/31(水) 21:57:180437デフォルトの名無しさん
2007/10/31(水) 22:03:360438デフォルトの名無しさん
2007/11/01(木) 00:19:03__m128i _mm_move_epi64(__m128i)
void _mm_storel_epi64(_m128i*, __m128i)
0439デフォルトの名無しさん
2007/11/01(木) 02:28:070440ヽ・´∀｀・,,）っ━━━━━━┓
2007/11/01(木) 23:00:54MMXのは無い。
__m64 mm0 = a[i]で既にロードに展開される。てか、コンパイラ任せ。
0441デフォルトの名無しさん
2007/11/14(水) 19:03:2464ビット整数のグローバル変数1つを操作する関数が
頻繁に呼ばれるプログラムを作っています。
アセンブラ見ると、32ビットずつ操作しているようなんですが
これをMMXを使っていっぺんに操作するようにすれば、高速化しますか？
高速化するなら、MMX勉強してみようかなと思ってるのですが。
0442デフォルトの名無しさん
2007/11/14(水) 19:57:230443デフォルトの名無しさん
2007/11/14(水) 19:59:230444デフォルトの名無しさん
2007/11/14(水) 22:10:28double でやればー?
0445ヽ・´∀｀・,,）っ━━━━━━┓
2007/11/14(水) 23:38:440446デフォルトの名無しさん
2007/12/22(土) 23:14:35ビット数一致しているかチェックするのに
SSEって有効に使えそう？1ビットずつチェック
とかアホ過ぎて
uint32_t chk_bit(uint32_t master, uint32_t src, uint32_t bit){
この中どうしよう。
}
0447ヽ・´∀｀・,,）っ━━━━━━┓
2007/12/22(土) 23:53:57return ((master ^ src) >> (32 - bit)) != 0;
0448デフォルトの名無しさん
2007/12/24(月) 00:16:33あるbitが立っているかどうかを高速に調べる方法はありませんか？
SSE4.1でptst命令が導入されますが，それまで待ってられません．
0449ヽ・´∀｀・,,）っ━━━━━━┓
2007/12/24(月) 00:30:38movdqa xmm1, [pattern]
movdqa xmm2, xmm0
pand xmm2, xmm1
pcmpeqb xmm2, xmm1
pmovskb eax, xmm0
test eax, eax
でeaxが0以外ならビットが立ってる。
0450ヽ＞´∀｀＜,,）っ━━━━━━┓
2007/12/24(月) 00:31:510451デフォルトの名無しさん
2007/12/24(月) 00:46:27やはりpmovmskbで移すしかありませんか．．．
Nehalemまでは64bit int x 2でやっとくのが吉？
0452デフォルトの名無しさん
2007/12/24(月) 11:21:120453デフォルトの名無しさん
2007/12/24(月) 13:14:13〜略〜
double dt = (double)((ntime.QuadPart - otime.QuadPart) * (1000.0f / f.QuadPart));
をSSE使ってVC8のインラインアセンブラで書くとどうなりますか？
0454デフォルトの名無しさん
2007/12/24(月) 19:38:490455デフォルトの名無しさん
2007/12/24(月) 20:04:3564bitモードにしかありません
VCでは64bitモード用のプログラムにインラインアセンブラは使えません
0456ヽ＞´∀｀＜,,）っ━━━━━━┓
2007/12/24(月) 20:30:130457デフォルトの名無しさん
2007/12/24(月) 20:32:450458ヽ＞´∀｀＜,,）っ━━━━━━┓
2007/12/24(月) 20:37:160459デフォルトの名無しさん
2007/12/24(月) 20:58:490460デフォルトの名無しさん
2007/12/24(月) 21:00:24パケット解析するのにSSE使っても
手間になるだけ？
0461ヽ＞´∀｀＜,,）っ━━━━━━┓
2007/12/24(月) 21:02:06SSEは大量のデータに同じ処理をかけるときにこそ効果を発揮するんであって
細かい所は従来のx86命令のほうがむしろ速い。
0462ヽ＞´∀｀＜,,）っ━━━━━━┓
2007/12/24(月) 21:03:24そういうのに向いてるって話は聞いたことがない。
0463デフォルトの名無しさん
2007/12/24(月) 21:55:340464デフォルトの名無しさん
2007/12/24(月) 21:57:380465ヽ・´∀｀・,,）っ━━━━━━┓
2007/12/24(月) 22:04:420466デフォルトの名無しさん
2007/12/24(月) 22:15:440467デフォルトの名無しさん
2007/12/25(火) 17:49:27実装はcarry selectあたりだろうか
0469デフォルトの名無しさん
2007/12/26(水) 11:52:30Penrynは4.1のみ
Nehalemは4.1と4.2の両方
>>452で合ってるんじゃねーの？
0470451
2007/12/26(水) 13:20:32どうもその様ですね，THX．
ttp://pc.watch.impress.co.jp/docs/2007/0925/hot507.htm
Penrynならそれほど待たなくて済むなぁ，どうしよう．
0471451
2007/12/26(水) 13:22:02これは価格が手頃になるのを，って意味です
0472デフォルトの名無しさん
2007/12/26(水) 13:25:45求めたいのですがSSE2を使って高速にできるでしょうか？
普段はVC++を使ってますがより高速化できるならアセンブラ
もつかってみようかと考えてます。OSはVista(64bit)です。
0473デフォルトの名無しさん
2007/12/26(水) 13:54:20x64用のの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;
}
0474デフォルトの名無しさん
2007/12/26(水) 18:30:53Cだと「for (int i=0;」のところでエラーになるので
#include <cmath>
#include <cstdlib>
を付け加えてCPPファイルにしてコンパイルしてみました。
movsdx andpd comisd
などが使われていますね。これがSSE2かな？
でもこれが本当に高速なコードかどうかはわからないですね。
インテルでMKLというライブラリを出してますがこれはすごいですね。
試したのは行列計算の一部だけ（LU分解）ですが数値計算の本に載っている
プログラムをVC++でコンパイルしたものより5倍ぐらい高速です。
数学レベルで新アルゴリズムを開発した可能性は低いので実装レベル
の技術が高いと思うのです。
5倍の差は大きいのでSSEなどを勉強して何とか近づきたいのですが
大変かな？
0475デフォルトの名無しさん
2007/12/26(水) 18:38:450476451
2007/12/26(水) 20:38:30P4用でちょっと古いけど
「ストリーミング SIMD 拡張命令 2(SSE2)を使用した、倍精度浮動小数点ベクトルの最大/最小要素とそのインデックスの検出」http://download.intel.com/jp/developer/jpdoc/w_max_app_j.pdf
0477472
2007/12/26(水) 23:15:38やりたいのは絶対値の最大なのでちょっと違うけどなかなか参考になります。
最大と最小をもとめて絶対値の大きな方をとる方法と
絶対値を計算しながら最大をもとめる方法がありますね。
まあこの辺はいろいろ実験してみないとどれがいいのかわからないですね。
0478ヽ・´∀｀・,,）っ━━━━━━┓
2007/12/27(木) 02:18:53VC++だと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;
}
0479デフォルトの名無しさん
2007/12/27(木) 23:05:22SIMD化の方が簡単で面白そうだから目につきやすいんだけど、そこは最後の手段なんだよね。
配列同士の四則演算では極力全ての演算をまとめて行って、代入を1回で済ます。
行列なんかの三次元的なループはキャッシュに入る長方形のブロック単位で処理をする。
そういうところが出来てればSIMD化しなくても前者で最大2倍くらい、後者は計り知れない程速くなる。
0480474
2007/12/28(金) 23:06:10気持ちはわかるけど具体的にはどうやるのかな？
短いので高速化したいプログラムをアップしてみる。
#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;
0481474
2007/12/28(金) 23:08:38for(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重ループなのでこの付近が一番スピードに関係してそう。
0482デフォルトの名無しさん
2007/12/28(金) 23:33:400483479
2007/12/29(土) 23:23:233重のループで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がどう変わるかを事前に必要なライン数分計算出来ればいいんだろうけど。
0484474
2007/12/30(日) 21:31:17コメントありがとうございます
少し詳細に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のような多重ループのブロック化が必然となるか？
まあ、難しそうなので具体的な方法は少し考えてみます。
うまいアイデアがありましたらまたコメントください。（ややスレ違いになりつつあるが）
0485デフォルトの名無しさん
2007/12/30(日) 22:03:51もし移動するならここかな？
ttp://pc11.2ch.net/test/read.cgi/tech/1177808054/l50
0486デフォルトの名無しさん
2007/12/30(日) 22:07:51スレ違いにならなずに済むか。
0487デフォルトの名無しさん
2008/01/16(水) 18:30:070488487
2008/01/16(水) 20:45:050489デフォルトの名無しさん
2008/01/16(水) 21:28:47そうなると、周りの命令と絡めて実質的に１命令で済ますことを考えるくらいか。
0490デフォルトの名無しさん
2008/01/17(木) 00:08:24cmpeq xmm0,xmm0 で all 1 を作る方が速いか？
0491ヽ・´∀｀・,,）っ━━━━━━┓
2008/01/17(木) 00:58:10ケースバイケース。
0492デフォルトの名無しさん
2008/02/19(火) 10:43:09コンパイラがSSEを使いやすいコードはどのように書いたらよいのでしょうか？
0493デフォルトの名無しさん
2008/02/20(水) 07:38:55ソートアルゴリズムをGPUでやるやつみたいに直線的なものにすればやってくれない事は無いけど。
とにかく一番内側のループがベクトル同士の演算になるように心掛ける事。
0494デフォルトの名無しさん
2008/06/19(木) 00:27:56解説サイトしらないっすか？
0495デフォルトの名無しさん
2008/06/19(木) 03:21:260496デフォルトの名無しさん
2008/06/19(木) 22:39:47r1 = a1^2 + a2^2 + a3^2 - a4^2
r2 = a1+a2 - a3*a4 +a1+a3 + a2*a4
r = r1+r2
こんなのSSEで解きたいんだけどどうすればいいんだろう
0497デフォルトの名無しさん
2008/06/21(土) 16:25:20cmpeq()した結果が全て０かどうやって判別するの？
0498デフォルトの名無しさん
2008/06/21(土) 20:26:500499デフォルトの名無しさん
2008/06/21(土) 23:31:44倍精度の絶対値はどうすれば求まるの？
0500デフォルトの名無しさん
2008/06/22(日) 00:08:16方法1(ロード無し):
// a = a < 0 ? -a : a;
F64vec2 z = _mm_setzero_pd();
a = select_lt(a, z, z-a, a);
方法2(ロード有り):
static const __int64 _0x7FFFFFFFFFFFFFFFLL = 0x7FFFFFFFFFFFFFFFLL;
F64vec2 m(*(double *)&_0x7FFFFFFFFFFFFFFFLL);
a &= m;
0501デフォルトの名無しさん
2008/06/22(日) 00:11:01static const F64vec2 m = 以下省略
0502デフォルトの名無しさん
2008/06/22(日) 00:17:45あーそういうのがあるのですね
何分あほ過ぎて、あきれてるかもしれませんがどうもすいません。
0503デフォルトの名無しさん
2008/06/22(日) 01:06:49ちなみに絶対値の処理がループに入っていて比率が高い場合はロード有り、
絶対値を取る負荷が低いならロード無しが効率的。
ところで最近rcp_nr()やrsqrt_nr()の精度の低さを嘆いていて
もう一段階計算するか素直にdivpsを使うか考えてたんだが
ググってみるとdivpsとsqrtpsって最近は6 cycleなのな。typoじゃないのか？速すぎる。
なんかrsqrt_nr()はともかくrcp_nr()って要らない子な気がしてきた。
そもそも何故rcpps, rsqrtpsでVMXみたいに12ビット用意しなかったのかと問いつめたい。
プロセッサは日々速くなるんだから12ビットが最初は大きすぎでも用意するべきだったろう。
0504デフォルトの名無しさん
2008/06/22(日) 10:06:410505デフォルトの名無しさん
2008/06/22(日) 10:39:18常にチェックするのかな
0506デフォルトの名無しさん
2008/06/22(日) 11:39:56情報が古いが248966.pdfを読んでも13 cycleだぞ。これでも十分速過ぎるだろ。
ちょっと前まで40 cycleだったのに。
こりゃ中では12bitのrcppsを持ってるな。逆数取って精度上げが1回で済めば13 cycleでも納得出来る。
>>505
0除算は数学上定義されていない。
プログラムとか関係なく、机上で数式書いた時点でつっこむべきだ。
定義されていないので、当然答えは自分で用意する事。
1. 0で除算する時点で数式が間違っていたと認識し、方法を改める。
2. 除数が0にならないようなロジックにする。
3. 除数が0になった場合の回避策を設ける。
3-1. c = a / (b + 0.001) のようなかさ上げを行う。
3-2. c = a / max(b, 1) のような下限を設ける。
3-3. c = b == 0 ? 0 : a/b のような特別な取り扱いを行う。
4. 結果がNANかを調べて後から計算に失敗している事を認識する。
3はプログラムに組み入れる事になる。3-2と3-3は当然事前に分かればそこで取り扱えばいいし、直前まで分からなければ常にチェックする。
処理によっては無理に回避するよりも4が重要な場合もある。
0507デフォルトの名無しさん
2008/06/22(日) 12:42:58icc買うしかないか
0508デフォルトの名無しさん
2008/06/22(日) 13:32:06常にチェックしなくても、__try { } で囲んで、
0除算例外を __except() で受ける方法もあるよ。
例外を発生させるようにfldcwやldmxcsrで設定する必要があるけど。
0509デフォルトの名無しさん
2008/06/25(水) 14:48:40スレッドごとにemmsを呼ぶ必要はありますか？
それとも以下のように、複数のスレッドから抜け出た後に
一回だけemmsを呼べばOKですか？
#pragma omp parallel for
for (int i = 0; i < hoge; i++) {
// ここでMMXを使用 (x87命令は使わない)
}
_mm_empty(); // emmsはこの一回でOK？
0510509
2008/06/25(水) 16:10:01スレッドごとにemmsを呼び出すことにしました。
0511デフォルトの名無しさん
2008/06/26(木) 02:27:180512デフォルトの名無しさん
2008/06/26(木) 22:59:190513デフォルトの名無しさん
2008/06/26(木) 23:10:160514デフォルトの名無しさん
2008/06/27(金) 00:40:22MMX/3DNowはx87FPUとレジスタ兼用だから問題無いし、
SSEはFXSAVE/FXRSTORという専用命令があるから、これも問題なさそうだが。
0515デフォルトの名無しさん
2008/06/27(金) 00:50:59マルチプロセスならコンテクストスイッチ時にSSE/MMXレジスタが
保存されるだろうがマルチスレッドは一つのプロセスの中で複数の
スレッドを走らせるので汎用レジスタ退避しかない
0516デフォルトの名無しさん
2008/06/27(金) 01:03:32なにその糞環境？
晒してみ
0517デフォルトの名無しさん
2008/06/27(金) 01:10:51少なくとも Linux は大丈夫だったはず
ダメな環境を俺も知りたい
0518デフォルトの名無しさん
2008/06/27(金) 02:14:56プロセス間でもだめだしそもそも(ry
なんてツッコミはいやん
0519デフォルトの名無しさん
2008/06/27(金) 02:31:101．>>514 に書いてあるように MMXレジスタ = x87レジスタ なのだから、
MMXレジスタが保存されないなら小数点演算も同様ではないのか。
２．特権ユーザでもない限りコンテクストスイッチを禁止できない。
さもなければ誰でもシステムを強制停止できてしまう。 （例：Windows 3.1）
制御できないとしたら、ではどのタイミングでレジスタを待避すればよいのか。
３．>マルチプロセスなら ... 中略 ... レジスタが保存される
それで、マルチコア非対応になる理由はなに？
0520デフォルトの名無しさん
2008/06/27(金) 03:03:41MMXのレジスタをFDPと共有させたのはOS側の対応を不要にするための
仕掛けだったのだけど今となってはやっちゃったって感じの仕組みと評価されている。
0521519
2008/06/27(金) 08:30:11２番ではやり方を聞いてしまってるな。
この質問は撤回するとして、代わりに３番に追加しておこう。
マルチコア非対応というのはマルチプロセッサ（ユニコア）
ならばOKということか？
SMT（ハイパースレッディング等)の場合はどうなのか。
0522デフォルトの名無しさん
2008/06/27(金) 08:33:320523デフォルトの名無しさん
2008/06/27(金) 10:26:51動かないっつーのが明記されてる資料出せやｗ
0524デフォルトの名無しさん
2008/06/28(土) 01:13:58まず訂正するとユニコアなる単語はシングルコアの誤りだ。
そんで微妙に通じていないようだからもう一度聞くよ。
複数のシングルコアのCPUを搭載したマルチプロセッサの
システムでMMX/SSEは利用可能なのか。
シングルコアなんだけど擬似的にマルチプロセッサの
ように振る舞うSMT対応のCPUではどうか。
具体的に言うとHT有効なPentium4でMMXは使えるのか。
結論だけではなくて、理由を教えてもらいたいのだが。
0525デフォルトの名無しさん
2008/06/28(土) 01:31:34話を簡単にするためマルチプロセスの場合を聞きたい。
とりあえずこの件についてはマルチスレッドは保留で。
0526デフォルトの名無しさん
2008/06/28(土) 10:19:45物理CPU1つだけで稼動する
物理CPU2つならそのうち１つだけ
４つならそのうち１つだけ
0527デフォルトの名無しさん
2008/06/28(土) 11:15:050528ヽ・´∀｀・,,）っ━━━━━━┓
2008/06/28(土) 14:34:24単精度の場合だけど
;; r1 = a1^2 + a2^2 + a3^2 - a4^2
movaps xmm0, xmmword ptr [a1_a2_a3_a4] ;; a1, a2, a3, a4を並べておく
movaps xmm1, xmm0
xorps xmm1, xmmword ptr [MASK_PPPN] ;; MASK_PPPN = { 0x00000000, 0x00000000, 0x00000000, 0x80000000 }
;; これで xmm1 = { a1, a2, a3, -a4 } になる
dpps xmm0, xmm1, 0xF1 ;; 内積をとる
;; SSE4.1非対応ならdppsはこれで代替(SSE3必須)
;; mulps xmm0, xmm1
;; haddps xmm0, xmm0
;; haddps xmm0, xmm0
;; SSE3が使えないなら・・・メンドイ・・・
;; r2側は大して並列化が期待できないのでスカラでやってよし
;; r2 = a1+a2 - a3*a4 +a1+a3 + a2*a4 = a1+a1+a2+a3 + (a2-a3)*a4
movss xmm1, dword ptr [a1]
addss xmm1, xmm1 ;; a1+a1
movss xmm2, dword ptr [a2]
addss xmm1, xmm2 ;; (a1+a1) + a2
movss xmm3, dword ptr [a3]
addss xmm1, xmm3 ;;
subss xmm2, xmm3 ;; a2 - a3
mulss xmm2, dword ptr [a4] ;; (a2-a3)*a4
addss xmm1, xmm2 ;; r2 = = (a1+a1+a2+a3) + ((a2-a3)*a4)
;; 最後はこう
addss xmm0, xmm1 ;; r = r1 + r2
0529デフォルトの名無しさん
2008/06/28(土) 14:36:05回答は１件だけとか、理由を言っては駄目とかいう戒律でもあるの？
>>515でマルチスレッド非対応の原因として、コンテクストスイッチで
レジスタの内容が保証されないことを挙げているが、一方で
マルチプロセスならレジスタは保存されるとも言っている。
レジスタがきちんと保存されるならMMX/SSEを使わないプログラムと
何も違わないのに、なぜ一つの物理CPUに縛られるのか。
そんでどのCPUに固定的に割り当てられるのか。
そもそもその割り当てをするのはOS,CPU,アプリのうちどれ？
OSかCPUならその名称、アプリならAPIの名称を教えてくれ。
すくなくとも最後の質問にだけは答えてほしい。
0530ヽ・´∀｀・,,）っ━━━━━━┓
2008/06/28(土) 15:03:54HT Pen4はおろかCore 2 Quadでも余裕で使えてるから問題ない
Core 2上だとXMMレジスタ使ったときのちょうど半分のスループットだけどな
0531デフォルトの名無しさん
2008/06/28(土) 15:05:48あ、526では"物理CPU"と書いてあるね。
>>524の質問には両方答えてあったのか。
すまない。 上の 2行目前半部分は、撤回する。
それと上でCPUなら名称を教えてくれと言ったがCPUのモデル名
ではなくて、振り分けを担当する機構の名称を聞きたかった。
（デコーダ、スケジューラ、実行ユニット等）
不注意な点が多いのは申し訳ない。 以後気をつける。
0532ヽ・´∀｀・,,）っ━━━━━━┓
2008/06/28(土) 15:05:530533デフォルトの名無しさん
2008/06/28(土) 15:07:42いや、使えるのは知っている。
ていうか使えないと主張しているのが１人いるだけ。
0534ヽ・´∀｀・,,）っ━━━━━━┓
2008/06/28(土) 15:11:31http://www.intel.com/jp/download/index.htm
IA-32 インテルR アーキテクチャー・ソフトウェア・デベロッパーズ・マニュアル、下巻: システム・プログラミング・ガイド
なんかをちゃんと読んでない子が1名いるのね
0535デフォルトの名無しさん
2008/06/29(日) 00:50:52>MMX/FPステートの退避・復帰
をやってない処理系があるって主張してる子がいるんだろ
0536デフォルトの名無しさん
2008/06/29(日) 01:17:44仮にそんな処理系があったとして
MMX/SSEがマルチスレッドに対応していないことには
ならないよな。あくまでそのクソOSが対応してないだけであって。
つーか、バカバカしいので打ち切りの方向で。
0537デフォルトの名無しさん
2008/06/29(日) 11:01:50そんな世迷い言が出てくるのか聞いてみたくてね。
>>529の回答がソフトウェアなら糞環境乙だし、ハードなら
そんなもんあるわきゃないので、たぶん返答はないだろう
けど、あっても次で終わるさ。
はぐらかすようならもう相手にしない。
0538デフォルトの名無しさん
2008/07/08(火) 23:47:17レジスタ何本まで同時に使えるの？
0539デフォルトの名無しさん
2008/07/09(水) 00:07:06CPUというのはコアなのかダイなのか？
ニモニックから指定できるレジスタは固定だがどういう意味のレジスタなんだ？
0540デフォルトの名無しさん
2008/07/09(水) 00:11:480541ヽ・´∀｀・,,）っ━━━━━━┓
2008/07/09(水) 10:31:48まさにその数分のレジスタが同時に使えるんだよ。
というのも、説明すると
add eax, 3という操作があるとする。
実レジスタファイル上のeaxにマッピングされた領域から値をロードし、3を加えて
またeaxに格納するってのを1サイクルでこなすのは実際は無理。
ショートカット用のレジスタ（要はアキュムレータ）に値を残すことによって、
次の命令ですぐにeaxの値を参照できるわけだ。
つまり1サイクルってのは実レジスタではなくアキュムレータの更新にかかるサイクル
でしかない。
それ以上になると、実レジスタの読み書きの分待たされるので遅くなるわけ。
で、そのショートカットレジスタは実行ユニットの個数分だけある。
64bitでの性能が伸び悩むのも同じ理由だよ。
レジスタ個数が増えた分、レジスタ間オペレーションのインターリーブがしやすくなった。
でもそれによってショートカットの有効利用ができなくなる。
増えたレジスタを有効に使おうとすればするほど、実レジスタファイルへの読み書きが増え、
高速化が使えなくなる。
ちなみにNehalemでは若干改善されるみたいだが。
おそらくは同時にショートカットできるレジスタの個数が増えるのだろう。
0542ヽ・´∀｀・,,）っ━━━━━━┓
2008/07/09(水) 10:50:030543デフォルトの名無しさん
2008/07/09(水) 22:28:30糞すぎるんだよなぁ
0544デフォルトの名無しさん
2008/07/30(水) 21:25:160545デフォルトの名無しさん
2008/07/30(水) 22:18:57mencoder
ffmpeg
0546デフォルトの名無しさん
2008/07/30(水) 22:57:31でも、考えてみたら、タスクスイッチのときに、
今のコンテキストの情報(全レジスタ丸ごと)をメモリにコピーして
スイッチ先タスクのコンテキストの情報を丸ごとメモリから読み込む訳だから、
コアが幾つあっても、タスクを実行するコアが入れ替わっても、
全然問題ありませんよね。
0547デフォルトの名無しさん
2008/07/30(水) 23:16:18マルチタスク環境での MMX/SSE の使用は問題なくて、
ただ、スレッド開始時のコンテキストの情報がどうなっているかは、環境依存だろうから、
スレッド開始時にフラグを設定しなおした方がいいという事ですよね。
複数の CPU がある場合でも、タスクを実行する CPU が入れ替わらなければ、1 CPU の時と同じだし、
タスクを実行する CPU が入れ替わる場合でも何らかの形でコンテキストの情報丸ごとを受け継がなければ、
タスクの続きを正常に実行できなくなるわけだから、アプリケーションを作る
プログラマが心配するような事では全くありませんよね。
なんかグダグダ書いてしまいって、見苦しいですよね。
御不快でしたら、スルーして下さいよね。
0548デフォルトの名無しさん
2008/07/31(木) 11:11:550549デフォルトの名無しさん
2008/08/01(金) 23:37:03明日までに欲しい
0550デフォルトの名無しさん
2008/08/09(土) 16:28:29指定の下位nビット(1 <= n <= 32)以外のビットが立っていないときに、
その配列をnビット幅の配列としてメモリ上にギチギチに詰める＆
詰めたものを32bit幅の配列に戻す、ということをやりたいです。
詰めるフォーマットは自由で、
詰め元・復元先について先頭のalignmentは揃えられます。
0551デフォルトの名無しさん
2008/08/09(土) 16:53:050552デフォルトの名無しさん
2008/08/09(土) 16:57:050553デフォルトの名無しさん
2008/08/10(日) 03:17:260554,,・´∀｀・,,
2008/09/01(月) 11:12:38PowerPC(970以降)は命令間レイテンシが大きいからそれはそれで
隙間埋めるのが大変なんだがな。
1回だけ使うデータのロードだけでも１命令分使っちゃうこととか、
32ビット即値をレジスタにセットするのにも2命令かかったりとか、
いざ使ってみるとパフォーマンスにかかわる制約が多すぎる。
Int/FP/SIMD各32本とレジスタ本数が多いのが逆に災いして
レジスタリネーミングそのものも弱いから、高速化のためには
レイテンシ隠蔽のため静的なアンロールに費やされることになり、
結果的にはx86に対するレジスタ本数差分の優位すら覆されてしまう。
ジョブズの「今までの○倍」ってプレゼンもあながち誇張でもない。
ものによっては確かにそれくらいIntel CPUのほうが性能が出る。
命令セットは汚く論理リソースは限られてるが、その分だけ逆に
アグレッシブな動的最適化技術が比較的有効に働くからね。
Java仮想マシンがスタックマシンなのだって、スタック構造は
並列度を抽出しやすいから。また、論理レジスタが少ないほど
アウトオブオーダ・レジスタリネーミングのリソース管理が楽。
もちろん、静的な最適化で事足りるならそれに越したことはないんだが
実行ステージのパイプラインが深くなったりするたびに再コンパイル
（最悪の場合再コーディング）してられないなど、「コード資産」
という名の制約もあるからね。
Intelのx86は新命令を取り入れつつも、既存のコードもコンパイル
しなおさなくてもある程度は速く走ることを主眼に改良してきたから、
いろんな処理を無難にこなせるわけだ。
0556デフォルトの名無しさん
2008/10/01(水) 14:05:220557デフォルトの名無しさん
2008/10/02(木) 08:53:34すっごくわかりやすかったんだよなぁ
信者になる気持ちもわかる
0558デフォルトの名無しさん
2008/11/15(土) 22:15:50簡単なベンチとったら↓以下のようになった。
SIMDに有利な内容だったとはいえ、SSEは結構すごいんだな
floating_point time = 0.012824
std::valarray time = 0.137409
packed_value time = 0.000011
0559デフォルトの名無しさん
2008/11/15(土) 22:50:49ベンチを見直したら↓になった
そりゃそうだよね orz
float time = 0.036192
std::valarray time = 0.117789
packed_value time = 0.026709
0560デフォルトの名無しさん
2008/12/02(火) 00:46:090x00000000000000FF0000000000000000
渡すとなぜ0x8000になるのですか？
0561デフォルトの名無しさん
2008/12/02(火) 11:54:51ならないはず。
__m128iにそのデータをセットして_mm_movemask_epi8を
呼び出すまでのコードをアップしてみて。
0562デフォルトの名無しさん
2008/12/02(火) 20:45:48えーと上のコードだと以下の計算で会ってますか？
(0x00 >> 7) << 15 |
(0x00 >> 7) << 14 |
(0x00 >> 7) << 13 |
(0x00 >> 7) << 12 |
(0x00 >> 7) << 11 |
(0x00 >> 7) << 10 |
(0x00 >> 7) << 9 |
(0xFF >> 7) << 8 |
(0x00 >> 7) << 7 |
(0x00 >> 7) << 6 |
(0x00 >> 7) << 5 |
(0x00 >> 7) << 4 |
(0x00 >> 7) << 3 |
(0x00 >> 7) << 2 |
(0x00 >> 7) << 1 |
(0x00 >> 7)
0563デフォルトの名無しさん
2008/12/03(水) 01:27:00それで0x0100
0564デフォルトの名無しさん
2008/12/03(水) 22:41:53なんで0x0100するの？どこにもそんなこと出てないけど
0565,,・´∀｀・,,）っ-○◎●
2008/12/05(金) 08:04:19デバッグウィンドウに出てきた16進ダンプをビッグエンディアンだと思い込んでるんじゃないの？
00 00 00 00 00 00 00 FF 00 00 00 00 00 00 00 00
を0x00000000000000FF0000000000000000だと勘違いし
80 00
を0x0080じゃなくて0x8000だと勘違いしてると。
0566デフォルトの名無しさん
2008/12/06(土) 10:02:32許してください
0567デフォルトの名無しさん
2009/01/19(月) 10:10:01何でandnotがあるの？
実用的にはこの方が都合いいのかい？
0568,,・´∀｀・,,）っ-○◎●
2009/01/19(月) 18:55:400569デフォルトの名無しさん
2009/01/19(月) 19:26:110570デフォルトの名無しさん
2009/01/19(月) 19:53:13まあnotした値はまた何かと演算する事が多いので
xorとandnotがあれば殆どの場合は事が足りるというのが理由かと。
0571デフォルトの名無しさん
2009/01/19(月) 20:17:400572デフォルトの名無しさん
2009/01/19(月) 20:22:39それにload使っちゃうのが勿体ない。
0573デフォルトの名無しさん
2009/01/20(火) 11:17:34確かに言われてみれば結果の正負問わなきゃand
or
xor
andnotであらゆる２値論理演算を１命令で出来るな。
でもやっぱり釈然とせんなぁ…
普通にnotより要らない命令ありそう。
0574デフォルトの名無しさん
2009/01/20(火) 12:08:33実際の回路作る時にはandよりnandの方が作りやすいんだそうな。
0575,,・´∀｀・,,）っ-○◎●
2009/01/20(火) 16:02:43安藤能登と難度は別物
AND-NOT： A & ~B
NAND： ~(A & B)
てかいい加減MUXが欲しい。
(A & B) OR (A & ~B)
0576,,・´∀｀・,,）っ-○◎●
2009/01/20(火) 16:05:14pcmpeqb xmm0, xmm0
pxor xmm0, xmm1
おｋｗｗｗｗｗｗ
0577デフォルトの名無しさん
2009/01/20(火) 16:29:46他の命令で容易に代用可能な処理にオペコード割り振る余裕がないから
0578,,・´∀｀・,,）っ-○◎●
2009/01/20(火) 17:35:440579デフォルトの名無しさん
2009/01/20(火) 17:39:43ある程度Cッぽい文法でお手軽になってきたようですけど。
0580,,・´∀｀・,,）っ-○◎●
2009/01/20(火) 17:42:46http://pc11.2ch.net/test/read.cgi/tech/1215388508/
0581デフォルトの名無しさん
2009/01/20(火) 18:01:18途中で書き換えたから少し分かりにくい文になってますが、
SSEはケチってますが、GPUはケチってるわけじゃありません。
CELLだと演算結果をPCの方に持ってこれませんよね。
もしかして物理演算（フィズクス）の方もやっちゃってるんですか？
0582,,・´∀｀・,,）っ-○◎●
2009/01/20(火) 18:13:290583デフォルトの名無しさん
2009/01/20(火) 18:40:55インテルのマニュアル読んでいて気がついたんですけど、
最近はSSEユニット搭載PCがだいぶ多くなってきたので、レジスタも多くなったと考えられませんか。
つまり、汎用レジスタは従来どおりIO関係とアドレス計算専用としておいて、
FPUは使用せず、MMXを整数計算（64bits)専用、SSEを浮動小数計算専用とすればそれぞれのユニットは直交してるので、
従来のインテルみたいなレジスタが少ないアキテクチャでもその概念で使うと多少は変数（レジスタ）が増えるかなって思います。
その代わり80bitsじゃないですけど、FPU使いたいときはいつも通りです。
0584デフォルトの名無しさん
2009/01/20(火) 18:44:13団子さんみたくアセンブラ職人だとレジスタ使い放題なんじゃないですかね。
といっても、職人団子さんがsimdコンパイラとかライブラリ作ってくれればそれまでですが。
それと、SSEと比べるならSIMDはGPUの方が５倍１０倍以上速いし、アライメントとかも含めてだいぶ職人の英知が必要なので、所詮は小手先業かなって感じですけど。
0585,,・´∀｀・,,）っ-○◎●
2009/01/20(火) 23:37:180586デフォルトの名無しさん
2009/01/20(火) 23:40:590587デフォルトの名無しさん
2009/01/20(火) 23:55:49ありがとう
団子さんはやさしい
0588デフォルトの名無しさん
2009/01/21(水) 00:01:12いや。結構いけるかも
0589デフォルトの名無しさん
2009/01/21(水) 01:16:03指摘されるまでもなくSSE使う時点で従来の整数レジスタはアドレスとループカウンタに総出でかり出されてる。
アドレスとループカウンタにレジスタ8つでもギリギリ足らないくらいだから、今までがいかに足りてなかったか考えるとやっぱこの変態アーキは笑える。
で、例えばAthlon系で3DNowとSSEを併用しても速くならないんだなこれが。
整数SIMDと浮動小数点数SIMDで演算器が分かれているわけでもないから、
MMXを整数、SSEを浮動小数点数としてもメモリアクセスの軽減以外に効果はあまりない。
というか、Cellみたいな1要素がスカラとしても扱える便利なアーキテクチャでも無い限り
浮動小数点数の演算が重要でSIMDを導入しよう、って箇所において整数SIMDが出てくる事なんてまずないと思うんだ。
0590デフォルトの名無しさん
2009/01/21(水) 02:30:07結局どれぐらいPGがプログラムしやすいか（管理しやすいか）てことかと思う。
storentapsみたいなキャッシュ効率をいちいち管理するとかはPGの仕事じゃなくてハード（それぐらいアキテクチャの組み込んどけ）の仕事かな。
ただ他のアキテクチャでもメモリからフェッチするわけで、どのハードを使ってもフェッチする以上計算じゃなくてメモリ転送の差じゃないのかな。
アセンブラに頼るような設計はしないし、アセンブラは直接使わないでコンパイラ任せだからあまり関係ないけど。
0591デフォルトの名無しさん
2009/01/21(水) 02:31:34もっとレジスタの糞少ないi8080で、XOR AとかやってたんだYo!
0592,,・´∀｀・,,）っ-○◎●
2009/01/21(水) 10:40:09> アドレスとループカウンタにレジスタ8つでもギリギリ足らないくらいだから、今までがいかに足りてなかったか考えるとやっぱこの変態アーキは笑える。
それは無いわ。何の計算やってたらそうなんだ？
どうせ多重ループとかやってんだろ？外側のループカウンタなんていちいちレジスタに置いておくなよ。
Ｐｅｎｔｉｕｍ M以降のＩｎｔｅｌアーキはスタック管理専用のハードウェアを備えてるからpush/popを
高速でこなしてくれる。
> というか、Cellみたいな1要素がスカラとしても扱える便利なアーキテクチャでも無い限り
あれのどこが便利なんだアレが。
MM/XMMレジスタでも最初の要素をmovd/movqで汎用レジスタに転送できるだろ？たかだかレイテンシ1で。
なんならpextrdでもどうぞ？あとptestで分岐条件レジスタ操作できるけど何か？
君、頭弱いでしょ。
0593デフォルトの名無しさん
2009/01/21(水) 13:36:12多重ループなんてコンパイラが自動的に最適化するだろう。
実計算をやった事がない負荷ベンチマーク厨は黙ってろ。
0594,,・´∀｀・,,）っ-○◎●
2009/01/21(水) 13:57:540595,,・´∀｀・,,）っ-○◎●
2009/01/21(水) 13:59:400596デフォルトの名無しさん
2009/01/21(水) 14:06:100597,,・´∀｀・,,）っ-○◎●
2009/01/21(水) 14:07:100598,,・´∀｀・,,）っ-○◎●
2009/01/21(水) 14:08:00みえんざん なのか
根本的な問題として
実演 算 なのか
実 演算 なのか
0599,,・´∀｀・,,）っ-○◎●
2009/01/21(水) 14:10:17ぐたいてきに
実演してくだサンせ
0600,,・´∀｀・,,）っ-○◎●
2009/01/21(水) 14:11:510601デフォルトの名無しさん
2009/01/21(水) 14:19:520602,,・´∀｀・,,）っ-○◎●
2009/01/21(水) 14:22:040603,,・´∀｀・,,）っ-○◎●
2009/01/21(水) 14:24:48自分でレジスタの割り当ての管理はできなくても組み込み関数くらいは使えるでしょ。馬鹿じゃないんだから。
っていうか、組み込み関数なしでMMX/SSEを適切に使ってくれるコンパイラって無いけど。
CellやGPUよりx86のほうが圧倒的に楽だよ。
0604デフォルトの名無しさん
2009/01/21(水) 14:25:030605,,・´∀｀・,,）っ-○◎●
2009/01/21(水) 14:27:210606デフォルトの名無しさん
2009/01/21(水) 15:00:120607デフォルトの名無しさん
2009/01/21(水) 15:01:44誰に対していってるか不明だけど、もしかして人違いしてないか？
0608,,・´∀｀・,,）っ-○◎●
2009/01/21(水) 15:05:36CellやGPUより
ﾆﾎﾝｺﾞﾖﾒﾏｾﾝｶ?
GPUが万能で全てのSIMD演算を高速に行えると思い込んでるｳﾞｧｶは相手にしたくない。
いやな制約だらけ。
0609,,・´∀｀・,,）っ-○◎●
2009/01/21(水) 16:06:05http://pc11.2ch.net/test/read.cgi/jisaku/1228400588/902,907
あたりでも嫁。もちろんCellも基本的にこの分野では難しいね。
0610デフォルトの名無しさん
2009/01/21(水) 16:20:46いや。そうじゃなくて、CellやGPUと、x86の何（の機能）を比べて圧倒的に楽かていってるわけ？
x86はSIMDを念頭においた設計から始まったわけじゃないから、そもそも比べるところないんだけど、どこを比べてるのかな。
0611,,・´∀｀・,,）っ-○◎●
2009/01/21(水) 16:32:38明示的にやらないといけないのがはんざつ（麻生語ではない）。
それ以上でもそれ以下でもない。
キャッシュ汚染を抑えたい箇所でprefetch*やmovnt*を使わなくなって遅くなるだけで別に死にはしないが
Cellだとスクラッチパッドメモリの容量超えたらアウトなんだよ。
CUDAは言語レベルである程度抽象化されてはいるが、本質的なハードの制約にはCellよりもっと厳しい。
0612デフォルトの名無しさん
2009/01/21(水) 17:08:01その部分は人の手でやるとかネイティブを直接扱う（キャッシュ・メモリ管理する）んじゃなくて、まず初めにライブラリとかのツールを作ってコンパイルするアプローチじゃないの？
そういうのがそろっているからこそ、扱いが圧倒的に楽といえるんじゃないか。
その分直接扱うときに比べれば冗長が生じるけど、楽したいわけだしその辺はトレードオフ。
0613,,・´∀｀・,,）っ-○◎●
2009/01/21(水) 17:56:18諸君 私はGPGPUが大嫌いだ。
低容量のシェアードメモリが嫌いだ
低容量のコンスタントメモリが嫌いだ
if文なのに分岐しないプレディケート機構が嫌いだ
switch文ですら分岐しないプレディケート機構が嫌いだ
やたら多いけど自由に使えないレジスタファイルが嫌いだ
低クロックなシェーダコアそのものが嫌いだ
CUDAで OpenCLで
Brook+で CALで
Compute Shaderで
この地上で行われるありとあらゆるGPGPUが大嫌いだ
0614デフォルトの名無しさん
2009/01/21(水) 19:53:400615,,・´∀｀・,,）っ-○◎●
2009/01/21(水) 21:10:320616デフォルトの名無しさん
2009/01/22(木) 01:56:41特に>>613 とか頭悪過ぎる。スパンコだと思えばむしろ普通じゃん。
せっかく昼間っから粘着できるニートなんだから、何でもアセンブラ
職人として腕を磨けば良いのに。
0617デフォルトの名無しさん
2009/01/22(木) 05:32:14なんていうか、素でキモイ。
折角持ち合わせた知識スキルを人の気を害する使い方すんなよ。
ただワガママで周りが見えてない馬鹿に見えるぜ。
0618,,・´∀｀・,,）っ-○◎●
2009/01/22(木) 05:38:370619デフォルトの名無しさん
2009/01/22(木) 10:09:570620デフォルトの名無しさん
2009/01/22(木) 11:12:32団子さんの自己表現用ですっ！
0621デフォルトの名無しさん
2009/01/22(木) 15:51:32そのまえに脳ミソが癌化してる気もするがｗ
0622デフォルトの名無しさん
2009/01/22(木) 23:54:14素直に退散するこった
0623デフォルトの名無しさん
2009/01/23(金) 00:06:400624デフォルトの名無しさん
2009/01/23(金) 09:45:32つかそれ以前にSSEのshuffleて癖あるよな？
0625,,・´∀｀・,,）っ-○◎●
2009/01/23(金) 12:38:41http://msdn.microsoft.com/ja-jp/library/bb531427.aspx
0626デフォルトの名無しさん
2009/01/23(金) 13:49:36コードにもよるんですが、ベンチをしても、gcc -O1, O2, O3 でそれぞれ異なるんで挙動を測定できないんですが。
それと、fenseとかキャッシュ制御も測定値（最適化つかう・つかわないときのベンチ）が一定してないのでイマイチ効果があるかわかりません。
0627,,・´∀｀・,,）っ-○◎●
2009/01/23(金) 14:33:03【movnt*が有用なケース】
既にL1キャッシュに載っかってる見込みで、そのままキャッシュに保持したいデータがある。
なおかつ、ストア先のアドレスは、キャッシュに載っかってなおらず、ストアしたデータを
すぐに再利用する予定もない。
ストア先のアドレスのアクセスがシーケンシャルでない場合は、汚染を防ぐ意味では特に有用。
movntでないアクセスをすると、該当アドレスはL1にフェッチされてしまう。
フェッチされた分、L1にもともとあったデータがL2以下にパージされてしまう可能性が高くなる。
【もっとも移植性の高いprefetcht0の代替方法】
volatile int tmp;
for (int i = 0; i < array.size(); i++) tmp = array[i];
簡易的にはキャッシュラインのどれかにタッチしてればL1に割り当てられるので、サイズに応じて
32バイトとか64バイトとかのストライドでタッチすればいい。
普通はprefetch*を使いますけどね
0628デフォルトの名無しさん
2009/01/23(金) 14:50:56測定不可能（不安定）なのにベンチすることも出来ないわけで、マニュアル記載の理論上の話ではなく、
実際にそのキャッシュ汚染を考慮したコードを組み込むだけの効果があるかどうかなんですけど。
ベンチをするサンプル・コード（や最適化オプション）によって全くベンチ結果が違うってことも分かります。
ただ、SSEを使うコードは巨大配列(64KB以上とか）が普通で再利用しないのでmovntps効果ありそうなんですけど、思ったほどでもありません。
そのような巨大配列はアライメントなど普通はされてないので、どうもprefetchやmovntpsの使いどころが分かりません。
0629,,・´∀｀・,,）っ-○◎●
2009/01/23(金) 15:03:33数十MBとかそれ以上の単位にならないと効果は実感できないかも知れない。
シーケンシャルだったり定ストライドだったり、アクセスに程度パターン性があればCPU側が勝手にやってくれる。
そう言う局面でprefetch*を変に使おうとすれば却って遅くなることもある。
効果がないと思えば、使わないのも手ではある。
0630デフォルトの名無しさん
2009/01/23(金) 15:24:10つまり、動画とか３DゲームならSSEを使うまでもなくGPUとか他を使うわけで、SSEは全く意味ないってことじゃないですか？
いまのところ画像ファイルにSSE適用することを考えてるので、アライメントされてない配列は高々９MB程度なんですけど、キャッシュ汚染を考慮したコードを書いても２,３倍高速になるわけではないようです。
まだあまり試してませんが、せいぜい5%程度速くなるところでしょうか。
なので、このインテルが提供しているキャッシュ制御機構は、どういうときだと劇的な効果（storeupsに比べて２倍高速とか）が出てくるんですか？
0631,,・´∀｀・,,）っ-○◎●
2009/01/23(金) 15:37:51キャッシュも256KBあればいいほうだった。
メモリ帯域も狭くて、それ故にその256KBに収まるかどうかどうかがパフォーマンスを
大きく左右した。
なんせ、Pentium IIIはCellのSPE程度のトランジスタ数しか備えてなかったからね。
明示的なキャッシュ制御命令の使用の効果はCPUの進化により、劇的なものは見られなくなった。
逆にいうと、ハードウェアの進化により、明示的なキャッシュ制御命令を使わないことの
デメリットが小さくなったってこと。これは好意的に解釈していいこと。
それでも5％程度あるならまだまだ意味はあるわけだが、どう解釈するかは自由。
もちろん、もしCPU以外のハードウェアによるアクセラレーションが使えるなら
それを使ってもいい。
0632デフォルトの名無しさん
2009/01/23(金) 15:38:28PGがCPU側のキャッシュメモリL123の管理（汚染など）を考慮しようがしまいが、
その効果も相殺されるってことなのでしょう。
0633,,・´∀｀・,,）っ-○◎●
2009/01/23(金) 15:48:33ミスアラインアドレスに対してテンポラルストアを使う場合は、palignrを使って補正してからストアすると速い。
ただしSSSE3をサポートしてないCPUでは使えない。
AMDだとPhenom以降はmovntss/movntsdが使えるからこっちを試してもいい。
どんだけ効果あるか疑わしいんだが。
0634デフォルトの名無しさん
2009/01/23(金) 19:21:19＞明示的なキャッシュ制御命令の使用の効果はCPUの進化により、劇的なものは見られなくなった。
それはただL2 L3 キャッシュの容量が大きくなって、実用上十分なキャッシュ容量となったからではないか？
0637デフォルトの名無しさん
2009/01/23(金) 21:55:53特に何も工夫のない三角関数を作ってベンチを取ったところ
_mm_prefetchと_mm_stream_psのペアがないものは
標準Cライブラリ以下の速度で
ペアがあるものは、3倍程度になった。
この結果から、SIMDはプリフェチがないと使い物にならないしろものだと
思ったけど違うのかな？
0638デフォルトの名無しさん
2009/01/23(金) 22:10:180639デフォルトの名無しさん
2009/01/23(金) 22:20:47なんか変な処理してるとしか思えんのだが
0640,,・´∀｀・,,）っ-○◎●
2009/01/23(金) 22:23:32現行のMSVCRTの数学関数は内部的にSSE*使ってるけど？
何のアルゴリズムの工夫も無くSIMD化しただけでは勝てなくても不思議ではないよ
0641デフォルトの名無しさん
2009/01/23(金) 22:31:13単純にベンチ用。プリフェチの効果を確認したかっただけです。
内容も64kb先読みしてるだけです。
>>640
最適化オプションで、SSEのスカラ使用状態になってるはわかってる。
でも一応俺のはSIMD化されてる訳でしょ。4倍のアドバンテージを
アルゴリズムだけで覆すってのも、難しい話な訳で。
0642,,・´∀｀・,,）っ-○◎●
2009/01/23(金) 22:34:170643デフォルトの名無しさん
2009/01/23(金) 22:43:52俺が聞きたいのは団子が他のライブラリを使っているとかいう回答ではなくて
標準や引率すべきコンパイラメーカの努力不足／整備不足をどう思っているか。
0644デフォルトの名無しさん
2009/01/23(金) 23:06:39意味不明
エスパー求む
0645,,・´∀｀・,,）っ-○◎●
2009/01/23(金) 23:13:03データの再利用頻度の高い処理なら明示的なprefetch/non-temporal storeなんざ使わなくても
単純2倍以上の性能向上は得られるよ
0646デフォルトの名無しさん
2009/01/23(金) 23:24:26__forceinline packed_value< _num_element, _element_type > __fastcall cos( /*[in]*/const packed_value< _num_element, _element_type >& v )
{
typedef packed_value< _num_element, _element_type > p_t;
p_t x;
uint_t i = 0;
if( sizeof(p_t) > p_t::cacheline_size )
{
const uint_t num_split = p_t::cacheline_size / p_t::unit_size;
while( i < p_t::num_unit - num_split )
{
_mm_prefetch( (const char*)( &v.unit(i) + num_split ), _MM_HINT_NTA );
_mm_prefetch( (const char*)( &x.unit(i) + num_split ), _MM_HINT_NTA );
uint_t j = 0;
for( ; j < num_split; ++j )
_mm_stream_ps( (float*)&x.unit(i), cos( v.unit(i) ) );
i += j;
}
}
for( ; i < p_t::num_unit; ++i )
_mm_stream_ps( (float*)&x.unit(i), cos( v.unit(i) ) );
return x;
}
0647デフォルトの名無しさん
2009/01/23(金) 23:29:431024要素のcosを計算してる。
これのプリフェチがない奴は、std::cosの1024ループに負ける。
cosの実装は教科書どおり
n != 0 : ( power< n >( value_type(-1)) / factorial< 2*n, value_type >() * power< 2*n >(x) ) + value< n-1 >( x)
n == 0 : 1
変数の再利用性は皆無なので、プリフェチないと駄目なのかな？
0648デフォルトの名無しさん
2009/01/23(金) 23:40:46その教科書だけど、SIMD用の公式も使ってみた？
0649,,・´∀｀・,,）っ-○◎●
2009/01/23(金) 23:57:38なんとなくアセンブラ読んでみると無駄な計算してそうな気がする
明示的なプリフェッチで改善されると言うことは、根拠はないがワークメモリがキャッシュ境界を跨いで
何度も再利用されてる気がする。
とすれば、アセンブリコード吐かせてスタックフレームサイズをどれだけ食ってるか見てみると面白いことになってるかもしれない。
テンプレート使うと、結構膨れあがることがあるんだわ。
>>648
割と素直なFFTのほうが性能出るかも知れないね
0650デフォルトの名無しさん
2009/01/24(土) 00:20:180651デフォルトの名無しさん
2009/01/24(土) 00:27:56いつの時代のCPU２を
比べるつもりだ？
0652デフォルトの名無しさん
2009/01/24(土) 07:44:58すまん。
三角関数とかのSIMD版がライブラリに入ってはいるのに内部的に使われるだけでヘッダが公開されてないんだよ。
自動ベクトル化はちょっとしたマスク、分岐、std:maxとかが入っただけで諦めてスカラ演算する糞仕様だから自分でSIMD化するわけだが
その時に基本的な数学の関数くらい用意してくれよと。
特にintelのコンパイラは内部的には持ってるんだから。
0653,,・´∀｀・,,）っ-○◎●
2009/01/24(土) 07:47:05げふんげふん
0654デフォルトの名無しさん
2009/01/24(土) 07:55:42そうなじゃなくて、CPUを作ってるメーカーがこのていたらくはなんだと問いたいわけ。
公開しないなら公開しないで、自動ベクトル化を完璧にしろと。
0655,,・´∀｀・,,）っ-○◎●
2009/01/24(土) 08:37:38Intelとのライブラリ共有の協定でもあるんじゃないかと思ってるんだが。
SIMD周りの組み込み関数の対応だけはしっかりしてるよMSは。
0656デフォルトの名無しさん
2009/01/24(土) 10:33:51○こっそり
だと思うのは俺だけ?
0657デフォルトの名無しさん
2009/01/24(土) 15:13:58テイラー展開とかを駆使して関数を実装することも出来るが自分でメンテするのも面倒だろ？
素直にintelのコンパイラ買えばよろし。
0658デフォルトの名無しさん
2009/01/24(土) 19:29:380659デフォルトの名無しさん
2009/01/24(土) 20:16:12>>652と>>654を読めば分かるとおり、intelのコンパイラを使ってるし三角関数のSIMD版は用意できている。
0660デフォルトの名無しさん
2009/01/25(日) 11:30:24それどころかご丁寧にfloatをdoubleに拡張しやがる。
俺にはお節介な機能だけど、ちょっと感動を覚えた。
0661デフォルトの名無しさん
2009/02/01(日) 17:04:24GCCで
__m128d x={290,320},y={199,1000};
x+=y;
みたいに関数不要でパック演算が通ったんだけど、
これってintrin系ヘッダーが提供された頃からずっと出来たの？
それとも、最近のGCC拡張？
0662,,・´∀｀・,,）っ-○◎●
2009/02/01(日) 19:54:24同様にAltiVecやSPUでも加減論理など一部の組み込み関数をC演算子で代用できる。
0663デフォルトの名無しさん
2009/02/01(日) 20:39:35天然なのかワザとなのか……
0664デフォルトの名無しさん
2009/02/01(日) 20:49:17言い争いになってもいつも相手の真意からズレたところを叩いて自分の話に持って行く。
0665デフォルトの名無しさん
2009/02/01(日) 20:56:40相手にした時点で負けー
0666,,・´∀｀・,,）っ-○◎●
2009/02/01(日) 21:44:340667デフォルトの名無しさん
2009/02/02(月) 12:28:550668デフォルトの名無しさん
2009/02/05(木) 19:31:270669デフォルトの名無しさん
2009/02/22(日) 19:51:270670,,・´∀｀・,,）っ-○◎●
2009/02/22(日) 20:30:54http://www.fides.dti.ne.jp/~tokai/vc/mmxab3.html
SSE2以降なら128bit単位でできる。
0671デフォルトの名無しさん
2009/02/22(日) 21:53:200672デフォルトの名無しさん
2009/02/22(日) 23:08:11正しい計算は「255で割る」
0673,,・´∀｀・,,）っ-○◎●
2009/02/22(日) 23:16:54257かけて上位ワードを取るとかすれば多少速いかな？
実用上256(8ビットシフト)で充分だけど。
0674デフォルトの名無しさん
2009/02/22(日) 23:47:560675デフォルトの名無しさん
2009/02/22(日) 23:52:060676,,・´∀｀・,,）っ-○◎●
2009/02/23(月) 00:06:01256で割るように改変した数式で、どのケースで誤差がでるか考えてみればいい。
誤差がでるやつだけ特殊化すればいいだけでは？ｗ
0677255
2009/02/23(月) 00:14:280678,,・´∀｀・,,）っ-○◎●
2009/02/23(月) 00:17:270679デフォルトの名無しさん
2009/02/23(月) 00:22:010681デフォルトの名無しさん
2009/02/23(月) 16:27:220682デフォルトの名無しさん
2009/02/23(月) 20:59:300683デフォルトの名無しさん
2009/02/25(水) 00:52:01254 = ((255 - 0) * 255 >> 8) + 0;
0684,,・´∀｀・,,）っ-○◎●
2009/02/25(水) 03:39:16http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/public/gfxColor.h
#define GFX_DIVIDE_BY_255(v) \
(((((unsigned)(v)) << 8) + ((unsigned)(v)) + 255) >> 16)
でいいらしい。
もっと単純化すると
(v * 257 + 255) >> 16
0685,,・´∀｀・,,）っ-○◎●
2009/02/25(水) 05:14:43これで確認
#/usr/bin/ruby
(255*255).times{|i|
if (((i+1)*257) >> 16) != (i / 255)
puts "#{i} : #{i/255}"
end
}
0686デフォルトの名無しさん
2009/02/25(水) 09:44:58dst.r 最後だけ赤限定？
0687デフォルトの名無しさん
2009/02/25(水) 15:51:53常に切り捨てなら685の式＋pmulhwで8並列で処理できるが。
0688デフォルトの名無しさん
2009/02/25(水) 18:37:330689,,・´∀｀・,,）っ-○◎●
2009/02/25(水) 18:43:410690デフォルトの名無しさん
2009/02/25(水) 19:22:140691デフォルトの名無しさん
2009/02/26(木) 08:07:550692デフォルトの名無しさん
2009/02/26(木) 15:49:02pmulhw(v + 1, 257)なら32ビットの上位16ビットを取り出せるだろ。
0693デフォルトの名無しさん
2009/02/26(木) 15:58:310694デフォルトの名無しさん
2009/02/26(木) 16:10:29だがPMULHUWはMMXではなくSSEの範疇なのであった。まあ、今更大した問題じゃないが
0695デフォルトの名無しさん
2009/03/20(金) 11:48:07Core2にはないよね？
0696デフォルトの名無しさん
2009/03/20(金) 22:28:150697,,・´∀｀・,,）っ-○◎●
2009/03/21(土) 00:34:22もともとビットスキャン命令があるからね。
SSE的にはcvtdq2psで浮動小数に変換して指数部をとれば並列処理できるぜ。
0698デフォルトの名無しさん
2009/03/21(土) 00:39:16具体的にCore2だとどれ使えばいいのですかね？
0699,,・´∀｀・,,）っ-○◎●
2009/03/21(土) 00:41:00movd eax, xmm0
movnti [mem], eax
movntsd [mem], xmm0の代用方法
movq mm0, xmm0
movntq [mem], mm0
emms
そう考えればなくて困る命令は特にないな。
insertq/extrqは有効な使い道がわからん。
SSE4Aって誰得？
0700,,・´∀｀・,,）っ-○◎●
2009/03/21(土) 00:44:52bsrって命令
ただ0ビットのカウント以外の副作用があるから、そう言う意味では使いにくい命令ではある。
組み込み関数を使うなら
http://msdn.microsoft.com/en-us/library/fbxyd7zd(VS.80).aspx
0701,,・´∀｀・,,）っ-○◎●
2009/03/21(土) 00:49:310702デフォルトの名無しさん
2009/03/21(土) 09:01:40Intel出してないの？
0703,,・´∀｀・,,）っ-○◎●
2009/03/21(土) 16:26:34有料だけど。
0704デフォルトの名無しさん
2009/04/03(金) 20:38:11exe形式になってるんだがダブルクリックしても prease waite...ってメッセージが出たまま起動しない。
なぜ〜？
ハッ、まさかCPUがAMD製だから立ち上がらないのか？ｗｗｗ
0705デフォルトの名無しさん
2009/04/03(金) 20:56:42JRE最新にしたら立ち上がったわ。
0706,,・´∀｀・,,）っ-○◎●
2009/04/04(土) 02:10:290707デフォルトの名無しさん
2009/04/04(土) 09:58:13Java入れてる？
0708デフォルトの名無しさん
2009/04/04(土) 14:50:560709デフォルトの名無しさん
2009/04/04(土) 15:29:140710デフォルトの名無しさん
2009/04/04(土) 16:02:580711デフォルトの名無しさん
2009/04/04(土) 16:17:330712,,・´∀｀・,,）っ-○◎●
2009/04/04(土) 16:19:4405, 06, 07とか要らないんだが
0713デフォルトの名無しさん
2009/04/04(土) 16:42:580714デフォルトの名無しさん
2009/04/04(土) 16:49:102chに書き込むの?
0715,,・´∀｀・,,）っ-○◎●
2009/04/04(土) 16:59:390716デフォルトの名無しさん
2009/04/04(土) 17:00:200718,,・´∀｀・,,）っ-○◎●
2009/04/04(土) 17:25:550719デフォルトの名無しさん
2009/04/19(日) 03:53:360720,,・´∀｀・,,）っ-○○○
2009/04/19(日) 10:36:480721デフォルトの名無しさん
2009/04/20(月) 01:11:49どういう基準で変えてんの?
0722デフォルトの名無しさん
2009/05/15(金) 13:32:52どっかにまとまったやつないのかな
0723デフォルトの名無しさん
2009/05/15(金) 14:04:16http://software.intel.com/file/10069
SSE
SSE2
SSE3
SSSE3
SSE4.1
SSE4.2
AES/PCLMUL
まである
0724デフォルトの名無しさん
2009/05/15(金) 16:09:12ありがとうー
あとでじっくり読んでみる
0725,,・´∀｀・,,）っ-○○○
2009/05/15(金) 23:13:150726,,・´∀｀・,,）っ-○○○
2009/05/15(金) 23:17:00ちなみにAMDのほうはきちんと分かれてる
0727デフォルトの名無しさん
2009/06/14(日) 03:16:30そのMUX間違ってませんか?
0728デフォルトの名無しさん
2009/06/14(日) 03:35:170729,,・´∀｀・,,）っ-○○○
2009/06/14(日) 22:40:360730デフォルトの名無しさん
2009/06/17(水) 02:52:440731デフォルトの名無しさん
2009/06/17(水) 07:11:35いじられ対象と同じくバカの壁を越えられない奴が釣られてくるので面白い。
0732,,・´∀｀・,,）っ-○○○
2009/06/18(木) 03:20:36OR が | であって || でないことくらいわかってるだろ
つか、MMXからあるPANDN命令って３命令でMUX演算するのを想定してると思うんだが
(V)PCMOVとかあったら使う頻度少なくならね？
んで、今度はNANDとかNORが欲しくなる。
なんでこうビット論理演算に関して不自由な命令セットなんだろうな
0733,,・´∀｀・,,）っ-○○○
2009/06/18(木) 03:21:51orz
0734デフォルトの名無しさん
2009/06/18(木) 04:42:210735デフォルトの名無しさん
2009/06/20(土) 18:45:250736デフォルトの名無しさん
2009/06/25(木) 14:25:18例えば1+2をfor文で100個*100回やるとして、1度に10回計算できるから10個*100回で済むとかいうことですか？
また、それを使うコードなどがあるのですか？
それと、ヘッダファイルにあるライブラリの関数などにも適用できますか？
0737デフォルトの名無しさん
2009/06/26(金) 01:08:30データの取り扱いにも使う。
まぁここに聞く前にインテルのドキュメントでも見ておいたら？
0738デフォルトの名無しさん
2009/06/26(金) 01:50:430739デフォルトの名無しさん
2009/06/26(金) 10:59:450740デフォルトの名無しさん
2009/06/26(金) 11:03:080741デフォルトの名無しさん
2009/06/26(金) 11:11:07XMMレジスタを使うようになるだけで、ベクトル化はほとんどやらないから
パフォーマンスがアップすることはまれ。逆に遅くなることも。
0742デフォルトの名無しさん
2009/06/26(金) 18:57:25全くの誤りじゃなくて？
0743デフォルトの名無しさん
2009/06/26(金) 19:20:00意地でもやらないって幹事。
0744,,・´∀｀・,,）っ-○○○
2009/06/29(月) 00:08:26差額でICC買うと幸せになれます
0745デフォルトの名無しさん
2009/07/01(水) 03:10:340746デフォルトの名無しさん
2009/07/01(水) 11:59:06?が多い
0747デフォルトの名無しさん
2009/07/01(水) 20:28:520748,,・´∀｀・,,）っ-○○○
2009/07/01(水) 23:55:530749デフォルトの名無しさん
2009/07/03(金) 20:40:09/arch:sse2
sinとかcosはsseに変えてくれてた
データ転送だけのwhileforは変えてくれないんだね
そこはインラインか
0750デフォルトの名無しさん
2009/07/03(金) 23:53:31高すぎてかえないお
ちがうなsincosはとんでたわw
0752デフォルトの名無しさん
2009/07/04(土) 02:16:010753デフォルトの名無しさん
2009/07/04(土) 02:23:460754デフォルトの名無しさん
2009/07/04(土) 03:58:04SSE2が持ってるのは四則演算とシャッフル演算とベクトル演算程度だろ
超越関数は相変わらずFPUに頼るしかない
0755デフォルトの名無しさん
2009/07/04(土) 06:45:45四則演算で書かかれた超越関数サブルーチンを使った方が速い。
intelのコンパイラなんて、SSE2未対応CPU向けコードでも
fsin命令は使わず四則演算で計算してる。
0756デフォルトの名無しさん
2009/07/04(土) 12:17:230757デフォルトの名無しさん
2009/07/04(土) 13:53:47sse２使おうとして
/arch:sse2にして2008expressに変えて
コンパイルリンクしたら
同じ動作しない／(^o^)＼ﾅﾝﾃｺｯﾀｲ
voidつけろ系のワーニングは無視して
やったけどさ
結構仕様変わってるんだね
ちなみに自分で作ったfftだけ/arch:sse2
にしてfft10000回やってみたら2秒縮まったお
けっこうぎゃく汗したらxmm系結構使ってるみたいで
がんばってるんだね
そこだけ
そのまま持って行って同じ動作しないのは
めんどいな
vc6.0のままインライン＋fftだけ2008のでコンパイルするか。
できるかわからんけど
0758デフォルトの名無しさん
2009/07/04(土) 14:20:160759デフォルトの名無しさん
2009/07/04(土) 14:42:57うっせーな
なんで同じ動作しないかとかわかる？
0760デフォルトの名無しさん
2009/07/06(月) 13:41:39一発で出来ないのかな？
本来のアンパックって言っていいのかわからないけど
998877を009900880077みたいに広げるの
0761デフォルトの名無しさん
2009/07/06(月) 18:00:01PMOVZXBW xmm, xmm/m64
PMOVZXBD xmm, xmm/m32
PMOVZXBQ xmm, xmm/m16
PMOVZXWD xmm, xmm/m64
PMOVZXWQ xmm, xmm/m32
PMOVZXDQ xmm, xmm/m64
0762デフォルトの名無しさん
2009/07/06(月) 20:26:12うわっこりゃニーモニックを覚えるだけで一苦労だ
0763デフォルトの名無しさん
2009/07/06(月) 23:11:33しかし規則的だとはいえ命令も長くなってきて
ぱっと見ランダムな文字列に見える
0764,,・´∀｀・,,）っ-○○○
2009/07/06(月) 23:14:190765デフォルトの名無しさん
2009/07/20(月) 00:38:56その結果で分岐させるにはどういう方法がスマートなんだろう
比較の結果がこうだったらこっちとかやりたいんだけど
結果が入ったMMXレジスタをどう扱ったらいいかわからない
0766デフォルトの名無しさん
2009/07/20(月) 01:02:230767デフォルトの名無しさん
2009/07/20(月) 01:10:48大して変わらなくなるな。
0768デフォルトの名無しさん
2009/08/01(土) 18:34:270769,,・´∀｀・,,）っ-○○○
2009/08/01(土) 18:49:340770デフォルトの名無しさん
2009/08/01(土) 18:50:562^nならシフトのみでいける
x/y≒x*(2^n/y)>>n
あきらめてSSEにでも
0771,,・´∀｀・,,）っ-○○○
2009/08/01(土) 18:51:490772デフォルトの名無しさん
2009/08/01(土) 19:08:20逆数求めるところから既にわからん…
なんか手持ちの色んなソフト見てみたらみんなMMX以降みたいなのばっかだったから
とりあえずMMXでやってみたんだ
0773デフォルトの名無しさん
2009/08/01(土) 19:24:57よーく見たら割る値が256だけでいけることに今気が付いた…
0774デフォルトの名無しさん
2009/08/01(土) 20:52:42cで何も考えず乗算除算使いまくった素のプログラムより遅くなったｗ
なぜなんだああああああ
0776デフォルトの名無しさん
2009/08/01(土) 22:43:210777デフォルトの名無しさん
2009/08/01(土) 23:03:19で、そこもMMXにしたら確かに4倍近く速くなった気がする
でも白を合成すると段々黒くなってくるなあ
やっぱりアルファが255なのに256で割りまくってるのが駄目なんかな
なかなか難しいね
0778デフォルトの名無しさん
2009/08/01(土) 23:54:330779デフォルトの名無しさん
2009/08/02(日) 10:17:53このスレためになるな
しかし全く考えてなかったからレジスタが全然足りなくて困る
16本くらいにしてくれればよかったのに…
0780,,・´∀｀・,,）っ-○○○
2009/08/02(日) 12:47:430781デフォルトの名無しさん
2009/08/02(日) 16:41:41pmulhwで257掛けてどうのっていうの
小数点全部切り捨てだから意味なくない？
0782デフォルトの名無しさん
2009/08/02(日) 17:36:43今更気が付いた
どのみち画面が真っ黒になって出来なかったけどｗ
0783デフォルトの名無しさん
2009/08/05(水) 14:18:190784デフォルトの名無しさん
2009/08/06(木) 02:46:480785デフォルトの名無しさん
2009/09/06(日) 16:34:5432ビットCPUだとそれぞれ別個に8個ずつあるんですか？
違いはMMXが64ビットでXMMが128ビットというだけ？
0786デフォルトの名無しさん
2009/09/06(日) 23:22:560787デフォルトの名無しさん
2009/09/06(日) 23:58:320788デフォルトの名無しさん
2009/09/06(日) 23:59:37常識だぞ
0789デフォルトの名無しさん
2009/09/07(月) 00:02:30日本語ならなんとか探せるとは思うんだけど…
0790デフォルトの名無しさん
2009/09/07(月) 00:08:03CHAPTER9〜11を読め
英語が分からないとかそういう質問は受け付けない
0791デフォルトの名無しさん
2009/09/07(月) 00:25:23…80ページくらいあるな…
The eight 128-bit XMM data registers...（中略）...
they can be accessed independently from the x87 FPU and MMX registers
and the general-purpose registers
ってあるから、一つ目の質問の答えはyes？
二つ目の答えはよく読まないとわからないか。
0792デフォルトの名無しさん
2009/09/07(月) 00:28:05PDFは常に最新版を
0793デフォルトの名無しさん
2009/09/07(月) 00:29:44SSEが単精度、SSE2から倍精度の浮動小数点を扱える(XMM)
0794デフォルトの名無しさん
2009/09/07(月) 09:48:19XMMレジスタ: 新規追加
0795デフォルトの名無しさん
2009/09/07(月) 15:12:4416個使えるのはロングモード(64ビット)のとき。
汎用レジスタだけでなく、XMMレジスタも増えたというわけ。
>>791
英語が分からないなら日本語を読めばいいじゃない。
http://www.intel.co.jp/jp/download/
IA-32 インテル® アーキテクチャー・ソフトウェア・デベロッパーズ・マニュアル、上巻: 基本アーキテクチャー
0796デフォルトの名無しさん
2009/09/30(水) 20:18:040797,,・´∀｀・,,）っ-○○○
2009/10/01(木) 02:11:46まあ、訳がどこそこおかしいが。
一時期日本Intelの仕事サボり具合は異常と思った。
0798デフォルトの名無しさん
2009/10/01(木) 06:20:41ダウンロードしてみよう。
0799デフォルトの名無しさん
2009/10/01(木) 06:34:540800デフォルトの名無しさん
2009/10/02(金) 18:25:44今PCMのステレオをモノラルに変換するコードを書いているのですが
下の処理をSSE2で書き換える場合どうすればいいでしょうか？
pshufw mm0, mm1, 0xDD
0801,,・´∀｀・,,）っ-○○○
2009/10/03(土) 13:15:50pshuflw xmm0, xmm1, 0xDD
pshufhw xmm0, xmm1, 0xDD
0802デフォルトの名無しさん
2009/10/05(月) 00:25:59助言のほうありがとうございます。
参考に色々試したら解決しました。
0803デフォルトの名無しさん
2009/10/12(月) 23:54:40人間あれが普通。
むしろ日本人が異常。
0804,,・´∀｀・,,）っ-○○○
2009/10/13(火) 01:35:18その異常な日本人がサボってるって話をしてるんでしょ。
0805デフォルトの名無しさん
2009/10/15(木) 22:04:050806,,・´∀｀・,,）っ-○○○
2009/10/15(木) 22:56:44CVTTPD2DQで十分じゃん
どのみち指数部が±2^63で扱える範囲超えてたら死ぬんだぜ
それ以上欲しかったらビットフィールド自力で展開しろとしか。
0807デフォルトの名無しさん
2009/10/24(土) 07:11:50通常は下記の様にやると思いますが、
MMXレジスタ(mm1)を使わずにmm0のみでやる代替法はないでしょうか。
mov eax, 0x00FF00FF
movd mm1, eax
punpckldq mm1, mm1
pand mm0, mm1
0808名無し募集中。。。
2009/10/24(土) 07:29:590809デフォルトの名無しさん
2009/10/24(土) 10:27:39psrlw mm0, 8
0810,,・´∀｀・,,）っ-○○○
2009/10/24(土) 11:57:07pandの第2オペランドをそのアドレスにする
0811デフォルトの名無しさん
2009/10/24(土) 19:02:36お応えありがとうございます。
それら以外はないでしょうか？汎用レジスタも使いたくなくて、
シフト二回はpand一回に比べて処理が多くなってしまうので、
１つの命令で済ませられるような…難しいとは思うのですが。
0812デフォルトの名無しさん
2009/10/24(土) 21:09:48汎用レジスタ使わなくても書けるでしょ？
0813,,・´∀｀・,,）っ-○○○
2009/10/24(土) 21:12:540814,,・´∀｀・,,）っ-○○○
2009/10/24(土) 21:13:470815名無し募集中。。。
2009/10/25(日) 06:44:57ほんとだーボケてんな、俺
esiとかediとかebpな
pand mm0,[esi+16]っていう書き方もできるし、ほとんど即値を使えないmmxでは
データセクションに定数を置いて参照するのは常套手段なんでは?
> １つの命令で済ませられるような
インテルに作ってもらえば良いじゃん！
0816,,・´∀｀・,,）っ-○○○
2009/10/25(日) 11:56:33static constで定義しる
0817デフォルトの名無しさん
2009/10/26(月) 00:38:53>>815 の[esi+16]とかのやり方が良さそうです。
１つのレジスタで色々と使い回しが利きそうで。
ご丁寧に教えて下さり、ありがとうございました。
0818デフォルトの名無しさん
2009/11/12(木) 19:37:580819デフォルトの名無しさん
2009/11/15(日) 02:23:330820,,・´∀｀・,,）っ-○○○
2009/11/15(日) 04:08:06ま、FPUの実装はさすがに旧SSE5を引きずってるのでSandy BridgeのAVXユニットと比べたら見劣り感はあるが
L1データキャッシュとロード・ストアユニットが1つのモジュールに2セットある意味を考えてみればいい。
1つのL1キャッシュで帯域倍増・LSU倍増よりは無理が無い。
0821デフォルトの名無しさん
2009/12/08(火) 12:02:31インテルコンパイラの解説がよい感じだった
インテル(R) C++ コンパイラー・ユーザー・リファレンス・ガイド
ttp://www.issp.u-tokyo.ac.jp/super/manual/system-b/Intel_Cdoc110/main_cls/index.htm
ヘルプファイルがあるらしいので探したら
日本語翻訳版ユーザー・ドキュメントのインストールについて (Windows* OS)
http://www.intel.com/software/products/compilers/docs/Intel_translated_11_documents_Windows.htm
ファイルが見つからない…とファイル名で検索したら以下のところで見つけた。
インテル(R) C++ コンパイラ Windows 版 日本語マニュアル 無料ダウンロードサービス
ttp://www.xlsoft.com/jp/products/download/intelccmanualdown.html
0822デフォルトの名無しさん
2009/12/16(水) 09:07:102コアでSSE共有じゃシングルスレッドのをマルチスレッドで実行しても今より性能性能伸びないし、
別コアで今どのユニットが使用中か予測しようがないじゃないから
CodeAnalyst Performance Analyzerで解析も無理じゃないか？
節約した分クロック上がってコア数も増えることを祈ります。
0823|ω・`)
2009/12/16(水) 11:09:17それより L2 直結でバス幅128のままなのかどうかが気になる
0824,,・´∀｀・,,）っ-○○○
2009/12/16(水) 23:59:020825|ω・`)
2009/12/17(木) 01:32:400826デフォルトの名無しさん
2009/12/17(木) 23:47:10MULとADDに分けちゃうと精度落ちない?
0827,,・´∀｀・,,）っ-○○○
2009/12/18(金) 02:11:27流石にそれはない。
FMACとは別にPermuteユニットがあって合計4ユニットかな
>>826
それは実装次第。そもそもFMA演算はIEEE754準拠じゃないんだよな。
加算のデノーマライズをパイプラインに隠蔽できるので、トータルのレイテンシが短くなると。
演算ユニットレベルで積和を統合する最大のメリットは、積和演算のレイテンシが短くなること
乗算：denormalize→乗算→normalize
加算：denormalize→加算→normalize
積和算：denormalize→乗算＋加算→normalize
しかも乗算ユニットに加算機能を付けるだけで対応できるので乗算・加算器を別々に持つよりは
実装コストが低い。
デメリットは>>824
0828デフォルトの名無しさん
2009/12/18(金) 03:00:450829,,・´∀｀・,,）っ-○○○
2009/12/18(金) 07:04:240830デフォルトの名無しさん
2009/12/23(水) 18:49:500831デフォルトの名無しさん
2010/01/01(金) 20:27:45ttp://kawahenteko.hp.infoseek.co.jp/myapp/optcode.zip
0832,,・´∀｀・,,）っ-○○○
2010/01/02(土) 03:29:420833デフォルトの名無しさん
2010/01/02(土) 22:33:230834デフォルトの名無しさん
2010/01/02(土) 22:39:33なんかこのコード変じゃないか？
__m64 m64Color1;
__m64 m64Color2;
m64Color1 = _mm_unpacklo_pi8(_mm_cvtsi32_si64(Color1), _mm_setzero_si64());
m64Color2 = _mm_unpacklo_pi8(_mm_cvtsi32_si64(Color2), _mm_setzero_si64());
m64Color1 = _mm_mullo_pi16(m64Color1, m64Color2);
m64Color2 = _mm_srli_pi16(m64Color1, 8);
m64Color1 = _mm_adds_pu16(m64Color1, m64Color2);
m64Color1 = _mm_adds_pu16(m64Color1, _mm_set1_pi16(0x0001));
m64Color1 = _mm_srli_pi16(m64Color1, 8);
m64Color1 = _mm_packs_pu16(m64Color1, _mm_setzero_si64());
return (DWORD)_mm_cvtsi64_si32(m64Color1) & 0x00ffffff;
255で正規化された２値の乗算らしいけど
これだと((a*b)+(a*b)/256+1)/256という計算になって無駄が多いと思う
0835デフォルトの名無しさん
2010/01/03(日) 23:44:06a*bは16ビットで、これに>684のように257をかけるのはMMXでは無理
MMXでこれ以上の方法は思いつかない
たしかSSE3で32ビット乗算が使えるはず
レジスタの使い方は改善の余地があるんじゃないかな
0836デフォルトの名無しさん
2010/01/03(日) 23:56:48Multiply colors (C = C1 * C2)
Normal 1.7752063 sec
Table 1.2520575 sec
MMX 1.0862872 sec
SSE2 0.5878748 sec
コード見た感じだとSSE2はMMXのただの128bits拡張のようだ
その割にはSSE2速すぎるだろ
実行ファイル用意されてないから何とも言えないけど
0837デフォルトの名無しさん
2010/01/10(日) 02:33:53MMXが遅すぎないか。
0838|ω・`)
2010/01/10(日) 11:24:37脳内でタイム半分にしたんじゃないの
0840デフォルトの名無しさん
2010/01/10(日) 19:51:30だから多分そのタイムであってる
0841デフォルトの名無しさん
2010/01/10(日) 20:01:01Multiply colors (C = C1 * C2)
Normal 1.6820140 sec
Table 1.1875109 sec
MMX 1.0300781 sec
SSE2 0.5574127 sec
0842デフォルトの名無しさん
2010/02/16(火) 11:00:55>>831のような単純な処理でこの程度の速度じゃあ
0843デフォルトの名無しさん
2010/02/16(火) 13:11:15XMMレジスタの大きさの16バイトずつで処理すればもっと速くなるよ。
0844デフォルトの名無しさん
2010/03/03(水) 14:13:07もうpen3以前のcpuは切り捨ててsse2使ってもいい頃かな？
いっそssse3でもいいか
0845デフォルトの名無しさん
2010/03/03(水) 15:18:24アセンブリ言語で書かねばならないような状況でないかぎり。
SSEを使った処理を自分では書かず、コンパイラに最適化オプションを指定してやる程度の
自己満足目的なら、SSSE3使う意味があるとは思えない。
0846デフォルトの名無しさん
2010/03/03(水) 15:34:370847デフォルトの名無しさん
2010/03/03(水) 15:36:010848デフォルトの名無しさん
2010/03/03(水) 16:16:500849デフォルトの名無しさん
2010/03/03(水) 16:28:52それを承知でやるならいいけど、高速化とかならが目的ならgpu(当然2004-6年ごろ以降のPC)に任せるべき。
どうしてもsseがいいならamd64からsse2が最低ラインか。
0850デフォルトの名無しさん
2010/03/03(水) 17:03:350851デフォルトの名無しさん
2010/03/03(水) 20:55:290852デフォルトの名無しさん
2010/03/03(水) 20:58:220853デフォルトの名無しさん
2010/03/03(水) 21:01:260854デフォルトの名無しさん
2010/03/03(水) 21:08:57機能は少ないからといって主ターゲットが32bits osなのにsse2以降も考えてるなら、それほどsseに依存したプログラムであるならそもそもそのようなソフトに汎用性はない考えるといいだろう。
0855,,・´∀｀・,,）っ-○○○
2010/03/03(水) 21:10:43まあ一応拡張命令が使えないCPU向けのパスは用意しておくべきかと。
0856,,・´∀｀・,,）っ-○○○
2010/03/03(水) 21:17:11命令列に対するアラインメントの計算がどこそこおかしい。
0857デフォルトの名無しさん
2010/03/03(水) 21:25:42久々だｗ
お奨めのララビーはバッコンバッコンなっちゃったよね。
sseはずいぶん遠ざかって気が向いたらsseに戻らずopenglの方に行く予定だけど、団子はgpuの方はやらないの？
0858デフォルトの名無しさん
2010/03/03(水) 21:45:41それよりSSE2が使えないくせに息が無駄に長かったAthlonXPをサポートするかどうかだと思うんだ。
0859デフォルトの名無しさん
2010/03/03(水) 21:48:39SSE使わなくても快適に動くならサポートすればいいし、
SSE4.2が無いと重くて仕方が無いのにPen4とかサポートする必要は無い。
0860デフォルトの名無しさん
2010/03/03(水) 21:58:25sseは結局、gpu generic programingが普及してなかった当時のpc向けのアクセラ・ユニットかな。俺の中では。
そのpc当時の性能だと、エンコーダソフトぐらいしかsseの活用は思い浮かばない。
0861844
2010/03/03(水) 22:00:48そんなソフトです
ソフト名は控えさせていただきます
0862デフォルトの名無しさん
2010/03/03(水) 22:04:34ここでいうsseとは、まばたき以下の時間つまり１００マイクロ秒の性能を競う世界。
0863デフォルトの名無しさん
2010/03/03(水) 22:11:570864名無し募集中。。。
2010/03/03(水) 22:17:210865|ω・`)
2010/03/03(水) 22:25:00当たり前のことを指摘してるのが団子しかいない
あとの全員は使うか使わないかという論点で話をしてる
0866デフォルトの名無しさん
2010/03/03(水) 22:27:120867デフォルトの名無しさん
2010/03/03(水) 22:36:27もうSSE2まで使うモード、SSSE3まで使うモード両方実装しておけばいいよ。
起動時にCPUの種類によってどっち使うか決める。
0868844
2010/03/03(水) 22:39:3287fpuとsseで結果が異なると困るんです
ieee準拠で53ビット切り捨て等で技術的には可能なのはわかっているんですが
検証に手間と時間がかかりすぎます
0869デフォルトの名無しさん
2010/03/03(水) 22:42:17え、そんなの当たり前過ぎて言っていないだけなんだが。
0870|ω・`)
2010/03/03(水) 23:26:00そもそも fp って結果がぴったり一致しないと困るものに使うもんじゃないよね
x87 か sse かというだけじゃなく、計算順とかでも変わっちゃうんだよ?
0871デフォルトの名無しさん
2010/03/03(水) 23:40:580872デフォルトの名無しさん
2010/03/04(木) 00:00:120873,,・´∀｀・,,）っ-○○○
2010/03/04(木) 00:06:38動く物をわざわざ動かなくする必要なんて無い
0874,,・´∀｀・,,）っ-○○○
2010/03/04(木) 00:08:20pshufb使って仮数部の切り捨てとか？
0875|ω・`)
2010/03/04(木) 00:37:02最新ハード通り越して未発売ハードしかサポートしませんみたいな勢いの新製品厨だったのに
0876デフォルトの名無しさん
2010/03/04(木) 01:31:34おたくの認識が間違ってただけなんじゃね？
0877デフォルトの名無しさん
2010/03/04(木) 01:50:49ワロタｗ
0878デフォルトの名無しさん
2010/03/04(木) 06:59:36自演するなら名無しの方がいいですよ
0879デフォルトの名無しさん
2010/03/04(木) 21:10:38SIMD対応のテンプレート行列ライブラリ作れや
対応はSSE2まででいいや
サイズは4x4 matrixまででいいや
逆行列は必ずいれろ
はやくしろカス
0880デフォルトの名無しさん
2010/03/04(木) 21:12:58オール組み込み関数にしろ
プリフェチ使え
サンプルで、速度比較出来るベンチつけろ
当然フリーだ
さっさとやれクズ
0881デフォルトの名無しさん
2010/03/04(木) 21:33:160882デフォルトの名無しさん
2010/03/04(木) 21:37:12お前が自作ライブラリによるベンチ結果でもUPしたら
話を聞いてやってもいいよ
ちなみにライブラリはC++版なら持ってるよ
SIMD版は優先順位が低いから・・
0883デフォルトの名無しさん
2010/03/04(木) 21:40:16つ_MM_TRANSPOSE4_PS
0884デフォルトの名無しさん
2010/03/04(木) 21:44:090885デフォルトの名無しさん
2010/03/04(木) 21:46:02？
逆行列に？
0886デフォルトの名無しさん
2010/03/04(木) 21:48:170887デフォルトの名無しさん
2010/03/04(木) 21:54:13Intel様やSONY様は
4倍速くなると豪語してたし
0888デフォルトの名無しさん
2010/03/04(木) 21:55:19C++なんてJava並に遅いものを使ってる時点で諦めろカス
0889デフォルトの名無しさん
2010/03/04(木) 23:09:45無茶言わんでくれ
0890,,・´∀｀・,,）っ-○○○
2010/03/04(木) 23:13:15いやーん＞＜
0891,,・´∀｀・,,）っ-○○○
2010/03/04(木) 23:31:10たとえばHogeって関数を古いCPUから新しいCPUの機能までフルに使えるようにするのって
HogeC
HogeMMX
HogeSSE
HogeSSE2
HogeSSSE3
HogeSSE41
HogeAVX
みたいな感じでカーネルコードをCPU機能レベル毎に作っておいて
初期化するときに関数ポインタセットするだけだろ
C++がJavaなみに遅いとか言ってる奴は仮想関数とかRTTIとか使ってる法則。
もしくはSTLのアロケータも自作しない。
てかベターCとして使うなら十分C++は速いよ
0892デフォルトの名無しさん
2010/03/04(木) 23:40:100893デフォルトの名無しさん
2010/03/05(金) 10:51:25でも仮想関数くらいは使わせでくだしあ
0894デフォルトの名無しさん
2010/03/05(金) 11:26:480895デフォルトの名無しさん
2010/03/05(金) 21:18:21JavaはC++より遅いだろjk
0896デフォルトの名無しさん
2010/03/05(金) 21:48:55仮想関数を使っても速度は低下しない
CふくめRTTIを自前実装でやろうとするなら
やはり同じように速度は低下する
言語が悪いのではなく、プログラマが悪い
みたいなことを誰かが言ってたような
まあ最適化の話ならrestrictとかファンクタとか・・・
0897デフォルトの名無しさん
2010/03/14(日) 21:26:23{
do{
unsigned char *d = (unsigned char *) dst++;
unsigned char *s = (unsigned char *) src++;
d[0] = d[1] = d[2] = s[0]/4 + s[1]/2 + s[2]/8;
}while(--siz);
}
↑をSIMD化で早くしてください。
0898デフォルトの名無しさん
2010/03/15(月) 00:04:35CPUを言えよw
x86ならこのままが一番良さそうな気がする。
どうしてもSIMD化したければ単精度に変換して逆数掛けるのが近道じゃね?
MMX/SSE2は糞だからエレメント毎に別のシフト量って命令は無い。
と、これ系のスレで毎度だだをこねている無い物ねだりのレスは俺です。
0899デフォルトの名無しさん
2010/03/15(月) 00:40:39(s[0]*3+s[1]*5+s[2])/8
じゃないのか?
0900デフォルトの名無しさん
2010/03/15(月) 01:00:19よーわからんフィルタだな。
mov ecx, siz;
mov esi, src;
mov edi, dst;
sub ecx, 4;
add edi, 2;
sar ecx, 2;
cmp ecx, 0;
jle TAIL;
LAST:
movq mm0, [esi+0];
movq mm1, [esi+1];
movq mm2, [esi+2];
add esi, 8;
psrab mm0, 2;
psrab mm1, 1;
psrab mm2, 3;
paddb mm0, mm1;
paddb mm0, mm2;
movq [edi], mm0;
add edi, 8;
dec ecx;
test ecx, ecx;
jnz HEAD;
TAIL:
先頭の 2 画素と末尾 2 画素 + 端数はPlain Cで作るように。
テストしてないので、動くかどうかは知らない。
0901デフォルトの名無しさん
2010/03/15(月) 01:03:27sar ecx 2; は sar ecx 3; の間違い
あと、
LAST: も HEAD: の間違い。
0902デフォルトの名無しさん
2010/03/15(月) 01:10:19>void proc(unsigned int *dst, unsigned int *src, int siz)
>{
> do{
> unsigned char *d = (unsigned char *) dst++;
> unsigned char *s = (unsigned char *) src++;
> d[0] = d[1] = d[2] = s[0]/4 + s[1]/2 + s[2]/8;
> }while(--siz);
>}
このd[1], d[2]は次のイテレーションで上書きされるけど
意図した記述なの？
0903デフォルトの名無しさん
2010/03/15(月) 06:03:00> CPUを言えよw
とりあえずCore Duoでお願いします。
>>899
適当にそれっぽい色になる数にしてみました。
公式がちゃんとあるんですね。
>>900
どうも想定してるのとは違うっぽい動作をするようです。
>>902
4バイトずつ加算されてくので上書きされないと思います。
0904898
2010/03/15(月) 14:24:56仕事ならライブラリを買いましょう。
人件費からすれば微々たる金額です。
趣味なら>>898をヒントに自分で頑張りましょう。
分からない所があったら書きかけのコードを添えてまた質問して下さい。
趣味だけどSIMDには興味がねーんだよボケと言うのなら>>897のままで結構です。
いやマジで。
演算量が少な過ぎてメモリアクセスの遅さを隠蔽出来ません。
0906デフォルトの名無しさん
2010/03/15(月) 16:42:400908デフォルトの名無しさん
2010/03/15(月) 19:16:56SIMD化すれば簡単に2〜4倍高速化できると聞いて期待してたのですが、難しいですか。
わかりました。自分で頑張ってみます。
>>905
prefetchってよくわからないんです。
_mm_prefetch(src, _MM_HINT_NTA);
d[0] = d[1] = d[2] = s[0]/4 + s[1]/2 + s[2]/8;
これって無駄になりますよね？
_mm_prefetch(src+16, _MM_HINT_NTA);
d[0] = d[1] = d[2] = s[0]/4 + s[1]/2 + s[2]/8;
↑この場合ってprefetch命令で確保した分はs[0]へアクセスして自動的に引っ張ってきた分で
押し流されて無かったことになったりしませんか？
0909898
2010/03/15(月) 19:28:57効くよ。
>>908
単精度にせず愚直にSIMD化してみたけど10%速くなっただけ。(Core 2 Duo Merom)
prefetchはsrc+16なんて近くじゃなくてもっと遠くを指定した方が良い。
でもハードウェアプリフェッチが効くので殆ど意味はない。
あと、L2キャッシュにロードするんだから1MB以上はあるわけで、そうそう簡単には押し流されない。
mov edi, dst
mov esi, src
mov ecx, siz
BEGIN_:
prefetchnta [esi+512]
mov eax, [esi]
mov dl, [esi+2]
shr al, 2
shr dl, 3
shr ah, 1
add al, dl
add al, ah
mov bl, al
mov ah, al
shl ebx, 16
mov bx, ax
movnti [edi], ebx
add esi, 4
add edi, 4
dec ecx
jnz BEGIN_
sfence
多分こんな感じ。
0911デフォルトの名無しさん
2010/03/16(火) 10:42:540912,,・´∀｀・,,）っ-○○○
2010/03/16(火) 13:33:000913デフォルトの名無しさん
2010/03/16(火) 17:13:36むしろ痒いところに手が届くよう、様々な種類の孫の手を用意した結果が今の86爺さん。
最近じゃ孫の手の改良に飽き足らず、人体改造で腕を6本生やし更に、一つの腕で孫の手を2本同時に使えるようにしちまったよ。
0914デフォルトの名無しさん
2010/03/16(火) 17:23:12もうそれは奇形児と言っていいな
そういうCPUが主流なのも不思議だが
便利な事は便利だ
0915|ω・`)
2010/03/16(火) 17:56:020917|ω・`)
2010/03/17(水) 01:09:35siz=1024
9.01 c
4.62 asm
4.52 mmx2
2.92 ssse3
siz=65536
9.01 c
4.78 asm
3.89 mmx2
2.28 ssse3
siz=4194304
9.82 c
7.47 asm
5.07 mmx2
4.80 ssse3
単位はcycle/siz
pmaddubsw って知らなかったんで使ってないけど、後でやってみよう
0918デフォルトの名無しさん
2010/03/17(水) 01:26:45一回に1キャッシュライン分だから、たとえば、Float A[10000]という配列があって、最初にA[0]をアクセスしたら、
A[0]〜A[16]までキャッシュにたまって、ちょっとしたらA[64]〜A[80]までがキャッシュされている。
それを繰り返して、A[960]以降をアクセスしたら、その256バイト先は4KBをまたぐので、
ハードウェアプリフェッチは機能しない。ということだよね？
つまりソフトウェアプリフェッチを入入れるときは、遠くの方のアドレスを指定しておくのが有効だけど、
この例でA[960]、A[976]、A[992]、A[1008] あたりをプリフェッチで指定しておけばしてより効果的になるのかな？
0919デフォルトの名無しさん
2010/03/17(水) 02:08:470920,,・´∀｀・,,）っ-○○○
2010/03/17(水) 03:30:51コード希望
0921898
2010/03/17(水) 08:38:57917は団子じゃねーのかw
Cと他に差があり過ぎるしpmaddubswを知らないってどういうことかと思った。
917のcycle/sizってのはtotal clock÷sizでいいのか？
まるで全部キャッシュに入っているかのようなスピードなんだが。
0922デフォルトの名無しさん
2010/03/17(水) 17:29:46mulとhadd使ったほうが早いんだけど使い方が悪いんかな？
0923デフォルトの名無しさん
2010/03/18(木) 00:54:27codepadのgccがintrinsicsを持ってないようだからgccでコンパイルしてDにポートした。
alignがバグっていて無駄な時間を過ごしてしまった。
proc0は純粋な実装で参考程度。codepadだと遅いけど手元の測定では他と大きな違いはない。
それとDがSSSE3に対応していないようなのでコメントアウトしてある。これも手元の測定では他と然程変わらない。
最適化の余地は残っていると思うものの、時間が劇的に変わるとは思えない。
proc2, proc3はproc0とは計算方法が違うのでproc0とは異なる結果を出す事がある。
0924,,・´∀｀・,,）っ-○○○
2010/03/18(木) 01:26:23だってさ、内部的に、乗算＋シャッフル×２＋加算＋シャッフル×２＋加算
に分解して実行してるだけだぜ？
適度に他のSimple Decoder Pathの命令と混ぜて配置すればスループット改善するかも
0925,,・´∀｀・,,）っ-○○○
2010/03/18(木) 01:38:07void proc3(unsigned int *dst, unsigned int *src, int siz)
だけど
> __m128i vSum = _mm_srli_epi32(_mm_add_epi32(vABS, vGRS), 8);
> __m128i vDst = _mm_shuffle_epi8(vSum, vSplat);
ここ8ビットシフトする必要なくね？
これでおｋ
__m128i vSplat = _mm_set_epi8(
0xff, 13, 13, 13,
0xff, 9, 9, 9,
0xff, 5, 5, 5,
0xff, 1, 1, 1);
あともう少し改善できるところがあるけどそもそもメモリネックだとか言う人が言うので
これ以上は突っ込まない
ヒント：pandはどのポートでも発行出来る
0926デフォルトの名無しさん
2010/03/18(木) 02:15:24速度以前にグレイスケールの変換式として問題があるだろ
0927デフォルトの名無しさん
2010/03/18(木) 02:18:43／／／）
／,.=ﾞ''"／
／ i f ,.r='"-‐'つ＿＿＿_
/ / _,.-‐'~／⌒ ⌒＼
／ ,i ,二ﾆ⊃（ ●）. （●）＼
/ ﾉ ilﾞフ::::::⌒（__人__）⌒::::: ＼
,ｲ｢ﾄ､ ,!,!| |r┬-| |
/ iﾄヾヽ_/ｨ"＼ `ー'´ ／
0928,,・´∀｀・,,）っ-○○○
2010/03/18(木) 02:20:11Y = ( 2 * R + 4 * G + B ) / 7で近似ならわかるけど8で割る意味が不明
正しい式は
Y = ( 0.298912 * R + 0.586611 * G + 0.114478 * B )
0929デフォルトの名無しさん
2010/03/18(木) 02:32:130930デフォルトの名無しさん
2010/03/18(木) 04:18:050931デフォルトの名無しさん
2010/03/18(木) 04:43:23これ256倍しとけ
0932デフォルトの名無しさん
2010/03/18(木) 08:00:20え、Complex Decoder Pathを並べるとパイプライン詰まるの?
OoOしてくれるかと思ってた。
シフトはいらないね。
andはどこで使うんだろう。
>>931
うん、897に合わせて書いているけど931がすぐ発想し易いようにしてある。
本質的にはどれ使っても大した違いはないという事が言いたかっただけだから。
0933デフォルトの名無しさん
2010/03/18(木) 08:17:34自分で書いてみましたが、SSE使っても最初のと速度変わらないままでした。
0934デフォルトの名無しさん
2010/03/18(木) 08:21:240935,,・´∀｀・,,）っ-○○○
2010/03/18(木) 09:11:00アウトオブオーダなのはデコード後であってデコーダの解釈は並べた順。
0936|ω・`)
2010/03/18(木) 10:05:49いや使い物にならないと思う
rgb 255 入れたとき w 221にしかならないじゃん
じゃ俺も貼るか、ループの中だけでいいよね
0937デフォルトの名無しさん
2010/03/18(木) 10:53:15> rgb 255 入れたとき w 221にしかならないじゃん
え？それに何か問題でも？
0938デフォルトの名無しさん
2010/03/18(木) 14:15:080939デフォルトの名無しさん
2010/03/18(木) 16:30:300940|ω・`)
2010/03/18(木) 21:08:00; asm
; edi=dst+siz*4, esi=src+siz*4, ecx=-siz*4
.lp:
mov al, [esi+ecx]
mov bl, [esi+ecx+1]
mov dl, [esi+ecx+2]
shr al, 2
shr bl, 1
add al, bl
shr dl, 3
add al, dl
mov [edi+ecx], al
mov [edi+ecx+1], al
mov [edi+ecx+2], al
add ecx, 4
jnz .lp
0941|ω・`)
2010/03/18(木) 21:10:00movq mm1, [eax+ecx]
movq mm2, mm1
punpcklbw mm1, mm0
punpckhbw mm2, mm0
%ifdef accurate
pmaddwd mm1, mm7
pmaddwd mm2, mm7
pshufw mm4, mm1, 0b11111110
pshufw mm5, mm2, 0b11111110
paddw mm1, mm4
paddw mm2, mm5
pshufw mm1, mm1, 0b11000000
pshufw mm2, mm2, 0b11000000
psrlw mm1, 8
psrlw mm2, 8
%else
pmulhuw mm1, mm7
pmulhuw mm2, mm7
pshufw mm4, mm1, 0b11001001
pshufw mm5, mm2, 0b11001001
paddw mm4, mm1
paddw mm5, mm2
pshufw mm1, mm1, 0b11010010
pshufw mm2, mm2, 0b11010010
paddw mm1, mm4
paddw mm2, mm5
%endif
packuswb mm1, mm2
movntq [edx+ecx], mm1
add ecx, 8
jnz .lp
0942|ω・`)
2010/03/18(木) 21:11:00; edx=dst+siz*4, eax=src+siz*4, ecx=-siz*4, xmm0=zero, xmm6=shuffle, xmm7=factor
.lp:
movdqa xmm1, [eax+ecx]
movdqa xmm2, xmm1
punpcklbw xmm1, xmm0
punpckhbw xmm2, xmm0
%ifdef accurate
pmaddwd xmm1, xmm7
pmaddwd xmm2, xmm7
phaddd xmm1, xmm2
%else
pmulhuw xmm1, xmm7
pmulhuw xmm2, xmm7
phaddw xmm1, xmm2
phaddw xmm1, xmm2
%endif
pshufb xmm1, xmm6
movntdq [edx+ecx], xmm1
add ecx, 16
jnz .lp
0943|ω・`)
2010/03/18(木) 21:12:00; edx=dst+siz*4, eax=src+siz*4, ecx=-siz*4, xmm5=mask, xmm6=shuffle, xmm7=factor
.lp:
movdqa xmm1, [ecx+eax]
%ifdef accurate
movdqa xmm2, xmm1
pand xmm2, xmm5
%else
pand xmm1, xmm5
%endif
pmaddubsw xmm1, xmm7
%ifdef accurate
paddw xmm1, xmm1
paddw xmm1, xmm2
%else
psrlw xmm1, 3
%endif
phaddw xmm1, xmm1
pshufb xmm1, xmm6
movntdq [ecx+edx], xmm1
add ecx, byte 16
jnz .lp
0944|ω・`)
2010/03/18(木) 21:13:00%ifdef accurate
qFactorW:
dqFactorW:
dw 77,150,29,0,77,150,29,0
dqShufB:
db 1,1,1,255,3,3,3,255,5,5,5,255,7,7,7,255
dqShufB159d:
db 1,1,1,255,5,5,5,255,9,9,9,255,13,13,13,255
dqFactorB:
db 38,75,14,0,38,75,14,0,38,75,14,0,38,75,14,0
dqMaskB:
db 0ffh,0,0ffh,0,0ffh,0,0ffh,0,0ffh,0,0ffh,0,0ffh,0,0ffh,0,
%else
qFactorW:
dqFactorW:
dw 16384,32768,8192,0,16384,32768,8192,0
dqShufB:
db 0,0,0,255,2,2,2,255,4,4,4,255,6,6,6,255
dqFactorB:
db 2,4,1,0,2,4,1,0,2,4,1,0,2,4,1,0
dqMaskB:
db 0fch,0feh,0f8h,0,0fch,0feh,0f8h,0,0fch,0feh,0f8h,0,0fch,0feh,0f8h,0
%endif
0945デフォルトの名無しさん
2010/03/18(木) 21:48:44ssse3(>>942)の!accurateを試してみたけど>>917みたいな大きな差が現れないどころか、純粋なCのプログラムより若干遅いんだけど。
0946|ω・`)
2010/03/18(木) 21:57:34なんか間違ってるんじゃない
あと実は917のときより全部ちょっと速くなってる
siz=1024 65536 4194304
// 45nm shift
4.08 4.44 7.50 gcc4
4.02 4.38 7.43 asm
3.98 3.87 5.08 mmx2
2.37 2.26 4.80 ssse3
2.36 2.27 4.78 ssse3_2 (pmaddubsw)
// 65nm shift
4.02 4.44 5.77 asm
4.39 3.89 4.55 mmx2
3.94 3.29 4.46 ssse3
2.66 2.19 4.44 ssse3_2 (pmaddubsw)
// 45nm accurate
4.73 4.90 7.35 asm
3.94 3.84 5.08 mmx2
2.36 2.26 4.80 ssse3
2.36 2.26 4.81 ssse3_2 (pmaddubsw)
// 65nm accurate
4.82 4.93 6.08 asm
4.36 3.78 4.57 mmx2
2.82 2.34 4.49 ssse3
2.77 2.26 4.43 ssse3_2 (pmaddubsw)
gcc4 は -mtuneを pentium-m 以前にしたら途端にまともなコードを吐くようになった
0947|ω・`)
2010/03/19(金) 00:28:20なら 65nm で L1 の中なら肉薄されるね
L1 内でループ回したら負けるかも
そういうセットアップだと、まず movnt を普通の mov にして
それから phadd とか pshufb とかバラすといいのかな? 団子が詳しそうだけど
0948,,・´∀｀・,,）っ-○○○
2010/03/19(金) 01:16:42ビットマスクしてpsadbw(乗算扱い)した方が速いよ。精度はさておき。
0949,,・´∀｀・,,）っ-○○○
2010/03/19(金) 01:32:58pmaddubswの第2引数
__m128i vGSMultipler1 = _mm_set_epi8(
ScaleR, ScaleG, ScaleB, 0,
ScaleR, ScaleG, ScaleB, 0,
ScaleR, ScaleG, ScaleB, 0,
ScaleR, ScaleG, ScaleB, 0
);
pmaddwdの第2引数
__m128i vGSMultipler2 = _mm_set_epi16(1, 1, 1, 1, 1, 1, 1, 1);
pshufbの第2引数
__m128i vSplat = _mm_set_epi8(
0xff, 15, 15, 15,
0xff, 11, 11, 11,
0xff, 7, 7, 7,
0xff, 3, 3, 3);
0950,,・´∀｀・,,）っ-○○○
2010/03/19(金) 01:43:22どうせ乗算ネックなら精度的にはR, BとG, 0に分けてpmaddwdの方が良いと思う。
0951デフォルトの名無しさん
2010/03/19(金) 14:41:13ScaleGを分割して精度を1bit稼ぐのはどうだ
0952|ω・`)
2010/03/19(金) 18:09:31ていうか手元の最新コードではそうなってた
でもさすがにバイトの和は使えないと思う
> 精度を1bit稼ぐ
お、気づいてくれた?
0953951
2010/03/20(土) 04:52:11ScaleGの精度だけ上げて
pmaddwd時に小数点の位置を合わせたほうがいのか
0954デフォルトの名無しさん
2010/03/20(土) 05:54:02複数のコアを使ったら殆ど変わらなくなった時って悲しくならねぇ？
0955,,・´∀｀・,,）っ-○○○
2010/03/20(土) 07:10:28ただ、メモリ帯域取らない別のワーカースレッドを並列稼働させればいいし
4コア分の仕事を1コアで賄えるなら結果省エネになる。
0956デフォルトの名無しさん
2010/03/20(土) 10:12:00マルチスレッドにしなきゃいかんし、4コアで別々にSSE使えるからもっと速くなるから
無駄ではないだろ
0957,,・´∀｀・,,）っ-○○○
2010/03/20(土) 10:21:39共有キャッシュ上のデータをうまく使い回してDRAM帯域をセーブするテクニックが必要になるし
なおかつそういう用途でしか使い物にならない。
0959デフォルトの名無しさん
2010/03/20(土) 16:22:28正確にはSIMDに合わせて、SISDのコードをSIMDに加工するのが無駄。
たまたま無理なくSIMDに出来るコードがあったらやる程度で十分。
0960デフォルトの名無しさん
2010/03/20(土) 16:51:41そう出なければ単なる負け惜しみ。
けど、SIMDを極めた人は最初からSIMDを意識して設計するんでない？
0961デフォルトの名無しさん
2010/03/20(土) 17:05:260962,,・´∀｀・,,）っ-○○○
2010/03/20(土) 17:14:540963デフォルトの名無しさん
2010/03/20(土) 19:02:59_mm_xxx_yyyの形で書く人がいないんだろ
知り合いとかもみんな基本はC使ってるくせにアセンブラ使いたがるよね
まあ単に俺がアセンブラ嫌いなだけなんだけど
0964デフォルトの名無しさん
2010/03/20(土) 19:37:180965|ω・`)
2010/03/20(土) 20:11:28pmaddubsw は片方符号付で7bit精度しかないんだけど
943ではちょっと工夫して他と結果そろえてる
実は速度とかよりここがメインだったんだけどなぁ
こだわらないなら団子の言う3命令だけでもできると思うけど
ただ>>949は引数全部違うよね
0966,,・´∀｀・,,）っ-○○○
2010/03/20(土) 22:27:22たまにアセンブラすら信用できないこともあるけどな、特にNで始まるあれは。
致命的なバグ大杉。
>>965
ごめん書いてから気づいたけど誰も突っ込まないから放置してた。
本当はYASM使いだけど、Cコードはかなりテキトーに書いた。引数順序とかテキトー
x86->x64, SSE->AVXの移行考えるならIntrinsics形式の方が楽だと思う。
0967デフォルトの名無しさん
2010/03/21(日) 02:11:47Cコンパイラがメモリ参照するコードばかり吐き出しよるとです。
0968デフォルトの名無しさん
2010/03/21(日) 02:47:180969デフォルトの名無しさん
2010/03/21(日) 03:19:14>>943で精度を1bit稼いでるのは気づいていなかった
>>943は
((77*R + 150*G) + 29*B)
を
((38*R + 75*G) + 14*B)*2 +R +B
に変形しているけど
>>951で書いたのはこの変形
(77*R+51*G) + (29*B+99*G)
0970|ω・`)
2010/03/21(日) 04:49:38なるほどねえ、そっちは俺が気づいてなかった
幅いっぱい使いきってるのが美しい
45nm 以降なら shufb 一発で済んで3命令得だし
65nm だと uop 数変わんないけど遅くはならないはず
そっちの方が断然いい
0971デフォルトの名無しさん
2010/03/21(日) 23:31:090972デフォルトの名無しさん
2010/03/22(月) 20:27:46もう3D Now!は要らないんじゃない？
0973デフォルトの名無しさん
2010/03/22(月) 23:15:53まあ、全体としてはマイノリティだけどな。
0974デフォルトの名無しさん
2010/03/23(火) 00:51:27メモリ帯域に対してSSEの処理が速すぎるんだよね。
しかもハードウェアプリフェッチが機能するようになってから、
余計メモリ帯域を消費するようになった。
メモリ転送レイテンシ以下で32bitや64bit変数を圧縮、展開を出来るアルゴリズムはないのかな？
多少圧縮展開で時間がかかっても並列化によって計算時間は相対的に下がるから、
メモリ帯域をセーブ出来ると思うんだけどな。
そんなにあまくないか。
0975デフォルトの名無しさん
2010/03/23(火) 01:21:37レイテンシー増えるけど著作権のためよ♪ｂｙ利権団体
0976デフォルトの名無しさん
2010/03/23(火) 02:32:21メモリ毎に保証料払えと。
ただPCIExpressとかは輻射の低減ため、
スクランブルが掛かっているけどね。
0977デフォルトの名無しさん
2010/03/23(火) 12:44:470978,,・´∀｀・,,）っ-○○○
2010/03/31(水) 16:07:12次の6年に備えて「SSE AVX XOP」でおｋ
0979デフォルトの名無しさん
2010/04/01(木) 21:52:121.パイプラインの使用率を見る方法
2.どの程度まで使用率を上げられるものか
教えてくだされ
0980デフォルトの名無しさん
2010/05/24(月) 14:01:42(´・ω・`) うさちゃんピース
0981デフォルトの名無しさん
2010/05/25(火) 02:28:13マザボの大半は著作権フリーの台湾で作っているのでまずあり得ない
レス数が950を超えています。1000を超えると書き込みができなくなります。