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

MMX SSE 3D NOW!のプ� ..

175:・∀・）っ-○◎● ◆toBASh....
06/05/19 01:26:16
>>174
__m128じゃなくて__m128i使いなよ。ただしSSEじゃなくてSSE「2」ね。
SSEまでなら単精度浮動小数×４までしかサポートされない。

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

#include <dvec.h>

VC++かICCならこれで Iu8Vec16 っていうクラスが使えるはず

176:デフォルトの名無しさん
06/05/19 01:32:07
すいません環境書くの忘れたのですが、
RedhatEL4 gccで作成しています。ｇｃｃだとdvec.hが使えないと
聞いて悩んでいました。

177:・∀・）っ-○◎● ◆toBASh....
06/05/19 01:45:07
確かに使えない。
じゃあこっち
#include <emmintrin.h>

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

URLﾘﾝｸ(msdn2.microsoft.com)
とかを参考に。

pcmp系関数でマスクしてpmovmskbで各上位ビットを汎用レジスタに転送して再度比較するのが
スマートかな。

178:デフォルトの名無しさん
06/05/19 02:12:04
>>177
うーんサンプルコードってあるのでしょうか？

179:デフォルトの名無しさん
06/06/13 01:35:19
すみません、ANDPDとANDPSって何か違いがあるんでしょうか？
どっちもxmmレジスタ同士のandを取るだけのような……

180:デフォルトの名無しさん
06/06/13 02:35:31
マシン語コードが違う。命令長は同じ。
動作も同じだと思う。
ニーモニックが2つあるのはいいとして、
なぜマシン語コードも違うのか謎ですな。

181:デフォルトの名無しさん
06/06/13 02:52:35
ANDPSは、SSEまでカバーしていれば使える。
建前上、パックド単精度実数が操作対象。
ANDPDは、SSE2をカバーしていないと使えない。
建前上、パックド倍精度実数が操作対象。

182:デフォルトの名無しさん
06/07/05 10:18:10
機械語は敷居が高すぎて手を出せないので、C言語だけで3DNOW!やSSE対応の
プログラムは作れないものでしょうか。

183:デフォルトの名無しさん
06/07/05 10:35:41
MMXやSSE命令をラッピングした組み込み関数が用意されている開発環境があるよ

184:デフォルトの名無しさん
06/07/05 12:47:46
なんでもそうだけど、知らないと食わず嫌いで難しそうに思うけど
やってみるとそうでもないもんだよ。

185:デフォルトの名無しさん
06/07/05 13:03:54
>>183
つか、x64やIL向けだとインラインアセンブラ無効だからそれ使うしかない

186:デフォルトの名無しさん
06/07/05 13:08:38
実際問題mmintrin系組込み関数は構造化設計ができるし、命令スケジューリングの最適化も阻害しないから
結構便利なんだよな

187:デフォルトの名無しさん
06/07/05 14:00:17
命令スケジューリングっていうか、VC++ の場合inline 使うと
前後でも最適化が一切行われないよね。

188:デフォルトの名無しさん
06/07/05 18:17:51
>>187
される。
まさかとは思うがコンパイルオプションミスったり、
デバッグモードで確認なんかしてないよな？

189:デフォルトの名無しさん
06/07/05 19:45:11
ホントダ・・・誰かに騙されていた！！
簡単に確認できるのに確認しない漏れって・・・orz

190:デフォルトの名無しさん
06/07/06 11:38:10
最適化されないのはインラインアセンブラ（__asmステートメント）の前後や中身。
inlineとか__inlineキーワードはむしろグローバルな最適化（高速化）のためのもの

191:デフォルトの名無しさん
06/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:デフォルトの名無しさん
06/07/06 17:24:38
インラインアセンブラの部分まで勝手に最適化されたら神認定なんだが。

193:デフォルトの名無しさん
06/07/06 17:47:13
インラインアセンブラの部分を勝手に最適化しやがったらキレるだろ普通。
アセンブラで記述しなきゃいけない部分は何らかの理由があって
わざわざそういうコードにしてるものもあるのに、
それを別の命令に置き換えられたらブチギレですよ。

194:デフォルトの名無しさん
06/07/06 19:04:49
>>191
関数の前半と後半を__asm{nop}でぶった切ったら最適かもぶった切られたよ。

195:デフォルトの名無しさん
06/07/07 11:33:32
「最適化もぶった切られた」ってのはどういう意味ですか？
後半が素直な100回ループになっちゃったってこと？

196:デフォルトの名無しさん
06/07/07 11:38:45
>>194
コンパイラによって結果は異なってあたりまえだろ。
漏れのとこの VC++ 2005 では __asm{ nop}; 入れてもnpad 1 が間に入るだけで
全く変らないコードが生成された。

197:デフォルトの名無しさん
06/07/07 12:03:47
>>195
__asmをまたいだ最適化はしない、ということかな？

198:196
06/07/07 13:16:40
>>197
そういうことじゃないんじゃないか？漏れのトコでは前述の通り npad 1 の有無だけ。
そもそも__asm 入れなくても「またいだ最適化」みたいなものは無かったし。

単に >>194 の使ってるコンパイラが__asm 入れると最適化しなくなる旧いVCとか
なんじゃまるまいか？

199:デフォルトの名無しさん
06/07/07 13:28:48
>>198
なるほど。

200:デフォルトの名無しさん
06/07/07 18:35:27
>>195
forループではないんだが、FPUレジスタの使い方に無駄が出た。
ある関数の最初の方で別のライブラリの関数にfloatの変数渡して、
いくつか別の浮動小数点の処理した後で変更なしで再びその変数を使うんだが、
この間にnop入れるだけでもう一回メモリから読み出すようになった。

>>196
すまんがforループなんて単純な部分ではなく、しかもVC8での話なんだ。

