[表示 : 全て 最新50 1-99 101- 201- 2chのread.cgiへ]
Update time : 04/29 12:09 / Filesize : 46 KB / Number-of Response : 221
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


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

【C++】高速化手法【SSE】



1 名前:デフォルトの名無しさん mailto:sage [2005/10/27(木) 02:55:36 ]
C++やインラインアセンブラ、SSEなどによる高速化の手法
について語りましょう。

85 名前:デフォルトの名無しさん mailto:sage [2006/11/11(土) 12:12:26 ]
>>80
MMXテクノロジ最適化テクニック(ISBN4-7561-0797-4)の5章


86 名前:80 mailto:sage [2006/11/11(土) 22:35:35 ]
>>85さん、ありがとうございます。
早速書店で探してみます。m(_ _)mペコリ

87 名前: 【凶】 【488円】 [2007/01/01(月) 10:52:18 ]
SSEでどこか参考になるサイトはありませんか?


88 名前:デフォルトの名無しさん mailto:sage [2007/01/01(月) 12:07:08 ]
つ[google]

89 名前:デフォルトの名無しさん mailto:sage [2007/01/08(月) 18:18:09 ]
最近のコンパイラはSSEなどは指定しなくても自動的に使ってくれるのでしょうか?

90 名前:デフォルトの名無しさん mailto:sage [2007/01/08(月) 18:30:46 ]
ではまず最近のコンパイラの定義から(ry

91 名前:デフォルトの名無しさん mailto:sage [2007/01/08(月) 18:32:37 ]
>>89
そういうコンパイラもあります。

92 名前:デフォルトの名無しさん mailto:sage [2007/01/08(月) 18:34:43 ]
インテルコンパイラです

93 名前:デフォルトの名無しさん mailto:sage [2007/01/08(月) 18:36:58 ]
自動的に使うようになってると、SSEがないCPUでは動作しないのでは。



94 名前:デフォルトの名無しさん mailto:sage [2007/01/08(月) 18:59:08 ]
O3を指定した場合、自動的に検出され使われる

95 名前:デフォルトの名無しさん [2007/01/08(月) 19:03:58 ]
  _  ∩
( ゚∀゚)彡 オッサン!オッサン!
 ⊂彡

96 名前:デフォルトの名無しさん mailto:sage [2007/01/08(月) 19:07:29 ]
ここってこんなに人居たんだ

97 名前:デフォルトの名無しさん mailto:sage [2007/01/08(月) 19:28:09 ]
>>95
オマイの駄洒落のほうが・・

98 名前:・∀・)っ-{}@{}@{}@ mailto:sage [2007/01/08(月) 20:10:18 ]
/Qx*とか/Qax*なしで使うことってあったっけ?
とりあえずboost:mt19937はICCのオートベクトライズでやたら速くなるが

99 名前:デフォルトの名無しさん mailto:sage [2007/01/08(月) 20:31:21 ]
Auto-vectorization in GCC
ttp://gcc.gnu.org/projects/tree-ssa/vectorization.html

100 名前:デフォルトの名無しさん mailto:sage [2007/01/08(月) 20:47:28 ]
AMD64向けだと強制的に使ってくれる。

自動ベクトル化は知らん。


