10/05/26 14:24:25
どうじょ
前スレ
MMX SSE 3D NOW!のプログラミング
ｽﾚﾘﾝｸ(tech板)
2:デフォルトの名無しさん
10/05/26 17:33:42
MMXはぶってんじゃねーよ
3:デフォルトの名無しさん
10/05/26 21:26:22
3D NOW!はぶって
よし
4:デフォルトの名無しさん
10/05/27 16:54:37
即死しないといいね。
5:１
10/05/28 01:09:31
なんか書きこめよ、
6:1
10/05/28 02:52:41
おい、さっさと俺様に役に立つこと書き込めよ
7:1
10/05/28 17:06:51
早く書けよ
バカ
8:デフォルトの名無しさん
10/05/28 17:27:54
>>7
即死しなくなるのは 20 くらいだっけ？
君の心意気は買うが、即死しなくなるまで一日一度でよい。
9:1
10/05/28 17:36:26
>>8
うぜーよてめぇよぉ
誰にけんかうってんだ？
てゆーかさぁ同一人物の書き込みじゃないんだけど？
んなことより、さっさと何か俺の役に立つことを書き込みやがれ
10:1
10/05/28 18:15:51
>>9
うるせ～よバ～カ
11:デフォルトの名無しさん
10/05/28 22:24:24
即死を避けたいのはわかるが、罵倒はさすがにいかがなものか。
それっぽいコードを貼る、といった程度で勘弁してもらいたい。
12:デフォルトの名無しさん
10/05/29 13:47:05
>>9
それはいいんだが、翌日になってから投稿すると、効率よく即死回避できるし、
もしかすると無駄な即死回避投稿する前に誰か何かネタを振ってくれるかも知れない。
だから投稿する前に一日待て。
13:デフォルトの名無しさん
10/05/30 01:30:49
AVX使ってみた奴いる？
ど～だった？使いやすい？
14:デフォルトの名無しさん
10/06/01 01:18:41
何故？
15:1
10/06/05 00:13:34
なんか書きこめよ、くずども
16:デフォルトの名無しさん
10/06/05 01:00:22
なんか
17:デフォルトの名無しさん
10/06/05 21:13:26
>>15
無理だろ
たかが１０００レスに６年もかかったんだし
２日に１レスが妥当
18:デフォルトの名無しさん
10/06/05 21:16:09
とりあえず前スレのMMX、SSE2、AMD64比較ベンチのソース
URLﾘﾝｸ(kawahenteko.hp.infoseek.co.jp)
19:デフォルトの名無しさん
10/06/12 20:22:54
すすまねえな
20:デフォルトの名無しさん
10/06/15 03:02:12
インテル(R) Advanced Vector Extensions プログラミング・リファレンス
URLﾘﾝｸ(download.intel.com)
p.86
3.2 YMM ステート管理
> AVX とFMA拡張をサポートするには、OS がYMM ステートを管理する必要がある。
> そうでない場合には、AVXあるいはFMA 拡張命令（VEX エンコーディングによる
> 拡張128 ビットSIMD 命令を含めて）を実行すると#UD 例外が発生する。
原文
Intel(R) Advanced Vector Extensions Programming Reference
URLﾘﾝｸ(software.intel.com)
P.90
3.2 YMM STATE MANAGEMENT
> An OS must enable its YMM state management to support AVX and FMA extensions.
> Otherwise, an attempt to execute an instruction in AVX or FMA extensions(including
> an enhanced 128-bit SIMD instructions using VEX encoding) will cause a #UD exception.
21:デフォルトの名無しさん
10/06/15 22:19:14
URLﾘﾝｸ(msdn.microsoft.com)
In Windows 7 and Windows Server 2008 R2, both 32-bit and 64-bit versions of the operating system preserve the AVX registers across thread (and process) switches.
22:デフォルトの名無しさん
10/06/26 18:26:07
SSEっていつまでサポートされる？
今後SSEのクロックあたりの実行速度が改善される見込みは？
23:デフォルトの名無しさん
10/06/26 23:02:16
> SSEっていつまでサポートされる？
x86/AMD64がサポートされなくなるまで
>今後SSEのクロックあたりの実行速度が改善される見込みは？
複数のμOPに分解して実行していた命令が、1μOPで実行
できるような改良はありえる
24:デフォルトの名無しさん
10/07/01 22:07:45
ビット論理演算て型によらず結果は一緒だよな？
なんで型ごとにあるんだ？
pxor / xorps / xorps とか。
例外も (対応CPUなら) 同じみたいだし。
25:デフォルトの名無しさん
10/07/01 22:14:53
>>24
もすこしSIMDを勉強したほうがよく寝？
26:デフォルトの名無しさん
10/07/01 22:18:17
>>25
どうしてもわからなくて夜も眠れないから
わかるなら教えてくれ！
27:デフォルトの名無しさん
10/07/01 22:22:37
結果の出し方が違くね？
28:デフォルトの名無しさん
10/07/01 22:28:39
結果の出し方は同じじゃね？
29:デフォルトの名無しさん
10/07/02 02:18:02
整数SIMDブロックとFP-SIMDのブロックのそれぞれに用意されている
演算ユニットを明示的に使うため
30:デフォルトの名無しさん
10/07/02 08:31:38
>>29
何のために？省電力？
パフォーマンスを考えた場合、
xorpd, xorps は PORT5 しか使えず、
pxor はPORT0, PORT1, PORT5 の3つを使える為、
pxor のみで十分だが。
31:デフォルトの名無しさん
10/07/02 11:16:59
パフォーマンスのためだ
異なるブロック間でのデータのやり取りにはペナルティがあるので
各ブロックに演算ユニットが用意されている
32: ◆0uxK91AxII
10/07/02 13:36:20
>>24
歴史的経緯に因る。
pdの追加は謎だけど。
33:|ω・`)
10/07/02 13:36:57
ペナルティがあったのって熱湯だけじゃないの？
34:デフォルトの名無しさん
10/07/02 14:59:50
インテル(R) 64 アーキテクチャーおよびIA-32 アーキテクチャー
最適化リファレンス・マニュアル
URLﾘﾝｸ(download.intel.com)
のp.43,.56を読むんだ
35:デフォルトの名無しさん
10/07/02 15:09:42
>>34
chapterごとにページ振ってあるんだが
何章の何ページだ？
36:|ω・`)
10/07/02 16:18:55
へー
ポート間じゃなくてintとfpの間に入るんだ
37:デフォルトの名無しさん
10/07/02 22:35:56
addpd xmm0, xmm1
xorpd xmm0, xmm1
addpd xmm0, xmm1
xorpd xmm0, xmm1
....
と
addpd xmm0, xmm1
pxor xmm0, xmm1
addpd xmm0, xmm1
pxor xmm0, xmm1
....
でパフォーマンスを比べてみた。
●実測
Core2Duo の E8400とT7300では同じタイム。
Corei7 では後者が倍時間がかかった。
●シミュレーション
nehalem / sandy とも同タイム。
38:デフォルトの名無しさん
10/07/02 22:41:17
addpd xmm0, xmm1
mulpd xmm2, xmm3
pxor xmm4, xmm5
pxor xmm6, xmm7
pxor xmm8, xmm9
の繰り返し
のように直後に値を使わない場合は
Corei7 だと pxor の方が実測、シミュレーションとも速い。
Core2Duoはこの場合もまったく同じ。
39:デフォルトの名無しさん
10/07/03 12:28:47
整数演算主体のプロジェクトを
/arch:AVXでビルドしてもあまり速くならないの？
40:デフォルトの名無しさん
10/07/03 12:39:25
SSEとAVX-128bitの組み込み関数は共通なので
コンパイラオプションで生成するバイナリを切り替えられる
整数SIMDの組み込み関数を使っているのなら
多少の性能向上はあると思われる
41:39
10/07/03 12:45:39
>>40
とんくす
42:デフォルトの名無しさん
10/07/03 12:49:48
エスパーだな。
俺はSSEを使っていないコードかと思った。
それだったら、多分最初の実装だとデコーダをカリカリにチューンはしないだろうから
命令の帯域がクリティカルな人は効果あるんじゃない？としか言えない。
命令長が短くなるのと、三項演算のおかげで退避に使う命令を減らせるからコードが全体的に少しだけ小さくなる。
43:39
10/07/03 13:50:08
プロジェクトのほんのごく一部にSSE2のintrinsicを使ってます。
さらに/arch:SSEではほとんど速くならず、
/arch:SSE2ではかなり高速化したプロジェクトです。
44:デフォルトの名無しさん
10/07/03 14:07:09
整数演算入ったのSSE2だし
45:デフォルトの名無しさん
10/07/03 14:26:15
VCの/archはFPのスカラーコードで使う命令セットを
指定するのが主な使い方なので性能向上に過度な期待は
しないほうがいい
46:39
10/07/03 15:01:42
分かりました。どうもありがとうございました。
47:|ω・`)
10/07/03 15:24:13
>>37-38
スループットの方は単純に fp logic の実行ポート数じゃん (Core2 は3つ、i7 は1つ)
レイテンシの方は、Core2 の fp logic 命令って実は int スタックらしいよ
だからどっち使っても同じ
48:デフォルトの名無しさん
10/07/04 02:31:05
nehalemでは >>37 は前者の方が速いので、
ペナルティがあると考えるのが妥当かと。
ただ、シミュレーションの結果と一致しないのは気になるが。
49:デフォルトの名無しさん
10/07/04 03:18:18
比較対象が違ってるんだが
50:デフォルトの名無しさん
10/07/04 08:08:34
なにが？
51:|ω・`)
10/07/04 10:39:45
Nehalem の fp logic は fp スタックだから
他の fp 命令と繋ぐのはペナルティなし、int<->fp 繋ぐのは2クロックペナルティ
ってことで>>34の資料と一致してるんじゃない
シミュレータは多分うんこ
52:デフォルトの名無しさん
10/07/04 10:50:49
"シュミレーター" の検索結果
約 334,000 件 （0.14 秒）
53:デフォルトの名無しさん
10/07/04 15:06:07
>>51
Nehalem のFP/SIMD/SSE2 Move and Logic の Domain は FP と書いてあるんだけど、
これって嘘なの？
54:デフォルトの名無しさん
10/07/17 20:37:01
__m128(fp32x4)の任意の要素に任意の値を書き込みたいんだが、
どういう実装がベストなのかな？↓がベストかな？
__m128 set_elem( __m128& v, const uint32_t index, float32_t e )
{
ALIGN(16) const float32_t mask_table[4*4] =
{
1,0,0,0,
0,1,0,0,
0,0,1,0,
0,0,0,1
};
const __m128 mask = _mm_load_ps( mask_table + index * 4 );
return _mm_or_ps( _mm_and_ps( _mm_set1_ps(e), mask ), _mm_andnot_ps( v, mask ) );
}
55:デフォルトの名無しさん
10/07/17 22:27:13
>>54
言語が何か分かんないけど、
float32_t の 1 でマスク作れるの？
andnot って1個目の引数のnotを取ると思うんだけど、順番あってる？
メモリ経由で、直接変更する要素に e を書くのとどっちが早いかなあ。
56:デフォルトの名無しさん
10/07/17 22:47:40
>>55
すいません、どっちも間違ってましたｗ
まあ、実際1要素だけ書き換えなんて
やらないんでしょうねえ。
57:デフォルトの名無しさん
10/07/17 22:59:05
4レジスタくらいなら直接保持したほうが速いと思う
で、値は1レジスタにまとめて読み込んで積をとる
58:デフォルトの名無しさん
10/07/24 10:21:46
画像フォーマットの(en|de)codingで効果を発揮するのはSSE2までだけで十分だったりするの？
SSE3 SSSE3 SSE4まで使って頑張ってもSSE2までしか使わない場合と大して変わらないとかあるの？
59:デフォルトの名無しさん
10/07/24 10:45:57
>>58
だんごさんはSSSE3が画像処理に意外と便利だと言っていたけど
60:デフォルトの名無しさん
10/07/24 11:56:53
SSSE3 SSE4.1 SSE4.2は無用の長物。
61:デフォルトの名無しさん
10/07/24 19:55:02
劇的に速くなることはマレだと思うが、
あれば便利な命令は結構ある。
互換性を考えると使いにくいけどね。
一般向け商用ソフトでパフォーマンスが重要なものの場合、
SSE2/SSE3/SSSE3/SSE4.1/SSE4.2/AVX/FMA....
と、すごい種類の可能性があって、
これらすべて用の関数を設計、チューニング、評価なんてとても出来ないから、
SSSE3/SSE4.1/SSE4.2 なんかは飛ばされがち。
62:デフォルトの名無しさん
10/07/24 20:00:27
OOPのインターフェースつかってSSEのXXを対応したバージョンと、
それ以外のコードの2種類くらいを用意してあげればいいんじゃね？
環境はユーザー責任でスイッチしてもらう。
63:デフォルトの名無しさん
10/07/24 22:04:16
>>62
それやりたいんだけどさ、C++のメンバ関数をアセンブラでどう書けばいいのかがわからない。
インラインアセンブラで書いたプログラムを64ビット用にコンパイルしようとしたら
cl64.exeはインラインアセンブラには対応してないとかエラーが出てコンパイルできないorz
64:デフォルトの名無しさん
10/07/24 22:23:50
>>63
cl64.exeはインラインアセンブラ非対応。
ml64.exeを使うかintrinsic命令を使うかしかない。
>>62
ユーザーが自分でスイッチは無いな。
普通は実行時に自動判別。
事情により新命令を使ったバージョンしか作らないのなら、
対応してないCPUでの実行時は非対応CPUである旨を表示する。
個人で作った個人用アプリなど、非常に限られた人しか使わないのであれば、
非対応CPUで使ったらいさぎよくOSの例外発生メッセージが出るのもありかも。
65:デフォルトの名無しさん
10/07/25 00:01:02
>>63
ぶっちゃけそのプログラムは64ビットネイティブにする必要はあるのか？
66:デフォルトの名無しさん
10/07/25 09:11:31
>>65
おれは最近は、個人でしか使わない趣味のプログラムはすべて64bitネイティブだよ。
レジスタが倍あるし、いまさら窮屈なレジスタ数で組みたくない。
C++オンリーでもパフォーマンスは上だし。
67:デフォルトの名無しさん
10/07/25 15:07:56
制約が緩くなるのはどう考えても悪いことじゃないな
68:デフォルトの名無しさん
10/07/25 15:17:40
>>66そのきもちはすこしわかる。
68系のデータ8本、アドレス8本の環境から、
86系に移ってきたときには窮屈な思いをしたもんだ。
69:デフォルトの名無しさん
10/07/25 19:10:36
>>65
>>63だが、>>66が全部言ってくれた。
インラインアセンブラで組んだウェーブレット変換のプログラムを
ちょっと64ビットで動かしてみたくなったのさ。
70:デフォルトの名無しさん
10/07/25 21:32:13
CL /FA でアセンブリ出力して、修正、アセンブル、リンクですかのう。
71:63
10/07/26 00:58:40
>>69
ありがとう
/FAオプションつけてコンパイルしたら、.asmファイルが出てきた
やる気出てきた。
ただ、今はDirectCompute用のプログラム書いてるんだけどね．．．
一応strategyパターン使ってCPU用とGPU用の処理を分けてる。
72:デフォルトの名無しさん
10/08/08 13:17:01
自作のSSEラップクラスとXMMATRIXの行列積について
生成されるコードを見比べてみたところ(VC2010EE)
自作のは並べ替えが甘くメモリ退避が多く、そのせいか命令数が倍ぐらいで
XMMATRIXのに比べて1.5倍ぐらい遅かった。
違いといえばXMMATRIXはイントリンシック命令直書きで
自作のは薄いクラスでラップされているぐらい。畳み込みで
同等のコードが生成されるはずなのに・・
結局、イントリンシック命令は直書きしないと
最適化がオミットされちゃうんですかね？
73:デフォルトの名無しさん
10/08/08 18:33:50
>>72
ラップすればするほどパフォーマンスが落ちるのは当たり前だ。
さらに作者の能力や熱意にも大きく依存する。
74:デフォルトの名無しさん
10/08/09 11:33:36
>>72
メモリのアクセスパターンは重要だよ。命令数が同じでも、キャッシュに乗ってないメモリアクセスが入ると途端に遅くなる。
75:デフォルトの名無しさん
10/08/09 22:13:49
>>73
適当なことを言うなよ。
>ラップすればするほどパフォーマンスが落ちるのは当たり前だ。
なぜ当たり前と言えるんだ？
別にいくらラップしようが__forceinlineをつけて展開すれば
最後に出来上がるものは同じじゃねーか。
事実、全てインライン展開されているのは確認しているし、
そっから先最適化するかしないかは、コンパイラがやるかやらないかでしかない。
結局、コンパイラが何か俺のわからない理由で最適化を打ち切っているようにしか
みえない。
>さらに作者の能力や熱意にも大きく依存する。
同等のコードが生成されるはず、と書いているように
そもそも同じ様式を採用している。
>>73
一応、ベンチマークなんで、同じ条件で回している。
76:デフォルトの名無しさん
10/08/09 22:22:23
>>75
じゃあ勝手に好きなようにやれ
77:デフォルトの名無しさん
10/08/09 22:45:31
>>76
結局ちゃちゃいれて終わりか。
なんつーか、無意味な奴。
78:デフォルトの名無しさん
10/08/09 22:50:48
>>75
確かに、よく分からない理由で
コンパイラが最適化の手をゆるめる事はある
PGOを適用すればレジスタをよりうまく使い回して
メモリアクセスが減るけど
Expressじゃ使えないんだよね
79:デフォルトの名無しさん
10/08/10 08:26:58
コンパイラの最適化を過信しすぎだな。
80: ◆0uxK91AxII
10/08/10 10:45:56
URLﾘﾝｸ(msdn.microsoft.com)
( ﾟ,_Jﾟ)
81:デフォルトの名無しさん
10/08/10 11:17:27
＞自作のは並べ替えが甘くメモリ退避が多く
＞一応、ベンチマークなんで、同じ条件で回している
自己矛盾にも気付けないらしい。
82:デフォルトの名無しさん
10/08/10 22:05:00
>>81
お前バカだろ、もう出てくるなよ。
つーか、何か言いたいことがあるなら
自分が試した結果を交えて話せ。
糞の役にも立たないんだよ。
83:デフォルトの名無しさん
10/08/11 10:26:26
>>82
悪いけど、コンパイラによる話なんだから該当コンパイラのスレでやってくれ。
空気悪くなって迷惑。
それと、具体的なコードを出さない限り具体的な話なんてできないよ。
84:デフォルトの名無しさん
10/08/11 18:41:23
SSEと番人は相性悪いな
結局ループせず必要な回数だけ命令を並べるほうが速い
以上チラ裏でした
85:デフォルトの名無しさん
10/08/11 18:48:22
>>81
自作:メモリ退避が多い
自作じゃない方:メモリ退避が多くないらしい
どう見ても自作の方が不利ですね。ご指摘本当にありがとうございました。
86:デフォルトの名無しさん
10/09/08 18:39:35
進まないね
もう他のCPUのSIMDの話題もおｋにしない？
87:デフォルトの名無しさん
10/09/09 11:25:36
他のCPUってARMのNEONとかか？
88:デフォルトの名無しさん
10/09/16 20:42:14
SSEのプリフェッチ命令を使っても効果が出ない。
使い方がわからないんだよな。
89:デフォルトの名無しさん
10/09/16 20:54:23
距離を測ってそれに合わせたタイミングで発行すればよろし
90:デフォルトの名無しさん
10/09/16 21:03:34
CPU固有の最適化になるわさ
そらICCも_mm_prefetchを消したくなるわ
91:デフォルトの名無しさん
10/09/16 22:07:39
キャッシュが潤沢で
ハードウェアプリフェッチが効いてる環境だと
ソフトウェアプリフェッチは要らないんじゃないの？
92:デフォルトの名無しさん
10/09/17 09:07:54
Core2,、Core iのハードウェアプリフェッチの動作仕様を書いた
文書はあるのか？
93:デフォルトの名無しさん
10/09/17 13:27:24
１．ループの外でバッファの先頭を指定して_mm_prefetch_ntaする。
２．ループ内で、バッファ先頭から順に読んで処理し、_mm_stream_si128で書き出す。
このとき、CPUが気をきかせて、1ループにかかった時間から最適な距離を判断して、
キャッシュ汚染しないプリフェッチをハードウェアで自動的にしてくれたりする？
94:デフォルトの名無しさん
10/09/17 13:31:41
表記間違えてるけどそこは無視してお願い
95:デフォルトの名無しさん
10/09/19 13:38:02
for(i=0;i<16;i++)
a[i]^=(d[i]+c[i])%16;
このプログラムをSSE2で書きたいのですがわかりません。
教えてください。よろしくお願いします。
96:デフォルトの名無しさん
10/09/19 14:18:07
宿題か？
97:デフォルトの名無しさん
10/09/19 14:24:07
暗号を作っているんですけど高速化したいんです。メインループは
for(k=0;k<500000;k++){
for(j=0;j<16;j++){
for(i=0;i<32;i++){
d[i]^=GF[mlt(FG[a[j]],FG[h[i][FG[b[j]]]])];
}
}
こんな感じなんですがGPGより4倍くらい遅いです。
98:デフォルトの名無しさん
10/09/19 14:45:45
>>95
全部あんろーる
>>97
コンパイラさんに任せてあきらめる
99:デフォルトの名無しさん
10/09/19 14:49:48
あんろーるってなんですか？
128ビット単位なので必要のないループが減らせたら高速化できると思うので
基本的に行列演算の高速化だと思います。
100:デフォルトの名無しさん
10/09/19 14:58:34
iccでベタ書きして最適化オプション/pragmaを加えるだけでおk？
101:デフォルトの名無しさん
10/09/19 15:01:15
すみません、具体的にコマンドラインを教えてください。
使用環境はCygwin32,gcc4です。
コンパイラに任せてもSSE2命令に変換してくれるのでしょうか？
102:デフォルトの名無しさん
10/09/19 15:03:49
実験したいからとりあえずmltとGF,FGの型おせーて
103:デフォルトの名無しさん
10/09/19 15:06:13
>>101
iccならベタ書きの内積計算関数でdpps使ってくれたりするから多分いやもしかしたらいけるかもしれない
104:デフォルトの名無しさん
10/09/19 15:08:47
int N=256;
static int GF[256];（GF(256)有限体の元）
static int FG[256]; GF(256)の対数値
int mlt(x, y){
if(x==0||y==0)
return 0;
return ((x+y-2)%(N-1))+1;
}
です。よろしくお願いします。
105:デフォルトの名無しさん
10/09/19 15:13:44
int h[32][256];
追加です。因みに
for(i=0;i<16;i++)
a[i]^=(d[i]+c[i])%16;
の高速化だけでもいいです。
106:デフォルトの名無しさん
10/09/19 15:15:24
ループから外して式をばらすってことですか？＞あんろーる
107:デフォルトの名無しさん
10/09/19 15:18:04
C言語からインラインアセンブラで呼び出したいと思うのですが、
うまくいきません。
moveq d,%xmm0
moveq c,%xmm1
paddb %xmm1,%xmm0
moveq a,%xmm1
pxor %xmm1,%xmm0
配列のデータをレジスタにセットするところもわかりません。
108:デフォルトの名無しさん
10/09/19 22:03:16
518 ：デフォルトの名無しさん：2010/09/19(日) 14:20:02
for(i=0;i<16;i++)
a[i]^=(d[i]+c[i])%16;
このプログラムをSSE2で書きたいのですがわかりません。
教えてください。よろしくお願いします。
C言語からインラインアセンブラで呼び出したいと思うのですが、
うまくいきません。
moveq d,%xmm0
moveq c,%xmm1
paddb %xmm1,%xmm0
moveq a,%xmm1
pxor %xmm1,%xmm0
配列のデータをレジスタにセットするところもわかりません。
109:デフォルトの名無しさん
10/09/20 20:17:26
>>107
インラインアセンブラ嫌いだから組み込み関数で書くけどこんな感じ。
_mm_storeu_si128((__m128i*)a,_mm_xor_si128(_mm_loadu_si128((__m128i*)a),_mm_and_si128(
_mm_add_epi8(_mm_loadu_si128((__m128i*)b),_mm_loadu_si128((__m128i*)c)),_mm_set1_epi8(0x0f))));
110:デフォルトの名無しさん
10/09/22 03:27:19
トリックを重ねたSandy Bridgeマイクロアーキテクチャ
URLﾘﾝｸ(pc.watch.impress.co.jp)
111:デフォルトの名無しさん
10/09/22 06:24:35
>>110の記事で256ビットを演算器の使い回しで実現するって部分で
128ビット幅の浮動小数点用と128ビット幅の整数演算用を使ったってのがよく理解できなかった
128ビットについては普通に浮動小数点用のを使って、
整数演算用が同サイクルに使われることがないから、
整数の加算乗算シフトとかを組み合わせて浮動小数点と同じことをしてるってことかな？
112:デフォルトの名無しさん
10/09/22 09:17:56
#include <stdio.h>
#include <stdlib.h>
int main(void){
unsigned long long int a,b;
a=strtoull("0x1111111111111111",(char **)NULL,16);
b=strtoull("0x2222222222222222",(char **)NULL,16);
a=a^b;
printf("%llu\n",a);
return 0;
}
このプログラムをMMXを使って最適化したいのですがわかりません。
アセンブラで書くしかないのでしょうか。
113:デフォルトの名無しさん
10/09/22 11:09:59
>>112
マルチうざい。
114:デフォルトの名無しさん
10/09/22 14:08:51
>>110
つまりAVXはSSEより速くはならないってこと？
単精度の4次元ベクトルは扱うことがあっても8次元や倍精度とか使わないからなぁ
これの最速のSSEコードを教えてください
32ビットカラービットマップを24.8固定小数点で線形補間するコードです
自分で書いてはみたものの元のCより遅いので
typedef struct
{
union
{
unsigned char b, g, r, a;
unsigned long c;
};
} COLOR;
unsigned long Get(unsigned x, unsigned y, COLOR* Table, unsigned width, unsigned height)
{
COLOR c;
c.r = (
(Table[(y >> 8) * width + (x >> 8)].r * (0x100 - (x & 0xff)) + Table[(y >> 8) * width + (x >> 8) + 1].r * (x & 0xff)) * (0x100 - (y & 0xff))
(Table[((y >> 8) + 1) * width + (x >> 8)].r * (0x100 - (x & 0xff)) + Table[((y >> 8) + 1) * width + (x >> 8) + 1].r * (x & 0xff)) * (y & 0xff)
+ 0x8000) >> 16;
以下g, b, aと繰り返す
return c.c;
}
115:デフォルトの名無しさん
10/09/22 14:20:15
>>114でCで実際に書いたときは乗算に[257][256]のテーブルを使用してました
116:デフォルトの名無しさん
10/09/22 14:40:16
257だと!?
117:デフォルトの名無しさん
10/09/22 21:10:04
このループはSSE2使っても早くならないですか？
ていうかSSE2使えますか？
for(j=0;j<16;j++){
for(i=0;i<16;i++){
d1[j]^=GF[e1[j][i]];
d2[j]^=GF[e2[j][i]];
}
}
118:デフォルトの名無しさん
10/09/22 21:33:03
xorだけsimd使ってもなぁー
d1の計算とd2の計算で2つスレッド使って別にループ回す方が
それにしてもsynchronizeのコストがあるしなぁ
119:デフォルトの名無しさん
10/09/23 05:41:30
配列の配列ってアドレスがバラバラだからSIMD処理できないかも。
120:デフォルトの名無しさん
10/09/24 02:10:48
SSE使うかどうかに関係無く、参照アドレスが連続なる様にしておかないと
キャッシュミスして処理速度がガタ落ちになる
昔ならともかく、今はどうしても明示的にSSEをしなければならない場合以外は
コンパイラー任せでいいんじゃないの
121:デフォルトの名無しさん
10/09/24 02:11:29
SSEを使用しなければならない場合以外は
122:デフォルトの名無しさん
10/09/30 02:18:33
変数は全部unsigned charですがコンパイラでやるとSSE2命令にしてくれません。
丸投げですが、組み込み関数でもいいのでSSE2のアセンブリコードをお願いします。
for(j=0;j<16;j++){
a[j]^=(d1[j]+c[j])&0xff;
b[j]^=(d2[j]+c[j])&0xff;
buf[j]^=d1[j];
buf[j+16]^=d2[j];
}
123:デフォルトの名無しさん
10/09/30 07:36:26
またお前か
124:デフォルトの名無しさん
10/09/30 07:41:34
128*2でしか使えないのか
蓋を開けてみればAVXも残念なものだった
125:デフォルトの名無しさん
10/09/30 09:31:46
高々数万のCPUに過大な期待すんな。
126:デフォルトの名無しさん
10/09/30 09:46:55
現プロセスにおいてトランジスタ効率上げるための折衷仕様だから、
いずれ改善されるだろう
127:デフォルトの名無しさん
10/09/30 22:14:46
>>124
> 128*2でしか使えないのか
コアあたり、1クロックで256bitレジスタの加減算と積が出来ると思うんだけど。
128:デフォルトの名無しさん
10/10/01 14:51:58
>>122
じゃあ、こんな感じで。
__m128i *pa = (__m128i*)a; __m128i *pb = (__m128i*)b; __m128i *pc = (__m128i*)c;
__m128i *pd1= (__m128i*)d1;__m128i *pd2= (__m128i*)d2;__m128i *pbuf=(__m128i*)buf;
__m128i *pa = (__m128i*)a; __m128i *pb = (__m128i*)b; __m128i *pc = (__m128i*)c;
__m128i *pd1= (__m128i*)d1;__m128i *pd2= (__m128i*)d2;__m128i *pbuf=(__m128i*)buf;
__m128i va, vb, vc, vd1, vd2;
va = _mm_loadu_si128(pa); vb = _mm_loadu_si128(pb); vc = _mm_loadu_si128(pc);
vd1 = _mm_loadu_si128(pd1); vd2 = _mm_loadu_si128(pd2);
_mm_storeu_si128(pa, _mm_xor_si128(va, _mm_adds_epu8(vd1, vc)));
_mm_storeu_si128(pb, _mm_xor_si128(vb, _mm_adds_epu8(vd2, vc)));
_mm_storeu_si128(pbuf++, _mm_xor_si128(_mm_loadu_si128(pbuf), vd1));
_mm_storeu_si128(pbuf, _mm_xor_si128(_mm_loadu_si128(pbuf), vd2));
129:デフォルトの名無しさん
10/10/02 08:25:41
エラーがでるよ。こうやって書いて！
_mm_storeu_si128((__m128i*)a,_mm_xor_si128(_mm_loadu_si128((__m128i*)a),_mm_and_si128( _mm_add_epi8(_mm_loadu_si128((__m128i*)d1),_mm_loadu_si128((__m128i*)c)),_mm_set1_epi8(0x0ff))));
_mm_storeu_si128((__m128i*)b,_mm_xor_si128(_mm_loadu_si128((__m128i*)b),_mm_and_si128( _mm_add_epi8(_mm_loadu_si128((__m128i*)d2),_mm_loadu_si128((__m128i*)c)),_mm_set1_epi8(0x0ff))));
130:デフォルトの名無しさん
10/10/02 08:27:27
あとこれも何とかして
for(j=0;j<16;j++){
for(i=0;i<16;i++){
d1[j]^=GF[e1[j][i]];
d2[j]^=GF[e2[j][i]];
}
}
131:デフォルトの名無しさん
10/10/02 09:40:15
エラーが無くなりました。早とちりでした。
132:デフォルトの名無しさん
10/10/02 10:02:14
buffに代入されません。
memcpy(&buff[32*k],buf,32);
133:デフォルトの名無しさん
10/10/02 10:18:44
ｽﾚﾘﾝｸ(tech板:95-番)
ｽﾚﾘﾝｸ(tech板:696-番)
ｽﾚﾘﾝｸ(tech板:195-番)
ｽﾚﾘﾝｸ(tech板:389-番)
ｽﾚﾘﾝｸ(tech板)
こいつどんだけマルチポストしてるんだ。
探せばまだありそうな気がする。
134:デフォルトの名無しさん
10/10/02 10:20:44
マルチポストがいけないとは言わないが、アルゴリズムとコードと態度の糞っぷりが果てしない。
135:デフォルトの名無しさん
10/10/02 14:16:41
_mm_storeu_si128(pbuf++, _mm_xor_si128(_mm_loadu_si128(pbuf), vd1));
_mm_storeu_si128(pbuf, _mm_xor_si128(_mm_loadu_si128(pbuf), vd2));
pbuf--;
buf[0]=*pbuf->m128i_u8;
pbuf++;
buf[16]=*pbuf->m128i_u8;
clではコンパイル出来るのに、GCCだと共用体のメンバじゃないというエラー
が出てコンパイルできません。なぜですか。正しい代入方法を教えてください。
136:デフォルトの名無しさん
10/10/02 14:43:21
_mm_storeu_si128(pbuf++, _mm_xor_si128(_mm_loadu_si128(pbuf), vd1));
_mm_storeu_si128(pbuf, _mm_xor_si128(_mm_loadu_si128(pbuf), vd2));
pbuf--;
buf[0]=*pbuf->m128i_i8;
pbuf++;
buf[16]=*pbuf->m128i_i8;
書いてもらったプログラムなのでよくわかりませんが、128ビットの
共用体を2つ分使っているのではないかと思います。
ところで上のプログラムをclでコンパイルすると通るのに、GCCだと
共用体のメンバじゃないといわれてエラーが出ます。pbufからbufに
値を代入する正しい方法を教えてください。もしくはmemcpyでpbuf
からbuffに代入する方法があったら教えてください。よろしくお願いします。
137:デフォルトの名無しさん
10/10/02 14:56:38
memcpyの使い方も知らない人はC言語の勉強からやり直した方が良いと思うんだ。
大体にして、スピードなんて後でいいだろ。
本当に良いプログラムなら指数的なオーダーで遅くならない限りみんな使ってくれるし、そんな良いソフトがオープンソースならガリガリに最適化してくれる人も現れるよ。
138:デフォルトの名無しさん
10/10/02 15:01:50
何かを習得するのって本当に難しい。使いながら解らない所を調べて
いくという感じで。ネットで調べてるんだけどなかなかいい情報が
得られない。エラーメッセージの意味もよくわからないし。
139:デフォルトの名無しさん
10/10/02 15:06:30
何を調べてるのかしらないが、英語の資料を除外してるといい情報は出ないぞ
いい情報は英語でしかないことが多い
140:デフォルトの名無しさん
10/10/02 16:45:14
>>114を教えていただけませんか？
Cより高速化できる見込みがあるかどうかだけでも結構です
141:デフォルトの名無しさん
10/10/03 21:02:01
>>140
ソース見にく過ぎ
142:デフォルトの名無しさん
10/10/05 06:14:52
見込みはないです。
143:デフォルトの名無しさん
10/11/01 01:24:37
AMDを応援したいがAVX対応が1年も遅れるようじゃSandyBridgeを買わざるを得ない。
144:デフォルトの名無しさん
10/11/01 01:31:18
地雷踏みはIntel信者の団子にでも任せておけばいいじゃないか。
145:,,・´∀｀・,,） ・・・→ -○○○
10/11/02 19:37:28
SDE使えばAMDのCPUでもAVXのコードを実行できるんだから好きにしろよ
むしろSandy Bridge出てからコード書こうと思ってるならどのみち出遅れてるから
いっそBulldozerまで待ってやれよ
146:デフォルトの名無しさん
10/11/05 19:55:53
>>145
シミュレーションじゃ実行速度のメリットをまったく味わえないじゃないか。
147:,,・´∀｀・,,） ・・・→ -○○○
10/11/05 20:50:16
俺は既にXOP向けのコード書いてるから実機（Bulldozer）は少なくとも買うよ。
BulldozerってSIMDユニットは結局1モジュールあたり４基（MMX×2、FMAC×2）だよな？
FPではクロック当たり性能で差は付かなさそうだ。
あとは整数だが、FMAC側でも簡単な整数論理演算ができれば胸熱なんだが。
FP積和算の理論スループットは同クロックならSandy Bridge 4コア＝Bulldozer 8コアで
あとは整数
148:デフォルトの名無しさん
10/11/06 02:28:59
>>147
俺は素直に先に出るSandyを買うよ。
その先はAMDのFMA4とintelのFMAの動向が見えてきたら考える。
命令セットだけ見るとFMA4の方が良いが....
149:,,・´∀｀・,,） ・・・→ -○○○
10/11/06 02:54:25
どっちも買えばいいじゃん。
Intel現行仕様の3オペランドFMAはAMDも「Bulldozer 2」で対応するらしい。
いっぽうIntelの4オペランドFMAの採用計画は不明。もともとIntelの提案仕様だしVEX空間にあるので
採用しない理由はないと思うが。
実際プログラム書いてみたけど3オペランドで困るケースって本当に.少ないんだわ。
しかもほとんどのケースでvfmadd231psで事足りる(132, 213は殆ど使わない）
むしろ3オペランド版のほうが1バイト短い。
どうせなら4オペランド版はimm8の残り4ビットを何かのオプションとして使いたいよね。
vbroadcastss + fmaddpsを1命令に纏めることができるとかさ。
Intelが3オペランド仕様に修正した技術的な理由はなんとなくわかる。
iaca使ってみればわかるが、AVXで4オペランド命令は複合命令ばっかしだぜ。
Simpleデコーダのロジックケチりたいんだろ。
150:デフォルトの名無しさん
10/11/06 08:22:34
>>149
AMDがintel仕様の3オペランドのFMAに対応するってマジか？
ソースきぼんぬ。
151:,,・´∀｀・,,） ・・・→ -○○○
10/11/06 11:17:42
> These patches add support for upcoming bdver2 AMD processors:
> BMI (Bit Manipulation Instructions)
> TBM (Trailing Bit Manipulation)
> FMA3 (three operand FMA) instructions
>
> The public specifications for BMI and TBM are in progress (they are
> today available under NDA). They will appear in one of the AMD64
> Architecture Programmer's Manual Volumes 3-6. I can post the
> mnemonics definitions if needed. The FMA3 specification is documented
> in URLﾘﾝｸ(software.intel.com)
URLﾘﾝｸ(archives.free.net.ph)
bdver2ってのが22nm版なのか後期リビジョンなのかが不明
152:デフォルトの名無しさん
10/11/06 16:58:50
>>151
thx
FMAの命令セットの分裂は避けられたってことか。
153:,,・´∀｀・,,） ・・・→ -○○○
10/11/06 18:29:31
こうでそ
AMD「SSE5で3オペランドFMAをサポートします」
↓
Intel「うちもそっくりそのまま＋addsub命令も加えて4オペランドFMAをサポートします」
↓
AMD「SSE5やめてAVX互換で仕切りなおします。FMAはIntelさんと同じ4オペランド方式になります」
Intel「デコードコストが大きいのでやっぱ4オペランド当分やめて3オペランド（新方式）でやります」
↓
AMD「え？」
Inteｌ「え？」
てか、SSE5にあったCVT16はXOP→VEX（Intelもサポート）という流れになってるし
IntelとてAMDはAVX普及に協力してもらう立場。
摺り寄せは当然やるでしょう
154:デフォルトの名無しさん
10/11/06 19:53:42
intelが元々考えてた4オペランドと
AMDが一番初めに考えてた3オペランドの
命令の詳細を見たことが無いけど、
これって
今の AMD FMA4 / intel FMA と同じ？
155:,,・´∀｀・,,） ・・・→ -○○○
10/11/06 20:08:59
・AMDのSSE5版FMA・・・廃止
・AMDのFMA4（現行）・・・Intelの初期仕様のFMAそのもの
・IntelのFMA・・・4オペランド→3オペランド(まったくの新規)
SSE5仕様書のミラーがあったｗｗｗ
URLﾘﾝｸ(www.cs.northwestern.edu)
Intel AVX規格書第３版（FMA仕様改定前）
URLﾘﾝｸ(softwarecommunity.intel.com)
156:デフォルトの名無しさん
10/11/06 20:13:54
>>155
オー、
thx、very much!
157:デフォルトの名無しさん
10/11/07 19:06:08
デスクトップのBulldozerは4月以降か、思ったより速いよ。
158:,,・´∀｀・,,） ・・・→ -○○○
10/11/07 19:13:54
ESが12月で4月に生産とか本当に出来るのかあやしい
159:デフォルトの名無しさん
10/11/07 19:39:10
ベンチマダー?
160:デフォルトの名無しさん
10/11/08 00:59:39
> デスクトップのBulldozerは4月以降か、思ったより速いよ。
早いが速くない
161:デフォルトの名無しさん
10/11/10 18:00:17
>>147
斜め下の期待を裏切らないAMDの事だから
直近: Sandy Bridge 4コア vs Bulldozer 4or6コア(2or3モジュール)
将来: Sandy Bridge 6コア vs Bulldozer 8コア(4モジュール)
とかってなりそうな気がしてる。そうするとFPで負けそう。
162:デフォルトの名無しさん
10/11/15 08:27:26
将来512bitとか1024bitのレジスタ作ったとき
VEXプリフィックスでどうやって指定するのかね？
Lは1bitしか用意されてないし
全然別系統の命令ということにするのかね？
163:デフォルトの名無しさん
10/11/15 08:57:09
3ビット余ってるって言ってたところ(3バイトVEXの第2バイト)使うんでしょ
長さ指定があっちゃこっちゃ散らばって、汚いなさすがイッテルきたない
164:デフォルトの名無しさん
10/11/15 11:03:35
無料RPG製作ツール「ロープレジェネレーター」
URLﾘﾝｸ(sekisekki.net)
特徴
直感的操作で簡単なゲームが作れます。
簡単に配布可能な状態に出力することができます。
HSP(URLﾘﾝｸ(hsp.tv))製のソースコード付きで、スクリプトの知識があれば
自由度の非常に高いカスタマイズができます
・要望、不満点、バグ報告、応援メッセージなどなど書き込みお願いします。
今もどんどん進化中だ。
165:デフォルトの名無しさん
10/11/20 16:53:10
FPUとSSEを交互に使うと待機時間が減って高速化できるとどこかで見たことがあるんだが
FPUとAVXを混ぜると速くなるとかってあるのか？
Pen4からSSEのユニットでFPUをシミュレートしてるらしいし現状のAVXはSSEを2個並べてシミュレートしてるらしいから無理なのかな？
166:,,・´∀｀・,,） ・・・→ -○○○
10/11/20 18:06:31
>>165
Pentium IIIのときはx87ユニットとSSEユニットが分かれてて論理レジスタも別だから
並列動作させることができてそういうことも起こりえた。
今となってはx87全面禁止にしたほうがいい。
167:デフォルトの名無しさん
10/11/20 18:12:02
128bit浮動小数が普及するのはいつになるのだろう
168:デフォルトの名無しさん
10/11/20 19:03:34
>>166
x87から切り捨てるならもっと古いx86は使わずAMD64やIA64を使えという話になってしまう。
互換性より速度が重要ならそれでいいかもしれんが。
169:,,・´∀｀・,,） ・・・→ -○○○
10/11/20 19:50:13
別にx87が動かないわけじゃない。速くないだけ。
170:デフォルトの名無しさん
10/11/20 20:53:11
>>167
128bit, 256bit, 多倍長, などのライブラリを自作してるオレからしてみると
早く普及してほしい。
ついでに、128bit 整数も欲しい。
が、用途が限られすぎて普及しないと思う。
171:デフォルトの名無しさん
10/11/20 21:10:09
>>170
俺もライブラリ作っているんだけれど、範囲被ってたりしないかなあ。
それはオープンソース？
172:デフォルトの名無しさん
10/11/20 22:22:18
今の所FORTRANのREAL*4ぐらいか？128ビット浮動小数点の利用価値が高いのは
C/C++でもlong doubleが128ビット長になる(規格には入らないだろうが)可能性はあるな
173:デフォルトの名無しさん
10/11/20 22:43:43
REAL*4でなくてREAL*16だろ
どちらにしろ標準FORTRANの文法から逸脱しているのでコンパイラの独自拡張になるが
174:デフォルトの名無しさん
10/11/21 05:05:28
>>171
公開してない自分用。
趣味の数値計算、組み合わせ計算、確率計算で使用。
ライブラリと言ってもlibやdllじゃなくて基本はソースのまま(cppとasm)。
asm部分は最近は64bit用しかメンテしてない。
一通りの関数は作ってあるつもり。
多倍長の乗算はフーリエ変換、
除算、ルートと一部の無理関数はニュートン法、
円周率はガウスルジャンドル、
他の無理関数はテーラー展開。
175:デフォルトの名無しさん
10/12/03 14:05:33
1100|0100 RXBm|mmmm||Wvvv|vLpp
1100|0101 Rvvv|vLpp
VEXと16進数の変換に一瞬頭が混乱する
もう歳だな・・・
176:デフォルトの名無しさん
10/12/03 16:17:13
64bitだとdoubleのシフト・回転も一発で出来て楽だな
177:デフォルトの名無しさん
10/12/03 20:03:41
Intel FMAの231, 213, 132ってのを似非4オペランド形式で記述できるYASM用マクロ書いてみたけど
こういうの需要ある？
178:デフォルトの名無しさん
10/12/03 20:09:32
そーいうのはいちいち他人にお伺い立てるんじゃなくて、
自分が公開したいしたくないで決めるもんだ
179:デフォルトの名無しさん
10/12/16 07:43:12
SSEとあんまり関係ないかもしれないけど、
普通のCPUの浮動小数点演算回路って
倍精度と単精度が別々にあるの？
それとも倍精度の一部を使って単精度にしてるかそれか単精度2つで倍精度作ってるのか、
それとも倍精度はかけるクロック数が違うだけで回路は共通なのか
どうなんでしょうか
180:デフォルトの名無しさん
10/12/16 07:58:41
SSEみたいなものを除けば、単精度演算回路自体を省略している方が多いんじゃないかと。
181:デフォルトの名無しさん
10/12/19 07:45:58
SSE/SSE2で全ビット1にするにはどうしたらいいの？
論理否定命令とか見当たらないんだが・・
182:デフォルトの名無しさん
10/12/19 08:03:08
>>2
IntelはもうMMX使うの止めてくれ、って言ってなかった？
183:181
10/12/19 08:17:33
_mm_cmpeq_pdでいいみたい
184:デフォルトの名無しさん
10/12/19 12:04:51
>>181,183
_mm_cmpeq_ps, _mm_cmpeq_pdだとNaNの時に1にならないから、z=_mm_setzero_pd();m=_mm_cmpeq_pd(z,z)
ってするか、_mm_cmpeq_epi32を使う。
あともっと手っ取り早いのは_mm_set1_epi32(0xFFFFFFFF)とする。
よく使われるならL1に入っているはずだからこれが一番速い。ミスヒットすると一番遅いけどね。
185:デフォルトの名無しさん
10/12/19 14:31:32
>>184 ベンチとってみた
// case 1
f0 = _mm_setzero_ps();
for( uint_t i = 0; i < UINT_MAX; ++i )
{
const __m128 f1 = _mm_cmpeq_ps( _mm_setzero_ps(), _mm_setzero_ps() );
f0 = _mm_add_ps( f0, f1 );
}
// case 2
f0 = _mm_setzero_ps();
const __m128 f1 = _mm_setzero_ps();
for( uint_t i = 0; i < UINT_MAX; ++i )
{
const __m128 f2 = _mm_cmpeq_ps( f1, f1 );
f0 = _mm_add_ps( f0, f2 );
}
// case 3
f0 = _mm_setzero_ps();
for( uint_t i = 0; i < UINT_MAX; ++i )
{
__m128i i1;
const __m128i i2 = _mm_cmpeq_epi32( i1, i1 );
f0 = _mm_add_ps( f0, _mm_castsi128_ps(i2) );
}
186:デフォルトの名無しさん
10/12/19 14:32:48
// case 4
f0 = _mm_setzero_ps();
for( uint_t i = 0; i < UINT_MAX; ++i)
{
const __m128i i1 = _mm_set1_epi32( 0xffffffff );
f0 = _mm_add_ps( f0, _mm_castsi128_ps(i1) );
}
// 結果
case 1: time = 6.090190
case 2: time = 4.637256
case 3: time = 4.636985
case 4: time = 4.620227
case3が良さそう。
つーか、case1よりcase2の方が速いのが解せない。
_mm_setzero_ps()って、何か効率の悪い方法で0生成してるの？
187:,,・´∀｀・,,）＜一番良い -○○○ を頼む
10/12/19 14:43:43
アセンブラ見てみろよ。case1はたぶんこうなってるから。
xorps xmm0, xmm0
xorps xmm1, xmm1
cmpeqps xmm0, xmm1
命令数が増えてデコーダネックってところだろう。
いくら同一レジスタ間のxorが実行ポートを使わないだのレジスタリネーミングのヒントになるだの言っても
デコーダは通るわけだからな
188:デフォルトの名無しさん
10/12/19 15:35:05
Case1は、_mm_setzero_ps()の呼び出しがループの外に出されている以外は
大体そのままの形でした。
Case2は、「const __m128 f2 = _mm_cmpeq_ps( f1, f1);」自体
ループの外に出されちゃってました。
つまりベンチが失敗してました、すんまそん(T_T)
189:デフォルトの名無しさん
10/12/20 05:18:48
そういやこのスレ立てたのは俺だった
細菌CUDAに凝ってSSE使うケース減ったな
190:デフォルトの名無しさん
10/12/20 11:13:45
細菌CUDA……バイオテロみたいだ
191:デフォルトの名無しさん
10/12/20 17:06:14
CUDA速いの？
192:デフォルトの名無しさん
10/12/20 17:15:48
使い方による
間違えれば効果なし
使えるアプリ使えないアプリの見極めが必要
はっきり言って使いこなしはかなり難しい
193:デフォルトの名無しさん
10/12/20 17:25:23
Cellより使いづらそうに見えるんだが気のせいだろうか？
194:デフォルトの名無しさん
10/12/20 17:33:40
Cellよりまし。ソースは私。
195:デフォルトの名無しさん
10/12/20 17:36:46
具体的にはどうマシなわけ？
Cellの難しさなんてSSE＋α程度だったと記憶してるけど？
196:デフォルトの名無しさん
10/12/20 18:12:39
SPUはパイプラインを切った貼ったやらんとパフォーマンスでないのよ。
単に動かすだけならSSEより楽なくらいだけど。
CUDAはFermiになるとキャッシュが利くから結構横着できるからね。
197: ◆0uxK91AxII
10/12/20 19:58:09
SSEとか無関係だし。
VC7.1の場合、大雑把にloopの中身。
case 1
movaps xmm0,xmm1
cmpeqps xmm0,xmm1
addps xmm2,xmm0
case 2
cmpeqps xmm0,xmm0
addps xmm1,xmm0
198:,,・´∀｀・,,）＜一番良い -○○○ を頼む
10/12/20 20:20:25
明らかに変数宣言をループの外に出したほうがいいな
てかstatic constじゃ駄目なのか？
AVXでOpcode空間に余裕ができたからNANDやNORがようやく実装されるんじゃないかと期待
199:デフォルトの名無しさん
10/12/20 22:24:40
>>198
あれ、団子の割にそんな事言っちゃうの？
それとも俺が確認不足かな。
最適化を有効にしたらループの中で変化しない演算はループの外に出るはずだし
static constにしなくても_mm_set1_pxxみたいのは定数のロードになってるはずだけど。
ただし、
float PI=3.14;
__m128 PI4=_mm_set1_ps(PI);
でこのあとPI4しか使わなければPI4は定数として用意されるけれど、PIを別の場所で使っているとオブジェクトにはPIだけ用意されてPI4を作り出す為にシャッフルする事が稀にあるのは知ってる。
あとgccなんかはstatic const __m128とかやろうものならむしろ無駄なコードを吐く。
200:デフォルトの名無しさん
10/12/20 22:57:06
gccを使うべきでない理由がまた一つ増えたな。
201:,,・´∀｀・,,）＜一番良い -○○○ を頼む
10/12/20 23:07:23
ぶっちゃけアセンブラでしか弄ってないもんで。
スカラ演算ベースだったらCでやっちゃうけど（最近のVC++は本当に優秀）
Intrinsicsは機械語とほぼ1:1で対応してる分、最適化が阻害される部分もあるんで
整数のコードに関しては最近はCでスカラ演算ベースで書いてアセンブリコード
吐き出してからそれを並列化するようなやり方でやってる。
ビット演算を組み合わせるところなんか、本当にVC++は賢い。
202:デフォルトの名無しさん
10/12/21 00:10:59
> Intrinsicsは機械語とほぼ1:1で対応してる分、最適化が阻害される部分もあるんで
ここに完全に同意。
ベクタ長を意識しなきゃいけないシーンが多過ぎる事、命令が変態過ぎてコンパイラが自動ベクトル化しづらい事、Intrinsicsと1:1なせいで自動的な最適化があまり望めない事、
そこら辺はGPGPUの方が若干目があるなあと感じている。
203:デフォルトの名無しさん
10/12/22 19:16:09
intrinsics のいいところは、値がメモリに割り付けられててもレジスタ上にしかなくても同じコードで済むところ。
204:デフォルトの名無しさん
10/12/24 06:15:37
新しいのでたよ
IntelR Software Development Emulator Download - IntelR Software Network
URLﾘﾝｸ(software.intel.com)
205:デフォルトの名無しさん
10/12/24 12:52:03
Intel(R) Software Development Emulator Release Notes
URLﾘﾝｸ(software.intel.com)
> 2010-12-21 version 3.88
> * Support for the POST-32NM processor instructions in the 008 revision of the Intel(R) AVX programmers reference document
206:,,・´∀｀・,,）＜一番良い -○○○ を頼む
10/12/24 20:23:40
Visual Studio 2010 SP1でXOP/FMA4/LWPなどのAMD独自新命令に対応の模様
207:デフォルトの名無しさん
10/12/24 20:49:04
What's New in Visual Studio 2010 SP1 Beta
URLﾘﾝｸ(msdn.microsoft.com)
208:デフォルトの名無しさん
10/12/24 21:36:45
AVX 第3版 以前
VFMADDPD __m128d _mm_fmadd_pd (__m128d a, __m128d b, __m128d c, const int ctrl);
VFMSUBPD __m128d _mm_fmsub_pd (__m128d a, __m128d b, __m128d c, const int ctrl);
AVX 第4版 以降
VFMADD???PD __m128d _mm_fmadd_pd (__m128d a, __m128d b, __m128d c);
VFMSUB???PD __m128d _mm_fmsub_pd (__m128d a, __m128d b, __m128d c);
VS2010 SP1 FMA4 intrinsics
VFMADDPD __m128d _mm_macc_pd (__m128d a, __m128d b, __m128d c);
VFMSUBPD __m128d _mm_msub_pd (__m128d a, __m128d b, __m128d c);
209:,,・´∀｀・,,）＜一番良い -○○○ を頼む
10/12/24 22:21:43
> VFMADDPD __m128d _mm_fmadd_pd (__m128d a, __m128d b, __m128d c, const int ctrl);
Intel FMAに第4引数なんて元々ないよ。imm8の3つ目のソースオペランドとして使って残り4ビットは予約。
AMD版FMAの_mm_macc*って命名則はSSE5由来だが対応する命令はAVX第3版までのFMA仕様にすげ変わってる。
210:デフォルトの名無しさん
11/01/10 01:34:19
Sandy発売したのに
211:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/01/10 02:32:27
ベータ版のサービスパック入れられない人もいるのよ
212:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/01/10 02:43:53
俺はAVXの先に興味を持ちました。
Bulldozerまだかよ
シミュレータでさっさと出して欲しいですな。
213:デフォルトの名無しさん
11/01/13 02:02:37
Intelのマニュアルのハードコピーって無くなってたんだ。
AVX版が出るまで待とうと思ってずっと我慢してたのに。
214:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/01/13 03:21:36
GARAPAGOSにPDFリーダーついてたら10インチ買うわ。
215:デフォルトの名無しさん
11/01/14 09:21:53
配布してる同期ソフト経由で転送してPDF見られるらしいけど、見開きで表示できなかったり
画像としてしか表示できなかったりして、色々と残念な出来らしい。
画面解像度だけみて大きくて見やすいだろうからとPDF目的で買うとガッカリするレベルだそうな。
216:デフォルトの名無しさん
11/01/14 18:11:12
ここで薀蓄垂れてる奴なら、ハックして自家製ビューア走らせるくらい朝飯前だろ？
217:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/01/14 20:04:42
やっぱりAdobe Readerそのものが必要だな。
Atomタブレット待ちか。
218:デフォルトの名無しさん
11/01/14 20:08:17
AVX試した奴いないの？
linuxならKernel最新にすりゃできるよな？
報告よろ
219:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/01/14 20:09:56
別に開発だけなら今回はシミュで十分だしな。
prefetch距離とかの調整くらいはやりたいけど。
220:デフォルトの名無しさん
11/01/15 01:09:44
団子は自作板の方でSandybridge出たら買って遊ぶとか言ってなかった？
Win7SP1待ち？
221:デフォルトの名無しさん
11/01/15 01:28:01
口先だけで、金も腕もないってとこなんじゃないの
222:デフォルトの名無しさん
11/01/15 01:41:36
>>216
GALAPAGOSにそこまでするだけの価値を見いだせない。
機能限定されすぎたタブレットPCのできそこないにすぎず、ちょっと機能が増えただけの電子書籍専用端末でしかない。
Androidマーケットでアプリ追加することすらできないんだぜ？
223:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/01/15 01:55:27
サイズ的には良い感じなんだけどね。Mebius辞めて何を作るかと思ったらこれだからな。
アップデートに期待したいところだが。
実機環境は枯れるまで待ち、というかノートの春モデル待ち。
何か問題出た場合にソフトの不具合なのかハードの不具合なのかわからないってのが一番厄介だから
自作をすべきではない、という経験論。
224:デフォルトの名無しさん
11/01/15 18:35:14
なんで AVX には bsr/bsf が無いんだよ。
225:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/01/15 22:55:26
なんで必要だと思ったの？
ただ4並列/8並列でbsr代替はできるよ。
(v)cvtpi2psで指数部抽出できるだろ。あとはわかるな。
226:|ω・`)
11/01/15 23:25:09
ローテートください
227:デフォルトの名無しさん
11/01/16 11:21:36
>>225
将棋のbitboardで必要だろう。jk
228:デフォルトの名無しさん
11/01/17 05:51:42
そんなどうでもいい用途向けに専用命令つくれとか
もっと意義のある事をあげろよ
229:デフォルトの名無しさん
11/01/17 07:34:48
圧縮やら浮動小数やらいくらでもある。
x86始め、よく実装されているのは必要とされているからだ。
230:デフォルトの名無しさん
11/01/17 19:43:53
CPUに実装されないのは「必要とされていないから」だろ。
231:デフォルトの名無しさん
11/01/17 19:58:26
>>230
何らかの事情で出来なかったも考慮したほうがよいのではないでしょうか。
232:デフォルトの名無しさん
11/01/17 20:08:36
そういう場合は代替がある。
233:デフォルトの名無しさん
11/01/17 20:27:55
このスレで一番賢くてSSEに詳しい人に質問。
__m128i ptn = { 0,4,8,12, 16,20,24,28, 1,5,9,13, 17,21,25,29};
__m128i ptn2={ 0,4,8,12, 1,5,9,13, 2,6,10,14, 3,7,11,15};
__m128i v0 = _mm_load_si128((__m128i*) p1);
__m128i v1 = _mm_load_si128((__m128i*) p2);
__m128i v2 = _mm_shuffle_byte(v0, v1, ptn); ←v0とv1を連結して8bit x 32個の要素の中からptnで指定したものだけを並べる
__m128i v3 = _mm_load_shuffle_byte((__m128i*) p3, ptn2); ←8bit x 16個の要素をメモリから読み出し、ptn通りに並べ変える
SSEにこんな感じの命令はありませんか？
無い場合、SSE3までの範囲で代替しようとすると、どのくらい複雑になって遅くなりますか？
234:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/01/17 20:30:05
日本ローカルのボードゲームの解法ごときに貴重なOpcode空間を割くのは無駄だからにきまってるだろ
とはいっても、cvtdq2psのような命令がある以上、4並列のビットスキャン回路は実装されてるわけだが。
235:デフォルトの名無しさん
11/01/17 20:41:34
>>233
本当に任意のパターンであればSSSE3が使えるかどうかによってだいぶ変わる。
SSSE3が使えない場合はパターンの規則性によってだいぶ変わる。
233に特化したやり方でこのスピード、ちょっとでも並びが変わると格段に遅くなる
とかあり得るので、「233の場合」という質問はアリでも「233みたいな場合」とか曖昧な質問は無しな。
236:デフォルトの名無しさん
11/01/17 21:08:37
できれば>>233のパターンに限定しない方向でお願いします。
237:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/01/17 21:24:02
>>233
1行目が釣りくせえええええ
packssdwの32ビット値の下位16ビットの最上位が1の場合って飽和処理されるんだっけ？ｗ
pshuflw/pshufhwで並べ替えてからpshufdで詰めるか
あとは8ビットおきにマスクしてpackuswbで詰めればOK
238:デフォルトの名無しさん
11/01/17 21:26:23
>>236
限定しないなら答えようが無い。
基本SSSE3の_mm_shuffle_epi8とSSE2の_mm_shuffle_epi16, _mm_shuffle_epi32を使ってどうにか出来なそうなら諦めるしか無い。
ちなみに複雑さに興味があるようだから例を挙げておくと
ptn2はshuffle x 2+unpack x 3回で作れる。
ptnの計算量は一度ptn2 x 2+unpack x 1回になるので、素直にバイト配列でも良いと思う。
239:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/01/17 21:28:13
>>236
方法など無い。テーブル参照して16回ロードすべし。以上。
ただ、32ビットずつ纏めてからmovdでxmmレジスタに転送したほうが速いかも知れないね。
240:デフォルトの名無しさん
11/01/17 21:30:30
>>237
ん？そんな簡単に出来るの？
packsは飽和処理がうざいよな。飽和無しバージョンを作って欲しい。
241:デフォルトの名無しさん
11/01/17 21:32:47
わかりました。SSEって不便なんですね。
242:デフォルトの名無しさん
11/01/17 21:36:40
>>241
Core1世代は諦めろ。
任意のパターンはshuffle_epi8が使えないとどうにもならんし、逆に使えればptn2は1発だ。
243:デフォルトの名無しさん
11/01/17 21:57:57
Intel製のCPUとかちょっと使いたくないんです。
AMD製に同様の命令が追加されたりしませんかね？
244:デフォルトの名無しさん
11/01/17 22:01:18
VS2010のデバッガ上でYMMレジスタが表示できないんだけどなぜ？
[AVX] と [AVX 浮動小数点] がグレー表示になってる。
CPUはSandyBridgeでWindows 7 のSPもあてたんだけど。
245:デフォルトの名無しさん
11/01/17 22:56:49
>AMD製に同様の命令が追加されたりしませんかね？
釣り確定
246:デフォルトの名無しさん
11/01/18 02:44:51
＞Intel製のCPUとかちょっと使いたくないんです。
煽り確定
247:デフォルトの名無しさん
11/01/18 09:04:41
使いたくないならコンパイラの最適化に丸投げでいいんでねーの
248:デフォルトの名無しさん
11/01/18 23:51:39
プリフェッチ命令は1回の発行で何バイト読み込むんですか？
32バイトから128バイトという曖昧な情報もあれば、
1ライン読み込みなので64バイトと言う情報もあります。
命令なので後者のほうが正確のような気がするのですが、認識は合っているのでしょうか？
249:デフォルトの名無しさん
11/01/18 23:54:34
CPUの型番で違う、ってのが答えだったような。
250:デフォルトの名無しさん
11/01/19 00:21:12
Pentium IIIは32バイト
Athlon XPは64バイト
Pentium 4は128バイト
Pentium Mは64バイト
だったような
251:デフォルトの名無しさん
11/01/19 00:23:55
>>249
となると、
Pen4はラインサイズが64バイトなので64バイト、
C2Qも同様に64バイト、ということでよろしいのでしょうか？
252:デフォルトの名無しさん
11/01/19 00:33:49
>>250
ありがとうございます。
微妙に情報が食い違っていたりするので、
もう少し調べてみます。
253:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/01/19 01:27:30
CPUIDでキャッシュラインのサイズ調べるのが確実だよ
t1 = L1D
t2 = L2
nta = LLC
ただしPentium 4はt1でもt2でもL2までしかフェッチされない
254:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/01/19 01:28:57
↑訂正
t0とt1読み替えてね
255:デフォルトの名無しさん
11/01/19 01:58:10
>>253
C2Dは64バイトでした。
他のマシンでも調べてみます。
ありがとうございました。
256: ◆0uxK91AxII
11/01/19 10:40:00
>>253
＞nta = LLC
えっ。
257:デフォルトの名無しさん
11/01/19 11:52:14
FMAってIvy Bridgeになったら搭載されるの?
それとももっと後?
258:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/01/19 16:35:09
>>256
ボケたな・・・
t0 = L1D (Pentium 4は例外)
t1 = L2
t2 = L3(LLC)
nta = L1D(Non Temporal)
259:デフォルトの名無しさん
11/01/19 18:28:14
>>257
Haswellのよてい
260:デフォルトの名無しさん
11/01/26 20:48:00
MASMでAVXプログラミングしてる人いませんか？
MASMで32バイトアラインメントで静的変数を確保したいんだけど、
方法がわかる人いませんか？
VS2010付属の ml64.exe です。
align 16 ならできるんだけど、
align 32 はダメみたい。
今はビルドしてずれてたら詰め物を手動で入れてます。
261:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/01/26 21:24:08
IntelはYASMがお墨付きだしMASMなんて使わないに越したことはないけど。
ちなみにNASMは色々腐ってるので使用禁止レベル。
たとえば、コード上でalignマクロを使うと、VEXが常に3バイトだと仮定して詰め物をするんだよね
align 16
vxorps ymm0, ymm0, ymm0
vxorps ymm1, ymm1, ymm1
vxorps ymm2, ymm2, ymm2
vxorps ymm3, ymm3, ymm3
align 16 ;; ←ここが問題
262:|ω・`)
11/01/26 22:01:10
何も問題ないけど
use64
vxorps ymm0, ymm0, ymm0
align 16
vxorps ymm8, ymm8, ymm8
align 16
db 0ffh
00000000 C5FC57C0
00000004 90<rept>
00000010 C4413C57C0
00000015 90<rept>
00000020 FF
263:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/01/26 22:13:52
ん？直ったのか？
264:デフォルトの名無しさん
11/01/26 22:20:42
>>181
今更だが...
浮動小数点例外を有効にして無いならこれでもいい。
_mm_cmpnlt_pd
_mm_cmpnlt_ps
AVXでYMMをすべて1にする場合は、
VCMPTRUEPD
VCMPTRUEPS
というぴったりな命令がある。
（VCMPNLT_UQPDとか他にもいろいろあるけど）
265:デフォルトの名無しさん
11/01/26 22:26:50
>>261
YASMだと align 32 が使えるの？
266:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/01/26 22:30:19
FP比較は遅いからvpcmpeqb *してvpinsertf128でいいよ。
128ビットまでならロードしたほうが速いかも。ブロードキャストすればデータセクションの容量も食わないし
267:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/01/26 22:31:05
>>265
64でも128でもいけるよ。
268:|ω?
11/01/26 22:32:49
4096
269:デフォルトの名無しさん
11/01/26 23:03:23
>>266
ロードは128bitも256bitも同じ速さだと思う
270:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/01/26 23:53:39
いいや。
Loadユニットは128ビットが2本。
256ビットロードは1ポートを2サイクル分消費する。
あと、32/64ビット→128ビットのブロードキャストはロードユニットだけでできるので
わざわざ大きいテーブル用意する必要も無くなる。
271:デフォルトの名無しさん
11/01/27 05:22:59
団子さんも勘違いしてる事が稀によくあるから、自分で実際に検証してみた方がいいぞ。
272:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/01/27 06:08:10
あのな・・・
シミュレータでの動作検証からはじまって足掛け1年半はAVX触ってるんだぞこっちは
せめてこれくらい読んでから言ってくれ
URLﾘﾝｸ(www.intel.com)
273:デフォルトの名無しさん
11/01/27 08:32:05
>>270
ヒント
32/64ビット→256ビットのブロードキャスト
274:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/01/27 09:13:03
vmovdqa (128b load) Load×1
vmovdqa (256b load) Load×2
vbroadcast{ss,sd} (128b) Load×1
vbroadcast{ss,sd,f128} (256b) Load×1+ FP_Permute
275:デフォルトの名無しさん
11/01/27 19:13:18
団子さんってトリップ検索以外もやるの？
276:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/01/27 19:39:54
実質6年前に辞めてるけど？
277:デフォルトの名無しさん
11/01/27 20:25:29
団子さんの目って ´ ｀ ですか？
それとも ・ ・ ですか？
278:デフォルトの名無しさん
11/01/27 22:06:39
>>266
レイテンシはあるけどPort1を1クロックだけ使うだけだから
使える場面は多いかと。
最良は3つを使い分けることか。
| Num of | Ports pressure in cycles | |
| Uops | 0 - DV | 1 | 2 - D | 3 - D | 4 | 5 | |
------------------------------------------------------------
| 2^ | | | | 1 | 1 | X | X | | 1 | CP | vbroadcastss ymm0, dword ptr [0x0]
| 1 | | | 1 | | | | | | | CP | vcmpps ymm0, ymm0, ymm0, 0xf
| 1 | 1 | | | | | | | | X | | vpcmpeqb xmm0, xmm0, xmm0
| 1 | | | | | | | | | 1 | | vperm2f128 ymm0, ymm0, ymm0, 0x0
279:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/01/28 01:11:57
FP演算の場合はport1とport2は利用頻度高くてport5はレジスタ間mov（AVXの場合は基本的に使わない）や
シャッフル、ブレンド程度しか使わないから、port5積極利用で良いと思うけどな。
これも場合によるか。
280:デフォルトの名無しさん
11/01/28 03:59:26
>>277
・の方。一行目のは公家が描いてる眉と同じ。
AAでは上が見切れてるけど烏帽子被ってる。
281:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/01/28 05:52:06
麿は団子が食いたいのじゃ
282:デフォルトの名無しさん
11/01/28 21:01:25
>>279
負けず嫌いなだんご。
だんごより大福の方がうまいし。
283:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/01/28 21:37:46
うるせえおれはだんごがくいたいんじゃ
というか、256ビット（SIMD-FP）でALL-Fなビットパターンが必要な処理って何があるんだ？
絶対値をとるために0x7FFFFFFFとかならまだわかるんだが。
284:デフォルトの名無しさん
11/01/28 23:49:54
多くのCPU向けにSSE2までに制限してプログラムを書いてるんだけど
Core2以降がそれより前のものと比べてSSE1～4.1が急に倍速化してるけど何か革新があったの？
285:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/01/29 01:26:54
タイムスリップして来た人乙
64ビットSIMDユニットで128ビット命令を2サイクルかけてたのが128ビットで1サイクルになった。
286:デフォルトの名無しさん
11/01/31 21:13:23
>>283
NaN作成の為に決まっとろうが。
287:デフォルトの名無しさん
11/01/31 21:25:48
上位下位128bitをまたいだPermute命令がほしかった。
VPERMPD ymm1, ymm2/m256, imm8
288:デフォルトの名無しさん
11/01/31 21:29:18
単純にSSEx2ってわけじゃないのが使いづらい。
パック、アンパック、cvtが面倒。
289:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/02/01 07:58:05
AoS推奨
290:デフォルトの名無しさん
11/02/01 08:04:39
今回Phenomとはまた違ったきな臭さを感じていたが、
プロセッサではなくチップセットに問題があったか。
URLﾘﾝｸ(plusd.itmedia.co.jp)
291:デフォルトの名無しさん
11/02/02 14:37:46
仮想環境でAVXは使えないのか
ホストOSは仕事の都合上古めのLinuxじゃないと駄目なので
ゲストで使いたいのだがcpuidのフラグが立たん
292:デフォルトの名無しさん
11/02/02 21:10:01
xgetbvのOSサポートのフラグじゃなくて？
cpuidによるCPU対応のフラグも立たない？
293:デフォルトの名無しさん
11/02/02 23:24:40
そうなんですよ
ホスト(RHEL5)だとOSXSAVE以外の必要なフラグは立ってるのだが
ゲスト(SL6beta on VMWare Player)だとAVXのフラグすら立たない
294:デフォルトの名無しさん
11/02/10 16:33:51
Win7のSP1がもうすぐのようだな
これでAVXガンガン効かせられる訳だ ったんだがな
295:デフォルトの名無しさん
11/02/16 13:57:54
SIMD命令ってなんで高級言語でかけないんだ
GPUでは当たり前にできるのに
296:デフォルトの名無しさん
11/02/16 14:04:15
OpenCLでかけるようなるとかならないとか。。。
297:デフォルトの名無しさん
11/02/16 14:09:01
どっちだよ
298:デフォルトの名無しさん
11/02/16 15:59:11
intrinsics で充分だろ。
299:デフォルトの名無しさん
11/02/16 22:08:03
x86デコーダが適当な命令をSIMDに読み替えてくれれば解決
名付けてウルトラスーパースカラー
300:デフォルトの名無しさん
11/02/17 10:21:06
>intrinsics で充分だろ。
高級言語だからARMでもPowerPCでもコンパイル通（ｒｙ
301:デフォルトの名無しさん
11/02/22 16:11:00.98
石に依存する部分をコンパイラに丸投げするなんて信用できねえ。
というか、データ構造の設計がしにくくなるから、絶対に嫌。
302:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/03/03 21:00:33.78
NASM/YASMのマクロの構造体機能なにげに活用してるわ
303:デフォルトの名無しさん
11/03/06 20:52:16.61
__m128を動的に確保するには_aligned_malloc()を使う。
__m128をメンバに持つクラスAも_aligned_malloc()を使う必要があるのは
まあ許すとして、
クラスAをメンバに持つクラスBも_aligned_malloc()を使う必要があるの？
もしそうなら、とてもライブラリ作りにくいんだけど、そういうものなのかな？
304:デフォルトの名無しさん
11/03/06 22:31:11.32
_mm_movelh_ps()と_mm_movehl_ps()って
なんでストアされる組み合わせが逆なの？
嫌がらせ？
305:デフォルトの名無しさん
11/03/06 23:47:06.94
>>303
そういうもんです。
__m128を少量メンバにするならdoubleやfloatで良いし、
大きな配列ならクラスの中で動的確保しる。
306:デフォルトの名無しさん
11/03/07 04:15:11.25
>>303
まず、根本的な問題として、C++なんか使うべきじゃあない。
クラスなんて非効率なものを使うのに、効率重視のintrinsics使うのはおかしい。
307: ◆0uxK91AxII
11/03/07 09:52:08.08
>>303
使えるなら、__declspec (align () )
308:デフォルトの名無しさん
11/03/07 22:07:52.97
>>306
クラスだから非効率は間違い
作り方によって効率的にも非効率的にもなる
309:デフォルトの名無しさん
11/03/07 23:00:24.87
>>306
今時はHLSLだって、クラス使うのよ
時代は変わっていくんだよ
>>307
それヒープには効かないのよ
310:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/03/08 14:20:20.44
xmmintrin.hに_mm_alloc()って有るはずだけど、使えない環境ではこんな感じでやってるぜ
void * aligned_alloc(int count, int align_bytes) {
void* addr = malloc(count + align_bytes);
int offset = (int)addr & align_bytes;
addr = (addr + align_bytes) & ~(align_bytes - 1);
((unsigned char*)addr)[-1] = offset;
return addr;
}
void aligned_free(addr) {
free(addr - ((unsigned char*)addr)[-1]);
}
C++を使いたい理由は明解だ。
_mm_add_ps(a, b)って書くよりa + bって書きたいじゃん。
つか、virtual継承さえ使わなきゃクラスってそんなに重たくならんよ。
311:デフォルトの名無しさん
11/03/08 17:14:45.18
AVXを試してみた 不良チップセットでだけど
win7、VC2010expressイントリでコンパイルし、除算がSSE2の倍かかるんだが…
312:デフォルトの名無しさん
11/03/08 19:55:13.27
>>311
除算はご丁寧に128bitずつやってる糞仕様だから
ニュートン法を使った方が最後の1ビットまで計算しても速いと思うよ。
Intelはマジこういうのやめてほしいけどね。正常進化を阻害すると凝った事する訳じゃないのにプロセッサ特有の最適化が必要になっちゃって、Pen4の二の舞。
313:デフォルトの名無しさん
11/03/08 22:08:25.45
c++ならtryが出来るよので、俺はnewを使うよ。
＞C++を使いたい理由は明解だ。
＞_mm_add_ps(a, b)って書くよりa + bって書きたいじゃん。
＞
＞つか、virtual継承さえ使わなきゃクラスってそんなに重たくならんよ。
gccなら、オーバーロードしなくてもそのままで使える。
314:デフォルトの名無しさん
11/03/09 21:56:18.07
>>312
除算はスーパーコンピューターだって遅いんだよ。
AVX除算速度と、回路規模、コスト、消費電力、クロック、開発期間、....
を天秤にかけて今の仕様になってんだよ。
ただ１個の要素だけ見て糞仕様とか、ド素人丸出し。
315:311
11/03/09 22:00:37.52
SSE2の除算より遅いと書いたと思うが
素人丸出しか？
AVXのが2倍速いとふつう思わんか？
素人で悪かったな
316:デフォルトの名無しさん
11/03/09 22:14:44.79
>>315
そりゃ256bitを128bitずつ2回に分けてるんだから当たり前だ。
317:311
11/03/09 22:16:46.51
>>316
SSE2でやっても128×2でやるんだから同速だろ
そういう素人意見が聞きたいんじゃないんだが
318:デフォルトの名無しさん
11/03/09 22:33:15.42
>>317
128bit 単精度 スループット14 レイテンシ14
256bit 単精度 スループット28 レイテンシ29
319:デフォルトの名無しさん
11/03/09 22:56:55.11
実行時間を計ってみた
divps xmm0, xmm1
183クロック
vdivps xmm0, xmm0, xmm1
183クロック
vdivps ymm0, ymm0, ymm1
203クロック
確かに異常に遅いな。
エラッタがあってマイクロコードで実行してるとか？
320:デフォルトの名無しさん
11/03/10 08:58:00.63
まあ、普通は除算は使わないようにするわな。
321:デフォルトの名無しさん
11/03/10 20:03:56.23
>>319
普通の数じゃないと極端に遅いみたいだ。
普通の数だと
divps xmm0, xmm1
12.7クロック
vdivps xmm0, xmm0, xmm1
12.7クロック
vdivps ymm0, ymm0, ymm1
25.3クロック
くらいだった。
値によって変わる模様。
インテルのドキュメントには範囲じゃない記述だったので
値によらずに同じクロックかと思ったのだが。
>>311 や >>312 が何を騒いでるのか意味不明。
322:デフォルトの名無しさん
11/03/10 20:17:04.16
128bitの場合、
割る数、割られる数のどちらかが 0.0, NaN, ∞ の時は9クロックくらい。
割る数が2^nの時も9クロックくらい。
結果がアンダーフローや非正規数の場合と、割る数、割られる数のいずれかが非正規数の場合は183クロックくらい。
結果がオーバーフロー、割る数と割られる数が同じ、等は普通どおりの時間。
323:デフォルトの名無しさん
11/03/10 21:07:01.21
せめてSIMDだけでもいい加減デノーマルやめてほしいわｗｗ
324:デフォルトの名無しさん
11/03/10 21:59:45.78
>>323
デノーマルも不要だが、
個人的には無限をなくしてほしい。
異常値検出のNaNのはずが、
無限があると、大小比較が出来てしまっておかしいことに。
0.0がプラスかマイナスかなんて意味が無いのに、
1.0/0.0 が＋無限、
1.0/-0.0 が－無限、
で、1.0/0.0 > 1.0/-0.0 が成り立ってしまう。
これを決めた人は頭が悪すぎる。
325:デフォルトの名無しさん
11/03/10 22:02:04.87
あの子の性癖はアブノーマル
326:311
11/03/10 22:03:22.76
>>324
1.0/0.0 > 1.0/-0.0
これ成り立つんだけど
327:デフォルトの名無しさん
11/03/10 22:34:57.73
>>326
成り立つから良くないと書いてるんだけど。
328:311
11/03/10 22:50:16.74
y=1/xの話だよ
ｘ＝0近傍での話
実際に発生しうるってことね
329:デフォルトの名無しさん
11/03/10 22:55:53.76
>>324
基本的に入力が悪い場合は入力の責任にできる環境にあるので今まで出くわした事が無いが、
確かに使いたい場面が滅多に無いのに凝ってるのはひどい仕様だな。
ただ-0.0はSIMDで符号ビットをマスクするために使わせてもらっているので無くさないで欲しいw
SSE2からは_mm_castsi128_ps(_mm_set1_epi32(0x80000000))ってできるので、
SSEの時に適切にintからキャストする方法を用意しなかったIntelが悪いんだけどな。
330:デフォルトの名無しさん
11/03/10 23:01:03.88
>>328
+0.0 と -0.0 がある理由は、
単に符号反転がしやすい為。
実際、+0.0 = -0.0 が成り立つので、
+0.0 と -0.0 は同じ値の別表現だという意味である。
ところが、除算をするといきなり大小が大きく違う数になってしまう。
一貫性がまったくない。
Unordered にしておけば良かったのに、
何を血迷ったか Ordered にしてしまった。
Unordered だったらここまで不満は無かった。
331:311
11/03/10 23:06:20.74
>>330
>>除算をするといきなり大小が大きく違う数になってしまう
数学的にそれが答えだから仕方ないでしょ
332:デフォルトの名無しさん
11/03/10 23:12:11.81
>>331
数学をしらない人間が数学を語るとは.....
数学的には、
+0と-0があって、同じもの同士を引いて+0にはなるが-0にはならない
なんて非対称な代数系は普通は使わない。
実数から0を除いたものに、±0と±∞を足したものは、
まともな代数系にならないことくらい周知の事実だ。
コンピューターも数学ももうちょっと勉強しなさい。
ド素人クン。
333:311
11/03/10 23:14:21.02
>>332
>>328が理解できないかな？ド玄人君
334:デフォルトの名無しさん
11/03/10 23:23:35.88
>>332
おまえ、数学素人だろw
335:デフォルトの名無しさん
11/03/10 23:28:03.89
考えられる実装は以下
A. +0と-0を同一視、+∞と-∞を同一視でUnordered、0による除算は∞
B. +0と-0を同一視、+∞と-∞は別でOrdered、0による除算はNaN
>>333
lim_[x→1.0] {1/(x-1.0)}
これは、xがプラス側、マイナス側のいずれから近づくかで+∞、-∞のどちらに発散するかが決まる。
ところが、コンピューター界では 1.0/(1.0-1.0) は-∞ではなく+∞だと定めている。
これには数学的根拠は全くない。
336:デフォルトの名無しさん
11/03/10 23:32:04.81
>>334
フィールズ賞をとったことが無いって意味では素人かもね。
337:デフォルトの名無しさん
11/03/10 23:36:29.93
つーか-0.0なんてどうやったら演算結果に出るんだよｗ
意図的に使わなければありえないだろ
個人的には
1.0/0.0=+Inf -1.0/0.0=-Inf
1.0/-0.0=NaN -1.0/-0.0=NaN
にしてほしい
338:311
11/03/10 23:37:38.58
>>335
お前さ～昨日の>>316だろ？
お前はレベル低いからもういいよ、素人回答すんなよ
339:デフォルトの名無しさん
11/03/10 23:39:44.00
0.0は限りなく0に近い切り捨てられた値として、-0.0は完全な0としてみなす仕様が欲しいってこと
340:デフォルトの名無しさん
11/03/10 23:41:11.49
>>337
ゼロ以外の普通の値に対して、
a*(b+c) とするだけでも出てくる可能性がある。
341:デフォルトの名無しさん
11/03/10 23:50:11.84
どうせ無限なんてでてくるのは異常値なんだからNaNで良いよ。
NaNはたくさんの種類が作れて、
勝手に自分で意味をつけられ、
その意味を伝搬していける。
中途半端な仕様の無限なんて不要。
342:デフォルトの名無しさん
11/03/10 23:50:38.26
>>340
bとcが正規数ならεはDBL_MINと同じか大きいから
abs(b+c)>=DBL_MINかabs(b+c)=0.0
だろ？
abs(a)<1.0だとしても計算時にデノーマルするだけで格納される値は
abs(a*(b+c))>=DBL_MINかabs(a*(b+c))=0.0
じゃないの？
具体的にはどんな値を入れれば出るんだ？
343:デフォルトの名無しさん
11/03/11 00:01:40.86
>>342
a=-1.0
b=1.0
c=-1.0
344:デフォルトの名無しさん
11/03/11 00:05:00.73
>>343
b+c= 1.00000000000000 + -1.00000000000000 = 0.00000000000000
a*(b+c)= -1.00000000000000 * 0.00000000000000 = 0.00000000000000
な気がするけどちょっと試してみる
345:デフォルトの名無しさん
11/03/11 00:13:16.51
お、できた
俺の認識が間違ってたみたいですまん
double a, b, c, d;
a = -1.0;
b = 1.0;
c = -1.0;
d = a * (b + c);
if(d < 0.0){d = 2.0;}
だとdは2.0じゃなくて-0.0のままなのが納得いかないけどｗ
346:デフォルトの名無しさん
11/03/11 00:29:15.92
>>345
-0.0 と +0.0 は同一視の為、-0.0 < +0.0 は偽で、
-0.0 = +0.0 が真になる。
>>323
デノーマル数を0にしちゃって計算を遅くしないモードがある
MXCSRレジスタのDAZビット
347:デフォルトの名無しさん
11/03/14 21:26:52.77
Ax + b = 0, A=3x3行列 の連立方程式を解く関数を
float(C++)からsse(C++ + 組み込み関数)へ移植したんだが
2倍程度遅い結果。これでも修正が効いた方で
ベタ移植だと30倍ぐらい遅かった。
等速ならまだしも、何倍も遅くなる理由がわからん。
floatだって内部的にsse使ってるのに。
思うんだが、組み込み関数使うと
コンパイラの最適化が相当オミットされてたりしないか？
348:デフォルトの名無しさん
11/03/14 21:32:28.16
そうだよ
SSEを下手に使っても効果ないよ
349:デフォルトの名無しさん
11/03/14 21:37:00.89
そうなの？
だったら、SSEとかAVXとか積まずに
FPUをその分載せてくれた方が
よっぽどマシだなぁ
350:デフォルトの名無しさん
11/03/14 21:43:59.96
上手に使えばいい話
なんでそういう思考になるの？アフォ？
351:デフォルトの名無しさん
11/03/14 21:53:42.11
>>350
だから上手に使った結果2倍遅いんだって。
SISDより遅いSIMDなんていらないじゃん普通。
352:デフォルトの名無しさん
11/03/14 21:56:21.55
>>351
単にSSEに置き換えても早くならないって書いたよね
基本だけどパイプラインとかアウトオブオーダーとか理解してる？
353:デフォルトの名無しさん
11/03/14 22:00:25.16
ていうかSSEの知識ないんだったら>>347の内容くらいBLASで解けばいいじゃん
354:デフォルトの名無しさん
11/03/14 22:02:35.51
>>352
何？組み込み関数を使うと
パイプラインがストールしたり、
インオーダー実行されちゃったりするの？
組み込み関数が遅いのはそんな理由じゃないよね。
つーか速くならないだけならいいんだってば。
現実は遅くなるの。それもとんでもなく。
floatだって、実際のコードはsseを使ってて
量的な差は無いはずなのにさ。
355:デフォルトの名無しさん
11/03/14 22:05:17.14
>>352
当然blasも使ってる。
ちなみにublasとubals相当の関数の比較だと
約5倍は遅い。
356:デフォルトの名無しさん
11/03/14 22:06:12.07
>>354
多少は知識あるじゃん
それでできないんだったらあきらめな
センスなさすぎw
357:デフォルトの名無しさん
11/03/14 22:06:28.66
検証比較ソース出せばすぐ検証して貰えるよ。
358:デフォルトの名無しさん
11/03/14 22:08:47.07
>>354
>コンパイラの最適化が相当オミットされてたりしないか？
これが正解
というか3x3だと最後の使わないデータがコンパイラには理解できないから
FPUはO(3x3)=O(9)
SSEはO(4x4)=O(16)
でコード次第では不利
359:デフォルトの名無しさん
11/03/14 22:09:44.25
つーか、こいつもしかしてintrinsicだと遅いっていってる？
つまりアセンブラなら速いと
こいつ性格悪そうだからそういう意味かもな
360:デフォルトの名無しさん
11/03/14 22:17:31.53
>>358
Ax + b = 0 は、3x4行列として扱う。
__m128 x 4本で無駄は出ない。
>>359
そうだよ。だってアセンブラは対象外だもん。
アセンブラで書くとコンパイラの最適化を阻害して
逆に遅くなるよ派だし。
intrinsicだと許せる理由の他に
許せない理由で遅くなってそうだと思って聞いてみたんだよ。
361:デフォルトの名無しさん
11/03/14 22:18:16.42
＞__m128 x 4本で無駄は出ない。
__m128 x 3本の間違い
362:デフォルトの名無しさん
11/03/14 22:18:56.98
データの順番を変えられるなら、
1個ずつ連立方程式を解かず、
8個ずつず解けば速い。
363:デフォルトの名無しさん
11/03/14 22:21:09.33
あ、AVXじゃなくSSEか。
じゃあ4個ずつ。
364:デフォルトの名無しさん
11/03/14 22:41:28.98
>>360
＞＞アセンブラで書くとコンパイラの最適化を阻害して
＞＞逆に遅くなるよ派だし。
それはおまえの能力が低いからって言われるよ
ま、最適化より早いコード書くのは大変だけどね
時間かければ可能
365:デフォルトの名無しさん
11/03/14 22:47:25.52
構造体の並び順とか変数の参照回数とかは大抵コンパイラに任せた方が速い
テーブル参照や三角行列化などのアルゴリズムに起因するものは人間が最適化しないといかん
366:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/03/15 18:16:06.10
割とテキトーに命令並べてもアウトオブオーダ実行でパイプライン埋めてくれるのでアセンブラで書くよ派
どのポートで実行されるかは意識して書くけどね
367:デフォルトの名無しさん
11/03/15 18:51:54.74
あれ、団子はintrinsic派じゃなかったっけ？
おいらはアセンブラ派。
もちろんどのポートで実行されるかとかレイテンシーとかは考慮する。
>>365
最近は構造体の並び順とかもコンパイラが勝手に並び変えるのか？
でも単純に並び変えてもほとんど恩恵が無いような。
SOAとAOSを最適化で切り替えてくれるならすごい恩恵はあるが、
まさかそんなところまで最適化は出来まい。
368:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/03/15 22:27:26.43
それは時と場合によって使い分ける
intrinsicsは緩くかけるからいいんだよC++のinlineとかtemplateと相性いいしね
関数丸ごと最適化の場合はアセンブラ使うよ。
とりあえずMSはYMMレジスタ全てcaller-saveのABI規約作ってくれ
369:デフォルトの名無しさん
11/03/16 00:29:18.14
> それは時と場合によって使い分ける
ふーん。
intrinsicマンセーぶりからしてアセンブラ使えないのかと思ってたよ。
> とりあえずMSはYMMレジスタ全てcaller-saveのABI規約作ってくれ
これはその通り。
> intrinsicsは緩くかけるからいいんだよ
そうだね。
AVXを使って緩くかけるような機会もそんなにないけど。
370:デフォルトの名無しさん
11/03/16 16:39:01.09
団子はこないだ intrinsics ディスってなかったか。
86 の事情は分からんが、ps3 で PPC VMX 向けなら、ひとまず intrinsics で書く。
ターゲットより規模の問題かもしれんけどね。
371:デフォルトの名無しさん
11/03/16 17:26:17.44
VCCだと64bitではintrinsicsしか使えないよね？
372:デフォルトの名無しさん
11/03/16 19:53:23.89
>>371
っMASM etc.
373:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/03/17 00:01:13.25
>>370
命令と１：１で対応している分逆にコンパイラの最適化が阻害されるケースがある
とかいったやつか？
所詮はintrinsicsは高級アセンブラだ。
コンパイラより賢いコードがかけるならそれでいいんだ。
アセンブラを使っても同じ。
intrinsicsと対比するなら、むしろコンパイラの自動ベクタライズ機能だ。
CilkとかCtとかまともに使えるならそっちでもいいんだけどな
「緩くかける」ってのはたとえば、SIMDレジスタ16本あっても変数が16以上ある場合なんかあるじゃん。
レジスタカラーリングは常に自分のほうがコンパイラより賢いとは限らない。
32ビットと64ビットで同じコードを使ったり、あるいは、ターゲットCPUごとにコンパイルオプションを変えて
命令スケジューリングをチューンしてみたりとか、そういう場合にある程度有効だと思う。
（32ビット＋AVXってなるべく考えたくないな）
最終的にはサポートされてる命令ごとに同じ関数を何個も実装しないといけなくなって
頭がパーン（必須アモト酸が足りない）
374:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/03/17 00:13:19.67
AVXのコードは個人的にはYASMが一番書きやすいと思った。
凝り性だから2バイトVEXになるべく収まるように第2ソースオペランドに使う頻度の高い変数は
ymm0-ymm7になるように配置したりとか、そういう試行錯誤もなかなか楽しい。
（当然%define使いまくり）
大きい関数になると流石に諦めたくなる。
375:デフォルトの名無しさん
11/03/21 22:40:07.33
AVXの命令を非対応のCPUに読み込ませたらどうなるんだ？
昔SSE2の整数命令をPen3で実行したらなぜか例外は全く起きず、MMXの相当する命令に置き換わったのか、
前半のエレメントだけ処理されたような形になった記憶があるが…。
376:デフォルトの名無しさん
11/03/21 22:53:23.22
自分でテストしてみりゃいいだろ
377:デフォルトの名無しさん
11/03/21 22:59:47.56
非対応CPUでも、非対応OS上の対応CPUでも例外発生
378:デフォルトの名無しさん
11/03/21 23:46:28.01
>>376
>>377
今あるのはVS2010とVistaとC2Qだけで、
>非対応CPUでも、非対応OS上の対応CPUでも例外発生
のとおりWin7SP1もCi7も持ってないので…。
379:デフォルトの名無しさん
11/03/21 23:51:39.51
結局Win7SP1上で走らせても相当するSSE命令に置き換わるようなことは無く、
処理単位だけ変えて同じ命令を使うようなことは出来ないと考えていい？
380:デフォルトの名無しさん
11/03/22 00:28:30.60
> 昔SSE2の整数命令をPen3で実行したらなぜか例外は全く起きず、MMXの相当する命令に置き換わったのか、
OSが例外を処理してたとか、
Pen3で中途半端にSSE2の実装がされていたとか、
....
AVXの場合はそんなことは無い。
潔くスパッと例外発生。
どちらも対応したければ、
XCR0レジスタでAVX対応かどうか判断して、
対応の場合と非対応の場合で別のコードを走らせる。
381:デフォルトの名無しさん
11/03/22 00:33:23.80
SSE2の、が勘違いだったんだろう
382:デフォルトの名無しさん
11/03/22 01:12:20.94
PentiumIIIのデコーダがprefixを無視するだけ
特殊なことをやっているわけじゃない
URLﾘﾝｸ(sandpile.org)
URLﾘﾝｸ(sandpile.org)
383:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/04/05 00:54:47.04
66, F3, F2＝意図しないプリフィックスがついてるけど無視しちゃえ
Athlon XPも同じ動きだね
384:,,・´∀｀・,,）＜一番良い -○○○ を頼む
11/04/05 00:57:52.59
あと、VC++なんかはSEH対応してるから、ためしにAVX命令を実行してみて
例外をキャッチしたら従来命令を実行って手も使えるけどな。
385:デフォルトの名無しさん
11/04/16 01:33:42.21
>>384
普通はそんなアホなコードにはしない。
386:デフォルトの名無しさん
11/04/16 04:04:56.75
普通じゃなくてもしない。
と思ったが、流れ的にその場じゃなくてアプリケーションの先頭でそうやってチェックして、
以降切り替えるという意味なのかも知れないと思い直した。
でもしない。
387:デフォルトの名無しさん
11/04/18 23:50:02.49
>>385
じゃあどうかくの？
最初にcpuidで判別？
388:デフォルトの名無しさん
11/04/19 05:21:52.32
そうだね
SIMD使うような性能重視のコードで、エミュレーショントラップなんてやってたら話にならないし
事前に切り分けるんだったら、例外なんか使う必要は普通ない
389:デフォルトの名無しさん
11/04/19 21:15:17.43
CPUIDだけじゃダメ。
XGETBVを使ってOSが対応しているかどうか調べる。
390:デフォルトの名無しさん
11/05/01 22:37:53.35
>>389
SIMD使うようなコードって、そもそも使うOSとか指定させないか？
そもそも未知のOSで動くバイナリなんて作れないでしょう。
391:デフォルトの名無しさん
11/05/02 00:04:37.45
将来のOSまでサポートできないしi7マシンにXP入れるようなバカも多いし
XPをAVX対応にするようなやつも出てきそうだし
あと今後はXPモードのような仮想環境も考える必要がありそうだし
結論
OS指定は無駄
392:デフォルトの名無しさん
11/05/02 17:13:41.32
現実的には、強制指定の手段をユーザーに提供して、一応自動検出するけれども
ユーザー指定を優先して動作する、でいいんじゃないの？
393:デフォルトの名無しさん
11/05/02 21:20:09.38
>>392
XGETBVの結果で十分
394:デフォルトの名無しさん
11/05/02 22:52:09.89
エラッタ対策としてユーザーが無効化するのは十分にありかも
395:デフォルトの名無しさん
11/05/03 07:44:32.29
>>394
今見つかっていなくて、存在もしないかもしれない重度のエラッタが心配なら
AVXに限らずプログラムなんか組めないと思う。
ユーザーが速度をくらべてニヤニヤする為とかデバッグの為とかならわからないでもないが。
396:デフォルトの名無しさん
11/05/03 08:32:40.26
fdivみたいな計算結果が間違えるようなエラッタだったら選択方式とかありえんし
どんなエラッタだと実行する命令を選択できることが嬉しいんだ
397:デフォルトの名無しさん
11/05/06 20:18:12.67
AVXのほうはどうよ？
SSEより速くなった？
398:デフォルトの名無しさん
11/05/06 23:05:52.73
>>397
そりゃそうよ。ツボにはまれば倍に。
ベクトル化が難しいデータだと活用はSSE2より難しくなるけど。
399:デフォルトの名無しさん
11/05/10 22:48:11.48
ドット積のような計算やってみたんだが水平加算が数が増えた分遅くなるな
とりあえずチューニングがむずい
ちっともはやくならん
400:デフォルトの名無しさん
11/05/10 22:53:58.51
構造体の配列じゃなく、配列の構造体にする。
出来ないなら劇的な速度アップはムリ。
401:デフォルトの名無しさん
11/05/10 23:05:47.94
SOAかAOSとか言ってるレベルではないよ
402:デフォルトの名無しさん
11/05/10 23:37:47.48
データのベクトル化が無理なら劇的な速度アップはあきらめろ。
403:デフォルトの名無しさん
11/05/10 23:56:50.67
AVXは128ビットずれててもセグ違反にもならなず、しっかり計算してしまうぞ？
404:デフォルトの名無しさん
11/05/11 00:06:16.67
256bitアラインメントを要求するのは
VMOVAPD VMOVAPS VMOVDQA VMOVNTDQ VMOVNTDQA VMOVNTPD VMOVNTPS
405:デフォルトの名無しさん
11/05/11 00:10:47.94
それって一切ペナルティ無しで？
406:デフォルトの名無しさん
11/05/11 00:18:24.19
ペンるてぃの有無は分からん
自分で確認してみてくれ
407:デフォルトの名無しさん
11/05/11 20:39:53.95
なんかSSEを2回やってるのと変わらん速度しかでないんだけど
ほとんどの命令で倍近い時間がかかるのは仕様？
408:399
11/05/11 20:46:30.30
同じく
今のところ対応不明
てか速くなるのかな？
409:デフォルトの名無しさん
11/05/11 20:54:48.81
そうか！
>>403が言っている通りならAVX命令は本当にただのSSE命令2回分だ
少し納得
410:デフォルトの名無しさん
11/05/11 22:49:47.40
どんな処理でテストしてるの？
411:デフォルトの名無しさん
11/05/11 23:24:13.81
今は土台を作る時期
412:デフォルトの名無しさん
11/05/12 01:41:23.77
レジスタ同士の演算なら普通に倍の速度は出る。
メモリからのロードは（あんまりここがボトルネックにならないだろうから）工夫して凌ぐ。
413:デフォルトの名無しさん
11/05/13 23:22:44.28
floatの配列の合計を求めるプログラムで試してみたけど、
普通にAVXの方が半分の時間で済むぞ。
アラインメントをずらした実験だと、
128bit境界でないと極端に遅く、
128bit境界であれば256bit境界に無くても速い
414:デフォルトの名無しさん
11/05/13 23:46:33.21
まあロード・ストアは128なんだから不思議でもないんじゃない
ただストアフォワーディングできるのは32Bアラインだけとかいう話だったような
415:デフォルトの名無しさん
11/05/14 00:37:44.73
>>412>>413
>>407=>>409だけど整数演算が完全に1回あたり2倍の時間がかかるんだ
浮動小数は2倍速とまではいかないかったけどメモリロードストアの回数が減った分程度に速くはなった