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

1 名前：デフォルトの名無しさん [04/05/28 22:00] どうぞ 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回ループになっちゃったってこと？ 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共用体使う

---

---

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

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