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

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 2chのread.cgiへ]
Update time : 10/27 07:58 / Filesize : 141 KB / Number-of Response : 567
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

1 名前：デフォルトの名無しさん [04/05/28 22:00]: どうぞ
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使ったことある人いる？
276 名前：デフォルトの名無しさん mailto:sage [2007/01/31(水) 07:50:32 ]: インラインうぜーよ
モジュール分けろやボケが
277 名前：デフォルトの名無しさん [2007/02/18(日) 10:10:27 ]: 裏切派遣って知ってる？
元々は正社員だったのに取引先にフリーのほうが稼げるとか騙されて派遣やってるバカのことｗ

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

自分でも騙され裏切れられてることは薄々わかってるから派遣問題の話が出るとウッキー！って逆ギレｗ
278 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 01:15:50 ]: krypton1.at.infoseek.co.jp/x86/x86ext.htm
279 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 09:39:36 ]: そんなサイトよか光成さんの方がよい
280 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 13:19:31 ]: >>279
光成さんって?
281 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 14:24:27 ]: 光成 SSE
でぐぐったらこんなページに出会った。
homepage1.nifty.com/herumi/index.html

あー、確かにこれはいいものだわ。
282 名前：デフォルトの名無しさん mailto:sage [2007/03/03(土) 15:17:55 ]: >>281
XBYAK
なんじゃこりゃ、すげぇ
283 名前：デフォルトの名無しさん mailto:sage [2007/03/04(日) 06:38:58 ]: むしろこのスレで知らない人が居るのに驚いた訳だが
284 名前：デフォルトの名無しさん mailto:sage [2007/03/05(月) 10:04:48 ]: 禿同
285 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 21:08:56 ]: 今更ながら MMX を使用した MMX_MemCpy() を作ってみたが普通の memcpy() と10%も速度が変わらなくて萎えた…
286 名前：・∀・）っ-○◎● mailto:sage [2007/03/13(火) 22:33:09 ]: FSBで律速されるからね。
キャッシュ内で使う場合は十分意味ある。
287 名前：デフォルトの名無しさん mailto:sage [2007/03/13(火) 22:56:37 ]: >>286の言う通りメモリの速度に依存する。
それに64byteとか128byteごとにキャッシュされるんだから
4byteずつコピーしようが8byteずつコピーしようが殆ど同じ。
重要なのはプリフェッチ。

