【FPU】　浮動小数点　【SSE】

>>410
ムー大陸は太平洋の島々の言語の構造や発音の共通性から言語学者が唱えた仮説だよ。
少なくとも母音の発音は同じアルタイ語族の日本と同じだってこと。

陸地がないと人間は大規模な移動ができないと思い込んでいる大陸系らしい考え方

「実は日本人はムー大陸の末裔だった！」という衝撃の真実を聞いて駆けつけてきました

ムー大陸は民族とかの人間に関するカテゴリーに属してないからそれは間違っていないか？

>>377
3DNow!のではなく、SSEのprefetchを使えば良い。

>>386
＞SSE2以降は倍精度も扱えるようになったんで共用化したほうがよくなったんだろ。
共用を前提として、SSE2を作ったという考えをしてみる。

『共用化』っていうのは、『復号化』のように、頭が悪く見えるね:b

Pentium(R)III プロセッサの実装条件
http://download.intel.com/jp/developer/jpdoc/impliment_j.pdf
P.9-10
> x87 加算器とパックドFP 加算器の統合も検討されましたが、こ
> ちらは開発スケジュールの関係で実現には至りませんでした

>>413
海洋民族の航海技術を無視した白人優位思想が根底にあるね。
白人ブルーブラッドが黄色人種を支配してたなんて電波な説だし。
自分たちの古代文明が見つかってないのでどこかにあったと思い込みたい白人に熱狂的に支持された。


※もちろんブルーブラッドなんて比喩であって、実際に人の血を青くしてみた創作は○ーゼ○ォンくらいのものです。

アメリカとオーストラリアに大量移民した奴らがよく言うよ

>>419
秋葉原のショップでは、こなた（らき☆すた）のフィギアは売ってますか？

古い話を掘り返してみると、>359の書く「銀行型」って、ISO丸めのことなのね。
>362にあるように元は英語だろうけど、それを直訳した馬鹿がいるから
>361のような「銀行で使う」と思い込む間抜けが出てくるんじゃないか。
寧ろ鉱工業などで測定結果の集計するのによく使うのに。

パイルバンカーの方？

銀行は銀行だけど、「銀行家の」と言う意味だね。
まぁ、銀行でも使うケースと使わないケースがあるのだろうし、
「銀行型」って言い方をするよりも「ISO丸め」って言い方でいいんでない?
まぁ、>422は言い過ぎだね。

8087作ったときは、ISOじゃなかったのでは。

んじゃ、8087について語りたいときはansi丸めでw

>>423
エウレカ厨乙

団子ってmixiにアカウントは持ってたよな。
嫌いなサイトが2chだとか書いてたろ。

それどころかVIPのコテとばっかしつるんでたが

貧乳について教えてください

「インテル 64 アーキテクチャーおよびIA-32 アーキテクチャー最適化リファレンス・マニュアル」を読んでいて驚いたのだけど、
最近のCPUは除算のレイテンシとスループットが異様に小さいんだね。
FDIVでレイテンシとスループットが６と５って乗算とそんなに差がなくなっているね。
あとx87の表にNehalemがないのはNehalemってx87を積んでないの？

トランジスタの物量攻勢で、年々巨大なテーブルを引いて割り算するようになってんじゃないかな？
バグ付きPentiumで有名になったアレ。まだまだ早くなるのかも。解説お願い。