101 名前:サイザー専用JAVA演習場 その2 [2007/01/08(月) 21:17:02 ]
次スレまできた。飽きっぽい俺が良く続くもんだ。Σ(´∀`;)
どうぞよろしくお願いします。

102 名前:デフォルトの名無しさん mailto:sage [2007/01/29(月) 08:23:39 ]
www.intel.co.jp/jp/developer/download/index.htm
ここにあるインストラクションセット表って、
SSE3以降のものも載ってます?

103 名前:デフォルトの名無しさん mailto:sage [2007/02/07(水) 20:57:03 ]
SSE3は載ってたと思う。SSSE3は知らん



104 名前:デフォルトの名無しさん mailto:sage [2007/02/09(金) 01:09:07 ]
gcc 4.1.1をMinGW gcc 3.4でコンパイルして使っています。
自分の使っているCPU向けに最適化をしようと、
-O2 -march=pentium-m -msse2 -mfpmath=sse
上のオプションを付けてLame 3.97をコンパイルしたところ、最後の
-mfpmath=sse
を外した方が速いという結果になってしまいました。
CPUはCeleron Mを使っています。

Cerelon Mでは、実数演算ではSSEではなく80387を使った方が速いのでしょうか。
SSE命令を使った方が一見速そうに見えるのですが・・・。

105 名前:・∀・)っ-○◎● ◆DanGorION6 mailto:sage [2007/02/10(土) 01:07:28 ]
BaniasかDothanかYonahかにもよるけど、SSEはあんまり得意じゃないよMは


106 名前:104 mailto:sage [2007/02/10(土) 16:29:40 ]
>>105
Dothanコアです。

MはSSEが得意ではないのですね。参考になりました。
参考までに、姫野ベンチでも実験したところ、こちらは-mfpmath=sseありの方が速かったので、
コードに依るかも知れません。

107 名前:・∀・)っ-○◎● ◆DanGorION6 mailto:sage [2007/02/10(土) 21:00:29 ]
Pentium M系アーキテクチャでSSE*が遅いのはデコーダがネックになってるらしい。
Complex Decoderのみでデコードされるから、倍精度は浮動小数が速くても不思議じゃない

Pentium MのFPUは加減算・乗算毎に倍精度×1、単精度×2だけど
x87とSSEスカラ演算だと単精度はクロックあたり1、SSEのパックド演算だと2つは
発行できるから、単精度ならまだ使う価値があるね。

108 名前:デフォルトの名無しさん mailto:sage [2007/02/10(土) 21:59:57 ]
演算ユニットの構成は

Port 0: x87ADD x87&SSE-MUL
Port 1: SSE-ADD(SP Only)

よってクロック毎に実行できる最大値は
x87-SP: 1
SSE-SP: 4
SSE-DP: 1

109 名前:デフォルトの名無しさん mailto:sage [2007/02/12(月) 16:51:08 ]
んでもSSE使うように最適化オプションつけた方が
遅くなるってのは不思議だよなぁ。
早くならないってことはあっても遅くなるってのはなぁ・・・
タスクスイッチのときにXMMレジスタも全部退避するようになるから?
そういやXMMレジスタまで対比するか否かってOSはどうやって知ってるの?

110 名前:デフォルトの名無しさん mailto:sage [2007/02/12(月) 16:58:01 ]
>>109
そもそも初期状態でFPUセットになっているのなら、SSEを使うだけで切り替えコストが発生する。

111 名前:・∀・)っ-○◎● ◆DanGorION6 mailto:sage [2007/02/12(月) 17:01:00 ]
まあ、Complexデコーダパス命令だから、の一言なんだが
待避のオーバーヘッドなんてたかがしれてる



MXCSRレジスタってあるじゃん

112 名前:・∀・)っ-○◎● ◆DanGorION6 mailto:sage [2007/02/12(月) 17:01:45 ]
>>110
それXMMレジスタじゃなくてMMレジスタの話では

113 名前:デフォルトの名無しさん mailto:sage [2007/02/12(月) 17:41:09 ]
でもSISDならデコードも速い。
単純にコンパイラが最適化しきれてないだけじゃないのか。
そもそも104氏が何の処理をさせてたのか書いてないから
イマイチ議論のしようがない気もする。

おそらく人間が書けばDothanでもSSEの方が速いとは思う。



114 名前: ◆0uxK91AxII mailto:sage [2007/02/12(月) 21:16:30 ]
>>109
>XMMレジスタまで対比するか否か
hira.main.jp/wiki/pukiwiki.php?__save_init_fpu()%2Flinux2.6

115 名前:・∀・)っ-○◎● ◆DanGorION6 mailto:sage [2007/02/17(土) 17:12:17 ]
Core 2 (Merom)ベースのCeleron Mももう出たし

116 名前:デフォルトの名無しさん [2007/02/19(月) 20:47:39 ]
二つの符号付及び符号無し 64bit 整数の乗算、
さらには 128bit 整数同士の乗算などは
SSE/SSE2/SSE3 命令群を使うことで高速化できるのでしょうか?

そもそもこれらの命令は SIMD 目的であって
ビット幅の長い演算が目的ではないので、
見当違いでしょうか?

117 名前:・∀・)っ-○◎● ◆DanGorION6 mailto:sage [2007/02/20(火) 00:30:25 ]
64ビット同士の整数乗算は素直にx64命令セット使えと思うが。。。

16×16の積算・積和演算があるから組み合わせればいくらでも可能だ罠

118 名前:デフォルトの名無しさん [2007/02/21(水) 14:03:24 ]
海外旅行での現地のATMでのキャッシングって、
キャッシング枠ですか?それともショッピング枠ですか?
以前現金主義の友人がどうしても両替商見つからなくて
現地のATMでキャッシングしたら、日本に帰ってきて
ショッピングとして明細に出てたって聞いたんですが。

119 名前:デフォルトの名無しさん mailto:sage [2007/02/21(水) 15:09:23 ]
>>118
ATMによる。スレ違い。

120 名前:デフォルトの名無しさん mailto:sage [2007/02/25(日) 13:31:40 ]
誤爆じゃないのか

121 名前:デフォルトの名無しさん [2007/03/02(金) 21:40:36 ]
浮動小数点モデルを /fp:fast にする
精度は落ちるが

122 名前:デフォルトの名無しさん mailto:sage [2007/03/03(土) 09:27:27 ]
マルチタスク/マルチスレッドで、セマフォを長時間握ったまま返さない奴とか見つける、とかは
やっぱプロファイラとかで動的解析しないと分らんよね。
そんなの静的解析でどうにかなるもんじゃないか・・・。

123 名前:デフォルトの名無しさん [2007/06/04(月) 18:02:04 ]
doubleは2つ同時にしか実行できないのか?



124 名前:デフォルトの名無しさん [2007/06/04(月) 18:08:28 ]
>>123
日本語よろ!

125 名前:デフォルトの名無しさん mailto:sage [2007/06/04(月) 18:54:23 ]
だぶる先生らいふのことだろ。
常識的に考えて。

126 名前:デフォルトの名無しさん mailto:sage [2007/09/28(金) 23:10:54 ]
ダブル先(の)生ライフ?

127 名前:デフォルトの名無しさん mailto:sage [2007/10/01(月) 19:33:27 ]
>>123
C++でおk

128 名前: ◆0uxK91AxII mailto:sage [2007/10/01(月) 23:04:52 ]
>>123
一つのみも可。
ex) addsd

129 名前:デフォルトの名無しさん mailto:age [2007/12/31(月) 11:50:57 ]
下がり過ぎ

130 名前:デフォルトの名無しさん mailto:sage [2008/11/08(土) 21:50:37 ]
SSEで大部分が記述された
正規表現エンジンって知りませんか?

131 名前:デフォルトの名無しさん mailto:sage [2008/11/09(日) 00:12:17 ]
闇雲にSSEを使えば速くなるってもんじゃないし、そんな阿呆な代物ないでしょ。
# 速度に寄与する肝腎な箇所に使っているってことなら話は別だが。

132 名前:デフォルトの名無しさん mailto:sage [2008/11/09(日) 01:43:59 ]
sseで正規表現・・・どこで使ったものやら

133 名前:デフォルトの名無しさん mailto:sage [2008/11/10(月) 14:07:10 ]
SSEって並列処理や積和なんかが1命令化で速くなる。
端からデータを舐めていくような処理はあまり効果ないよ。
特に検索には向かない。



134 名前:デフォルトの名無しさん mailto:sage [2008/11/10(月) 14:17:20 ]
bit列のマッチングはどう?
1bitずつずらしたのをxorしてall 0になったかどうか調べるとか

135 名前:デフォルトの名無しさん mailto:sage [2008/11/10(月) 21:40:31 ]
strlenをSSE2でやる人がいるくらいだし、その応用でstrchr/strstrのような単純な検索はできると思う。
ただ、正規表現となるとうまく使うのは難しいと思う。

136 名前:デフォルトの名無しさん mailto:sage [2008/11/18(火) 03:23:27 ]
sse4.2じゃないのか

137 名前:,,・´∀`・,,)っ-●◎○ [2008/12/21(日) 11:48:46 ]
固定文字列部分を抽出してBoyer-Moore法とかで検索するのが良く使われる方法。
strstrなんかはSIMDを使った力技検索に置き換えることができる。

