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

このエントリーをはてなブックマークに追加
1デフォルトの名無しさん
C++やインラインアセンブラ、SSEなどによる高速化の手法
について語りましょう。
2デフォルトの名無しさん:2005/10/27(木) 03:00:35
まずはi++は++iにしろよ。
3デフォルトの名無しさん:2005/10/27(木) 03:02:26
それで速度があがるならな
4デフォルトの名無しさん:2005/10/27(木) 03:07:02
Intelのコンパイラ買って開発したほうがいいんじゃね?
ヘタに素人が最適化なんてやるより
5デフォルトの名無しさん:2005/10/27(木) 03:07:39
アルゴリズムよりメモリアクセスが最大のボトルネックだったりする。
結局レジスタやキャッシュを意識するのが重要になってくる。
6デフォルトの名無しさん:2005/10/27(木) 03:09:50
>>4
コンパイラを変えるんじゃなくてパフォーマンスの解析ツールを
買わないとダメじゃないかな。
コンパイラ自体はVC7も用途によっては悪くないし。
7デフォルトの名無しさん:2005/10/27(木) 03:14:21
>>6
VC++はプロファイラがついてると思うが
8デフォルトの名無しさん:2005/10/27(木) 03:14:44
今月のCマガ買って読め。
9デフォルトの名無しさん:2005/10/27(木) 03:21:52
STL使うなら自分で同じような物を作ったほうが高速。
10デフォルトの名無しさん:2005/10/27(木) 03:24:25
その心は?
11デフォルトの名無しさん:2005/10/27(木) 03:26:35
なんでいきなりSTLが・・・
12デフォルトの名無しさん:2005/10/27(木) 04:41:40
主要部分をasmで書き直せばOK
13デフォルトの名無しさん:2005/10/27(木) 05:59:50
>>7
VC++のプロファイラは、普通に一通りの機能を備えているのに、使われないんだよね。

VC.NET用だと、Compuware(Numega)がプロファイラを無償で提供してくれてるよ。
VC++6.0まで、TrueTimeは売り物だったのにねぇ。
14デフォルトの名無しさん:2005/10/27(木) 06:01:00
>1
>>12

インラインアセンブラよりも、組込み関数を使ったほうがいいことが多い。
・コンパイラが最適化をしてくれる
・プログラムの記述が楽で、修正しやすい。
という2つの大きなメリットがあるよ。
15デフォルトの名無しさん:2005/10/27(木) 06:01:56
なおVC系の場合、
組込み関数をインライン展開する
というオプションを有効にしてしまうと、
インライン展開されてしまい、最適化されない
という直感的ではない結果になるので、確認しながらやりましょう。
16デフォルトの名無しさん:2005/10/27(木) 06:02:27
VCにプロファイラがあるなんて気づかなかった
というか2chで聞いたら無いっていわれてずっと信じてた
17デフォルトの名無しさん:2005/10/27(木) 06:09:25
VC7でなくなったんだっけか
18デフォルトの名無しさん:2005/10/27(木) 11:13:28
>>13
>使われないんだよね。
GUIに罠が仕掛けてあるからじゃまいか?
19デフォルトの名無しさん:2005/10/27(木) 11:23:51
SSE2が付いてるマシンではインラインアセンブラで書かれた処理を実行したいけど、
それ以外のマシンでは普通のC++で書かれた処理を実行したいと言うような場合、
どうすればいい?
20デフォルトの名無しさん:2005/10/27(木) 11:25:47
開始時に判別して関数ポインタで入れ替え
21デフォルトの名無しさん:2005/10/27(木) 11:29:20
やっぱそれしかないか。
関数のインライン化されにくいなぁとか、
C++のメンバ関数だと面倒だなぁとか思ったんで。
22デフォルトの名無しさん:2005/10/27(木) 12:25:13
>>21
インスタンスをやたら作る必要が無いならファクトリーパターンで作り分けしてもらうという逃げ方もある。
23デフォルトの名無しさん:2005/10/27(木) 16:10:52
んなややこしいことしなくても、マクロ使って1つのソースから2つのオブジェクトを吐かせればいい。

関数ポインタだってコストかかるので、1つずつの関数を切り替えるのではなく、
2通りのプログラムを1つのプログラムに押し込むくらいの気持ちで、
もっとmain関数に近いところから切り替えてしまおう。
24デフォルトの名無しさん:2005/10/27(木) 23:22:49
インテルコンパイラってプリフェッチ命令を挿入するとか言ってるけど
プリフェッチって入れても効果ほとんど無いよね?
あとこれからPen3コアをベースにしたCPUになっていくからPen4用に
最適化はしないほうがいい?
25デフォルトの名無しさん:2005/10/27(木) 23:26:27
>>24
場合によるだろ。prefetch命令はL2へのロードのアルゴリズムを
変更するので、場合によってはメモリのレイテンシを劇的に減らす
事が出来る。というかintelのpdf嫁。
26デフォルトの名無しさん:2005/10/28(金) 03:13:27
prefetch命令を使って具体的に速度改善を説明する本とかないのかな。
サンプルコードとか載せてるのがあったら欲しい。
Webでも以外と情報無いし。
27デフォルトの名無しさん:2005/10/31(月) 20:11:01
STL like Template based coding with MMX/SSE extension
http://www.codeproject.com/useritems/STL_like_coding_with_MMX.asp

Intel IPP
Iten OpenCV
そのまま使えば高速じゃん
28デフォルトの名無しさん:2005/11/10(木) 03:07:31
>>27
なんだこれ。
マトリクスとかImageとか扱えるものなのか。
結構みんな使ってるんだろーか。
29デフォルトの名無しさん:2005/11/10(木) 05:49:34
クイックソート以外の例えばマージソートやバルブソートなどはどのようなときに使うのでしょうか?
30デフォルトの名無しさん:2005/11/10(木) 07:43:42
>>29
クイックソートは万能ではない。
特にソートする要素数が少ないときには他の方法が早い。
また、安定でないという欠点もある。(マージソートは安定)
31デフォルトの名無しさん:2005/11/11(金) 01:17:48
>>29じやないんだが
>また、安定でないという欠点もある。(マージソートは安定)

これどーゆー意味なんよ?
高速化のスレだから速度の事を言ってるのか?
32デフォルトの名無しさん:2005/11/11(金) 01:53:10
>>31
ソートで不安定といったら
比較関数の評価で重みが重複した場合に順序関係が保存されない
ことだと思うが…(;´Д`)
33デフォルトの名無しさん:2005/11/11(金) 07:49:51
34デフォルトの名無しさん:2005/11/11(金) 13:33:13
出席番号順にソート済みの身体測定データを身長順にソートしたいとする。
ただし、同身長の人間がいる場合は出席番号の若い順に並んだままになっていて欲しい。
そういうときは「安定したソート」の出番よ。
クイックソートだと出席番号はバラバラになるからな。

まあ「安定した速度」って点でもマージソートはなかなかのもんだと思うけど
それにしても
35デフォルトの名無しさん:2005/11/11(金) 13:36:35
それは、キーの指定が悪い。
36デフォルトの名無しさん:2005/11/11(金) 13:47:58
>>31
基本情報の資格でも取ったほうがいいお
言葉が通じないと頭良くても吸収できないでしょ
37デフォルトの名無しさん:2005/11/11(金) 20:59:00
>>35
ソートで大小の評価を、
身長だけではなく、出席番号も加味してやればいい
と言いたいのだろう。

でもね、出席番号がついてなかったら、どーするの?
38デフォルトの名無しさん:2005/11/12(土) 02:14:44
一般的にソート前のインデックス順序を比較で使えばいい
二次キーとして出席番号があるならそれを使えばいいし
39デフォルトの名無しさん:2005/11/12(土) 17:04:32
インデックスがついていなかったら?
40デフォルトの名無しさん:2005/11/12(土) 18:46:58
アドレスで比較すればいいだろ馬鹿か?
41デフォルトの名無しさん:2005/11/13(日) 16:52:40
アドレスで比較? なに馬鹿いってるの?
42デフォルトの名無しさん:2005/11/13(日) 19:38:41
IntelのライブラリはAMDでワザと遅くなるようにしてそうなんで
一般向けには使ってません
43デフォルトの名無しさん:2005/11/14(月) 02:57:33
高速なメモリコピーするにはmemcpy?
それともキャシュ無視するためにSSEとか利用するのか?
44デフォルトの名無しさん:2005/11/14(月) 07:00:54
memcpyの実装はたくさんあるから一概には言えないぞ。

最もシンプルなのは1バイトずつコピーしているし、
コンパイラによってはインライン展開どころか組込み関数として処理しちゃうぞ。
4543:2005/11/15(火) 02:12:42
へぇー、組み込み関数(SSE?)で処理しちゃうのか。
ネットで調べてたらSSEのレジスタ4つにまず読んで、それを
また4つ書き出すとレイテンシとやらを隠蔽できるとかなんとか
あったけどそんな感じかな。
とりあえずmemcpy使っておきます。
46デフォルトの名無しさん:2005/11/15(火) 15:00:39
組込み関数の意味がわかってない希ガス。
47デフォルトの名無しさん:2005/11/15(火) 17:17:53
関係ないけど __divdi3 は組み込み関数なんだろうか。
48・∀・)っ-●◎○- ◆Pu/ODYSSEY :2005/12/11(日) 17:53:45
直にCPUの命令またはその組み合わせに展開してしまえる関数だね。

組み込み関数の利用は#pragma intrinsic で明示できるよ。
逆に出来ない場合は組み込み関数として用意されてないといえる。」



ぶっちゃけIntel C++のオートベクトライズなんてあんま役に立たない。
処理を並列化できるところは明示的にMMX/SSEの組み込み関数
使って最適化したほうがいい。
CPUの動きを知り尽くしてレジスタカラーリングしてくれるから
へたなアセンブリコード書くより速い。

あとIntel C++なんかは、インライン関数を基本的に展開しない。
STL使ったら重いってことは結構ある。
ただし __forceinliceは受け付ける。


VC2005はcpuidとかローテート命令まで組み込み関数として使える
ようになったから、アセンブラ嫌いにはかなりフレンドリーになった希ガス。
49デフォルトの名無しさん:2005/12/12(月) 08:14:59
ローテートはVC6の頃から組み込み関数であった希ガス。
50デフォルトの名無しさん:2006/01/30(月) 17:07:08
2005は8bit版や16bit版も用意されてる
http://msdn2.microsoft.com/library/hd9bdb82(en-US,VS.80).aspx
51デフォルトの名無しさん:2006/02/13(月) 23:04:16
                       U
                \     |
                  \   人  /
                    メ´  ヾ  _,−'
                 −―<  , -、 て_
        C++とSSE!      ) / / (´
                          / / ⌒ 、
                  (⌒V ,'´`ヽ
        ト、       ,ヘ   ヽ  !   :〉
        ト、ヽ    / /!    /   、゙ーァ'
        |,ノ ´ ̄` ヾ!  /   /`~´
        ,' >   < ゙, /   /
          l   、ー―:ァ  i/   /
          ゙、   Y⌒/  ,/   /
        `''ァ‐`ー'      /
         / i      /
52デフォルトの名無しさん:2006/02/14(火) 09:28:47
だんごって何の仕事してんの?
53デフォルトの名無しさん:2006/02/14(火) 17:36:10
.NEETでFA
54デフォルトの名無しさん:2006/02/17(金) 12:53:20
倍精度実数、うらやましいなー
55デフォルトの名無しさん:2006/05/10(水) 23:25:12
constで最適化が促進させられる理由ってなんでそ?
5655:2006/05/10(水) 23:28:03
書き込むスレ間違えました。失礼しました。
57デフォルトの名無しさん:2006/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: WindowsXP 
 [3.2] コンパイラ名とバージョン: VC 6.0 
 [3.3] 言語: C 
[4] 期限: (2006年06月08日まで 

よろしくお願いします 
58デフォルトの名無しさん:2006/06/03(土) 20:12:46
やべっ 二分法って何だっけ
忘れちゃったよ
59デフォルトの名無しさん:2006/06/03(土) 21:02:27
>>58
カップラーメンを従来の1.5倍の速度で完成させる最適化技法
60デフォルトの名無しさん:2006/06/06(火) 23:05:22
調理時間の短いラーメンほど短時間で伸びる
61デフォルトの名無しさん:2006/06/07(水) 02:49:26
グルテンを加えるといい
62デフォルトの名無しさん:2006/06/08(木) 20:36:36
麩になっちまう
63デフォルトの名無しさん:2006/06/11(日) 01:52:05
即値で掛け算する場所を書き直してみたら?
64デフォルトの名無しさん:2006/06/11(日) 13:36:33
PenMのSSE2って遅くね?
65・∀・)っ-○◎● ◆toBASh.... :2006/06/11(日) 14:11:11
デコーダがネック。複合デコーダパスだからね。
汎用&MMレジスタベース命令と交互に配置するとデコーダネックを隠蔽できる。

Yonahでは解消されてる。てかめちゃくちゃスループットいい
66デフォルトの名無しさん:2006/06/11(日) 21:19:38
じゃあPenMだったら無条件でSSE2不使用、ってコーディングはもうしちゃ駄目だね。
67デフォルトの名無しさん:2006/06/12(月) 05:21:20
そもそもYonahな時点でPenMじゃないし。
つかPenMって3年前から更新されてない一昔前のチップだろ。
68デフォルトの名無しさん:2006/06/12(月) 05:50:51
ド忘れされてるDothanとi915萌え
YonahもBanias、Dothanと同様Pentium-Mですよ。
ただ発表後にPentiumブランド消失と絡んでIntel Coreとも名付けられちゃったが。
ブランド展開がまだよく分からんのでこの先どうなるか知らんが
69デフォルトの名無しさん:2006/06/12(月) 23:51:39
面白い話題なんでもっと調べたいんですが、
いい本ないでしょうか?

やっぱりパターソン&ヘネシーですか?
70デフォルトの名無しさん:2006/06/20(火) 21:14:25
メーカのドキュメント
71デフォルトの名無しさん:2006/10/12(木) 18:47:05
SSEはコンパイラが自動的に使ってくれるのですか?
72デフォルトの名無しさん:2006/10/12(木) 20:00:52
コンパイラによる。VCだとスカラ演算のみ。
自動ベクトル化が可能なコンパイラはgcc4.0系とかiccとかPGIとか。
73デフォルトの名無しさん:2006/10/20(金) 02:49:00
SSEで最適化してもメモリアクセスのほうがボトルネックになんね?
キャッシュとかよく分かんねけどメモリよりキャッシュを意識せな
いかんのだろうけど。
74デフォルトの名無しさん:2006/10/20(金) 03:06:04
処理の内容によるんじゃない?
動画の画像処理みたいにプリフェッチの予測が当たりやすい処理だと
メモリ帯域の方がボトルネックになってる感じはしない。
他の分野についてはわかりません。
75デフォルトの名無しさん:2006/10/20(金) 03:50:56
>>73
同じデータを色々な組み合わせで何度も使う場合
キャッシュをうまく効かせるのが腕の見せ所。
76デフォルトの名無しさん:2006/10/20(金) 09:13:41
誰かSSEのプリフェッチをどう使えばいいのかまとめてくれ。
77デフォルトの名無しさん:2006/10/20(金) 14:58:09
めちゃくちゃ大雑把に話せば、
メモリを使う100クロック前くらいで
64byteごとに1回プリフェッチ命令を置く。
どの命令がいいかは、全部試して速いのを採用。

詳しくは、たくさんコードを書いてから
キャッシュについて勉強してくれ。
俺も勉強せねば・・・。
78デフォルトの名無しさん:2006/10/25(水) 11:25:01
GPUと組み合わせ使うて場合って
GPUができる計算はみんななげちゃうって方針でいいの?

低次元行列計算はDirextXでできるみたいだから、
DirextXになげちゃおかと思ってるのだけど
79デフォルトの名無しさん:2006/10/26(木) 03:45:06
>>78
DirectXは誰が動かしていると思っているの?
ユーザプロセスは?
OSカーネルは?
80デフォルトの名無しさん:2006/11/11(土) 01:02:00
インテルのペンティアムプロセッサのマシン語で
高速化を勉強できる良い入門書みたいなのあったら教えてください
ホント、よろしくお願いします。
         
このとおり!m(_ _;)m m(-.-;)m m(_ _;)m
81デフォルトの名無しさん:2006/11/11(土) 01:24:25
>>4
82デフォルトの名無しさん:2006/11/11(土) 01:40:00
そうおっしゃらず。。
なにとぞ、お願いします〜m(_ _;;)m
83デフォルトの名無しさん:2006/11/11(土) 08:03:04
>>83
いやマジで、下手な本買うよりiccのアセンブラ出力眺めた方がよっぽど勉強になるって。
84デフォルトの名無しさん:2006/11/11(土) 10:14:57
なるほど、そういう意味でしたか。
85デフォルトの名無しさん:2006/11/11(土) 12:12:26
>>80
MMXテクノロジ最適化テクニック(ISBN4-7561-0797-4)の5章
8680:2006/11/11(土) 22:35:35
>>85さん、ありがとうございます。
早速書店で探してみます。m(_ _)mペコリ
87 【凶】 【488円】 :2007/01/01(月) 10:52:18
SSEでどこか参考になるサイトはありませんか?
88デフォルトの名無しさん:2007/01/01(月) 12:07:08
つ[google]
89デフォルトの名無しさん:2007/01/08(月) 18:18:09
最近のコンパイラはSSEなどは指定しなくても自動的に使ってくれるのでしょうか?
90デフォルトの名無しさん:2007/01/08(月) 18:30:46
ではまず最近のコンパイラの定義から(ry
91デフォルトの名無しさん:2007/01/08(月) 18:32:37
>>89
そういうコンパイラもあります。
92デフォルトの名無しさん:2007/01/08(月) 18:34:43
インテルコンパイラです
93デフォルトの名無しさん:2007/01/08(月) 18:36:58
自動的に使うようになってると、SSEがないCPUでは動作しないのでは。
94デフォルトの名無しさん:2007/01/08(月) 18:59:08
O3を指定した場合、自動的に検出され使われる
95デフォルトの名無しさん:2007/01/08(月) 19:03:58
  _  ∩
( ゚∀゚)彡 オッサン!オッサン!
 ⊂彡
96デフォルトの名無しさん:2007/01/08(月) 19:07:29
ここってこんなに人居たんだ
97デフォルトの名無しさん:2007/01/08(月) 19:28:09
>>95
オマイの駄洒落のほうが・・
98・∀・)っ-{}@{}@{}@:2007/01/08(月) 20:10:18
/Qx*とか/Qax*なしで使うことってあったっけ?
とりあえずboost:mt19937はICCのオートベクトライズでやたら速くなるが
99デフォルトの名無しさん:2007/01/08(月) 20:31:21
100デフォルトの名無しさん:2007/01/08(月) 20:47:28
AMD64向けだと強制的に使ってくれる。

自動ベクトル化は知らん。
101サイザー専用JAVA演習場 その2:2007/01/08(月) 21:17:02
次スレまできた。飽きっぽい俺が良く続くもんだ。Σ(´∀`;)
どうぞよろしくお願いします。
102デフォルトの名無しさん:2007/01/29(月) 08:23:39
http://www.intel.co.jp/jp/developer/download/index.htm
ここにあるインストラクションセット表って、
SSE3以降のものも載ってます?
103デフォルトの名無しさん:2007/02/07(水) 20:57:03
SSE3は載ってたと思う。SSSE3は知らん
104デフォルトの名無しさん: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 :2007/02/10(土) 01:07:28
BaniasかDothanかYonahかにもよるけど、SSEはあんまり得意じゃないよMは
106104:2007/02/10(土) 16:29:40
>>105
Dothanコアです。

MはSSEが得意ではないのですね。参考になりました。
参考までに、姫野ベンチでも実験したところ、こちらは-mfpmath=sseありの方が速かったので、
コードに依るかも知れません。
107・∀・)っ-○◎● ◆DanGorION6 :2007/02/10(土) 21:00:29
Pentium M系アーキテクチャでSSE*が遅いのはデコーダがネックになってるらしい。
Complex Decoderのみでデコードされるから、倍精度は浮動小数が速くても不思議じゃない

Pentium MのFPUは加減算・乗算毎に倍精度×1、単精度×2だけど
x87とSSEスカラ演算だと単精度はクロックあたり1、SSEのパックド演算だと2つは
発行できるから、単精度ならまだ使う価値があるね。
108デフォルトの名無しさん: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デフォルトの名無しさん:2007/02/12(月) 16:51:08
んでもSSE使うように最適化オプションつけた方が
遅くなるってのは不思議だよなぁ。
早くならないってことはあっても遅くなるってのはなぁ・・・
タスクスイッチのときにXMMレジスタも全部退避するようになるから?
そういやXMMレジスタまで対比するか否かってOSはどうやって知ってるの?
110デフォルトの名無しさん:2007/02/12(月) 16:58:01
>>109
そもそも初期状態でFPUセットになっているのなら、SSEを使うだけで切り替えコストが発生する。
111・∀・)っ-○◎● ◆DanGorION6 :2007/02/12(月) 17:01:00
まあ、Complexデコーダパス命令だから、の一言なんだが
待避のオーバーヘッドなんてたかがしれてる



MXCSRレジスタってあるじゃん
112・∀・)っ-○◎● ◆DanGorION6 :2007/02/12(月) 17:01:45
>>110
それXMMレジスタじゃなくてMMレジスタの話では
113デフォルトの名無しさん:2007/02/12(月) 17:41:09
でもSISDならデコードも速い。
単純にコンパイラが最適化しきれてないだけじゃないのか。
そもそも104氏が何の処理をさせてたのか書いてないから
イマイチ議論のしようがない気もする。

おそらく人間が書けばDothanでもSSEの方が速いとは思う。
114 ◆0uxK91AxII :2007/02/12(月) 21:16:30
>>109
>XMMレジスタまで対比するか否か
http://hira.main.jp/wiki/pukiwiki.php?__save_init_fpu()%2Flinux2.6
115・∀・)っ-○◎● ◆DanGorION6 :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 :2007/02/20(火) 00:30:25
64ビット同士の整数乗算は素直にx64命令セット使えと思うが。。。

16×16の積算・積和演算があるから組み合わせればいくらでも可能だ罠
118デフォルトの名無しさん:2007/02/21(水) 14:03:24
海外旅行での現地のATMでのキャッシングって、
キャッシング枠ですか?それともショッピング枠ですか?
以前現金主義の友人がどうしても両替商見つからなくて
現地のATMでキャッシングしたら、日本に帰ってきて
ショッピングとして明細に出てたって聞いたんですが。
119デフォルトの名無しさん:2007/02/21(水) 15:09:23
>>118
ATMによる。スレ違い。
120デフォルトの名無しさん:2007/02/25(日) 13:31:40
誤爆じゃないのか
121デフォルトの名無しさん:2007/03/02(金) 21:40:36
浮動小数点モデルを /fp:fast にする
精度は落ちるが
122デフォルトの名無しさん:2007/03/03(土) 09:27:27
マルチタスク/マルチスレッドで、セマフォを長時間握ったまま返さない奴とか見つける、とかは
やっぱプロファイラとかで動的解析しないと分らんよね。
そんなの静的解析でどうにかなるもんじゃないか・・・。
123デフォルトの名無しさん:2007/06/04(月) 18:02:04
doubleは2つ同時にしか実行できないのか?
124デフォルトの名無しさん:2007/06/04(月) 18:08:28
>>123
日本語よろ!
125デフォルトの名無しさん:2007/06/04(月) 18:54:23
だぶる先生らいふのことだろ。
常識的に考えて。
126デフォルトの名無しさん:2007/09/28(金) 23:10:54
ダブル先(の)生ライフ?
127デフォルトの名無しさん:2007/10/01(月) 19:33:27
>>123
C++でおk
128 ◆0uxK91AxII :2007/10/01(月) 23:04:52
>>123
一つのみも可。
ex) addsd
129デフォルトの名無しさん:2007/12/31(月) 11:50:57
下がり過ぎ
130デフォルトの名無しさん:2008/11/08(土) 21:50:37
SSEで大部分が記述された
正規表現エンジンって知りませんか?
131デフォルトの名無しさん:2008/11/09(日) 00:12:17
闇雲にSSEを使えば速くなるってもんじゃないし、そんな阿呆な代物ないでしょ。
# 速度に寄与する肝腎な箇所に使っているってことなら話は別だが。
132デフォルトの名無しさん:2008/11/09(日) 01:43:59
sseで正規表現・・・どこで使ったものやら
133デフォルトの名無しさん:2008/11/10(月) 14:07:10
SSEって並列処理や積和なんかが1命令化で速くなる。
端からデータを舐めていくような処理はあまり効果ないよ。
特に検索には向かない。
134デフォルトの名無しさん:2008/11/10(月) 14:17:20
bit列のマッチングはどう?
1bitずつずらしたのをxorしてall 0になったかどうか調べるとか
135デフォルトの名無しさん:2008/11/10(月) 21:40:31
strlenをSSE2でやる人がいるくらいだし、その応用でstrchr/strstrのような単純な検索はできると思う。
ただ、正規表現となるとうまく使うのは難しいと思う。
136デフォルトの名無しさん: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デフォルトの名無しさん: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デフォルトの名無しさん:2008/12/21(日) 13:31:59
同時比較でいいならロードして比較してvec_all_eq()するだけじゃね?
ストアと読み出しはいらん。
144,,・´∀`・,,)っ-○◎●:2008/12/21(日) 18:51:16
>vec_all_eq()
あのさー、それ複合関数だから。

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

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


CPUネイティブのベクトル比較命令であるvcmpequb自体は、SIMDレジスタ上にマスクを生成するのみ。
マッチしたのか、マッチしてないのか、マッチした場合、どこの位置でマッチしたのかっていう判定は
汎用レジスタ側でやるしかないんだよ。
145デフォルトの名無しさん:2008/12/21(日) 19:51:08
お前こそvcmpequbの仕様を読んだ事あるのかと。

> The CR6 is set according to whether all, some, or none of the elements compare equal.
146デフォルトの名無しさん:2008/12/21(日) 19:59:03
最近論調がおとなしくなってきて改心したのかと思えば、
内心人を見下してるのは変わってないんだよな。
147デフォルトの名無しさん:2008/12/21(日) 20:04:05
あ、なんでアセンブリコードとか的外れな事言ってるのかようやく分かった。
最適化オプションを全く指定しないと確かに複合になるね。

ていうかさあ、デバッグ用とはいえ確かにこのアセンブリは変態だけど
つまりはお前は大口たたいておきながら
その実>>143を言われて顔真っ赤にして焦ってアセンブリ出力を確認したんだろ。
恥ずかしいなあ。
148,,・´∀`・,,)っ-○◎●:2008/12/21(日) 20:06:12
「.」付き版はcr6を更新するからptest相当のことだけはできるよ。それは正しい。
どこでマッチしたかを求めるには汎用レジスタ側でやんないといけない。

pmovmskb相当の命令がないから遅いんだって。
Cell SPEだと7ビットシフトしてギャザリングし、ビットスキャンすれば位置が求まるけど
149,,・´∀`・,,)っ-○◎●:2008/12/21(日) 20:07:28
>>147
で、pmovmskbの代用命令はどこにあるの?
150デフォルトの名無しさん:2008/12/21(日) 20:08:21
っヒント:もうL1に乗ってる
151デフォルトの名無しさん:2008/12/21(日) 20:09:45
>>149
無いよ。
そこを叩きたいなら叩いてくれ。
152,,・´∀`・,,)っ-○◎●:2008/12/21(日) 20:11:31
そんなことは聞いてない。
SSE*にはSIMDレジスタ上のベクトルデータのMSBを縮約してダイレクトに汎用レジスタに転送する命令がある。
bsfと組み合わせればマッチ位置まで簡単に求めることができる。

AltiVecには、そういう命令は、ない。
153,,・´∀`・,,)っ-○◎●:2008/12/21(日) 20:12:47
>>151
なら結局遅いじゃん。
154デフォルトの名無しさん:2008/12/21(日) 20:15:38
支離滅裂だな。
それが初めから分かってるなら慌ててアセンブリ確認なんてしてないだろ。
百歩譲って今お前が力説したい事にスポットを当てるなら
all_xx()が複合であるかどうかなんてどうでもいいんだからな。