201:デフォルトの名無しさん
06/07/07 20:27:10
インラインアセンブラ挟んで最適化を期待する方がおかしい気がしますが。
しかも複雑な部分なら尚の事。

202:200
06/07/07 21:27:22
>>201
アンカーがないから俺へのレスってことでOKなのか？
おれは__asmブロックで最適化が阻害されるのは当然だと主張してるのであって
最適化されねーぞなんでだヴォケと言ってるわけじゃないんだが。

203:デフォルトの名無しさん
06/07/07 21:36:42
>>200
その話の真偽はおいといて、
>>191 >>194 を読んでそんな風に理解できるかというと、
それはちょっと無理じゃないか。

漏れは 191 の関数の前半と後半という風に読んじゃたよ。
想像力が無いからかもしれないけど。

204:デフォルトの名無しさん
06/07/07 22:01:59
>202
当たり前の結果にムキになってっから、何か不満でもあるのかと思った。

205:デフォルトの名無しさん
06/07/08 09:25:11
>>81
古い話だけど今のICCには_mm_cast*という命令があってこれでキャストできることに気がついた。
VCLにはない。GCCは普通に(__m128)とかでキャストできる。

206:・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6
06/07/08 17:53:16
浮動小数の2倍とか1/2倍とかやるのに指数部を直接整数として足し算引き算すると確かに速いんだよな

AMDが来年予定してる新リビジョン（K8L）でXMMレジスタの下位・上位QWORDと汎用レジスタ命令の値を
相互に交換する追加されるみたいだけど、これってIntelも採用するかのう？
別のニーモニック割り当てるんだろうな。

207:・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6
06/07/08 17:54:25
×汎用レジスタ命令
○汎用レジスタ

208:182
06/07/13 16:03:54
みなさん、どうもありがとうございました。
3DnowやSSEを使えるようになるのを目標にして、機械語を勉強するのに
良い参考書がありましたら、教えていただけませんか。
NWSAというのを見つけて、解説を読んでいますが未知の言葉が山盛りです。

209:デフォルトの名無しさん
06/07/13 16:14:38
SIMDが載ってる本
x86アセンブラ入門
アセンブラ画像処理プログラミング

載ってない本
独習アセンブラ
アセンブリ言語の教科書
糞級言語プログラマのためのアセンブラ入門

210:デフォルトの名無しさん
06/07/13 16:19:02
>>208
fURLﾘﾝｸ(download.intel.co.jp)
URLﾘﾝｸ(homepage1.nifty.com)

211:デフォルトの名無しさん
06/07/13 23:48:16
絶対に買ってはいけない本

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

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

212:デフォルトの名無しさん
06/07/14 00:33:58
「IA-32 インテルアーキテクチャ・ソフトウェア・デベロッパーズ・マニュアル」
を読んでSSEが難しいようだったら多分それを触る前に覚えることがまだまだある。

213:デフォルトの名無しさん
06/07/14 06:06:27
>>212
そうかな。俺はよくわかんないうちから
MMXでガンガンコード作って覚えたけど。

あのマニュアルを読むのは、ある程度
SSEを使えるようになってからでないときついだろう。

214:デフォルトの名無しさん
06/07/14 10:07:33
>>213
212ではないが、あれ読めないって事は結局x86の構造理解出来てないって事だと思うが。
通常命令での効率的な組み方を勉強する方が先じゃね？

215:デフォルトの名無しさん
06/07/15 06:49:15
Core2に搭載されるISSE4っていったいなんだろう。

216:デフォルトの名無しさん
06/07/21 11:50:31
CASL IIやれば十分だよな

217:デフォルトの名無しさん
06/07/27 15:42:54
単純な画像変換とかをMMX化SSE化して
デバッガにかけながら読むとテラわかりやすいお。

218:デフォルトの名無しさん
06/07/28 21:22:59
だれか Core2 に搭載される(た) SSE4 のマニュアルを
ダウンロードできるとこ知らない？
www.intel.com とか探しても全然見当たらない。
まだ非公開かな？
それにしてはベンチマークが対応しているのが不思議．．．。

219:デフォルトの名無しさん
06/07/28 21:39:10
糞団子のページに書いてあるよｗｗｗｗｗｗｗｗｗｗ

220:デフォルトの名無しさん
06/07/28 21:47:56
あれはニーモニックから推測したものでしょ。

TMPGEncだかも対応したよな。
開発者向けには公開してあるってことか？

221:デフォルトの名無しさん
06/07/28 22:00:38
TMPGEncはIntelが金出して最適化してたはず。

222:デフォルトの名無しさん
06/07/28 22:58:59
なるほど。抜け目ないね。
TMPGEncはベンチとしても一般的だからな。

223:デフォルトの名無しさん
06/08/04 10:38:00
推測っていうか、既にICC9.1でこっそり対応してる。組み込み関数も既に用意されてる。
団子のページ引用率高すぎ

224:デフォルトの名無しさん
06/08/14 07:45:54
C言語のプログラムの途中たった一行だけ、計算式をインラインアセンブラで
MMXやSSE、3DNOWに対応させるというのは可能ですか。

225:デフォルトの名無しさん
06/08/14 09:09:05
たった一行だけのためにemmsを使うのはアフォ

226:デフォルトの名無しさん
06/08/14 13:22:18
最低でもループの一番内側丸ごと、じゃないかな。
emmsもｄろうけど、SIMDはデータをレジスタに乗っ
けるところが結構食うからね。

227:・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6
06/08/14 23:22:34
アンロールしまくれ

SSE2の整数命令ってSSE2非対応CPUはMMXの相当命令として解釈されるから
うまく組めばパスの分岐必要なし

