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

1 名前：デフォルトの名無しさん [04/05/28 22:00] どうぞ 95 名前：デフォルトの名無しさん mailto:sage [2006/02/07(火) 10:21:34 ] xor ecx,ecx lp0: movq mm0,[esi+ecx] movq mm1,mm0 punpcklbw mm0,mm7 punpckhbw mm1,mm7 pmullw mm0,[eax+ecx*2] pmullw mm1,[eax+ecx*2+8] movq mm2,[esi+ecx+3] movq mm3,mm2 punpcklbw mm2,mm7 punpckhbw mm3,mm7 pmullw mm2,[eax+ecx*2+48] pmullw mm3,[eax+ecx*2+48+8] paddw mm0,mm2 paddw mm1,mm3 paddw mm0,mm5 paddw mm1,mm5 pmulhw mm0,mm6 pmulhw mm1,mm6 packuswb mm0,mm1 movq [edi+ecx],mm0 add ecx,8 cmp ecx,24 jnz lp0 add esi,27 add edi,24 ;MMXでバイリニアてのはどうやるの？ 96 名前：デフォルトの名無しさん mailto:sage [2006/02/09(木) 09:45:01 ] >>90 変数の中身へのポインタを取得するとアセンブリでは lea eax,[esp-12] のようになるから、movは使えないのだね。 int *a;ならmov eax,aできても、int a[4];だとmov eax,aで氏んだからな。 あのときはけっこう悩んだ。 97 名前：デフォルトの名無しさん mailto:sage [2006/02/11(土) 09:08:17 ] SIMDで計算したいブロックを高級言語で明示できないかな。 たとえば、C言語風の妄想言語... struct complex_t {     float r, i; }; foo() {     complex c[4];     VEC( float re : [ c[0].r, c[1].r, c[2].r, c[3].r ], float im : [ c[0].i, c[1].i, c[2].i, c[3].i ] ) {         float t = re * re - im * im;         im = 2 * re * im;         re = t;     } とか書くと、VECブロックの中が自動的にSIMD命令で構成される。 ( SIMD未対応のCPU向けのときは、通常の命令になる ) SIMDで実行するのだから、VECブロック中には分岐はかけず、 ループも固定回数ループだけ。 どう？この妄想言語。 98 名前：デフォルトの名無しさん mailto:sage [2006/02/11(土) 11:51:13 ] １つの構造体がメモリ上でバラバラになってるな。 それはいいとして、組み込み関数と演算子オーバーロードでよくない？ ただ、俺もそういう言語は欲しいと思っていた。 せっかくCPUに色々な命令があるんだから、命令が見える言語がいいよね。 そういう意味じゃCのシフト演算子とかナイスと思った。 99 名前：デフォルトの名無しさん mailto:sage [2006/02/11(土) 19:29:54 ] Intrinsics使えばｲﾝｼﾞｬﾈ? 最終段で機械任せの最適化するなら、 そのままCでも構わないと思うけど。 100 名前：デフォルトの名無しさん mailto:sage [2006/02/17(金) 21:01:05 ] 8bitビットマップ(グレースケール)から32bitビットマップへの変換を、MMX使って 実装しようとしているのですが、思っていたよりも早くならずに難渋しています。 　適当なやり方しているのは自覚しているのですが、同じく適当にＣで書いたルーチン と、リリース版の最適化コミで速度変わらずってのはかなり凹みました。 　どこかもっと最適化する場所があるのでしょうか？　ご存じの方ご教授願います。 void testcopy( void *dst, const void *src, int size ) { 　　int size2 = size >> 1; 　　if(size2 != 0){ 　　　　__asm{ 　　　　　　mov edi, dst; 　　　　　　mov esi, src; 　　　　　　mov ecx, size2; 　　　　loop_mp: 　　　　　　movq mm0, [esi]; 　　　　　　punpcklbw mm0, mm0; 　　　　　　punpcklbw mm0, mm0; 　　　　　　movq [edi], mm0; 　　　　　　lea esi, [esi + 2]; 　　　　　　lea edi, [edi + 8]; 　　　　　　dec ecx; 　　　　　　jnz loop_mp; 　　　　　　emms; 　　　　} 　　} } 101 名前：デフォルトの名無しさん mailto:sage [2006/02/17(金) 21:20:54 ] >>100 使用CPUは何？ lea esi, [esi + 2] はadd esi,2 のが無難だと思う。Pen4ならaddのが速い。 movqは8byteだから最後の2byte読むときに6byte余計に読んでしまうのが気持ち悪い。 速度の面からも、読み取りを2byte毎じゃなく4byteか8byteにするべき。 MMX2が使えるならpshufwを使ってもいいかな。 movd mm0, [esi]; punpcklbw mm0, mm0; movq mm1,mm0 punpcklbw mm0, mm0; punpckhbw mm1, mm1; movq [edi], mm0; movq [edi], mm1; add esi,4; add edi,16; sub ecx,2; jnz loop_mp; 即興で作って試してないけど、こんなのでどうでしょ。 102 名前：100 mailto:sage [2006/02/17(金) 21:25:43 ] >101 >使用CPUは何？ 　書き忘れていました。CPUはPen4ですが、諸事情(VC6sp6開発)のため MMXまでの制限になってます。 103 名前：デフォルトの名無しさん mailto:sage [2006/02/17(金) 21:39:40 ] そういえば、これ処理が軽いからメモリ速度がボトルネックになるね。 おそらくCで書いたルーチンでもメモリ帯域を使い切っているに近いと思う。 ありえん話だが、メモリがL1キャッシュくらい速い環境ならば >>100氏はCコンパイラに大勝していただろう。 あと、このように毎回実行する余計な処理が4命令もあるので、 ループをアンロールすれば少し速くなると思う。 lea esi, [esi + 2]; lea edi, [edi + 8]; dec ecx; jnz loop_mp; >>102 SP6か。それは残念。後でnasmでも使ってみてください。 Pen4だとALUが速くてMMXが遅いからな。 104 名前：デフォルトの名無しさん mailto:sage [2006/02/17(金) 22:15:40 ] 画像処理はメモリのアクセス速度がボトルネックだよな〜 105 名前：デフォルトの名無しさん mailto:sage [2006/02/17(金) 22:30:45 ] Microsoft Visual C++ Toolkit 2003 ttp://msdn.microsoft.com/visualc/vctoolkit2003/ 106 名前：デフォルトの名無しさん mailto:sage [2006/02/17(金) 23:09:57 ] SSEが使えればprefetchがあるんだけどなぁ。 107 名前：100 mailto:sage [2006/02/18(土) 10:01:35 ] 　いろいろと助言ありがとうございます。参考にしていろいろ試してみます。 >>103 >後でnasmでも使ってみてください。 　個人で試す分には思いっきりやってみたいところなのですが、 そこまですると引き継ぎが出来なくなって（略）な事になるので…… 108 名前：デフォルトの名無しさん [2006/02/18(土) 18:14:08 ] いまどきアーキテクチャー依存のアクセラレータなど流行らん 109 名前：デフォルトの名無しさん [2006/02/18(土) 20:32:13 ] >>97 ivec.h fvec.h dvec.h をインクルード 110 名前：デフォルトの名無しさん mailto:sage [2006/02/18(土) 23:38:01 ] >>109 そういったクラスライブラリじゃなくて言語の拡張仕様に 埋め込んで欲しいって言ってんじゃないの？ 111 名前：デフォルトの名無しさん mailto:sage [2006/02/19(日) 00:03:31 ] >>110 そんなことは言ってない 112 名前：デフォルトの名無しさん mailto:sage [2006/02/19(日) 00:40:17 ] 俺も妄想言語は考えてるよ。つーかみんな一度は考えてるんじゃないかなぁ multivalue< float, 3 > m0( 1.0f, 2.0f, 3.0f), m1( 5.0f, 5.0f, 4.0f), m2; simd foreach( float v0 in m0, float v1 in m1, float r0 in m2) { float t = v0 * v0 + v1 * v1;  if( t > 0.9f) r0 = t; else r0 = 0.0f; } 分岐は、通るブロックは全て実行して最後論理積って形になるかなぁ。 誰か作って、C++へのコンバータでいいからさ。 113 名前：・∀・）っ-○●◎- ◆Pu/ODYSSEY mailto:sage [2006/02/19(日) 02:01:05 ] どうみてもivec.h/fvec.h/dvec.hの使い方慣れたほうが楽です F32vec4 m0(1.0f, 2.0f, 3.0f, 0.0f); F32vec4 m1(5.0f, 4.0f, 4.0f, 0.0f); F32vec4 m2 = m0 * m0 + m1 * m1; m2 = select_gt(m2, F32vec4(0.9f, 0.9f, 0.9f, 0.9f), m2, F32vec4(0.0f, 0.0f, 0.0f, 0.0f)); 114 名前：・∀・）っ[http://www.coins-project.org/] ◆Pu/ODYSSEY mailto:sage [2006/02/19(日) 02:15:47 ] ここが実現してくれるの待ちましょう。どうも税金の無駄遣い臭いのだが。 115 名前：デフォルトの名無しさん mailto:sage [2006/02/19(日) 02:28:09 ] そういや ・データ読み込み ・同アドレスにデータ書き込み を行った場合、このデータ書き込みの際にmovntiとか使っても全然 早くならないんだけれども、これって対象アドレスに既にデータが入っている 場合、非テンポラル指定はキャッシュ汚染を防ぐためにやるんだから キャッシュに入っていては意味が無いって事だよな？ 116 名前：デフォルトの名無しさん mailto:sage [2006/02/20(月) 13:33:53 ] >100 vcpp5解凍してml.*をコピーすればSSE2命令くらいまで使えたはず、 ってか俺はVC6SP6で使えてる。 もしくは、VC6インスコ→SP5→vcpp5→SP6でもいけた希ガス。 117 名前：デフォルトの名無しさん mailto:sage [2006/02/20(月) 13:37:05 ] 434 名前：・∀・）っ-○●◎- ◆Pu/ODYSSEY 投稿日：2006/01/11(水) 00:05:58 論破されてやがるざまぁｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ 118 名前：デフォルトの名無しさん mailto:sage [2006/02/20(月) 14:09:47 ] >>115 意味ないね。その場合ってロードをプリフェッチすれば ピーク性能を引き出せるのかな？ 119 名前：100 mailto:sage [2006/02/20(月) 20:02:21 ] 金曜日にお世話になりました>100 です。 >101 殿のアドバイスを元に、改良版を作成して実験したところ、試行１回あたり 0.01msほど早くなりました（笑 ＃640×480サイズ、1万回試行の平均。 MMXレジスタ８本全部使って１６ピクセル分１ループで処理するサンプルも実験 してみましたが（ループ回数削減を企図）、やはりほとんど変わりませんでした。 　処理画像サイズを大きくしても、0.1msほどの違いしか出ないことを考えると、 「メモリ速度がネックになる」という>103、>104 殿の指摘にハマっていそうです。 　他の作業指示が飛んできたので、現状でこれ以上の追求は出来なくなって しまいましたが、メモリ速度や最適化の意義などについて深く考える良い機会に なりました。折を見てまたいろいろ試してみたいと思います。 >116 殿 　かなりそれは魅力的な手段ですが……引き継いだ後に環境再構築できる人間が（ｒｙ 120 名前：97 [2006/02/21(火) 12:50:45 ] >>111 いや言っている。 どちらかというと言語の標準仕様であってもらいたいね。 件の記法が正式採用されたら最適化エンジンは楽チンにベクトル化出来るし SIMD使えないときでも依存関係の解析が楽になる。 処理が長いときはスレッド化だってイケる。 どれかの言語がこんな感じの機能を実装したら(あるいは約束したら)、 明日にでもその言語に乗り換えるね。 121 名前：デフォルトの名無しさん mailto:sage [2006/02/21(火) 13:18:37 ] >>119 0.01msか。思ったより効かないな。 prefetchの代替ならmovを使うという手もあるが、この処理の要はmovntqだからな。 後で俺も試してみよう。 122 名前：デフォルトの名無しさん mailto:sage [2006/02/21(火) 13:58:35 ] Win機でのprefetchはいろいろやったけどあまり効かなかった。 効果てきめんな人居る？ 別のCPUでうまいこと使って爆発的に速くなった経験はあるから、 ちゃんとはまれば効果があることは理解してるんだけど失敗続き… VTuneとかでメモリアクセスのパターンとか見れば何とかなるか と評価版を試してみたけど結局うまく行ってない。残念無念 123 名前：デフォルトの名無しさん mailto:sage [2006/02/21(火) 14:03:39 ] 非実用コードで試しても、１割くらい速くなるだけだね。 キャッシュラインは64byteないとほとんど効かないと思う。 124 名前：デフォルトの名無しさん mailto:sage [2006/02/21(火) 14:23:50 ] >>122 PGIの嘘っぽい最適化結果によると ttp://www.softek.co.jp/SPG/Pgi/TIPS/amd64_em64t.html だそうな。 125 名前：デフォルトの名無しさん mailto:sage [2006/02/21(火) 16:37:15 ] PGIスレにぎわってないけど、ホントに性能出るもんかねえ？ intelでもオレのケースではまったく効果なかったし（性能クリ ティカルな部分は全部SIMD化している）、iccで最適化 かけた性能はオレのasmコードにぜんぜんのよばねーし。 126 名前：デフォルトの名無しさん mailto:sage [2006/02/21(火) 17:05:03 ] ハードウェアプリフェッチついてるから、 ソフトウェアプリフェッチの効果薄いのかもね。 メモリアクセスレイテンシ対策にはiccの #pragma unroll(?) は段数変えてみると結構効く場合があるね。 127 名前：デフォルトの名無しさん mailto:sage [2006/02/21(火) 21:34:42 ] バタフライ演算が華麗に書けないのは痛いな。他のレジスタにコピーして 別に計算、マスクしてから元のレジスタに加算とか、ステップが余計にかかって しょうがない。 二次元DCTをFCTで書いたものと、まともにDCTしたものを比べたら、普通の DCTのほうが幾らか速かったorz 腕が悪い可能性も大だが。 V-Tuneなんつうブルジョアなものは持ってないので、visioでダイヤグラムを 書いて、ペナルティを極力食らわないように組替えてからソースを書きました とさ。手動最適化マンセー。 128 名前：デフォルトの名無しさん mailto:sage [2006/02/21(火) 22:24:19 ] shuffle命令やSSE3使ってる？ 129 名前：デフォルトの名無しさん [2006/02/22(水) 10:48:20 ] SSEすら使ってない。 お客は5、6年位前のスペックでも結構平気で使ってるからな。 SSE3対応の石にせよ、この国ではすでにデスクトップ市場を越えたノート市場で 最近出始めたばかりで、使えないことのほうが多い。 Intel Macあたりが対象なら、あんま考えなくていいけど。 まぁMMXまでは完全に存在を前提に書いたりするがな。 MMX非対応の石はどのみち絶対性能が不足するので切り捨ててる。 つか、SSE2/3って、本当にごく特殊な演算を除けば、MMXの有無程にはパフォーマンスに影響ないんだよな。 130 名前：デフォルトの名無しさん mailto:sage [2006/02/22(水) 11:00:13 ] >>129 ＞SSE2/3って、本当にごく特殊な演算を除けば、MMXの有無程にはパフォーマンスに影響ない 同意 ＭＭＸでの高性能化に比べてＳＳＥ以降はかなりがっかりなのだ。 ＭＭＸと同程度に努力したが同じ率での高速化はしなかったよ。 掛け算に無符号が付いたMMX2は最初からやっとけと 131 名前：デフォルトの名無しさん mailto:sage [2006/02/22(水) 11:50:23 ] ま、あれか。プログラム起動時にCPUの種類を判別して、それぞれに 最適なルーチンを走らせるというのが普通か。 132 名前：デフォルトの名無しさん mailto:sage [2006/02/22(水) 12:27:12 ] 手動最適化はMMXだけ使って SSEはコンパイラに丸投げ そんなシナリオを想定してある感じ 133 名前：デフォルトの名無しさん mailto:sage [2006/02/22(水) 13:04:07 ] MMXはまぁ当然として、SSEはP3/AthlonXPからだっけ？ x86の浮動小数点命令は使いにくいからSSEでの最適化は欠かせないなぁ。 3D Now! の話題が全く無いのは互換性割り切るほど速度出ないからか。 >129 SSE2/3の命令ってmov系と高精度演算命令系以外になんかあんの？ 134 名前：デフォルトの名無しさん mailto:sage [2006/02/22(水) 13:47:08 ] >>133 MendocinoコアCeleronの載ったマシンとか現役で使ってる人が結構いるから SSEも迂闊に使えないｗｗｗ もっとも、うちは基本的に整数演算か倍精度実数演算しか滅多に使わない 人なんで、パックド単精度ってそんなに有り難味が無い。 pmovmskbとかmaskmovqとかもそれなりに便利だけど、わざわざ別々の最適化コード 書いてディスパッチするだけの労力に見合った効果も得にくいんだよな。 > SSE2/3 ホラ、あるじゃないか。MMX/3DNOW!を無理矢理二つくっ付けた様な糞命令群が。 このへんは演算ユニットが128bit化するときのための布石と考えてるが。 てか、64bitになるとMMXもそろそろ要らなくなりそうな雰囲気。 飽和演算とか撹拌処理とかやらなくていいなら汎用ALU使ったほうが速度が出るんだよね。 135 名前：デフォルトの名無しさん mailto:sage [2006/02/22(水) 15:08:51 ] >>100のコードと、>>119で使われたと思われるコードで測定してみた。＠PenM 640*480*16で、43.7msと43.2msくらい。1%程度の違いしかない。 最初からL2ヒットであれば>119が倍近く速いので、やはりメモリネック。 ストアに対してprefetchntaを使うと30.8ms。効いてます（ライトスルーのP4では効かないかも）。 ていうかプリフェッチなんかせずにストアをmovntqにすると18.1ms（これはP4でもOKだと思う）。 単純な処理の割に、MMXが効かずSSE（MMX2）が効くというヤツであった。 >>119 仕事で使っているみたいだから無理だとは思うけど、>>100のコードのmovq [edi], mm0;の行を _asm _emit 0x0f _asm _emit 0xe7 _asm _emit 0x07;//movntq [edi], mm0 のマシン語コード このように書き換えればmovntqが使えますぜ。 俺の環境だと20.0ms。たった１行書き換えただけで倍以上速くなるのは気持ちいい♪ >>115 prefetchntaが最速だった。 ロードなしのmovntや、ストアなしのprefetchロード、というならもっと速いが、 ロードとストアを両立させようとすると、prefetchntaという結論になる。 136 名前：デフォルトの名無しさん mailto:sage [2006/02/22(水) 15:29:56 ] >>134 ＞Mendocinoコア めんどっちーの、と読むのか？ 137 名前：デフォルトの名無しさん mailto:sage [2006/02/22(水) 19:52:50 ] 略してマンコア 138 名前：デフォルトの名無しさん [2006/02/23(木) 20:53:08 ] >135 殿 　アドバイスありがとうございます。 　実験してみましたところ、おおよそ速度が4倍にアップしました。 　こりゃすげえ！　と思ったのですが、上長には却下されました。 『だれもわからねぇYo！』だそうで。 　さすがにMMX2まで扱おうとすると、VC6ではやりづらいですね。 上長の上の人に結果まとめてレポしてみて、環境更新するよう具申してみることにします。 　ちなみに、こちらの環境で一番速かったのは、>101殿のアドバイス を受けたもの(>119報告のもの)の改造版でした。 void test4( void *dst, const void *src, int size ) {　int size2 = size >> 2; 　　if(size2 != 0){　__asm{ 　　　　　mov　　　　　　edi,　　dst; 　　　　　mov　　　　　　esi,　　src; 　　　　　mov　　　　　　ecx,　　size2; 　　　loop_mp: 　　　　　movd　　　　 mm0,　　[esi]; 　　　　　punpcklbw　　mm0,　　mm0; 　　　　　movq　　　　 mm1,　　mm0; 　　　　　punpcklbw　　mm0,　　mm0; 　　　　　punpckhbw　　mm1,　　mm1; 　　　　　_asm _emit 0x0f _asm _emit 0xe7 _asm _emit 0x07; 　　　　　_asm _emit 0x0f _asm _emit 0xe7 _asm _emit 0x4f _asm _emit 0x08; 　　　　　add　　　　　　esi,　　4; 　　　　　add　　　　　　edi,　　16; 　　　　　sub　　　　　　ecx,　　1; 　　　　　jnz　　　　　　 loop_mp; 　　　　　emms; 　}} } 139 名前：デフォルトの名無しさん mailto:sage [2006/02/23(木) 21:14:55 ] MMX2って何？SSEで入れられた整数演算？ 140 名前：・∀・）っ-○●◎- ◆Pu/ODYSSEY mailto:sage [2006/02/23(木) 21:38:09 ] もともとはSSEの旧い仮称だった気が。 今はへるみ氏あたりが初代AthlonでサポートされたEnhanced 3DNOW!とで 共通で使える拡張命令（要するにSSEのMMX整数演算拡張）を総称して そう言ってるような。 案外午後な人書き込んでるかもしれんね。 141 名前：デフォルトの名無しさん mailto:sage [2006/02/23(木) 22:22:04 ] 浮動小数点形式にすればバタフライ演算は可能になるが、そのかわり 一度に演算できるデータは少なくなる。 16bit整数でバタフライ演算すれば同時に処理できるデータは8点に増えるが、 同じレジスタ内に0以上1未満の整数値(シフト処理したもの)と1以上の 整数値が混在する場合は、バタフライ演算で同時に演算できない。 該当するデータはいったん別のレジスタで処理しなければ成らないため ステップ数が増える。 精度を保って処理したいなら単精度小数点などで処理するが、リアルタイム 性能を追求するなら整数で処理するしかないかな、と。 まぁ、どうせインテルは本当に便利な命令は用意しない方針のようなので。 142 名前：デフォルトの名無しさん mailto:sage [2006/02/23(木) 22:53:27 ] ソフトウェアパイプライニングとか 手でやってる？コンパイラまかせ？ x64だとレジスタ数も違うし、そもそも CPUごとにレイテンシ等変わって面倒だよね？ 143 名前：・∀・）っ-○●◎- ◆Pu/ODYSSEY mailto:sage [2006/02/23(木) 23:01:45 ] Athlon系はレイテンシが長いからL/S頻度上げてでも並列化汁 PenMは全般にレイテンシ短いから程々でヨシ NetBurstはパイプラインの長さの分OoOが強力だからあんまり何も考えないほうが かえって良かったりするかも。 という風に把握している 144 名前：デフォルトの名無しさん [2006/02/24(金) 08:45:35 ] >>142 JIT付きの実行環境が欲しくなるなあ 145 名前：・∀・）っ-○●◎- ◆Pu/ODYSSEY mailto:sage [2006/02/24(金) 21:27:24 ] っ[ドトニート] 146 名前：デフォルトの名無しさん mailto:sage [2006/02/26(日) 19:46:12 ] ん、MMX2ってAMDがつけた3D-Now!の前の名称だったのでは？ MMXを機能拡張したCPUをAMDが出したとき、インテルが「MMXはうちの登録商標 だから使うな」とAMDを訴え、AMDは「マルチメディアエクステンションなんて 平凡な名称だ」と反発していたような。 違ったらｽﾏｿ 147 名前：デフォルトの名無しさん mailto:sage [2006/02/27(月) 06:55:48 ] 確かにｸｿ平凡だよな 148 名前：デフォルトの名無しさん mailto:sage [2006/02/27(月) 14:28:57 ] 俺はMMX2ってSSEの中でMMXレジスタを使うものをIntelが呼んでいたんだと 思っていたが、何か違うみたいね。ぐぐっても少ないし。 149 名前：・∀・）っ-○●◎- ◆Pu/ODYSSEY mailto:sage [2006/02/27(月) 21:14:27 ] >>146 古いソースを漁ってみるに、MMX2はSSEがまだ世に出る前の仮称。 SSE自体もKatmaiが出始めた頃はiSSE（インターネットストリーミングSIMD拡張）と 呼んでたり。 AMDその他CPUメーカーがMMXを使うこと自体にIntelが提訴したのでは。 Intel側の主張は棄却で和解したはず。 150 名前：・∀・）っ-○●◎- ◆Pu/ODYSSEY mailto:sage [2006/02/27(月) 22:06:26 ] すんまそん、技術自体ではなく名称ですね。 サポートされた拡張命令セットが同一であっても、あくまでカタログ上は Enhanced 3DNOW!、3DNOW! Professionalなどと称し、SSE、SSE2という商標名は 使ってませんな。 151 名前：デフォルトの名無しさん mailto:sage [2006/02/27(月) 22:25:55 ] 3DNow!はSSE+αなんだからSSEと名乗るのは変じゃないか 152 名前：・∀・）っ-○●◎- ◆Pu/ODYSSEY mailto:sage [2006/02/27(月) 22:34:40 ] まぁそうなんだけどEnhanced→ProfessionalはIntelが先行して行ったXMMレジスタ周りの 拡張命令のサポートで、AMD独自の拡張命令の追加は無い やっぱり商標権のトラブル回避の為でしょうな 153 名前：デフォルトの名無しさん [2006/04/25(火) 20:19:34 ] MMXに命令が追加されたときにユーザーが俗にMMX2と読んだだけなんじゃなかったkk手 154 名前：デフォルトの名無しさん mailto:sage [2006/04/25(火) 23:21:44 ] 0x8E574343みたいなHexのデータが延々と続いたデータの 中から、特定のhex列を見つけたいと思ったらアルゴリズムは 別の領域として高速化するのにSSEとかは使えそう？ もし使えそうだったら簡単なサンプル示していただけないでしょうか 155 名前：デフォルトの名無しさん mailto:sage [2006/04/25(火) 23:27:01 ] キャッシュに納まるサイズのデータの中を何度も検索するんじゃなければ 普通にCで書いてもMMX使っても大差ないような気がする。 巨大データ（and 古いCPU）ならむしろ prefetch の有無で変わってくる。 156 名前：デフォルトの名無しさん mailto:sage [2006/04/25(火) 23:32:10 ] えーとCPUはOpteron850とかXeon 3.6Ghz当たりを64コアから512コアぐらいを 想定しています。データは1データあたり1000バイト程度それが秒間900MB/sec 転送されてきますそれをリアルﾀｲﾑで処理しないといけません。そうするとCで 書いても大差ないですか。 157 名前：デフォルトの名無しさん mailto:sage [2006/04/26(水) 13:15:35 ] >154 その程度のサンプルも書けないレベルなら諦めろ。 結局メンテナンス出来ずに回りに迷惑かけるだけだ。 >156みたいな用途ならおとなしくCで書いとけ。 158 名前：デフォルトの名無しさん mailto:sage [2006/04/26(水) 19:48:30 ] 900MB/sのネットワークがなんなのか気になる 159 名前：デフォルトの名無しさん mailto:sage [2006/04/28(金) 00:41:23 ] SSEはレジスタが広いけど、 汎用レジスタで最初の4byte一致したら続きを調べるってすれば実質変わらんしなあ。 「特定のhex列」の登場頻度が高いなら別だけど。 あ、でもこれもSSEで並列にやればいいんだ。hexは1/2バイトなのも考えて。 「特定のhex列」のバイト数は？ 2バイト単位くらいで比較して、4bitシフトしてまた比較。 一致するものがあったらそこを普通に調べる。 これなら数倍比較コストが減るんじゃないか。 ＃まあ、メモリ帯域ネックから高速化はしないと思うよ。 あとはキャッシュラインをまたぐときに気をつけること。ここもうまくやればSSEが有効か？ ていうかCで書いて速度が足りないから>>154で質問したんじゃないよね？ 普通にCで十分な速度だと思うよ。 160 名前：デフォルトの名無しさん mailto:sage [2006/04/28(金) 02:39:57 ] スペック見る限り結構な規模のプロジェクトだし、 そんなプロジェクトで汎用性が無くメンテナンス性の悪いアセンブラを使おうってのが間違ってる。 しかも知識も無いときたら周りに迷惑かけるに決まってる。 や　め　と　け。 161 名前：デフォルトの名無しさん mailto:sage [2006/04/28(金) 02:47:22 ] 昔似たようなことやったけれどあんまり意味が無かった記憶がある。 162 名前：デフォルトの名無しさん mailto:sage [2006/04/28(金) 06:53:08 ] いまやSSEもAltivecもCで書く時代 163 名前：デフォルトの名無しさん mailto:sage [2006/04/28(金) 07:43:02 ] みんな言ってることは正しいと思うけど、 このスレ的にはアセンブラでSIMDを使い無駄な最適化をするべきじゃないか？ 164 名前：デフォルトの名無しさん mailto:sage [2006/04/28(金) 10:14:38 ] ＞無駄な最適化 ｗｗｗ なんかわかるｗ 165 名前：デフォルトの名無しさん mailto:sage [2006/05/01(月) 01:01:51 ] 154タンはいなくなってしまったか。。 166 名前：デフォルトの名無しさん mailto:sage [2006/05/02(火) 01:27:50 ] いやいるし勉強してるんだけど、いまいちよくわからない もう少し修行してきます 167 名前：デフォルトの名無しさん mailto:sage [2006/05/02(火) 19:01:46 ] >>166 いたか。いつでもいいので修行したら報告ヨロ。 168 名前：デフォルトの名無しさん mailto:sage [2006/05/03(水) 10:49:45 ] とりあえず、gasとnasmどっちでインラインすればいいんだろう gccだと一択なのかな？ 169 名前：デフォルトの名無しさん mailto:sage [2006/05/03(水) 20:55:17 ] SIMDの資料ってみなさんはどこから取得してるのでしょうか？ 170 名前：デフォルトの名無しさん mailto:sage [2006/05/03(水) 21:29:21 ] www.intel.co.jp/jp/developer/download/index.htm 171 名前：デフォルトの名無しさん mailto:sage [2006/05/05(金) 19:42:06 ] ていうか検索アルゴリズムってどう最適化しても 結局メモリ帯域で頭打ちになるっしょ 172 名前：・∀・）っ-○◎● ◆toBASh.... [2006/05/05(金) 19:52:44 ] ここを熱心に読んでたことが、私にもありました。 developer.apple.com/hardwaredrivers/ve/ 173 名前：デフォルトの名無しさん mailto:sage [2006/05/05(金) 21:00:21 ] 黙れキチガイ 174 名前：デフォルトの名無しさん mailto:sage [2006/05/19(金) 01:02:05 ] 組み込み関数を利用してSSEプログラミング勉強しようと頑張ってみたのですが 以下のようなクラスを用意して、一度に16バイトずつuchar型のデータを判別しようと しましたが、このchar型のデータをSSEで計算するにはどうしたらいいのでしょうか class CHARVector { union { __m128 vec; struct { unsigned char c1, c2, c3, c4; unsigned char c5, c6, c7, c8; unsigned char c9, c10, c11, c12; unsigned char c13, c14, c15, c16; }; }; // ... }; 175 名前：・∀・）っ-○◎● ◆toBASh.... [2006/05/19(金) 01:26:16 ] >>174 __m128じゃなくて__m128i使いなよ。ただしSSEじゃなくてSSE「2」ね。 SSEまでなら単精度浮動小数×４までしかサポートされない。 C++ラッパー１から作るくらいなら最初から用意してある物使ったほうがいい。 #include <dvec.h> VC++かICCならこれで Iu8Vec16 っていうクラスが使えるはず 176 名前：デフォルトの名無しさん mailto:sage [2006/05/19(金) 01:32:07 ] すいません環境書くの忘れたのですが、 RedhatEL4 gccで作成しています。ｇｃｃだとdvec.hが使えないと 聞いて悩んでいました。 177 名前：・∀・）っ-○◎● ◆toBASh.... [2006/05/19(金) 01:45:07 ] 確かに使えない。 じゃあこっち #include <emmintrin.h> __m128i共用体メンバに m128i_u8[16] ってのがある。 あとは msdn2.microsoft.com/en-US/library/26232t5c.aspx とかを参考に。 pcmp系関数でマスクしてpmovmskbで各上位ビットを汎用レジスタに転送して再度比較するのが スマートかな。 178 名前：デフォルトの名無しさん mailto:sage [2006/05/19(金) 02:12:04 ] >>177 うーんサンプルコードってあるのでしょうか？ 179 名前：デフォルトの名無しさん [2006/06/13(火) 01:35:19 ] すみません、ANDPDとANDPSって何か違いがあるんでしょうか？ どっちもxmmレジスタ同士のandを取るだけのような…… 180 名前：デフォルトの名無しさん mailto:sage [2006/06/13(火) 02:35:31 ] マシン語コードが違う。命令長は同じ。 動作も同じだと思う。 ニーモニックが2つあるのはいいとして、 なぜマシン語コードも違うのか謎ですな。 181 名前：デフォルトの名無しさん mailto:sage [2006/06/13(火) 02:52:35 ] ANDPSは、SSEまでカバーしていれば使える。 建前上、パックド単精度実数が操作対象。 ANDPDは、SSE2をカバーしていないと使えない。 建前上、パックド倍精度実数が操作対象。 182 名前：デフォルトの名無しさん mailto:sage [2006/07/05(水) 10:18:10 ] 機械語は敷居が高すぎて手を出せないので、C言語だけで3DNOW!やSSE対応の プログラムは作れないものでしょうか。 183 名前：デフォルトの名無しさん mailto:sage [2006/07/05(水) 10:35:41 ] MMXやSSE命令をラッピングした組み込み関数が用意されている開発環境があるよ 184 名前：デフォルトの名無しさん mailto:sage [2006/07/05(水) 12:47:46 ] なんでもそうだけど、知らないと食わず嫌いで難しそうに思うけど やってみるとそうでもないもんだよ。 185 名前：デフォルトの名無しさん [2006/07/05(水) 13:03:54 ] >>183 つか、x64やIL向けだとインラインアセンブラ無効だからそれ使うしかない 186 名前：デフォルトの名無しさん [2006/07/05(水) 13:08:38 ] 実際問題mmintrin系組込み関数は構造化設計ができるし、命令スケジューリングの最適化も阻害しないから 結構便利なんだよな 187 名前：デフォルトの名無しさん mailto:sage [2006/07/05(水) 14:00:17 ] 命令スケジューリングっていうか、VC++ の場合inline 使うと 前後でも最適化が一切行われないよね。 188 名前：デフォルトの名無しさん mailto:sage [2006/07/05(水) 18:17:51 ] >>187 される。 まさかとは思うがコンパイルオプションミスったり、 デバッグモードで確認なんかしてないよな？ 189 名前：デフォルトの名無しさん mailto:sage [2006/07/05(水) 19:45:11 ] ホントダ・・・誰かに騙されていた！！ 簡単に確認できるのに確認しない漏れって・・・orz 190 名前：デフォルトの名無しさん [2006/07/06(木) 11:38:10 ] 最適化されないのはインラインアセンブラ（__asmステートメント）の前後や中身。 inlineとか__inlineキーワードはむしろグローバルな最適化（高速化）のためのもの 191 名前：デフォルトの名無しさん mailto:sage [2006/07/06(木) 15:49:58 ] >>190 漏れもそう思ってだんだけど、Visual Studio 2005 の C++ で実験してみると 同じ関数内の __asm 後のコードもきっちり最適化されてるわけですよこれが・・・ char a[100]; for (int i = 0; i < 100; i++) a[i] = i; int sum = 0; for (int i = 0; i < 100; i++) sum += a[i]; で、全てC++で書いても最初の初期化のトコを __asm で書いても、後者の加算のループは 5つずつ加算する20回のループに展開されますた。 192 名前：デフォルトの名無しさん mailto:sage [2006/07/06(木) 17:24:38 ] インラインアセンブラの部分まで勝手に最適化されたら神認定なんだが。 193 名前：デフォルトの名無しさん mailto:sage [2006/07/06(木) 17:47:13 ] インラインアセンブラの部分を勝手に最適化しやがったらキレるだろ普通。 アセンブラで記述しなきゃいけない部分は何らかの理由があって わざわざそういうコードにしてるものもあるのに、 それを別の命令に置き換えられたらブチギレですよ。 194 名前：デフォルトの名無しさん mailto:sage [2006/07/06(木) 19:04:49 ] >>191 関数の前半と後半を__asm{nop}でぶった切ったら最適かもぶった切られたよ。 195 名前：デフォルトの名無しさん mailto:sage [2006/07/07(金) 11:33:32 ] 「最適化もぶった切られた」ってのはどういう意味ですか？ 後半が素直な100回ループになっちゃったってこと？

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef