08/02/25 16:18:51
>>270
数式演算すればいいんじゃね？
Mathematicaと言わず、HP49Gくらいでいいじゃん。
272:デフォルトの名無しさん
08/02/25 18:57:53
URLﾘﾝｸ(rayn.ld.infoseek.co.jp)
273:デフォルトの名無しさん
08/02/25 20:15:51
>269
言い換えてみる。
最初から無限長のバイト列（0で初期化済）があったとしても
サイコロを振るなりしてその中を埋める作業が永遠に終わらない
ので結局実数を表現することは無理。
とはいえ中を埋め続けるアルゴリズム（時間がたつほど精度が
上がる）があるような実数ならその実数はきちんと定義されたと
いえる。でそのような実数は可算無限個しかない。
>270
循環小数だとわかってるならそこまで格納できればいい。
1/3 = 1/(2^2-1) = 0.010101...(2)
1/7 = 1/(2^3-1) = 0.001001...(2)
1/3*1/7 = 1/21 = 3/1/(2^6-1) = 0.000011000011...(2)
周期aの数と周期bの数を掛けたら結果の周期はa*bかその約数
結果の周期の分だけ循環部分を展開して掛ければ
正しい結果を取り出せるのかな？
（結局は分数で扱うのが一番簡単そうに見えるのが）
>272
うーんなんだこりゃ
274:デフォルトの名無しさん
08/02/25 20:20:31
よく考えたら間違ってる
1/3*1/3 = 1/9 = 7/(2^6-1) = 0.000111000111...(2)
275:デフォルトの名無しさん
08/02/25 20:43:36
不可算無限を実現する必要は無いと思う。
実際の問題で扱う値ってある程度限定されてるから、
その実際に扱う値さえ表現できればそれで現実的には十分だと思う。
ただ、それでも無理な事もあるかもしれないけどね。
276:デフォルトの名無しさん
08/02/25 23:22:17
>>273
>周期aの数と周期bの数を掛けたら結果の周期はa*bかその約数
なるほどそんな性質が。
>（結局は分数で扱うのが一番簡単そうに見えるのが）
例えば小数を分数に変換する、みたいなプログラムがたまにありますけど
有限な小数しか入力できないというのは片手落ちかなと思って。
周期が短い循環小数ぐらいはなんとかしたいかなーと。
例えば 1/7 の循環小数を入力したら、ちゃんと 1/7 を答えてくる、みたいな。
277:デフォルトの名無しさん
08/02/25 23:43:37
＞例えば 1/7 の循環小数を入力したら、ちゃんと 1/7 を答えてくる、みたいな。
循環小数を入力する書式さえ決めれば、どうにでもなるかと
循環部分を括弧で囲む 0.[142857] とか、循環する桁数を付ける 0.142857, 6 とか
142857/999999 で約分して 1/7
278:デフォルトの名無しさん
08/02/26 00:40:17
>273
どこの分野でも測定機の精度が八桁もあったら高性能といわれる
実数をきちんと表現しても元データの誤差以上にはならないから
現実的には計算が遅くなるだけでなんの意味もなさないでしょ
役に立たたないことそんなに力説しないでもいいんじゃない
>276
循環小数なら整数演算だからスレ違いでしょ
279:デフォルトの名無しさん
08/02/26 00:45:04
KY
280:デフォルトの名無しさん
08/02/26 00:58:12
不可算無限個について、なにやら認識が膨らみすぎてどうにかなっている人がいるので、ちょっと書いとくよ。
可算な集合の特性は適当な集合について、これをコンピュータで言う所の class でいうと
それは隣の要素を知るためのインターフェイスがあるという事だよ。
適当なコンテナオブジェクトがあるとき、その内容を列挙する気がないのなら別に列挙インターフェイスをつけなくてもいいんだよ。
それが不可算無限個を扱うという事、作れないって事はない、それは機能が制限されたライブラリとなっているだけだから。
281:デフォルトの名無しさん
08/02/26 01:55:10
>>277
なるほど。
ちなみに 142857/999999 というのは等比級数の無限和ですかね?
282:デフォルトの名無しさん
08/02/26 05:33:20
>>281
x = 0.[142857]
1000000x = [142857] = 142857.[142857]
1000000x - x = 142857
x = 142857/999999
283:デフォルトの名無しさん
08/02/26 09:22:43
>>282
なるほど。等比級数を持ち出すまでもないですね。ってゆうか確か高校で等比級数の和を
教えるときは同じような変形をするんだったかな。
浮動小数点の数値を整数分数に直してその後は分数として計算したら、精度的には
うれしい場合もあるかな?
284:デフォルトの名無しさん
08/02/26 10:28:18
>循環小数を入力する書式さえ決めれば、どうにでもなるかと
>循環部分を括弧で囲む 0.[142857] とか、循環する桁数を付ける 0.142857, 6 とか
914314.3143...とかどうしよう。9[143]XX.0とかでいいか。
無理数か循環小数かよく解らない数はどう表そう。
オイラーの定数γとか。
285:デフォルトの名無しさん
08/02/26 11:51:53
URLﾘﾝｸ(q.hatena.ne.jp)
286:デフォルトの名無しさん
08/02/27 13:06:33
>>278
ビット表現に×2^nと正規化が出てきたら文字通り
浮動小数点だと言ってみるテスト
（まあ現在普通に浮動小数点といえば
誤差含む数を扱うためのものだが）
>>280
実際のところ実数が不可算無限個あるって性質は
無視していいよね。
数学上は可算無限個の中に含まれない実数を
作り出すこと自体無理だし、
実用上は誤差を考えれば有限桁ですむし。
>>284
表そうも何もどういう循環小数か分からない時点で
287:デフォルトの名無しさん
08/02/27 15:46:50
>>286
有限のメモリーの中に無限を置けないのは、可算・非可算問わず事情は同じで
有限のメモリーの中"無限"という文字列が取り扱えるという事情も可算・非可算問わず事情は同じかと。
288:デフォルトの名無しさん
08/02/27 16:28:26
まあ、この話が出てきたのはBCDなら万全とかいう変な人のレスからだし、
真剣に無限どうこう考えてるわけじゃないでしょ。
289:デフォルトの名無しさん
08/02/27 20:29:04
BCDなら万全とかいう変な人のスレ
ｽﾚﾘﾝｸ(db板)
290:デフォルトの名無しさん
08/03/02 01:20:43
非加算な世界を考えれば、もうなんでもありですからね。
アルフ0 の一つ上は実数でしたっけ（連続体仮説？）
291:デフォルトの名無しさん
08/03/02 11:10:14
＞現在の数学で用いられる標準的な枠組みのもとでは
＞「連続体仮説は証明も反証もできない命題である」ということが明確に証明されている。
292:デフォルトの名無しさん
08/03/26 00:01:38
>>240
>（任意の循環小数には有限小数に変換できるような基数が必ず存在する?）
>もしかして有理数 m/n として表されるなら n を基数にすればいいとかそんな感じかな?
>n が素数でない場合はもうちょい工夫できそうな?
>>243
>・(n*x == o**y)を満たす整数x,yが存在するならoは何でも良い
nからよりコンパクトなoを求めるアルゴリズムが思い浮かばないよぅ。
素直にnを素因数分解するほうが近道か・・・
293:デフォルトの名無しさん
08/03/26 23:33:47
素因数分解はコストが大きいですよ
294:デフォルトの名無しさん
08/04/25 22:58:05
高精度計算サイト
URLﾘﾝｸ(keisan.casio.jp)
公開数日で、はてブ500ブックマーク突破。
有効桁数50桁。これ、BCDかなあ…。オリジナル精度の浮動小数点数かも。
プロの電卓屋が考えた「独自の桁数可変型演算システム」とやらの詳細が知りたいぜ！
君たちの大好きな 1 / 3 * 3 もちゃんと 1 になるぞ！
295:デフォルトの名無しさん
08/04/26 00:10:49
1.4142135623730950488016887242096980785696718753769
確かカイジでは
ｲﾖｲﾖ ﾐｺﾞﾛｼ って読んでた気がする。
1414 3564
>>294
CPUは、繰り上がりフラグがあるから、足し算なら無限にできる。
掛け算を因数分解して有効桁の範囲で計算したあと足し合わせればいいわけで。
または文字で計算。まあ速度的にないと思う。
296:デフォルトの名無しさん
08/04/26 12:32:29
宇海零が開平法知らなくてﾌｲﾀｗ
297:デフォルトの名無しさん
08/04/26 15:47:06
ひとよひとよにひとみごろ
１. ４ １ ４ ２ １ ３ ５ ６
が一般的だろうな。
298:デフォルトの名無しさん
08/09/25 14:29:48
float 使うヤツはドシロートかおぢさん
ｽﾚﾘﾝｸ(tech板)
299:デフォルトの名無しさん
09/01/05 07:38:27
299
300:デフォルトの名無しさん
09/01/31 16:44:13
300
301:デフォルトの名無しさん
09/02/15 22:19:06
FPU命令に三角関数があるらしいけどマジで？
ところで、Boostの分数はいずれ多倍長整数をサポートするとか。
精度ってどうなのよ？
302:デフォルトの名無しさん
09/02/15 22:27:45
>>301
8087の頃からある。
303:デフォルトの名無しさん
09/02/15 22:50:46
>>302
ほへぇ～。だったらsinテーブル作って引くよりそっち使った方が早いのかな？
304:デフォルトの名無しさん
09/02/15 22:55:46
>>303
んなわけないだろ
8087系統は愚直にマクローリン展開の公式を実行している
だけだからクロック数はすごいぞ
305:デフォルトの名無しさん
09/02/15 23:06:12
そっか。でもまぁ、SSEなんざ使うよりまし？
306:デフォルトの名無しさん
09/02/15 23:18:07
>>303
そういうことを自分で調べずに、このスレで何をするつもりなの？
307:デフォルトの名無しさん
09/02/16 07:46:44
>>304
乗算器が速くなかった時代では級数展開やってない。
CORDICでぐぐれ。
308:デフォルトの名無しさん
09/02/16 19:05:38
>>306
実装って複数あるだろうから平均的な動作を知りたくてね。
やろうと思えば、アセンブリ命令レベルで組み込まれてる訳だから
並列化した回路を実装してある物もあるかもしれないじゃん。
でも、そういう情報は古すぎてかあんまりWebにゃ載ってなくてねぇ。
309:デフォルトの名無しさん
09/02/17 00:43:56
>>307
ほう昔はこんな方法使ってたのか
今じゃRadix16だからなー
310:デフォルトの名無しさん
09/02/17 16:44:54
逆数テーブル持ってるんじゃなかったのか。
311:デフォルトの名無しさん
09/02/18 23:04:32
doubleの逆平方根が存在しないのは何故？
floatからニュートン法でやるしかない？
312:デフォルトの名無しさん
09/02/18 23:44:15
>>311
あるところにはあるよ。
URLﾘﾝｸ(docs.hp.com)
313:デフォルトの名無しさん
09/02/19 00:17:31
そうか、SSEスレじゃないのかスマン
HPのWS？の関数じゃあなあ
314:デフォルトの名無しさん
09/02/19 00:22:08
そりゃぁ、このスレはx86での浮動小数点数のスレなんだから、HP-UXだってありだろ。
315:デフォルトの名無しさん
09/02/19 19:55:09
素朴な疑問。SSE用レジスタっていっぱいあるけど、
なんちゃらオーダー見たいな機能で並列実行とかされないの？
暇そうに遊んでるレジスタが気になって仕方ない。
316:デフォルトの名無しさん
09/02/19 20:18:35
OOOのことか？
>>SSE用レジスタっていっぱい
だからOOOが効くとでも思ってるのか？
317:デフォルトの名無しさん
09/02/19 21:00:28
やっぱりねぇ。
結局多項式でぐらいしか意味は無いのか。
もったいねぇ。
318:デフォルトの名無しさん
09/02/19 21:04:49
>>317
おまえ、全然分かってないな
多項式だって a(b+x(c+x(d+x)))をSSEに置き換えただけでは
全然効果ない
319:デフォルトの名無しさん
09/02/19 22:01:15
>>318
そうなんけ？2～3倍早くなったことはあったけど。
じゃああのレジスタ群は何に使うのよ？
320:デフォルトの名無しさん
09/02/19 22:04:50
そこがテクニックw
321:デフォルトの名無しさん
09/02/19 22:53:03
>>318
単に置き換えただけでも効果あるぞ。
FPUはfxchとか駆使してもOoOし切れないことが多い。
322:デフォルトの名無しさん
09/02/19 23:01:06
SSEの一番の問題は、超越関数を使うにはFPUに切り替えるかiccの内部関数に頼るか自作する必要があることだな。
323:デフォルトの名無しさん
09/02/20 02:56:34
iccではsseで改めてcos/sinとかを（ソフト上で）実装してるってこと？
icc持ってないから分からないんだけど。
324:デフォルトの名無しさん
09/02/20 04:00:23
あるっぽいよ。iccが出力した実行モジュールのプロファイルを見た限りでは。
325:デフォルトの名無しさん
09/02/20 04:13:50
sse精度になっちゃうんじゃないの？
それとも-msse, -O3とは別の意味で、オプションとか組み込みキーワードで精度を選択できるのか？
326:デフォルトの名無しさん
09/02/20 14:15:09
１０バイト精度でがんばっていた人たちって、どうするのかね。
327:デフォルトの名無しさん
09/02/20 15:17:11
fp80のことか？もう見捨てられてるっしょ。
ただでさえサポートしてるプロセッサはx86以外ほぼ皆無だし。
実際問題精度よりスループットのほうが重視されてるからな。
スループットがあればFFTによる多倍長演算も容易になる。
328:デフォルトの名無しさん
09/02/20 17:19:20
むぅ、１２８ｂｉｔはドリフトか。
329:,,・´∀｀・,,）っ-○◎●
09/02/20 22:08:20
80bit精度って今となっては帯に短し襷に長しだからな。
MSコンパイラがlong double = doubleにやっちゃってるし。
330:デフォルトの名無しさん
09/02/20 22:56:00
８０ビットはインテルの（変態）独自仕様だと思ってたけどちがうの？
出来るだけ６４ビットに演算誤差を伝播しないようにするインテルの親心というか・・・
331:デフォルトの名無しさん
09/02/20 23:02:41
ところで、FFTの多倍長というのは桁数いくつ以上からを考えてるの？
１２８ビットじゃないけど、金融・財務とか科学の計算でも普通は多く５０桁＊２程度あれば十分だと思うけど。
暗号とかエンコード用途なら、スループット以前の問題でFFTをハードとしちゃうだろうし。
というか、IEEEは早いところ１６ビット小数を定義して実装して欲しい・・
332:,,・´∀｀・,,）っ-○◎●
09/02/20 23:14:27
もうAMDのでいいよ
333:,,・´∀｀・,,）っ-○◎●
09/02/20 23:26:23
つか、金融・財務で10分の1が正確に表せない浮動小数は非常識かと。
COBOLみたいな10進で扱う言語がわざわざ使われてるわけで。
かつ、Javaへの置き換えとかはBCD専用クラスとか作ってやってるわけで
それにしてもAMD64がBCD演算命令を整理（廃止）する一方で今更POWERが実装とかｱﾌｫかとｳﾞｧｶかと
どうせ高級言語ごしでやるんだから命令ニーモニックレベルでのサポートも原則的には要らない訳なんだが。
334:デフォルトの名無しさん
09/02/21 00:19:22
桁数の実用性の問題だから、当然BCDとか小数とかの比較のことじゃなかったんだけど。
BCDとかの実装の問題だとしても、ソフト上でintでいいんじゃないの？
例えば、高々１００桁程度でかつ１００桁の固定精度で十分なのに、どこにFFT使うんだ？
廃止かどうかというのは、当時の貧弱なハードや産業界の需要によって機能をつけたわけで・・・
浮動小数は、実際は指数部分が重要なわけであって、仮数部分は低精度でいいってことは分かってるのか？w
仮数の精度は低いが、たとえ８ビットだとしても高精度と比較してもグラフの形状はほぼ同じ形状になる。
高精度が欲しいなら小数なんか使わないでBCDにすればいいんじゃないの？
335:デフォルトの名無しさん
09/02/21 00:37:55
>>322
SSEというのはスカラー演算はおまけで、ストリーム用途（といってもたった１６バイトだけど）が本命じゃなかったのか？
インテルはサーバ用CPUの方に目がいっちゃってるから、PC用ではAMDの方がやる気あるよねって言うのは同意するけど。
でもインテルは組み込みやサーバーや携帯市場にもいってみたけど活路は無く、一方でPC市場を放棄したりして一体何やりたいんだろうね。
一番活躍できそうなネットブックは、MSが仕様作ってるからインテルが主導権握ってる市場じゃないみたいだし、インテルには将来の展望というか何やりたいのかさっぱり見えてこない。
小数とは関係ないけど。
336:デフォルトの名無しさん
09/02/21 00:59:08
少し話がずれていくが、「仮数部分は低精度でいい」ってのは語弊があるな
高い精度で高速な浮動小数点演算を必要とする需要ってのもいくらでも存在するぞ
最終段の出力が全てではないわけで
ま、そのために80ビットてのも痛し痒しだって流れには同意するけどね
337:デフォルトの名無しさん
09/02/21 01:22:45
>>336
それも一応考えてみたんだけど、浮動小数を他と比べるとき、仮数（有効精度）で比べると１０進上の扱いや演算誤差はBigDecimalの方が分があるから浮動小数は入らないとなるけど、
指数では当然だけど浮動少数の方にメリットがあって、少ないビットで巨大な数2.1 * 2^1022 などを表現できることに利点がある。
これはBCDでは桁数分の配列(上と同じなら1000以上）を用意しないとだめだし、もしBigDecimalだとしても実装が val * 10^exp とするならそれは浮動少数でしかない。
つまり浮動小数は、極端に言えば仮数は指数がゼロか否かの1 0のみでよくて仮数に意味はなく指数が命ってことになる。
すると８ビットでもいいじゃないのって事がわかってくる。深く考えてみれば分かるよ。
それなのに仮数の精度がどうとかこうとか言うのは、よくいるだろ？財務アプリなのにint,longで金額を保持しちゃう奴。アレと同じだろ。
もし精度が欲しかったり演算誤差を気にするなら、プリミティブ型なんか使わずちゃんとBCDつかったりソフト上で多倍長を実装するべきだと思うよ。
338:デフォルトの名無しさん
09/02/21 01:36:23
sigma取る時に桁落ちしなければ何でもいい
339:デフォルトの名無しさん
09/02/21 01:56:44
じゃ８０ビットでいいじゃん。６４ビットまでを有効桁にするだけ。
関数電卓（手元にあるのはカシオだけど）の説明書では１０桁を有効桁にして、内部では１５桁でやってるとかいてある。
たぶん実際のこと知らないのに、どっかの三流起者とか○○研究所研究員が書いた記事を鵜呑みにしちゃって、演算誤差が出やすいとか思い込みしてたんじゃないの？ｗ
340:デフォルトの名無しさん
09/02/21 12:19:27
>>339
10^15程度でいいなら倍精度の53ビットあれば十分だろ。
更に言うなら64ビット整数と10^nの固定スケールで表してもいい。
なおさら機種依存のfp80なんて使う必要ねーよ。
むしろ【浮動】小数で扱う必要がない。
ジンバブエドルでも扱うのか？www
341:デフォルトの名無しさん
09/02/21 12:25:43
15桁っていうのは、内部的に倍精度ってだけなんだろ
ところで財務アプリなんか触ったことないがなぜlongで保持しちゃいけないんだ？
_int64で持てってこと？
342:デフォルトの名無しさん
09/02/21 12:59:31
言いたいことが良く分からないんだけど、例えばジンバブエドル１００兆ドル札が発行されたとしても、使う人たちはりんご２０個で１００兆１３０ドルか１００兆１４０ドルかの違いなど気にすることはない。
君の妄想はこの程度しかできないんだろうけど、もっと現実に即して考えないと後々損することになるかもしれないよ。
８０ビット精度は上にもあるように６４ビット（IEEE定義のdouble)に演算誤差を伝播しないためにインテルが保障を確保するために必要とする精度であって、ジンバブエドルとはまったく別の話。
英語のウェキの方が詳しいが、IEEEの浮動小数点数の定義も含めて勉強しなおしたほうがいいんじゃないか？
343:デフォルトの名無しさん
09/02/21 13:02:00
>>341
longで持ってもいいけど、プリミティブかオブジェクト（インスタンス）かの違い。
インスタンスで持つとオブジェクト指向の方法論が使えて何かと便利ってこと（他にもあるけど）。
344:デフォルトの名無しさん
09/02/21 14:18:45
>>343
いや、普通に long じゃ桁あふれするだろ。
345:デフォルトの名無しさん
09/02/21 14:29:50
この前ジンバブエドルがデノミを行ったのは、コンピュータで扱いきれなくなる恐れがあったかららしい。
346:デフォルトの名無しさん
09/02/21 15:10:35
>>342
金融演算知らないｼｯﾀｶは黙ってな。IEEE浮動小数なんて使わねーよ。
整数四則演算より80ビット浮動小数の方が速いような変態CPUなんてどこにあるんだと。
fp80をかろうじて使える当のIntelすら整数(固定小数)のほうが圧倒的に速い。
347:デフォルトの名無しさん
09/02/21 15:15:02
１００兆１３０ドルか１００兆１４０ドルかが大きな意味を持つ世界もあるわけで。
結局適材適所だよね。
348:デフォルトの名無しさん
09/02/21 15:17:40
知ったかといって大きく出た割にはビッグマウスだなｗ
金融とか財務とかのアプリで、どこに浮動小数を使う場面があるんだ？
整数と浮動小数（IEEE）で全然違うフォーマットなのに比べてみたり、一体いつの時代で比較してみたり速いとか遅いと基準もなく比べたりしてるんだ？
どうせ「IBM」という肩書きの３流記事を読んで頭おかしくなっちゃってるんだろ。知ったかはお前の方だな。カスは黙ってろｗ
349:デフォルトの名無しさん
09/02/21 15:19:21
Wiki＝ウ【ェ】キは新しすぎる
350:デフォルトの名無しさん
09/02/21 15:23:05
新ジャンル「ウェキ」
351:デフォルトの名無しさん
09/02/21 15:23:10
>>346
あのね、ベンチマークなんかいくらでも都合よくプログラム書ける訳よ。
インテルがtmpegエンコ―ダに賄賂（支援）してインテルCPUに都合よくプログラムしてるって話は有名だろｗ
例えば統計の数値使って官僚とか経営者を騙すとかたまに聞くだろ。つまり、IBMとか東大とか肩がきってのはそういうの同じ（その統計もある意味あってるから別に否定はしないけど）
頭弱いおサルちゃんはどの分野にいっても「コロっと」騙されちゃうんだろうけど（笑）
352:デフォルトの名無しさん
09/02/21 15:26:04
TMPEGはCUDAにすら対応してるわけだが
賄賂？妄想を既成事実にしないで下さい
353:デフォルトの名無しさん
09/02/21 15:35:51
最新のIntelCPUでFP80がクソ遅いのは常識なわけだが。
物理的に32bit×4ないし64bit×2のSIMDに最適化された演算器しか載ってないし。
なにより今時スタックな時点で論外。
他人のベンチがどうとか以前に自分で計測してみろよ、ゆとり
354:デフォルトの名無しさん
09/02/21 15:42:52
＞金融とか財務とかのアプリで、どこに浮動小数を使う場面があるんだ？
PBRとかわざわざ固定小数で計算してるとは思えないな。
355:デフォルトの名無しさん
09/02/21 15:47:47
SIMDでBCDを使うと10のべき乗単位の乗除をバイトシフトで表せるという利点がある。
356:デフォルトの名無しさん
09/02/21 15:52:16
BCDクラス内でSIMD用のビットアラインメントって出来るの？
357:デフォルトの名無しさん
09/02/21 15:53:21
どんなに精度が高い演算ができようとも、手計算で小数点以下２桁で切り捨てた低精度演算の結果に合わせなけばならない悲劇
358:デフォルトの名無しさん
09/02/21 17:43:02
>>353
物理的にはFPUユニットとSSEユニットが載っているわけで、間違って覚えたりしてないでインテルのマニュアルをあとでこっそり読み直したほうがいいんじゃね？
鼻高々に知ったかばかりしてると、もっと大きな恥かくことになるからｗ
359:デフォルトの名無しさん
09/02/21 20:48:14
使わないなら、銀行型四捨五入とかやめてほしかった。
360:デフォルトの名無しさん
09/02/21 20:51:37
>>359
それ何?
361:デフォルトの名無しさん
09/02/21 20:56:53
>>359
銀行で使ってるの見たことないんだけど
使ってる銀行ってあるの？
362:デフォルトの名無しさん
09/02/21 21:13:02
>>360
つ Banker's Rounding
363:デフォルトの名無しさん
09/02/21 21:55:45
ジンバブエで使ってるCPU使えばよい
364: ◆0uxK91AxII
09/02/21 22:05:17
>>353 >>358
ia32_final_i.pdf
今時のCPUは十分に処理能力が高いから、遅くても問題ない。
365:デフォルトの名無しさん
09/02/21 23:45:37
>>364
いや、シミュレーションの世界では早ければ早いほどよい。
366:,,・´∀｀・,,）っ-○◎●
09/02/22 00:04:04
>>358
「論理的」だろ。物理的に別ユニットっていつの時代のCPUだよ。
現行のCore MAなんかではx87とSSEは共用だよ。
大別してFADDがSIMD FP Adder, FMULがSIMD FP Multipler。
あとDividerとかFP ROMが同じポートにぶら下がってるかな
まあ、fpスタック経由でしか80bit精度の演算ができない（XMMレジスタは使用できない）時点で
実効スループットは察して下さい。
>>364
英語版にしろよ。それPentium 4までしか載ってなくね？
367:,,・´∀｀・,,）っ-○◎●
09/02/22 00:19:58
URLﾘﾝｸ(www.intel.com)
IntelR 64 and IA-32 Architectures Optimization Reference Manual
SKU #248966
ゆっくり読んでいってね！
SIMD FPユニットとｘ87用ユニットが別なのってIntelだとPentium IIIが最後だと思うんだが。
あんときはSSEは単精度までのサポートだったから共有化の機運がなかったのかな？
368:デフォルトの名無しさん
09/02/22 01:07:42
>>366
結局お前か。お前のウンチクなど聞きたいわけではないわ。
名無しで潜伏してないでちゃんと名を名乗れ。ニートｗｗｗ
369:デフォルトの名無しさん
09/02/22 01:14:17
>>367
スループット云々よりもメイン・メモリとのレイテンしが改善されないから、もう頭打ちなんじゃないの？
結局fetchに頼るのみなら、80ビットやFPのフォーマットや機構（スタックとか）の問題じゃないし。
SSEは、レイテンシを考えると、ガバッと持ってくるようにするために１６バイトとかケチってないで３２バイト(double*4)でよかったんじゃないかと思う。
370:,,・´∀｀・,,）っ-○◎●
09/02/22 01:24:09
>>368
は？ｗｗ
被害妄想いいかげんにして。
ウェキは吹いたｗｗｗ
371:,,・´∀｀・,,）っ-○◎●
09/02/22 01:25:14
>>369
＞SSEは、レイテンシを考えると、ガバッと持ってくるようにするために１６バイトとかケチってないで３２バイト(double*4)でよかったんじゃないかと思う。
それがAVXなんだけど・・・。
372:デフォルトの名無しさん
09/02/22 01:38:55
>>346
> 整数四則演算より80ビット浮動小数の方が速いような変態CPUなんてどこにあるんだと。
Netburstだと、整数の乗除算よりFPの乗除算の方が速い
373:,,・´∀｀・,,）っ-○◎●
09/02/22 01:40:14
prefetch*はキャッシュライン単位だぞ。
あと、Core MAやAMD K8以降ではL1キャッシュの1ラインは64byteなんで。
シーケンシャルリードなら同一ラインの後続ブロックもL1から続けて読めるから
>>369の想定する用途では全然問題ないと思うんだが。
シーケンシャルとか定ストライドなどのパターン性のあるアクセスなんかだと
いまのCPUではキャッシュ自体が自動的に先読みしてレイテンシ隠蔽してくれる機会がある。
ベクトル長伸ばしちゃうとそれはそれで厄介だぜ
座標を表すのですら、単精度だとx, y, zであと1要素分余らせたりすることが珍しくない。
現状のSSEの実装ではpermute演算はそこまで強力じゃないので128bitが妥協点だったのでは？
374: ◆0uxK91AxII
09/02/22 01:55:30
>>367
thx
>>369
＞メイン・メモリとのレイテンし
そこは、cacheが入り込むし、命令の並び換えで適当に隠せる。
375:デフォルトの名無しさん
09/02/22 02:06:22
>>373
＞現状のSSEの実装ではpermute演算はそこまで強力じゃないので128bitが妥協点だったのでは？
だからさ、その時代その時代に合わせたお前のウンチクなんて興味ないのよ。
３年後には全く逆のこといったりするだろ。
主張がコロコロ変わるからいつまでたってもお前は誰からも認められないんじゃないの？ニート君ｗ
376:デフォルトの名無しさん
09/02/22 02:11:16
>>373
なんつーか、お前の浮動小数点の理念とか信念なんか聞きたいわけじゃないわけ。
fp80の精度が必要な人もいれば、高速な方がいいって人もいるわけで、インテルの洗脳されちゃってるお前の信念を押し付けないでくれないか？
それも信念がコロコロ変わるんだろ。お前だって嫌だろ。草かみたい選挙が近くなるたびに草か信者が家に押しよせてきたら・・・
377:デフォルトの名無しさん
09/02/22 02:14:20
prefetchはINTELとAMDで細かいところに互換性がないから、（未知のバグになるから）できればユーザーが明示的にコード書いて使うようなものではない、ってことだったんじゃないの？
378:,,・´∀｀・,,）っ-○◎●
09/02/22 02:15:58
> ３年後には全く逆のこといったりするだろ。
言わねーよ池沼
10年前のPentium IIIではSIMD演算ユニットは単精度2並列分のスループットしか得られなかったが
それでも10年前なりの技術水準でできるだけのことはやってた。
それを文句言う奴はいねーよ。
379:,,・´∀｀・,,）っ-○◎●
09/02/22 02:18:03
x64でのx87のレガシー化で主に動いたのはMSとAMDなんだが。
IntelはAMD64のコピー実装だし。
Intel信仰がどうとか言ってることがちゃんちゃらおかしい。
ウェキ（笑）
380:デフォルトの名無しさん
09/02/22 02:21:28
>>372
よく分からないんだけど、bitwiseの観点からみれば整数四則もFP四則も同等でしょ。
両者に差が出るようところはどこにあるの？
整数もFPも、１０進に直したり結果を出力して視覚化するところに差があるというなら、本質的には君>>346が言うところの四則の計算とは関係ないわけで・・・
381:,,・´∀｀・,,）っ-○◎●
09/02/22 02:22:34
>>377
キャッシュのローカリティヒントなんて同じIntelでも、Pentium 4とCore MAでも動作が違う。
たとえばPen4ではprefetcht0を使ってもL1にはデータは置かれないがCore MAでは置かれる
だがキャッシュのヒット率なんて演算結果に直接影響しないだろ？
キャッシュローカリティで演算結果が変わるようなプログラム書いちゃう人はそれはそれで問題だが？
382:,,・´∀｀・,,）っ-○◎●
09/02/22 02:30:31
昔のIntel独自実装の8087をマンセーしつつIntel信仰はキモイとかどんだけ～
単精度と倍精度はIEEE754の規格にも入っててPowerPCやARMでも使えるんですが。
FP80（笑）
383:デフォルトの名無しさん
09/02/22 02:31:02
>>378,379
当時の水準でFPUとSSEは分離してたのが最良といいつつ、何でさっきの主張では「FPUはイラン！」とか文句言っちゃうんだ。
どうも当時の技術水準とその互換性「FP80」に文句あるみたいだけど、そんなに演算誤差を気にしなくてもいいプログラムをしてるのか？
お前みたいな奴が「古い技術はイラン！」とか言って互換性を破壊していく元凶なんだよな・・・・そういうの世の中に出てみると分かるけど、即効で嫌われるから。
日本男児の固定観念もいいけど、英語の発音では一応「ウェキ」といってるようだが・・・なんかお気に入りのようだなｗ
384:デフォルトの名無しさん
09/02/22 02:32:17
なんで団子の周りには馬鹿が集まるんだ？
385:デフォルトの名無しさん
09/02/22 02:36:00
>>379
インテル信仰とは、インテルのx86命令コード体系のことだと思うんだが・・・？
実際今の64ビット向けとかはAMD64の定義をコピーしてインテルが使ってるんだし。
もしかして団子は、会社としてのインテル（INTEL入ってる！）にあこがれてるのか？
よく読んでみると所々に穴があるよね。団子はｗ
386:,,・´∀｀・,,）っ-○◎●
09/02/22 02:38:42
おまえ馬鹿だねぇ
Pentium IIIのSSEはたかだか単精度のSIMDでしかない。
SSE2以降は倍精度も扱えるようになったんで共用化したほうがよくなったんだろ。
倍精度対応の演算ユニットは半導体のコストが大きいからね。
PowerPCのAltiVec(VMX)でも倍精度対応のスカラFPUと、単精度までのVFPUが共存してるが
POWER7のVSXでようやくレジスタセットごと統合の運びになりましたが。
387:,,・´∀｀・,,）っ-○◎●
09/02/22 02:39:55
>>384
俺に噛みつく奴は馬鹿ってより
馬鹿だからこそ噛みつくんですよ。
388:デフォルトの名無しさん
09/02/22 02:44:25
というか業界人でもない普通の人（本業でPG含む）は、新作CPUの各ベンチ取るために毎度毎度CPUを買ったりしないから。
だからPen4では・・とかCoreでは・・とか言われても知らんわ。現状では、一般的に議論ができるのはSSE１/SSE2しかないな。
実際PC使いこなしてアプリ作ってるわけでもないくせに、お前の主張など、「ソニーのパソコンは・・・東芝のパソコンは・・・」とか言ってるカスタマーの戯言にしか聞こえんわw
389:,,・´∀｀・,,）っ-○◎●
09/02/22 02:45:39
過渡期の実装は一見無駄に見える。近視眼の馬鹿には。
390:,,・´∀｀・,,）っ-○◎●
09/02/22 02:46:53
>>388
それで、ｘ87とSSEが分かれてないPentium IIIのパソコンをいまだに使ってるんですね。
零細企業乙
391:デフォルトの名無しさん
09/02/22 02:51:29
というか、団子はブログとかウェキでもやりながら、細々と「執筆募集！」をすればいいだろ。
隅々までマニュアル読んでるようだし、どこかの雑誌とかベンチャーが「ベンチとってくれない？」とかの依頼ぐらいはあるだろから。
少なくともお前の能書きを２ｃｈスレに書かなくていいからｗ
392:,,・´∀｀・,,）っ-○◎●
09/02/22 02:52:44
ウェキ（笑）
393:デフォルトの名無しさん
09/02/22 02:56:04
え！団子さんってブログもってなかったの？！
ダサｗ
394:,,・´∀｀・,,）っ-○◎●
09/02/22 02:56:52
[wi]の発音は日本古来の「ヰ（ウィ）」に相当するものであってヱ（ウェ）じゃないんだよね
395:,,・´∀｀・,,）っ-○◎●
09/02/22 02:59:28
もしかして: ウィキ
ウェキ（笑）
396:,,・´∀｀・,,）っ-基地外-
09/02/22 03:00:33
真夜中ですが基地外警報
397:,,・´∀｀・,,）っ-○◎●
09/02/22 03:07:58
ホロン部の人なのかな？
URLﾘﾝｸ(ja.wikipedia.org)
左上のロゴよく読んでね。
これが「ェ」に見えちゃう人は目か頭がおかしいです
398:デフォルトの名無しさん
09/02/22 03:08:36
そんなに発狂するなよ。その情熱をブログにぶつけろｗたまに読んでやるからｗ
一応言っておくと発音のときはスラッシュを使う。
で、wikiの/i/は/e/ではないので口が横に大げさに伸びるわけで、日本人の耳では「い」や「いぇ」ではなく「え」に聞こえるはず。
また、まえの/w/と重なって「い」のようにはっきり聞こえる事はない。
短母音にこだわっちゃう辺りも、団子は生粋の日本男児なのかねぇ。どこ出身？
399:,,・´∀｀・,,）っ-○◎●
09/02/22 03:10:07
URLﾘﾝｸ(ja.wikipedia.org)
？？？？？？？？？
400:,,・´∀｀・,,）っ-○◎●
09/02/22 03:17:04
URLﾘﾝｸ(ja.wikipedia.org)
項目無いから作ってよｗｗｗ
401:デフォルトの名無しさん
09/02/22 03:23:22
>>398
大阪民国
団子はPGじゃないだろ？
402:デフォルトの名無しさん
09/02/22 03:31:43
>>399
こういうどうでもいいところに情熱を注ぐ意味が分からん。
ところで団子のINTELウンチクはもういいから、このスレでは小数の話題にしてくれないか？
403:,,・´∀｀・,,）っ-○◎●
09/02/22 03:32:55
wiki wiki（ウィキウィキ）は速いと言う意味のハワイ現地語であって英語じゃないからね。
※いわゆるコラボレーションツールのWikiの由来も元々は地元の観光バスが由来です。
ハワイ原住民はムー大陸の末裔なんて言われるくらいガチのウラル・アルタイ語族。
a e i o uの発音はハッキリしてて、イとエを聞き間違えることなんて有りえませんよ。
ハワイ行ったこと有りますか？無いでしょうね。
↓Google先生もお困りです。
URLﾘﾝｸ(www.google.co.jp)
ウェキウェキバス に一致する情報は見つかりませんでした。
404:デフォルトの名無しさん
09/02/22 03:34:27
>>401
層化かと思ったけど、ああ在日なのね。
別に層化も在日は嫌いじゃないんだけど、それならファビョーリやすいのも納得だわｗ
405:,,・´∀｀・,,）っ-○◎●
09/02/22 03:40:10
吠えてますなｗｗｗ
悪いがミンジョクではない。俺はシオレスト（笑）だぞ。
406:,,・´∀｀・,,）っ-○◎●
09/02/22 03:43:39
ウェキ君はみっともないな
407:デフォルトの名無しさん
09/02/22 03:49:10
雑談はよそでやれや
408:デフォルトの名無しさん
09/02/22 03:54:47
>>403
そういうウンチもいらないからｗ
ウンチするなら他でやってくんない？
409:,,・´∀｀・,,）っ-○◎●
09/02/22 03:59:35
ウェキ（笑）がどれだけ恥ずかしいかは知っておかないとね
410:デフォルトの名無しさん
09/02/22 04:09:06
「ムー大陸の末裔」の方が数倍恥ずかしいと思うが…
411:,,・´∀｀・,,）っ-○◎●
09/02/22 04:10:15
そりゃ金融システムでFP80だとか非常識きわまりないことも言えるわけだ。
JavaやC#でPL/IやCOBOL同様に10進演算をサポートしてる理由を考えてみてくれ。
ちなみに754rのドラフトにも10進演算の項目入ってるよ。確認しる。
URLﾘﾝｸ(754r.ucbtest.org)
FP80（笑） ウェキ（笑）
412:,,・´∀｀・,,）っ-○◎●
09/02/22 04:14:55
>>410
ムー大陸は太平洋の島々の言語の構造や発音の共通性から言語学者が唱えた仮説だよ。
少なくとも母音の発音は同じアルタイ語族の日本と同じだってこと。
413:デフォルトの名無しさん
09/02/22 05:15:00
陸地がないと人間は大規模な移動ができないと思い込んでいる大陸系らしい考え方
414:デフォルトの名無しさん
09/02/22 05:18:46
「実は日本人はムー大陸の末裔だった！」という衝撃の真実を聞いて駆けつけてきました
415:デフォルトの名無しさん
09/02/22 05:23:48
ムー大陸は民族とかの人間に関するカテゴリーに属してないからそれは間違っていないか？
416: ◆0uxK91AxII
09/02/22 08:36:25
>>377
3DNow!のではなく、SSEのprefetchを使えば良い。
>>386
＞SSE2以降は倍精度も扱えるようになったんで共用化したほうがよくなったんだろ。
共用を前提として、SSE2を作ったという考えをしてみる。
417: ◆0uxK91AxII
09/02/22 08:38:34
『共用化』っていうのは、『復号化』のように、頭が悪く見えるね:b
418:デフォルトの名無しさん
09/02/22 10:37:02
Pentium(R)III プロセッサの実装条件
URLﾘﾝｸ(download.intel.com)
P.9-10
> x87 加算器とパックドFP 加算器の統合も検討されましたが、こ
> ちらは開発スケジュールの関係で実現には至りませんでした
419:,,・´∀｀・,,）っ-○◎●
09/02/22 13:26:34
>>413
海洋民族の航海技術を無視した白人優位思想が根底にあるね。
白人ブルーブラッドが黄色人種を支配してたなんて電波な説だし。
自分たちの古代文明が見つかってないのでどこかにあったと思い込みたい白人に熱狂的に支持された。
※もちろんブルーブラッドなんて比喩であって、実際に人の血を青くしてみた創作は○ーゼ○ォンくらいのものです。
420:デフォルトの名無しさん
09/02/22 13:32:17
アメリカとオーストラリアに大量移民した奴らがよく言うよ
421:デフォルトの名無しさん
09/02/22 13:38:47
>>419
秋葉原のショップでは、こなた（らき☆すた）のフィギアは売ってますか？
422:デフォルトの名無しさん
09/07/11 00:11:19
古い話を掘り返してみると、>359の書く「銀行型」って、ISO丸めのことなのね。
>362にあるように元は英語だろうけど、それを直訳した馬鹿がいるから
>361のような「銀行で使う」と思い込む間抜けが出てくるんじゃないか。
寧ろ鉱工業などで測定結果の集計するのによく使うのに。
423:デフォルトの名無しさん
09/07/11 21:25:48
パイルバンカーの方？
424:デフォルトの名無しさん
09/07/11 22:34:38
銀行は銀行だけど、「銀行家の」と言う意味だね。
まぁ、銀行でも使うケースと使わないケースがあるのだろうし、
「銀行型」って言い方をするよりも「ISO丸め」って言い方でいいんでない?
まぁ、>422は言い過ぎだね。
425:デフォルトの名無しさん
09/07/11 22:49:06
8087作ったときは、ISOじゃなかったのでは。
426:デフォルトの名無しさん
09/07/11 23:04:27
んじゃ、8087について語りたいときはansi丸めでw
427:,,・´∀｀・,,）っ-○○○
09/08/16 13:27:05
>>423
エウレカ厨乙
428:デフォルトの名無しさん
09/09/20 13:20:35
団子ってmixiにアカウントは持ってたよな。
嫌いなサイトが2chだとか書いてたろ。
429:,,・´∀｀・,,）っ-○○○
09/09/20 19:09:53
それどころかVIPのコテとばっかしつるんでたが
430:デフォルトの名無しさん
10/01/30 07:55:53
貧乳について教えてください
431:デフォルトの名無しさん
10/03/04 04:58:05
「インテル 64 アーキテクチャーおよびIA-32 アーキテクチャー最適化リファレンス・マニュアル」を読んでいて驚いたのだけど、
最近のCPUは除算のレイテンシとスループットが異様に小さいんだね。
FDIVでレイテンシとスループットが６と５って乗算とそんなに差がなくなっているね。
あとx87の表にNehalemがないのはNehalemってx87を積んでないの？
432:デフォルトの名無しさん
10/03/04 10:07:17
トランジスタの物量攻勢で、年々巨大なテーブルを引いて割り算するようになってんじゃないかな？
バグ付きPentiumで有名になったアレ。まだまだ早くなるのかも。解説お願い。
float同士の割り算の全パターンを事前にテーブル化して焼いとくのもそう遠くない未来のような。
(仮数部だけでいいとして46bitのインデックスを引っ張るテーブルがあればいいのか？
433:デフォルトの名無しさん
10/03/04 10:39:40
少なくとも一回計算した組み合わせくらいはキャッシュで持ってても良いよね
434:デフォルトの名無しさん
10/03/18 04:44:33
SSEを使うっているのは一般に、SSE命令を使っていればいいのか？
最近のコンパイラが吐くコードってスカラーでもaddssとかsubssを使っていることが多いので、
それだと何もしなくても”SSE”を使ったコードになってしまう気がする。
それともSIMDを使わないのはSSEを使っているとは言えないとなるのだろうか？
435:デフォルトの名無しさん
10/03/18 07:46:55
単に8087由来FPUの80bitレジスタが嫌なだけじゃね？
とエスパー回答してみる。
436:デフォルトの名無しさん
10/03/19 07:02:17
x86-64向けでなく組み込み関数でもなく、オプションも付けずにSSE命令を使うのはICCだけだろ
437:デフォルトの名無しさん
10/03/19 07:08:33
gccでも使うよ。適切にビルドされていれば
438:デフォルトの名無しさん
10/03/20 05:22:14
gccでも使うんだよ。でもさすがにパックドのコードを吐くことはないけど。
439:デフォルトの名無しさん
10/03/20 17:58:41
インテルコンパイラを使っているのですが、WindowsとLinuxで結果が変わってきてしまいます。
精度を同じにするには、どのオプションを使えばよいのでしょうか？
440:,,・´∀｀・,,）っ-○○○
10/03/20 18:07:52
>>432
Pentiumの除算ユニットはRadix-4 SRTっていうアルゴリズムを使っている。
URLﾘﾝｸ(journal.mycom.co.jp)
45nm以降のCoreアーキテクチャはそれより強力なRadix-16 SRTで
4ビットずつ処理出来るから従来の倍程度は速い。
441:デフォルトの名無しさん
10/03/20 18:08:47
>>439
442:デフォルトの名無しさん
10/03/20 18:09:31
>>439
http://homepage1.nifty.com/herumi/prog/prog90.html#PRECISION
443:デフォルトの名無しさん
10/06/25 01:13:02
新しいOpteron(Magny-Cours)で単精度のSSEのコードを走らせたんだけど、異様に遅い。
スカラーのコードの方が遙かに速いんだけど、そんなことってあるのかな？
インテルのCPUなら概ね2倍になるコードなんだけど、2倍どころか1/3にもなりそうな感じだった。
ただ、倍精度になるとスカラーよりも速くなる。
ICCでやったりgccでいろんなオプション試したけど、あんまりかわらないので何が原因かわからずにいる。
これだけで原因がわかるエスパーな人がいると助かるんだが。
444:デフォルトの名無しさん
10/06/25 13:59:28
URLﾘﾝｸ(pc.watch.impress.co.jp)
＞4つ目は省電力機能の拡張だ。Opteron 6100にはIstanbul世代で実装されていなかったC1E(CPUがスリープモードにあるときの電
＞力を減らす機能)が実装されたほか、「AMD Cool Speed Technology」と呼ばれる省電力機能が実装されており、温度センサーで温
＞度が限界を迎えたと判断したとき、プロセッサのPステートをより低い段階へと強制的に移行させる機能だ。これらの機能により、プロセ
＞ッサの電力効率を前世代に比べて高めている。
CPU温度が高くてクロックダウンしてるとか？
分からんけどｗ
445:デフォルトの名無しさん
10/06/25 20:14:14
>>443
ベクトル化が下手かOpteronの単精度がうんこかOpteronが不得意な命令を使っているか、
だと思う。
ICCはインテルCPU用の最適化しかしないという噂だけど、
gccはそんなことないはずだし。
プログラムの一部でもさらす気があるなら
もうちょっと答えられるかも。
C++とIntrinsicライブラリ？
C++とインラインアセンブラ？
C++とアセンブラ？
32bit? 64bit?
446:デフォルトの名無しさん
10/06/25 20:57:24
>>443
スカラーのコード
x87 or SSEのスカラー命令を使うコード?
SSEのコード
コンパイラの設定でSSEを使うようにしたスカラーコード or 並列化したコード?
447:デフォルトの名無しさん
10/06/26 01:45:18
>>444
これさ、一度CPUクーラーのファンを止めて、高負荷で動かしてみたことがあるんだけど、
マザーから警告のアラームがなって、ヒートシンクをさわったらさわれなくなる位めちゃくちゃ熱くなっていたけど、
実行しているプログラムが落ちることなく、動き続けていたから、相当熱くなるような環境でないと、
クロックが落ちることは無いと思う。よく負荷テストとかでPrime95とかいうFFTを馬鹿みたいに立ち上げる様な
ことをしない限りは無いんじゃないかな。
448:デフォルトの名無しさん
10/06/26 01:54:08
>>445
レスサンクス。
使っているのはC++とIntrinsic。最初はインラインアセンブリで書いていたんだけど、
WindowsのVCCも考えて、Intrinsicに変更した。
コードをさらしたいのだけど、さすがにそれは出来ないので、
ちょっとシンプルなコードを書いて比較してみるよ。
何かわかったら書き込んでみる。
なんとなく思っているのは単精度だとシャッフルやらシフトを多用しているんだけど、
倍精度ではデータ幅の関係でそんなにやらなくていいので、Opteronはシャッフルとかシフトに弱いのかなあ？
とか思っている。
>>446
64bitで使っているんで、もはやコンパイラがx87のコードを吐いてくれません。
ちょっと表現が悪かったけど、SSEと言っているのはベクトル化したSIMDコードという意味。
449:デフォルトの名無しさん
10/06/26 04:22:39
>>448
シャッフルのレイテンシ
AMD Family 10h: 3 cycle
Intel Penryn以降: 1 cycle
450:デフォルトの名無しさん
10/06/26 10:40:33
「OpteronとIntel(Core2?)とで挙動が違う」のが問題であるなら、
キャッシュ構成を疑ってみるのはいかが。
Opteronの一次キャッシュって今も2-wayなの？
451:443
10/06/29 01:29:17
ちょこっと調べてみたら、クリティカルな部分は
ループの中に
for(;;)
{
//A,B,Cその他諸々のデータを取ってきて下記を実施
SSEの計算群1 -> 結果をxmm0に最終的に放り込む
SSEの計算群2 -> 結果をxmm5に最終的に放り込む
SSEの計算群3 -> 結果をxmm10に最終的に放り込む
// メモリへの書き込み
A[i] = xmm0;
B[i] = xmm5;
C[i] = xmm10;
}
と言うような感じなんだけど、メモリへの書き込みの段階で偉く遅くなっていた。
>>450が言うようにキャッシュの問題なんだろうけど、解決方法は無いのかな？
Opteronはライトスルーなのかな？
A、B、Cの結果は再利用されることはないので_mm_stream_ps()でやってみたけど、そっちはもっと遅くなった。
452:デフォルトの名無しさん
10/06/29 03:11:14
配列A,B,Cのサイズを
32kBの倍数+64*n(n=1,2,...,511)
に変える
453:デフォルトの名無しさん
10/06/29 19:57:17
>>451
A,B,Cのサイズは？
SSEの計算群1 -> 結果をxmm0に最終的に放り込む
A[i] = xmm0;
SSEの計算群2 -> 結果をxmm5に最終的に放り込む
B[i] = xmm5;
SSEの計算群3 -> 結果をxmm10に最終的に放り込む
C[i] = xmm10;
とやってみるとか。
Cだけ_mm_stream_psにしてみるとか。
454:デフォルトの名無しさん
10/06/29 22:57:53
キャッシュスラッシングが原因だとすると
スカラーコードではA,B,Cは独立した
ループで処理してるのかな？
455:443
10/06/30 02:18:30
>>453
レスありがとう。
実はすでにやってみたけど変わらなかった。
ひょっとしてレジスタが足りなくなって、xmm0とかが、メモリに待避させられているのでは？
と思ったんだけど。
A,B,Cのサイズ自体多次元配列で、すごく大きいけど、ループの中では4K以下になるように処理している。
たとえば
AAA[i][j][k]の3次元配列があった場合、
A = AAA[i][j]
と1次元は配列として扱っている。そしてA[max]が4KB以下になるようにしている。
>>454
スカラーのコードもA,B,Cでループ内で処理している。
やっぱり、スラッシングが原因なのかなあ？
456: ◆0uxK91AxII
10/06/30 18:03:29
とりあえず、境界を合わせて128[bit]ずつnon temporalな書込みをする。
457:デフォルトの名無しさん
10/06/30 19:03:04
Cだけ_mm_stream_psにしても変わらないならA,B,Cだけが原因じゃなさそうだ。
計算群1,2,3で参照しているメモリがA,B,Cとスラッシングしてるんじゃないかな。
なので、こうしたらどうだろう？
for () {SSEの計算群1-> 結果をA[i]}
for () {SSEの計算群2-> 結果をB[i]}
for () {SSEの計算群3-> 結果をC[i]}
これでも計算群1で参照しているメモリがA[i]とスラッシングしてたらお手上げなんだけど。
458:443
10/07/01 01:21:40
>>456
>>457
いろいろと調べてみたら、キャッシュの問題ではなくて、
NUMAノードの設定が問題だったようだ。
メモリの確保をmalloc()ではなく、numa_alloc_onnode()でダイレクトにNUMAノードを指定してあげたら、
ほぼスカラーの倍の速度が得られたよ。
numactlをつかって、--preferred=nodes --localallocとかいろいろといろいろとオプションを
つけてやってみたけど、うまく指定したノードでのメモリ割り当てが出来ていなかったみたい。
いずれにしてもSSEの問題ではなかったので、変な質問をして申し訳ない。
レスしてくれた人ありがとう。
ただ、プリフェッチの指定をしていた部分でNehalemではかなり効果があったのが、
Opteronでは全く効果が無いので、プリフェッチの距離とかはOpteron用に考えないといけない様だ。
459:デフォルトの名無しさん
10/07/01 08:56:52
OpteronのNUMAは諸刃の剣だな。ハマればメモリの許す限りスケールするしな。
ていうかSMP Opteron由来の問題とは俺も気付かなかった。
460:デフォルトの名無しさん
10/07/23 11:32:54
（０００、０００）10
ー１０、８３５
とかいう問題
461:デフォルトの名無しさん
10/07/27 16:59:37
>>458
First touch 問題だね