228:デフォルトの名無しさん
06/08/29 01:31:22
gccでintrinsic function使ってSSE2,3の処理書きたいんですけど
3年ぐらい前に書くとアライメント指定しても4byteでまとめられたりして
まともに使えなかった記憶があるんだけど今はどうなんですかね？

229:デフォルトの名無しさん
06/08/29 21:46:08
_mm_malloc()かunion共用体使う

230:デフォルトの名無しさん
06/09/14 14:49:48
SSE4の仕様解析出たな

>>226
SIMDのデータ転送のレイテンシが半端なくでかいのはPen4くらい
AthlonやPenM, Core系は整数と大して変わらない

231:デフォルトの名無しさん
06/09/14 15:00:09
ようするにネトバは糞って事？

232:デフォルトの名無しさん
06/09/14 15:57:07
ネトバカッコイイってほざいてたのは雑音だけ。
SIMDとSIMMを間違えるのも雑音だけ。

233:デフォルトの名無しさん
06/09/14 16:57:41
たるさん…

234:・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6
06/09/14 23:04:40
psign*とpalignr間違えてましたすいません。
SSE4って命令部3バイトだからあんまり使えない気が。
XMMレジスタでREXプリフィックス付けたら命令長最低6バイトになる

>>228
ヒープ上に16バイトくらい多めに確保して、返ってきたアドレスに15足して~15でマスク。
Windowsだと、SSEがまともに使えるようになったのがVC7からだと記憶してる。

235:デフォルトの名無しさん
06/09/27 11:49:46
SSE4のレイテンシやスループットの数字って出てる？

236:・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6
06/09/27 22:11:16
非公式ながら、x86の～スレにある。
正式名称はSupplimental-SSE3(SSSE3)になったらしい。

あと、まるも製作所の中の人が色々と考察してた

237:デフォルトの名無しさん
06/09/27 22:28:46
へえ、SSE4じゃなくてSSE3に追加するという形か。

238:デフォルトの名無しさん
06/09/28 20:11:09
長いからSSE4かTNIでいいよ

239:デフォルトの名無しさん
06/09/28 21:16:13
追加って話ならSSSEよりSSE3sのが理にかなってわかりやすいなぁ…

240:デフォルトの名無しさん
06/09/28 21:21:57
Enhanced 3D Now! みたいなものだろう。
ただ、次に命令を追加するときに「SSE4」とされるとややこしいな。

241:デフォルトの名無しさん
06/09/28 21:24:32
次はSSSSE3だな

242:デフォルトの名無しさん
06/09/28 21:31:38
スプラッシュスターSSE3

243:デフォルトの名無しさん
06/09/29 10:58:55
Streaming SIMD Extensions eXtendedにするべきだと思うんだが

244:デフォルトの名無しさん
06/10/05 01:38:11
今後、SSE4はSSE4と呼べばいいが、
SSE3+SSSE3を総称した呼び名はできるのかな。

命令が普及した後で、SSE3と言ったときに、
SSSE3が含まれるかどうかが不明確になりそう。

245:デフォルトの名無しさん
06/10/05 01:39:39
総称がSSE3だろ
ﾌﾟﾚｽｺは要らない子

246:デフォルトの名無しさん
06/10/05 01:50:35
そっか。じゃあ、Prescottと最近のK8だけ仲間外れだ。
あれ、Cyrixの系統のやつも載せてたっけ。

今度はSSE3（総称）の中のSSSE3に含まれない命令の
呼び名がないと不便になるなあ。

247:デフォルトの名無しさん
06/10/05 02:10:26
SSSSSEE33

248:デフォルトの名無しさん
06/10/05 02:18:44
SSE3-FP

249:デフォルトの名無しさん
06/10/05 02:23:10
SSE3-Classical

250:デフォルトの名無しさん
06/10/05 02:24:49
SSE3ESS

251:・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6
06/10/05 02:50:45
PNIとTNI(MNI)でいいじゃん。

PenrynもPだから困る。

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

ところでこのスレも2年以上になるのだが、
今こういうスレを立てるとしたら、3D Now!の名前は入るだろうか。
まあ、2004年と言えばとっくに3D Now!は下火だったが。

253:デフォルトの名無しさん
06/10/16 18:03:24
>>25
この2年前のソースが見てみたい

254:デフォルトの名無しさん
06/10/16 18:07:15
もう2年になるのか・・・。
少し遅れて来て>>25が取れなかったことを
昨日のように思い出す。

255:デフォルトの名無しさん
06/10/16 21:01:22
URLﾘﾝｸ(hitokuso.kicks-ass.org)
２年前のソースをそのまま晒す恥知らずの俺サイコー

256:デフォルトの名無しさん
06/10/16 21:31:14
>>255
こ、更新日時が2004/12/12 10:07！！
俺は特に見たかったわけではないが、>>255はある意味で神。
よかったな、>>32！

257:デフォルトの名無しさん
06/10/16 22:36:18
>>255
すげぇｗ

258:デフォルトの名無しさん
06/11/21 14:43:13
これから、64bitのWindowsが普及してくる（使えるレジスタ倍増）のと、
Core2やK8LでSSE命令のレイテンシは据え置きでスループットが倍になること、
これらによってSSEの使い方がかなり変わってくるだろう。

259:デフォルトの名無しさん
06/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:デフォルトの名無しさん
06/11/29 03:09:59
処理内容に依存するからなあ。
どんなの？

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

最近はCPUが賢いというのも
コンパイラ有利な要因かも。

261:デフォルトの名無しさん
06/11/29 03:44:25
>259
SIMDで最適化するならデータの配置も最適化しないと意味無いぽ。
てかコンパイラ、サンプルコード、計測方法、コアの情報も無く比だけ提示されてもな、って感じ。