>>136
確かにあれは速いようだ


138 名前:,,・´∀`・,,)っ-●◎○ [2008/12/21(日) 11:51:30 ]
固定文字列部分ならともかく「大部分」をSIMDに置き換えることに意味はない。
文字クラス程度ならSSE4.2で一括判定みたいなのも可能になるかと思うけど

139 名前:デフォルトの名無しさん mailto:sage [2008/12/21(日) 12:13:43 ]
つうかそんなのAltiVecでとうの昔にやられてる事だしな。
Intelは必要な命令(シャッフル、MIN/MAXなど)が揃うまでにどれだけかかるんだ。
ルーチンごとにSSE1があるか、2があるかと判定しなくちゃいけなくて面倒くさい。

140 名前:,,・´∀`・,,)っ-●◎○ [2008/12/21(日) 12:18:35 ]
Macのこと言ってるのか?
SSE3以上使える前提できめうちで組めるからかえって楽だろw

大体にAltiVecに文字列比較命令なんてねーよ。
汎用レジスタ−SIMDレジスタ間のダイレクト転送命令ないし
レジスタ値を比較してbranchフラグを更新する命令もない。

そもそも更新が停まってるだけだろ。

141 名前:,,・´∀`・,,)っ-●◎○ [2008/12/21(日) 12:30:26 ]
SSE2の16バイト単位の文字列同時比較なんてこれだけだぞ
(MMX(SSE)での8バイト同時比較でもこいつの64bit版を使えばいい)
pcmpeqb → pmovmskb → test → branch

SSE4.1だと
pcmpeqb→ptest→branchでおk


AltiVecだとpmovmskb相当のことをMSBの縮約いちいちマスク&シフトを繰り返した上
いったんメモリにストアしてから汎用レジスタで読み直さないといけない。
pmovmskbなんてIntelプロセッサでは1サイクルでこなせる処理だがAltiVecなんて
ここだけで何十サイクルもかかる。

なにかと俺がコケにしてるCell SPEのほうがまだ使えるよ。
SPUにはMSBじゃなくてLSBのビット縮約命令がある。

要するに
AltiVec=保守されてない時代遅れの命令セット
俺も使ってたからよくわかるよ。

142 名前:,,・´∀`・,,)っ-●◎○ [2008/12/21(日) 12:47:01 ]
俺の経験上文字列サーチでAltiVec使うと遅くなるケースのほうが多い。
だからMacOSでもstrcpy/memcpyみたいな分岐の必要ない操作に限ってだけAltiVecが内部的に使われてる。