ていうかstrchなのかstrstrなのかハッキリしろよ。
反論するのに都合の良い方を選択してるだけじゃねーか。
155,,・´∀`・,,)っ-○◎●:2008/12/21(日) 20:16:13
慌ても確認もしてないよ
156デフォルトの名無しさん:2008/12/21(日) 20:17:49
じゃあall_xxが複合だと言ったのはどこのだれですか?
結局gather出来ないんだから、そこはどうでもいいんだけどね。
157,,・´∀`・,,)っ-○◎●:2008/12/21(日) 20:19:12
>>154
どっちもSSEより遅いよ。

PPCからの移植にSSE1まで使えるか2まで使えるかとか気にしなきゃいけないと思う方が馬鹿だよ。
Win32でもSSE2が使えないCPUなんてどのみちSIMDユニットの実装もショボイから最適化対象としては無視して良いくらいだよ。
非SIMDのパスに飛ばしておけばいい。
158デフォルトの名無しさん:2008/12/21(日) 20:22:57
まあそれも論点ずれてるんだが、建設的な話をしたいからお前に合わせよう。

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

でもx86陣営がそういう路線を歩んでいるのは間違いなくて
SSE3, SSSE3, SSE4.1, SSE4.2, AVX, LNIといちいちチェックしなくてはいけない日々が続く事には変わりない。
159デフォルトの名無しさん:2008/12/22(月) 00:20:05
Core2 Duoと比較して、Athlon X2がそれほど酷いとは思えないんだけど。
160デフォルトの名無しさん:2008/12/22(月) 00:39:51
整数演算はひどいな
161デフォルトの名無しさん:2008/12/22(月) 12:59:27
一晩考えて、何故団子がgatherに必死なのかが分かった。
団子はトリップ検索が主だから検索対象が極端に小さくて、
詳細な位置の特定の方がボトルネックになっているんだな。
162,,・´∀`・,,)っ-○◎●:2008/12/22(月) 18:05:57
tawake
163デフォルトの名無しさん:2008/12/22(月) 18:42:38
続きをどうぞ
164デフォルトの名無しさん:2008/12/23(火) 01:34:18
>>161
誰が笑いを取れとw
165デフォルトの名無しさん:2008/12/24(水) 07:45:53
変な事言った?
166,,・´∀`・,,)っ-○◎●:2008/12/24(水) 19:00:25
一晩考えることじゃないだろ。俺のブログ一通り読んだら30分以内に否定される。
167デフォルトの名無しさん:2008/12/24(水) 20:19:04
で?
168,,・´∀`・,,)っ-○◎●:2008/12/24(水) 20:52:06
笑いしかとれなかったね
169デフォルトの名無しさん:2008/12/24(水) 23:46:08
そうだね。俺もだけど団子も痛い子だね。
170デフォルトの名無しさん:2008/12/25(木) 00:24:23
痛いのはお前だけですからwww
171デフォルトの名無しさん:2008/12/25(木) 00:39:33
だから何故?
煽ってるんじゃなくて純粋に。
172デフォルトの名無しさん:2008/12/26(金) 19:45:57
無知のまま過ごすのは恥だし勿体ないので団子でも名無しでも回答くれないかな。
名無しが答えられるかどうかは疑問だけど。
173デフォルトの名無しさん:2008/12/26(金) 20:29:55
        ∩___∩
. \     | ノ      ヽ
   \  /  ●   ● |
     \|    ( _●_)  ミ  そんなエサでおれが釣られるかクマー!
      彡、   |∪| ,/..
       ヽ   ヽ丿/  /⌒|
       / \__ノ゙_/  /  =====
      〈          _ノ  ====
       \ \_    \
        \___)     \   ======   (´⌒
           \   ___ \__  (´⌒;;(´⌒;;
             \___)___)(´;;⌒  (´⌒;;  ズザザザ
174デフォルトの名無しさん:2008/12/27(土) 07:45:25
都合が悪くなるとすぐ逃げるか話そらすからな。
結局161が図星だったのか。
175デフォルトの名無しさん:2008/12/27(土) 10:20:33
名無しが寂しそうにしてるから構ってやれよw
176デフォルトの名無しさん:2009/01/04(日) 11:41:54
ビット演算の代数的な性質、それを導き出す公理が知りたい
算術演算から式変形だけでアセンブリ言語のコードを導き出せるようになりたい
177デフォルトの名無しさん:2009/01/04(日) 12:31:09
コンパイラでも作りたいの?
178デフォルトの名無しさん:2009/01/07(水) 23:00:55
メモリアクセスとかを考慮すると構造体より配列のほうが高速?
179デフォルトの名無しさん:2009/01/08(木) 00:02:43
>>178
同じ。
180デフォルトの名無しさん:2009/01/08(木) 00:13:42
SSE2でnビット左rolってどうやって記述すればいいのですか?
181デフォルトの名無しさん:2009/01/08(木) 00:34:34
Intelのマニュアル読みなさい
182,,・´∀`・,,)っ-○◎●: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デフォルトの名無しさん:2009/01/08(木) 11:55:57
俺の質問には答えずに人の質問には答えるんだな。

要素ごとのは、例えば最上位に立っているビットからNビット欲しいとか色々使い道はあるよ。
floorみたいのを自力で実装しようとすれば分かる。
184,,・´∀`・,,)っ-○◎●:2009/01/08(木) 12:46:20
サーセンwwwpandじゃなくてporだwww
185デフォルトの名無しさん:2009/01/09(金) 14:29:17
>>179
うほ?
>>178の意味がいまいち分からんが、
char array[0x100];

struct{char value;} array[0x100];
だったらレジスタサイズにパディングされる分、構造体の方が早くね?
ちなみに、同じ事だが容量気にして構造体のなかでshortとか使うと
パデイング入るんでメモリに無駄が発生する。
まぁ、パディングを知っていれば無駄を防ぐこともできるけど。
186デフォルトの名無しさん: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デフォルトの名無しさん:2009/01/11(日) 01:44:37
配列のindexが定数なら変わらんだろ
アセンブラ見ろ
189デフォルトの名無しさん: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デフォルトの名無しさん:2009/01/11(日) 10:18:30
おまえほんとにだんごか?
デフォルトなんて決まってるわけ無いだろ
193,,・´∀`・,,)っ-●◎○:2009/01/11(日) 10:25:51
まあデフォルト値は処理系依存だな。

>>189の言ってることが嘘ってことで。
少なくともパディングが入らない保障はない。
194デフォルトの名無しさん: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デフォルトの名無しさん:2009/01/11(日) 15:41:20
http://kikyou.info/diary/?200812#i24_1
> つまり最大でポインタ二つ分のデータを保持しています。LP64の場合は128bitとなります。ILP32の場合は64bitとはならず、パディングの関係でLP64と同じく128bitとなります。
8byte?
197デフォルトの名無しさん:2009/01/11(日) 15:44:14
将来AVXの1024bit SIMDが使えるようになった際に、128byteにパディングされるとかなるとイヤだな。
その頃にはメモリは数十GBで128byteなんてゴミみたいなもんだろうけど。
198,,・´∀`・,,)っ-○◎●:2009/01/11(日) 15:47:54
その頃までにSIB.scaleのビット拡張してほしいね。1ビット増やせばx16, x32, x64, x128になるのに。
199デフォルトの名無しさん:2009/01/11(日) 15:59:23
\  \\       ____         // / /
<           _-=≡:: ;;   ヾ\            >
<         /          ヾ:::\           >
<         |            |::::::|          >
<        ミ|-=≡、 ミ≡==- 、 |;;;;;/          >
<         || <・>| ̄| <・> |── /\         >
<         |ヽ_/  \_/    > /         >
<        / /(    )\      |_/          >
<        | |  ` ´        ) |           >
<        | \/ヽ/\_/  /  |           >
<        \ \ ̄ ̄ /ヽ  /  /           >
<          \  ̄ ̄   /  /       \    >
  / /        ̄ ̄ ̄ ̄ ̄ ̄ ̄     \\ \ \
     ___
   / ―\ ナンミョウホウレンゲッキョウナンミョウホウレンゲッキョウナンミョウホウレンゲッキョウ
 /ノ  (@)\ ナンミョウホウレンゲッキョウナンミョウホウレンゲッキョウナンミョウホウレンゲッキ
.| (@)   ⌒)\ ナンミョウホウレンゲッキョウナンミョウホウレンゲッキョウナンミョウホウレンゲッ
.|   (__ノ ̄|  |   ///;ト,  ナンミョウホウレンゲッキョウナンミョウホウレンゲッキョウナンミョ
 \   |_/  / ////゙l゙l;  ナンミョウホウレンゲッキョウナンミョウホウレンゲッキョウナンミョ
   \     _ノ   l   .i .! |  ナンミョウホウレンゲッキョウナンミョウホウレンゲッキョウナンミョ
   /´     `\ │   | .|  ナンミョウホウレンゲッキョウナンミョウホウレンゲッキョウナンミョ
    |       | {   .ノ.ノ  ナンミョウホウレンゲッキョウナンミョウホウレンゲッキョウナンミョ
    |       |../   / . ナンミョウホウレンゲッキョウ
200デフォルトの名無しさん:2009/01/12(月) 00:40:28
パディングってむやみに入れるとキャッシュヒット率悪くなってかえって効率落ちたりしないんだろか
201,,・´∀`・,,)っ-●◎○:2009/01/12(月) 00:42:04
逆にキャッシュラインを跨ぐと効率悪くなるんだよ
202デフォルトの名無しさん:2009/01/12(月) 00:44:50
>>200-201
どっちも一般論だー

場合によるでしょ
203デフォルトの名無しさん:2009/01/12(月) 00:58:25
実測すれば済む話
204デフォルトの名無しさん:2009/01/12(月) 01:11:32
>>191
cygwin上のgccで試してみたけど、padding入らないよ
205デフォルトの名無しさん:2009/01/12(月) 13:59:38
>>204
CPUによるが
struct foo {
char a;
double b;
};
でパディングが入らなかったら例外起きるだろうが。
206デフォルトの名無しさん:2009/01/12(月) 14:41:55
起こんねーよ、CPUによるが。
207デフォルトの名無しさん:2009/01/12(月) 14:55:43
struct {char a, b, c;}だったらパディングなくても例外起きないよ。
コンパイラがまともなら。
208,,・´∀`・,,)っ-○◎●:2009/01/12(月) 17:32:33
アラインメント制約の厳しいプロセッサなら、例外が起きないようにコンパイラが勝手にパディングするんじゃないかな。


しかしミスアラインメントのデータに対するロード・ストアの扱いは各CPUアーキ毎に方針が違ってて面白いな
x86のSSE以降は、ミスアラインメントを許すが遅い命令と、許さないが高速な命令の2通りを用意。
対して、POWER/CellのSIMDは下位ビットを無視してロードし、プログラマが勝手にPermuteしてくれっていう扱い。
209デフォルトの名無しさん:2009/01/12(月) 18:31:15
下位ビットを無視してくれるのはわざわざAND取ってアライメントする必要がないから楽でいいよな。
210デフォルトの名無しさん:2009/01/12(月) 18:38:09
中を作る側もデコーダが軽くなるからウマー
211デフォルトの名無しさん:2009/01/13(火) 01:17:59
>>205
> >>204
> CPUによるが
> struct foo {
> char a;
> double b;
> };
> でパディングが入らなかったら例外起きるだろうが。

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

>>185
> struct{char value;} array[0x100];
212デフォルトの名無しさん:2009/01/13(火) 01:46:59
ところでパディングの入らない環境ってどんな環境だろ?
PC用で32bitプロセッサじゃ大抵入ると思うが。
sizeof(struct{char value;})==4
見たいにね。
213デフォルトの名無しさん:2009/01/13(火) 02:10:47
struct{char value;} array[0x100];
printf("%d\n", sizeof(array));
=> 256
gcc-4.3.2ではこうなったけど、パディングってそもそも何だ?無効領域?
214デフォルトの名無しさん:2009/01/13(火) 02:48:14
>>212
Crayだとchar=short=int=32bitとかが普通らしい。
PC用じゃないけど。
215デフォルトの名無しさん:2009/01/13(火) 17:31:55
>>213
ゴメン
sizeof(struct{char value;})じゃ1だね。
sizeof(struct{char v1;short v2})じゃ4になったから試さずに
書いちゃった。メンバーが同じサイズなら配列化されるっぽいね。
216デフォルトの名無しさん: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,,・´∀`・,,)っ-○◎●:2009/01/13(火) 21:09:54
俺的に配列は__declspec(align(32))がデフォです
218デフォルトの名無しさん:2009/01/13(火) 21:34:41
32?
16じゃないのか?
219,,・´∀`・,,)っ-○◎●:2009/01/13(火) 23:06:38
AVX化を視野に入れてるから
220デフォルトの名無しさん:2009/01/14(水) 08:14:08
Alphaには16bitレジスタなかったよん
221デフォルトの名無しさん:2009/04/07(火) 23:53:51
MacでIntel PPC両対応のコードを書いています。

SSEでは、16ビット整数や8ビット整数をVectorに一括セットする命令が
見つけられません。
SSEで、以下のAltivecと同等の記述をするには通常どのような手順を使えば
よいのでしょうか?

例:Altive用コード
vUInt8 multiL, multiS;
vUInt16 shift;
switch (mode) {
case 2:
multiL = vec_splat_u8(5); multiS = vec_splat_u8(3); shift = vec_splat_u16(3);
break;
case 1:
multiL = vec_splat_u8(3); multiS = vec_splat_u8(1); shift = vec_splat_u16(2);
:
222デフォルトの名無しさん:2009/04/08(水) 00:08:13
っ _mm_set1_pi16
223デフォルトの名無しさん:2009/04/08(水) 05:32:21
>>222
__mm_set1_pi16とか_mm_set1_pi8とかですと、MMXレジスタが対象と
ありました。

SSEレジスタにセットする場合、もしかして次のような手順になるのですか?
 CPUでメモリ上にパターンを作成
 SSEレジスタにロード

それとも、そもそもsseレジスタを使うのが遠回りで、MMXレジスタで2回
まわすのが普通なのでしょうか?
224デフォルトの名無しさん:2009/04/08(水) 07:20:56
「e」pi16だな。
225デフォルトの名無しさん:2009/04/08(水) 20:22:07
>>224
なるほど!
__m128i _mm_set1_epi8(char b)

見落としていました。ありがとうございました。
226 ◆0uxK91AxII :2009/04/09(木) 17:01:19
xrgbxrgb の8[Byte]を、vuyyの4[Byte]に変換する場合、
途中で、
mm0: 左右平均r, 左右平均r, 左r, 右r
mm1: 左右平均g, 左右平均g, 左g, 右g
mm2: 左右平均b, 左右平均b, 左b, 右b
っていう感じに並べ換えるのに、えらく時間が掛かる。

32[bit]なOS上で、Athlon 64の2[GHz]、SSEは2までを使用、
メモリは、DDR 400を、dualchannel、
連続した1024*768[dot]の処理に、6[ms]弱を要する。

極力、同じレジスタに連続して触れないように書こうとしても、
何かとやりづらい。

他に適当な方法があれば、教えて欲しいとか、書いてみる。
227デフォルトの名無しさん:2009/04/09(木) 21:58:05
pmaddwd 2個で済むように書けるよな?
228 ◆0uxK91AxII :2009/04/09(木) 23:29:25
thx
pmaddwd - packssdw - pmaddwdで、vuかyyの二要素出せるのかー。
/(^o^)\
229 ◆0uxK91AxII :2009/04/10(金) 01:48:24
5[ms]弱に短縮。
適当に並び換えれば、もう少し行けるかも。
230デフォルトの名無しさん:2009/04/14(火) 08:19:33
バイト列の入れ替えをしたいのですが、普通はどのように行うのでしょうか。

単に偶数、奇数バイトをスワップさせたいだけなのです。
00 11 22 33 00 11 22 33 00 11 22 33 00 11 22 33
11 00 33 22 11 00 33 22 11 00 33 22 11 00 33 22

上マスク、下マスクで二つの値を出し、それぞれシフトして、ANDを取る
という方法しか思いつきません。もっと賢い方法がありそうな気がします・・・
231デフォルトの名無しさん:2009/04/14(火) 09:36:53
4バイトならbswapで一発なんだが
232デフォルトの名無しさん:2009/04/14(火) 10:05:56
言葉足らずですみません。xmmでの処理途中なんです。
233デフォルトの名無しさん:2009/04/14(火) 13:25:24
psrlw psllw por
または
pshufb
あたりじゃね?

>>231
エンディアン変換命令使ってどうするw
234デフォルトの名無しさん:2009/04/15(水) 23:05:41
>>233
なるほど、前者はSSE2までのマスク+シフト+orですね。
後者はSSSE3ってことはCore2Duo以降ですか・・・

CoreDuo以前を切り捨てれば楽だけど・・・ん〜。
235,,・´∀`・,,)っ-@{}@{}@{}-:2009/04/16(木) 08:01:14
2通りの関数書いてCPUIDで振り分けるのはどう?
SSSE3でも128ビット版は65nm版Core2やAtomは速くないよ。
ちなみにSSE5なら
protw xmm0,xmm0,8
で1命令ですな
236デフォルトの名無しさん:2009/04/16(木) 14:44:26
>>235
>2通りの関数書いてCPUIDで振り分けるのはどう?
これでやってみます。サンクスでした。
237デフォルトの名無しさん:2009/04/18(土) 11:46:24
お前ら、ちょっと頼みがあるんだが。
SSEでどの程度高速化できるか、ちょっくら試しにコードを書いてみたんだが全然速くねぇ。
コードの書き方が悪いのか、俺のPCのCPUがAthlonなのが悪いのか、アドバイスおくれ。

ソースはコレ↓
http://uproda11.2ch-library.com/11172112.zip.shtml

題材はビットカウントで、コンパイラは GNU C++。

よろしくおながいします。



238デフォルトの名無しさん:2009/04/18(土) 11:47:42
あ、言い忘れたけどDLキーはデフォルトの1です。
239237=238:2009/04/18(土) 11:50:15
ちなみに家のPCでの実行結果はこんな感じ

init data
func = reference : test=OK : clock = 15063 : sum = 504854834
func = bit32 : test=OK : clock = 6812 : sum = 504854834
func = bit64 : test=OK : clock = 5219 : sum = 504854834
func = sse : test=OK : clock = 5109 : sum = 504854834
240デフォルトの名無しさん:2009/04/18(土) 12:06:54
すまん、データの初期化でバグがあった。

直したんで、こっち↓を見てくれ。
http://uproda11.2ch-library.com/11172113.zip.shtml
241デフォルトの名無しさん:2009/04/18(土) 12:36:15
生のアセンブラで書けよ!インラインってw
実行せずとも分かる事を述べよう。
ソースを16バイトアライメントに合わせている?
ソフトウェアパイプライン化が行われていない。(これをやっていないとSSEの意味がない。)
そもそも速度計測しているコードが小さい。
SSE4.2だと1命令でなかった?
242デフォルトの名無しさん:2009/04/18(土) 13:17:12
>>235
CPUIDで振り分けてもSSE5じゃ使えるCPUが現状ないジャマイカw
SSEPlusでエミュレーションするとSSE2の実装で9.3サイクルかかるな。
これ分岐いらんだろjk
ttp://sseplus.sourceforge.net/group__emulated___s_s_e2.html#g80be0eae1c514715a253654cdc4280db
243デフォルトの名無しさん:2009/04/18(土) 20:12:39
勉強し始めです。
リトルエンディアンとxmmで混乱してしまったので教えてください。

実アドレス上、以下の順で並んでいたアドレス上のデータは、
0 1 2 ... D E F
xmmレジスタにロードすると
F E D ... 2 1 0
の順で取り込まれるのですよね?

_mm_srli_si128()で1バイト右シフト(256で割る)するとレジスタ上は
0 F E ... 3 2 1
となり、これをメモリにストアすると
1 2 3 ... E F 0
という順でストアされる

ということは、
 xmmで右シフトした状態というのは、
 メモリ上では(上記表現では)左シフトした状態に相当
これ、認識あっていますでしょうか。
244デフォルトの名無しさん:2009/04/18(土) 21:25:00
デバッガで見えるレジスタの状態は右が下位だよっと
糞長い128bit変数だと思えばいいよ
245,,・´∀`・,,)っ-○◎○:2009/04/19(日) 01:13:42
>>240

inline __m128i population_count_sse_iter(__m128i *v)
{
__m128i tmp0,tmp1,tmp2,mask;
tmp0=_mm_load_si128(v);

mask=_mm_set1_epi32(0x55555555);
tmp1=_mm_and_si128(tmp0,mask);
tmp2=_mm_srai_epi32(tmp0,1);
tmp2=_mm_and_si128(tmp2,mask);
tmp0=_mm_add_epi32(tmp1,tmp2);

mask=_mm_set1_epi32(0x33333333);
tmp1=_mm_and_si128(tmp0,mask);
tmp2=_mm_srai_epi32(tmp0,2);
tmp2=_mm_and_si128(tmp2,mask);
tmp0=_mm_add_epi32(tmp1,tmp2);

mask=_mm_set1_epi32(0x0f0f0f0f);
tmp1=_mm_and_si128(tmp0,mask);
tmp2=_mm_srai_epi32(tmp0,4);
tmp2=_mm_and_si128(tmp2,mask);
tmp0=_mm_add_epi32(tmp1,tmp2);

mask = _mm_setzero_si128();
tmp0 = _mm_sad_epu8(tmp0, mask);
return tmp0;
}
246,,・´∀`・,,)っ-○○○:2009/04/19(日) 01:17:51
【続き】
virtual int population_count(unsigned int data[4])
{
__m128i sum = population_count_sse_iter((__m128i *)data);
return _mm_extract_epi16(sum, 4) + _mm_cvtsi128_si32(sum);
}

virtual int population_count_array(unsigned int data[][4],int size)
{
__m128i sum = _mm_setzero_si128();
for(int i=0;i<size;i++)
{
sum = _mm_add_epi32(sum, population_count_sse_iter((__m128i*)data[i]));
}
return _mm_cvtsi128_si32(sum) + _mm_cvtsi128_si32(_mm_srli_si128(sum, 4));
}

んで、うちの環境ではこんな感じになった(Core 2 Duo E8500, Cygwin)

func = reference : test=OK : clock = 8890 : sum = 504854834
func = bit32 : test=OK : clock = 4859 : sum = 504854834
func = bit64 : test=OK : clock = 12829 : sum = 504854834
func = sse : test=OK : clock = 2156 : sum = 504854834
func = dango-sse : test=OK : clock = 1281 : sum = 504854834
func = dango-ssse3 : test=OK : clock = 1093 : sum = 504854834

