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

1 名前：デフォルトの名無しさん [04/05/28 22:00] どうぞ 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回ループになっちゃったってこと？ 196 名前：デフォルトの名無しさん mailto:sage [2006/07/07(金) 11:38:45 ] >>194 コンパイラによって結果は異なってあたりまえだろ。 漏れのとこの VC++ 2005 では __asm{ nop}; 入れてもnpad 1 が間に入るだけで 全く変らないコードが生成された。 197 名前：デフォルトの名無しさん mailto:sage [2006/07/07(金) 12:03:47 ] >>195 __asmをまたいだ最適化はしない、ということかな？ 198 名前：196 mailto:sage [2006/07/07(金) 13:16:40 ] >>197 そういうことじゃないんじゃないか？漏れのトコでは前述の通り npad 1 の有無だけ。 そもそも__asm 入れなくても「またいだ最適化」みたいなものは無かったし。 単に >>194 の使ってるコンパイラが__asm 入れると最適化しなくなる旧いVCとか なんじゃまるまいか？ 199 名前：デフォルトの名無しさん mailto:sage [2006/07/07(金) 13:28:48 ] >>198 なるほど。 200 名前：デフォルトの名無しさん mailto:sage [2006/07/07(金) 18:35:27 ] >>195 forループではないんだが、FPUレジスタの使い方に無駄が出た。 ある関数の最初の方で別のライブラリの関数にfloatの変数渡して、 いくつか別の浮動小数点の処理した後で変更なしで再びその変数を使うんだが、 この間にnop入れるだけでもう一回メモリから読み出すようになった。 >>196 すまんがforループなんて単純な部分ではなく、しかもVC8での話なんだ。 201 名前：デフォルトの名無しさん mailto:sage [2006/07/07(金) 20:27:10 ] インラインアセンブラ挟んで最適化を期待する方がおかしい気がしますが。 しかも複雑な部分なら尚の事。 202 名前：200 mailto:sage [2006/07/07(金) 21:27:22 ] >>201 アンカーがないから俺へのレスってことでOKなのか？ おれは__asmブロックで最適化が阻害されるのは当然だと主張してるのであって 最適化されねーぞなんでだヴォケと言ってるわけじゃないんだが。 203 名前：デフォルトの名無しさん mailto:sage [2006/07/07(金) 21:36:42 ] >>200 その話の真偽はおいといて、 >>191>>194 を読んでそんな風に理解できるかというと、 それはちょっと無理じゃないか。 漏れは 191 の関数の前半と後半という風に読んじゃたよ。 想像力が無いからかもしれないけど。 204 名前：デフォルトの名無しさん mailto:sage [2006/07/07(金) 22:01:59 ] >202 当たり前の結果にムキになってっから、何か不満でもあるのかと思った。 205 名前：デフォルトの名無しさん mailto:sage [2006/07/08(土) 09:25:11 ] >>81 古い話だけど今のICCには_mm_cast*という命令があってこれでキャストできることに気がついた。 VCLにはない。GCCは普通に(__m128)とかでキャストできる。 206 名前：・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6 [2006/07/08(土) 17:53:16 ] 浮動小数の2倍とか1/2倍とかやるのに指数部を直接整数として足し算引き算すると確かに速いんだよな AMDが来年予定してる新リビジョン（K8L）でXMMレジスタの下位・上位QWORDと汎用レジスタ命令の値を 相互に交換する追加されるみたいだけど、これってIntelも採用するかのう？ 別のニーモニック割り当てるんだろうな。 207 名前：・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6 [2006/07/08(土) 17:54:25 ] ×汎用レジスタ命令 ○汎用レジスタ 208 名前：182 mailto:sage [2006/07/13(木) 16:03:54 ] みなさん、どうもありがとうございました。 3DnowやSSEを使えるようになるのを目標にして、機械語を勉強するのに 良い参考書がありましたら、教えていただけませんか。 NWSAというのを見つけて、解説を読んでいますが未知の言葉が山盛りです。 209 名前：デフォルトの名無しさん mailto:sage [2006/07/13(木) 16:14:38 ] SIMDが載ってる本 x86アセンブラ入門 アセンブラ画像処理プログラミング 載ってない本 独習アセンブラ アセンブリ言語の教科書 糞級言語プログラマのためのアセンブラ入門 210 名前：デフォルトの名無しさん mailto:sage [2006/07/13(木) 16:19:02 ] >>208 ftp://download.intel.co.jp/jp/developer/jpdoc/24547103_j.pdf ttp://homepage1.nifty.com/herumi/adv.html 211 名前：デフォルトの名無しさん mailto:sage [2006/07/13(木) 23:48:16 ] 絶対に買ってはいけない本 いまどきのアセンブリ言語 いまどきのアセンブリ言語の教科書 212 名前：デフォルトの名無しさん mailto:sage [2006/07/14(金) 00:33:58 ] 「IA-32 インテル アーキテクチャ・ソフトウェア・デベロッパーズ・マニュアル」 を読んでSSEが難しいようだったら多分それを触る前に覚えることがまだまだある。 213 名前：デフォルトの名無しさん mailto:sage [2006/07/14(金) 06:06:27 ] >>212 そうかな。俺はよくわかんないうちから MMXでガンガンコード作って覚えたけど。 あのマニュアルを読むのは、ある程度 SSEを使えるようになってからでないときついだろう。 214 名前：デフォルトの名無しさん mailto:sage [2006/07/14(金) 10:07:33 ] >>213 212ではないが、あれ読めないって事は結局x86の構造理解出来てないって事だと思うが。 通常命令での効率的な組み方を勉強する方が先じゃね？ 215 名前：デフォルトの名無しさん mailto:sage [2006/07/15(土) 06:49:15 ] Core2に搭載されるISSE4っていったいなんだろう。 216 名前：デフォルトの名無しさん mailto:sage [2006/07/21(金) 11:50:31 ] CASL IIやれば十分だよな 217 名前：デフォルトの名無しさん mailto:sage [2006/07/27(木) 15:42:54 ] 単純な画像変換とかをMMX化SSE化して デバッガにかけながら読むとテラわかりやすいお。 218 名前：デフォルトの名無しさん mailto:sage [2006/07/28(金) 21:22:59 ] だれか Core2 に搭載される(た) SSE4 のマニュアルを ダウンロードできるとこ知らない？ www.intel.com とか探しても全然見当たらない。 まだ非公開かな？ それにしてはベンチマークが対応しているのが不思議．．．。 219 名前：デフォルトの名無しさん mailto:sage [2006/07/28(金) 21:39:10 ] 糞団子のページに書いてあるよｗｗｗｗｗｗｗｗｗｗ 220 名前：デフォルトの名無しさん mailto:sage [2006/07/28(金) 21:47:56 ] あれはニーモニックから推測したものでしょ。 TMPGEncだかも対応したよな。 開発者向けには公開してあるってことか？ 221 名前：デフォルトの名無しさん mailto:sage [2006/07/28(金) 22:00:38 ] TMPGEncはIntelが金出して最適化してたはず。 222 名前：デフォルトの名無しさん mailto:sage [2006/07/28(金) 22:58:59 ] なるほど。抜け目ないね。 TMPGEncはベンチとしても一般的だからな。 223 名前：デフォルトの名無しさん mailto:sage [2006/08/04(金) 10:38:00 ] 推測っていうか、既にICC9.1でこっそり対応してる。組み込み関数も既に用意されてる。 団子のページ引用率高すぎ 224 名前：デフォルトの名無しさん mailto:sage [2006/08/14(月) 07:45:54 ] C言語のプログラムの途中たった一行だけ、計算式をインラインアセンブラで MMXやSSE、3DNOWに対応させるというのは可能ですか。 225 名前：デフォルトの名無しさん mailto:sage [2006/08/14(月) 09:09:05 ] たった一行だけのためにemmsを使うのはアフォ 226 名前：デフォルトの名無しさん mailto:sage [2006/08/14(月) 13:22:18 ] 最低でもループの一番内側丸ごと、じゃないかな。 emmsもｄろうけど、SIMDはデータをレジスタに乗っ けるところが結構食うからね。 227 名前：・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6 mailto:sage [2006/08/14(月) 23:22:34 ] アンロールしまくれ SSE2の整数命令ってSSE2非対応CPUはMMXの相当命令として解釈されるから うまく組めばパスの分岐必要なし 228 名前：デフォルトの名無しさん mailto:sage [2006/08/29(火) 01:31:22 ] gccでintrinsic function使ってSSE2,3の処理書きたいんですけど 3年ぐらい前に書くとアライメント指定しても4byteでまとめられたりして まともに使えなかった記憶があるんだけど今はどうなんですかね？ 229 名前：デフォルトの名無しさん mailto:sage [2006/08/29(火) 21:46:08 ] _mm_malloc()かunion共用体使う 230 名前：デフォルトの名無しさん mailto:sage [2006/09/14(木) 14:49:48 ] SSE4の仕様解析出たな >>226 SIMDのデータ転送のレイテンシが半端なくでかいのはPen4くらい AthlonやPenM, Core系は整数と大して変わらない 231 名前：デフォルトの名無しさん mailto:sage [2006/09/14(木) 15:00:09 ] ようするにネトバは糞って事？ 232 名前：デフォルトの名無しさん mailto:sage [2006/09/14(木) 15:57:07 ] ネトバカッコイイってほざいてたのは雑音だけ。 SIMDとSIMMを間違えるのも雑音だけ。 233 名前：デフォルトの名無しさん mailto:sage [2006/09/14(木) 16:57:41 ] たるさん… 234 名前：・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6 mailto:sage [2006/09/14(木) 23:04:40 ] psign*とpalignr間違えてましたすいません。 SSE4って命令部3バイトだからあんまり使えない気が。 XMMレジスタでREXプリフィックス付けたら命令長最低6バイトになる >>228 ヒープ上に16バイトくらい多めに確保して、返ってきたアドレスに15足して~15でマスク。 Windowsだと、SSEがまともに使えるようになったのがVC7からだと記憶してる。 235 名前：デフォルトの名無しさん mailto:sage [2006/09/27(水) 11:49:46 ] SSE4のレイテンシやスループットの数字って出てる？ 236 名前：・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6 mailto:sage [2006/09/27(水) 22:11:16 ] 非公式ながら、x86の〜スレにある。 正式名称はSupplimental-SSE3(SSSE3)になったらしい。 あと、まるも製作所の中の人が色々と考察してた 237 名前：デフォルトの名無しさん mailto:sage [2006/09/27(水) 22:28:46 ] へえ、SSE4じゃなくてSSE3に追加するという形か。 238 名前：デフォルトの名無しさん mailto:sage [2006/09/28(木) 20:11:09 ] 長いからSSE4かTNIでいいよ 239 名前：デフォルトの名無しさん mailto:sage [2006/09/28(木) 21:16:13 ] 追加って話ならSSSEよりSSE3sのが理にかなってわかりやすいなぁ… 240 名前：デフォルトの名無しさん mailto:sage [2006/09/28(木) 21:21:57 ] Enhanced 3D Now! みたいなものだろう。 ただ、次に命令を追加するときに「SSE4」とされるとややこしいな。 241 名前：デフォルトの名無しさん mailto:sage [2006/09/28(木) 21:24:32 ] 次はSSSSE3だな 242 名前：デフォルトの名無しさん mailto:sage [2006/09/28(木) 21:31:38 ] スプラッシュスターSSE3 243 名前：デフォルトの名無しさん mailto:sage [2006/09/29(金) 10:58:55 ] Streaming SIMD Extensions eXtendedにするべきだと思うんだが 244 名前：デフォルトの名無しさん mailto:sage [2006/10/05(木) 01:38:11 ] 今後、SSE4はSSE4と呼べばいいが、 SSE3+SSSE3を総称した呼び名はできるのかな。 命令が普及した後で、SSE3と言ったときに、 SSSE3が含まれるかどうかが不明確になりそう。 245 名前：デフォルトの名無しさん mailto:sage [2006/10/05(木) 01:39:39 ] 総称がSSE3だろ ﾌﾟﾚｽｺは要らない子 246 名前：デフォルトの名無しさん mailto:sage [2006/10/05(木) 01:50:35 ] そっか。じゃあ、Prescottと最近のK8だけ仲間外れだ。 あれ、Cyrixの系統のやつも載せてたっけ。 今度はSSE3（総称）の中のSSSE3に含まれない命令の 呼び名がないと不便になるなあ。 247 名前：デフォルトの名無しさん mailto:sage [2006/10/05(木) 02:10:26 ] SSSSSEE33 248 名前：デフォルトの名無しさん mailto:sage [2006/10/05(木) 02:18:44 ] SSE3-FP 249 名前：デフォルトの名無しさん mailto:sage [2006/10/05(木) 02:23:10 ] SSE3-Classical 250 名前：デフォルトの名無しさん mailto:sage [2006/10/05(木) 02:24:49 ] SSE3ESS 251 名前：・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6 mailto:sage [2006/10/05(木) 02:50:45 ] PNIとTNI(MNI)でいいじゃん。 PenrynもPだから困る。 252 名前：デフォルトの名無しさん mailto:sage [2006/10/05(木) 14:27:03 ] >>251 なるほど。 Penryn New Instructionsの略称はどうなるのかね。 まあSSE4と呼べばいいだろう。 ところでこのスレも2年以上になるのだが、 今こういうスレを立てるとしたら、3D Now!の名前は入るだろうか。 まあ、2004年と言えばとっくに3D Now!は下火だったが。 253 名前：デフォルトの名無しさん mailto:sage [2006/10/16(月) 18:03:24 ] >>25 この2年前のソースが見てみたい 254 名前：デフォルトの名無しさん mailto:sage [2006/10/16(月) 18:07:15 ] もう2年になるのか・・・。 少し遅れて来て>>25が取れなかったことを 昨日のように思い出す。 255 名前：デフォルトの名無しさん mailto:sage [2006/10/16(月) 21:01:22 ] ttp://hitokuso.kicks-ass.org/bilinear.zip ２年前のソースをそのまま晒す恥知らずの俺サイコー 256 名前：デフォルトの名無しさん mailto:sage [2006/10/16(月) 21:31:14 ] >>255 こ、更新日時が2004/12/12 10:07！！ 俺は特に見たかったわけではないが、>>255はある意味で神。 よかったな、>>32！ 257 名前：デフォルトの名無しさん mailto:sage [2006/10/16(月) 22:36:18 ] >>255 すげぇｗ 258 名前：デフォルトの名無しさん mailto:sage [2006/11/21(火) 14:43:13 ] これから、64bitのWindowsが普及してくる（使えるレジスタ倍増）のと、 Core2やK8LでSSE命令のレイテンシは据え置きでスループットが倍になること、 これらによってSSEの使い方がかなり変わってくるだろう。 259 名前：デフォルトの名無しさん mailto:sage [2006/11/29(水) 02:30:01 ] 急にSIMDとかインラインアセンブラ使いたくなってやってみたんだけど、 トイプログラムで 　A: SIMD化+とことんオプション最適化 　B: とことんオプション最適化 　C: SIMD化 　D: 軽くオプション最適化 　E: ベタ書き で 　A:B:C:D:E = 10:15:30:35:60 ＃速度比 と、実は結構コンパイラオプションのチューニングだけで いけてしまうことがわかってコンパイラスゴスと思ってしまった。 A:Bでも10:15位の速度比があるのでSSEとか効いてはいるんだけど、 最初はC:Dで止まってて「あんま変わんないなぁ」とか思ってたら B:Cで15:30とオプションいじるだけで下手なSIMD化を抜いてしまって 驚いた。よほど性能が必要なケース以外は下手に拡張命令使うより コンパイラお任せで十二分にいい仕事してくれるのな。 自分は拡張命令覚えるよりコンパイラオプション覚えたほうがいい レベルなのだと痛感しますた・・・ 260 名前：デフォルトの名無しさん mailto:sage [2006/11/29(水) 03:09:59 ] 処理内容に依存するからなあ。 どんなの？ SIMD化というのはインラインアセンブラ？ コンパイラに頼るなら組み込み関数という手も。 インラインアセンブラをまたいでは最適化が効かない。 最近はCPUが賢いというのも コンパイラ有利な要因かも。 261 名前：デフォルトの名無しさん mailto:sage [2006/11/29(水) 03:44:25 ] >259 SIMDで最適化するならデータの配置も最適化しないと意味無いぽ。 てかコンパイラ、サンプルコード、計測方法、コアの情報も無く比だけ提示されてもな、って感じ。 262 名前：デフォルトの名無しさん mailto:sage [2006/11/29(水) 16:58:12 ] 正直、そのデータ配置の最適化ってのがどういうもんなのかよくわかんね・・・ セオリーとかあるの？ 263 名前：デフォルトの名無しさん mailto:sage [2006/11/29(水) 17:10:13 ] インテルのマニュアルにSoAとかAoSとかについて書いてある。 264 名前：デフォルトの名無しさん mailto:sage [2006/11/29(水) 21:27:32 ] 何にせよ、どんな処理を高速化したいのか 書いてくれないと話が進まない。 265 名前：デフォルトの名無しさん mailto:sage [2006/11/29(水) 22:58:45 ] >>260 いや、トイプログラムって書いてる通り、1M個くらいのfloat列を ２つ乗算するだけのコード。インラインアセンブラもやったこと なかったので、最初はインラインアセンブラで書き始めて、途中で Intel/MS/GNUが全部同じAPIで叩かせてくれると気づいて書き直した。 これまでやったことがなかったので経験のためやってみただけなので、 あまり真剣に取らないで・・・スマソ。 でもコンパイラオプションだけで考えていた以上に性能が接近すると 知ったのは収穫でした。問題の部分に使うクロック数で非SIMDは３倍 程度はかかるかと思ってたから。 266 名前：デフォルトの名無しさん mailto:sage [2006/11/29(水) 23:16:32 ] >>265 そういうのをトイプログラムというのか。 今のCPUだと、floatならSIMDの方が速いと思うが、 float*1M個*2つ＝8MBなので、L2キャッシュに乗らず、 単にメモリがネックになってるだけと思われる。 非SIMDでfloatの乗算をするのに、うまく最適化すれば Athlon系なら1クロック、Pentium系なら2クロックでできる。 それに対しメモリ帯域は1〜2byte/clkだから、 2つのfloatをロードし結果をストアするのに12byteのアクセスを するのに全然帯域が足りてない。 つまり、ここで必要なのはSIMDでなくプリフェッチ。 >>259のどのコードも、FP演算ユニットは遊んでいたと思われる。 もっとも、SIMDのロードやストアはアクセスの単位が大きいので、 メモリアクセスが効率化されて若干速くなる。 AとBの差はそれだろう。 267 名前：・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6 mailto:sage [2006/11/29(水) 23:43:32 ] 結果の格納を別の配列にしてるんならmovntpsが有効なのでつ x87からライトスルー命令は使えないし、やっぱりSSEまんせー 268 名前：デフォルトの名無しさん mailto:sage [2006/11/29(水) 23:52:32 ] >>266 いやそれがですね、-fprefetch-loop-arrays とかいうオプションが あってまさにそれやってくれてたんですよ。 わざわざ拡張命令使わなくても限定的ながら自動ベクトルかとかも してるそうで、もうコンパイラ様々というか。 269 名前：デフォルトの名無しさん mailto:sage [2006/11/30(木) 00:00:04 ] >>267 あ、それを忘れてた。 >>268 すごいなコンパイラ。 すると、インラインアセンブラを使うと最適化が効かないから プリフェッチもしてくれないわけで、それでAがBに勝ったの？ コンパイラの吐いたプリフェッチコードキボンヌ。 270 名前：デフォルトの名無しさん mailto:sage [2006/11/30(木) 04:55:32 ] そもそも機械的な最適化に負けるコード吐いてる次点でSIMDがどうこう言う資格無い。 時々勘違いしてる奴がいるが、アセンブラ化すれば速くなるわけじゃない。 コンパイラで出来ないことをアセンブラで最適化するから速くなる。 MMX/SSE命令並べただけで速くなるならコンパイラだってそうするだろうよ。 271 名前：デフォルトの名無しさん mailto:sage [2006/11/30(木) 05:20:08 ] >>270 コンパイラに負けるから勉強して SIMDを使えるように頑張るんじゃないか。 272 名前：デフォルトの名無しさん mailto:sage [2006/11/30(木) 11:31:10 ] うん、勉強頑張るのはいいよな。 「コンパイラの最適化で十分」とか結論付けるのは良くないよね。 273 名前：デフォルトの名無しさん mailto:sage [2006/11/30(木) 20:51:08 ] VC8で64bitコードにインラインアセンブラを使えないのが腹立たしい。 MASMだと煩雑だしプリプロセッサも無い。 組み込み関数じゃ思った通りの命令を生成しない。 274 名前：・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6 mailto:sage [2006/11/30(木) 21:58:25 ] COFF形式でコード吐きだせば別にアセンブラは何だっておｋだよ。 むしろx64対応のアセンブラそのものが少ないのが問題。 x64でプログラミングやるならVC++Std + PSDK + ICCが一番コストパフォーマンスいいと思う。 275 名前：デフォルトの名無しさん mailto:sage [2006/11/30(木) 22:14:39 ] yasm使ったことある人いる？

---

---

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

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