143 名前:デフォルトの名無しさん mailto:sage [2008/12/21(日) 13:31:59 ]
同時比較でいいならロードして比較してvec_all_eq()するだけじゃね?
ストアと読み出しはいらん。



144 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2008/12/21(日) 18:51:16 ]
>vec_all_eq()
あのさー、それ複合関数だから。

ではマスク生成+縮約+ストア+汎用レジスタにロードって操作を1つの組込関数に纏めただけ。
1インストラクションで済んでるわけではない。

アセンブリコード読んだことある?無いだろうけど。


CPUネイティブのベクトル比較命令であるvcmpequb自体は、SIMDレジスタ上にマスクを生成するのみ。
マッチしたのか、マッチしてないのか、マッチした場合、どこの位置でマッチしたのかっていう判定は
汎用レジスタ側でやるしかないんだよ。

145 名前:デフォルトの名無しさん mailto:sage [2008/12/21(日) 19:51:08 ]
お前こそvcmpequbの仕様を読んだ事あるのかと。

> The CR6 is set according to whether all, some, or none of the elements compare equal.

146 名前:デフォルトの名無しさん mailto:sage [2008/12/21(日) 19:59:03 ]
最近論調がおとなしくなってきて改心したのかと思えば、
内心人を見下してるのは変わってないんだよな。

147 名前:デフォルトの名無しさん mailto:sage [2008/12/21(日) 20:04:05 ]
あ、なんでアセンブリコードとか的外れな事言ってるのかようやく分かった。
最適化オプションを全く指定しないと確かに複合になるね。

ていうかさあ、デバッグ用とはいえ確かにこのアセンブリは変態だけど
つまりはお前は大口たたいておきながら
その実>>143を言われて顔真っ赤にして焦ってアセンブリ出力を確認したんだろ。
恥ずかしいなあ。

148 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2008/12/21(日) 20:06:12 ]
「.」付き版はcr6を更新するからptest相当のことだけはできるよ。それは正しい。
どこでマッチしたかを求めるには汎用レジスタ側でやんないといけない。

pmovmskb相当の命令がないから遅いんだって。
Cell SPEだと7ビットシフトしてギャザリングし、ビットスキャンすれば位置が求まるけど


149 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2008/12/21(日) 20:07:28 ]
>>147
で、pmovmskbの代用命令はどこにあるの?


150 名前:デフォルトの名無しさん mailto:sage [2008/12/21(日) 20:08:21 ]
っヒント:もうL1に乗ってる

151 名前:デフォルトの名無しさん mailto:sage [2008/12/21(日) 20:09:45 ]
>>149
無いよ。
そこを叩きたいなら叩いてくれ。

152 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2008/12/21(日) 20:11:31 ]
そんなことは聞いてない。
SSE*にはSIMDレジスタ上のベクトルデータのMSBを縮約してダイレクトに汎用レジスタに転送する命令がある。
bsfと組み合わせればマッチ位置まで簡単に求めることができる。

AltiVecには、そういう命令は、ない。

153 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2008/12/21(日) 20:12:47 ]
>>151
なら結局遅いじゃん。



154 名前:デフォルトの名無しさん mailto:sage [2008/12/21(日) 20:15:38 ]
支離滅裂だな。
それが初めから分かってるなら慌ててアセンブリ確認なんてしてないだろ。
百歩譲って今お前が力説したい事にスポットを当てるなら
all_xx()が複合であるかどうかなんてどうでもいいんだからな。