64bitが遅いのは32ビットとしてビルドしてるからだと思うが、それはさておき
SSSE3を使う方法は、Penryn/Nehalemでは速いけど
AtomとかCore 2 65nm系は使えてもSSE2のより遅い。
247,,・´∀`・,,)っ-○○○:2009/04/19(日) 01:18:54
virtual int population_count_array(unsigned int data[][4],int size)
{
__m128i sum = _mm_setzero_si128();
for(int i=0;i<size;i++)
{
sum = _mm_add_epi32(sum, population_count_sse_iter((__m128i*)data[i]));
}
return _mm_cvtsi128_si32(sum) + _mm_cvtsi128_si32(_mm_srli_si128(sum, 4));
}

訂正してくだしあ><
248,,・´∀`・,,)っ-○○○:2009/04/19(日) 01:20:10
【これが正解】
virtual int population_count_array(unsigned int data[][4],int size)
{
__m128i sum = _mm_setzero_si128();
for(int i=0;i<size;i++)
{
sum = _mm_add_epi32(sum, population_count_sse_iter((__m128i*)data[i]));
}
return _mm_cvtsi128_si32(sum) + _mm_cvtsi128_si32(_mm_srli_si128(sum, 8));
}
249240:2009/04/19(日) 06:24:28
>>,,・´∀`・,,)っ-○○○

うちのAthlonの環境でも>>246のdango-sseの結果と大体同じくらいの性能うpが確認できました。
しかし、こんなに差がつくとはSSE侮りがたし。

団子さん、多謝です!

250デフォルトの名無しさん:2009/04/25(土) 20:53:10
VC++ と gcc (言語は C++)のインラインアセンブラで
SSE の16バイトアラインメントされていることを仮定した命令を使いたいのですが、
float の配列変数全体を16バイト境界にアラインさせることって可能ですか?
251デフォルトの名無しさん:2009/04/25(土) 21:04:42
>>250
__declspec(align(16))と__attribute__((aligned(16)))
マクロなりなんなりで切り替えればいい
252デフォルトの名無しさん:2009/04/25(土) 21:27:17
>>251
即レスありがとうございます!
253,,・´∀`・,,)っ-○○○:2009/04/26(日) 01:00:01
__m128(あるいはその配列)との共用体にすれば勝手に合うけどね。
254デフォルトの名無しさん:2009/04/26(日) 01:02:51
gcc で使えるの?
255デフォルトの名無しさん:2009/04/26(日) 02:32:21
gcc で使えるの?
256デフォルトの名無しさん:2009/04/26(日) 09:52:02
大事な事なので2回聞きました
257デフォルトの名無しさん:2009/04/26(日) 15:03:36
#include <xmmintrin.h>
258,,・´∀`・,,)っ-○○○:2009/04/26(日) 15:14:47
あとコンパイルオプションにフラグつけとけ
-msse

とか
259デフォルトの名無しさん:2009/04/26(日) 15:23:18
そしてautotools地獄へ…
260,,・´∀`・,,)っ-○○○:2009/04/26(日) 15:50:01
ああ、あのへんマジで何とかして欲しい。
Win32ではASMで書いた関数の頭にアンスコ付けないと認識しなかったりとか
261デフォルトの名無しさん:2009/04/26(日) 18:46:23
頭に…アンスコ…?
262デフォルトの名無しさん:2009/04/26(日) 18:53:03
アンダースコート被るんだよ
263 ◆0uxK91AxII :2009/04/26(日) 19:14:57
underscore、呼出規約云々のアレ。
264,,・´∀`・,,)っ-○○○:2009/04/26(日) 21:11:39
こやつらには5Fhって言った方がわかりやすいかもしれんな
265デフォルトの名無しさん:2009/04/26(日) 21:44:35
プログラマのくせに、「あんすこ」が通じないのはおかしい。
266デフォルトの名無しさん:2009/04/26(日) 21:46:17
職業プログラマだけじゃないだろ
趣味でやるやつもいる
267デフォルトの名無しさん:2009/04/26(日) 22:06:11
趣味グラマだけど理解してるよ
268デフォルトの名無しさん:2009/04/26(日) 22:58:53
アンダーバーとか言う奴は素人
269デフォルトの名無しさん:2009/04/28(火) 14:56:39
ひゃっひゃっひゃっひゃっ
270デフォルトの名無しさん:2009/04/28(火) 16:21:42
なさけなや
271デフォルトの名無しさん:2009/04/28(火) 17:08:11
アンダーバー。
272デフォルトの名無しさん:2009/05/01(金) 21:18:18
今のVCのコンパイラは、インラインアセンブラを書くと、そのインラインアセンブラを含む関数が最適化がされないらしいけど、
xmmintrin.hなどは、使うと最適化されなくなる?
273デフォルトの名無しさん:2009/05/01(金) 21:26:48
うん
274デフォルトの名無しさん:2009/05/01(金) 21:45:13
インラインアセンブラだけインライン関数で分離すればいいじゃまいか
275デフォルトの名無しさん:2009/05/01(金) 21:46:51
インライン展開されたら最適化抑制も伝播したりして。
276デフォルトの名無しさん:2009/05/01(金) 22:26:45
>>273
いやいや、組込関数ならインラインアセンブラと違って最適化できるという触れ込みではなかったっけ?
277デフォルトの名無しさん:2009/05/01(金) 22:33:02
sse使って、まだコンパイラが入り込むある余地があるのか?
278デフォルトの名無しさん:2009/05/01(金) 22:37:15
xmmintrin.hなどの場合はxmmレジスタへの割付が最適化まかせなので、
最適化をしないと、1命令ごとにメモリとデータをやり取りするので非常に遅くなる。
279デフォルトの名無しさん:2009/05/01(金) 22:41:37
__m128iってクラスはレジスタ的なもので局所変数にしか使えないかと思ってたんだが、
実はvector<__m128i> みたいな使い方もありなの?
280デフォルトの名無しさん:2009/05/01(金) 22:45:35
typedef union __declspec(intrin_type) _CRT_ALIGN(16) __m128 {
     float               m128_f32[4];
     unsigned __int64    m128_u64[2];
     __int8              m128_i8[16];
    : 略
 } __m128;

てな感じで普通にメモリ上にとられるよ。最適化でレジスタに置きっぱなしになる。
281279:2009/05/01(金) 22:54:29
そうなのか。ありがとう。
282デフォルトの名無しさん:2009/05/01(金) 23:33:29
組み込み関数の最適化は
lstファイルでも出力して見てみるといいよ。
一応されるようだよ。
283,,・´∀`・,,)っ-○○○:2009/05/01(金) 23:35:01
GCCはpshufb周りのコード生成が酷い。
284デフォルトの名無しさん:2009/05/01(金) 23:36:16
まあgccはコードジェネレーター部がx86決め打ちじゃなくて汎用だからな
285,,・´∀`・,,)っ-○○○:2009/05/01(金) 23:48:38
_mm_set1_epi8()相当のことやろうとしたんだけどさ
_mm_shuffle_epi8(_mm_cvtsi32_si128((int)c), _mm_setzero_si128());

ってやるじゃん。Intel先生は当然のごとくこういう風に生成するだろ。

pxor xmm0, xmm0
movd xmm1, DWORD PTR [esp+4]
pshufb xmm1, xmm0

3行で済むことを6行もかける馬鹿コンパイラ

pxor xmm0, xmm0
movd xmm1, DWORD PTR [esp+4]
movss xmm0, xmm1
pxor xmm1, xmm1
pshufb xmm0, xmm1
movdqa xmm1, xmm0

飽くまでカンだけど、pshufbの引数の順番間違えてて、応急処置的に直したんじゃないかと思うんだ
286デフォルトの名無しさん:2009/05/02(土) 01:55:20
そういうときはgccのソース読むのが基本だろ。
287,,・´∀`・,,)っ-○○○:2009/05/04(月) 14:47:39
insn-attrtab.cが酷いな。SSSE3以降の命令の扱いがテキトーすぐる。
288,,・´∀`・,,)っ-○○○:2009/05/04(月) 17:26:36
>>279
処理系によっては自作アロケータで128ビットアラインされた領域に確保するようにしないと酷いことになるかもしれません。
289デフォルトの名無しさん:2009/05/04(月) 21:03:31
GCCはGPLなんだから文句ばっかり行ってないでお前らも
プロジェクトに参加して改良しろよ
290,,・´∀`・,,)っ-○○○:2009/05/04(月) 21:09:55
それは本末転倒。アセンブラよりも作業効率を期待してCコンパイラで生成できないか試みてるのに
いっそう手間かけてどうすんだと。別にGCCである必要ないんだよ。
っていうかオープンソース界隈は今頃AMD SSE5がキャンセルで大荒れだと思う。
291デフォルトの名無しさん:2009/05/04(月) 21:36:28
まあ、正論だな
292デフォルトの名無しさん:2009/05/04(月) 22:21:05
ダンゴさんの正論でスレがピリッと引き締まったな。
293デフォルトの名無しさん:2009/05/04(月) 22:51:03
キャンセルって何の事って調べたら・・・
俺的にはAVX一本のほうが楽でいいな。AMDは正しい判断をしたと思う。
当初の予定はSSSE3もSSE4もサポートせずに、SSE5追加だけだったよね?
294,,・´∀`・,,)っ-○○○:2009/05/04(月) 22:54:08
いや、元々SSSE3はSSE5と一緒に追加、SSE4.1/4.2は順次対応する予定だったと思う
295デフォルトの名無しさん:2009/05/05(火) 21:04:42
Intel様、3Dゲームとか画像とか動画エンコとか特殊な用途向けよりもっと一般人が
恩恵をうけれるような命令を追加して下さい。といいつつ、マイナーな事言いますが、
IEEE754Rで改訂された10進浮動小数点の命令を追加して下さい。
296,,・´∀`・,,)っ-○○○:2009/05/05(火) 21:10:40
一般用途とかけ離れてるだろ10進浮動小数なんて

金融演算でもやるのか?
297デフォルトの名無しさん:2009/05/05(火) 21:38:01
>>296
そうです、金融がらみとかです。
298デフォルトの名無しさん:2009/05/06(水) 20:28:58
>>290-292
一度実装すれば以後恩恵を受けられるわけだし、そもそもサポート契約してないなら、正論とは言えないだろう。
299,,・´∀`・,,)っ-○○○:2009/05/07(木) 01:20:09
本来そういうのはハードベンダーが技術協力名目でやるものだろう
300デフォルトの名無しさん:2009/05/07(木) 01:49:26
インテル様はインテル・コンパイラを買えと仰っているからなぁ。

gccのauthorに-○○○@2ch.netとでも付け加えた方が
トータルで安く上がるだろ。
301,,・´∀`・,,)っ-○○○:2009/05/07(木) 02:06:08
Intelコンパイラもたいがいだよ。
_mm_set1_epi8()はCore 2以降でなら>>285の実装のほうが速いのに
-QxSSE4.1とか加えても使ってくれないのはどうしたものかね

_mm_set1_epi1(0)を pxor (_mm_setzero_si128()相当)に置き換えるのはさすがにやってくる
302デフォルトの名無しさん:2009/05/08(金) 06:17:11
メディアンフィルタの高速なアルゴリズムを教えてください。
複数のピクセルから中央値を選べばいいだけなのですが、
ifステートメントを避けて並列化する方法はないでしょうか?
303デフォルトの名無しさん:2009/05/08(金) 07:32:50
それを考えるのが面白いところなのに・・・
304,,・´∀`・,,)っ-○○○:2009/05/08(金) 20:51:11
305,,・´∀`・,,)っ-○○○:2009/05/08(金) 21:27:34
ちなみに言うと8要素のソートして真ん中の値をとればいいだけ。
pmaxub/pminubを使うことで大小入れ替えができる

ちょっと考えてみたが愚直な並列バブルソートでpmaxub/pminubを合計40回程度かな?
それでも1要素あたりにすると2.5回の比較で済む。
まあ、ベクトルのセットアップがちょっとばかし大変だが。
306デフォルトの名無しさん:2009/05/10(日) 00:07:29
8?
307,,・´∀`・,,)っ-○○○:2009/05/10(日) 00:25:33
自身含めて9か。
すまん素で間違えた

3.5命令・・・うーん
308デフォルトの名無しさん:2009/05/10(日) 11:17:30
ダンゴさん何者なんだw CPUに詳しいな。
309デフォルトの名無しさん:2009/05/10(日) 12:49:10
ダンゴさんへの賞賛でスレがヒートアップしたな
310デフォルトの名無しさん:2009/05/10(日) 16:54:52
AGIストールとかパイプリングストールとか意味がわかりまセンチ
311,,・´∀`・,,)っ-○○○:2009/05/11(月) 21:36:15
だんごー
だんごー
312デフォルトの名無しさん:2009/05/11(月) 21:54:38
だんごー
だんごー
だんごー大家z(ry

だんごさんって鳥の方の人かしら。
もしそうだとすると、数年前に某荒板でCPUのこととかお話した元コテですがお久しぶりです(´・ω・`)ノ
人違いだったらごみんなさい。
313,,・´∀`・,,)っ-○○○:2009/05/11(月) 21:58:28
島は鳥の左側です。
314デフォルトの名無しさん:2009/05/11(月) 22:15:09
レフトシフト
315デフォルトの名無しさん:2009/05/12(火) 12:56:48
おまえらだんごさんがいるうちにいっぱいためになる話聞いておけよ。
316 ◆0uxK91AxII :2009/05/12(火) 20:00:05
いっぱいだめになる話?
317デフォルトの名無しさん:2009/07/11(土) 00:34:33
itoaを高速に書く場合
どうやってかけばいいのですか?

val % 10なんかで基数割してると
遅くてダメポなんですが.......
318デフォルトの名無しさん:2009/07/11(土) 01:17:42
除算が遅いなら0.1を乗算すりゃいいじゃない
319デフォルトの名無しさん:2009/07/13(月) 07:47:59
100でやれば除算回数が半分になる
320デフォルトの名無しさん:2009/07/13(月) 10:41:55
テーブル引け
321デフォルトの名無しさん:2009/07/15(水) 21:23:00
,,・´∀`・,,)っ-○○○先生
おられませんかー?
322デフォルトの名無しさん:2009/07/16(木) 00:33:39
>>317
一体何桁の数字を変換したいんだ?
速くしたけりゃベクトル化すればいいだろ。
323デフォルトの名無しさん:2009/07/16(木) 00:41:13
>>322
10桁っす
324デフォルトの名無しさん:2009/07/16(木) 23:15:35
fbstpとか
10桁は遅いか
325デフォルトの名無しさん:2009/07/17(金) 01:49:04
いっそ数値の方をBCDにしちまえ
ついでにCPUを6502にだな
326デフォルトの名無しさん:2009/07/17(金) 02:15:08
10桁の数字を何回処理してどの程度時間がかかり、
どれだけ高速化したいのか位は言えよ。
327デフォルトの名無しさん:2009/07/18(土) 18:37:21
fildしてfbstpするのが速そうではあるね
328 ◆0uxK91AxII :2009/07/18(土) 21:15:36
基数は可変...っと。
ふつーitoaの高速化は無意味。
329デフォルトの名無しさん:2009/07/18(土) 21:35:05
> 基数は可変...っと。
それitoaじゃねー。
330,,・´∀`・,,)っ-○○○:2009/07/31(金) 20:55:39
x86のAAMとかAADの基数って変えられたよな?
Opcodeがないからマシンコード直打ちになるけど
331デフォルトの名無しさん:2009/08/27(木) 19:59:33
if (a>=b) a = 0;
これから条件分岐を取り除くにはどうすれば良いですか
332デフォルトの名無しさん:2009/08/27(木) 21:32:22
(void)(a >= b) && (a = 0));
333デフォルトの名無しさん:2009/08/27(木) 21:33:42
余計な括弧がついていた
(void)(a >= b && (a = 0));
334デフォルトの名無しさん:2009/08/27(木) 21:50:02
それってアセンブラレベルでは分岐してないか?
335デフォルトの名無しさん:2009/08/27(木) 21:54:03
アセンブラ以前に分岐しとるがな
if構文を使ってないだけでしかない
336,,・´∀`・,,)っ-○○○:2009/08/27(木) 22:50:17
なぜ条件分岐を取り除きたいの?

倍精度・スカラだとこんな感じ

movsd xmm1, dword ptr [b]
movsd xmm0, dword ptr [a]
cmpgtsd xmm1, xmm0
andpd xmm0, xmm1
movsd dword ptr [a] xmm0

で、もっとも移植性の高く速いコードを生成する可能性の高い俺の回答はこれ。
a = (a >= b)? 0 : a;

っていうかConditional MOVEとかプレディケートの仕組みをハード的にサポートしてるCPUでないと
根本的に高速化にならないと思うんだ。
なんのために分岐を除去するのか、本末転倒な解決策でもいいなら、他にいくらでも方法はある。

337デフォルトの名無しさん:2009/08/27(木) 23:53:51
つーか三項演算子ってもともとハードがサポートしてるから、それを利用する為に作られたってどこかで読んだような。
x86がサポートし始めたのがC言語の登場に比べれば割と最近だからまるで最新技術のような錯覚を覚えるけどな。
338,,・´∀`・,,)っ-○○○:2009/08/28(金) 01:14:14
Pentium Proが出た時期を最近とか言っちゃうか?
それを最近って言っちゃうならRISCでプレディケートをサポートするCPUはかなり新しい部類だよだよ。
分岐のオーバーヘッドを軽減するための機構が必要になったのはパイプラインが深いCPUが出だした頃の話だからな。
分岐(条件ジャンプ)が相対的にボトルネックになったのが動機。



つーか、Pentium Proの更に10年前、386の頃からCコンパイラはあったろ?



あと、こんなブログ見つけた
http://keisanki.at.webry.info/200908/article_8.html

これARMそのまんまだな
339デフォルトの名無しさん:2009/08/28(金) 01:22:30
Conditional MOVEで思い出したけど、cmovcなどのフラグレジスタを見るものは、前の演算結果が出るまでストールするから、普通に条件分岐するより遅くなることが多いって本当?
340,,・´∀`・,,)っ-○○○:2009/08/28(金) 01:41:24
>>339
大嘘

>前の演算結果が出るまでストールする

これは大いなるミスリード。
CMOV命令の結果に依存しない命令は先行実行出来るだろ?
パイプラインの充填率を高める努力を怠ってはならない

>普通に条件分岐するより遅くなることが多いって本当?

分岐予測の精度と頻度によってはそうなる「こともある」程度
一般的には単純な3項演算に展開出来る程度の条件分岐ならCMOVのほうが速い
341デフォルトの名無しさん:2009/08/28(金) 01:48:24
そうだったのか
サンクス
342,,・´∀`・,,)っ-○○○:2009/08/28(金) 01:50:23
if - else のブロック中の演算式がいくつもあるようなのをcmovに展開して速くなるかって話なら
流石に無理。そういうイチャモン付ける奴は単に使い分けを見誤ってるだけ。
343デフォルトの名無しさん:2009/08/28(金) 03:35:55
a &= - (a >= b);
344デフォルトの名無しさん:2009/08/28(金) 03:37:43
あ、条件が逆だた
345デフォルトの名無しさん:2009/08/28(金) 12:36:47
>>343
どういう命令に展開されるか意識して書いてる?
cond?0:1が表記上省略されてるだけで、大概のCPUでは演算回数は増えてしまうと思われ

条件フラグ値を汎用レジスタに転送する命令があればそれを使うんだろうが、
それなら既にConditional-MOVEより条件は悪い

フラグ確定までフラグに依存関係のある命令は(投機)実行できないのは同じだからな
346デフォルトの名無しさん:2009/08/28(金) 16:30:21
だったら、最初のままでCMOVに展開されるから、何もしないでよい
で終了するだけじゃん。

コンパイラ次第だけど。
347デフォルトの名無しさん:2009/08/28(金) 16:35:24
あ、比較とandの場合は
(cmp xx,xx)の後、
sbb edx, edx
and eax, edx
の2命令。

cmov の場合も
即値が使えないから、メモリアクセスをしないよう
比較の前にレジスタクリアをしなきゃいけないし
xor edx, edx
(cmp xx,xx)
cmovxx eax, edx
の2命令。
348デフォルトの名無しさん:2009/08/28(金) 18:58:47
cmp->sbb->andで依存関係が生じる。

cmovはというと、P6以降のアーキではxorによるゼロクリアはALUを消費せず
リザベーションにゼロを入れるだけの操作にデコードされるから
実質cmp+cmovの2命令分のコストだけだな
349デフォルトの名無しさん:2009/08/28(金) 19:13:14
そう言えばcmovを吐くコンパイラって見た事ないな
大抵前者のコードを吐く
350,,・´∀`・,,)っ-○○○:2009/08/28(金) 19:34:15
単純にターゲットCPUがi386になってるからだろ。
351デフォルトの名無しさん:2009/08/28(金) 20:33:40
cmp+cmovにもマクロフュージョン効けばいいのに
352デフォルトの名無しさん:2009/08/28(金) 20:42:30
setccは普通に見るな
353デフォルトの名無しさん:2009/08/28(金) 20:46:10
げっごめんageになってた
354デフォルトの名無しさん:2009/08/28(金) 22:12:40
setccとcmovの違いが分からない
355デフォルトの名無しさん:2009/08/28(金) 22:25:02
>>348
ただ、その分レジスタを消費するけどな。
内部的なレジスタリネーミングという話でなく、
アクセス可能なレジスタが足りずに内容を退避する必要が出て来るケースもある。

また、単純な比較命令ではなくサブルーチンコール等をまたぐ場合
フラグ保持のためにxor等でのクリアは使えない。
比較の後にmovで0を入れる等だと、「ゼロクリア時の特別扱い」の利点が弱くなる。

あと、当然だがcmovはP6以降。
まあこれは現在は問題にならないかもしれないけどね。
356デフォルトの名無しさん:2009/08/28(金) 23:02:06
>>354
Intelが配布してるPDF見ればいいじゃん
cmovは条件が一致した時にソースをディスティネーションに転送する
setccは条件が一致した時にレジスタを1に設定、それ以外は0に設定する

C言語の場合条件は0か1で判定できるのでsetccで十分な場合が多い
但しcmov使った方がより短縮できる事もある
357,,・´∀`・,,)っ-○○○:2009/08/28(金) 23:10:08
>>355
どんだけカツカツなんだよ

XMMレジスタにでも退避しろやwww
358デフォルトの名無しさん:2009/08/31(月) 23:22:06
ダンゴさんって何者なんだw
359デフォルトの名無しさん:2009/09/08(火) 18:49:43
このダンゴって本物のダンゴなの?
i5ってどうなのーって聞いてみたいんだけど。
360デフォルトの名無しさん:2009/09/08(火) 20:07:19
だんごじゃないけどi5はi5だよ。それ以上でもそれ以下でもない。
361デフォルトの名無しさん:2009/09/08(火) 20:13:34
>>360
おめーみたいなカスには聞いとらん失せろゴミが
ダンゴさんマダー?
362,,・´∀`・,,)っ-○○○:2009/09/08(火) 20:47:27
i7にしろや
363デフォルトの名無しさん:2009/09/08(火) 21:25:40
>>361
ちょwだれww
ほれ、なんかcore2の時とかこれはいいぜーとかなんか詳しく言ってたような気がしたから
i7なりi5なりのアーキテクチャ面からの意見を聞いてみたかったんだ
364,,・´∀`・,,)っ-○○○:2009/09/08(火) 21:36:21
Phenom 2も悪くないCPUだから好きなの選べ。
365デフォルトの名無しさん:2009/09/09(水) 02:09:19
>>363
i7ー900はメモリ周りが速い。(トリプルチャネル)
i5/i7(デュアルチャネル)で少し遅い。でもCore2よりは速い。
さあ選べ。
366デフォルトの名無しさん:2009/09/09(水) 02:24:23
でもこれから6コアとか8コアとか12コアとか出てくるんだろ
少しでもFSBが速くないともっさりしてくるのは確実
367デフォルトの名無しさん:2009/09/09(水) 02:33:02
>>365
Core2とi7を比較すると、とりあえずメモリが速いのと、デュアルコア*2からクアッドコアになったという利点が
あるのはわかる
i5はコア間でのやりとりがずいぶん遅いらしいので、場面によっては結構な影響を与えそう

iシリーズになって各命令が要するクロックとかパイプライン周りは変わってないの?
368デフォルトの名無しさん:2009/09/09(水) 03:50:34
>>367
>iシリーズになって各命令が要するクロックとかパイプライン周りは変わってないの?
そのあたりは余り変わっていないと思われるが、大きく変わっているのはSSE4.2?(4.3だったか?)になっている。
メモリ周りと、キャッシュ周りが大きく変わっているので、iシリーズ用に最適化すると早くなるかもしれない。
iシリーズはQPIが速いので、Core2シリーズよりマルチプロセッサになったとき速い。
いずれにしてもメモリ帯域がボトルネックになりそうなプログラムを書くなら、
iシリーズを使った方がパフォーマンスが出る。
キャッシュに収まるレベルで、SSEの新機能を使わなければあまり変わらない。
今からならCore2Quadよりもi5の方がいいと思う。

369デフォルトの名無しさん:2009/09/09(水) 04:17:10
i7って64bit時のパフォーマンスはどうなの?Core2より良いという話を聞くけど。
370デフォルトの名無しさん:2009/09/09(水) 06:03:53
良いと言われる理由は、Core 2と違ってMacro-Op Fusionが64ビットでも使えることだったと思う。
371デフォルトの名無しさん:2009/09/09(水) 17:21:56
2のx乗(xはfloat、絶対値が100未満)を、テーブル参照やFPUなしで、SSEで4並列処理できませんか?
精度は6bit程度で十分なんですが
372デフォルトの名無しさん:2009/09/09(水) 20:19:58
無理ぽ
373デフォルトの名無しさん:2009/09/09(水) 20:23:04
374,,・´∀`・,,)っ-○○○:2009/09/09(水) 22:32:19
整数乗なら簡単
指数部に加算するだけですむからな
375デフォルトの名無しさん:2009/09/09(水) 22:51:39
お前ら文盲か?
可能なら方法を書け。
できないならできないと書く。
わからないなら黙って首吊って死ね。
376デフォルトの名無しさん:2009/09/09(水) 22:56:14
で、それは4並列可能なの?
377,,・´∀`・,,)っ-○○○:2009/09/09(水) 23:12:26
整数+小数点以下にわけて

整数部は指数部直接操作
あと小数点以下はpshufbで勝つる
378デフォルトの名無しさん:2009/09/09(水) 23:19:12
釣りにすらならねえ。。。
379デフォルトの名無しさん:2009/09/10(木) 00:03:24
>>373
これ凄いですね
VS2005では_mm_castがないようなので、*(__m128i*)&に直してコンパイルを通しました
自前で用意した64kBのテーブルがばっさり不要になりました
log10を求める処理もあるので、log2のソースと底の変換を使うことでこのテーブルもなくなりました
書き忘れでSSE2までという条件がありましたが、これも満たしていました
完璧です。ありがとうございました
380デフォルトの名無しさん:2009/09/10(木) 00:11:34
あれ。Debugだと上手くいきますが、Releaseだと0とか負の無限大になってしまいますね
直接アセンブラに落として使います
381デフォルトの名無しさん:2009/09/10(木) 00:34:34
連カキ失礼します
Releaseだと、__m128への代入の時点でスタックが何バイトがずれるようです
この後でカウンタを1加算する処理がありますが、0に1を足して1になるはずが-2になっていてびっくりしました
_m128をグローバル変数に置いたら直ったので、とりあえずこれで誤魔化します
382デフォルトの名無しさん:2009/09/10(木) 00:35:11
おい!テーブル使わん言ったじゃねえかよ。死ねカス。
383デフォルトの名無しさん:2009/09/10(木) 01:30:43
>>382
>>373
> Polynomial
384デフォルトの名無しさん:2009/09/10(木) 08:35:36
>>382は本当にカスだな
385デフォルトの名無しさん:2009/09/11(金) 01:21:58
>>382
テーブルと多項式の比較だから、下の方を見てみよう。
386デフォルトの名無しさん:2009/10/08(木) 03:31:44
頻繁に整数を6で割った余りを使うプログラムなんですが、
除算が1回40クロック以上もかかると聞いて以下のようなロジック組んでみました。
試してみると若干早くなってるような気もしますが、
これは効率的って言えますかね?
387デフォルトの名無しさん:2009/10/08(木) 03:33:43
unsigned int mod6(unsigned int m){
unsigned int a = 0;
static unsigned int x[] = {0,2,4,0,2,4,0,2,4,0,2,4,0,2,4,0,2,4,0,2,4,0,2,4};
__asm{
mov eax, m
test eax, 1
jz Mod3
inc a
Mod3:
shr eax, 1
lea ebx, x
mov edx, eax
and eax, 0000ffffh
shr edx, 16
add eax, edx
mov edx, eax
and eax, 0000003fh
mov ecx, edx
and edx, 00000fffh
shr ecx, 12
shr edx, 6
add eax, ecx
add eax, edx
mov edx, eax
and eax, 0000000fh
shr edx, 4
add eax, edx
mov edx, x[eax*4]
add a, edx
}
return a;
}
388デフォルトの名無しさん:2009/10/08(木) 03:38:11
条件分岐入れるくらいなら素直に割れ。
389デフォルトの名無しさん:2009/10/08(木) 03:47:13
考え方としては、偶数ビットシフトしても3で割った余りは変わらない
(ただしシフトして消える部分に立ってるビットがない場合のみ)のを利用します。