float同士の割り算の全パターンを事前にテーブル化して焼いとくのもそう遠くない未来のような。
(仮数部だけでいいとして46bitのインデックスを引っ張るテーブルがあればいいのか？

少なくとも一回計算した組み合わせくらいはキャッシュで持ってても良いよね

SSEを使うっているのは一般に、SSE命令を使っていればいいのか？
最近のコンパイラが吐くコードってスカラーでもaddssとかsubssを使っていることが多いので、
それだと何もしなくても”SSE”を使ったコードになってしまう気がする。
それともSIMDを使わないのはSSEを使っているとは言えないとなるのだろうか？

単に8087由来FPUの80bitレジスタが嫌なだけじゃね？
とエスパー回答してみる。

x86-64向けでなく組み込み関数でもなく、オプションも付けずにSSE命令を使うのはICCだけだろ

gccでも使うよ。適切にビルドされていれば

gccでも使うんだよ。でもさすがにパックドのコードを吐くことはないけど。

インテルコンパイラを使っているのですが、WindowsとLinuxで結果が変わってきてしまいます。
精度を同じにするには、どのオプションを使えばよいのでしょうか？

>>432
Pentiumの除算ユニットはRadix-4 SRTっていうアルゴリズムを使っている。
http://journal.mycom.co.jp/column/architecture/090/index.html

45nm以降のCoreアーキテクチャはそれより強力なRadix-16 SRTで
4ビットずつ処理出来るから従来の倍程度は速い。

>>439

>>439
http://homepage1.nifty.com/herumi/prog/prog90.html#PRECISION

新しいOpteron(Magny-Cours)で単精度のSSEのコードを走らせたんだけど、異様に遅い。
スカラーのコードの方が遙かに速いんだけど、そんなことってあるのかな？
インテルのCPUなら概ね2倍になるコードなんだけど、2倍どころか1/3にもなりそうな感じだった。
ただ、倍精度になるとスカラーよりも速くなる。
ICCでやったりgccでいろんなオプション試したけど、あんまりかわらないので何が原因かわからずにいる。
これだけで原因がわかるエスパーな人がいると助かるんだが。

ttp://pc.watch.impress.co.jp/docs/news/20100329_357660.html

＞4つ目は省電力機能の拡張だ。Opteron 6100にはIstanbul世代で実装されていなかったC1E(CPUがスリープモードにあるときの電
＞力を減らす機能)が実装されたほか、「AMD Cool Speed Technology」と呼ばれる省電力機能が実装されており、温度センサーで温
＞度が限界を迎えたと判断したとき、プロセッサのPステートをより低い段階へと強制的に移行させる機能だ。これらの機能により、プロセ
＞ッサの電力効率を前世代に比べて高めている。


CPU温度が高くてクロックダウンしてるとか？

分からんけどｗ

>>443
ベクトル化が下手かOpteronの単精度がうんこかOpteronが不得意な命令を使っているか、
だと思う。
ICCはインテルCPU用の最適化しかしないという噂だけど、
gccはそんなことないはずだし。

プログラムの一部でもさらす気があるなら
もうちょっと答えられるかも。

C++とIntrinsicライブラリ？
C++とインラインアセンブラ？
C++とアセンブラ？
32bit? 64bit?

>>443
スカラーのコード
　x87 or SSEのスカラー命令を使うコード?

SSEのコード
　コンパイラの設定でSSEを使うようにしたスカラーコード or 並列化したコード?

>>444
これさ、一度CPUクーラーのファンを止めて、高負荷で動かしてみたことがあるんだけど、
マザーから警告のアラームがなって、ヒートシンクをさわったらさわれなくなる位めちゃくちゃ熱くなっていたけど、
実行しているプログラムが落ちることなく、動き続けていたから、相当熱くなるような環境でないと、
クロックが落ちることは無いと思う。よく負荷テストとかでPrime95とかいうFFTを馬鹿みたいに立ち上げる様な
ことをしない限りは無いんじゃないかな。

>>445
レスサンクス。
使っているのはC++とIntrinsic。最初はインラインアセンブリで書いていたんだけど、
WindowsのVCCも考えて、Intrinsicに変更した。

コードをさらしたいのだけど、さすがにそれは出来ないので、
ちょっとシンプルなコードを書いて比較してみるよ。
何かわかったら書き込んでみる。
なんとなく思っているのは単精度だとシャッフルやらシフトを多用しているんだけど、
倍精度ではデータ幅の関係でそんなにやらなくていいので、Opteronはシャッフルとかシフトに弱いのかなあ？
とか思っている。

>>446
64bitで使っているんで、もはやコンパイラがx87のコードを吐いてくれません。
ちょっと表現が悪かったけど、SSEと言っているのはベクトル化したSIMDコードという意味。

>>448
シャッフルのレイテンシ
AMD Family 10h: 3 cycle
Intel Penryn以降: 1 cycle

「OpteronとIntel(Core2?)とで挙動が違う」のが問題であるなら、
キャッシュ構成を疑ってみるのはいかが。

Opteronの一次キャッシュって今も2-wayなの？

ちょこっと調べてみたら、クリティカルな部分は
ループの中に
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()でやってみたけど、そっちはもっと遅くなった。

配列A,B,Cのサイズを
32kBの倍数+64*n(n=1,2,...,511)
に変える

>>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にしてみるとか。

キャッシュスラッシングが原因だとすると
スカラーコードではA,B,Cは独立した
ループで処理してるのかな？

>>453
レスありがとう。

実はすでにやってみたけど変わらなかった。
ひょっとしてレジスタが足りなくなって、xmm0とかが、メモリに待避させられているのでは？
と思ったんだけど。
A,B,Cのサイズ自体多次元配列で、すごく大きいけど、ループの中では4K以下になるように処理している。
たとえば
AAA[i][j][k]の3次元配列があった場合、
A = AAA[i][j]
と1次元は配列として扱っている。そしてA[max]が4KB以下になるようにしている。

>>454
スカラーのコードもA,B,Cでループ内で処理している。
やっぱり、スラッシングが原因なのかなあ？

とりあえず、境界を合わせて128[bit]ずつnon temporalな書込みをする。

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]とスラッシングしてたらお手上げなんだけど。

>>456
>>457

いろいろと調べてみたら、キャッシュの問題ではなくて、
NUMAノードの設定が問題だったようだ。
メモリの確保をmalloc()ではなく、numa_alloc_onnode()でダイレクトにNUMAノードを指定してあげたら、
ほぼスカラーの倍の速度が得られたよ。
numactlをつかって、--preferred=nodes --localallocとかいろいろといろいろとオプションを
つけてやってみたけど、うまく指定したノードでのメモリ割り当てが出来ていなかったみたい。
いずれにしてもSSEの問題ではなかったので、変な質問をして申し訳ない。
レスしてくれた人ありがとう。
ただ、プリフェッチの指定をしていた部分でNehalemではかなり効果があったのが、
Opteronでは全く効果が無いので、プリフェッチの距離とかはOpteron用に考えないといけない様だ。

OpteronのNUMAは諸刃の剣だな。ハマればメモリの許す限りスケールするしな。
ていうかSMP Opteron由来の問題とは俺も気付かなかった。

（０００、０００）10
ー１０、８３５

とかいう問題

>>458
First touch 問題だね