ていうかstrchなのかstrstrなのかハッキリしろよ。
反論するのに都合の良い方を選択してるだけじゃねーか。

155 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2008/12/21(日) 20:16:13 ]
慌ても確認もしてないよ

156 名前:デフォルトの名無しさん mailto:sage [2008/12/21(日) 20:17:49 ]
じゃあall_xxが複合だと言ったのはどこのだれですか?
結局gather出来ないんだから、そこはどうでもいいんだけどね。

157 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2008/12/21(日) 20:19:12 ]
>>154
どっちもSSEより遅いよ。

PPCからの移植にSSE1まで使えるか2まで使えるかとか気にしなきゃいけないと思う方が馬鹿だよ。
Win32でもSSE2が使えないCPUなんてどのみちSIMDユニットの実装もショボイから最適化対象としては無視して良いくらいだよ。
非SIMDのパスに飛ばしておけばいい。


158 名前:デフォルトの名無しさん mailto:晒しage [2008/12/21(日) 20:22:57 ]
まあそれも論点ずれてるんだが、建設的な話をしたいからお前に合わせよう。

確かにSSE2が使えないCPUは大抵しょぼいから無視しても良いんじゃないかな。
強いて言うならAMD(笑)が例外だが。

でもx86陣営がそういう路線を歩んでいるのは間違いなくて
SSE3, SSSE3, SSE4.1, SSE4.2, AVX, LNIといちいちチェックしなくてはいけない日々が続く事には変わりない。

159 名前:デフォルトの名無しさん mailto:sage [2008/12/22(月) 00:20:05 ]
Core2 Duoと比較して、Athlon X2がそれほど酷いとは思えないんだけど。

160 名前:デフォルトの名無しさん mailto:sage [2008/12/22(月) 00:39:51 ]
整数演算はひどいな

161 名前:デフォルトの名無しさん mailto:sage [2008/12/22(月) 12:59:27 ]
一晩考えて、何故団子がgatherに必死なのかが分かった。
団子はトリップ検索が主だから検索対象が極端に小さくて、
詳細な位置の特定の方がボトルネックになっているんだな。

162 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2008/12/22(月) 18:05:57 ]
tawake

163 名前:デフォルトの名無しさん [2008/12/22(月) 18:42:38 ]
続きをどうぞ



164 名前:デフォルトの名無しさん mailto:sage [2008/12/23(火) 01:34:18 ]
>>161
誰が笑いを取れとw

165 名前:デフォルトの名無しさん mailto:sage [2008/12/24(水) 07:45:53 ]
変な事言った?

166 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2008/12/24(水) 19:00:25 ]
一晩考えることじゃないだろ。俺のブログ一通り読んだら30分以内に否定される。

167 名前:デフォルトの名無しさん mailto:sage [2008/12/24(水) 20:19:04 ]
で?

168 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2008/12/24(水) 20:52:06 ]
笑いしかとれなかったね

169 名前:デフォルトの名無しさん mailto:sage [2008/12/24(水) 23:46:08 ]
そうだね。俺もだけど団子も痛い子だね。

170 名前:デフォルトの名無しさん mailto:sage [2008/12/25(木) 00:24:23 ]
痛いのはお前だけですからwww

171 名前:デフォルトの名無しさん mailto:sage [2008/12/25(木) 00:39:33 ]
だから何故?
煽ってるんじゃなくて純粋に。

172 名前:デフォルトの名無しさん mailto:sage [2008/12/26(金) 19:45:57 ]
無知のまま過ごすのは恥だし勿体ないので団子でも名無しでも回答くれないかな。
名無しが答えられるかどうかは疑問だけど。

173 名前:デフォルトの名無しさん mailto:sage [2008/12/26(金) 20:29:55 ]
        ∩___∩