まず2の剰余を取った後、値を半分にして6の剰余から3の剰余の問題に変えます。
上位16ビットと下位16ビットを加算して17ビットに落とし、
6ビット/6ビット/5ビットに分割して加算して8ビットに落とし、
上位4ビットと下位4ビットに分割して加算して5ビットに落とし、
最後にテーブル参照して、その時点の3の剰余の2倍の値に変換して
最初の2で割った余りを足します。
390デフォルトの名無しさん:2009/10/08(木) 03:59:17
>>388
条件分岐ダメですか?

もう一個レジスタ使って

mov edi, eax
and edi, 00000001h



add edx, edi
mov a, edx

ってやり方にもできますが。
391デフォルトの名無しさん:2009/10/08(木) 04:44:47
x[]を読みに行く方が遅い説
392デフォルトの名無しさん:2009/10/08(木) 07:17:20
・6割り算は本当にボトルネックか。
他にどうしようもなく遅い処理があるなら6割り算は無視していいはず。
6割り算だけする関数を作ってそれを呼ぶようにし、インライン展開を抑制してプロファイルを取るくらいはすべき。

・6割り算の代わりに6掛け算は使えないか。
つまり、データの持ち方を工夫して高速化したい処理全体で6で割った商と余りを利用するようにすれば割り算は無視できるはず。
余りも要らないなら、メモリコストも増えないだろう。

・値域はどのくらいか。配列参照で代用できないか。
値域が16ビット程度なら高高数十キロのメモリしか使わないで実現できる。巧くキャッシュに乗れば、速いかもしれない。
393デフォルトの名無しさん:2009/10/08(木) 08:35:44
実に適切なレスだな、感動した
394デフォルトの名無しさん:2009/10/08(木) 09:07:56
結論

人間よりコンパイラの方が賢い
395デフォルトの名無しさん:2009/10/08(木) 09:18:27
コンパイラを作ってる人たちより賢いユーザは極少数
396デフォルトの名無しさん:2009/10/08(木) 12:56:15
とも限らない
397デフォルトの名無しさん:2009/10/08(木) 14:35:29
ゆとりはRDTSCの使い方も知らんのか
398デフォルトの名無しさん:2009/10/08(木) 14:50:11
ちょっと面倒
399デフォルトの名無しさん:2009/10/08(木) 15:58:42
逆数乗算で商を求めて元の値から引いたほうが速い
今のCore MAでは整数乗算は浮動小数除算機と兼用してて
非除数 − (除数×小数点以下切り捨てた商)

まあベンチ取ってみればわかるがコンパイラの吐くコードにも勝てんと思う
400デフォルトの名無しさん:2009/10/08(木) 15:59:25
整数 ×乗算は ○乗算は 浮動小数除算機と兼用してて
401デフォルトの名無しさん:2009/10/08(木) 17:45:39
static const int rcp6 = 1.0 / 6.0 * std::pow(2.0,16.0);
int x = 255 - ((255 * rcp6) >> 16) * 6;

確かにこれで十分な気がするし、>>387より速そうだ。
402 ◆0uxK91AxII :2009/10/08(木) 18:41:36
結果を使う40clk程度過去に除算を投げておくとか:b
403387:2009/10/08(木) 21:02:29
申し訳ないけど俺のレベルが低すぎてまったく理解できん。

>>399
その「小数点以下切り捨てた商」はどうやって出したらいいの?

>>401

考え方だけでも教えて欲しい。
404デフォルトの名無しさん:2009/10/08(木) 21:55:29
ここはアホしかいないからビット演算スレで適当に質問した方がいいよ
405デフォルトの名無しさん:2009/10/08(木) 21:57:06
>>403
x / 6 = x * 1 / 6
これで、除算がなくなる。
ただ、1/6は小数点数になるから、整数演算じゃ表現出来ない。

>>399は、整数演算も少数演算もコストは同じだから少数でやれと。
>>401は、一時的に2^16倍してるだけ。

>その「小数点以下切り捨てた商」はどうやって出したらいいの? 
std::floor(x * 1.0 / 6.0)
406デフォルトの名無しさん:2009/10/08(木) 22:29:32
手持ちのコンパイラで
int hoge(int a)
{
 return a % 6;
}
をコンパイルしてasm吐かせてみてよ
div使われてないと思うよ
407デフォルトの名無しさん:2009/10/08(木) 23:14:01
VC9だとこうなった。
// const int x  = argc%6;
    mov ecx, DWORD PTR _argc$[esp-4]
    mov eax, 715827883              ; 2aaaaaabH
    imul    ecx
    mov eax, edx
    shr eax, 31                 ; 0000001fH
    add eax, edx
    lea eax, DWORD PTR [eax+eax*2]
    add eax, eax
    mov edx, ecx
    sub edx, eax

↓このブロックでargc/6を計算しているようだが、意味不明w
    mov eax, 715827883              ; 2aaaaaabH
    imul    ecx
    mov eax, edx
    shr eax, 31                 ; 0000001fH
    add eax, edx

つーか、eax * 3を計算するのに、LEAを使うのか。すげーなオイ。
408387:2009/10/08(木) 23:24:00
VC6だと確かにDIV使ってたんですが…

今VS2008インストールしてみたら確かに>>407みたいな感じでした。
符号なしの場合で、一部整理すると(popとかも省略)
__asm{
mov ecx, DWORD PTR [m]
mov eax, 0aaaaaaabH
mul ecx
mov eax, ecx
shr edx, 2
lea ecx, [edx+edx*2]
add ecx, ecx
sub eax, ecx
ret 0
}
ぐはっ、まったく意味がわかりません!
409デフォルトの名無しさん:2009/10/08(木) 23:45:46
VC5あたりで整数定数除算は掛け算になってたはず
剰余は確かめたことないな・・・

意味だけど、64bit固定小数点数で、小数点が32bit位置にあると考えると
(0x1_0000_0000 / 6) を掛けることは 6 で割ることになるでしょ

んでもって6掛けて元の数から引けば剰余になる
leaの計算は3倍してて、その後自身とのaddで2倍、都合6倍


>コンパイラを作ってる人たちより賢いユーザは極少数

ときどきasm吐かせてみたりしないと浦島太郎になるね。
410デフォルトの名無しさん:2009/10/08(木) 23:50:55
mingw32 gcc 4.4.0

_hoge:
  pushl  %ebp
  movl   %esp, %ebp
  movl  8(%ebp), %eax
  movl  $6, %edx
  movl  %edx, %ecx
  cltd
  idivl %ecx
  movl  %edx, %eax
  leave
  ret

あれ?
411デフォルトの名無しさん:2009/10/08(木) 23:53:54
マヌケなコンパイラだと大変ですね(^^)
412,,・´∀`・,,)っ-○○○:2009/10/09(金) 00:08:33
64ビット整数の3の剰余を分岐も乗算使わずにハイパー高速に求めるアルゴリズム

n ^= n >> 32;
n ^= n >> 16;
n ^= n >> 8;
n ^= n >> 4;
n ^= n >> 2;
n &= 3;
n ^= ((n&1) << 1) | (n >> 1);

後半はLUT使ったほうが速いかもな
413,,・´∀`・,,)っ-○○○:2009/10/09(金) 00:15:01
んで6の剰余ってこれでいいよな?

mod3(n >> 1) * 2 + (n & 1)
414デフォルトの名無しさん:2009/10/09(金) 01:24:41
>>387
inline unsigned int mod6(unsigned int a){
 unsinged int b = (a >> 3) + (a >> 5); // /6
 unsinged int c = (b << 1) + (b << 2); // *6
 return a - c;
}
415デフォルトの名無しさん:2009/10/09(金) 01:49:37
>>414
mod6 : 65536 % 6 = 4096
C    : 65536 % 6 = 4

mod6の/6が0.15625と、精度が悪いせいか?
416,,・´∀`・,,)っ-○○○:2009/10/09(金) 02:02:30
その通り
417,,・´∀`・,,)っ-○○○:2009/10/09(金) 02:09:39
でもまあショートカットとしては十分優秀だよ


SSEを用いた3の剰余のショートカット方法

movq xmm0, rcx
pxor xmm1, xmm1
psadbw xmm0, xmm1
movd ecx, xmm0

これで64ビットが11ビットくらいに縮まる
418414:2009/10/09(金) 02:22:00
>>415
//もうすこし高精度版
inline unsigned int mod6(unsigned int a){
 unsigned int b = a >> 1;
 unsigned int c = b + (b >> 2);
 unsigned int d = c + (c >> 4);
 unsigned int e = d + (d >> 8);
 unsigned int a_div6 = e + (e >> 16) - b;
 unsigned int a_div6_mul6 = (a_div6 << 1)+(a_div6 << 2);
 return a - a_div6_mul6;
}
419デフォルトの名無しさん:2009/10/09(金) 02:33:18
あんたらよくやるよ
templateで、任意除数版を作ってくれたら
俺様のライブラリに加えてやってもよいぞよ
420デフォルトの名無しさん:2009/10/09(金) 02:34:59
>>419
コードが膨らんでキャッシュの効きが悪くなりそう
421,,・´∀`・,,)っ-○○○:2009/10/09(金) 03:27:52
>>417
GCC4.4で-O3 -march=core2でコンパイルして
なぞの某パイプラインシミュレータ通したらトータルレイテンシ20サイクル, スループット10サイクルって出た

俺の>>412-413使った方法だとレイテンシ18と6
後半テーブル化すればもう少し減りそう
0, 1, 2, 3になったときに3だけを0に丸めるためだけにあほなビット演算やってるが
なんとかならんかな
422-〇〇〇:2009/10/09(金) 10:10:58
>>412は嘘ですたorz
シフト+加算ならいけるんだが
423デフォルトの名無しさん:2009/10/09(金) 11:19:23
団子かわいいよ団子
424デフォルトの名無しさん:2009/10/09(金) 14:26:12
signedだが
妙に凝ったことやるよりこれが一番速いだろ
inline int mod6(int n) { return n - (_mm_cvttsd_si32(_mm_mul_sd(_mm_set_sd(n), _mm_set_sd(1.0/6))) * 6); }
425デフォルトの名無しさん:2009/10/09(金) 19:44:48
mm...mmmとか読みにくくてかなわん
DirectXみたいなセンスが欲しい
426デフォルトの名無しさん:2009/10/10(土) 01:05:31
……?
427デフォルトの名無しさん:2009/10/10(土) 14:56:58
これがエスパー戦争の始まりである
428デフォルトの名無しさん:2009/10/10(土) 14:59:45
結論

inline int mod6(unsigned int n) { return n%6; }

でおk
429,,・´∀`・,,)っ-○○○:2009/10/11(日) 03:12:20
unsignedだとLSB保存して1ビット右シフトすればsignedで扱える
あとは>>424の方法でmod3を求めて2倍してLSB足せばOK

整数ベースでやるにはレイテンシ1の命令だけでなんとか工夫しないと
ちなみにpsadbwはレイテンシ3だからイマイチ
解説してなかったけどpsadbwが使える理由は

mod3(A * 2^24 + B * 2^16 + C * 2^8 + D)
= mod3(A + B + C + D)

だから。
A * 256 + B = (A * 255) + A + B
430,,・´∀`・,,)っ-○○○:2009/10/11(日) 04:20:21
まあしかし、6の剰余程度だといずれの方法も大した意味は無いな
http://www.wikihouse.com/x86clocker/index.php?div%CC%BF%CE%E1%A4%CE%A5%EC%A5%A4%A5%C6%A5%F3%A5%B7
431デフォルトの名無しさん:2009/10/11(日) 05:07:16
CedarMillの88クロックってひどいな。
432デフォルトの名無しさん:2009/10/12(月) 21:07:44
AMDがいきなりパなしてきたが・・・
ttp://developer.amd.com/CPU/LIBRARIES/LIBM/Pages/default.aspx
433,,・´∀`・,,)っ-○○○:2009/10/12(月) 21:27:20
この手のはIntelコンパイラに標準で付いてきてるんだがな。まあ有償だが。
どのみちプロプライエタリならGPL/LGPLには組み込めん。
434デフォルトの名無しさん:2009/10/12(月) 23:23:36
>>432
こういうのはコンパイラがチート使ってくれなきゃ
威力半減な気がするんだが、どうなのかね?
435デフォルトの名無しさん:2009/10/12(月) 23:26:12
それをするのがコンパイラの仕事だろ
436,,・´∀`・,,)っ-○○○:2009/10/12(月) 23:28:45
AMDは自社コンパイラを持ってないからな(あのお粗末なAMD Stream SDK以外)
437デフォルトの名無しさん:2009/10/14(水) 22:23:37
スカラなんかどうでもいいよ。
SIMDをどうにかしろバカIntel。
438,,・´∀`・,,)っ-○○○:2009/10/14(水) 23:00:54
SIMDでどうにかしろ
439デフォルトの名無しさん:2009/10/16(金) 01:11:17
SIMDとか用語が嫌になる
しむど!
かっこわるー
440,,・´∀`・,,)っ-○○○:2009/10/16(金) 01:12:15
ネイティブはシムディーって言ってるぞ
441デフォルトの名無しさん:2009/10/16(金) 01:27:21
MMX
むむっくす!
かっこわるー
ネイティブでは?
442デフォルトの名無しさん:2009/10/16(金) 11:21:57
えめめくす
443デフォルトの名無しさん:2009/10/16(金) 20:57:46
かっこわるー
444デフォルトの名無しさん:2009/10/17(土) 04:41:05
はいはい無限再帰無限再帰
66 e8 fc ff
445デフォルトの名無しさん:2009/10/17(土) 23:55:00
かっこいいと思った用語

XMS
EMS
VMS

なんと!最後にMSが付く・・・・
446デフォルトの名無しさん:2009/10/17(土) 23:58:17
あっちがっ・モビルスーツ!だからね!
まい・・・・じゃないんだからね!
誤解しないでよね!
↓死ねよガンオタしないでよね!!
447,,・´∀`・,,)っ-○○○:2009/10/18(日) 00:00:55
>>445
腹筋運動マシン?
448デフォルトの名無しさん:2009/10/18(日) 00:15:39
XMS
EMS
VMS
IMS
OMS
UMS
SMS
449デフォルトの名無しさん:2009/10/20(火) 21:55:15
Large
Middle
Small
450 ◆0uxK91AxII :2009/10/20(火) 22:20:34
Long, Middle, Short corn.
451デフォルトの名無しさん:2009/10/21(水) 01:58:29
CMS忘れるなよ

Chinko Manko, Sexだけどな
452237:2009/10/21(水) 21:12:39
久しぶりにスレをのぞいてみたら、昔の自分のスレを発見。
そういや、こんなことしてたな。
団子さん、その節はお世話になりました。
あれからマシンもcore i7に代えたのでせっかくだからSSE4.2をためしてみた。
当たり前だけどやっぱり専用命令は速いね。
ところで_mm_popcnt_u32は使えたのに_mm_popcnt_u64はnot declared in this scopeって言われちゃった。
OSとかgccが32bitなのがいけないのかしら?
453,,・´∀`・,,)っ-○◎○:2009/10/21(水) 21:18:27
64bit専用です
454237:2009/10/21(水) 21:28:49
func =  reference :clock   =   14540000
func =        bit32 :clock   =    1710000
func =        bit64 :clock   =    4620000
func =           sse :clock   =     680000
func =  dango-sse :clock   =     430000
func =        sse42:clock   =     270000

文字数制限うぜぇ。削るのに手間取っちまった。しかも微妙にずれてるし。

455デフォルトの名無しさん:2009/10/21(水) 21:32:01
>>453
どもです。
世間がwindows 7 で64bitへ本格的に移行してくれることを期待してまつ。
456デフォルトの名無しさん:2009/10/22(木) 03:07:47
C/C++でメモリプール(int, doubleなど様々な型が共存)を作り、
メモリプール内部でメモリの詰め直しを行って最適化しようと試みています。

入門書+α(boostがわかるぐらい)なので、
キャッシュやメモリに関する特殊なことは全然わかりません。
何か気をつけなければならないことや忠告があれば教えてください。
457デフォルトの名無しさん:2009/10/22(木) 03:23:42
>>456
メモリのことを知らずにどうやって最適化する気なのかね?
458456:2009/10/22(木) 04:45:35
高速化が必要というわけではなくて、ガベージコレクションの宣伝文を見て
興味本位に詰め直しをやってみようと思いました。

空き領域を整えるだけでなく、アドレス配置を上手くソートすれば
キャッシュヒット率の向上ができると思いますが、それは難しいので
今回はプール内の空き領域を整えることだけに目的を留めて置きます。

プールはchar型の配列で確保し、memmove()でclassやプリミティブを
移動させる予定です。何か規則に反することなどがあれば教えてください。
459デフォルトの名無しさん:2009/10/22(木) 05:00:47
そんな無駄な事をする意味がわからない
460デフォルトの名無しさん:2009/10/22(木) 05:32:17
メモリコンパクションを実装するということは、
生ポインタから、ハンドル経由のアクセスに切り替えることになると思うけど
461456:2009/10/22(木) 06:01:05
>>460
自作のスマートポインタを利用してアクセスを管理する予定になっています。
スマートポインタとコンパクションが同一のスレッドになければ危険ですが。
462デフォルトの名無しさん:2009/10/23(金) 03:31:47
やってみりゃいいんじゃないの
463 ◆0uxK91AxII :2009/10/23(金) 04:39:52
下手の考え休むに似たり。
464デフォルトの名無しさん:2009/10/23(金) 04:48:37
バウンダリに気を付けろよ
465456:2009/10/23(金) 17:53:10
アライメント(構造体のサイズをバイトorワード境界に調整)はsizeof(...)使えば済むと思う。
でも開始アドレスもバイトorワード境界に調整する(これがバウンダリ?)のは知らなかった。

466456:2009/10/24(土) 01:53:17
いや、アライメントを制御することをバウンダリと呼ぶという記事を見つけた。
だとすれば開始アドレスは特に気をつけることはないはず……。
467デフォルトの名無しさん:2009/10/24(土) 02:02:00
他人に伝わらず、自分もよくわからない言葉を使うのは、とりあえずやめよう
468デフォルトの名無しさん:2009/10/24(土) 03:17:08
何のためにアドレス調整するのか分かってんのか?
469456:2009/10/24(土) 03:40:37
>>467
失礼しました。どうやら混乱してしまったようです。
とりあえず今日把握できた点について整理するために簡潔に書いてみます。

1.はじめに
32bitOSでは、4byte境界というものがある。
クラス・構造体であろうと、int,char,doubleなどのプリミティブ型であろうと、
インスタンスのサイズと開始アドレスは、4byte境界のルールに従うことになっている。。

2.サイズ
構造体やクラスは、4byte単位の大きさに整えられる場合がある。
以下のhogeクラスは5byteだが、4byte単位の大きさに整えられて8byteになる。
従って、sizeof(hoge)の返り値は8byteである。
ただしhelloクラスは4byte単位にされることはなく、
そのまま5byteなので注意が必要である。

class hoge
{
int i;
char c;
};

class hello
{
char c[5];
};
470456:2009/10/24(土) 03:41:53
続き

3.開始アドレス
インスタンスが4byte境界を踏み越えないように、注意しなければならない。
具体的には、以下のように分類してインスタンスを配置すれば良い。
(※以下は正しいのか非常に不安)

・4byte以上の大きさを持つインスタンスの場合
開始アドレスが、4の倍数となる番号になるように配置する。

・3byteの大きさを持つインスタンスの場合
開始アドレスが、4byteで割り切れる番号になるように配置する。

・2byteの大きさを持つインスタンスの場合
開始アドレスが、2の倍数となる番号になるように配置する。

・1byteの大きさを持つインスタンスの場合
どこでもよい


参考URL
http://park21.wakwak.com/~yuiti/program/c/08_boundary_c.htm
471デフォルトの名無しさん:2009/10/24(土) 03:49:04
OSつーか、ハードの制約では
472デフォルトの名無しさん:2009/10/24(土) 03:53:34
double(IEEE754)を4バイト境界なんかに配置しねーよ。
4byteだと、キャッシュラインをまたぐ位置に置かれる可能性が出てくるからな。
だから32bitOSだから4byteなんて話にはならない。
473456:2009/10/24(土) 04:45:04
>>471
>>472
ありがとう。わかった気がする。
アドレスの配置の仕方を訂正〜。

・8byte以上の大きさを持つインスタンスの場合
開始アドレスが、8の倍数となる番号になるように配置する。
(double=8バイトプリミティブを含む可能性があるため)

・4〜7byteの大きさを持つインスタンスの場合
開始アドレスが、4の倍数となる番号になるように配置する。
(int,float,longなど4バイトプリミティブを含む可能性があるため)

・3byteの大きさを持つインスタンスの場合
開始アドレスが、4の倍数となる番号になるように配置する。
(4バイト境界を越えないため)

・2byteの大きさを持つインスタンスの場合
開始アドレスが、2の倍数となる番号になるように配置する。

・1byteの大きさを持つインスタンスの場合
どこでもよい

(x86CPU環境限定)
474デフォルトの名無しさん:2009/10/24(土) 04:51:10
そろそろ愚行に気付けばいいのに・・・
475456:2009/10/24(土) 04:56:58
「32bitOSの境界は8byte」と認識するだけで十分ですね。
476デフォルトの名無しさん:2009/10/24(土) 05:40:30
真性のアフォだ
477デフォルトの名無しさん:2009/10/24(土) 07:24:51
javaもコンパクション捨てたよな
D言語は知らんが
478デフォルトの名無しさん:2009/10/24(土) 12:06:39
>参考URL
>http://park21.wakwak.com/~yuiti/program/c/08_boundary_c.htm

見てみたが、酷い内容だなw
479デフォルトの名無しさん:2009/10/24(土) 12:17:37
情報系の学校でも最近はいきなりJavaとかから入る所もあるらしいしなぁ。
480デフォルトの名無しさん:2009/10/24(土) 15:11:33
>>475
OSは全く関係ない。
関係あるのはCPUがメモリにアクセスする粒度。
同じハードウェアなら、16bitOSだろうか32bitOSだろうが64bitOSだろうが一緒。
481デフォルトの名無しさん:2009/10/24(土) 16:22:34
OS が関係あるとしたらミスアラインメント例外を捕捉して(処理速度以外は)
何も無かったかのように振舞う実装をしていた場合だな。
マニュアルとかには良く書いてあるけど、実際に実装されてる OS ってあるのかね?
境界跨ぎじゃなかったかもしれんけど、IRIX では何かやってたようななかったような。
482デフォルトの名無しさん:2009/10/24(土) 16:25:57
>>479
むしろ聞きかじり未満量産所
483デフォルトの名無しさん:2009/10/24(土) 16:29:11
>>481
Linux/ARM(規定で有効)
Windows/IA-64(規定で無効)
484デフォルトの名無しさん:2009/10/24(土) 16:36:56
Linux/ARMは規定有効じゃなかったわ
規定例外だけ無視だわ
485デフォルトの名無しさん:2009/10/24(土) 21:27:11
>>480
それ嘘だから
486デフォルトの名無しさん:2009/10/25(日) 05:24:36
456のベンチまだー?
487デフォルトの名無しさん:2009/10/28(水) 04:42:22
配列の合計値を求めたいのですが、コンパイラがSSEを使いやすいようなコードはどのように書けばよいのでしょうか?
488,,・´∀`・,,)っ-○○○:2009/10/28(水) 04:46:10
for (i = 0; i < N; i+=4) {
  sum1 += A[i];
  sum2 += A[i+1];
  sum3 += A[i+2];
  sum4 += A[i+3];
}
sum = sum1 + sum2 + sum3 + sum4;

っていうか組み込み関数使えよ
489デフォルトの名無しさん:2009/10/28(水) 04:54:38
ありがとう。
SSEに最適化された組み込み関数なんてあるんですか?
490,,・´∀`・,,)っ-○○○:2009/10/28(水) 05:02:38
_mm_add_ps
_mm_add_pd

491デフォルトの名無しさん:2009/10/28(水) 09:37:19
>>487
インテルコンパイラを使って、普通に書けばなんとかしてくれる。
# つーか、そのアセンブリ出力を読むのが先ず一歩目だと思う。
492デフォルトの名無しさん:2009/10/28(水) 09:37:28
xmmintrin.h
493デフォルトの名無しさん:2009/10/28(水) 21:37:44
そこを高速化して意味があるのかどうか検証するのが先だな。
494 ◆0uxK91AxII :2009/10/28(水) 22:28:29
モノによっては、配列に入れる際に和を求めるっていう手もあるワケで。
495デフォルトの名無しさん:2009/10/28(水) 23:17:40
まぁまずはどこがクリティカルなのかを割り出すのが一番大事だよな。
496デフォルトの名無しさん:2009/10/29(木) 01:40:16
>>490って>>488の処理の代替になる?
497デフォルトの名無しさん:2009/10/29(木) 08:42:12
>>488
これってNがわかっていないと、だめだよね?
ICCだと出来るのかな?
GCCでは無理だった。
498デフォルトの名無しさん:2009/10/29(木) 08:44:26
>>488
これってNがわかっていないとコンパイラはやってくれないよね?
ICCだと出来るのかな?
GCCではベクトル化してくれなかった。
499497:2009/10/29(木) 08:45:34
>>497
>>498

連投すまそ。書き込みが出来なかったと思った。
スレ汚し申し訳ない。
500デフォルトの名無しさん:2009/10/29(木) 11:47:52
>>498
Nが既知でなくてもベクタ化するよ。例えば4で割った余りの分は、ベクタ化しない処理になるだけ。
擬似的には>488にこれが追加されるだけ。
for (; i < N; ++i) {
  sum += A[i];
}
501デフォルトの名無しさん:2009/10/30(金) 00:02:08
>>500
そうなんだ。
以前やってみたときはaddssしか出さなくて、
addpsは使ってくれなかった。
ループが深すぎたからかなあ。
502,,・´∀`・,,)っ-○○○:2009/10/30(金) 00:04:30
Visual C++は何やってもベクトル化しないぞ
503デフォルトの名無しさん:2009/10/30(金) 03:22:53
>>502
GCCでもやってみたが、
#define N 4
__m128 vA[N],vB[N],vC[N];
float *A,*B,*C;
A = (float *)&vA;
B = (float *)&vB;
C = (float *)&vC;
for(i = 0; i < N*4; i+=4)
{
A[i+0] = B[i+0] + C[i+0];
A[i+1] = B[i+1] + C[i+1];
A[i+2] = B[i+2] + C[i+2];
A[i+3] = B[i+3] + C[i+3];
}
は出来なくて、
for(i = 0; i < N; i++)
{
vA[i] = vB[i] + vC[i];
}
これはやってくれたよ。