262:デフォルトの名無しさん
06/11/29 16:58:12
正直、そのデータ配置の最適化ってのがどういうもんなのかよくわかんね・・・
セオリーとかあるの？

263:デフォルトの名無しさん
06/11/29 17:10:13
インテルのマニュアルにSoAとかAoSとかについて書いてある。

264:デフォルトの名無しさん
06/11/29 21:27:32
何にせよ、どんな処理を高速化したいのか
書いてくれないと話が進まない。

265:デフォルトの名無しさん
06/11/29 22:58:45
>>260
いや、トイプログラムって書いてる通り、1M個くらいのfloat列を
２つ乗算するだけのコード。インラインアセンブラもやったこと
なかったので、最初はインラインアセンブラで書き始めて、途中で
Intel/MS/GNUが全部同じAPIで叩かせてくれると気づいて書き直した。

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

でもコンパイラオプションだけで考えていた以上に性能が接近すると
知ったのは収穫でした。問題の部分に使うクロック数で非SIMDは３倍
程度はかかるかと思ってたから。

266:デフォルトの名無しさん
06/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
06/11/29 23:43:32
結果の格納を別の配列にしてるんならmovntpsが有効なのでつ

x87からライトスルー命令は使えないし、やっぱりSSEまんせー

268:デフォルトの名無しさん
06/11/29 23:52:32
>>266
いやそれがですね、-fprefetch-loop-arrays とかいうオプションが
あってまさにそれやってくれてたんですよ。

わざわざ拡張命令使わなくても限定的ながら自動ベクトルかとかも
してるそうで、もうコンパイラ様々というか。

269:デフォルトの名無しさん
06/11/30 00:00:04
>>267
あ、それを忘れてた。

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

コンパイラの吐いたプリフェッチコードキボンヌ。

270:デフォルトの名無しさん
06/11/30 04:55:32
そもそも機械的な最適化に負けるコード吐いてる次点でSIMDがどうこう言う資格無い。
時々勘違いしてる奴がいるが、アセンブラ化すれば速くなるわけじゃない。
コンパイラで出来ないことをアセンブラで最適化するから速くなる。
MMX/SSE命令並べただけで速くなるならコンパイラだってそうするだろうよ。

271:デフォルトの名無しさん
06/11/30 05:20:08
>>270
コンパイラに負けるから勉強して
SIMDを使えるように頑張るんじゃないか。

272:デフォルトの名無しさん
06/11/30 11:31:10
うん、勉強頑張るのはいいよな。
「コンパイラの最適化で十分」とか結論付けるのは良くないよね。

273:デフォルトの名無しさん
06/11/30 20:51:08
VC8で64bitコードにインラインアセンブラを使えないのが腹立たしい。
MASMだと煩雑だしプリプロセッサも無い。
組み込み関数じゃ思った通りの命令を生成しない。

274:・∀・）っ-○◎●新世紀ダンゴリオン ◆DanGorION6
06/11/30 21:58:25
COFF形式でコード吐きだせば別にアセンブラは何だっておｋだよ。
むしろx64対応のアセンブラそのものが少ないのが問題。

x64でプログラミングやるならVC++Std + PSDK + ICCが一番コストパフォーマンスいいと思う。

275:デフォルトの名無しさん
06/11/30 22:14:39
yasm使ったことある人いる？

276:デフォルトの名無しさん
07/01/31 07:50:32
インラインうぜーよ
モジュール分けろやボケが

277:デフォルトの名無しさん
07/02/18 10:10:27
裏切派遣って知ってる？
元々は正社員だったのに取引先にフリーのほうが稼げるとか騙されて派遣やってるバカのことｗ

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

自分でも騙され裏切れられてることは薄々わかってるから派遣問題の話が出るとウッキー！って逆ギレｗ

278:デフォルトの名無しさん
07/03/03 01:15:50
URLﾘﾝｸ(krypton1.at.infoseek.co.jp)

279:デフォルトの名無しさん
07/03/03 09:39:36
そんなサイトよか光成さんの方がよい

280:デフォルトの名無しさん
07/03/03 13:19:31
>>279
光成さんって?

281:デフォルトの名無しさん
07/03/03 14:24:27
光成 SSE
でぐぐったらこんなページに出会った。
URLﾘﾝｸ(homepage1.nifty.com)

あー、確かにこれはいいものだわ。

282:デフォルトの名無しさん
07/03/03 15:17:55
>>281
XBYAK
なんじゃこりゃ、すげぇ

283:デフォルトの名無しさん
07/03/04 06:38:58
むしろこのスレで知らない人が居るのに驚いた訳だが

284:デフォルトの名無しさん
07/03/05 10:04:48
禿同

285:デフォルトの名無しさん
07/03/13 21:08:56
今更ながら MMX を使用した MMX_MemCpy() を作ってみたが普通の memcpy() と10%も速度が変わらなくて萎えた…

286:・∀・）っ-○◎●
07/03/13 22:33:09
FSBで律速されるからね。
キャッシュ内で使う場合は十分意味ある。

287:デフォルトの名無しさん
07/03/13 22:56:37
>>286の言う通りメモリの速度に依存する。
それに64byteとか128byteごとにキャッシュされるんだから
4byteずつコピーしようが8byteずつコピーしようが殆ど同じ。
重要なのはプリフェッチ。

L1のサイズをきちんと考慮してプリフェッチしてからmemcpy()を繰り返してもいけたりして。

288:285
07/03/14 07:59:02
そうなのか…
8Byte境界なら MM7 レジスタまで使用して64Byte転送するとかやってみたんだが同じなのか。orz

289:名無し募集中。。。
07/03/14 21:13:59
数%でも高速化されるならそれは凄い事だと思うよ

290:デフォルトの名無しさん
07/03/14 21:42:23
後は用途によってノンテンポラル関連を使うとかだよな。