. \     | ノ      ヽ
   \  /  ●   ● |
     \|    ( _●_)  ミ  そんなエサでおれが釣られるかクマー!
      彡、   |∪| ,/..
       ヽ   ヽ丿/  /⌒|
       / \__ノ゙_/  /  =====
      〈          _ノ  ====
       \ \_    \
        \___)     \   ======   (´⌒
           \   ___ \__  (´⌒;;(´⌒;;
             \___)___)(´;;⌒  (´⌒;;  ズザザザ




174 名前:デフォルトの名無しさん mailto:sage [2008/12/27(土) 07:45:25 ]
都合が悪くなるとすぐ逃げるか話そらすからな。
結局161が図星だったのか。

175 名前:デフォルトの名無しさん mailto:sage [2008/12/27(土) 10:20:33 ]
名無しが寂しそうにしてるから構ってやれよw

176 名前:デフォルトの名無しさん mailto:sage [2009/01/04(日) 11:41:54 ]
ビット演算の代数的な性質、それを導き出す公理が知りたい
算術演算から式変形だけでアセンブリ言語のコードを導き出せるようになりたい

177 名前:デフォルトの名無しさん mailto:sage [2009/01/04(日) 12:31:09 ]
コンパイラでも作りたいの?

178 名前:デフォルトの名無しさん [2009/01/07(水) 23:00:55 ]
メモリアクセスとかを考慮すると構造体より配列のほうが高速?

179 名前:デフォルトの名無しさん mailto:sage [2009/01/08(木) 00:02:43 ]
>>178
同じ。

180 名前:デフォルトの名無しさん mailto:sage [2009/01/08(木) 00:13:42 ]
SSE2でnビット左rolってどうやって記述すればいいのですか?

181 名前:デフォルトの名無しさん mailto:sage [2009/01/08(木) 00:34:34 ]
Intelのマニュアル読みなさい

182 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/01/08(木) 08:10:02 ]
好きなの使え

;;【16bit×4並列】
movdqa xmm1, xmm0
psllw xmm0, N
psrlw xmm1, 16-N
pand xmm0, xmm1

;;【32bit×4並列】
movdqa xmm1, xmm0
pslld xmm0, N
psrld xmm1, 32-N
pand xmm0, xmm1

;;【64bit×2並列】
movdqa xmm1, xmm0
pslld xmm0, N
psrld xmm1, 64-N
pand xmm0, xmm1

【↓こっからまだ存在してないCPU向け】
protb xmm0, xmm0, N ;; 8bit×16用 AMD SSE5
protw xmm0, xmm0, N ;; 16bit×8用 AMD SSE5
protd xmm0, xmm0, N ;; 32bit×4用 AMD SSE5
protq xmm0, xmm0, N ;; 64bit×2用 AMD SSE5
あと要素毎に変量が変えられる命令もサポートされてる。
俺は実用性を思いつかないが何かしら使える用途があるんだろう。

ちなみに128ビットフルは、場合によるので省略する。
4バイト単位ならpshufdとかのシャッフル命令使った方がいい。

183 名前:デフォルトの名無しさん mailto:sage [2009/01/08(木) 11:55:57 ]
俺の質問には答えずに人の質問には答えるんだな。

要素ごとのは、例えば最上位に立っているビットからNビット欲しいとか色々使い道はあるよ。
floorみたいのを自力で実装しようとすれば分かる。



184 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/01/08(木) 12:46:20 ]
サーセンwwwpandじゃなくてporだwww

185 名前:デフォルトの名無しさん mailto:sage [2009/01/09(金) 14:29:17 ]
>>179
うほ?
>>178の意味がいまいち分からんが、
char array[0x100];

struct{char value;} array[0x100];
だったらレジスタサイズにパディングされる分、構造体の方が早くね?
ちなみに、同じ事だが容量気にして構造体のなかでshortとか使うと
パデイング入るんでメモリに無駄が発生する。
まぁ、パディングを知っていれば無駄を防ぐこともできるけど。

186 名前:デフォルトの名無しさん mailto:sage [2009/01/10(土) 05:48:58 ]
構造体にすればパディングされると決まっているわけではない。
だからその例だけだとどちらとも言えない訳だが。

構造体のメンバを一部だけshortにするのは意味が殆どない(寧ろ遅くなる)という点については同意。

187 名前:デフォルトの名無しさん [2009/01/11(日) 01:26:48 ]
>>185

short array[3];

struct{short value1;short value2;short value3;} array;
でどっちが高速かという意味です。

188 名前:デフォルトの名無しさん mailto:sage [2009/01/11(日) 01:44:37 ]
配列のindexが定数なら変わらんだろ
アセンブラ見ろ

189 名前:デフォルトの名無しさん mailto:sage [2009/01/11(日) 01:50:19 ]
>>185
> struct{char value;} array[0x100];
> だったらレジスタサイズにパディングされる分、構造体の方が早くね?

pragmaやattributeでパックしない限りpaddingは入らないだろ。

190 名前:,,・´∀`・,,)っ-●◎○ [2009/01/11(日) 06:03:24 ]
16とか32になるのはいいけどメモリアドレッシングで使えるscaleが8倍までなんだよな。
添字によるアクセスは思わぬ性能低下を起こすことがある

191 名前:,,・´∀`・,,)っ-●◎○ [2009/01/11(日) 06:05:36 ]
>>189
構造体やその配列の場合、パディングが入る。
デフォルトが4バイト単位だったかな?