ICCならやってくれるのか?
504,,・´∀`・,,)っ-○◎○:2009/10/30(金) 07:55:04
for (i = 0; i < N; i+=4) {
  sum1 += A[i];
  sum2 += A[i+1];
  sum3 += A[i+2];
  sum4 += A[i+3];
}
sum = sum1 + sum2 + sum3 + sum4;

ちなみに>>488は手動でSIMD組み込み関数に置き換えやすい形に展開しただけ
コンパイラの自動最適化使うならここまでやる必要ない
505,,・´∀`・,,)っ-○○○:2009/10/30(金) 07:56:38
↑前文引用してどうする俺
506デフォルトの名無しさん:2009/11/05(木) 09:42:57
hello
507デフォルトの名無しさん:2009/11/05(木) 09:50:36
Meow
508デフォルトの名無しさん:2009/11/20(金) 16:36:44
高速道路無料化に関係ありそうだな( ・ω・)y─┛〜〜
509デフォルトの名無しさん:2010/01/28(木) 11:52:03
(__m128)num.m128_f32[0]=0;みたいな操作すると
error: request for member 'm128_f32' in 'num', which is of non-class type 'float __vector__'って
怒られるんだが原因わかる?そんなクラスタイプねーよと怒られてる気がするのでインクルード足りない気がするんだが。。。
環境はXcode 3.2にGCC 4.2です。
510デフォルトの名無しさん:2010/01/28(木) 12:11:25
(__m128)num->m128_f32[0]=0;
とかやらにゃならんとかいうオチではなかろうな?
511デフォルトの名無しさん:2010/01/28(木) 13:47:58
>>510
レスthx。試してみたがやっぱダメ。
根本的に__ml128構造体のメンバとしてm128_f32が無いんじゃないかとおもてきた。。。
512デフォルトの名無しさん:2010/01/28(木) 16:25:04
>>511
そうかもしれない。
自分とこのMinGW TDM gcc 4.4.1のxmmintrin.hを見たら次のように定義されていた。
typedef float __m128 __attribute__ ((__vector_size__ (16), __may_alias__));
513デフォルトの名無しさん:2010/02/11(木) 11:27:54
HTTPヘッダを高速に
解析する方法を教えてください
514デフォルトの名無しさん:2010/02/11(木) 14:01:37
ggrks
515デフォルトの名無しさん:2010/02/26(金) 18:21:28
http://pc12.2ch.net/test/read.cgi/tech/1264774545/904

なんかわからんけどこんな結論がでているっぽいんで助けてください
516デフォルトの名無しさん:2010/03/12(金) 14:45:40
>>515
該当スレは落ちている希ガス。
517デフォルトの名無しさん:2010/03/24(水) 22:25:30
保守
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
配列のデータをレジスタにセットするところもわかりません。
519デフォルトの名無しさん:2010/09/19(日) 21:15:01
ハッシュ計算で見たような式だな
MASMなら答えれたが残念だ
520デフォルトの名無しさん:2010/09/19(日) 22:02:24
95 :デフォルトの名無しさん:2010/09/19(日) 13:38:02
for(i=0;i<16;i++)
a[i]^=(d[i]+c[i])%16;
このプログラムをSSE2で書きたいのですがわかりません。
教えてください。よろしくお願いします。
521デフォルトの名無しさん:2010/09/20(月) 10:44:45
マルチポストか
522デフォルトの名無しさん:2010/10/11(月) 00:45:27
sse 4.2で大々的に文字列検索の命令追加されてたけど
あれ大文字小文字の変換とかサポートしてくれんの?
523デフォルトの名無しさん:2010/10/12(火) 01:43:07
無理じゃね?
単純一致だけだろ
524,,・´∀`・,,)っ[売り切れだよ]:2010/11/02(火) 14:12:47
>>522-523
Equal Anyモードでいけるでしょ。
http://journal.mycom.co.jp/photo/articles/2008/04/10/idf09/images/Photo46l.jpg

たとえば"hoge"を大文字小文字区別なしで検索するには、

まず [Hh] [Oo] [Gg] [Ee]の4つのベクトルに分け、ソース2として用いる。
ソース1には検索対象の文字列をロードし、まず[Hh]とのマッチ位置を検索する。
更にpalignrで1文字ずらして[Oo]とのマッチ判定、次は[Gg]とのマッチ判定。
以降、ecxのビットパターンのマスクをとっていって0になる、あるいは[Ee]に達するまで繰り返し。

マッチに失敗すれば次の16バイトをソース1に読み直してまた同じことをやる。


これ文字クラスとか簡単に表現できるよね。
正規表現のJITコンパイラとか作ったら爆速になりそうだから誰か試してみない?
もっとも、SSDでも積まないと大した効果なさそうだけど。
525デフォルトの名無しさん:2010/11/16(火) 22:35:23
SSEに関する参考書とかってあるんですか?
526デフォルトの名無しさん:2010/11/16(火) 23:17:26
>>525
団子と寝るか5万払って買ってる
527デフォルトの名無しさん:2010/11/17(水) 18:09:36
『MMXテクノロジ最適化テクニック』で基本的なことを覚えて
SSE以降はIntelのマニュアルで独学した
528デフォルトの名無しさん:2010/11/17(水) 21:24:25
ナカーマ
俺はノンケじゃwwww
530デフォルトの名無しさん:2010/11/18(木) 09:35:06
女子中学生かもしれんやん。
531デフォルトの名無しさん:2010/11/26(金) 09:33:13
みんなプロファイラは何使ってるの?

VTune と AQTime の評価版を落としてきて試したんだけど、結果が結構違う。
手法とかが違うのかな。
AQTime は計測対象のプログラムの動作が遅くなるから侵入型なんだろうか。
これは Windows での話ね。
532デフォルトの名無しさん:2010/11/27(土) 23:26:04
AMDのプロファイラが世界で一番正確
研究者はAMDのプロファイラしか使わない

正真正銘プロのツールだよね
533デフォルトの名無しさん:2010/11/29(月) 01:19:07
>>532
ヤな言い方だな。何か AMD に恨みでもあるの?
534デフォルトの名無しさん:2010/11/29(月) 01:56:52
タダのネタでしょ
反応するほうが信者臭がしてキモイ
535デフォルトの名無しさん:2010/11/30(火) 07:11:38
自演乙
536デフォルトの名無しさん:2011/01/12(水) 22:32:18
for(int i=0; i<N; i++){
sum += a[i];
}

これってベクトル化効きませんかねぇ・・・
537デフォルトの名無しさん:2011/01/12(水) 22:35:40
それも分からんようなら諦めな
538デフォルトの名無しさん:2011/01/12(水) 23:25:35
というか*aとsumが浮動小数点数ならgccでもiccでも自動ベクトル化してくれるが。
問題は、メモリがボトルネックだからそんなの意味ないという事だ。
539デフォルトの名無しさん:2011/01/28(金) 11:43:56
x86は浮動小数点が弱くて仕方がないからなあ
8087のコプロセッサの頃からの負の遺産を引きずっている
でもL1/大容量L2キャッシュを媒介にする事によって相当克服して来てはいるんだけどな
PowerPCなどにどうしても勝てない
540デフォルトの名無しさん:2011/01/28(金) 11:54:51
釣れますか?
541デフォルトの名無しさん:2011/01/28(金) 13:20:30
お前が釣れた
542デフォルトの名無しさん:2011/01/28(金) 13:34:01
>>539
インテルは不動整数点が抜群に早い
543デフォルトの名無しさん:2011/01/28(金) 20:33:11
糞環境でちまちま最適化した後に
インテルチップでてきとーにビルドしたプログラム走らせると絶望できる
>>539
前世紀からタイムスリップしてきた人乙
理論値こんなもん

Core i7 2600(3.4GHz)
54.4GFLOPS/27.2GFLOPS(DP)

POWER7(4.1GHz)
32.3GFLOPS(SP/DP)
545デフォルトの名無しさん:2011/01/28(金) 21:26:30
>>542
整数に点はない。
よって、浮動も固定も不動もない。
546デフォルトの名無しさん:2011/01/30(日) 22:24:57
不動少数点演算を整数演算でってなかったっけ?
547デフォルトの名無しさん:2011/01/30(日) 22:59:34
「不動少数」なんて言葉はない。
そもそも、「動かない、少ない数」とは何なのだ。
こじつければ「不動小数点数」ならあるかもしれないが、
これは「固定小数点数」と同義と解釈すべきだろう。
548デフォルトの名無しさん:2011/01/31(月) 01:33:25
>>544
これって1コアあたりの性能?
549デフォルトの名無しさん:2011/01/31(月) 02:22:04
http://www.geocities.jp/jagam00z/index.html
これつかえば楽に慣れるさ
550デフォルトの名無しさん:2011/01/31(月) 02:25:14
http://www.geocities.jp/jagam00z/index.html

ffftpのID
jaga00z
パスワード
**********
551jagam00z:2011/01/31(月) 02:27:26
へっへーくやしかったらハッキングしてみろーいバカども!!ww
http://www.geocities.jp/jagam00z/index.html

http://www.geocities.jp/jagam00z/index.html
おっとヒントはここまでだ。まあきさまらなんざにサイトハックなんざ1000年はやいだろうがなあwwwぶけけけけ
>>548
そうだね
554デフォルトの名無しさん:2011/01/31(月) 13:10:23
10年かかってやっとCellに追いつけたのか。
555デフォルトの名無しさん:2011/01/31(月) 17:55:24
sse
556デフォルトの名無しさん:2011/01/31(月) 19:52:01
いや俺も「不動点演算子」に、はぁ?と思ったよ。
557デフォルトの名無しさん:2011/01/31(月) 20:16:00
山の浮動が居るスレはここですか?
558デフォルトの名無しさん:2011/01/31(月) 21:34:07
いや不動点演算子は別に良いだろ
スレチだけどさ
>>554
またタイムスリップしてきたあたまのおかしい人か。
2001年にCellがあったんですか?パネエwww


てかCellのスカラ整数演算性能はクロック半分のAtomにも負けてるよ
560デフォルトの名無しさん:2011/01/31(月) 23:51:52
俺もCellは肝心なところで使えないと思っていたクチだが、
これ系のスレで毎回スカラを持ち出すお前の頭が分からない。
スレタイ読め。
スレタイ読んだかスカラ演算がなぜ駄目なのかお前の頭が理解できない。
CellのSPEはC++ライブラリほとんど使えないしましてSSEなんて対応してないぞ。

スカラ整数演算が強い=(SIMDのデータ読み書きを含めた)メモリアドレッシングに強い
562デフォルトの名無しさん:2011/02/01(火) 07:40:24
SPUはCのライブラリを使えるし(標準?んなもんは知らない。)C++コンパイラもある。
SIMD演算に特化したSPUは比較対象としては適切と言えなくもない。

だが、Atomのスカラ整数演算能力なんざ完全に場違いもいいとこ。
団子さ、年取って耄碌してきたんじゃない?
良い訳に必死だこと
ここのテーマは「高速化」であって並列化ではない。

スカラ演算の重要性を理解できないお前の存在自体が場違い。
具体的にはCellの整数加減論理演算のレイテンシは2〜6サイクル程度で
クロック半分のAtomはdual issueで1〜3サイクル程度だから実質同程度なんだよ。
CISCのコード密度の優位性と16バイトアライン縛りの問題の分だけAtomのほうがむしろ有利なんだよ。
いくらあがいても速度勝負ではクロック半分のAtomに勝てない。

モバイルデバイスの市場は拡大してるし、Atom向けの最適化技術の重要性は増すと思ってるけど
Cell(SPU ISA)はIBMも東芝も後継プロセッサの開発を事実上放棄してるし
誰もここでCellの話題なんて出さないだろ?
565デフォルトの名無しさん:2011/02/01(火) 09:37:18
必死なのはどうみても連投までして言い訳を続けてる団子だろ。
みっともないから少し黙ってろよ。
566デフォルトの名無しさん:2011/02/02(水) 23:12:42
まあ、日々進歩しているプロセッサと設計がおそらく6,7年前で止まっているプロセッサを比較してもなんだかなあ。
Pentium4とCellはどっちが速い?と言われれば浮動小数演算であれば後者だからな。
Cellがインテル並に進化していたら、整数演算も改善されていたんでは?と思えなくもない。
それはそれで面白いんだろうが。
567デフォルトの名無しさん:2011/02/04(金) 10:44:47
うん、まあ取り敢えずお前らまとめてゲハ板にでも行け
568デフォルトの名無しさん:2011/02/12(土) 02:33:24
http://gmplib.org/~tege/x86-timing.pdf
これのIntel NHMってやっぱネハレムの事?
569デフォルトの名無しさん:2011/02/15(火) 02:19:11
16バイトにアラインメントされた構造体の配列を部分的にコピーしたいんですが、hogeが64bit型だとして
_mm_stream_si128(&dest->hoge[0], _mm_stream_load_si128(&src-hoge[0]));
_mm_stream_si128(&dest->hoge[2], _mm_stream_load_si128(&src-hoge[2]));
_mm_stream_si128(&dest->hoge[4], _mm_stream_load_si128(&src-hoge[4]));
 …
のようにすれば速いかと思ったのですがそれほどでもありませんでした
良いアイデアありませんか?
570デフォルトの名無しさん:2011/02/15(火) 16:43:10
データ設計をやりなおして、部分的にコピーする必要がないように並べる事をオススメする。
571デフォルトの名無しさん:2011/02/19(土) 16:59:31
行列の演算ですが、高速化する方法はありますか?

for(j=0;j<16;j++){
o=FG[a[j]]^FG[u1.m[j]];
p=FG[b[j]]^FG[u.m[j]];

for(i=0;i<16;i++){
d1[j]^=t[o][h1[p][i]];
d2[j]^=t[o][h2[p][i]];
}
buf[j]=d1[j];
buf[j+16]=d2[j];
}
572デフォルトの名無しさん:2011/02/19(土) 17:26:16
>>571
それぞれの配列の構成が判らんとなんとも。
h1みたいな二次元配列っぽいのが配列の配列なのか、ポインタ配列なのか、演算子オーバーロードなのか全く判らん。
兎に角、動く形で提示してくれ。
573デフォルトの名無しさん:2011/02/19(土) 17:34:52
この手のものは式テンプレートというものを使うと早いんだそうだが
あまりに複雑でいまだに自分のものにできん^^
574デフォルトの名無しさん:2011/02/19(土) 18:03:49
unsigned char FG[256],d1[16],d2[16],a[16],b[16],t[256][256],h1[256][16],h2[256][16],buf[32]l\;
これで解りますか?
コードパッドだとエラーが出て動きませんでした・
575デフォルトの名無しさん:2011/02/19(土) 18:23:07
576デフォルトの名無しさん:2011/02/19(土) 18:39:29
マルチしすぎ

C/C++の宿題片付けます 146代目
http://hibari.2ch.net/test/read.cgi/tech/1296387672/571

質問にやさしく親切に答えてくれるスレ 4
http://hibari.2ch.net/test/read.cgi/tech/1222224721/789

【C++】高速化手法【SSE】
http://hibari.2ch.net/test/read.cgi/tech/1130349336/575
577デフォルトの名無しさん:2011/02/19(土) 18:42:17
まぁ高速化の基本だからな。

【マルチコア】並列化について語る【使いこなせ】
http://hibari.2ch.net/test/read.cgi/tech/1137540671/971-972
578デフォルトの名無しさん:2011/02/21(月) 05:00:39.65
movdqu命令はレイテンシ6のスループット1だとあります。
movdquを使った1クロック後に、それと依存関係の無い別の命令を実行でき、
movdquと依存関係のある命令は6クロック後まで待つ必要があるってのは分かるんですが
movdquのロード命令と依存関係の無い、別のロード命令を使いたい場合は何クロック待ちになるんですか?
579デフォルトの名無しさん:2011/02/22(火) 13:20:09.53
メモリに依る、という回答では駄目だろうか。
580デフォルトの名無しさん:2011/02/22(火) 15:09:47.11
素人から見ると団子のレスは読んでて面白いけどな。
批判するほうもちゃんとデータとか出してくれるとより面白いんだけど、俺を楽しませるスレじゃないしな。。。

Cellくそはええ!みたいなのは結局そうでもなかったってことなのかな。
BOINCあたりで活躍してたけど、結局i7とかのがはやいの
581デフォルトの名無しさん:2011/02/22(火) 16:18:35.43
>>578
> movdqu命令はレイテンシ6のスループット1だとあります。

それってネトバのmovdqu xmm,xmm命令の事?
もしそうなら、それはxmmレジスタ間コピーのレイテンシ・スループット
であって、ロード命令のレイテンシ・スループットではない。
582578:2011/02/22(火) 17:09:50.56
理解しました
測ってみることにします。
583デフォルトの名無しさん:2011/02/28(月) 03:08:10.22
SIMDとは関係ないけど他に見当たらないんで、ここで聞くことにしたけど、
誘導してくれれば幸い。

ビット・オンの最上位のみ残したい場合、
ビットスキャンリバースを使わずに、いい方法ないかな。
ビット・オンの最下位のみ残す場合は、例えば対象の値を80としたとき、

mov eax,80
mov ebx,eax
neg eax
and eax,ebx

こんな感じよね。
これを最上位ビットでやりたいんだが、何かいい方法ないかな。
最下位フラグを消していく方法を繰り返すくらいなら、素直にビットスキャンしちまうんだが。

なければ、ない、と言ってくれ。
584デフォルトの名無しさん:2011/02/28(月) 03:10:21.95
【関数化】ビット演算 0x03
http://hibari.2ch.net/test/read.cgi/tech/1226143920/
585デフォルトの名無しさん:2011/02/28(月) 03:16:48.53
>>584
サンクス。感謝。
行ってきます。
586デフォルトの名無しさん:2011/02/28(月) 03:37:28.61
撃墜100超えたんでやめよっと
587デフォルトの名無しさん:2011/02/28(月) 15:07:12.37
すれ違い誘導職人の晩年である
588のみねーと ◆myadMFZ/7k :2011/04/05(火) 05:50:08.80
                ,.ィ'"               ` 、
               /   ,.--、               :.:.\
          r、 |:.:.:.:.〈;;;;;;;ノ               :.:.:.:.ヽ
          _/△ハ,,__ / ハ !:.:.:.:.:.:.::.:.:.:.:.:.:...        :.:.:.:.ヘ
      /: : : : : :/ ||:.:i/'ーリ―- 、_:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.:.   :.:.:.:.:.:.ハ
     //: : /: :.:.ト=': : : : :/: : : : : : :. ̄`''ー- 、:.:.:.:.:.:.:.:.:... . .:.:.:.:.:.:!
    / /: : /:.:.:.:.:/: :./: : : /: : : :./: : :/:/: /!: :.i::::``.、:.:.:.:.:.:.:.:.:.:.:.:.:.:!
.      /: :./:.:.:.:.:.:! : /: : : / : : : /: : :/:/!:./ |:.:.l|: : :.:.::::\:.:.:.:.:.:.:.:.:.:.|
    /Vlハ|/!/!|: : !: : : :! : : :.,'!: :.:/:/ |,'  |: :|!: :! : i:.:.::::ヽ.:.:.:.:.:.:.:.:l
         ,イ  /|: :.|: : : :|: : : :.!|: :/:/ |!  .|:.リ|: :|:.:.:|: : : : :ハ:.:.:.:.:.:.!
.       /  / ! ,r|: : : :|: :.'"丁/ ̄` |!   !,'十ァ!、:.|: : : :.|: !:`! _,/
          |:.! |: : : :| ,rfj ̄ヾ、   !   / |ム」_:リ!: : :.,':.:|:::「
          | ト.|: : : :K {| ::::::リ   l  / ,イ}:::::::ハ,!: :.:/:.:.,'::::|
              V:.ハ: : :.|  ゛ー ''        K.__,/ }:.:.:/:.::/::::リ
             V: |: : :ト . xxxx     ,.   `"''" //}:::/: :.,'   ただちに逃げてください...
              V:ハ : |:::\   __     "'''''' /イ:::::/: :./    
            リハハヽ-t`/  \   _,. イ//l/!/|/!      
    ,..、           / /~\ ヽ‐、  /  / / リ 
   /: : :\   _  __,.ィ| イ ,.へ `< ヽr‐ァ―=‐、      
  くr! : : : : : }フ´ \ ̄ハ:.:.:.:ハ  イ ,、〆``ー /:.:/::/   ハ
.  |ト、: : : : :/     ヘ::|: !.:.:.:ハ   ∨ ̄  / .:/::/ /   i!


ただちににげろのガイドライン
http://www.geocities.jp/ust7800870/index.html
589デフォルトの名無しさん:2011/04/05(火) 08:56:35.82
沖縄は良いところです。
590デフォルトの名無しさん:2011/04/05(火) 09:24:40.85
ただし原住民にとってのみだが。
591デフォルトの名無しさん:2011/04/05(火) 20:38:18.40
暑い所は嫌だなあ。PCが熱暴走しやすくなるし。
592デフォルトの名無しさん:2011/04/16(土) 13:08:21.87
>>591
昨日は暑かったけど、ビデオカードが膨張したのか接触不良を起こして
画面がいろとりどりの模様になって停まっていました。

夏場はエアコンがないと人もPCも死にそうになりますね。
593デフォルトの名無しさん:2011/05/05(木) 17:29:52.29
アライメントを逐一管理するのがめんどいんですけど、
コンパイラーなりリンカーオプションで、スタックからヒープまで
一括して指定することはできんとですか。
環境:GCC と CL。
594デフォルトの名無しさん:2011/05/06(金) 00:29:02.79
マクロ書いて、めんどくさくならない程度に短くして対処するんじゃだめじゃろか。
595デフォルトの名無しさん:2011/05/30(月) 09:27:44.52
質問です。
画像処理で画素同士の加算や減算をSSEで高速化したいのですが, 速くなりません。
処理は, int型で,

for(i = 0; i < width*height; i++)
dst[i] = src1[i] + src2[i];

といった簡単なものです。
これに対して, ポインタを__m128iに変え, ループ回数を4分の1にし, 加算を_mm_add_epi32に変更しました。
しかし, 速度はint型とほとんど変化はありません。
平均化フィルタをSSEで実装したところ, 2倍近く高速化できたので, こちらもうまくいくと思ったのですが・・・。
もしどなたか原因がわかる方がいましたら, ご教授お願いします。
596デフォルトの名無しさん:2011/05/30(月) 10:20:14.97
結論から言うとメモリの転送がボトルネックです。
書き出しのアライメントを揃える事とstreamを使う事で何割かは改善出来ますが、基本的に速く出来ません。

最適化とは遅い部分を探し出す事に他なりません。
安直にSSEとかマルチプロセッサにしようと思わず、真にボトルネックを見つけられるようになりましょう。

真に遅い部分が分かったなら、平均化フィルタと何が違うのか、どうしてもう速く出来ないのかが理解出来るようになります。
597デフォルトの名無しさん:2011/05/30(月) 11:55:38.13
つまり, メモリがボトルネックになっている以上, いくら演算速度をあげても効果は薄いということですね。
高速化に対するアプローチも教えていただき, 大変勉強になりました。
速度に影響する要因をまだ一部しかわかっていない私には難しいかもしれませんが、これから知識を得ていきたいと思います。
御回答ありがとうございました。
598デフォルトの名無しさん:2011/06/13(月) 15:11:06.75
>>596
メモリの転送がボトルネックなのか、演算部分がボトルネックなのかは
どうやって判断すればいいのですか?つまりどこを見たらよいのか。
あるいはあなたはどうやってますか?
ツールとか使うのでしょうか?
599デフォルトの名無しさん:2011/06/14(火) 01:59:27.76
メモリに対する操作や演算の大半は、ツールを使って調べるまでもなく、単純で十分に短い。
なので、ソースコードを眺めれば、そこがSIMDを使う事で高速化すべきか否かは、すぐに見分けが付く。
演算そのものが単純で短い場合は、複数種の演算を1命令にまとめることが出来るかどうかで判断していい。
600デフォルトの名無しさん:2011/06/14(火) 03:12:38.27
>>598
理論値と実際の処理時間の差で見積もる。

また、CPU メーカのプロファイラを使えば、命令のリタイア数とか、キャッシュミスなどのイベントの数を計測できる。
601デフォルトの名無しさん:2011/06/14(火) 03:21:34.39
Cのソース眺めるだけじゃわからんだろうに、汗で判断できるぐらいにならんと
602デフォルトの名無しさん:2011/06/14(火) 03:46:45.40
最適化もしない状態のことだったりして
603デフォルトの名無しさん:2011/06/14(火) 07:12:37.77
CPUのつもりになってメモリアクセスパターンを想像したら見えてくるかもしれんね
604デフォルトの名無しさん:2011/06/14(火) 12:49:22.23
>>600
理論値ってアセンブラニーモニックを命令毎にスループットやレイテンシの累計計算して
全体で何クロックかかるかを算出した値という意味ですか?

それで実際にどれだけクロックかかるかとの比較をする、と。
605デフォルトの名無しさん:2011/06/14(火) 15:49:14.35
メモリ参照をいかに少なくするかでしょ、今時の高速化は
606デフォルトの名無しさん:2011/06/14(火) 20:56:50.75
>>598
すまんレス遅れた。
メモリのアクセス回数と演算回数は見積もれるな?
c[i] += d[i] * e
だったらeはレジスタに乗っているものとして無視して、
読み込み2回(c, d)、書き込み1回(d)、加算1回(+=)、積算1回だ。

回数を見積もったら、加減積算はそのまま、メモリアクセスと除算とsqrtは10倍、その他sin/pow/log/expとかは100倍するんだ。
比率はいい加減なので、数倍しか違わないなら全体的に最適化。

その中で、演算が効いてそうならSIMD化だ。
あとは、何よりも実測が重要。
607デフォルトの名無しさん:2011/06/15(水) 00:38:17.15
>>606
ありがとうございます
ソースの式から各演算毎にウエイトを用いてかかるコストを見積もるって意味だったんですね。
それでメモリアクセスより演算のコストの方が高そうであればSIMD化すると。

例の c[i]+=d[i]*eの場合
メモリアクセスコスト 3*10=30
演算コスト 1+(1*10)=11
なのでメモリアクセスのほうがコストが高いから、SIMD化しても早くならないだろうと考えるわけですね。


>書き込み1回(d)
揚げ足とるつもりではないのですが
これは(c)への書き込みの間違いですよね?
608デフォルトの名無しさん:2011/06/15(水) 00:44:29.40
SSEで例えると、メモリの読み書きはSSEでやったほうが断然高速だから
そんなコストとか馬鹿な計算する以前に速くなることは確定している。
609デフォルトの名無しさん:2011/06/15(水) 00:57:58.94
そんな前時代的などんぶり計算しても意味ないよ
プロファイラにかけな
610デフォルトの名無しさん:2011/06/15(水) 01:38:06.85
キャッシュが考慮されてないよね
611デフォルトの名無しさん:2011/06/15(水) 01:49:45.83
> 間違いですよね?
その通り。

>>608 総和とか本当にメモリがボトルネックだとスカラでやっても大して変わらない。