291:285
07/03/15 23:32:55
>>289
最初はそう思おうとしたが、さらに速いマシンで実行したら効果がさらに薄くなったんだよつД｀
1Gコピーしても50msも変わんねぇ

292:・∀・）っ-○◎●
07/03/15 23:38:30
そんな大容量のコピーするからこそかわらんのですよ
キャッシュの中でうまく捏ね回すのがSIMDプログラミングの掟

293:デフォルトの名無しさん
07/03/15 23:42:26
正直単純なメモリ転送を最適化する暇があるなら、転送中ヒマをもてあましてる演算器の活用方法でも考えたほうが。

294:デフォルトの名無しさん
07/03/19 13:38:50
32bitのDIB(R8G8B8A8)を24bitのDIB(R8G8B8)にアルファブレンドする関数を書いているのですが、
Cでテーブルを使って実装すると、テーブルへのアクセスがボトルネックとなって、
他の処理と比べて重くなってしまいます（テーブルは256x512x4で、L2にも入らない）。
そこでMMXを使ってみようと考えたのですが、
MMX命令を用いた計算方法そのものは分かるものの、
ピクセル単位の異なる二つの画像を、上手くMMXレジスタに配置する方法が分かりません。
どなたかご教授下さいませんか。
＃どちらのDIBも、横幅が8の倍数であることは保障されています。

295:デフォルトの名無しさん
07/03/19 14:25:33
mov ecx, pixelcnt
mov esi, DIB32
mov edi, DIB24
label:
mov mm0, esi
mov mm1, edi
--なんか処理--
add esi, 4
add edi, 3
loop label
後は最初か最後にediからの読み込みに1Byte前後して読んでシフトする処理が必要になるけど、
ループの外で処理すればいいし、テーブル参照するよりゃ速いんじゃね？

296:デフォルトの名無しさん
07/03/20 13:51:06
>>295
どうもありがとうございます。
シフト処理を入れたら上手く配置できて、
二倍近く速度が出るようになりました。

297:デフォルトの名無しさん
07/04/04 17:21:13
>295
どーでもいいけど、
mov mm0, [esi]
mov mm1, [edi]
じゃね？

298:・∀・）っ-○◎●
07/04/04 21:13:55
っていうかmovdじゃね

299:デフォルトの名無しさん
07/04/05 02:13:45
movq な。

300:デフォルトの名無しさん
07/04/05 02:18:01
あ、この場合movqでなくてmovdになるか…。

301:デフォルトの名無しさん
07/04/06 04:15:49
つまり団子は普通に名無しで潜伏してる

302:・∀・）っ-○◎●
07/04/06 21:41:06
イミフ

303:デフォルトの名無しさん
07/05/26 14:50:25
URLﾘﾝｸ(www.cutt.co.jp)

こんな本が出てるね。初学者にはありがたいかも。
SSSE3やSSE4の解説は載ってないっぽいけど、仕方ないか・・・。

304:デフォルトの名無しさん
07/05/26 20:06:23
上下で都合2ﾏｿ取ろうっての？ボッタクリ過ぎだろ。
x86アセンブラ入門＋IntelのPDFで十分。

305:・∀・）っ-○◎●
07/05/27 16:37:14
>>303
要らん

操作画面の横でPDF表示する為のサブディスプレイを2万で買ったほうが有意義

306:デフォルトの名無しさん
07/05/27 16:53:13
ひでぇ商売だ

307:・∀・）っ-○◎●
07/05/27 16:59:20
著者の情報調べてみた
URLﾘﾝｸ(www.vector.co.jp)

最近の作品さっぱり無いな

308:デフォルトの名無しさん
07/05/27 17:41:16
mmxって廃止なの？
代わりに何をつかえばいいの？

309:デフォルトの名無しさん
07/05/27 17:44:22
>>303
不要。
最近のコンパイラは、SSEを自動的に使ってくれる。
むしろ、その最適化にやさしいコードを書いた方がよい。
手動で最適化したところで、大抵数パーセントも上がらない。

310:・∀・）っ-○◎●
07/05/27 18:29:03
SIMD Intrinsicsの解説やってる実践的な本のほうが欲しいな。
それもIntelで十分か。
どうせならAltiVecとかCellのSPUとかも扱って移植性とパフォーマンスを両立する方法とかね。

311:デフォルトの名無しさん
07/05/27 22:26:02
>>310
Intrinsicsの解説自体はコンパイラのドキュメント読めば十分理解できるだろ。
むしろ実践的なアルゴリズムをいかにSIMDに落とし込むかという話のほうが読み応えないか？

312:デフォルトの名無しさん
07/05/28 18:33:00
>>309
アセンブラでSSE使うことが不要というのは言いすぎだと思う。
まあ、結果としてこの本が不要という結論にはなるだろうが。

313:デフォルトの名無しさん
07/05/30 00:27:06
>>310
移植とかは、COINSにお任せしておけば良いのでは

314:デフォルトの名無しさん
07/05/30 00:50:18
金融SE、プログラマにこの辺やOpenMPのHPC系技術をおぼえてほしいんだがな。
誰もわからんからユーザーの俺がプログラミング。どういうこっちゃ。

315:デフォルトの名無しさん
07/05/30 00:59:53
金融で、そんなにシングルスレッド性能がいるの？？

316:デフォルトの名無しさん
07/05/30 01:07:04
金融の一部の分野は大量データの高速計算や
複雑な計算を瞬時に行う必要がある。

317:デフォルトの名無しさん
07/05/31 07:57:11
へー、どんな計算？

318:デフォルトの名無しさん
07/05/31 16:21:28
>>316
こういう奴ってさも物事を大げさに書きたがるが、具体的な例や数字は
一つも書かないから結局何を言っているのかさっぱりわからないんだよな。