L1のサイズをきちんと考慮してプリフェッチしてからmemcpy()を繰り返してもいけたりして。
288 名前：285 mailto:sage [2007/03/14(水) 07:59:02 ]: そうなのか…
8Byte境界なら MM7 レジスタまで使用して64Byte転送するとかやってみたんだが同じなのか。orz
289 名前：名無し募集中。。。 mailto:sage [2007/03/14(水) 21:13:59 ]: 数%でも高速化されるならそれは凄い事だと思うよ
290 名前：デフォルトの名無しさん mailto:sage [2007/03/14(水) 21:42:23 ]: 後は用途によってノンテンポラル関連を使うとかだよな。
291 名前：285 mailto:sage [2007/03/15(木) 23:32:55 ]: >>289
最初はそう思おうとしたが、さらに速いマシンで実行したら効果がさらに薄くなったんだよつД｀
1Gコピーしても50msも変わんねぇ
292 名前：・∀・）っ-○◎● mailto:sage [2007/03/15(木) 23:38:30 ]: そんな大容量のコピーするからこそかわらんのですよ
キャッシュの中でうまく捏ね回すのがSIMDプログラミングの掟
293 名前：デフォルトの名無しさん mailto:sage [2007/03/15(木) 23:42:26 ]: 正直単純なメモリ転送を最適化する暇があるなら、転送中ヒマをもてあましてる演算器の活用方法でも考えたほうが。
294 名前：デフォルトの名無しさん mailto:sage [2007/03/19(月) 13:38:50 ]: 32bitのDIB(R8G8B8A8)を24bitのDIB(R8G8B8)にアルファブレンドする関数を書いているのですが、
Cでテーブルを使って実装すると、テーブルへのアクセスがボトルネックとなって、
他の処理と比べて重くなってしまいます（テーブルは256x512x4で、L2にも入らない）。
そこでMMXを使ってみようと考えたのですが、
MMX命令を用いた計算方法そのものは分かるものの、
ピクセル単位の異なる二つの画像を、上手くMMXレジスタに配置する方法が分かりません。
どなたかご教授下さいませんか。
＃どちらのDIBも、横幅が8の倍数であることは保障されています。
295 名前：デフォルトの名無しさん mailto:sage [2007/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 名前：デフォルトの名無しさん mailto:sage [2007/03/20(火) 13:51:06 ]: >>295
どうもありがとうございます。
シフト処理を入れたら上手く配置できて、
二倍近く速度が出るようになりました。
297 名前：デフォルトの名無しさん mailto:sage [2007/04/04(水) 17:21:13 ]: >295
どーでもいいけど、
mov mm0, [esi]
mov mm1, [edi]
じゃね？
298 名前：・∀・）っ-○◎● mailto:sage [2007/04/04(水) 21:13:55 ]: っていうかmovdじゃね
299 名前：デフォルトの名無しさん mailto:sage [2007/04/05(木) 02:13:45 ]: movq な。
300 名前：デフォルトの名無しさん mailto:sage [2007/04/05(木) 02:18:01 ]: あ、この場合movqでなくてmovdになるか…。
301 名前：デフォルトの名無しさん mailto:sage [2007/04/06(金) 04:15:49 ]: つまり団子は普通に名無しで潜伏してる
302 名前：・∀・）っ-○◎● mailto:sage [2007/04/06(金) 21:41:06 ]: イミフ
303 名前：デフォルトの名無しさん mailto:sage [2007/05/26(土) 14:50:25 ]: ttp://www.cutt.co.jp/book/4-87783-169-1.html

こんな本が出てるね。初学者にはありがたいかも。
SSSE3やSSE4の解説は載ってないっぽいけど、仕方ないか・・・。
304 名前：デフォルトの名無しさん mailto:sage [2007/05/26(土) 20:06:23 ]: 上下で都合2ﾏｿ取ろうっての？ボッタクリ過ぎだろ。
x86アセンブラ入門＋IntelのPDFで十分。
305 名前：・∀・）っ-○◎● mailto:sage [2007/05/27(日) 16:37:14 ]: >>303
要らん

操作画面の横でPDF表示する為のサブディスプレイを2万で買ったほうが有意義
306 名前：デフォルトの名無しさん mailto:sage [2007/05/27(日) 16:53:13 ]: ひでぇ商売だ
307 名前：・∀・）っ-○◎● mailto:sage [2007/05/27(日) 16:59:20 ]: 著者の情報調べてみた
ttp://www.vector.co.jp/vpack/browse/person/an001828.html

最近の作品さっぱり無いな
308 名前：デフォルトの名無しさん [2007/05/27(日) 17:41:16 ]: mmxって廃止なの？
代わりに何をつかえばいいの？
309 名前：デフォルトの名無しさん mailto:sage [2007/05/27(日) 17:44:22 ]: >>303
不要。
最近のコンパイラは、SSEを自動的に使ってくれる。
むしろ、その最適化にやさしいコードを書いた方がよい。
手動で最適化したところで、大抵数パーセントも上がらない。
310 名前：・∀・）っ-○◎● mailto:sage [2007/05/27(日) 18:29:03 ]: SIMD Intrinsicsの解説やってる実践的な本のほうが欲しいな。
それもIntelで十分か。
どうせならAltiVecとかCellのSPUとかも扱って移植性とパフォーマンスを両立する方法とかね。
311 名前：デフォルトの名無しさん mailto:sage [2007/05/27(日) 22:26:02 ]: >>310
Intrinsicsの解説自体はコンパイラのドキュメント読めば十分理解できるだろ。
むしろ実践的なアルゴリズムをいかにSIMDに落とし込むかという話のほうが読み応えないか？
312 名前：デフォルトの名無しさん mailto:sage [2007/05/28(月) 18:33:00 ]: >>309
アセンブラでSSE使うことが不要というのは言いすぎだと思う。
まあ、結果としてこの本が不要という結論にはなるだろうが。
313 名前：デフォルトの名無しさん mailto:sage [2007/05/30(水) 00:27:06 ]: >>310
移植とかは、COINSにお任せしておけば良いのでは
314 名前：デフォルトの名無しさん mailto:sage [2007/05/30(水) 00:50:18 ]: 金融SE、プログラマにこの辺やOpenMPのHPC系技術をおぼえてほしいんだがな。
誰もわからんからユーザーの俺がプログラミング。どういうこっちゃ。
315 名前：デフォルトの名無しさん mailto:sage [2007/05/30(水) 00:59:53 ]: 金融で、そんなにシングルスレッド性能がいるの？？
316 名前：デフォルトの名無しさん mailto:sage [2007/05/30(水) 01:07:04 ]: 金融の一部の分野は大量データの高速計算や
複雑な計算を瞬時に行う必要がある。
317 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 07:57:11 ]: へー、どんな計算？
318 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 16:21:28 ]: >>316
こういう奴ってさも物事を大げさに書きたがるが、具体的な例や数字は
一つも書かないから結局何を言っているのかさっぱりわからないんだよな。
319 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 19:24:02 ]: >>318
こういう想像力の無い奴に物事を説明するのって疲れるんだよな
320 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 19:56:50 ]: 想像力……ｗｗｗ
321 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 20:09:35 ]: >>318
デリバのプライシングとか、ALMでのVaR計算とかなんだが詳しく書いても
多分分らんと思うが。
322 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 20:29:00 ]: 知らないことを想像しろと言われても、ヒントもなしでは結構難しいと思うのだが。
323 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 20:31:13 ]: リロードしてなかったorz
324 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 20:37:36 ]: >321
それは具体的な「業務内容」であって、具体的な「例」でも「数字」でも無いと思うんだ。
ここが金融系の板ならそれで通じるかもしれんが、ここはム板だから。
例えば必要精度何桁でどんな数式を秒間何万件処理する必要があるとか、そういうこと。
専門用語でお茶を濁す事は具体例では無い。
325 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 20:52:19 ]: >>324
たとえば百万件のデータから求める解を得るためにニュートン法等を数種類、複数回駆使ししたり
モンテカルロシミューレーションで数十万回の試行を行ったりといったこと。

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

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

がちがちにコーディングする暇があるなら速くなるかもしれないけど
そんなことで工数がホイホイ増えるくらいなら計算機にお金使ったほうがマシ。
327 名前：デフォルトの名無しさん mailto:sage [2007/05/31(木) 22:00:56 ]: >>326
高速化するために数学的手法を駆使したMCなんだが
MCがすべて単純な繰り返しと思っているレベルの頭脳では話にならん。

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

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