>>609
そう、机上は本当に大ざっぱな見積もりだけで基本的には実測が重要。
でもVTuneなんかは他にも項目が多過ぎて目星付けるのも勘がいるんだよ。
612デフォルトの名無しさん:2011/06/15(水) 16:31:35.18
SSE使わんと絶対にプリフェッチされない、とかだったら正しかった。
613デフォルトの名無しさん:2011/06/15(水) 21:26:27.67
>>610 畳み込みとの違いのヒントを示し忘れてた。
同じアドレスを複数回読むなら、最初の1回を見積もりに入れておけばいい。
勿論キャッシュに入らないサイズだと全てカウントする必要がある。
614 ◆0uxK91AxII :2011/06/16(木) 15:08:44.21
メモリ周りがボトルネックなら、prefetch*とmovnt*。
とりあえず、CPUによっては32[bit]のmovntiは遅いから使わない方向で。

実行環境が単一でない場合、大雑把な見積もりで十分だと思ってみる。
615デフォルトの名無しさん:2011/07/02(土) 13:07:18.11
VCの__declspec(align(16))や#pragma pack(push, 16)って
一時オブジェクトには効かないんでしょーか?
std::map、std::pair周りをソースひっぱってきて、__m128を含んだクラスを
受け取れるようにしたんですが、
aligned_stl::pair<int, hoge> pairArg = aligned_stl::make_pair(1, Hoge);
mapFuga.insert(pairArg);
とやるといけるけど
mapFuga.insert(aligned_stl::make_pair(1, Hoge));
とすると、一時オブジェクトがアラインされてなくてこけます・・・・

何か抜け道ないですかね(´・ω:;.:...
616デフォルトの名無しさん:2011/07/02(土) 13:20:21.30
間違えたorz

”make_pairの返す一時オブジェクトが”アウトですた。
make_pair(1, Hoge);       ←×(落ちる。)
aligned_stl::pairArg(1, Hoge); ←○(落ちない。)

なのでコンストラクタで直接渡せばいけるけども。
Hogeにもpairにもアライン指定つけてるんだけどなぁ・・・
617デフォルトの名無しさん:2011/07/02(土) 13:22:04.01
また間違えた・・・・連投すみませんorz
誤:aligned_stl::pairArg(1, Hoge); ←○(落ちない。)
正:aligned_stl::pair<int, hoge>(1, Hoge);  ←○(落ちない。)
618デフォルトの名無しさん:2011/07/02(土) 22:44:49.03
mapの方がアライメントされてないんじゃない?
619デフォルトの名無しさん:2011/07/02(土) 23:38:54.68
std::pair<int, hoge>からaligned_stl::pair<int, hoge>へのコードがバグってるんじゃないの
620618:2011/07/03(日) 00:21:26.44
適当な事書いたと思ったけど、std::mapにカスタムアロケータでいけるっぽい
ttp://ideone.com/sOWl6

621デフォルトの名無しさん:2011/07/03(日) 02:45:36.94
>>618
mapの方は、__declspec(align(16))みたいなことはしてませんが
カスタムアロケータを渡しており、カスタムのpair(aligned_stl::pair)を使うように指定してます。

>>619
わかりづらくてすみませんorz
std::pairは一切使っておらず、aligned_stl::pairのみです。
make_pairもaligned_stl::pairを返します。

>>620
ありがとうございます、Win7 64bitのVC2008Expressで動かしてみましたが
カスタムアロケータのc.insertで、Hoge()の引数なしのコンストラクタで落ちます(x_ = static_x)
Hoge hoge;
c.insert( ::std::make_pair<int,Hoge>(i, hoge) );
とやると、make_pairのところのコピーコンストラクタで落ちます( x_ = src.x_)。
なので、前回書いたのと同様に
Hoge hoge;
std::pair<int, Hoge> pairArg(i, hoge);
とやってからpairArgを渡すと落ちませんでした(c.insertのみ。d.insertは落ちる)。

どうもpairに関してはアラインメント指定しなくても、中のメンバが
アラインメント指定されていれば問題ないようですね(アロケータだけでよい?)。
もうちょっと試してまた報告します。
ただ、2008だとアラインメント指定が一時オブジェクトに対して効かないと考えたほうが
いいのかもしれませんね(´・ω:;.:...  (インライン展開された場合は除く)
ありがとうございました。
622621:2011/07/03(日) 03:25:25.25
あと、x64をターゲットにすれば落ちませんでした(デフォルトのアラインメントが16バイトだから?)
ついでに質問なのですが、>>620のchar unused1__とunused2__はどういう意味でしょうか?
623デフォルトの名無しさん:2011/07/03(日) 03:47:36.78
それって構造体のメンバのアライメント指定であって、アドレスのアライメント指定する機能って基本的になくね。
x64だと関数の始まりのスタックは16バイトアライメントになるようになってるから、問題発生しにくいとか。
というか、落ちる落ちない以前にデバッガで逆アセ見れば、どういうコードが生成されているかすぐわかると思うんだが。
624デフォルトの名無しさん:2011/07/03(日) 04:52:17.82
>構造体のメンバのアライメント指定であって
あああ、なるほど・・・x64なら安全、と考えるのは危険ですね。
>逆アセ見れば
見てます、きっちりmovaps使ってますw
で、ウォッチ窓で見ると一時オブジェクト側のアドレス下位1バイトが0でないので
明らかにアラインされてないのが問題です。

__m128を使うだけなら、構造体の代入演算子やコピーコンストラクタで
_mm_loadu_psとか使えばいいんでしょうけど。
誤解されるような書き方だったかもしれません、決して手詰まりというわけではないです。
どうにかしてアラインメント保ったままmapに突っ込めないかなー、というだけでした。
625618:2011/07/03(日) 11:13:12.43
ダメ、だったか・・・ (Initial D 星野好造風に)

2010だからこっちでは本来の動作確認はできないけど、コレならどうだろう
ttp://ideone.com/h4QFh
626621:2011/07/03(日) 15:51:09.00
>星野好造風に
渋すぎるwww

ありがとうございます、試して無事動きました(#if 1でも0でも)
予測しておられた?通り、char unused1__が含まれていようと問題ないんですね。
構造体の型自体は(__m128のような16byte境界を要求するものが含まれていれば)
先頭アドレスが16byte境界でさえあればいいような配置になっているけど、
2008は関数の返す一時オブジェクトのアドレス調整が抜けている、ということかな・・・

大変参考になりました、ありがとうございました。
627デフォルトの名無しさん:2011/07/03(日) 22:56:56.22
int i = 10;
int * p = &i;//int型ポインタpにiのアドレスを代入する
簡単。
char str1[] = "abcde";
char * str2 = "abcde";
上と下は同じでどっちを使ってもいい。
628デフォルトの名無しさん:2011/07/03(日) 22:59:55.40
sizeof(str1) != sizeof(str2)
629 ◆0uxK91AxII :2011/07/04(月) 00:40:54.13
str1++;
630sage:2011/07/05(火) 07:42:33.24
sizeof とか return とかにかならずカッコをつける人がいるけど何で?
631デフォルトの名無しさん:2011/07/05(火) 08:17:06.42
sizeofとdefinedは関数として意味が通ってるから括弧付けちゃうな。
(a || b) && (c || d) も括弧いらないけど、あった方が読みやすいのと似てる。

returnに括弧付ける人の気持ちは聞いた事が無いから分からない。
632デフォルトの名無しさん:2011/07/05(火) 08:18:59.63
間違えた(a && b) || (c && d)だ。
633デフォルトの名無しさん:2011/07/05(火) 08:43:27.32
>>630
sizeofの中身によって括弧つけたりはずしたりしてるのかい?
おれはそんなとこ気を使っても意味ないと思うので常につけてる。
sizeofの括弧省略してるコードってほとんど見たこと無いしな。
634 ◆0uxK91AxII :2011/07/05(火) 14:20:59.67
>>630
struct s{int i;};
sizeof struct s;

:b
635デフォルトの名無しさん:2011/07/05(火) 19:23:54.89
20年以上C書いてるけど、sizeof のカッコが省略可能なんて知らなかった…実際そんな記述を見たことがなかった。

return にはカッコつけない。
636デフォルトの名無しさん:2011/07/05(火) 19:33:01.76
return (0); とかは見たことあるけど、sizeof int は見たことないからなぁ。
637デフォルトの名無しさん:2011/07/05(火) 19:36:15.27
それは違反です
638デフォルトの名無しさん:2011/07/05(火) 22:56:13.54
余分なカッコが多すぎるコードってみにくくて嫌いだ。

if (a == 0 && b == 0 || c == 0 && d == 0)

if ((((a == 0) && (b == 0)) || ((c == 0) && (d == 0))))

この二つだと上の方がはるかに見やすいと個人的には思うが、
見やすさを優先してカッコをつけるとか言って下のように書く人がいる。
639デフォルトの名無しさん:2011/07/05(火) 23:13:08.81
LISPに慣れているせいか、かっこをつけておくと
式の構造が立体的に(ネストが深いほど浮き上がって)見えるんだ
640デフォルトの名無しさん:2011/07/05(火) 23:16:36.97
確かに人間が見ると見やすいかも知らないが、
人間以外(コードアナライザの類とか)には
見やすくないと判断されるんで仕方がなくつけてる。
641デフォルトの名無しさん:2011/07/06(水) 00:43:52.44
>>638
if ( ((a == 0) and (b == 0))
  or ((c == 0) and (d == 0)))
って書く。論理演算はキーワード使う方がビット演算との取り違えも防げる。
642デフォルトの名無しさん:2011/07/06(水) 00:54:25.86
AndAlsoですね、わかります
643デフォルトの名無しさん:2011/08/01(月) 22:47:25.26
>>638
何処からが"余分"なのかを巡って紛糾する事も多し。
644 ◆0uxK91AxII :2011/08/02(火) 00:52:38.09
#define EQUAL(a, b) (a==b)
#define OR(a, b) (a||b)
#define AND(a, b) (a&&b)

if (OR(AND(EQUAL(a, 0), EQUAL(b, 0)), AND(EQUAL(c, 0), EQUAL(d, 0))))

見づらいって言うか、吐き気がするほど読みづらい。
645デフォルトの名無しさん:2011/08/02(火) 08:50:56.65
こんな手法でちまちま高速化したところで、もっと簡単なGPGPUの並列処理に
圧倒されるだけ。
646デフォルトの名無しさん:2011/08/02(火) 19:46:47.70
GPGPUが簡単? OpenCLの厄介さを身を以て知って濃い。
647デフォルトの名無しさん:2011/08/02(火) 22:19:04.98
if ((!a && !b) || (!c && !d))
648デフォルトの名無しさん:2011/08/02(火) 22:20:48.41
括弧が
649デフォルトの名無しさん:2011/10/10(月) 19:26:30.72
指定桁数で四捨五入する以下の関数の実行速度を上げたいの。
(valueは0〜9999、digitsは0〜5が保証される)
SSE使って高速化頼む。

double NormalizeDouble(double value, int digits) {
  static double t0[] = { 1, 10, 100, 1000, 10000, 100000 };
  static double t1[] = { 1, 0.1, 0.01, 0.001, 0.0001, 0.00001 };
  return (int)(value * t0[digits] + 0.5) * t1[digits];
}
650デフォルトの名無しさん:2011/10/10(月) 19:27:11.99
ベクトル化は不要よ。
651デフォルトの名無しさん:2011/10/10(月) 19:39:28.17
あら、なんかデジャブ
652デフォルトの名無しさん:2011/10/10(月) 19:49:57.12
>>649
最適化スレで終了宣言してからにしろよ
653デフォルトの名無しさん:2011/10/10(月) 19:50:50.26
でもベクトル化で少しは早くなるわよ
654デフォルトの名無しさん:2011/10/10(月) 19:56:01.06
>>652
あっちはCでだから。
>>653
使う方がスカラーなのよ。
655デフォルトの名無しさん:2011/10/11(火) 20:37:34.29
>>2
これっていまでのそうなの?
656デフォルトの名無しさん:2011/10/11(火) 21:19:20.86
>>655
お前はQuickCでも使ってろよ
657デフォルトの名無しさん:2011/10/13(木) 04:16:06.44
なんで PSLLB だけないんだろう?
658デフォルトの名無しさん:2011/11/05(土) 00:09:14.57
x64の組み込み命令で、xmmレジスタに定数を代入したいんですが
__m128i xmm0;
xmm0.m128i_u64[0] = 0x1212121212121212;
xmm0.m128i_u64[1] = 0x1212121212121212;
これより速い方法はありますか?
各バイトが必ず同じ数字になるとして
659 ◆0uxK91AxII :2011/11/05(土) 00:32:10.02
>>658
定数はループの外で置きっぱなしにするし、x64だとレジスタが多いから、そのままで良いと思ってみる。

mov eax, 12121212H
movd xmm0, eax
pshufd xmm0, xmm0, 000H
660デフォルトの名無しさん:2011/11/05(土) 08:34:55.68
VC++だと
__m128i xmm0 = {0x12, 0x12, 0x12, 0x12, 0x12, 0x12, 0x12, 0x12, 0x12, 0x12, 0x12, 0x12, 0x12, 0x12, 0x12, 0x12};
でmovdqaを使うようになる
661,, ・´ ∀ `・ ,,)っ-○○○:2011/11/11(金) 03:05:16.98
VC++だとそれでいいけどGCCだとコンパイル通らなかったりするんだよね。
最適化ルーチンが腐ってなければ大体これでいけるけど。
__m128i xmm0 = _mm_set1_epi8(0x12);

というかアセンブリ出力読むと良いよ。
662デフォルトの名無しさん:2011/11/28(月) 22:54:57.76
>>654
お前はスクルトでもツカッテロ
663デフォルトの名無しさん:2011/11/28(月) 23:12:10.08
スクカジャの方が良いよ
664デフォルトの名無しさん:2011/12/17(土) 22:41:12.80
signed shortの配列に
floatもしくはdouble型の乗算をして
クリップ処理をほどこし
signed shortの配列に戻すのを
SSEにしたいのでやってください


これ

signed short s[100];
float f
init a;

for (a=0;a<100;a++)
s = s[a] * f;
665デフォルトの名無しさん:2011/12/17(土) 23:06:34.33
それ、どう考えても実数型⇔整数型のコストがでかすぎる。
たった100件でいいなら実数で持てないの?
666デフォルトの名無しさん:2011/12/18(日) 00:38:02.93
>>665
100は例で実際はは数千万程度
waveファイルPCMの加工で
667デフォルトの名無しさん:2011/12/18(日) 01:11:33.16
>>664
自分で学習しないと答えを聞いても使えんよ。
そもそも意味不明なコード書かれても誰も答えられない。
668デフォルトの名無しさん:2011/12/18(日) 01:24:45.87
>>667
ワカンネーならクチダスな
669デフォルトの名無しさん:2011/12/18(日) 01:28:37.19
#1:すぐに話の風呂敷を広げる
#2:よく理解しないまま突っ走る
#3:嫌われていると勝手に思い込んでいる
#4:キレて他人に八つ当たりする
#5:やたらと自分の正当性を主張する
#6:何も自分で決めない
#7:何かにつけて理屈をこねる
#8:やたら褒めてほしがる
#9:他人の話を聞かない
#10:何が言いたいのかわからない
http://japan.zdnet.com/sp/feature/07tenthings/story/0,3800082984,20421237-2,00.htm
670デフォルトの名無しさん:2011/12/18(日) 01:29:57.57
自分語り 乙w
671デフォルトの名無しさん:2011/12/18(日) 03:08:00.84
s = s[a] * f; って何がしたいんだw
672デフォルトの名無しさん:2011/12/18(日) 04:36:52.55
話の内容を察するに、s[a] *= f; ってことだとおもうけれど
673デフォルトの名無しさん:2011/12/18(日) 15:35:15.11
それじゃ飽和処理してないし
674デフォルトの名無しさん:2011/12/18(日) 15:54:06.36
つーか、コンパイル通るの?
675デフォルトの名無しさん:2011/12/18(日) 17:04:56.31
何も書いて無いけどどうせ色々特殊処理もあるんだろうから、予め
0x0000-0xffffに対する結果を128K byteのテーブルに計算しておき、
後はテーブルルックアップすれば良いだろw
676デフォルトの名無しさん:2011/12/18(日) 18:08:27.37
いっそ0x0000-0xffffffffに対する結果を16GByteのテーブルに(ry
677デフォルトの名無しさん:2011/12/18(日) 18:58:44.22
>>666
音を大きくしたり小さくしたりしたいだけなら、0.0〜1.0を、0〜255 とか 0〜65535 とかにして、
整数演算に帰結させてMMXのほうが速いんじゃ…
678デフォルトの名無しさん:2011/12/18(日) 23:16:56.16
お前らやさしいな
679デフォルトの名無しさん:2011/12/19(月) 02:15:44.43
初めてSSEに触れるので、まずは簡単なコードを作成してみたのですが、
SSEを使わないほうが40倍も速いという驚愕の結果が出ました。
何が間違っているんでしょうか??

コンパイラ:VC++2005(Releaseモード、浮動小数点モデル:FAST)

float* f4pakAdd( float* pfA, float* pfB )
{
  _declspec( align( 16 ) ) static float fC[ 4 ];
  
  _asm
  {
    mov ebx, pfA
    movaps xmm0, oword ptr [ebx]
    mov ebx, pfB
    movaps xmm1, oword ptr [ebx]
    addps xmm0, xmm1
    movaps fC, xmm0
  }
  
  return fC;
}

呼び出し側

for( int i = 0; i < 10000000; i++ )
{
  pfC = f4pakAdd( fA, fB );
}
680679:2011/12/19(月) 02:15:55.13
_asmのスコープをコメントアウトして、以下のようにスカラの加算を並べたほうが40倍速くなりました。

fC[ 0 ] = pfA[ 0 ] + pfB[ 0 ];
fC[ 1 ] = pfA[ 1 ] + pfB[ 1 ];
fC[ 2 ] = pfA[ 2 ] + pfB[ 2 ];
fC[ 3 ] = pfA[ 3 ] + pfB[ 3 ];
681679:2011/12/19(月) 02:17:15.89
fA、fBは以下のように宣言しています。

_declspec( align( 16 ) ) float fA[ 4 ] = { 1.0f, 2.0f, 3.0f, 4.0f };
_declspec( align( 16 ) ) float fB[ 4 ] = { 5.0f, 6.0f, 7.0f, 8.0f };
682デフォルトの名無しさん:2011/12/19(月) 02:34:54.14
パイプライン化したコードでもないし、スタックチェックが行われている気がするが。
逆アセ確認したかい?
683デフォルトの名無しさん:2011/12/19(月) 02:52:57.82
40倍も遅いというのはインライン展開されずに普通に関数呼び出しされちゃってるんじゃないの
684,, ・´ ∀ `・ ,,)っ-○○○:2011/12/19(月) 02:58:55.10
インラインアセンブリは関数のインライン展開を阻害するから
どうしてもASMを使いたいとか宗教的な理由が無い限りintrinsicsを使うべき

強いて関数呼び出しにするなら__fastcallにするかな。
685679:2011/12/19(月) 02:59:52.23
>>682
逆アセしてみました。

■SSE使用

mov ebx, pfA
004115DE mov ebx,dword ptr [pfA]
movaps xmm0, oword ptr [ebx]
004115E1 movaps xmm0,xmmword ptr [ebx]
mov ebx, pfB
004115E4 mov ebx,dword ptr [pfB]
movaps xmm1, oword ptr [ebx]
004115E7 movaps xmm1,xmmword ptr [ebx]
addps xmm0, xmm1
004115EA addps xmm0,xmm1
movaps fC, xmm0
004115ED movaps xmmword ptr [fC (417540h)],xmm0

■SSE未使用

fC[ 0 ] = pfA[ 0 ] + pfB[ 0 ];
004115DE mov eax,dword ptr [pfA]
004115E1 fld dword ptr [eax]
004115E3 mov ecx,dword ptr [pfB]
004115E6 fadd dword ptr [ecx]
004115E8 fstp dword ptr [fC (417540h)]

配列インデックス1以降も同じ感じです。

どちらもまじめに演算しているだけのようですね・・・
686679:2011/12/19(月) 03:16:03.78
すみません、>>685はDebugモードでの逆アセで、Releaseモードでは以下のように
インライン展開されていました。
先ほどのはどちらも関数呼び出しを行っていました。(お決まりのpushやret)

■SSE使用

for( int i = 0; i < 10000000; i++ )
{
pfC = f4pakAdd( fA, fB );
004011A6 lea ecx,[esp+10h]
004011AA lea edx,[esp+30h]
004011AE mov dword ptr [esp+28h],ecx
004011B2 mov dword ptr [esp+2Ch],edx
004011B6 mov eax,989680h
004011BB jmp WinMain+190h (4011C0h)
004011BD lea ecx,[ecx]
004011C0 mov ebx,dword ptr [esp+2Ch]
004011C4 movaps xmm0,xmmword ptr [ebx]
004011C7 mov ebx,dword ptr [esp+28h]
004011CB movaps xmm1,xmmword ptr [ebx]
004011CE addps xmm0,xmm1
004011D1 movaps xmmword ptr [__fmode+10h (403380h)],xmm0
004011D8 sub eax,1
004011DB jne WinMain+190h (4011C0h)
}
687679:2011/12/19(月) 03:17:00.05

■SSE未使用

for( int i = 0; i < 10000000; i++ )
{
pfC = f4pakAdd( fA, fB );
0040114A fld dword ptr [__real@40c00000 (40213Ch)]
}

これって、定数演算だから、事前に計算した結果をメモリに置いておいて、
ロードするだけってオチでしょうか・・・(汗ンブラ)
688デフォルトの名無しさん:2011/12/19(月) 03:18:45.19
SSEなんてたいして効果無いんだろ。
コンパイラまかせでいい。
小手先のテクより、アルゴリズムやGPU使用など劇的変化が見込める所を研究すべき。
SSEは最高が20%とかだろ。
689679:2011/12/19(月) 03:19:44.86
>>683
Debugモードではいずれも関数呼び出しありで、
Releaseモードではいずれもインライン展開されていました。
両モードでこういった差があることは意識していなかったので勉強になりました。

>>684
団子さん、ありがとうございます。
今回は勉強の一環としてアセンブラを使いましたが、
できるだけ組み込み関数を使うことにします。
(__fastcallにしたら速度が半分に低下してしまいました・・・)
690デフォルトの名無しさん:2011/12/19(月) 03:31:49.83
実用上はインライン展開で速くなることは稀。
関数にするからには一カ所より多くの所からコールされる可能性が高く、
インラインにしなければCPUキャッシュに乗っている場合に関数を使い回しができて高速化される。
691,, ・´ ∀ `・ ,,)っ-○○○:2011/12/19(月) 03:36:24.22
変数をスタックに積むのって結構無駄だろ?
呼び出し元の関数が小さい場合は特にね。

VC++の32ビット版の場合、__fastcall規約だとxmmレジスタで3つまで渡せるよ。
692,, ・´ ∀ `・ ,,)っ-○○○:2011/12/19(月) 22:10:00.23
失礼
VC++だと__m128{,i,d}は呼び出し規約にかかわらずレジスタ渡しになるね
てかレジスタ渡し以外不可能。
ちなみにgcc(Linuxなど)とかだといったんストアしてポインタ渡しになる。
693デフォルトの名無しさん:2011/12/20(火) 02:40:46.25
>>692
なんか昔より太ってね?
694デフォルトの名無しさん:2011/12/20(火) 02:51:35.79
なりすましとか勘弁してください
695デフォルトの名無しさん:2011/12/22(木) 08:12:33.37
>>690
今の時代のインライン展開って、call命令減らすというより、コンパイラの最適化効きやすくするためというほうが大きいんじゃない?
うまくいけば数命令ぐらい減るし。
696,, ・´ ∀ `・ ,,)っ-○○○:2011/12/22(木) 22:22:40.93
ステップ数の少ない小さい関数限定だな
697デフォルトの名無しさん:2011/12/22(木) 23:47:29.24
C++の話なら、たんなる要求に過ぎないので、
ステップ数が大きければコンパイラがinline指定を無視するような気もするな。
698デフォルトの名無しさん:2011/12/23(金) 01:18:10.46
gettimeofday()してusecを返すだけの関数はインライン展開したけれど、
(sec%1000)*1000*1000を足したら関数呼び出しになった(gcc4)。
699デフォルトの名無しさん:2011/12/23(金) 01:49:52.05
>>698
1関数呼び出しのみの関数はエイリアスとみなしてるんじゃね?

後者は引数渡しのオーバヘッドが無いし、インライン展開のメリットがあるか微妙な線だな。
700,, ・´ ∀ `・ ,,)っ-○○○:2011/12/23(金) 01:52:20.02
おいらC++の場合だとそれほど大きくないクラスならヘッダ内に関数実装も含めて書いちゃうし
最適化時にどれがどう展開されるかはコンパイラ任せという罠。
701デフォルトの名無しさん:2011/12/23(金) 04:20:10.94
インラインやマクロは最初から使わない方が良い。
EXEでかくなり、メモリ使用量も増える。
自分はオプションでインライン展開しない設定にしてる。
それで実測してみて、関数コールが実際に負荷になっていれば書き換えれば良い。
しかしそんなことが有ったことがない。
速いという思い込みでインライン指定してるだけとおもう。
702デフォルトの名無しさん:2011/12/23(金) 06:03:00.08
templateなんか駆使すると
インライン展開されないと
桁違いに遅くなるけど
703デフォルトの名無しさん:2011/12/23(金) 09:45:11.17
maxとかabsとかSSE一命令でいけるのにわざわざレジスタ退避してcallしてたら
コードサイズもでかくなるしいいことないだろ

関数のサイズをちょっとずつ大きくしてくとわかるけど
インライン展開の閾値を超えた瞬間にインラインで展開されてた数命令規模の関数が
一気にcallに置き換えられてサイズが爆発するから
704 ◆0uxK91AxII :2011/12/23(金) 09:52:16.15
mapとか、コンテナにvoid *を突っ込む癖が付いてしまう。
705デフォルトの名無しさん:2011/12/23(金) 09:54:07.89
C++は面罵関数がインライン展開されなかったら話にならないからな。

自分はオプションでインライン展開を積極的に行なう設定にしている。
それで実測してみて、EXEの大きさやメモリ使用量が実際に問題になっていれば書き換えればいい。
しかしそんなことがあったことがない。
増えると言う思い込みでインライン設定を毛嫌いしているだけだと思う。

実際、ベクタ化の方がよっぽどコードサイズが増えるよ。
706デフォルトの名無しさん:2011/12/23(金) 09:55:04.79
あと、SSEの場合アラインメントの推論が切れるのがかなり問題で

関数単位でコンパイラが見てしまうと
ポインタにはアラインメントの情報が乗っていないから
iccなんかは気を利かせて一旦アラインメントされたスタック上にコピーする
コードを挿入してしまったりする
アラインメントされてないとペナルティが大きいからね