319:デフォルトの名無しさん
07/05/31 19:24:02
>>318
こういう想像力の無い奴に物事を説明するのって疲れるんだよな

320:デフォルトの名無しさん
07/05/31 19:56:50
想像力……ｗｗｗ

321:デフォルトの名無しさん
07/05/31 20:09:35
>>318
デリバのプライシングとか、ALMでのVaR計算とかなんだが詳しく書いても
多分分らんと思うが。

322:デフォルトの名無しさん
07/05/31 20:29:00
知らないことを想像しろと言われても、ヒントもなしでは結構難しいと思うのだが。

323:デフォルトの名無しさん
07/05/31 20:31:13
リロードしてなかったorz

324:デフォルトの名無しさん
07/05/31 20:37:36
>321
それは具体的な「業務内容」であって、具体的な「例」でも「数字」でも無いと思うんだ。
ここが金融系の板ならそれで通じるかもしれんが、ここはム板だから。
例えば必要精度何桁でどんな数式を秒間何万件処理する必要があるとか、そういうこと。
専門用語でお茶を濁す事は具体例では無い。

325:デフォルトの名無しさん
07/05/31 20:52:19
>>324
たとえば百万件のデータから求める解を得るためにニュートン法等を数種類、複数回駆使ししたり
モンテカルロシミューレーションで数十万回の試行を行ったりといったこと。

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

ってとこ。

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

がちがちにコーディングする暇があるなら速くなるかもしれないけど
そんなことで工数がホイホイ増えるくらいなら計算機にお金使ったほうがマシ。

327:デフォルトの名無しさん
07/05/31 22:00:56
>>326
高速化するために数学的手法を駆使したMCなんだが
MCがすべて単純な繰り返しと思っているレベルの頭脳では話にならん。

328:デフォルトの名無しさん
07/05/31 22:27:38
>327
お前プログラマじゃないだろ？
具体例の無い説明といい、「ｘｘを駆使」とかいかにも営業が使いそうな言い回しといい、胡散臭すぎる。

329:デフォルトの名無しさん
07/05/31 22:35:50
>>328
流れを読め。

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

また別にお前に依頼してる訳ではないから具体的に書く必要性もない。

330:デフォルトの名無しさん
07/05/31 23:43:09
以下、「お前こそ」禁止。

331:デフォルトの名無しさん
07/06/01 00:14:39
うーむ、よくみりゃ誤字ってたな。

>>327
MCが単純って書いた覚えはないよ。
金融工学の問題ってSIMDがクリティカルに利いてくるような
単純な代数計算なのかって話。

332:デフォルトの名無しさん
07/06/01 00:43:42
たとえばExceで用意されているNormdistといった確率分布関数のようなものは
商用ライブラリーを購入する手があるが、処理スピードと精度のトレードオフの調整が利かない。

これをCで組むと四則演算+EXPの多用となる。普通にプログラミングするとかなり遅いがSIMDを使うと大幅に
高速化する。SIMDにEXPがあると良いのだが。

333:・∀・）っ-○◎●
07/06/01 00:59:18
その辺はニュートン法使ったりテーラー展開したり。
Intelが数学用ライブラリ出してなかった？

x87のアレはどうせマクロ命令なので。
ちなみにdivpsとかで得られる商は近似値で精度低い。

334:デフォルトの名無しさん
07/06/01 01:06:33
標準関数よりニュートンのほうが早いってことあるのか？
ニュートンは方程式を解くのに多用するが初期値問題があるしな。

MKLのEXPは使い方によるだろうが、メモリにデータを貯める必要があるときは高速だろうが
そうでないとメモリアクセスの遅さがネックになってあまり役立たない。

335:・∀・）っ-○◎●
07/06/01 01:12:44
SIMDで組み直せば標準関数のスループット越えることなんてざらにあるよ。
あくまでSIMD使うからこそ意味があるんだけど。

336:デフォルトの名無しさん
07/06/01 01:24:31
へ-そうなんだ。
とすれば試してみる価値あるな。

expのニュートンは簡単そうだし。。。
初期値どうするかな

337:デフォルトの名無しさん
07/06/01 01:33:41
金融の問題って収束が遅いモンテカルロでどうにかなるのか。

338:デフォルトの名無しさん
07/06/01 01:37:50
使わないですめばそれにこしたことはない。
解析的に求める方法がなければモンテカルロを使うしかない。
という理由で使われる。

339:デフォルトの名無しさん
07/06/01 09:24:19
結局金融には直接関係ない部分の話になっちゃったね。

340:デフォルトの名無しさん
07/06/02 00:29:40

>>335
よく考えたら　f(x)=exp(x)で　f'(x)=exp(x)だからexpをニュートンで求めるのは無理だな。
　
テーラー展開でやってみたんだが
・テーラー展開式　exp(x)=∑x^n/n!
・階乗部分をすべて初期値設定
0!:n0=1
1!:n1=1
2!:n2=2
・・・
x:入力値
expsse:求める値

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

こんな感じ。for分使わずn=20までやって精度９桁くらいだったかな。
しかし処理時間は非常に遅かった。
時間がなかったのであまり詳しく調べなかったがコーディングに問題あるかな？

341:デフォルトの名無しさん
07/06/05 01:32:46
Visual C++ 2005 で ssse3 の intrinsics が使えるようだ

342:・∀・）っ-○◎●
07/06/05 06:08:53
いつのまにSSSE3まで使えるようになったのか
インラインアセンブラのニーモニックは使えるが

343:デフォルトの名無しさん
07/06/05 14:01:57
>342
お前が>333でネタ振ったんだから責任もって>340のフォローしろや

344:・∀・）っ-○◎●
07/06/05 19:50:20
レイテンシのチェインがある mulpd→divpd→addpd
対象データが複数あるなら複数インターリーブするとスループットが稼げます。