192 名前:デフォルトの名無しさん mailto:sage [2009/01/11(日) 10:18:30 ]
おまえほんとにだんごか?
デフォルトなんて決まってるわけ無いだろ

193 名前:,,・´∀`・,,)っ-●◎○ [2009/01/11(日) 10:25:51 ]
まあデフォルト値は処理系依存だな。

>>189の言ってることが嘘ってことで。
少なくともパディングが入らない保障はない。



194 名前:デフォルトの名無しさん mailto:sage [2009/01/11(日) 10:51:19 ]
コンパイラ依存だよな。
歴史的な理由で当時の最長のレジスタがdoubleだからCPUのアライメントが8byte推奨で、コンパイラも8byteに詰めてた気が。
もしかしたらx86じゃなくてPowerPCかも知れん。

195 名前:デフォルトの名無しさん [2009/01/11(日) 14:47:57 ]
VCやGCC辺りはパディングが入る。
Bitmapヘッダをそのまま構造体で読み取ろうとして引っかかった
やつも少なくない筈。(VCならpragmaを使えばパディングを消すことができる)
一応32bitCPUならVC、GCC共にcharもshortも32bitで確保される。
64bitなら64bitで確保されるとか聞いたことがあるが真偽は不明。
蛇足だが、VCでchar array[5];などと確保すると確保した容量+3
の領域が確保される。

196 名前:デフォルトの名無しさん mailto:sage [2009/01/11(日) 15:41:20 ]
kikyou.info/diary/?200812#i24_1
> つまり最大でポインタ二つ分のデータを保持しています。LP64の場合は128bitとなります。ILP32の場合は64bitとはならず、パディングの関係でLP64と同じく128bitとなります。
8byte?

197 名前:デフォルトの名無しさん mailto:sage [2009/01/11(日) 15:44:14 ]
将来AVXの1024bit SIMDが使えるようになった際に、128byteにパディングされるとかなるとイヤだな。
その頃にはメモリは数十GBで128byteなんてゴミみたいなもんだろうけど。

198 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/01/11(日) 15:47:54 ]
その頃までにSIB.scaleのビット拡張してほしいね。1ビット増やせばx16, x32, x64, x128になるのに。

199 名前:デフォルトの名無しさん mailto:sage [2009/01/11(日) 15:59:23 ]
\  \\       ____         // / /
<           _-=≡:: ;;   ヾ\            >
<         /          ヾ:::\           >
<         |            |::::::|          >
<        ミ|-=≡、 ミ≡==- 、 |;;;;;/          >
<         || <・>| ̄| <・> |── /\         >
<         |ヽ_/  \_/    > /         >
<        / /(    )\      |_/          >
<        | |  ` ´        ) |           >
<        | \/ヽ/\_/  /  |           >
<        \ \ ̄ ̄ /ヽ  /  /           >
<          \  ̄ ̄   /  /       \    >
  / /        ̄ ̄ ̄ ̄ ̄ ̄ ̄     \\ \ \
     ___
   / ―\ ナンミョウホウレンゲッキョウナンミョウホウレンゲッキョウナンミョウホウレンゲッキョウ
 /ノ  (@)\ ナンミョウホウレンゲッキョウナンミョウホウレンゲッキョウナンミョウホウレンゲッキ
.| (@)   ⌒)\ ナンミョウホウレンゲッキョウナンミョウホウレンゲッキョウナンミョウホウレンゲッ
.|   (__ノ ̄|  |   ///;ト,  ナンミョウホウレンゲッキョウナンミョウホウレンゲッキョウナンミョ
 \   |_/  / ////゙l゙l;  ナンミョウホウレンゲッキョウナンミョウホウレンゲッキョウナンミョ
   \     _ノ   l   .i .! |  ナンミョウホウレンゲッキョウナンミョウホウレンゲッキョウナンミョ
   /´     `\ │   | .|  ナンミョウホウレンゲッキョウナンミョウホウレンゲッキョウナンミョ
    |       | {   .ノ.ノ  ナンミョウホウレンゲッキョウナンミョウホウレンゲッキョウナンミョ
    |       |../   / . ナンミョウホウレンゲッキョウ


200 名前:デフォルトの名無しさん mailto:sage [2009/01/12(月) 00:40:28 ]
パディングってむやみに入れるとキャッシュヒット率悪くなってかえって効率落ちたりしないんだろか


201 名前:,,・´∀`・,,)っ-●◎○ [2009/01/12(月) 00:42:04 ]
逆にキャッシュラインを跨ぐと効率悪くなるんだよ


202 名前:デフォルトの名無しさん mailto:sage [2009/01/12(月) 00:44:50 ]
>>200-201
どっちも一般論だー

