05/10/27 02:55:36
C++やインラインアセンブラ、SSEなどによる高速化の手法
について語りましょう。
2:デフォルトの名無しさん
05/10/27 03:00:35
まずはi++は++iにしろよ。
3:デフォルトの名無しさん
05/10/27 03:02:26
それで速度があがるならな
4:デフォルトの名無しさん
05/10/27 03:07:02
Intelのコンパイラ買って開発したほうがいいんじゃね？
ヘタに素人が最適化なんてやるより
5:デフォルトの名無しさん
05/10/27 03:07:39
アルゴリズムよりメモリアクセスが最大のボトルネックだったりする。
結局レジスタやキャッシュを意識するのが重要になってくる。
6:デフォルトの名無しさん
05/10/27 03:09:50
>>4
コンパイラを変えるんじゃなくてパフォーマンスの解析ツールを
買わないとダメじゃないかな。
コンパイラ自体はVC7も用途によっては悪くないし。
7:デフォルトの名無しさん
05/10/27 03:14:21
>>6
VC++はプロファイラがついてると思うが
8:デフォルトの名無しさん
05/10/27 03:14:44
今月のCマガ買って読め。
9:デフォルトの名無しさん
05/10/27 03:21:52
STL使うなら自分で同じような物を作ったほうが高速。
10:デフォルトの名無しさん
05/10/27 03:24:25
その心は？
11:デフォルトの名無しさん
05/10/27 03:26:35
なんでいきなりSTLが・・・
12:デフォルトの名無しさん
05/10/27 04:41:40
主要部分をasmで書き直せばＯＫ
13:デフォルトの名無しさん
05/10/27 05:59:50
>>7
VC++のプロファイラは、普通に一通りの機能を備えているのに、使われないんだよね。
VC.NET用だと、Compuware(Numega)がプロファイラを無償で提供してくれてるよ。
VC++6.0まで、TrueTimeは売り物だったのにねぇ。
14:デフォルトの名無しさん
05/10/27 06:01:00
>1
>>12
インラインアセンブラよりも、組込み関数を使ったほうがいいことが多い。
・コンパイラが最適化をしてくれる
・プログラムの記述が楽で、修正しやすい。
という2つの大きなメリットがあるよ。
15:デフォルトの名無しさん
05/10/27 06:01:56
なおVC系の場合、
組込み関数をインライン展開する
というオプションを有効にしてしまうと、
インライン展開されてしまい、最適化されない
という直感的ではない結果になるので、確認しながらやりましょう。
16:デフォルトの名無しさん
05/10/27 06:02:27
VCにプロファイラがあるなんて気づかなかった
というか2chで聞いたら無いっていわれてずっと信じてた
17:デフォルトの名無しさん
05/10/27 06:09:25
VC7でなくなったんだっけか
18:デフォルトの名無しさん
05/10/27 11:13:28
>>13
>使われないんだよね。
GUIに罠が仕掛けてあるからじゃまいか？
19:デフォルトの名無しさん
05/10/27 11:23:51
SSE2が付いてるマシンではインラインアセンブラで書かれた処理を実行したいけど、
それ以外のマシンでは普通のC++で書かれた処理を実行したいと言うような場合、
どうすればいい？
20:デフォルトの名無しさん
05/10/27 11:25:47
開始時に判別して関数ポインタで入れ替え
21:デフォルトの名無しさん
05/10/27 11:29:20
やっぱそれしかないか。
関数のインライン化されにくいなぁとか、
C++のメンバ関数だと面倒だなぁとか思ったんで。
22:デフォルトの名無しさん
05/10/27 12:25:13
>>21
インスタンスをやたら作る必要が無いならファクトリーパターンで作り分けしてもらうという逃げ方もある。
23:デフォルトの名無しさん
05/10/27 16:10:52
んなややこしいことしなくても、マクロ使って1つのソースから2つのオブジェクトを吐かせればいい。
関数ポインタだってコストかかるので、1つずつの関数を切り替えるのではなく、
2通りのプログラムを1つのプログラムに押し込むくらいの気持ちで、
もっとmain関数に近いところから切り替えてしまおう。
24:デフォルトの名無しさん
05/10/27 23:22:49
インテルコンパイラってプリフェッチ命令を挿入するとか言ってるけど
プリフェッチって入れても効果ほとんど無いよね？
あとこれからPen3コアをベースにしたCPUになっていくからPen4用に
最適化はしないほうがいい？
25:デフォルトの名無しさん
05/10/27 23:26:27
>>24
場合によるだろ。prefetch命令はL2へのロードのアルゴリズムを
変更するので、場合によってはメモリのレイテンシを劇的に減らす
事が出来る。というかintelのpdf嫁。
26:デフォルトの名無しさん
05/10/28 03:13:27
prefetch命令を使って具体的に速度改善を説明する本とかないのかな。
サンプルコードとか載せてるのがあったら欲しい。
Webでも以外と情報無いし。
27:デフォルトの名無しさん
05/10/31 20:11:01
STL like Template based coding with MMX/SSE extension
URLﾘﾝｸ(www.codeproject.com)
Intel IPP
Iten OpenCV
そのまま使えば高速じゃん
28:デフォルトの名無しさん
05/11/10 03:07:31
>>27
なんだこれ。
マトリクスとかImageとか扱えるものなのか。
結構みんな使ってるんだろーか。
29:デフォルトの名無しさん
05/11/10 05:49:34
クイックソート以外の例えばマージソートやバルブソートなどはどのようなときに使うのでしょうか？
30:デフォルトの名無しさん
05/11/10 07:43:42
>>29
クイックソートは万能ではない。
特にソートする要素数が少ないときには他の方法が早い。
また、安定でないという欠点もある。（マージソートは安定）
31:デフォルトの名無しさん
05/11/11 01:17:48
>>29じやないんだが
>また、安定でないという欠点もある。（マージソートは安定）
これどーゆー意味なんよ？
高速化のスレだから速度の事を言ってるのか？
32:デフォルトの名無しさん
05/11/11 01:53:10
>>31
ソートで不安定といったら
比較関数の評価で重みが重複した場合に順序関係が保存されない
ことだと思うが…(;´Д｀)
33:デフォルトの名無しさん
05/11/11 07:49:51
>>31
>>31
>>31
34:デフォルトの名無しさん
05/11/11 13:33:13
出席番号順にソート済みの身体測定データを身長順にソートしたいとする。
ただし、同身長の人間がいる場合は出席番号の若い順に並んだままになっていて欲しい。
そういうときは「安定したソート」の出番よ。
クイックソートだと出席番号はバラバラになるからな。
まあ「安定した速度」って点でもマージソートはなかなかのもんだと思うけど
それにしても
35:デフォルトの名無しさん
05/11/11 13:36:35
それは、キーの指定が悪い。
36:デフォルトの名無しさん
05/11/11 13:47:58
>>31
基本情報の資格でも取ったほうがいいお
言葉が通じないと頭良くても吸収できないでしょ
37:デフォルトの名無しさん
05/11/11 20:59:00
>>35
ソートで大小の評価を、
身長だけではなく、出席番号も加味してやればいい
と言いたいのだろう。
でもね、出席番号がついてなかったら、どーするの?
38:デフォルトの名無しさん
05/11/12 02:14:44
一般的にソート前のインデックス順序を比較で使えばいい
二次キーとして出席番号があるならそれを使えばいいし
39:デフォルトの名無しさん
05/11/12 17:04:32
インデックスがついていなかったら?
40:デフォルトの名無しさん
05/11/12 18:46:58
アドレスで比較すればいいだろ馬鹿か？
41:デフォルトの名無しさん
05/11/13 16:52:40
アドレスで比較? なに馬鹿いってるの?
42:デフォルトの名無しさん
05/11/13 19:38:41
IntelのライブラリはAMDでワザと遅くなるようにしてそうなんで
一般向けには使ってません
43:デフォルトの名無しさん
05/11/14 02:57:33
高速なメモリコピーするにはmemcpy?
それともキャシュ無視するためにSSEとか利用するのか?
44:デフォルトの名無しさん
05/11/14 07:00:54
memcpyの実装はたくさんあるから一概には言えないぞ。
最もシンプルなのは1バイトずつコピーしているし、
コンパイラによってはインライン展開どころか組込み関数として処理しちゃうぞ。
45:43
05/11/15 02:12:42
へぇー、組み込み関数(SSE?)で処理しちゃうのか。
ネットで調べてたらSSEのレジスタ4つにまず読んで、それを
また4つ書き出すとレイテンシとやらを隠蔽できるとかなんとか
あったけどそんな感じかな。
とりあえずmemcpy使っておきます。
46:デフォルトの名無しさん
05/11/15 15:00:39
組込み関数の意味がわかってない希ガス。
47:デフォルトの名無しさん
05/11/15 17:17:53
関係ないけど __divdi3 は組み込み関数なんだろうか。
48:・∀・)っ-●◎○- ◆Pu/ODYSSEY
05/12/11 17:53:45
直にCPUの命令またはその組み合わせに展開してしまえる関数だね。
組み込み関数の利用は#pragma intrinsic で明示できるよ。
逆に出来ない場合は組み込み関数として用意されてないといえる。」
ぶっちゃけIntel C++のオートベクトライズなんてあんま役に立たない。
処理を並列化できるところは明示的にMMX/SSEの組み込み関数
使って最適化したほうがいい。
CPUの動きを知り尽くしてレジスタカラーリングしてくれるから
へたなアセンブリコード書くより速い。
あとIntel C++なんかは、インライン関数を基本的に展開しない。
STL使ったら重いってことは結構ある。
ただし __forceinliceは受け付ける。
VC2005はcpuidとかローテート命令まで組み込み関数として使える
ようになったから、アセンブラ嫌いにはかなりフレンドリーになった希ガス。
49:デフォルトの名無しさん
05/12/12 08:14:59
ローテートはVC6の頃から組み込み関数であった希ガス。
50:デフォルトの名無しさん
06/01/30 17:07:08
2005は8bit版や16bit版も用意されてる
URLﾘﾝｸ(msdn2.microsoft.com)(en-US,VS.80).aspx
51:デフォルトの名無しさん
06/02/13 23:04:16
￤
＼ |
＼ 人 ／
メ´ ヾ _,－'
－―＜ , -､ て＿
C++とSSE！ ) / / (´
/ / ⌒ ､
(⌒Ｖ ,'´｀ヽ
ﾄ､ ,ﾍ ヽ ! :〉
ﾄ､ヽ / /! / ､ﾞーｧ'
|,ﾉ ´￣｀ ヾ! / /｀~´
,' ＞ ＜ ﾞ, / /
l ､ー―:ｧ i/ /
ﾞ､ Ｙ⌒/ ,/ /
｀''ｧ‐`ｰ' /
/ i ／
52:デフォルトの名無しさん
06/02/14 09:28:47
だんごって何の仕事してんの？
53:デフォルトの名無しさん
06/02/14 17:36:10
.NEETでFA
54:デフォルトの名無しさん
06/02/17 12:53:20
倍精度実数、うらやましいなー
55:デフォルトの名無しさん
06/05/10 23:25:12
constで最適化が促進させられる理由ってなんでそ？
56:55
06/05/10 23:28:03
書き込むスレ間違えました。失礼しました。
57:デフォルトの名無しさん
06/06/03 15:41:51
[1] 授業単元： 数値計算法
[2] 問題文(含コード&リンク)： ①f (x) = cos (x) - x2 = 0 の根のうち、0 < x < 1 を満たすものを2分法で求める
初期値 a, b が入力でき、 6桁推定された解と関数 f (x) を呼びだした回数を出力するようにしなさい。
[3] 環境
[3.1] OS： WindowsＸＰ
[3.2] コンパイラ名とバージョン： VC 6.0
[3.3] 言語： C
[4] 期限： (2006年06月08日まで
よろしくお願いします
58:デフォルトの名無しさん
06/06/03 20:12:46
やべっ 二分法って何だっけ
忘れちゃったよ
59:デフォルトの名無しさん
06/06/03 21:02:27
>>58
カップラーメンを従来の1.5倍の速度で完成させる最適化技法
60:デフォルトの名無しさん
06/06/06 23:05:22
調理時間の短いラーメンほど短時間で伸びる
61:デフォルトの名無しさん
06/06/07 02:49:26
グルテンを加えるといい
62:デフォルトの名無しさん
06/06/08 20:36:36
麩になっちまう
63:デフォルトの名無しさん
06/06/11 01:52:05
即値で掛け算する場所を書き直してみたら？
64:デフォルトの名無しさん
06/06/11 13:36:33
PenMのSSE2って遅くね？
65:・∀・）っ-○◎● ◆toBASh....
06/06/11 14:11:11
デコーダがネック。複合デコーダパスだからね。
汎用＆MMレジスタベース命令と交互に配置するとデコーダネックを隠蔽できる。
Yonahでは解消されてる。てかめちゃくちゃスループットいい
66:デフォルトの名無しさん
06/06/11 21:19:38
じゃあPenMだったら無条件でSSE2不使用、ってコーディングはもうしちゃ駄目だね。
67:デフォルトの名無しさん
06/06/12 05:21:20
そもそもYonahな時点でPenMじゃないし。
つかPenMって3年前から更新されてない一昔前のチップだろ。
68:デフォルトの名無しさん
06/06/12 05:50:51
ド忘れされてるDothanとi915萌え
YonahもBanias、Dothanと同様Pentium-Mですよ。
ただ発表後にPentiumブランド消失と絡んでIntel Coreとも名付けられちゃったが。
ブランド展開がまだよく分からんのでこの先どうなるか知らんが
69:デフォルトの名無しさん
06/06/12 23:51:39
面白い話題なんでもっと調べたいんですが、
いい本ないでしょうか？
やっぱりパターソン＆ヘネシーですか？
70:デフォルトの名無しさん
06/06/20 21:14:25
メーカのドキュメント
71:デフォルトの名無しさん
06/10/12 18:47:05
SSEはコンパイラが自動的に使ってくれるのですか？
72:デフォルトの名無しさん
06/10/12 20:00:52
コンパイラによる。VCだとスカラ演算のみ。
自動ベクトル化が可能なコンパイラはgcc4.0系とかiccとかPGIとか。
73:デフォルトの名無しさん
06/10/20 02:49:00
SSEで最適化してもメモリアクセスのほうがボトルネックになんね？
キャッシュとかよく分かんねけどメモリよりキャッシュを意識せな
いかんのだろうけど。
74:デフォルトの名無しさん
06/10/20 03:06:04
処理の内容によるんじゃない？
動画の画像処理みたいにプリフェッチの予測が当たりやすい処理だと
メモリ帯域の方がボトルネックになってる感じはしない。
他の分野についてはわかりません。
75:デフォルトの名無しさん
06/10/20 03:50:56
>>73
同じデータを色々な組み合わせで何度も使う場合
キャッシュをうまく効かせるのが腕の見せ所。
76:デフォルトの名無しさん
06/10/20 09:13:41
誰かSSEのプリフェッチをどう使えばいいのかまとめてくれ。
77:デフォルトの名無しさん
06/10/20 14:58:09
めちゃくちゃ大雑把に話せば、
メモリを使う100クロック前くらいで
64byteごとに1回プリフェッチ命令を置く。
どの命令がいいかは、全部試して速いのを採用。
詳しくは、たくさんコードを書いてから
キャッシュについて勉強してくれ。
俺も勉強せねば・・・。
78:デフォルトの名無しさん
06/10/25 11:25:01
GPUと組み合わせ使うて場合って
GPUができる計算はみんななげちゃうって方針でいいの？
低次元行列計算はDirextXでできるみたいだから、
DirextXになげちゃおかと思ってるのだけど
79:デフォルトの名無しさん
06/10/26 03:45:06
>>78
DirectXは誰が動かしていると思っているの?
ユーザプロセスは?
OSカーネルは?
80:デフォルトの名無しさん
06/11/11 01:02:00
インテルのペンティアムプロセッサのマシン語で
高速化を勉強できる良い入門書みたいなのあったら教えてください
ホント、よろしくお願いします。
このとおり！m(_ _;)m m(-.-;)m m(_ _;)m
81:デフォルトの名無しさん
06/11/11 01:24:25
>>4
82:デフォルトの名無しさん
06/11/11 01:40:00
そうおっしゃらず。。
なにとぞ、お願いします～m(_ _;;)m
83:デフォルトの名無しさん
06/11/11 08:03:04
>>83
いやマジで、下手な本買うよりiccのアセンブラ出力眺めた方がよっぽど勉強になるって。
84:デフォルトの名無しさん
06/11/11 10:14:57
なるほど、そういう意味でしたか。
85:デフォルトの名無しさん
06/11/11 12:12:26
>>80
MMXテクノロジ最適化テクニック(ISBN4-7561-0797-4)の5章
86:80
06/11/11 22:35:35
>>85さん、ありがとうございます。
早速書店で探してみます。m(_ _)mﾍﾟｺﾘ
87: 【凶】 【488円】
07/01/01 10:52:18
SSEでどこか参考になるサイトはありませんか？
88:デフォルトの名無しさん
07/01/01 12:07:08
つ[google]
89:デフォルトの名無しさん
07/01/08 18:18:09
最近のコンパイラはSSEなどは指定しなくても自動的に使ってくれるのでしょうか？
90:デフォルトの名無しさん
07/01/08 18:30:46
ではまず最近のコンパイラの定義から（ｒｙ
91:デフォルトの名無しさん
07/01/08 18:32:37
>>89
そういうコンパイラもあります。
92:デフォルトの名無しさん
07/01/08 18:34:43
インテルコンパイラです
93:デフォルトの名無しさん
07/01/08 18:36:58
自動的に使うようになってると、SSEがないCPUでは動作しないのでは。
94:デフォルトの名無しさん
07/01/08 18:59:08
O3を指定した場合、自動的に検出され使われる
95:デフォルトの名無しさん
07/01/08 19:03:58
_ ∩
( ﾟ∀ﾟ)彡 オッサン！オッサン！
⊂彡
96:デフォルトの名無しさん
07/01/08 19:07:29
ここってこんなに人居たんだ
97:デフォルトの名無しさん
07/01/08 19:28:09
>>95
オマイの駄洒落のほうが・・
98:・∀・）っ-{}@{}@{}@
07/01/08 20:10:18
/Qx*とか/Qax*なしで使うことってあったっけ？
とりあえずboost:mt19937はICCのオートベクトライズでやたら速くなるが
99:デフォルトの名無しさん
07/01/08 20:31:21
Auto-vectorization in GCC
URLﾘﾝｸ(gcc.gnu.org)
100:デフォルトの名無しさん
07/01/08 20:47:28
AMD64向けだと強制的に使ってくれる。
自動ベクトル化は知らん。
101:サイザー専用JAVA演習場 その２
07/01/08 21:17:02
次スレまできた。飽きっぽい俺が良く続くもんだ。Σ(´∀｀;)
どうぞよろしくお願いします。
102:デフォルトの名無しさん
07/01/29 08:23:39
URLﾘﾝｸ(www.intel.co.jp)
ここにあるインストラクションセット表って、
SSE3以降のものも載ってます？
103:デフォルトの名無しさん
07/02/07 20:57:03
SSE3は載ってたと思う。SSSE3は知らん
104:デフォルトの名無しさん
07/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
07/02/10 01:07:28
BaniasかDothanかYonahかにもよるけど、SSEはあんまり得意じゃないよMは
106:104
07/02/10 16:29:40
>>105
Dothanコアです。
MはSSEが得意ではないのですね。参考になりました。
参考までに、姫野ベンチでも実験したところ、こちらは-mfpmath=sseありの方が速かったので、
コードに依るかも知れません。
107:・∀・）っ-○◎● ◆DanGorION6
07/02/10 21:00:29
Pentium M系アーキテクチャでSSE*が遅いのはデコーダがネックになってるらしい。
Complex Decoderのみでデコードされるから、倍精度は浮動小数が速くても不思議じゃない
Pentium MのFPUは加減算・乗算毎に倍精度×１、単精度×2だけど
x87とSSEスカラ演算だと単精度はクロックあたり1、SSEのパックド演算だと2つは
発行できるから、単精度ならまだ使う価値があるね。
108:デフォルトの名無しさん
07/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:デフォルトの名無しさん
07/02/12 16:51:08
んでもSSE使うように最適化オプションつけた方が
遅くなるってのは不思議だよなぁ。
早くならないってことはあっても遅くなるってのはなぁ・・・
タスクスイッチのときにXMMレジスタも全部退避するようになるから？
そういやXMMレジスタまで対比するか否かってOSはどうやって知ってるの?
110:デフォルトの名無しさん
07/02/12 16:58:01
>>109
そもそも初期状態でFPUセットになっているのなら、SSEを使うだけで切り替えコストが発生する。
111:・∀・）っ-○◎● ◆DanGorION6
07/02/12 17:01:00
まあ、Complexデコーダパス命令だから、の一言なんだが
待避のオーバーヘッドなんてたかがしれてる
MXCSRレジスタってあるじゃん
112:・∀・）っ-○◎● ◆DanGorION6
07/02/12 17:01:45
>>110
それXMMレジスタじゃなくてMMレジスタの話では
113:デフォルトの名無しさん
07/02/12 17:41:09
でもSISDならデコードも速い。
単純にコンパイラが最適化しきれてないだけじゃないのか。
そもそも104氏が何の処理をさせてたのか書いてないから
イマイチ議論のしようがない気もする。
おそらく人間が書けばDothanでもSSEの方が速いとは思う。
114: ◆0uxK91AxII
07/02/12 21:16:30
>>109
＞XMMレジスタまで対比するか否か
URLﾘﾝｸ(hira.main.jp)()%2Flinux2.6
115:・∀・）っ-○◎● ◆DanGorION6
07/02/17 17:12:17
Core 2 (Merom)ベースのCeleron Mももう出たし
116:デフォルトの名無しさん
07/02/19 20:47:39
二つの符号付及び符号無し 64bit 整数の乗算、
さらには 128bit 整数同士の乗算などは
SSE/SSE2/SSE3 命令群を使うことで高速化できるのでしょうか？
そもそもこれらの命令は SIMD 目的であって
ビット幅の長い演算が目的ではないので、
見当違いでしょうか？
117:・∀・）っ-○◎● ◆DanGorION6
07/02/20 00:30:25
64ビット同士の整数乗算は素直にｘ64命令セット使えと思うが。。。
16×16の積算・積和演算があるから組み合わせればいくらでも可能だ罠
118:デフォルトの名無しさん
07/02/21 14:03:24
海外旅行での現地のATMでのキャッシングって、
キャッシング枠ですか？それともショッピング枠ですか？
以前現金主義の友人がどうしても両替商見つからなくて
現地のATMでキャッシングしたら、日本に帰ってきて
ショッピングとして明細に出てたって聞いたんですが。
119:デフォルトの名無しさん
07/02/21 15:09:23
>>118
ATMによる。スレ違い。
120:デフォルトの名無しさん
07/02/25 13:31:40
誤爆じゃないのか
121:デフォルトの名無しさん
07/03/02 21:40:36
浮動小数点モデルを /fp:fast にする
精度は落ちるが
122:デフォルトの名無しさん
07/03/03 09:27:27
マルチタスク/マルチスレッドで、セマフォを長時間握ったまま返さない奴とか見つける、とかは
やっぱプロファイラとかで動的解析しないと分らんよね。
そんなの静的解析でどうにかなるもんじゃないか・・・。
123:デフォルトの名無しさん
07/06/04 18:02:04
doubleは2つ同時にしか実行できないのか？
124:デフォルトの名無しさん
07/06/04 18:08:28
>>123
日本語よろ！
125:デフォルトの名無しさん
07/06/04 18:54:23
だぶる先生らいふのことだろ。
常識的に考えて。
126:デフォルトの名無しさん
07/09/28 23:10:54
ダブル先(の)生ライフ？
127:デフォルトの名無しさん
07/10/01 19:33:27
>>123
C++でおｋ
128: ◆0uxK91AxII
07/10/01 23:04:52
>>123
一つのみも可。
ex) addsd
129:デフォルトの名無しさん
07/12/31 11:50:57
下がり過ぎ
130:デフォルトの名無しさん
08/11/08 21:50:37
SSEで大部分が記述された
正規表現エンジンって知りませんか？
131:デフォルトの名無しさん
08/11/09 00:12:17
闇雲にSSEを使えば速くなるってもんじゃないし、そんな阿呆な代物ないでしょ。
# 速度に寄与する肝腎な箇所に使っているってことなら話は別だが。
132:デフォルトの名無しさん
08/11/09 01:43:59
sseで正規表現・・・どこで使ったものやら
133:デフォルトの名無しさん
08/11/10 14:07:10
SSEって並列処理や積和なんかが1命令化で速くなる。
端からデータを舐めていくような処理はあまり効果ないよ。
特に検索には向かない。
134:デフォルトの名無しさん
08/11/10 14:17:20
bit列のマッチングはどう？
1bitずつずらしたのをxorしてall 0になったかどうか調べるとか
135:デフォルトの名無しさん
08/11/10 21:40:31
strlenをSSE2でやる人がいるくらいだし、その応用でstrchr/strstrのような単純な検索はできると思う。
ただ、正規表現となるとうまく使うのは難しいと思う。
136:デフォルトの名無しさん
08/11/18 03:23:27
sse4.2じゃないのか
137:,,・´∀｀・,,）っ-●◎○
08/12/21 11:48:46
固定文字列部分を抽出してBoyer-Moore法とかで検索するのが良く使われる方法。
strstrなんかはSIMDを使った力技検索に置き換えることができる。
>>136
確かにあれは速いようだ
138:,,・´∀｀・,,）っ-●◎○
08/12/21 11:51:30
固定文字列部分ならともかく「大部分」をSIMDに置き換えることに意味はない。
文字クラス程度ならSSE4.2で一括判定みたいなのも可能になるかと思うけど
139:デフォルトの名無しさん
08/12/21 12:13:43
つうかそんなのAltiVecでとうの昔にやられてる事だしな。
Intelは必要な命令(シャッフル、MIN/MAXなど)が揃うまでにどれだけかかるんだ。
ルーチンごとにSSE1があるか、2があるかと判定しなくちゃいけなくて面倒くさい。
140:,,・´∀｀・,,）っ-●◎○
08/12/21 12:18:35
Macのこと言ってるのか？
SSE3以上使える前提できめうちで組めるからかえって楽だろｗ
大体にAltiVecに文字列比較命令なんてねーよ。
汎用レジスタ－SIMDレジスタ間のダイレクト転送命令ないし
レジスタ値を比較してbranchフラグを更新する命令もない。
そもそも更新が停まってるだけだろ。
141:,,・´∀｀・,,）っ-●◎○
08/12/21 12:30:26
SSE2の16バイト単位の文字列同時比較なんてこれだけだぞ
（MMX(SSE)での8バイト同時比較でもこいつの64bit版を使えばいい）
pcmpeqb → pmovmskb → test → branch
SSE4.1だと
pcmpeqb→ptest→branchでおｋ
AltiVecだとpmovmskb相当のことをMSBの縮約いちいちマスク＆シフトを繰り返した上
いったんメモリにストアしてから汎用レジスタで読み直さないといけない。
pmovmskbなんてIntelプロセッサでは1サイクルでこなせる処理だがAltiVecなんて
ここだけで何十サイクルもかかる。
なにかと俺がコケにしてるCell SPEのほうがまだ使えるよ。
SPUにはMSBじゃなくてLSBのビット縮約命令がある。
要するに
AltiVec＝保守されてない時代遅れの命令セット
俺も使ってたからよくわかるよ。
142:,,・´∀｀・,,）っ-●◎○
08/12/21 12:47:01
俺の経験上文字列サーチでAltiVec使うと遅くなるケースのほうが多い。
だからMacOSでもstrcpy/memcpyみたいな分岐の必要ない操作に限ってだけAltiVecが内部的に使われてる。
143:デフォルトの名無しさん
08/12/21 13:31:59
同時比較でいいならロードして比較してvec_all_eq()するだけじゃね？
ストアと読み出しはいらん。
144:,,・´∀｀・,,）っ-○◎●
08/12/21 18:51:16
＞vec_all_eq()
あのさー、それ複合関数だから。
ではマスク生成＋縮約＋ストア＋汎用レジスタにロードって操作を1つの組込関数に纏めただけ。
1インストラクションで済んでるわけではない。
アセンブリコード読んだことある？無いだろうけど。
CPUネイティブのベクトル比較命令であるvcmpequb自体は、SIMDレジスタ上にマスクを生成するのみ。
マッチしたのか、マッチしてないのか、マッチした場合、どこの位置でマッチしたのかっていう判定は
汎用レジスタ側でやるしかないんだよ。
145:デフォルトの名無しさん
08/12/21 19:51:08
お前こそvcmpequbの仕様を読んだ事あるのかと。
> The CR6 is set according to whether all, some, or none of the elements compare equal.
146:デフォルトの名無しさん
08/12/21 19:59:03
最近論調がおとなしくなってきて改心したのかと思えば、
内心人を見下してるのは変わってないんだよな。
147:デフォルトの名無しさん
08/12/21 20:04:05
あ、なんでアセンブリコードとか的外れな事言ってるのかようやく分かった。
最適化オプションを全く指定しないと確かに複合になるね。
ていうかさあ、デバッグ用とはいえ確かにこのアセンブリは変態だけど
つまりはお前は大口たたいておきながら
その実>>143を言われて顔真っ赤にして焦ってアセンブリ出力を確認したんだろ。
恥ずかしいなあ。
148:,,・´∀｀・,,）っ-○◎●
08/12/21 20:06:12
「.」付き版はcr6を更新するからptest相当のことだけはできるよ。それは正しい。
どこでマッチしたかを求めるには汎用レジスタ側でやんないといけない。
pmovmskb相当の命令がないから遅いんだって。
Cell SPEだと7ビットシフトしてギャザリングし、ビットスキャンすれば位置が求まるけど
149:,,・´∀｀・,,）っ-○◎●
08/12/21 20:07:28
>>147
で、pmovmskbの代用命令はどこにあるの？
150:デフォルトの名無しさん
08/12/21 20:08:21
っヒント:もうL1に乗ってる
151:デフォルトの名無しさん
08/12/21 20:09:45
>>149
無いよ。
そこを叩きたいなら叩いてくれ。
152:,,・´∀｀・,,）っ-○◎●
08/12/21 20:11:31
そんなことは聞いてない。
SSE*にはSIMDレジスタ上のベクトルデータのMSBを縮約してダイレクトに汎用レジスタに転送する命令がある。
bsfと組み合わせればマッチ位置まで簡単に求めることができる。
AltiVecには、そういう命令は、ない。
153:,,・´∀｀・,,）っ-○◎●
08/12/21 20:12:47
>>151
なら結局遅いじゃん。
154:デフォルトの名無しさん
08/12/21 20:15:38
支離滅裂だな。
それが初めから分かってるなら慌ててアセンブリ確認なんてしてないだろ。
百歩譲って今お前が力説したい事にスポットを当てるなら
all_xx()が複合であるかどうかなんてどうでもいいんだからな。
ていうかstrchなのかstrstrなのかハッキリしろよ。
反論するのに都合の良い方を選択してるだけじゃねーか。
155:,,・´∀｀・,,）っ-○◎●
08/12/21 20:16:13
慌ても確認もしてないよ
156:デフォルトの名無しさん
08/12/21 20:17:49
じゃあall_xxが複合だと言ったのはどこのだれですか？
結局gather出来ないんだから、そこはどうでもいいんだけどね。
157:,,・´∀｀・,,）っ-○◎●
08/12/21 20:19:12
>>154
どっちもSSEより遅いよ。
PPCからの移植にSSE1まで使えるか2まで使えるかとか気にしなきゃいけないと思う方が馬鹿だよ。
Win32でもSSE2が使えないCPUなんてどのみちSIMDユニットの実装もショボイから最適化対象としては無視して良いくらいだよ。
非SIMDのパスに飛ばしておけばいい。
158:デフォルトの名無しさん
08/12/21 20:22:57
まあそれも論点ずれてるんだが、建設的な話をしたいからお前に合わせよう。
確かにSSE2が使えないCPUは大抵しょぼいから無視しても良いんじゃないかな。
強いて言うならAMD(笑)が例外だが。
でもx86陣営がそういう路線を歩んでいるのは間違いなくて
SSE3, SSSE3, SSE4.1, SSE4.2, AVX, LNIといちいちチェックしなくてはいけない日々が続く事には変わりない。
159:デフォルトの名無しさん
08/12/22 00:20:05
Core2 Duoと比較して、Athlon X2がそれほど酷いとは思えないんだけど。
160:デフォルトの名無しさん
08/12/22 00:39:51
整数演算はひどいな
161:デフォルトの名無しさん
08/12/22 12:59:27
一晩考えて、何故団子がgatherに必死なのかが分かった。
団子はトリップ検索が主だから検索対象が極端に小さくて、
詳細な位置の特定の方がボトルネックになっているんだな。
162:,,・´∀｀・,,）っ-○◎●
08/12/22 18:05:57
tawake
163:デフォルトの名無しさん
08/12/22 18:42:38
続きをどうぞ
164:デフォルトの名無しさん
08/12/23 01:34:18
>>161
誰が笑いを取れとｗ
165:デフォルトの名無しさん
08/12/24 07:45:53
変な事言った？
166:,,・´∀｀・,,）っ-○◎●
08/12/24 19:00:25
一晩考えることじゃないだろ。俺のブログ一通り読んだら30分以内に否定される。
167:デフォルトの名無しさん
08/12/24 20:19:04
で？
168:,,・´∀｀・,,）っ-○◎●
08/12/24 20:52:06
笑いしかとれなかったね
169:デフォルトの名無しさん
08/12/24 23:46:08
そうだね。俺もだけど団子も痛い子だね。
170:デフォルトの名無しさん
08/12/25 00:24:23
痛いのはお前だけですからｗｗｗ
171:デフォルトの名無しさん
08/12/25 00:39:33
だから何故？
煽ってるんじゃなくて純粋に。
172:デフォルトの名無しさん
08/12/26 19:45:57
無知のまま過ごすのは恥だし勿体ないので団子でも名無しでも回答くれないかな。
名無しが答えられるかどうかは疑問だけど。
173:デフォルトの名無しさん
08/12/26 20:29:55
∩＿＿＿∩
. ＼ | ノ ヽ
＼ / ● ● |
＼| ( _●_) ミ そんなエサでおれが釣られるかクマー！
彡､ |∪| ,/..
ヽ ヽ丿/ /⌒|
/ ＼＿＿ノﾞ＿/ / =====
〈 _ノ ====
＼ ＼＿ ＼
＼＿__） ＼ ====== (´⌒
＼ ＿＿_ ＼＿＿ (´⌒;;(´⌒;;
＼＿＿＿）＿＿＿）(´;;⌒ (´⌒;; ズザザザ
174:デフォルトの名無しさん
08/12/27 07:45:25
都合が悪くなるとすぐ逃げるか話そらすからな。
結局161が図星だったのか。
175:デフォルトの名無しさん
08/12/27 10:20:33
名無しが寂しそうにしてるから構ってやれよｗ
176:デフォルトの名無しさん
09/01/04 11:41:54
ビット演算の代数的な性質、それを導き出す公理が知りたい
算術演算から式変形だけでアセンブリ言語のコードを導き出せるようになりたい
177:デフォルトの名無しさん
09/01/04 12:31:09
コンパイラでも作りたいの?
178:デフォルトの名無しさん
09/01/07 23:00:55
メモリアクセスとかを考慮すると構造体より配列のほうが高速？
179:デフォルトの名無しさん
09/01/08 00:02:43
>>178
同じ。
180:デフォルトの名無しさん
09/01/08 00:13:42
SSE2でnビット左rolってどうやって記述すればいいのですか？
181:デフォルトの名無しさん
09/01/08 00:34:34
Intelのマニュアル読みなさい
182:,,・´∀｀・,,）っ-○◎●
09/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:デフォルトの名無しさん
09/01/08 11:55:57
俺の質問には答えずに人の質問には答えるんだな。
要素ごとのは、例えば最上位に立っているビットからNビット欲しいとか色々使い道はあるよ。
floorみたいのを自力で実装しようとすれば分かる。
184:,,・´∀｀・,,）っ-○◎●
09/01/08 12:46:20
サーセンｗｗｗpandじゃなくてporだｗｗｗ
185:デフォルトの名無しさん
09/01/09 14:29:17
>>179
うほ？
>>178の意味がいまいち分からんが、
char array[0x100];
と
struct{char value;} array[0x100];
だったらレジスタサイズにパディングされる分、構造体の方が早くね？
ちなみに、同じ事だが容量気にして構造体のなかでshortとか使うと
パデイング入るんでメモリに無駄が発生する。
まぁ、パディングを知っていれば無駄を防ぐこともできるけど。
186:デフォルトの名無しさん
09/01/10 05:48:58
構造体にすればパディングされると決まっているわけではない。
だからその例だけだとどちらとも言えない訳だが。
構造体のメンバを一部だけshortにするのは意味が殆どない(寧ろ遅くなる)という点については同意。
187:デフォルトの名無しさん
09/01/11 01:26:48
>>185
short array[3];
と
struct{short value1;short value2;short value3;} array;
でどっちが高速かという意味です。
188:デフォルトの名無しさん
09/01/11 01:44:37
配列のindexが定数なら変わらんだろ
アセンブラ見ろ
189:デフォルトの名無しさん
09/01/11 01:50:19
>>185
> struct{char value;} array[0x100];
> だったらレジスタサイズにパディングされる分、構造体の方が早くね？
pragmaやattributeでパックしない限りpaddingは入らないだろ。
190:,,・´∀｀・,,）っ-●◎○
09/01/11 06:03:24
16とか32になるのはいいけどメモリアドレッシングで使えるscaleが8倍までなんだよな。
添字によるアクセスは思わぬ性能低下を起こすことがある
191:,,・´∀｀・,,）っ-●◎○
09/01/11 06:05:36
>>189
構造体やその配列の場合、パディングが入る。
デフォルトが4バイト単位だったかな？
192:デフォルトの名無しさん
09/01/11 10:18:30
おまえほんとにだんごか？
デフォルトなんて決まってるわけ無いだろ
193:,,・´∀｀・,,）っ-●◎○
09/01/11 10:25:51
まあデフォルト値は処理系依存だな。
>>189の言ってることが嘘ってことで。
少なくともパディングが入らない保障はない。
194:デフォルトの名無しさん
09/01/11 10:51:19
コンパイラ依存だよな。
歴史的な理由で当時の最長のレジスタがdoubleだからCPUのアライメントが8byte推奨で、コンパイラも8byteに詰めてた気が。
もしかしたらx86じゃなくてPowerPCかも知れん。
195:デフォルトの名無しさん
09/01/11 14:47:57
VCやGCC辺りはパディングが入る。
Bitmapヘッダをそのまま構造体で読み取ろうとして引っかかった
やつも少なくない筈。(VCならpragmaを使えばパディングを消すことができる)
一応32bitCPUならVC、GCC共にcharもshortも32bitで確保される。
64bitなら64bitで確保されるとか聞いたことがあるが真偽は不明。
蛇足だが、VCでchar array[5];などと確保すると確保した容量+3
の領域が確保される。
196:デフォルトの名無しさん
09/01/11 15:41:20
URLﾘﾝｸ(kikyou.info)
> つまり最大でポインタ二つ分のデータを保持しています。LP64の場合は128bitとなります。ILP32の場合は64bitとはならず、パディングの関係でLP64と同じく128bitとなります。
8byte？
197:デフォルトの名無しさん
09/01/11 15:44:14
将来AVXの1024bit SIMDが使えるようになった際に、128byteにパディングされるとかなるとイヤだな。
その頃にはメモリは数十GBで128byteなんてゴミみたいなもんだろうけど。
198:,,・´∀｀・,,）っ-○◎●
09/01/11 15:47:54
その頃までにSIB.scaleのビット拡張してほしいね。1ビット増やせばx16, x32, x64, x128になるのに。
199:デフォルトの名無しさん
09/01/11 15:59:23
＼ ＼＼ ＿＿＿＿ ／／ ／ ／
＜ _-=≡:: ;; ヾ＼ ＞
＜ ／ ヾ:::＼ ＞
＜ | |::::::| ＞
＜ ﾐ|-=≡、 ミ≡==- 、 |;;;;;/ ＞
＜ || <・>|￣| <・> |─ /＼ ＞
＜ |ヽ＿/ ＼＿／ > / ＞
＜ / ／( )＼ |_/ ＞
＜ | | ｀ ´ ） | ＞
＜ | ＼/ヽ／＼＿／ / | ＞
＜ ＼ ＼￣￣ ／ヽ / / ＞
＜ ＼ ￣￣ ／ ／ ＼ ＞
／ ／ ￣￣￣￣￣￣￣ ＼＼ ＼ ＼
＿__
／ ―＼ ﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳ
／ノ (＠)＼ ﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷ
.｜ (＠) ⌒）＼ ﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯ
.｜ （__ノ￣| | ///;ﾄ, ﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮ
＼ |＿／ / ////ﾞlﾞl; ﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮ
＼ _ノ l .i .! | ﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮ
/´ ｀＼ │ | .| ﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮ
| | { .ﾉ.ﾉ ﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳﾅﾝﾐｮ
| |../ / . ﾅﾝﾐｮｳﾎｳﾚﾝｹﾞｯｷｮｳ
200:デフォルトの名無しさん
09/01/12 00:40:28
パディングってむやみに入れるとキャッシュヒット率悪くなってかえって効率落ちたりしないんだろか
201:,,・´∀｀・,,）っ-●◎○
09/01/12 00:42:04
逆にキャッシュラインを跨ぐと効率悪くなるんだよ
202:デフォルトの名無しさん
09/01/12 00:44:50
>>200-201
どっちも一般論だー
場合によるでしょ
203:デフォルトの名無しさん
09/01/12 00:58:25
実測すれば済む話
204:デフォルトの名無しさん
09/01/12 01:11:32
>>191
cygwin上のgccで試してみたけど、padding入らないよ
205:デフォルトの名無しさん
09/01/12 13:59:38
>>204
CPUによるが
struct foo {
char a;
double b;
};
でパディングが入らなかったら例外起きるだろうが。
206:デフォルトの名無しさん
09/01/12 14:41:55
起こんねーよ、CPUによるが。
207:デフォルトの名無しさん
09/01/12 14:55:43
struct {char a, b, c;}だったらパディングなくても例外起きないよ。
コンパイラがまともなら。
208:,,・´∀｀・,,）っ-○◎●
09/01/12 17:32:33
アラインメント制約の厳しいプロセッサなら、例外が起きないようにコンパイラが勝手にパディングするんじゃないかな。
しかしミスアラインメントのデータに対するロード・ストアの扱いは各CPUアーキ毎に方針が違ってて面白いな
x86のSSE以降は、ミスアラインメントを許すが遅い命令と、許さないが高速な命令の2通りを用意。
対して、POWER/CellのSIMDは下位ビットを無視してロードし、プログラマが勝手にPermuteしてくれっていう扱い。
209:デフォルトの名無しさん
09/01/12 18:31:15
下位ビットを無視してくれるのはわざわざAND取ってアライメントする必要がないから楽でいいよな。
210:デフォルトの名無しさん
09/01/12 18:38:09
中を作る側もデコーダが軽くなるからｳﾏｰ
211:デフォルトの名無しさん
09/01/13 01:17:59
>>205
> >>204
> CPUによるが
> struct foo {
> char a;
> double b;
> };
> でパディングが入らなかったら例外起きるだろうが。
なぜ勝手にdoubleが入ってるんだww
誰もそんな場合の話はしていない。
団子にこんな基本的なことで嘘つき呼ばわりされたが嘘じゃないってことで
>>185
> struct{char value;} array[0x100];
212:デフォルトの名無しさん
09/01/13 01:46:59
ところでパディングの入らない環境ってどんな環境だろ？
PC用で32bitプロセッサじゃ大抵入ると思うが。
sizeof(struct{char value;})==4
見たいにね。
213:デフォルトの名無しさん
09/01/13 02:10:47
struct{char value;} array[0x100];
printf("%d\n", sizeof(array));
=> 256
gcc-4.3.2ではこうなったけど、パディングってそもそも何だ?無効領域?
214:デフォルトの名無しさん
09/01/13 02:48:14
>>212
Crayだとchar=short=int=32bitとかが普通らしい。
PC用じゃないけど。
215:デフォルトの名無しさん
09/01/13 17:31:55
>>213
ゴメン
sizeof(struct{char value;})じゃ1だね。
sizeof(struct{char v1;short v2})じゃ4になったから試さずに
書いちゃった。メンバーが同じサイズなら配列化されるっぽいね。
216:デフォルトの名無しさん
09/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:,,・´∀｀・,,）っ-○◎●
09/01/13 21:09:54
俺的に配列は__declspec(align(32))がデフォです
218:デフォルトの名無しさん
09/01/13 21:34:41
32？
16じゃないのか？
219:,,・´∀｀・,,）っ-○◎●
09/01/13 23:06:38
AVX化を視野に入れてるから
220:デフォルトの名無しさん
09/01/14 08:14:08
Alphaには16bitレジスタなかったよん