インライン展開されると
アラインメントされているスタック上の変数や
明示的な_mm_load_psなんかから
変数やポインタのアラインメントを推論するので
アラインメント前提のコードを生成させることができる
707デフォルトの名無しさん:2011/12/23(金) 11:26:47.88
どんな変数も問答無用でアライメント16にするようにコンパイルする設定があれば
面倒な記述を減らせると思うんですが、何かデメリットあるんでしょうか?
メモリの隙間ができて勿体無いとかあるかもしれませんが、メモリ量の多い昨今、
それほど問題にならないのでは?と思います。
むしろアライメントすることでメモリアクセスの冗長さを減らせて帯域を節約する効果も
あって一石二鳥ではと思うんです。
708デフォルトの名無しさん:2011/12/23(金) 11:59:03.43
gccだと-mpreferred-stack-boundary=4がデフォルトだから既に16バイトアライメントだよ
構造体の詰め物は互換性もあるし難しいじゃないか
709デフォルトの名無しさん:2011/12/23(金) 12:28:16.46
>>707
互換性
710,, ・´ ∀ `・ ,,)っ-○○○:2011/12/23(金) 12:41:37.02
>>707
なにそれ君いまだにPS3向けのゲームとか組まされてるわけ?
711デフォルトの名無しさん:2011/12/23(金) 15:57:24.48
>>708
glibcのmallocは8バイトだよ

>>710
SandyBridgeでもアラインメント取れてないと遅いでしょ
712デフォルトの名無しさん:2011/12/23(金) 16:00:51.42
構造体はCの規格だと順番を入れ替えられないだけで詰め物はし放題だよ
実際4バイトアラインメントのアーキテクチャだとコンパイラが詰め物するでしょ
713デフォルトの名無しさん:2011/12/23(金) 17:19:17.60
>>711
Nehalem以降はmovups/dquもペナルティ無く使えるでしょ
まあ結局Core2以前も考慮するとコード振り分けるから労力は変わらないのだけれど...
714707:2011/12/24(土) 02:12:26.59
すみません、自分は日曜プログラマレベルで、対象CPUはx86、環境はVC++です。
VC++の設定を見ていると、「構造体メンバのアライメント」というのがあって16バイトアライメントを選べるようになってました。
同様に通常の変数もアライメントできる設定があるかと思い探しましたが見付かりませんでした。
715デフォルトの名無しさん:2011/12/24(土) 02:18:17.32
どう考えてもこれ以上削れないってくらいの手書きインラインアセンブリコードに対し、
C記述版をVC++のReleaseモード(最適化O2)でコンパイルしたもののほうが1.3倍速かったです。
生成されたアセンブリを覗いてみたところ、

変数 * 3

というコードを

lea edx, DWORD PTR [eax+eax*2]

としていてびっくりしました。
これって、アドレス演算を行うローダ(専用の演算器?)を使うことで、
通常のALUと並行して演算(スーパースカラって言うんでしたっけ?)し
高速化しているということなんでしょうか??
716デフォルトの名無しさん:2011/12/24(土) 02:34:46.72
>>714
__declspec(align(N))
717707:2011/12/24(土) 02:44:05.59
>>716
ありがとうございます。
それは知っているんですが、>>707でも書いた通り、
そういった記述をわざわざせずとも、自動で全てアライメントしてくれるような設定があればイイのでは?
と思った次第です。

しかし、上でも仰られたように、互換性の問題があったりで難しいのでしょうね・・・
でも二重インクルード防止の「#pragma once」のように、互換性を考慮しない機能があったりするくらいですから、
自分のようにずっとVC++しか使わない人間を対象にそういうオプションが用意されていても良いのではと思いました。
718デフォルトの名無しさん:2011/12/24(土) 04:29:51.40
>>715
ついでにPartial flags stallも回避できるな
719デフォルトの名無しさん:2011/12/24(土) 05:22:08.10
>>717
キャッシュミスが多くなったら速くならない。
だから隙間が多すぎるのは良くない。

まだそのレベルの高速化を気にするレベルじゃないと思うが、気になるなら続きは↓とかで。
http://toro.2ch.net/test/read.cgi/tech/1322981274/
http://toro.2ch.net/test/read.cgi/tech/1302223650/
720デフォルトの名無しさん:2011/12/24(土) 06:03:11.07
>>713
Nehalemでmovupsのペナルティがなくなったのはアラインメントされている場合だけ
Penrynまではアラインメントされていてもmovapsより遅かった
ハードウェアがどういう実装になっているのかをよく考えてほしい

さらにSandyBridgeでは非アラインメントの場合
2つあるロードユニットが生かされないばかりか追加ペナルティもあるので
アラインメントされている場合に比べて非常に性能が落ちる

movaps/movups使い分けの時代はSegmentation Faultの温床だったので
movupsオンリーで書ける様になったのはうれしいよね

Haswellで32Byteアラインメントが出てくるかと思うと頭が痛いが
721デフォルトの名無しさん:2011/12/24(土) 06:12:36.27
>>716
VCの__declspec(align(N)) や gccの__attribute__ ((aligned(N)))は
スタックやベースポインタからのアラインメントは保証されるけど
ヒープにどう確保されるかは保証されないよ
ランタイムライブラリ依存だからね

そのクラスのnew/deleteをオーバーロードするか
大雑把にグローバルでオーバーロードするかしないといけないが
どちらも一長一短ある
722デフォルトの名無しさん:2011/12/24(土) 08:19:59.68
>>717
ぶっちゃけそれやってどれだけの速度向上が望めるの?って事情もあるんじゃねーの
たかだか1MBに満たないスタックに、って
最近のCPUだとunalignedアクセスの性能低下も軽減されて古いCPUだと速くなるって言われてもなーって気持ちもあると思う
723デフォルトの名無しさん:2011/12/24(土) 08:56:50.23
SandyBridgeもL1D$は1R1Wの4bank構成で
うまくバンクコンフリクトを避けないとペナルティがある
非アラインメントのmovupsは2bank使ってしまう
724デフォルトの名無しさん:2011/12/24(土) 12:22:00.92
>>715
手書きでもふつーにやる。
725715:2011/12/24(土) 14:11:41.35
>>718
おお、そんなメリットもあるんですね。

>>724
覚えておきます。

コンパイラの吐くアセンブラを見てると眩暈がしてきましたw
SIMDやプリフェッチ等のキャッシュ制御を除けば、
手書きでアセンブリ書くのはほとんど効果的でないような気がしてきました。
726707:2011/12/24(土) 14:22:27.84
>>719
なるほど、バイト境界を跨いでしまってアクセス回数が増えることより、
キャッシュに収まって低レイテンシでアクセスし易くなる効能のほうが上回るわけですね。
いかに外部DRAMへのアクセスがコストになっているかがよく分かります。
あと、スレ誘導もありがとうございます。

>>722
>最近のCPUだとunalignedアクセスの性能低下も軽減されて
そうだったんですか。
それだったらmovupsでいいですね。
でも>>723さんの御意見も気になりますので、パフォーマンス測りながら追い込むようにします。
727デフォルトの名無しさん:2012/01/10(火) 00:59:58.08
>>720
64ビットだと、当初MMXが使えなくなるとか言ってた関係で
VCはMMX用の組み込み関数が使えないんだよなぁ
でもって、MMXをSSE2に書き換えるとメモリオペランドのアライメントで
例外が発生したりするんだorz
728デフォルトの名無しさん:2012/01/10(火) 01:14:13.06
もう最初から全部、256バイト境界にアライメント揃えて実行ファイル作っとくかw
729デフォルトの名無しさん:2012/01/10(火) 04:02:17.42
グローバルのnewをオーバーロードしたくなる時は結構ある
730デフォルトの名無しさん:2012/01/10(火) 09:57:01.67
32bitOSを切り捨てたい時もよくある
731デフォルトの名無しさん:2012/01/10(火) 11:53:57.38
intやポインタが64bitになっても面倒なだけだと思うけどな。
732デフォルトの名無しさん:2012/01/10(火) 13:24:45.38
お前がそう思うんならそうなんだろう
お前ん中ではな
733デフォルトの名無しさん:2012/03/09(金) 12:53:25.77
unsigned int maxpos(unsigned int src[256])
{
unsigned int i, m = 0;
for(i = 1; i < 256; i++)if(src[m] < src[i])m = i;
return m;
}
これをSSEで高速化する方法があれば教えて下さい
734デフォルトの名無しさん:2012/03/09(金) 14:27:48.76
byte配列ならPHMINPOSUWで速くなりそうだけど、そのコード基本的に検索だからSSE向きではないな。
最大値求めて、それを検索して位置返すのもありだが、速いかは知らんw
735デフォルトの名無しさん:2012/03/09(金) 15:23:00.43
>>733
src[m]をキャッシュした方が速いと思う。
要は、SSE以前にやることやってからにしろ。
736デフォルトの名無しさん:2012/03/09(金) 17:16:54.28
unsigned intだとSSE4使わないと素で書いたより無駄に遅くなりそうなのしか思いつかないわ
737デフォルトの名無しさん:2012/03/10(土) 14:03:19.33
SSE使った方が遅くなるのは何故でつか?
738デフォルトの名無しさん:2012/03/10(土) 18:35:29.43
日本の道路をF1で走るようなもんだから
739デフォルトの名無しさん:2012/03/11(日) 00:41:15.69
>>733
画像とか統計の基礎だな。疑似コードで書くとこんな感じだ

maxpos(src[256]) {
pos = {0, 1, 2, 3};
for(i=0; i<256; i+=4) {
 s=load(&src[i]);
 isGT=maxVal<s;
 maxVal=isGT&s | ~isGT&maxVal;
 maxPos=isGT&pos | ~isGT&maxPos;
 pos += 4;
}
return max_position(
 maxVal[0], maxPos[0],
 maxVal[1], maxPos[1],
 maxVal[2], maxPos[2],
 maxVal[3], maxPos[3]);
}
740デフォルトの名無しさん:2012/03/11(日) 01:57:27.28
>>739
SSEは max命令とunpackv命令があるんだから
32bitのsrc[i]値を64bitのsrc[i]<<32|iに変換して最大値を求める方が速いと思うね
741デフォルトの名無しさん:2012/03/11(日) 02:00:06.23
740だが、64bitのmax命令はないんだな それなら >>739でいいと思う
スカラーコードより速く
すまん
742デフォルトの名無しさん:2012/03/11(日) 12:51:45.57
>>739
signedの比較命令しかないからダメじゃない?
743デフォルトの名無しさん:2012/03/11(日) 13:56:40.66
なんか知らんが、そんなのずらせば済む事だろ
744デフォルトの名無しさん:2012/03/11(日) 15:40:49.12
実際にコード書いて検証しようぜ。
思い込みと現実は違う場合が結構あるしさ。
745デフォルトの名無しさん:2012/03/11(日) 16:00:05.53
古いPCを使ってるからかもしれんが>>733を単純にアンロールしたのが一番速いな
746デフォルトの名無しさん:2012/03/12(月) 00:37:37.24
スレチではあるが、このコードを高速化する必要がある処理を見てみたい気がした。
747,, ・´ ∀ `・ ,,)っ-○○○:2012/03/12(月) 04:51:41.06
>>742
0x80000000を引く。
足してもいいしXORでもいいけど。
748デフォルトの名無しさん:2012/03/12(月) 19:18:44.41
横レスだけどおおすげー。
そもそも正数同士・負数同士の比較ならsigned/unsignedで結果は変わらないので
問題は正数と負数の比較のみ。確かに最上位ビットを反転させれば万事うまくいくね。
749デフォルトの名無しさん:2012/03/12(月) 19:42:04.67
256個ぐらいだと、最大値を見つけて最大値と同じのを見つけるのだと遅いかな
750デフォルトの名無しさん:2012/03/13(火) 01:41:38.96
signedとunsignedの変換が凄いのか。
この手のテクをまとめようと思ったらどのレベルから書いていいか分からんな。
751デフォルトの名無しさん:2012/03/13(火) 02:23:57.53
>>749
俺は実装が面倒という理由でそれでやってるが
やっぱメモリに2週アクセスするから遅いのでは
752デフォルトの名無しさん:2012/03/13(火) 05:34:13.85
pxor x2+pcmpgtbとpblendvbで最大値のインデックスを保存
インデックスは0x01010101でインクリメント
最後に4要素を比較

4要素あたり2サイクルで回るかな
signed intだったら4要素あたり1サイクルでいけるかも?

unsignedでもcharだとpsub+pblendvbだけでいけるからよいんだけどね
753デフォルトの名無しさん:2012/03/13(火) 05:36:23.52
あpmaxudも必要か
754デフォルトの名無しさん:2012/03/13(火) 05:54:27.09
__m128i pos = _mm_setzero_si128();
__m128i maxpos = _mm_setzero_si128();
__m128i maxsrc = _mm_set1_epi32( 0x80000000 );
#pragma unroll(16)
for( int i = 0; i < 256; i+=4 )
{
__m128i signed_src = _mm_xor_si128(
_mm_load_si128( (__m128i*)&src[i] ),
_mm_set1_epi32( 0x80000000 ) );
__m128i mask = _mm_cmpgt_epi32( signed_src, maxsrc );
maxpos = _mm_blendv_epi8( pos, maxpos, mask );
maxsrc = _mm_max_epi32( maxsrc, signed_src );
pos = _mm_add_epi32( pos, _mm_set1_epi32( 1 ) );
}
以下略
実行してないのであってるかは知らん
755,, ・´ ∀ `・ ,,)っ-○○○:2012/03/13(火) 12:31:21.86
> unsignedでもcharだとpsub+pblendvbだけでいけるからよいんだけどね

その程度ならpacked floatにキャストしてblendvpsでもいけるけどね。

SSE4対応以前ならpmovmskb/maskmovps+test+jccでもいけるか
(メディアンならともかく最大値ならcmovより分岐のほうが速いはず)
756デフォルトの名無しさん:2012/03/13(火) 14:51:08.23
>>755
pbledvbは7+8nのビットしか読まないから符号の判定に使える

SSE4以前だとmaskにはand+andnot+orが使われてたね
757デフォルトの名無しさん:2012/03/13(火) 14:52:50.84
Penrynだと下手にblendv系使うより速い場合もあったりした
758デフォルトの名無しさん:2012/03/13(火) 14:59:06.94
ごめんblendvpsも31+32nビットしか読まないのか
勘違いしてた
符号の判定に使えるね
759デフォルトの名無しさん:2012/03/14(水) 00:38:46.60
>>757
PenrynのPBLENDVBはレイテンシ1、スループット2で
SandyBridgeはレイテンシ2、スループット1か…

Penrynはデコーダの制限もありそうだし、and,orでもよさげ
760デフォルトの名無しさん:2012/03/14(水) 00:46:50.97
HTが使えるCPUならblendの方がいいかな?
761,, ・´ ∀ `・ ,,)っ-○○○:2012/03/14(水) 07:19:23.65
どうせ全検索するんだしレイテンシの長さ分だけインタリーブすればレイテンシ隠せるよ
762,, ・´ ∀ `・ ,,)っ-○○○:2012/03/14(水) 07:23:58.09
packed unsigned intの比較(マスク生成)だけど、両項のMSBを反転してからpcmpgtdするより
psubd + psradのほうが速いかもしれない
763デフォルトの名無しさん:2012/03/14(水) 09:52:48.15
>>762
どっちも2命令でXORの方が実行出来るポートが多い分有利そうに感じるのだが
764デフォルトの名無しさん:2012/03/14(水) 20:30:50.02
pdangod
765デフォルトの名無しさん:2012/03/19(月) 10:59:48.11
>>762
blendvps用のマスクならpsubdだけでよい
blendvpsは最上位ビットしか見ないから
766デフォルトの名無しさん:2012/03/21(水) 21:47:07.57
話の流れぶった切るけど団子さんよ〜。
今の静的分岐予想って相変わらずifよりelseの方が速いの?
ifとelseのどっちが速いか正確に計測するにはどういうコード書いたらいい?
767デフォルトの名無しさん:2012/03/21(水) 23:28:17.45
あれ?ifの方が速いんじゃなかったか
768デフォルトの名無しさん:2012/03/21(水) 23:53:20.16
P6,P2,P3,P4はforwardならnot taken backwardならtakenがデフォルト
P4はPrefixでヒントを出せる
PM,Core2はランダム
ソースはAgner
769,, ・´ ∀ `・ ,,)っ-○○○:2012/03/24(土) 09:22:43.82
分岐予測履歴がない場合あるいは予測そのものがない場合、条件付ジャンプは前のアドレスに
飛ぶ場合(多くの場合ループ)は原則ジャンプ、後ろならスルーが多くのCPUの実装ですね。
大体のコンパイラってforやwhile文はこんな感じに展開するでしょ?
if (cond) { do { ... } while(cond); }
770デフォルトの名無しさん:2012/03/24(土) 12:02:04.61
>>769
モダンなCPUはどんな感じなのよ
>>768 はランダムだと言ってるけど
モダンなCPUでも静的予想だとifはスキップ
whileはループ確定なのけ。
771デフォルトの名無しさん:2012/03/24(土) 19:11:37.76
分岐履歴が無いのに前方への分岐を予測したら命令フェッチをやり直さなきゃならないじゃん
後方への分岐はループの場合が多いから特別扱いなんだと思う
772デフォルトの名無しさん:2012/03/24(土) 21:14:58.62
大概returnやthrowが行われるからifをすっ飛ばせば速いのは解る。
反復も反復する事を優先した方が早いのは解る。
それはいいとして、今のCPUは分岐ヒントとか投棄とかあって単純じゃないんだろ。
そこを知りたいんだがね。
773デフォルトの名無しさん:2012/03/24(土) 21:25:07.37
>今のCPUは分岐ヒントとか投棄とかあって単純じゃないんだろ。
パイプラインが深いだけでしょ
774デフォルトの名無しさん:2012/03/24(土) 21:33:04.06
わかってないのにわかったつもりになって
単語だけ並べているように見えるのは何故だろう
775デフォルトの名無しさん:2012/03/24(土) 21:41:50.71
そう思ってくれるのはいいが、間違いの指摘と
実際はどうなってんのか答えてくれ
批難だけの回答はいらん。
776デフォルトの名無しさん:2012/03/24(土) 21:45:20.20
>>773
分岐予測の話はパイプラインが深いこと前提で話してるわけで・・・
777デフォルトの名無しさん:2012/03/24(土) 21:50:30.10
>分岐予測
って、言い方してるだけなの?
778デフォルトの名無しさん:2012/03/24(土) 21:52:06.49
>>775
じゃあ間違いを指摘してやる。

>大概returnやthrowが行われるからifをすっ飛ばせば速いのは解る。
前方への条件分岐は、「分岐しない」と予測される、とオマエ以外の全員が言っている。
if (xx) return
で「すっ飛ばせば云々」なんて、理解していないまま「わかったつもりになってるだけ」の証拠。

>今のCPUは分岐ヒントとか投棄とかあって単純じゃないんだろ
ヒントはともかく、投機はまさに「投機実行するために分岐予測をする」のであって
「投機実行もあるから分岐予測が複雑になる」はナンセンス。
もちろん、エンプラ系/VLIW系では「分岐の有無の両経路を実行する」なんてのもある(らしい)が
一般的とは言いがたい。
779デフォルトの名無しさん:2012/03/24(土) 21:59:34.64
>>778
内容じゃなく国語的に誤解されてるな。

>前方への条件分岐は、「分岐しない」と予測される、とオマエ以外の全員が言っている。
if( xx ) throw xxx;
throwなんて実行するケース殆ど無いんだから基本if実行しないってのは同じ話。
矛盾してないでしょ。

まず分岐予測が複雑になってるって話はしてないよ。
投棄実行については投棄実行を考慮した上での静的予測方法があるでしょという話。
780デフォルトの名無しさん:2012/03/24(土) 22:04:11.41
>>779
だから、ifの内部は「実行すると予測される」んだよ、バーカ
781779:2012/03/24(土) 22:05:34.03
尤も、わかりやすいからifと書いたけど、
実際はコンパイラの最適化でif、elseは反転するから
この言い方は正しくは無いんだけどね。
782デフォルトの名無しさん:2012/03/24(土) 22:06:41.25
せめて正しい漢字使えよ。

一度なら単なる変換ミスとして納得できるけど
繰り返しているってことは、別の意味に捉えているとしか思えない。
783デフォルトの名無しさん:2012/03/24(土) 22:09:32.88
>>780
お前バカだろ
みんなアセンブリ前提で言ってんだよ

jze label   if() {
・・・処理・・・
labeli     }
784デフォルトの名無しさん:2012/03/24(土) 22:12:25.76
>>782
ん?尤も(もっとも)か?無い(ない)か?
785デフォルトの名無しさん:2012/03/24(土) 22:20:41.79
>投棄実行については投棄実行を考慮した上での静的予測方法があるでしょ

理解できる日本語で書いてくれないかな。

分岐予測というのは、投機的に(結果が判明する前に)実行する前提でのもの。
(無条件分岐や間接分岐もあるから、厳密には正しくないけど)
予想して(投機的に)実行するのでなければ、単に結果が判明するのを待って、それから実行すればよい。

つまり、投機実行するからこそ分岐予測が必要なのであって
投機実行しないのであれば、分岐予測など元々必要ない。
そのことをちゃんと理解していれば、
そもそも「投機実行を考慮しない分岐予測」などというものが存在しないから
>投棄実行を考慮した上での静的予測方法
が意味不明に感じられる気がするんだけどな。

>>783
わかってるよ、そんなこと。
786デフォルトの名無しさん:2012/03/24(土) 22:22:22.48
>>780 ifが優先されると思ってたのは>>767 とお前ぐらいだよ
787デフォルトの名無しさん:2012/03/24(土) 22:25:19.71
>>785
ごめん。もう今更何を言おうが>>780のせいで信用ないわ。
788デフォルトの名無しさん:2012/03/24(土) 22:34:54.17
>>782
ああ投棄実行ね投機の変換ミスそのままにしてたわ
789デフォルトの名無しさん:2012/03/24(土) 22:48:33.55
投棄実行については誤解してたわ。
2つの分岐を両方実行して実際実行対象にならなかった方の結果を破棄するものだと思ってた。
790デフォルトの名無しさん:2012/03/24(土) 22:50:38.87
>大概returnやthrowが行われるからifをすっ飛ばせば速いのは解る。

もう一度考えてみたけど、この意味が全然理解できない。
ぱっと見で、何故returnや、
増してthrowなどという言葉が出るのかわからない。
(GP等の例外の割り込みは全く別物)

で、次の行の
>反復も反復する事を優先した方が早いのは解る。
の意味は、「ループであることが推測されるから分岐すると予測する」だよね?
それとの対比で、「ifをすっとばせば」の意味が
「ifの内部は実行されないと予測」と捉えれば
「ifの部分での分岐は分岐すると予測すれば
if内部のreturnやthrowに制御が来ないので別の分岐の予測を避けられる」という意味にもとれる。
それならようやく意味が通じるような気がして、そういう意味だと思ったんだけど。
つまり、ifの部分(=前方分岐)を「分岐すると予測する」という意味だと。

でもそれ(前方へ分岐すると予測する)は実際のプロセッサの動作とは違うわけで
ならばどういう意味なのか、さっぱりわからなくなってしまってね。
791デフォルトの名無しさん:2012/03/24(土) 23:00:43.72
お前の文章が解らんわ
792デフォルトの名無しさん:2012/03/24(土) 23:01:04.27
一応。

突然returnやthrowが出てくるのが
if (xx) return
という意味じゃないか、というのも勝手に俺が頭の中で補って想像しただけで
実際には何の説明も無く(ifの多くがreturnやthrowというのにも同意しにくい)
唐突な「rerturnやthrow」「すっ飛ばす」を必死に理解しようとしたのがそもそもの間違いかもね。
793デフォルトの名無しさん:2012/03/24(土) 23:01:51.31
実行時の分岐予測って、どうなってるのかわかってないと、グダグダでしょ
794デフォルトの名無しさん:2012/03/24(土) 23:04:39.09
>>792
>>779で補足だしてるだろしつこいわ
795デフォルトの名無しさん:2012/03/24(土) 23:09:08.21
>>790 >>792 ウゼェ・・・
796デフォルトの名無しさん:2012/03/24(土) 23:18:44.32
>>794
>>779だとしたら>>780だっての。
「前方分岐は分岐しないと予測する」のが実際のプロセッサの動作なわけ。
>>779の「throwなんか滅多に起こらないから実行しない(と予測する)」は
「前方分岐は分岐すると予測する」ことになるから実際の動作と矛盾するという話。
それを、「わかってないくせに」の根拠の一つにしたんだよ。

実際、「分岐予測とはどういうものか」も「なぜ分岐予測するのか」もわかってなかったわけでしょ(>>789)。
797デフォルトの名無しさん:2012/03/25(日) 01:09:12.01
口汚い言葉で罵倒せずには居られない奴って下品・・・。
団子さんの紳士っぷりを少しは見習ったらどうだろうか。
798デフォルトの名無しさん:2012/03/25(日) 01:16:07.87
もう>>780はいいから団子さんこないかな
799デフォルトの名無しさん:2012/03/25(日) 01:24:14.75
え?指摘するの780だけ?
露骨だなぁ。恥ずかしくないんだろうか。
800デフォルトの名無しさん:2012/03/25(日) 02:30:29.23
お前がなwww
801デフォルトの名無しさん:2012/03/25(日) 03:19:03.04
頭が悪すぎて理解できなかったらしいから仕方ないな。
802デフォルトの名無しさん:2012/03/25(日) 14:12:21.08
>>796
投機実行という言葉については誤解してました。
分岐予測については、分岐ミスでパイプラインに読み込んだ
命令を破棄が発生するという認識です。

そもそも、それが気にならないのであれば分岐予測なんて
気にする必要はないでしょう。
803デフォルトの名無しさん:2012/03/25(日) 16:12:43.94
インテルの最適化マニュアルだと
>インテルPentiumM プロセッサー、インテルCoreSolo プロセッサー、インテルCoreDuoプロセッサーは、
>ジャンプの向きに従った条件分岐を静的には予測しない。これらのプロセッサーでは、
>すべての条件分岐は、最初に発生したときでも動的に予測される。
と書いてあって、wikiで調べたらPenM以降は広域分岐予測を取り入れた関係で静的予測はしなくなったみたいだね
ttp://ja.wikipedia.org/wiki/%E5%88%86%E5%B2%90%E4%BA%88%E6%B8%AC

>>768
>PM,Core2はランダム
というよりも、「前に実行した別の分岐命令の結果も影響する」とした方が適切みたいだ

分岐予測に関して
ttp://news.mynavi.jp/column/architecture/index.html
の第167回からの解説が参考になるよ
804デフォルトの名無しさん:2012/03/25(日) 18:09:59.76
>>803
なるほど。いい話が聞けました。ありがとうございます。
805デフォルトの名無しさん:2012/03/28(水) 00:06:00.96
>>803
>と書いてあって、wikiで調べたらPenM以降は広域分岐予測を取り入れた関係で静的予測はしなくなったみたいだね
P4もグローバル履歴を使ってるよ