場合によるでしょ

203 名前:デフォルトの名無しさん mailto:sage [2009/01/12(月) 00:58:25 ]
実測すれば済む話



204 名前:デフォルトの名無しさん mailto:sage [2009/01/12(月) 01:11:32 ]
>>191
cygwin上のgccで試してみたけど、padding入らないよ

205 名前:デフォルトの名無しさん mailto:sage [2009/01/12(月) 13:59:38 ]
>>204
CPUによるが
struct foo {
char a;
double b;
};
でパディングが入らなかったら例外起きるだろうが。

206 名前:デフォルトの名無しさん mailto:sage [2009/01/12(月) 14:41:55 ]
起こんねーよ、CPUによるが。

207 名前:デフォルトの名無しさん mailto:sage [2009/01/12(月) 14:55:43 ]
struct {char a, b, c;}だったらパディングなくても例外起きないよ。
コンパイラがまともなら。

208 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/01/12(月) 17:32:33 ]
アラインメント制約の厳しいプロセッサなら、例外が起きないようにコンパイラが勝手にパディングするんじゃないかな。


しかしミスアラインメントのデータに対するロード・ストアの扱いは各CPUアーキ毎に方針が違ってて面白いな
x86のSSE以降は、ミスアラインメントを許すが遅い命令と、許さないが高速な命令の2通りを用意。
対して、POWER/CellのSIMDは下位ビットを無視してロードし、プログラマが勝手にPermuteしてくれっていう扱い。

209 名前:デフォルトの名無しさん mailto:sage [2009/01/12(月) 18:31:15 ]
下位ビットを無視してくれるのはわざわざAND取ってアライメントする必要がないから楽でいいよな。

210 名前:デフォルトの名無しさん mailto:sage [2009/01/12(月) 18:38:09 ]
中を作る側もデコーダが軽くなるからウマー


211 名前:デフォルトの名無しさん mailto:sage [2009/01/13(火) 01:17:59 ]
>>205
> >>204
> CPUによるが
> struct foo {
> char a;
> double b;
> };
> でパディングが入らなかったら例外起きるだろうが。

なぜ勝手にdoubleが入ってるんだww
誰もそんな場合の話はしていない。
団子にこんな基本的なことで嘘つき呼ばわりされたが嘘じゃないってことで

>>185
> struct{char value;} array[0x100];

212 名前:デフォルトの名無しさん mailto:sage [2009/01/13(火) 01:46:59 ]
ところでパディングの入らない環境ってどんな環境だろ?
PC用で32bitプロセッサじゃ大抵入ると思うが。
sizeof(struct{char value;})==4
見たいにね。

213 名前:デフォルトの名無しさん mailto:sage [2009/01/13(火) 02:10:47 ]
struct{char value;} array[0x100];
printf("%d\n", sizeof(array));
=> 256
gcc-4.3.2ではこうなったけど、パディングってそもそも何だ?無効領域?



214 名前:デフォルトの名無しさん mailto:sage [2009/01/13(火) 02:48:14 ]
>>212
Crayだとchar=short=int=32bitとかが普通らしい。
PC用じゃないけど。

215 名前:デフォルトの名無しさん mailto:age [2009/01/13(火) 17:31:55 ]
>>213
ゴメン
sizeof(struct{char value;})じゃ1だね。
sizeof(struct{char v1;short v2})じゃ4になったから試さずに
書いちゃった。メンバーが同じサイズなら配列化されるっぽいね。

216 名前:デフォルトの名無しさん mailto:sage [2009/01/13(火) 19:04:45 ]
1つの構造体中でサイズ違いのアクセスが発生するかどうかによって変わるのじゃない。
連続の同一単位アクセスだけなら必要ないし、むしろ最適化にも邪魔だと思うんだよね?

struct{char a;} arrayo[10];
struct{char a; char b;} arrayp[10];
struct{char a; char b; char c;} arrayq[10];
struct{char a; int b;} arrayr[10]; /* inserted */
struct{int a; char b;} arrays[10]; /* interted */

217 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/01/13(火) 21:09:54 ]
俺的に配列は__declspec(align(32))がデフォです

218 名前:デフォルトの名無しさん mailto:sage [2009/01/13(火) 21:34:41 ]
32?
16じゃないのか?

219 名前:,,・´∀`・,,)っ-○◎● mailto:sage [2009/01/13(火) 23:06:38 ]
AVX化を視野に入れてるから

220 名前:デフォルトの名無しさん mailto:sage [2009/01/14(水) 08:14:08 ]
Alphaには16bitレジスタなかったよん






[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧](*・∀・)<46KB

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