345:デフォルトの名無しさん
07/06/05 20:33:01
>>344
その理論で行けばSPEのスカラも多くはスループット1クロックで処理出来るんだがな。
つーかx86にその理論を適用するにはレジスタが足(ry

346:・∀・）っ-○◎●
07/06/05 20:34:12
レジスタリネーム

347:・∀・）っ-○◎●
07/06/05 20:39:13
XORでゼロクリアしたり（Core 2からSIMDレジスタにも適用）
データ移動（部分データ移動は不可）するとレジスタリネームのヒントになる

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

Cellの演算ユニットはIntelアーキのそれの倍のレイテンシがかかる。
SPEのスカラが性能でないのは、そもそもベクタ化すら出来ないデータを
並列処理でレイテンシ隠蔽するには限界があるから。

348:デフォルトの名無しさん
07/06/05 21:00:36
演算器が先にストールする。

349:デフォルトの名無しさん
07/06/05 21:06:06
連投失礼。
レジスタリネームとかって言ってる人のコードの書き方に興味がある。
よっぽどコンパクトな演算じゃない限り演算結果をレジスタから追い出さなきゃいけないと思うんだが。

350:デフォルトの名無しさん
07/06/05 21:36:42
問題は十分な精度が得られないことだと思う

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

定数除算を逆数との乗算に置き換える
↓
a4*x^4 +a3*x^3 +a2*x^2 +a1*x + a0
↓
(((a4*x+a3)*x+a2)*x+a1)*x+a0
↓
tmp=a[N]
for(i=N-1;i>=0;i--) tmp=tmp*x+a[i]
↓
(初期化部分は省略)
LOOP:
mulpd xmm4, xmm0
mulpd xmm5, xmm1
mulpd xmm6, xmm2
mulpd xmm7, xmm3
addpd xmm4, [esi]
addpd xmm5, [esi]
addpd xmm6, [esi]
addpd xmm7, [esi]
add esi, 16
sub ecx, 1
jnz LOOP

351:・∀・）っ-○◎●
07/06/05 21:50:00
いや除算は近似値命令だから乗算に置き換えるだけである程度
精度確保できるんじゃないの？

Intelはx87倍精度は内部的に80ビット精度に展開して処理してるけど
SSEは精度度外視してたような。
精度が必要ならx87のほうがいいかもしれない

352:デフォルトの名無しさん
07/06/05 22:11:04
近似値なのはrcpps,rsqrtps命令で、
divpsは近似値じゃないんじゃない？

353:・∀・）っ-○◎●
07/06/05 22:21:41
いや近似値。内部的に逆数近似値と乗算してるだけ。

354:・∀・）っ-○◎●
07/06/05 22:22:19
ちなみに本物の除算は何十クロックもかかりますから。

355:デフォルトの名無しさん
07/06/05 22:28:36
>>353
そのソースは？
rcppsのレイテンシとmulpsのレイテンシを足しても
divpsのレイテンシよりずっと短いよ。
インテルの命令セットマニュアルには
rcpps,rsqrtpsの説明には近似値であると明記してあるけど、
divpsには近似値なんて書いてないよ。

356:デフォルトの名無しさん
07/06/05 22:32:08
x87を比較対象にしてるでしょ。
そら80bitなら何十クロックもかかるわな。

357:デフォルトの名無しさん
07/06/05 23:08:46
>>350
スマン、教えてほしい
（アセンブラは苦手なだが)多項式近似のパタンは和算→乗算の繰り返しでやるしかないという認識なのだが
乗算を先に4つやって、あとから和算4つ行うって計算は可能なのか？

358:>>357
07/06/05 23:13:47
>>344
> 対象データが複数あるなら複数インターリーブするとスループットが稼げます。

359:デフォルトの名無しさん
07/06/05 23:31:26
>>358
そういう手があるのか
サンクス

360:・∀・）っ-○◎●
07/06/06 00:30:48
>>340と>>350の式が一致してない気がするの気のせい？

361:・∀・）っ-○◎●
07/06/06 00:31:53
>>355
すまんそうだったかも。
ただ仮数部全部厳密に求めるほど精度なかったと思う

362:デフォルトの名無しさん
07/06/06 00:34:38
>>360
別物。テーラー展開とチェビシェフ系の違い。

363:350
07/06/06 01:01:20
>>360
>>340のテーラー展開式とintrinsicsでの実装が一致していない

364:340
07/06/06 19:11:56
>>344
回答ありがとう。
俺の知識ではいま一つ分らんが命令の並び順に工夫がいるということと
他のデータも同時に処理できたら同時に行うということかな。

>>363
確かに最初がまちがっとる。記述ミスなのできにしないでくだはれ。
ま、exp（）だと近似式でやったほうが速そうだね。

365:340
07/06/06 19:15:18
ところで金融システムをやる人たちはこの辺の技術を
ほとんど知らないのだけれど皆さんはどの分野でやられてるのでしょうか？

366:デフォルトの名無しさん
07/06/06 21:54:11
信号処理とかゲームじゃないかな。
逆に聞きたいのは、金融の分野で応用効くの？
桁数が必要だろうし、スピードよりも可読性が求められそうじゃ無い？

367:340
07/06/06 23:23:51
金融では最近一部グリッドが導入されだしたようだけど
HPC分野はほとんど未開拓な状態だと思う。
またSIMDとかMPIなどは外資パッケージソフトの一部では使われている。

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

という状況下、前にも挙げたようにリスク管理やデリバティブ関連などでは高速化へのニーズは高く、
この辺からHPC化が進んでいくと思う。
現時点では、すぐ欲しい計算結果も下手をすると数日かかるといったことが、あたりまえにおこなわれているから・・・