おそらくだけど ある分岐命令を最初に実行したかどうかはBTBのエントリが割り当てられているかで判断するので
分岐先予測より分岐予測のヒット率が十分に高い場合は動的分岐予測が当たる条件で誤って静的予測してしまう確率が高いから
1回目の分岐予測を諦めても静的予測をやめたほうがヒット率が上がるということなんじゃないだろうか
806デフォルトの名無しさん:2012/03/28(水) 00:11:22.64
×分岐先予測より分岐予測のヒット率が十分に高い場合
○BTBのヒット率より分岐予測のヒット率が高い場合
807デフォルトの名無しさん:2012/09/07(金) 22:44:12.83
これからSSEを使ってみようと思うんですけど、Cから使う場合の
SSE Intrinsicの解説書でおすすめのものはありますか?
Amazonで探したんですけど、SSEの解説書はアセンブラのものしか
見つけられませんでした。
808デフォルトの名無しさん:2012/09/07(金) 23:31:39.23
>>807
基本的な使い方はアセンブラで覚えて、組み込み関数への変換は
http://software.intel.com/en-us/avx/
のIntrinsic Guidを使って対応する関数を探すようにすればそのうち慣れてくると思うよ。
809デフォルトの名無しさん:2012/09/08(土) 00:19:54.30
810デフォルトの名無しさん:2012/09/08(土) 09:05:03.86
>>808
これ、日本語が用意されてないあたり、もう日本は完全に商売の相手としてみなされてないんだろうな・・・。
中国語はあるのに。
811デフォルトの名無しさん:2012/09/08(土) 09:43:31.00
米中の長期的戦略では日韓は中国に併合される
おまいらも今のうちから中国語勉強しておいた方が良いぞ
812デフォルトの名無しさん:2012/09/08(土) 10:02:01.94
中国に併合?なら大丈夫だ。
中国語の一方言として日本語は残る。
やつら、言葉が通じなくても全然気にしないし。
813デフォルトの名無しさん:2012/09/08(土) 10:14:57.49
すぐ暴力に訴えるからな
814デフォルトの名無しさん:2012/09/08(土) 10:58:16.73
>>808>>809
まとまった書籍があればと思いましたが、そういうのはないですか。ありがとうございました。
815デフォルトの名無しさん:2012/09/09(日) 14:17:37.65
>>810
スタッフに日本人はいないが中国人はいるだけの話。
あと、日本人で必要な人は英語を読んでしまうので、いらないと言えばいらないからじゃないか?
816デフォルトの名無しさん:2012/09/09(日) 19:22:22.77
それもあるだろうが、日本人は押しが弱くて文句言わない(言えない)とか
中国人なら「読めない!何とかしろ!」とIntelに怒鳴むに違いない
817デフォルトの名無しさん:2012/09/10(月) 11:30:11.68
中国語のサイト見るとあっちのプログラマはかなりがんがってる
理系離れ技術者軽視でバカマスゴミに蹂躙されてる日本はもうだめだ
818デフォルトの名無しさん:2012/09/10(月) 13:14:27.74
Intelの日本法人が人手不足っていうだけかと
819,, ・´ ∀ `・ ,,)っ-○○○:2012/09/10(月) 19:11:56.20
現実見ろや
中国語圏の人口は日本語圏の10倍以上いる
820デフォルトの名無しさん:2012/09/11(火) 22:57:53.20
つーかどう考えても世界最大勢力w
821デフォルトの名無しさん:2012/09/12(水) 00:32:29.23
コンピューターの世界では英語が最大勢力ではないか
822デフォルトの名無しさん:2012/09/12(水) 07:47:54.64
いまのEmacsのコミッタって中国人なんやね
823デフォルトの名無しさん:2012/09/13(木) 05:39:46.78
あっちはgeekの受け皿も多いからなあ
英語もできないくせにコミュニケーション能力とか言って
オタを弾き出してる日本人が食っていける仕事じゃなくなったね
824デフォルトの名無しさん:2012/09/16(日) 21:01:12.14
中国人は日本以上に英語ができないからな。
825デフォルトの名無しさん:2012/09/16(日) 23:51:27.54
んなこたーない。
826デフォルトの名無しさん:2012/09/17(月) 00:08:04.54
ピンキリのスパンが大きくて
ネラー級の教養で大陸ならピン側寄りで
キリの人数が日本の人口超えてるのは事実
827デフォルトの名無しさん:2012/09/20(木) 00:11:06.49
ループ内不変のクラスメンバ変数の参照を自動変数に代入して置き換えると
結構違いが出るね。
828,, ・´ ∀ `・ ,,)っ-○○○:2012/09/20(木) 03:33:48.73
自動変数は可能ならレジスタに配置するからね
829デフォルトの名無しさん:2012/09/20(木) 13:26:01.82
>>828
だけじゃなくて、メンバ関数の呼び出しが
あれば、少なからず実際に呼び出す
必要があるからじゃね。
うかつにキャッシュできるもんでも
ないしね。
830デフォルトの名無しさん:2012/09/20(木) 17:47:56.27
じゃあこれも結局そうなの?

http://qarc.info/qa/show-11205-871.html
831デフォルトの名無しさん:2012/09/20(木) 19:52:09.30
クラスオブジェクトはポインタで管理されてるから
エイリアシングの最適化と似たような問題があるんだと思う。
832デフォルトの名無しさん:2012/09/21(金) 03:59:51.50
エイリアシングってあれか
ポインタの値をレジスタに持ったままに出来ずその都度ロードするあれか
だからFORTRANよりも速く出来なくて restrict って予約語がC99に作られたんだな
VCなら__restrictを付ければ同じなんで少しはクラスは速くなるかな
あ、だめか
thisをrestrict化出来ないや
833デフォルトの名無しさん:2012/09/21(金) 04:45:42.15
http://www.ertl.jp/~takayuki/readings/info/no06.html

ここがよく分かるな
Cをコンパイルした時にポインタ変数がレジスタ割り当てされたら
ハードウェア的にコヒーレンシを保証してくれる仕組みでもないものだろうか
834デフォルトの名無しさん:2012/09/23(日) 11:31:02.45
constつければいいだけだろ。
835デフォルトの名無しさん:2012/09/23(日) 11:35:51.01
constは安全だけどrestrictは相当注意して使わないと危険。
836デフォルトの名無しさん:2012/09/24(月) 00:32:15.53
「ポインタは基本的にどこでも指し示せる」という性質が問題なんだよ
これがFORTRANにもアセンブラにもない(厳密にはアセンブラにもあるけどそんな馬鹿な事はしない)
厄介事を引き起こして最適化の妨げになっている
837デフォルトの名無しさん:2012/09/24(月) 00:40:17.40
カプセル化をうっかりブチ壊せちゃうOOP気取りのクソ言語
838デフォルトの名無しさん:2012/09/24(月) 17:13:46.52
だからC++の哲学は「うっかりミスを防ぐ」だけであって、故意にOOPのバリアを
ぶち破ろうとする悪意には抵抗力はない
839デフォルトの名無しさん:2012/09/24(月) 20:48:22.50
Cはむしろエイリアスの問題を無視すればよかったのに
どうせバッファーオーバーフローだって無視されてる

アセンブラと同じくエイリアスが問題が原因のバグはプログラマのせいにするとか
840,, ・´ ∀ `・ ,,)っ-○○○:2012/09/24(月) 21:34:41.25
Win32でいうCreateThreadのパラメータにthisポインタを渡して・・・みたいな厨テクってやってる人いるけど
やっぱ害悪なんだろうな。
SSEとか駆使するときは極力クラス使わずベターCで使ってるわ。
841,, ・´ ∀ `・ ,,)っ-○○○:2012/09/24(月) 22:53:23.26
VC++の場合、thisポインタはecxレジスタに渡され、メンバ変数や仮想関数テーブルは
ptr[ecx + offset]みたいな形でアクセスされると思うんだけど、
パラメータにecxをとる命令って結構多い(シフト・ローテートなど)
当然、ecxの中身を都度入れ替えるよね
ローカル変数にコピーしたら速くなるってそういうことなのかも

メンバ関数は特に必要がなければstaticにしてthisポインタを渡さないようにしてみると
いいかもしれない
842デフォルトの名無しさん:2012/09/25(火) 03:54:43.28
>特に必要がなければstaticにして

ベターCどころか記述が面倒な糞言語
それがC++
843,, ・´ ∀ `・ ,,)っ-○○○:2012/09/25(火) 04:09:22.33
そりゃC++を積極的に使う理由がないですわ。
templateを使ったメタプログラミングは便利だけどね
844デフォルトの名無しさん:2012/09/27(木) 05:17:17.23
そんなレベルで最適化が必要なら、最初からアセンブラ使えとおもうのは俺だけ?
845 ◆0uxK91AxII :2012/09/27(木) 06:49:04.92
intrinsicを使うと、32bit, 64bit両方を一発で書けるのがいい。
846デフォルトの名無しさん:2012/09/27(木) 11:59:11.92
>>844
だけじゃないけど少数派だろう。
動くものを作ってから置き換えないと、どこのバグなのかわかりにくい。
847デフォルトの名無しさん:2012/09/27(木) 19:50:42.91
_mm_slli_si128のシフト量は即値だけど、可変にしたい場合は替わりに何を使えばいいのかな?
switchで切り替えるかshuffleのmaskを配列で用意しておくというのは思いついたけど。
848デフォルトの名無しさん:2012/09/29(土) 16:56:08.35
SSSE3が使えるならpshufb+配列がいいだろうね
そうじゃないなら分岐するか自己書き換えするか

シフト量4以下限定なら
movdqa dst, src
psrldq dst, 4
psllq src, shamt
psllq dst, shamt
pslldq dst, 4
por dst, src
5以下限定なら
movdqa dst, src
movdqa tmp, src
psrldq dst, 3
psrldq tmp, 5
psllq src, shamt
psllq dst, shamt
psllq tmp, shamt
pslldq dst, 3
pslldq tmp, 5
por dst, src
por dst, tmp
...とか煩わしいができなくもない(shamtはシフト量*8としてxmmに入れておく)
849デフォルトの名無しさん:2012/09/30(日) 01:05:27.99
zeroとpalignrするというのを思いついた。
850デフォルトの名無しさん:2012/09/30(日) 01:20:11.21
palignrも即値だけ
851,, ・´ ∀ `・ ,,)っ-○○○:2012/09/30(日) 17:31:17.41
妙なことやるよりstoreしてlddquが一番シンプルな解決策だったりするかもな。
852デフォルトの名無しさん:2012/09/30(日) 22:01:14.77
くそー64bitモードでCompiler Instinctsじゃなくてasm復活させろよ
何のためにC++にわざわざasmキーワードが予約されてんだよ
853デフォルトの名無しさん:2012/09/30(日) 22:02:54.03
解決策: gccかclangを使う
854デフォルトの名無しさん:2012/10/01(月) 22:52:27.70
gccは-masm=intelでintelシンタックスでもasm使えるけど、
ダブルクォートはどうにもならないよねぇ。
ただでさえSSEのバージョンに応じたコード用意するのが面倒なのに
64bitとgcc向けで組み合わせが膨れ上がるよ。
intrinsicsでいいや、って思うようになったよ。
855デフォルトの名無しさん:2012/10/01(月) 22:57:59.24
64bitと32bitは工夫すれば共通化できるよ
確かにダブルクォートはどうにもならんけどね
あれのせいでメンテナンス性が落ちてるのは確かだ
856デフォルトの名無しさん:2012/10/01(月) 23:36:22.63
>>855
>64bitと32bitは工夫すれば共通化できるよ
intrinsicsなら同じソースで簡単に64bitに出来るけど、gccのインラインアセンブラで
共通にするには制約無い?それにレジスタが増えるメリットが生かせないんじゃない?

Xvidに32bit/64bit共通.asmってのがあったっけ。制約きつそうだったけど。

面倒だけどインラインアセンブラからintrinsicsに徐々に置き換えつつデバッグ済ませとけば
その後はコンパイラの違いや32bit/64bit、SSE/AVXにも対応しやすいよ。
857デフォルトの名無しさん:2012/10/02(火) 00:04:19.23
もちろん同時に使えるレジスタ本数は8本までになるけど
そもそも16本フルで使うと性能上がるようなコードは
intrinsicsで書くにしても分けると思うなあ
(アンロールをどの程度するか、ループ内の定数をレジスタに置くかメモリに置くか等)

MSコンパイラはどうか知らんけどgccはintrinsicsにおまかせすると
レジスタのやりくりがタコで無駄なスタック退避が多かったりして
あまり積極的に使う気にはならんかった。

AVXなコードも書いてるけどintrinsicsに移行するよりは
素のアセンブリで書く機会が増えた印象。
intrinsicsだと128bit VEXとnon VEXの使い分けとかやってくれないよね
858デフォルトの名無しさん:2012/10/02(火) 00:10:41.35
gccのインラインアセンブラで32bitと64bitを共通化するときに困るのは
自動割り当てを使うときに32bitな変数に割り当てられたレジスタを
64bitでアクセスしたい時かな。
例えばループ変数は32bitだけどそのループ変数をインデックスレジスタに使いたいとか。
859,, ・´ ∀ `・ ,,)っ-○○○:2012/10/02(火) 01:22:46.83
> intrinsicsだと128bit VEXとnon VEXの使い分けとかやってくれないよね
コンパイルオプションで切り分けろ

複数のCPU向けの最適化コード書く場合、同じソースファイルにVEXとnon-VEXのコード
記述できないので面倒にはなったね

そのくせ_mm_broadcast_ssとかload+shufpsなどに展開してくれないから困る
860デフォルトの名無しさん:2012/10/02(火) 02:23:50.50
>複数のCPU向けの最適化コード書く場合
それ以外に、単純にAVX対応CPU向けのコードでも
VEXを使うと命令長が長くなる場合があるので(SSE単精度SIMD,REXなしでソース破壊可能な場合)
命令毎に使い分けたいという話なのだ
さすがにintrinsicsでも2/3バイトVEXの使い分けぐらいはやってくれるのかな?

まあuop cacheのあるSandyで命令長にこだわる意味がどこまであるのかという話ではある
861デフォルトの名無しさん:2012/10/02(火) 02:24:51.90
SSEはデコードが大変だから将来は遅くなるかもって記事があったよね。
そういう状況ではインラインアセンブラはlegacyってことなのかもね。

>>857
VCでも2008(std)から2010(EE)に変えたら速くなったし(2012EforD)ではほとんど差が無さそう)
2010のも自分だったらこう並べないよなぁって思う部分があったり、SIMD以外の部分との連携が
気になるとか、そういうのはあるよ。
IACAで手抜き解析するとCP(クリティカルパス)が並んでたし、スループットもその合計に近いので
それなりにがんばってそう(ポートの表示はほぼ意味不明だけど)。
http://software.intel.com/en-us/articles/intel-architecture-code-analyzer
VCの64bitはインラインアセンブラが使えないからIACAも使えないけど、
32bitより多少は速くなることが多いみたい。

SSEはdestが破壊されるから速いコードは寿命の長いデータがレジスタ間を漂うようなコードになるので
正直あまりやりたくないなぁ。
レジスタが余っていたらパイプライン化を目指すので共通コードにはしないかなぁ。
862,, ・´ ∀ `・ ,,)っ-○○○:2012/10/02(火) 02:45:53.68
> さすがにintrinsicsでも2/3バイトVEXの使い分けぐらいはやってくれるのかな?
大体のコンパイラはそのへんタコってるよ。-Osオプション何のためにあるんだか・・・

> まあuop cacheのあるSandyで命令長にこだわる意味がどこまであるのかという話ではある

小さいに越したことはないから余裕があったら手作業でコードサイズ縮小やってるね。
YASMで組む場合は変数を%defineで適当な変数名つけてレジスタ使ってるよ
dest, src1に使う頻度の高いレジスタをx(y)mm8〜15に配置すれば大体2バイトVEXに収まるんだよね。
もちろんSSEでは全く逆の割り当てをやる。

> VCの64bitはインラインアセンブラが使えないからIACAも使えないけど
VCの64ビット版は/FAsでasmコード生成して吐き出したコードにIACAマーカー仕込んでml64通すかな。
そこまでパフォーマンス解析が必要なコードならそもそも、コンパイラの最適化を信用しないかも
863 忍法帖【Lv=28,xxxPT】(1+0:5) :2012/10/31(水) 19:17:53.71
ん…。
864デフォルトの名無しさん:2012/11/02(金) 17:48:11.10
>>832 亀レスですまんが
関数に _restrict 付ければ this に付けたことになるんじゃなかったか?
865 忍法帖【Lv=31,xxxPT】(1+0:5) :2012/11/03(土) 12:42:51.04
整数に関するCPU拡張命令って、あまり数が充実してないね。
866デフォルトの名無しさん:2012/11/03(土) 12:45:20.76
需要がねーもん
867 忍法帖【Lv=31,xxxPT】(2+0:5) :2012/11/03(土) 12:47:44.67
そうか…残念だ。
868デフォルトの名無しさん:2012/12/01(土) 17:08:51.43
あげ
869デフォルトの名無しさん:2012/12/02(日) 16:22:09.19
これからは固定小数の時代か…
あれやこれやを固定小数で解けるようにするのは大変そうだね
870デフォルトの名無しさん:2012/12/02(日) 16:49:35.82
んなこたーない。
871デフォルトの名無しさん:2012/12/03(月) 00:32:15.60
固定小数があれば
増税したい放題
公共事業費ネコババしたい放題
ノーパンしゃぶしゃぶ無料で接待
もうえらいことです
872 忍法帖【Lv=40,xxxPT】(1+0:5) :2012/12/03(月) 07:57:12.83
何言ってんだ?
873片山博文MZボット ◆0lBZNi.Q7evd :2012/12/04(火) 13:12:49.38
>>869>>871
固定小数をクラスにしてみた。
http://ideone.com/x2uolH
874デフォルトの名無しさん:2012/12/07(金) 11:25:53.23
>>873
整数部がint_partなのはいいとして、小数部がdecimal_partなのは如何な最中と。
違うシフト値を持った固定小数点数同士のキャストオペレータが欲しいところだな。
floatは精度がintよりも精度が低いから、doubleとのキャストオペレータも欲しいな。
875片山博文MZボット ◆0lBZNi.Q7evd :2012/12/07(金) 14:48:43.69
あまりキャストオペレータばかり作ると曖昧になっちゃうんじゃない?
876デフォルトの名無しさん:2012/12/09(日) 11:13:54.82
だったら寧ろ、floatいらね。
877デフォルトの名無しさん:2012/12/09(日) 15:13:41.29
固定小数点数のことを固定小数と書くやつのソースを見てあげる優しさは素晴らしい。
符号ビットの指定もできないし、幅も int 固定だし、ものを知らない。
固定小数点数ルーチンなんていくらもあるんだから、他人に見せるんなら、他と比べてメリットのあるものにしてほしいね。
decimal は通貨用のを恥知らずにも参考にしたんだろうね。
878デフォルトの名無しさん:2013/01/07(月) 20:31:50.25
>>875
今時のコンパイラなら、explicitをつければキャスト演算子必須な変換関数が作れる。
explict operator float() const { …… }みたいな感じ。
879片山博文MZボット ◆0lBZNi.Q7evd :2013/01/11(金) 15:12:09.26
>>878 ありがと
880デフォルトの名無しさん:2013/09/25(水) 22:42:54.37
vs2010 x64でアドレスに16bitのオフセットを加算しようとすると
movzx esi、word ptr[]
add rsi、r15
みたいなコード吐くんだけど、
これってパーシャルレジスタストールする?
881デフォルトの名無しさん:2013/09/25(水) 22:45:27.74
32ビットレジスタへの書き込みは自動的に64ビットにゼロ拡張されるんじゃなかったっけ
882デフォルトの名無しさん:2013/09/25(水) 23:12:56.51
64bitモードで32bit書き込みした場合上位32bitはクリアされるってwebで見つけたから
ストール無しなのかな
883デフォルトの名無しさん:2013/09/25(水) 23:19:20.46
REXを省略するための工夫だからストールはしないよ。
884デフォルトの名無しさん:2013/09/26(木) 00:35:37.10
>>883
>>881
スッキリしました
ありがとう
885,,・´∀`・,,)っ-○○○:2014/05/29(木) 20:00:32.71 ID:lUpNZIqd
レガシーSSEもYMM上位ゼロクリアならどれだけ楽だったか
886デフォルトの名無しさん:2014/05/30(金) 20:15:02.46 ID:jY9kjQQc
部分的な入れ替えはシャッフル的な命令使うことを強制しておけば、CPUを作る側も楽だったろうに。
887デフォルトの名無しさん:2014/05/31(土) 22:50:23.70 ID:LCfd5xM6
MC68000にはmovqという命令があってだな(しみじみ
888デフォルトの名無しさん:2014/06/02(月) 19:21:08.89 ID:8JTSYrBj
なにその clr.l より速い命令
889デフォルトの名無しさん:2014/06/23(月) 20:54:19.11 ID:gCMZG5du
x64のgccで使われているmovqはmove quadって意味だよね
890,,・´∀`・,,)っ-○○○:2014/06/23(月) 21:13:16.17 ID:yaiQwJtG
move qwordです

8086時代からの伝統でword=16ビット
891デフォルトの名無しさん:2014/07/20(日) 21:51:09.79 ID:hMBGYG/C
512bit SIMDはまだかのう。
19x19の碁盤を一レジスタに収めたいんだが。
512bitシフト演算もできるとええのう。
892デフォルトの名無しさん:2014/08/06(水) 13:00:40.68 ID:YJYkBYpf
碁石ってシフトのような動きするのか?
893デフォルトの名無しさん:2014/08/07(木) 19:26:33.11 ID:/tiJ31dE
シフトすれば斜めに置いてあるのを同時に扱えるんじゃない?
894デフォルトの名無しさん:2014/08/07(木) 20:18:32.91 ID:ZNqBW9eR
石の繋がりを調べるのにシフトしてandとったりする。
895デフォルトの名無しさん:2014/08/21(木) 00:19:45.14 ID:gFJa9U99
特にアライメントせずに確保した配列(std::vector標準のアロケータ)に対し、
AVXの_mm256_load_psや_mm256_store_psでアクセスしても何事もなく処理が実行されます。

以前、SSEのときは、アライメントされていない配列に対し、_mm_load_psや_mm_store_psを行うと、
プログラムがクラッシュしていました。

アライメントされた配列に対し、loadu_psやstoreu_psを使っても、
load_psやstore_psと比べてパフォーマンス低下が起こらなくなったというのは聞いていますが、
アライメントされていない配列に対し、load_psやsotre_psを使っても動くようになったというのは聞いたことがありません。

AVXになってから、このような挙動に変更されたのでしょうか??
896,,・´∀`・,,)っ-○○○:2014/08/21(木) 00:47:52.02 ID:WeLFut8I
された。
聞く前にまずIntelが出してるリファレンスマニュアル目をとおしなよ。
君は仕様書も目を通さずにプログラムを書く人間なのかい?
897895:2014/08/21(木) 01:00:22.02 ID:gFJa9U99
団子さん、ありがとう!
Intel CPUはどんどん便利になっていくね。
898デフォルトの名無しさん:2014/08/21(木) 03:05:34.68 ID:7/onAByI
でも、アライメントを保証できる状況の方が-mavxを指定したときに
ループがベクタ化されて出力されるアセンブリがより高速な組み合わせになった希ガス。
899デフォルトの名無しさん:2014/08/21(木) 20:16:59.91 ID:o3QnzrK3
1024bit SIMD搭載CPUが廉価で発売されたら本気出す。
900,,・´∀`・,,)っ-○○○:2014/08/23(土) 14:19:39.84 ID:aDxyXNe8
AVX-1024なんて出るのかしら
マスクレジスタが128ビットになるからそのままだと汎用レジスタの幅が足りなさそう
それまでにIntel 128が必要ですね。
901デフォルトの名無しさん:2014/08/23(土) 14:34:08.88 ID:XHId/Nm0
AVX-1024・・・。
8bitデータだったら128並列・・・ハァハァ・・・。
902,,・´∀`・,,)っ-○○○:2014/08/23(土) 15:08:24.52 ID:aDxyXNe8
囲碁や将棋のAIが捗りそうだね
903デフォルトの名無しさん:2014/08/23(土) 20:44:39.18 ID:IjpJYp7Y
904デフォルトの名無しさん:2014/08/25(月) 00:35:27.81 ID:grVdsSDN
それよりOSが使わないアプリ専用のコアをつけてほしい
905デフォルトの名無しさん:2014/08/25(月) 18:22:20.48 ID:DrxGPTGS
OSってそんなにオーバーヘッドあるの?
906,,・´∀`・,,)っ-○○○:2014/08/25(月) 20:17:59.65 ID:OadJeN+C
OSが管理しなかったらどうやってアプリから使うの?
Cell-SPEみたいなのは御免だけどな。
cooperativeなマルチタスクは今日日はやらない。
907デフォルトの名無しさん:2014/08/25(月) 22:25:05.33 ID:ll9U2Mw1
タスクスイッチせずに占有させろってことかな?
908,,・´∀`・,,)っ-○○○:2014/08/26(火) 08:36:59.57 ID:alyrvqJW
カーネルモードで割り込み禁止にすりゃいいだけ
OSに管理させないとか仮想化の流れと逆行するからまず受け入れられない
自分が考え方を変えるほうが早い。

Linuxならオープンソースだからカスタムカーネル作れるんじゃね?
909デフォルトの名無しさん:2014/08/26(火) 11:57:01.53 ID:beppGarV
つーか、カーネルのAffinity設定して特定のcoreに拘束すればいいんじゃね?
910デフォルトの名無しさん:2014/08/27(水) 03:26:34.90 ID:6l9mfgq+
割り込みなかったらキーボード入力とかどうすんの
911デフォルトの名無しさん:2014/08/27(水) 04:19:52.65 ID:FbvwZ2Et
つ GPGPU
912デフォルトの名無しさん:2014/08/27(水) 19:23:26.39 ID:VCMYq2O7
Xeon Phiとかはこのスレ的にどうなの?
913デフォルトの名無しさん:2014/08/27(水) 21:32:33.93 ID:rbN3bC5Y
高嶺の花だなぁ・・・。
914デフォルトの名無しさん:2014/08/29(金) 17:49:28.50 ID:P44XFAJD
全部のプロセスのアフィニティ設定しなおすとかできんのかな?
特定のプロセスだけcore4とかに
915,,・´∀`・,,)っ-○○○
今のWindowsはGPUのコンテクストすらプリエンプションやってますが


>>914
権限のあるプロセスに対してはやれるといえばやれる