368:・∀・）っ-○◎●
07/06/06 23:36:08
っていうかmsdn2みたけど
VC++だと数学関数はSSE2対応ならSSE2版使ってくれるようになってるみたい？

純正の最適化ルーチンより速くしようと考えるのはぶっちゃけかなり無謀かと。

369:340
07/06/06 23:57:04
exp()はそれほど問題になっていないからいいんだけど
問題は上に書いたことなんだ。

皆さん、金融システムやらないかい？

370:デフォルトの名無しさん
07/06/07 01:16:32
仕事にする気はないが話題として興味はあるな。
重たいのはDBとかで、SIMD化するようなものでは無いイメージがある。

371:デフォルトの名無しさん
07/06/07 01:19:32
そんなのアプリによるのでは？

372:デフォルトの名無しさん
07/06/07 01:23:59
書き込みタイミングも全体パフォーマンスには注意が必要

373:デフォルトの名無しさん
07/06/18 23:11:59
【派遣ネガティブ根性チェック】

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

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

374:デフォルトの名無しさん
07/06/22 00:18:26
ねぇねぇこれSSE使ってかける？

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

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

return (hash & 0x7FFFFFFF); //Returns the hashed string
}

375:デフォルトの名無しさん
07/06/22 00:43:56
PMULUDQか。
2つの文字列を同時に処理するなら使えるかな？

376:・∀・）っ-○◎●
07/06/22 00:54:28
intは32ビットね？

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

依存関係がきれいに解決できてpmaddwdが適用できれば速くはなりそうだが。

377:・∀・）っ-○◎●
07/06/22 00:55:54
>>375
ああそっちがあったかど忘れしてた

378:・∀・）っ-○◎●
07/06/22 01:07:24
ループの内側を２倍に引き伸ばすとこうか？

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

引き伸ばしていけば並列演算できそうなところは結構あるんだが、さて・・・
ああ頭いてぇ

379:デフォルトの名無しさん
07/06/22 01:46:48
SSE入門したいのですが
みんなどこから手をつけはじめたのですか？

380:341
07/06/22 02:34:18
使い方
intrin.hをインクルードすることでSSE3のintrinsicsまでは使える
SSSE3のintrinsicsは自前で各命令を定義することで使えようになる

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

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

問題点
palignr命令の3番目の引数が定数でもエラーにならない

381:341
07/06/22 02:38:44
>>380の訂正
問題点
palignr命令の3番目の引数が『定数でない場合に』エラーにならない

382:デフォルトの名無しさん
07/06/22 15:15:51
>>379
俺も最初はこんなのから始めて動作を確認していった。
（この書き方、aがポインタか配列かって区別がややこしいんだが）

#include<stdio.h>
int main()
{
int i,a[]={12,23,34,45};
__asm{
movdqu xmm0,a
paddd xmm0,xmm0
movdqu a,xmm0
}
for (i=0; i<4; i++) printf("%d\n",a[i]);
return 0;
}

383:・∀・）っ-○◎●
07/06/22 23:23:53
>>381
すまん意味不明。エラーにならないならどんなコード吐くの？

384:341
07/06/23 00:28:50
定数の場合
0f 3a 0f c1 01 palignr mm0, mm1, 1

定数でない場合
0f 3a 0f c1 ac palignr mm0, mm1, DWORD PTR _i$[ebp]

385:デフォルトの名無しさん
07/06/23 09:10:46
IA-32 SIMDリファレンス買ってみた。

図がいぱい載ってるぞw

386:デフォルトの名無しさん
07/06/24 09:40:42
>>340
exp(x)=2^(y1+y2)と変換する（y1は整数部y2は少数部）
y2を多項式近似で求めると速くできる
10桁程度の精度でよければ7次で可能
>>465

387:デフォルトの名無しさん
07/06/28 12:38:59
>exp(x)=2^(y1+y2)と変換する（y1は整数部y2は少数部）
それをやるならy1は整数、y2は-0.5<=y2<0.5と選んだ方がよさそうだね。

388:デフォルトの名無しさん
07/06/29 01:19:41
＞＞３８７
そうだね。
ところでｙ１が正のときはビットシフトで行けるんだが
負の時はいい方法ないかね？

389:デフォルトの名無しさん
07/06/29 12:06:17
IA-32SIMDリファレンスブック
こんな本が出てるね

390:デフォルトの名無しさん
07/06/29 13:24:55
>>303-309

391:デフォルトの名無しさん
07/07/03 22:32:30
書店でぱらっと見た感じではSSSE3まで紹介してるみたいだけど
これでどうやって下巻を書くつもりなんだろう

392:デフォルトの名無しさん
07/07/08 00:12:54
誰かSSE2にrcppdとrsqrtpdがない理由を合理的に説明してください

393:デフォルトの名無しさん
07/07/08 00:20:39
あえて近似解をDoubleで使う必要はないからだろう

394:デフォルトの名無しさん
07/07/08 01:16:16
SSEのrcpps,rsqrtpsって
｜相対誤差｜≦ 1.5×2^-12
って書いてあるから、
仮数部12bitくらいの精度しかないって事だよね？

395:デフォルトの名無しさん
07/07/08 01:17:58
rcppsからもってけるから。命令数も倍になるがな。
そして倍精度にそんなトランジスタ割けないというのが合理的理由だろう。

396:395
07/07/08 01:27:58
あー失礼。トランジスタを割けないという主張は同じなんだが
仕組みとしてはテーブルを引いてるだけのはず。
だから24bitとか32bit分ものテーブルを用意出来るわけが無い。

倍精度を使うような人は精度重視なわけで、
divpdあるんだからどうしてもやりたいんだったらソフトウェアでrcppsから精度上げてくれ、
マイクロコードを用意するのはバカバカしい、ということ。

次ページ