C、C++の最適化について語るスレ
レス数が1000を超えています。これ以上書き込みはできません。
0001デフォルトの名無しさん
NGNG主に速度面の最適化を中心としますが、サイズなどの最適化もどうぞ。
なお、OS、CPU、コンパイラなどは限定しません
0002デフォルトの名無しさん
NGNG0003デフォルトの名無しさん
NGNG0004デフォルトの名無しさん
NGNG最初の具体的な話題提起は無いの?
0005デフォルトの名無しさん
NGNGこんなとこでは一般的なことしか書かないよ。
0006デフォルトの名無しさん
NGNG0007デフォルトの名無しさん
NGNG0008デフォルトの名無しさん
NGNG0009デフォルトの名無しさん
NGNG0010デフォルトの名無しさん
NGNG0011デフォルトの名無しさん
NGNG圧縮ファイルを閲覧でき、さらにその中から任意の画像を１枚単位で
抽出できるビューアってありますか？
現在はビューアで圧縮ファイル内閲覧→欲しい画像名をメモ→WinRarで抽出…という手順なもので。
199名無しさん＠お腹いっぱい。[sage] 04/05/16 13:41 ID:O4RkkSrF
> ありますか？
あるよー。
ソフトの名称までは当然答える必要無いよね。
202新参者にマジレス[sage] 04/05/16 14:17 ID:O4RkkSrF
199の回答は意地悪く揚げ足を取ったのではなく、教えて厨を蔓延させない為に
テンプレに挙がってるソフトくらい試してから質問しろという趣旨のものですよ。
｢ありますか？｣と聞かれても、その答えがテンプレに載ってないものならソフト名でこたえますが、
｢既出上等、初心者歓迎、教えて君いらっしゃい｣なスレじゃなければ、
テンプレに挙がってるものくらいは、質問する前に試すのが当然です。
0012デフォルトの名無しさん
NGNG0013デフォルトの名無しさん
NGNG│ ヽ( ,_ﾉ`)ノ 残念、私のおいなりさんだ
│ へﾉ /
└→ ω ノ
>
0014デフォルトの名無しさん
NGNG袋はあるのに、何故棒が無いんだ？
0015デフォルトの名無しさん
NGNG存在はするけれども見えないんだよ。
つっこんだら可哀想じゃないか。
0016デフォルトの名無しさん
NGNG0017デフォルトの名無しさん
NGNG0018デフォルトの名無しさん
NGNGところでよ、インテルのコンパイラだが、今のバージョンには
次世代CPUプレスコットをサポートみたいに誇らしげに書いてあるけど、
今後はPentium Mベースだから、オプションの説明を見てると
涙を誘うぞ。
0019デフォルトの名無しさん
NGNG0020デフォルトの名無しさん
NGNGhttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vctchoptimizingyourcodewithvisualc.asp
Microsoft Visual C++ Floating-Point Optimization
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/floapoint.asp
Visual C++ Optimization Overview
http://msdn.microsoft.com/library/en-us/dv_vstechart/html/optimization.asp
Profile-Guided Optimization with Microsoft Visual C++ 2005
http://msdn.microsoft.com/library/en-us/dv_vstechart/html/profileguidedoptimization.asp
0021デフォルトの名無しさん
NGNGi686指定でオッケーなんだろうか
0022デフォルトの名無しさん
NGNG∩＿＿＿∩ . ∩＿＿＿∩ ∩＿＿＿∩
/ ヽ | . / ヽ | / ヽ
| ● ● ヽ . | ● ● ヽ | ● ● ヽ
ミ (_●_ ) | . ミ (_●_ ) | ミ (_●_ ) |
ヽ |∪| ミ ヽ |∪| ミ ヽ|∪| ミ
/ ヽノ ⌒ヽ / ヽノ ⌒ヽ / .ヽノ ⌒ヽ
l⌒Ｖ ヽ l⌒Ｖ ヽ l⌒Ｖ ヽ
ヽ､_,.'/ /> 〉 ヽ､_,.'/ /> 〉 ヽ､_,.'/ /> 〉
/ /(_ ／ ../ /(_ ／ / /(_ ／
/ /＼ ＼ / /＼ ＼ ./ /＼ ＼
(＿_／ （＿／ .(＿_／ （＿／ (＿_／ （＿／
0023デフォルトの名無しさん
NGNG皇太子の激怒している写真
0024デフォルトの名無しさん
NGNG皇太子殿は実がぎっしり詰まった方なのですね。
0025デフォルトの名無しさん
NGNG-fomit-frame-pointer -funroll-loops
0026デフォルトの名無しさん
NGNG0027デフォルトの名無しさん
NGNG-ga
0028デフォルトの名無しさん
NGNG-O99
0029デフォルトの名無しさん
NGNG0030デフォルトの名無しさん
NGNG0031デフォルトの名無しさん
NGNG0032デフォルトの名無しさん
NGNG0033デフォルトの名無しさん
NGNG0034デフォルトの名無しさん
NGNG0035デフォルトの名無しさん
NGNG↓ ↑
→→→→→→↑
0036デフォルトの名無しさん
NGNG0037デフォルトの名無しさん
NGNGこのスレはこういうのを語ればいいの？
0038デフォルトの名無しさん
NGNGといいたいが、スレの主旨はそっちであってる。
というかそのページの最適化房丸出し。
0039デフォルトの名無しさん
NGNG0040デフォルトの名無しさん
NGNGテストプログラムが単に代入だけのループを使っていると言うこと。
ループ中で除算を数回しただけで、速度の違いなどほとんど存在しなくなる。
どうも最適化云々という人間は、そういった部分を考証することに欠けている。
0041デフォルトの名無しさん
NGNGconst float dx = c[0] + c[1] * x + c[2] * powf( x, 2.0f) .... + c[8] * powf( x, 8.0f);
と、
const float c[] = {...};
float dx = 0.0f, xx = 1.0f;
for( uint i = 1; i <= 8; ++i, xx*=x) dx += (float)i * c[i] * xx;
ではコンパイラの最適化に違いは出るのかな？
0042デフォルトの名無しさん
NGNG0043デフォルトの名無しさん
NGNG0044デフォルトの名無しさん
NGNG0045デフォルトの名無しさん
NGNGまったくわからん。最適化どうこう以前にプログラム組めない悪寒・・・
0047デフォルトの名無しさん
NGNG日本語で頼む。
0048デフォルトの名無しさん
NGNGhttp://homepage1.nifty.com/herumi/
考察にいろいろ
アセンブラのサイトだけどところどころCのコードも見かける。
0049デフォルトの名無しさん
NGNG0050デフォルトの名無しさん
NGNG0051デフォルトの名無しさん
NGNG最適化手法の名前でググれ
0052デフォルトの名無しさん
NGNGやっぱり、ある程度は自分でやったほうがいいの？
0053デフォルトの名無しさん
NGNG45じゃないんだけどさ、最適化どうこう聞く以前の問題だよ。
>それでもFPUレジスタを使うことにかわりないし・・・
FPUレジスタを使うこと自体、最適化では極力控えるんだ。
そのくらいの知識はあってほしいものだね。
だから、変わりないなんていう前に極力FPUを使わないようなコードを取るか、
アセンブラで書くか、どちらかの手法をとらないと最適化の意味を
なさないんだよ。わかるかな？
たとえば、32bit長のfloatの絶対値を求める場合の
fabsの代用とか同符号の大小比較とか、
とにかくいろいろあるけれど、きみは最適化どうこうの前に
プログラムの勉強をしたほうがいいのではないかな？
0054デフォルトの名無しさん
NGNG0055デフォルトの名無しさん
NGNG0056デフォルトの名無しさん
NGNGPS2とかは
a+b
a-b
acc+=a*b
acc-=a*b
max(a,b)
min(a,b)
abs(a)
-a
が全部１クロック実行レイテンシ４クロックだったりするし、
これを整数レジスタでやったりすると掛け算辺りはえらい事になる。
0057デフォルトの名無しさん
NGNG0058デフォルトの名無しさん
NGNGでは、
boolを返すのとconst bool&を返すのはどっちが速いですか？
intやcharやdoubleではどうでしょう？
005958
NGNGローカル変数や即値ではありません。
(ローカル変数だったらconst bool&は返せないし、即値ならconst bool&よりboolの方が速いに決まってるから)
0060デフォルトの名無しさん
NGNGそれと、ＷｉｎＡＰＩとか使えるんでしょうか？
0061デフォルトの名無しさん
NGNGWin32APIはつかえるよ
0062デフォルトの名無しさん
NGNGあまり変わらないと思う。
ポインタ・参照を返す・渡す目安はsizeof (返す型) > sizeof (返す型 *)になったら。
006341
NGNGネタなのか何なのかよくわからんが
fabsとかはバリバリ使うよ。
0064デフォルトの名無しさん
NGNG0065デフォルトの名無しさん
NGNG0066デフォルトの名無しさん
NGNG0067デフォルトの名無しさん
NGNGﾌﾟｹﾞﾗ
0068デフォルトの名無しさん
NGNG0069デフォルトの名無しさん
NGNG確かスタック型とかいうアホな仕様だったような。
あれってやっぱ遅かったの？
0070デフォルトの名無しさん
NGNG0071デフォルトの名無しさん
NGNG秋葉原に行って大枚はたいて買ってきてわくわくしながらつけたけど
N88BASICのマンデルブロ集合の描画は1.5倍も速くならなかったよ...orz
0072デフォルトの名無しさん
NGNG0073デフォルトの名無しさん
NGNGFPUはメモリー空間やIO空間にくっついているディバイスじゃないよ、
CPU命令のセット拡張するんだよ。
だからドライバは有りません。
0074デフォルトの名無しさん
NGNGそうですか。cygwinでかじってみようと思います。ｶﾞﾘ う、
0075デフォルトの名無しさん
NGNGアホな仕様つうか当時流行りの、ってとこなんだが。
別にスタックマシンだから
遅くなくてはいけないという理由はない。
しかも過去形でもない。
でもx87はコンパイラ屋から冷遇されてるので遅い。
0076デフォルトの名無しさん
NGNG0077デフォルトの名無しさん
NGNG0078デフォルトの名無しさん
NGNG0079デフォルトの名無しさん
NGNG0080デフォルトの名無しさん
NGNG0081デフォルトの名無しさん
NGNG0082デフォルトの名無しさん
NGNGMMXとはまた違うんだよ
0083デフォルトの名無しさん
NGNGC++やCといったコンパイル対象言語がベクトルに対応していないのに
ベクトルや行列演算をコンパイラに任せることが出来るのか？
基本データ型にfloat4だのfloat4x4だの定義されたHLSLのような言語きぼんぬ。
0084デフォルトの名無しさん
NGNGそういうのはCPUの種類に依存するから言語仕様に盛り込むべきじゃないと思われ。
CPU製造メーカ謹製のライブラリを使えと。
0085デフォルトの名無しさん
NGNGSSEの用途はMMXと違ってSIMDだけじゃないんだよ。
0086デフォルトの名無しさん
NGNG逆に言うとSIMDもあるってこったな。
0087デフォルトの名無しさん
NGNG最高の最適化オプションてなんですか？
0088デフォルトの名無しさん
NGNG0089デフォルトの名無しさん
NGNG0090デフォルトの名無しさん
NGNG「高速化の技術にはMIMD、SIMD、(あと一つあったが忘れた）があるが、(忘れたやつ）が主流になり、限界が近いSIMDは使われなくなっていくだろう」
だってさ。世の中はどう動くか分からないねぇ
0091デフォルトの名無しさん
NGNG0092デフォルトの名無しさん
NGNG0093デフォルトの名無しさん
NGNG0094デフォルトの名無しさん
NGNGそういう情報を掴むデータが俺も欲しかったりする
0095デフォルトの名無しさん
NGNG0096デフォルトの名無しさん
NGNGGCCはもうICCより速くなってる
0097デフォルトの名無しさん
NGNGlameだけgccの方が速いのは元々のコードがgccで速くなるように書かれてるだけ。
0098デフォルトの名無しさん
NGNG0099デフォルトの名無しさん
NGNG0100デフォルトの名無しさん
NGNGMISD
0101デフォルトの名無しさん
NGNG0102デフォルトの名無しさん
NGNG0103デフォルトの名無しさん
NGNGconst int a = 5;
const struct b {
const int a;
} b = {
6
};
void f(void);
void f(void)
{
malloc(a);
malloc(b.a);
}
これをgcc -O3 -Sでコンパイルすると下のコードになるのですが、
malloc(b.a)のところも6をpushlするようなコードにするにはどう
すればいいでしょうか。
f:
pushl %ebp
movl %esp, %ebp
subl $20, %esp
pushl $5
call malloc
popl %eax
pushl b
call malloc
0104デフォルトの名無しさん
NGNG0106デフォルトの名無しさん
NGNG0107デフォルトの名無しさん
NGNGconst struct b {
enum { a = 6 };
};
0108デフォルトの名無しさん
NGNG0109デフォルトの名無しさん
NGNG0110デフォルトの名無しさん
NGNGlibm
0111キリ番ゲッター ◆Q5W244LhJU
NGNG0112デフォルトの名無しさん
NGNG最速にするオプションを教えてください。
0113デフォルトの名無しさん
NGNG0114デフォルトの名無しさん
NGNG-fichibantakaicpuwokattekuru
だよ
0115デフォルトの名無しさん
NGNG0117デフォルトの名無しさん
NGNGそれともSSEなどは自分でコードを書かないとダメなのでしょうか？
0118デフォルトの名無しさん
NGNGIntelのコンパイラなら使ってくれる。
0119デフォルトの名無しさん
NGNG0120デフォルトの名無しさん
NGNG0121デフォルトの名無しさん
NGNG0122デフォルトの名無しさん
NGNG起動時にCPU判別するコードが埋まるよ？
0123デフォルトの名無しさん
NGNGそれはいいけど、大きなEXEが出来るとしたら嫌だな。
0124デフォルトの名無しさん
NGNG0125デフォルトの名無しさん
NGNG実際にinline化されているかどうかを調べるにはどうしたらいいのでしょう？
0126デフォルトの名無しさん
NGNG逆アセが妥当だと思う。
0127デフォルトの名無しさん
NGNG0128125
NGNGDebugでアセンブリコード表示してみたんですが、
非inlineと__forceinline(M$の強制inline化)との違いは見られませんでした
Debug構成だとinlineすらされないのでしょうか？
で、Release構成にして調べようと思ったのですが…
アセンブラはマイコン(PIC)で触れた程度でほとんど知らないので何がなにやら…＾＾；
inline化されているかどうかの目印になるようなコードなどあれば教えてください
0129デフォルトの名無しさん
NGNG0130デフォルトの名無しさん
NGNG通常、Debugビルドでは一切のinline化を行なわない。
#デバッグに便利なように。
アセンブリコードで、ぶっちゃけcallが関数呼び出し。
但し、明示的な関数呼び出し以外にもcallが置かれることがあるので要注意。
0131デフォルトの名無しさん
NGNG0132デフォルトの名無しさん
NGNG無駄に大きくなってキャッシュの効率が下がる。
とりあえずつけない方がまだまし。
C++ならヘッダに書けるくらい短いコードをinlineにするのが吉。
0133r
NGNGまあ、いわゆる getter/setter とかだね。
0134デフォルトの名無しさん
NGNG0135デフォルトの名無しさん
NGNG0136デフォルトの名無しさん
NGNGあと、絶対に1度きりしか呼ばれない関数も。
1関数内の処理が長くなっちゃったから途中で別の関数に分けたとかそういうときに。
0137デフォルトの名無しさん
NGNG0138デフォルトの名無しさん
NGNGOTL
0139デフォルトの名無しさん
NGNG一時オブジェクトが必要な関数はインライン展開できなかったな。
いや、正確にはinline指定に対して警告が出たというべきか。
0140デフォルトの名無しさん
NGNGまとまった量のコードなら相対的に関数呼び出しのオーバーヘッドなんて無視できるだろうし。
0141デフォルトの名無しさん
NGNG変数の種類はどれを使っても最適化には関係ない？
コード的にはローカル変数を使いたいのですが、グローバル変数の方が高速なの？
0142デフォルトの名無しさん
NGNG0143デフォルトの名無しさん
NGNGローカル変数の方が良い。
最適化でレジスタに割り当ててくれる。
どうしてもグローバル・スタティック変数を使わなければならない時、関数内で何度もその変数を使う時は、
レジスタに入れられるような型なら一旦関数内でローカル変数にコピーして関数内ではそれを使い、
関数を抜けるときに元の変数に代入するようにすると、やはりローカル変数をレジスタに割り当てて高速化へ繋がる。
0144デフォルトの名無しさん
NGNG0145デフォルトの名無しさん
NGNG0146デフォルトの名無しさん
NGNG・スタックの先頭付近はキャッシュに乗っている可能性が高い、
というか乗りっぱなし
・エイリアスの可能性を考慮すると、グローバル変数/スタティック変数を
レジスタに入れっぱなしにするような最適化がしにくい
とはいえ差がでるようなことはほとんどないと思うがな。
0147デフォルトの名無しさん
NGNGスタックの先端ってプログラム終了の瞬間しか通らないmainの変数か速攻で消滅するちょい関数のどっちかだとおもわれ。どっちにしろ価値無くないですか？
0148デフォルトの名無しさん
NGNG0149デフォルトの名無しさん
NGNG0150デフォルトの名無しさん
NGNG>>148は>>147に対して。
0151デフォルトの名無しさん
NGNG0152デフォルトの名無しさん
NGNG0153デフォルトの名無しさん
NGNG0154デフォルトの名無しさん
NGNG0155デフォルトの名無しさん
NGNG0156デフォルトの名無しさん
NGNG0157デフォルトの名無しさん
NGNGエイリアスの可能性ってﾅﾆ？
漏れもわからん
ﾅﾆ？
0158デフォルトの名無しさん
NGNG要するにポインタ・参照のことだよ。
0159デフォルトの名無しさん
NGNG0160デフォルトの名無しさん
NGNG0161デフォルトの名無しさん
NGNG0162デフォルトの名無しさん
NGNGvoid func(int& x)
{
f_count++; // 関数が呼ばれた回数をカウントする
x = 0; // 入力引数を0クリアする
}
たとえば、かような関数があったとして
func(x);とかやって関数を呼ぶと、その回数が
f_countに記録されるわけだが
ここで、
func(f_count);
とやると、関数二行目のx = 0; のステートメントで
f_countの値は0になってしまう
こういう風に、グローバルと参照する入力引数がかぶることを
エイリアスというのではなかったか？
うろ覚え
0163デフォルトの名無しさん
NGNG> エイリアスとは、同じメモリ位置を複数の名前によって参照することを言います。
少なくとも160の脳内の話ではない。
このスレのレベルの低さが伺えるな・・・。
0164デフォルトの名無しさん
NGNG0165デフォルトの名無しさん
NGNG0166デフォルトの名無しさん
NGNG0167デフォルトの名無しさん
NGNGエイリアスになっていないことの証明に成功するとは限らない．
一切エイリアスなしのコンパイラオプション，もしくは const,
restrict キーワードをつければ，グローバル領域で実体を確保
しても問題ない．問題あるようなコンパイラは捨ててしまおう．
ローカル変数にする実行速度的長所はキャッシュにのる可能性が
大きいことだけで，短所は実体を複製（初期化）しなければならな
いこと．
結局，実行速度が重要な場所では，ローカルとグローバルの
2通りを実際に作ってターゲットの環境で実際に試すしかない
と思う．
0168デフォルトの名無しさん
NGNGおまい頭いいな
0169デフォルトの名無しさん
NGNG本当にそう思うか？register指定子はあくまでサジェスチョンに過ぎないし、
百歩譲って本当にレジスタがグローバル変数に割り当てられたとしたら、
プログラムの終了までそのレジスタは他の用途にずっと使えなくなる恐れ
もある。
賢いコンパイラなら関数の入り口でその都度レジスタにグローバル変数を
ロードしてくれるかもしれないが、CPUのアーキテクチャによってはx86の
ようにレジスタの極端に少ないものもあり、たかだか数個しか割り当てられ
ないし、それにしても関数内のローカル変数の扱いに障害を与えるだけだ。
0170デフォルトの名無しさん
NGNG0171デフォルトの名無しさん
NGNG悪かった。マジレスしてしまった。
0172デフォルトの名無しさん
NGNG0173デフォルトの名無しさん
NGNGC99の仕様にも盛り込まれてるんだがなー
ホントに知らんの？ネタかな？
0174デフォルトの名無しさん
NGNG0175デフォルトの名無しさん
NGNG商品として売られてる例があったら教えて欲しい。
0176デフォルトの名無しさん
NGNG0177デフォルトの名無しさん
NGNG0178デフォルトの名無しさん
NGNG0179デフォルトの名無しさん
NGNG0180デフォルトの名無しさん
NGNG0181デフォルトの名無しさん
NGNGconstは丁寧にコードを書けば compilerが checkしてくれたりして
使えそうなのはわかるんだが、restrictでもそういえるのかがわからん。
restrictを生かした memcpyの宣言は以下のようになる (NetBSDより引用):
void*memcpy __P((void * __restrict, const void * __restrict, size_t));
memcpyの二つの引数が restrictだってのは検査できないのでは?
以下の例とか..
void foo(char *bar) {
memcpy(bar, bar+16, 16);
}
0182デフォルトの名無しさん
NGNG最適化に役立てようという意図なのがrestrict・・・だと思ったけど。
0183デフォルトの名無しさん
NGNGその通り。restrictポインタでないと、ポインタの指す領域同士のコピーの
ループに、その都度ポインタからアドレスをロードしてしまうようなコードを
吐く所を、restrictポインタはアドレスをレジスタに代入しっぱなしのコードに
最適化しても良くなる。
volatileの事情とよく似て、ポインタ変数の領域を上書きしてしまって、レジスタ
の値と整合が取れなくなるのを防止するために最適化が抑制されてしまって
いたエイリアシングの問題を、restrictキーワードはパスしても構わない事を
コンパイラに伝える。
0184デフォルトの名無しさん
NGNG0185デフォルトの名無しさん
NGNG並列処理しやすいようにいくつかに分けて書く。
↓
for(i=0;i<100;i++)
a=A;
のようなものより
for(i=0;i<50;i++){
a=A;
b=B;
}
のような感じ
ループに依存しない部分はループの外に出す
など
0186184
NGNG0187デフォルトの名無しさん
NGNG素人にいい加減なことを言うのはやめて～。
回りまわってコンパイラに苦情がくる。
0188デフォルトの名無しさん
NGNG0189デフォルトの名無しさん
NGNGお前、素人だなw
0190デフォルトの名無しさん
NGNGちょっと違くない？ そもそも書いてることの意味がわからん．
「修正されたオブジェクトが，他のポインタ等で参照されていない
ことをコンパイラに伝える．」という意味ならば納得なんだけど...
どう意味だったの？ volatileと事情は似てないよ．むしろ，しいて
言うなら反対だよ．しかも，restrict ポインタのアドレスは今は関係
ないだろ．いや，ポインタのポインタが restrict だっていうのならば
そういう事もあるかもしれないが...
>>185
これもちがくない？ それはコンパイラがベクトル化可能かどうか認識する
のを助けるテクニックではないぜ．むしろ妨げてる気がする．いや，たしか
にそんな高速化のテクニックもあるけどさぁ．
0191デフォルトの名無しさん
NGNG前から全く内容が改変されてないし、間違いないんだろう。
http://seclan.dll.jp/c99d/c99d07.htm#dt19991018
0192デフォルトの名無しさん
NGNGvolatileとrestrictはどちらも、プログラム上に明示的に表れていない
意味情報をコンパイラに伝えるという点で事情が似ている、という
ことなのだろう。たぶん。
ところで、C99のrestrictは、参照しかされない場合は別名を持っても
いいんだっけ？ 昔調べたとき、美しくないなあ、と思った記憶がある。
0193デフォルトの名無しさん
NGNGパイプライン・ストールを減らすという効果が主に期待される。
VC6/7.1などでdouble型の配列にループを適用して最適化かけると
勝手にアンロールされる事がある。そして効果はかなり大きい。
0194デフォルトの名無しさん
NGNG余計な突っ込みを入れられそうなので一応追加。
0195デフォルトの名無しさん
NGNG人手でunroll化されたコードを巻き戻す機能があります。
0196デフォルトの名無しさん
NGNG0197デフォルトの名無しさん
NGNG0198デフォルトの名無しさん
NGNG有効な寿命の間に修正されなければ，別名を持っていても構わない
んじゃないかな．そもそも，配列やポインタを使っているにもかか
わらず，別名を持たないなんて事は在り得るのだろうか．a[i] とし
た時点で既に a[j] とか a[0] のエイリアスの可能性がある．
>>193
単純にジャンプ命令を減らす事以外にもアンロールの利点はあるっす．
out-of-order execution っすよ．185 の例だと，a=A を処理してる間
に b=B の処理をしはじめれるかもしれないっす．
0199デフォルトの名無しさん
NGNGアンロールはもうコンパイラに委ねる方が賢いやり方だとおもわれ。
で、コンパイラが巧くやってくれなかったら、コンパイラベンダーに
文句を言うのです。
そうも言ってられないこともあるだろうけどね。
0200デフォルトの名無しさん
NGNG基本的には賛成なのだ．でもそうも言っていられない． :)
sum1=sum2=0.0;
for (i=0;i<N;i+=2) {
sum1+=a[i]; sum2+=a[i+1]; }
sum=sum1+sum2;
なんてのが有名な例だとおもう．浮動小数点演算順序の自動変更
は一切コンパイラにやってもらいたくないっすよ．
0201デフォルトの名無しさん
NGNGを読め。Cでの最適化の仕方についてくわしく書かれている。athlonの場合を
想定して書いてあるが、x86全般に共通する説明が多い。
http://www.amd.com/jp-ja/Processors/TechnicalResources/0,,30_182_739_3748,00.html
0202デフォルトの名無しさん
NGNGmemcpy(bar, bar+16, 16);
これは重なってないからいいのでは?
0203デフォルトの名無しさん
NGNGa[j]やa[0]が出てこなければ別名ないだろ。
{ int a[N]; for(i=0;i<N;i++) a[i]=0; }
これなら別名はない。インデックス解析で分かる。
0204デフォルトの名無しさん
NGNGすまん，書き方が悪かった．「配列やポインタを使って何か意味のある事を
しようとしているにもかかわらず，」と読んでくれ．
今考え直してみたけど，要素数1の時とかは別名参照の可能性が一切ない
ように書けそうだ．void foo( hoge_t * restrict p ); なんて感じ
で関数 foo を宣言し，hoge_t hoge; ... foo(&hoge); なんてする事は
結構あると思う．で，関数 foo 内では *p 以外の名前はない．
いや，そもそもどうでもいい事だな．
0205デフォルトの名無しさん
NGNGint a[10];
int f(restrict int *p)
{
return *p + a[2];
}
int g(void)
{
f(&a[2]);
}
0206デフォルトの名無しさん
NGNG満たしてないのだ．restrict キーワードはポインタの値そのものを修飾でき
ないっす．
たとえ int f(int * restrict p ) としても *p と a[2] は実際にエイリ
アスの関係にあるから，厳密には許されていない気がする．ISO のドラフ
トしか読んでないから嘘を言ってるかもしれないけど．
でも，この例の場合，pに別名なしの仮定をしたことによって引き起こされる，
プログラムが正常に動かなくなるような最適化はありえないと思うな．きっと
コンパイラエラーもなければ実行も正常に行われるよ．
そもそも，この例の場合，restrict を使う意味がまったくないし．やっぱ，
restrict ポインタの指す値が左辺値にこないとねぇ．
0207デフォルトの名無しさん
NGNGrestrictの位置の間違いを直せば、それは言語仕様を満たしている。
>>192も言っているが、嫌な仕様だ。
0208デフォルトの名無しさん
NGNG単なるしったかクンだよね？
0209デフォルトの名無しさん
NGNGそういうお前はうまく説明できるのか？知ったか君。
0210デフォルトの名無しさん
NGNG0211デフォルトの名無しさん
NGNG0212デフォルトの名無しさん
NGNGint func(int& a, int& b)
{
a = 1;
b = 2;
return a + b;
}
この関数は一見すると、常に3を返すように見えるが
func(x, x)のようにエイリアスしていると
x = 1;
x = 2;
return x + x;
という内容を実行するので、その場合のみは4を返すことになる
しかし、エイリアスを考慮せずにa, bを
それぞれ別のレジスタに割り当てて計算する最適化をしたら
常に3を返すことになりかねない
エイリアスの可能性を最適化コンパイラは
考慮しないとだめなのは、そういったことが理由
0213デフォルトの名無しさん
NGNG「その関数内では」エイリアスが無い
という事の表明でいいんですよね？
0214デフォルトの名無しさん
NGNG0215デフォルトの名無しさん
NGNG修正されない場合は言語仕様を満たしているの？ そんな事をいってる文章
を読んだことがないんだ．いや，煽っているわけではないんだ．本当に教え
てもらいたいんだ．できれば web 上で公開されているタダで読めるものがあ
りがたいっす．
Aliasing of unmodified objects の場合でも，そのオブジェクト自身が
ポインタ，もしくは配列等の index として使われて，そいつがポイント
するオブジェクトが修正された場合に問題が生じるから，restrict-qualifier
の使用は残念ながら許されないと
Numerical C Extensions Group, Aliasing Subcommittee
Final Report: Draft 2, X3J11/94-019, WG14/N334
に書いてあったのだ．これを読んだときはそのとーりだと思った．いや，
google で検索しておもむろにクリックして見つけたのを読んだだけで，
この文章が本物で，公の何らかの効力があるのか分からないんだけど...
ぼくは，「エイリアスしていても，プログラマが問題が生じないと判断した
ならば restrict を使用しても構わない」ぐらいに思っていたし，そうあって
もらいたいと願ってもいる．美しさよりも，タイトなループの最適化の方が
重要っす．汚くても速度的に重要でない所では使はないから構わないのだ．
さらに，そもそも「言語仕様を満たす」とはどういう意味なのか分からん．
たとえば，定数 0 で除算した場合，それは言語仕様を満たしているん
だろうか．ちなみに，C の文法は満たされていると思う．演算子 / の
後に定数がくることは許されていて，「定数はゼロではいけない」とい
う文法上の決まりごとはないはずだ．いや，最適化とは関係ないかもし
れないけどさ．長文ですまん．
0216215
NGNGあ，ちなみに
>>213
restrict-qualifier を指定された変数のスコープがその関数内ならば
そのとうり．
0217デフォルトの名無しさん
NGNGhttp://www.jisc.go.jp/app/pager?id=293
79ページにポインタ型以外をrestrict修飾してはならないと書いてある。
0218215
NGNGそれは僕の質問に対しての答えじゃないのだ．でも，返事ありがと．
restrict 修飾されたポインタが指すオブジェクトが修正されていな
いがエイリアスされている場合は許されるのかって事だったのだ．
>>205 の例の restrict の位置を直したものがまさにそうなっている
のだ．ちなみに，僕はそのページを見れないっす．
0219デフォルトの名無しさん
NGNG規格を読めよ。基本的な知識の無い人間が「～なはずだ」なんて良く言えるな。
jisc行ってデータベースからX3010を検索。
0220デフォルトの名無しさん
NGNGJISかよw原文読め
0221デフォルトの名無しさん
NGNG原文ってANSI? ISO(とその翻訳であるJIS)って何かまずいの？
あと、それがタダでみられる所を教えてくれ。
0222デフォルトの名無しさん
NGNGhttp://pc5.2ch.net/test/read.cgi/tech/1101473340/4
のPDF。ただし違法。
0223デフォルトの名無しさん
NGNGそれはC++であってC(99)じゃないと思うが。
0224デフォルトの名無しさん
NGNGttp://www.google.co.jp/search?q=9899+ISO+filetype%3Apdf&hl=ja&ie=UTF-8&oe=UTF-8&c2coff=1
ただし違法。
0225215
NGNGありがとーーー この web page は読めた！
この文章では、どのような状況でプログラムの振る舞いが undefined になるかの
説明があるだけで「restrict ポインタが指すオブジェクトが修正されない場合は
エイリアスを許す」とは書いていないのだ。まぁ、それはそうだ。たとえ修正され
なくても振る舞いがおかしくなる状況はあるからね。
ちなみに、この文章の 6.3.7.1 の 10 に、修正されない別名を持つオブジェクト
のポインタに restrict-qualifier をつけた場合で振る舞いが defined になる
例が紹介されているね。
結局、「動く」とプログラマが判断した場合に restrict を使えと言っている
ように、僕は思えた。
>>219
この文章では / 演算子の 2 つめのオペランドの値が 0 の場合、振る舞いは
undefined だとかいてある。で、結局定数 0 で割る c99 プログラムは言語
仕様を満たしているといえるのかな？ 言えないのかな？
「言語仕様を満たす」という言葉の意味がわからん。
0226デフォルトの名無しさん
NGNG0227デフォルトの名無しさん
NGNG0228デフォルトの名無しさん
NGNGhttp://www.jisc.go.jp/app/pager?%23jps.JPSH0020D:JPSO0010:/JPS/JPSO0020.jsp=
規格番号X3010でC99、X3014だとC++の日本語の規格書が手に入る。
0229デフォルトの名無しさん
NGNGwww.jisc.go.jp から行け。ただし、規格書を「見る」だけな。
本物は大きな本屋で売ってる。
0230デフォルトの名無しさん
NGNG0231デフォルトの名無しさん
NGNGDLすんのできなくね？
0232デフォルトの名無しさん
NGNGC++相談室 part38
ttp://pc5.2ch.net/test/read.cgi/tech/1101473340/258-259
あと、↑のスレの303辺りから。
0233デフォルトの名無しさん
NGNG>>229読め
0234デフォルトの名無しさん
NGNG0235デフォルトの名無しさん
NGNG0236デフォルトの名無しさん
NGNGすみません、あなたのレス、リンクが付いてないので読みにくいです。
0237デフォルトの名無しさん
NGNG文句があるならば、2chブラウザを使えば?
0238デフォルトの名無しさん
NGNGこのSTLをお前のコンパイラに取り付けろ。すごいぞぉ。プログラムの作成効率は100倍に跳ね上がる。
もってけ。そしてすぐに取り付けて試すんだ。
0239デフォルトの名無しさん
NGNG0240デフォルトの名無しさん
NGNG文字列関係のコーディングが信じられないくらい楽になるぞ
0241デフォルトの名無しさん
NGNG日本語処理ができるわけでもないし
0242デフォルトの名無しさん
NGNGそのくっ付けたり切り離したりが楽になるだけで十分楽できる。
0243デフォルトの名無しさん
NGNG0244デフォルトの名無しさん
NGNGその証拠にstd::wstringがtypedefされているわけだが。
0245デフォルトの名無しさん
05/02/03 05:05:170246デフォルトの名無しさん
05/02/03 05:52:240247デフォルトの名無しさん
05/02/03 06:17:460248デフォルトの名無しさん
05/02/03 16:06:58環境によるだろ。
俺はBorland-C++5.6.2に -D_RTLDLL オプションを指定して、極力
ランタイムを使用するようにして使っているが、例えばstd::vectorを
使っても使わない時と比べ10Kほどしか増えない。
0249デフォルトの名無しさん
05/02/03 21:03:19馬鹿？
0250デフォルトの名無しさん
05/02/03 22:48:52すげえ。ダイナミックリンクしといてファイルサイズが増えないとかいってるよ。この人。
0251デフォルトの名無しさん
05/02/04 04:59:400252デフォルトの名無しさん
05/02/04 09:27:040253デフォルトの名無しさん
05/02/04 20:50:53この流れ、何ヶ月か前にも見たような…
0254デフォルトの名無しさん
05/02/04 20:59:250255デフォルトの名無しさん
05/02/04 23:27:13C++ ( コンパイラ VCTK2003 /Ox )
aaa[pos+X1]++; // posは基準位置として
bbb[pos+X1]^=z; // 相対位置X1,X2,...,Xnの値を操作
aaa[pos+X2]++; // X1,X2,...,Xnは定数
bbb[pos+X2]^=z;
以下数回繰り返し、という場合に、
１．X1,X2,...,Xnを自分で即値を書き込む。
２．X1,X2,...,Xnを配列に収めて、for文等でコンパイラの最適化に頼る。
が考えられるのですが、
出力される.asmファイルを見ると、
１より２のほうが、より最適化されているのですが、
もともとグローバルで扱いたいX1,X2,...,Xnの配列を
対象ファイルの外に置いたとたん
２では即値展開されなくなってしまいます(都度メモリ読み込みしている)。
自分が即値で書き込むよりも、
コンパイラの最適化に頼ったほうがいい状況なので、
対象ファイル外にあっても即値展開して欲しいのですが、
いい方法はないでしょうか？
（開き直って全ファイルに、staticとして配置するのも手なんですが...）
0256デフォルトの名無しさん
05/02/04 23:40:02コンパイル時に即値で書ける訳ないだろ
そもそも、即値だと本当に速いんか？
0257デフォルトの名無しさん
05/02/05 00:17:03コンパイラに /GL
で、
リンカに /LTCG
0258デフォルトの名無しさん
05/02/05 00:24:19>>1を読んで他所でやってくれ。
0259255
05/02/05 01:51:49＞リンク云々...
そう言われるとそうですね。
＞そもそも、即値だと本当に速いんか？
環境によりけりとは思いますが、
自分の環境では速かったです。
>>257
ありがとうございます。
>>258
すいません。これで失礼します。
0260デフォルトの名無しさん
05/02/05 05:42:01(´,_ゝ｀)プッ
0261デフォルトの名無しさん
05/02/05 08:28:58;｀;:ﾞ;｀(;ﾟ;ж;ﾟ; )ﾌﾞｯ
0262デフォルトの名無しさん
05/02/05 20:27:52マジレス来たーｗ
0263デフォルトの名無しさん
05/02/06 02:02:330264デフォルトの名無しさん
05/02/06 05:09:02>>263
歴代のC++本スレの最初をどれでもいいから読んでこい
0265デフォルトの名無しさん
05/02/24 07:35:560266デフォルトの名無しさん
05/02/24 13:46:540267デフォルトの名無しさん
05/02/24 17:37:520268デフォルトの名無しさん
05/02/24 18:15:02キャッシュといえばプリフェッチやストリーム。
0269デフォルトの名無しさん
05/02/24 22:34:110270デフォルトの名無しさん
05/02/24 23:23:040271デフォルトの名無しさん
05/02/25 08:06:560272デフォルトの名無しさん
05/02/25 16:54:56キャッシュ容量をあまり消費しないプログラムの事です
0273デフォルトの名無しさん
05/02/25 16:55:53妙な副作用を起こさせるための期待はするべきではない
0274デフォルトの名無しさん
05/02/25 17:00:43データをただ垂れ流すだけになる。
そのようなストリームデータはキャッシュに対してプリフェッチを
行うこと。
0275デフォルトの名無しさん
05/02/25 23:52:12アドレス下位ビットが同じメモリだけを使うと、キャッシュ効率が上がるぞ！
0276デフォルトの名無しさん
05/02/26 02:46:35この弾の処理をキャッシュを考慮したら速く出来ますか？
0277デフォルトの名無しさん
05/02/27 13:29:140278デフォルトの名無しさん
05/03/09 17:17:27500発って弾幕薄くないか？
0279デフォルトの名無しさん
05/03/09 18:17:210280デフォルトの名無しさん
05/03/09 18:29:000281デフォルトの名無しさん
05/03/10 02:16:42じゃあ弾の数はこんぐらいで。
こーゆーのはキャッシュ利きそうにないね。
0282デフォルトの名無しさん
05/03/10 05:45:10なんで板が分かれてるか知ってるか？
http://pc5.2ch.net/gamedev/
0283デフォルトの名無しさん
05/03/10 05:54:18総合的なゲームに関して話す場が当時なかったためそれぞれ分散してた上に
どこもゲームが絡むと敬遠される傾向にあったから
0284デフォルトの名無しさん
05/03/10 05:54:480285デフォルトの名無しさん
05/03/10 08:36:080286デフォルトの名無しさん
05/03/14 03:07:050287デフォルトの名無しさん
2005/03/31(木) 11:45:590288デフォルトの名無しさん
2005/04/29(金) 15:09:05コンパイラが生成しやすいようにするには、どのようなコードを書くのがよいのですか？
0289デフォルトの名無しさん
2005/04/29(金) 15:14:540290デフォルトの名無しさん
2005/04/29(金) 15:35:49ループに依存しない部分はループの外に出すようにしておく
ループのカウンターのようなものはintじゃなくてunsigned intを使う
構造体は16バイト境界に合わせる
構造体のメンバはサイズがでかい物から配置する
割り算より掛け算を使用する
関数に引数を渡す時は、関数の中でその引数用の一時変数を使うようにする
ポインタはなるべく使わず、配列を使用する
0291デフォルトの名無しさん
2005/04/29(金) 15:50:22unsignedの方が演算が高速と言うことでしょか？
0292デフォルトの名無しさん
2005/04/29(金) 16:10:18あるから読め。Athlon向けだけど、内容はほとんど、一般的なx86
プロセッサ向けだから問題は無かろう。具体例を出して説明しているので
分かりやすいと思う。
ttp://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_739_3748,00.html
それと、インテルのコンパイラのマニュアルにも最適化しやすい
コードの書き方が出ている。xlsoftから日本語版のマニュアルだけ
落とせたような気がした。
0293デフォルトの名無しさん
2005/04/29(金) 17:23:320294デフォルトの名無しさん
2005/04/29(金) 18:25:430295デフォルトの名無しさん
2005/04/29(金) 20:58:44unsignedが32ビットで、size_tが64ビットの環境もあるので要注意。
0296デフォルトの名無しさん
2005/04/30(土) 08:56:54もちろんわかっている。
0297デフォルトの名無しさん
2005/04/30(土) 18:20:430298デフォルトの名無しさん
2005/04/30(土) 19:29:01それ以外なら、unsigend だな
0299デフォルトの名無しさん
2005/04/30(土) 19:33:39そうか、unsigendという型があるのか。知らなかった。
0300デフォルトの名無しさん
2005/04/30(土) 20:05:080301デフォルトの名無しさん
2005/04/30(土) 20:49:18> >>298
> そうか、unsigendという型があるのか。知らなかった。
0302デフォルトの名無しさん
2005/04/30(土) 21:13:06俺はいつもtypedefしてるよ
コレでtaipoも怖くない
0303デフォルトの名無しさん
2005/04/30(土) 21:33:440304デフォルトの名無しさん
2005/04/30(土) 21:45:00#define するのがプロ
0305デフォルトの名無しさん
2005/04/30(土) 23:19:48たいぼを防ぐのが本当のブ□
0306デフォルトの名無しさん
2005/05/01(日) 03:06:22即座に修正できるかも知れねぇが。
0307デフォルトの名無しさん
2005/05/01(日) 10:40:29予約語のtypoが0になりました。
0308デフォルトの名無しさん
2005/05/01(日) 13:16:230309デフォルトの名無しさん
2005/05/01(日) 13:24:590310デフォルトの名無しさん
2005/05/07(土) 08:09:400311デフォルトの名無しさん
2005/05/07(土) 10:30:08インテルのサイトのデベロッパページを探ればある。
0312デフォルトの名無しさん
2005/05/14(土) 06:26:56bool IsX;
があるとして、
if(IsX)
と
if(!IsX)
では速度的に同じになるのでしょうか？それとも!IsXの方が余計な計算コストがかかるのでしょうか
0313デフォルトの名無しさん
2005/05/14(土) 08:44:30IsXへの値の設定から条件分岐後の処理まで提示しないと一概には言えない。
#勿論、コンパイル環境の違いもある。
0314デフォルトの名無しさん
2005/05/14(土) 09:55:530315デフォルトの名無しさん
2005/05/14(土) 13:30:230316デフォルトの名無しさん
2005/05/15(日) 06:21:030317デフォルトの名無しさん
2005/05/15(日) 06:27:200318デフォルトの名無しさん
2005/05/15(日) 14:54:320319デフォルトの名無しさん
2005/05/23(月) 08:03:340320デフォルトの名無しさん
2005/05/23(月) 12:45:18気にするなﾏｼﾞﾚｽ
0321デフォルトの名無しさん
2005/05/23(月) 15:38:19iccなら最適化でやってくれる
0322デフォルトの名無しさん
2005/05/23(月) 17:15:190323デフォルトの名無しさん
2005/05/23(月) 18:27:12{
確立が高いほう
}
else
{
低いほう
]
でFA？
0324デフォルトの名無しさん
2005/05/23(月) 19:44:49jump if equal ラベル1
ほげ
ふが
jump ラベル2
ラベル1:
はげ
ひげ
ラベル2:
合流
...この場合、たぶん
はげとひげのコンビに逝ったほうが
無条件分岐がないので、
はやい?
0325デフォルトの名無しさん
2005/05/24(火) 15:59:00合流せずにretするパターンだと明らかにほけふがの方が
パイプラインを壊さない分速いな。
0326デフォルトの名無しさん
2005/05/24(火) 21:32:570327デフォルトの名無しさん
2005/05/25(水) 23:52:160328デフォルトの名無しさん
2005/05/26(木) 09:23:28同様にはげひげがキャッシュに載っていない可能性もある。
ほげふがの手前まで実行することが分かってるので、
どっちかというとはげひげがキャッシュから落ちていて
ほげふががキャッシュに載っている確率のほうが高い。
0329デフォルトの名無しさん
2005/05/26(木) 21:33:00「場合による」が正解だ。
0330デフォルトの名無しさん
2005/05/28(土) 12:12:13１回しか実行しないなら実行速度を気にする必要なし。
無条件ジャンプがある方が1clk程度遅い。CPUによるけど。
ジャンプがある方が速いなんてケースはほとんどない。
あったとしても、329がそこまで理解しているとは思えない。
0331デフォルトの名無しさん
2005/05/28(土) 14:04:131クロックなんて具体的な数値がどっから出てくるんだ？
0332デフォルトの名無しさん
2005/05/29(日) 11:29:41それじゃ質問への答えとしては生産性がないと思うんだ。
ジャンプした方が速い例を１つ挙げてみてよ。
0333デフォルトの名無しさん
2005/05/29(日) 12:32:270334デフォルトの名無しさん
2005/05/29(日) 18:36:07仮にジャンプした方だけキャッシュにのってて速くても、
ほげふがとはげひげを逆に書いたらキャッシュへの乗り方も逆になって
逆にする意味がなくなる。
0335デフォルトの名無しさん
2005/05/29(日) 18:56:28>>324からそれをどう読み取ったんだ？
結局なにか別の条件を付けないと分からないって事だろ。
無条件ジャンプのレイテンシなど0にできる。
無条件ジャンプの前に検討すべき事はいくつもある。
0336デフォルトの名無しさん
2005/05/29(日) 19:32:50お互い、相手にケチつけるのが目的で、
324氏にとって役に立つ議論ではなくなっている。
＃このままいつまでも続きそうで、それはそれで面白いがｗ
0337デフォルトの名無しさん
2005/05/29(日) 20:09:260338デフォルトの名無しさん
2005/05/29(日) 20:41:13じゃあ、
call func1
...
call funcn
compare b,0
jump if equal ラベル1
ほげ
ふが
となってて、func*がほげふがと同じキャッシュラインを使う無茶苦茶
レアなケースを考えよう。
同じラインに載らないように最適化するリンカってあるのかなあ？
ダイレクトマップのプロセッサでひどい目に合った事がある。
0339デフォルトの名無しさん
2005/05/29(日) 20:57:46dcache用にはコンパイラがpaddingを入れたりするが。
0340デフォルトの名無しさん
2005/05/31(火) 11:38:41>>318とかもそうだが、正しいけど答えになってない。
明らかに速いと言ってる奴の方がずいぶんましだと思った。
それが気に入らなかったから、>>330でトゲのあるレスをしてしまった。
>>335
繰り返しでないなら、ますますジャンプのコストを気にする必要がない。
他に検討すべき事があるのは同意。
で、大事なことを忘れていた。
jump if equal で、前方分岐の静的分岐予測は分岐しないと予測するのが普通。
つまり初回の実行は、ふげほが の方がずっと速いことになる。
PentiumMでだけど、アセンブラで実験してみた。
静的予測は、初めの４回はジャンプしないと予測するようだ。
はげひげ だけ実行すると最終的には合計50clk程度の不利となり、
100回以下のループなら、ふげほが が速い。
繰り返し回数を十分大きくとると、はげひげ の方が平均0.5clkほど速かった。
命令数が１つ少ないのが出ている。
処理内容によっては、まれに逆転することもある。
というわけで、かなり場合による。
他のCPU、特にPC用x86以外だと更に違うと思われる。
まあ、どちらが速いかで困ったら、２つ作って自分で比較しろということだ。
0341デフォルトの名無しさん
2005/05/31(火) 12:46:020343デフォルトの名無しさん
2005/05/31(火) 14:13:510344デフォルトの名無しさん
2005/05/31(火) 14:18:06「場合による」って答え方が嫌いなだけだよ。
0345デフォルトの名無しさん
2005/05/31(火) 14:32:23一言「場合による」と答えれば、初心者なら「気にすることない」と知ることができ
もう少し経験値があれば自分で調べようと思うこともできる。
>340のようにくどくど書くと、初心者には「なんだかよくわからない」という印象しか残らない。
場合によっては、「場合による」という回答の方が適当であることも知ったほうがいい。
0346デフォルトの名無しさん
2005/05/31(火) 16:21:35これまた当たり前かつ普遍の結論ですね。
0347デフォルトの名無しさん
2005/05/31(火) 16:38:11「場合による」と「気にすることない」は違うと思うが。
俺は「気になる初心者」だったのでそう思うのかな。
まあ、助言サンクス。気をつけます。
0348デフォルトの名無しさん
2005/05/31(火) 18:57:01中級者以上が専門のスレッドで議論する時には、「場合による」という一般論的回答でなく
「こういう条件では～、こういう条件では～」という対象の構造に踏み込んだ回答が望ましい。
>329のようにただ「場合による」と書くと、「そんなのは当たり前だ」という印象しか残らない。
このような場合には、「場合による」という回答が不適切であることも知ったほうがいい。
0349デフォルトの名無しさん
2005/05/31(火) 22:54:58嘘よりまし。
逆に明らかに速い時に「場合による」といったら嘘になる。
従って、「場合による」という回答は当り前ではなく意味がある。
0350デフォルトの名無しさん
2005/05/31(火) 23:20:04「場合による」よりましかどうかは場合による．
まあそんな順序付けをするより>>348のように書く方が建設的だな．
0351デフォルトの名無しさん
2005/05/31(火) 23:59:13出てるんだよな。
まずいのは、新たな条件の場合の話を始めた>>330が、そのように
読み取れないことだな。次の段落で>>326向けみたいな話をしてるし。
0352デフォルトの名無しさん
2005/06/01(水) 01:40:260353デフォルトの名無しさん
2005/06/01(水) 01:48:230354デフォルトの名無しさん
2005/06/01(水) 06:59:020355デフォルトの名無しさん
2005/06/01(水) 10:17:41俺もバシッとこういうこと言えたらヨカタ。。orz
>>351
326はあげあしとりだろう。命令キャッシュまで考えるケースじゃないよ。
すまん、煽りなら無視できるんだが・・・。
0356デフォルトの名無しさん
2005/06/01(水) 12:08:130357デフォルトの名無しさん
2005/06/01(水) 12:12:22ファビョってないでどっか逝けよ。もしかして在日チョンか？
0358デフォルトの名無しさん
2005/06/25(土) 12:01:450359デフォルトの名無しさん
2005/06/25(土) 13:21:45初期条件をより明確にしないと意味無し
0360デフォルトの名無しさん
2005/07/10(日) 07:04:13これはコントロールできないのでしょうか？OS側の問題でしょうか？
0361デフォルトの名無しさん
2005/07/10(日) 07:06:300362デフォルトの名無しさん
2005/07/10(日) 07:25:30OSによる
>>361
場合による
0363デフォルトの名無しさん
2005/07/10(日) 09:54:02それはこのスレの趣旨から外れる。
>>361
inlineを指定したからといって、必ずしもインライン展開されるわけではない。
その関数内で複雑な処理をしたり多数のローカル変数を使うとコンパイラが音を上げやすくなる。
また、インライン展開による速度向上よりも、もっと効果がある最適化もある。
0364デフォルトの名無しさん
2005/07/10(日) 10:53:29そんな複雑な処理をする場合まで考えるケースじゃないよ。
0365デフォルトの名無しさん
2005/07/10(日) 11:15:47そんなケースではないとどこに?
0366デフォルトの名無しさん
2005/07/10(日) 19:13:15頻繁に呼ばれる短い関数だったら速くなる。
複雑な関数だと大して速くならないか、かえって遅くなる。
0367デフォルトの名無しさん
2005/07/10(日) 20:02:35寡聞にしてそのような例を知らないのだが、具体例を挙げてもらえまいか。
0368デフォルトの名無しさん
2005/07/10(日) 20:14:590369デフォルトの名無しさん
2005/07/11(月) 11:58:540370デフォルトの名無しさん
2005/07/11(月) 12:00:21無視されたからってファビョるなよｗ
0371デフォルトの名無しさん
2005/07/11(月) 12:18:34意味判らん。精薄？
0372デフォルトの名無しさん
2005/07/11(月) 13:29:250373デフォルトの名無しさん
2005/07/11(月) 13:47:02一般論としては>>366だと思ったのだが、違う？
確かに実験もせずに悪かった。確かめるから少し待ってくれ。
0374デフォルトの名無しさん
2005/07/11(月) 14:45:55一般的に、遅くなるほど複雑な関数はインライン化されない。
コンパイラはその程度には賢い。
0375373
2005/07/12(火) 14:21:55逆にちょっと複雑にするとinlineにしてくれなくなるが、
これもPeniumMのスタックエンジンのおかげか、
呼び出しオーバーヘッドがほとんどない。
つーわけで、最近のCPUとコンパイラならどっちでもいいと思った。
0376デフォルトの名無しさん
2005/07/15(金) 17:02:37アフォか
0377デフォルトの名無しさん
2005/07/22(金) 07:25:29ただ、クリティカルな部分ではコンパイラが信用できないのでマクロにしてしまう人も多いと思う。
例えばGCC4とかはバグがあってやばい感じだ。
0378デフォルトの名無しさん
2005/07/23(土) 02:14:24だからinlineは強制ではなく、あくまでもコンパイラに対する示唆に過ぎないと何度（ｒｙ
0379デフォルトの名無しさん
2005/07/23(土) 02:49:010380デフォルトの名無しさん
2005/07/23(土) 21:41:08コンパイラ依存だが。
0381デフォルトの名無しさん
2005/08/22(月) 04:20:460382デフォルトの名無しさん
2005/08/22(月) 08:00:130383デフォルトの名無しさん
2005/08/22(月) 08:24:59・inline指定する
・ローカル変数を減らす
・一時オブジェクトも減らす
・複雑な条件分岐を減らす
0384デフォルトの名無しさん
2005/08/22(月) 19:08:08関数を関数引数に入れて呼び出したりとかはうまくすると展開される。
Lispでは常識の最適化だけど。
0385デフォルトの名無しさん
2005/08/22(月) 20:44:49・プログラムを1ファイル化する
0386デフォルトの名無しさん
2005/09/08(木) 17:39:20if (i = 0; i < n; i++) …
i も n も整数型の変数だとすると、n > 0 であることが保証されていれば、
マシン語コードにおいて最初の継続条件 (i < n) のチェックは不要になりますよね。
そこで __assume(n > 0) を入れて最適化のためのヒントを与えてみたのですが、
コンパイルされたコードを確認しても、最初の継続条件のチェックは消えていません。
どこか使い方が間違っているのでしょうか。それとも、他に何か条件がありますか？
この場合は、どうしても嫌なら do ～ while を使えばいいだけなんですが、
__assume() が使えるといろいろ応用が効きそうなので…よろしくお願いします。
0387デフォルトの名無しさん
2005/09/08(木) 18:02:310388デフォルトの名無しさん
2005/09/08(木) 18:04:07絶対にそこに展開したいんなら#defineが確実
0389デフォルトの名無しさん
2005/09/08(木) 18:22:47よく解らんが、__assume(i >= 0) も入れてみたらどうなる？
0390デフォルトの名無しさん
2005/09/08(木) 19:18:440391デフォルトの名無しさん
2005/09/08(木) 19:33:25#つーか、defined(NDEBUG)か。
0392デフォルトの名無しさん
2005/09/08(木) 20:00:22__assume(i >= 0) も入れてみましたが、変化はありませんでした。
一応、最適化オプションもいろいろ変えて試しているのですが、
いずれも最初に余計な比較とジャンプのコードが挿入されてしまいます。
手軽に実験するなら…何でもいいんですけど、例えばこんなコードです。
int n = GetSystemMetrics(SM_CMONITORS);
__assume(n > 0);
for (int i = 0; i < n; i++) MessageBox(NULL, NULL, NULL, 0);
>>390
説明を読むと、やや高度な指定もできそうな感じがするのですが、
現段階では 0 を指定するくらいしか使い道がないのかもしれませんね。
>>391
それはひょっとして assert() とか _ASSERT() の話だったりしませんか？
0393デフォルトの名無しさん
2005/09/09(金) 11:38:42{ assert(n > 0); int i = 0; do { ... } while (++i < n); }
にしる
0394デフォルトの名無しさん
2005/09/09(金) 18:44:56それこそ無意味
0395デフォルトの名無しさん
2005/09/09(金) 19:31:25つーかお前の存在自体無意味
0396デフォルトの名無しさん
2005/09/09(金) 19:42:14お前がこの世に存在する意味あるの？
0397デフォルトの名無しさん
2005/09/09(金) 20:16:510398デフォルトの名無しさん
2005/09/09(金) 20:30:440399デフォルトの名無しさん
2005/09/09(金) 21:45:270400デフォルトの名無しさん
2005/09/10(土) 00:48:48最初の条件判定（1回）を排除するために
定型表現を無視して見づらいコード作るのはやりすぎじゃね？
0401デフォルトの名無しさん
2005/09/10(土) 10:05:160402デフォルトの名無しさん
2005/09/10(土) 12:54:03そこまで最適化したいのなら、素直にdo-whileを使えって話でもあるし。
0403386
2005/09/10(土) 13:22:31いえ…早い話が、__assume() の可能性について知りたかっただけなんです。
今回の件は __assume() の挙動について調べるために一例として取り上げただけでして、
普通はコードの可読性を優先させて、定型表現を使うべきだと思います。
そもそも定型表現にこだわる必要がないのなら、はじめに >>386 でも触れましたように、
最初から for ではなく do ～ while で書いてしまえばいいわけですから…。
つーか >>386 の２行目、if じゃなくて for の間違いだよ…今頃気が付いた ＿|￣|○
0404デフォルトの名無しさん
2005/09/10(土) 16:01:08… ようするにもともと話の切り出し方も例もその後の情報の出し方も
ようを得ないで気も利かないから、みんなも興味ない喰いつきが悪いかと。
その例だともともと do{}while で書けばよい類のものだし、効果も小さいし、
hint与えたからといって、最適化しなくてもなんら不思議は無い、
逆に何を根拠にそれを期待するのか、のほうが冷ややかに不思議、程度かと。
0406デフォルトの名無しさん
2005/09/12(月) 10:35:24例示してあるような限定的なケースだけ最適化の対象になるのかも。
面白いネタ思いついたらまた戻っておいで。
0407デフォルトの名無しさん
2005/09/12(月) 11:17:32コンパイラ内の実装もdirty hack系のような気がする。
MSDNの"Example"では、式である必然性を疑わせる例なのに、
#pragmaじゃなくて、式の拡張になっているのも謎。
0408デフォルトの名無しさん
2005/09/12(月) 12:05:120409デフォルトの名無しさん
2005/11/09(水) 00:28:130410デフォルトの名無しさん
2005/11/09(水) 03:39:34全部forceinlineに汁
0411r
2006/01/05(木) 23:48:21typedef int int32_t;
int32_t min0( int32_t a, int32_t b ) {
return a < b ? a : b;
}
int32_t min1( int32_t a, int32_t b ) {
return ( ( a < b ) * a ) | ( ( b <= a ) * b );
}
int32_t min2( int32_t a, int32_t b ) {
// mathmatic shift
return ( ( ( a - b ) >> 31 ) & a ) | ( ( ( b - a - 1 ) >> 31 ) & b );
}
int32_t min3( int32_t a, int32_t b ) {
// logical shift
return ( ( ( a - b ) >> 31 ) * a ) | ( ( ( b - a - 1 ) >> 31 ) * b );
}
int32_t min4( int32_t a, int32_t b ) {
return ( ( ( ( a - b ) >> 31 ) & 0x01 ) * a ) | ( ( ( ( b - a - 1 ) >> 31 ) & 0x01 ) * b );
}
0412デフォルトの名無しさん
2006/01/05(木) 23:54:380413デフォルトの名無しさん
2006/01/06(金) 00:02:59俺も一時期、この手のヤツいろいろ試してみたけど十中八九 min0 が最速になるよ。
0414r
2006/01/06(金) 00:13:00そっか。一番短いもんなあ。
なんか三項演算子ってジャンプしそうだから、
ジャンプしなさそうなのがいいかなって思ったけど。
>>412
整数型でも、かけ算ってやっぱまだ遅いのか。
ｻﾝｷｭ
0415デフォルトの名無しさん
2006/01/06(金) 00:22:18いや、三項演算子ってジャンプするけどな。
それでも 0 が他と比べて早いと思う。
DSP とか、条件命令実行機能持った CPU だと条件ジャンプのコストはかなり低いし。
super scaler とか hyper threading でバリバリに最適化かかったら 1 が早いかもしれないけど、
十中八九 0 かと。
乗算はやっぱ遅い。
ただ、MMX 命令みたいに、複数の乗算を同時に出来る命令持った CPU もあるから、
そういうのだと積和演算なんかのスループットは結構早い。
0416デフォルトの名無しさん
2006/01/06(金) 00:38:03int32_t d = a - b;
return a - (d & (~(d ^ (a^b)&(d^a)) >> 31));
}
0417デフォルトの名無しさん
2006/01/06(金) 01:00:22int32_t r[2] = { a, b };
return( r[a<b] );
}
0418デフォルトの名無しさん
2006/01/06(金) 01:09:53if (MB_YES == MessageBox(NULL, "a は b より大きいですか？", "('A`)", MB_ICONINFORMATION |MB_YESNO)) {
return a;
} else {
return b;
}
}
0419デフォルトの名無しさん
2006/01/06(金) 01:30:000420デフォルトの名無しさん
2006/01/06(金) 02:42:51それ、メモリアクセスになって余計に遅かったりはしない？
あるいは最適化が効いて結局 0 と同じコードになるか。
0421デフォルトの名無しさん
2006/01/06(金) 03:04:41といいなぁ。
0422デフォルトの名無しさん
2006/01/06(金) 05:40:160423デフォルトの名無しさん
2006/01/06(金) 12:32:22メモリアクセスってもスタックは大概キャッシュにあるだろ。
0 の方が速いが。
0424デフォルトの名無しさん
2006/01/06(金) 12:52:390425デフォルトの名無しさん
2006/01/06(金) 22:26:330426デフォルトの名無しさん
2006/01/06(金) 23:36:220427デフォルトの名無しさん
2006/01/07(土) 00:04:44for(j=0; j<100000; ++j) {
k = rand();
l = rand();
test[j&0xFF] = min0(k,l);
}
}
みたいな感じでやったら、北森Pen4 3.0G ＋ VC7.1 Releaseビルド（/GB）で
5≒6＜2＜1≒3＜4＜0＜＜＜＜越えられない壁＜＜＜＜7
だった。/G7にすると2が最速
0428デフォルトの名無しさん
2006/01/07(土) 00:08:07さすがパイプライン深いな。
5が速いのは倍速ALUかな？遅いシフトも1回だけだし。
6はシンプルに分岐をなくすいい手だね。
0429デフォルトの名無しさん
2006/01/07(土) 00:19:06いろんな意味で。
0430デフォルトの名無しさん
2006/01/07(土) 00:32:39それぞれの実測値は？
7以外は測定誤差の範囲内だったりしないか？
ちゃんとQueryPerformanceCounterとか使った？
0431デフォルトの名無しさん
2006/01/07(土) 00:49:13VC++2003の/G6オプション。
>>427氏と同じコードで1ループ当たりのクロック数。
0:42clk
1:41clk
2:37clk
3:39clk
4:40clk
5:38clk
6:34clk
ランダムデータだから0が遅いんだね。
普通は分岐予測が効くだろうから実戦では0が速いんだと思う。
6は速いねえ。
コンパイル結果を見ると、6のr[2]はeaxとecxになってた。
つまりメモリアクセスをしていないから速い。
0432デフォルトの名無しさん
2006/01/07(土) 01:00:23eax と ecx は ID が1違いのレジスタってことなんかな？
0433デフォルトの名無しさん
2006/01/07(土) 01:04:3232bitのx86は8個の汎用レジスタがあって、espがスタックポインタな他は
どれも同じ種類のレジスタと考えて差し支えないと思いまんもす。
別にebxとesiに割り当てても速度や動作に違いは出ない。
0434デフォルトの名無しさん
2006/01/07(土) 01:04:377は？
0435デフォルトの名無しさん
2006/01/07(土) 01:08:04僕がボタンを押すのに40clkとかの時間で済むと思いますか。
0436デフォルトの名無しさん
2006/01/07(土) 01:08:11いや、min6 が分岐じゃないから早いという理屈から察するに、
a < b の演算結果が 0 か 1 かという事実から、
条件分岐ではなく値の違いでレジスタを選択できなきゃ駄目でしょ。
そういうことじゃないん？
0437デフォルトの名無しさん
2006/01/07(土) 01:14:03その通り。。俺の勘違いですた。
メモリアクセスはその後でしています。
0438427
2006/01/07(土) 01:16:30timeBeginPeriod(1) & timeGetTime() で計りますた。
何回やっても、こんな傾向だから、誤差以上ではあると思う。
5 ≒ 6 ＜ 2 ＜ 1 ≒ 3 ＜ 4 ＜ 0
5015 5019 5040 5092 5084 5151 5563 (ms)
/G7にすると2が5000ms切って、最速なんだけど、コード見たら
dec eax が sub eax,1 に置き換わってるだけだった。
そんなに違うもん？
0439デフォルトの名無しさん
2006/01/07(土) 01:18:38頑張れ！
0440デフォルトの名無しさん
2006/01/07(土) 01:20:42Pentium4だと、decとsubでレイテンシが0.5clk違う。
まあ、1～2%の差なら生まれてもおかしくない。
意外だが、0と6の差がPentiumMより少ないね。
0441431
2006/01/07(土) 01:36:350442デフォルトの名無しさん
2006/01/07(土) 01:38:24min0 が遅い理由、まあ Pen4 のパイプライン段数が糞多いのが直接の原因だけど、
普通は遅延分岐とかで多少マシになるでしょ。
入力がランダムだから予測は意味ないけど、遅延分岐なら。
min 関数の場合、遅延させるほど命令がないからどうしようもなくなってるわけで、
min 関数の前とかに別の処理とか入ってたらひょっとすると遅延分岐が効いてこないかな？
0443デフォルトの名無しさん
2006/01/07(土) 01:43:50Pen4 はよく知らないけど、普通は dec の方が早くないの？
Pen4 って内部的には算術命令を複数個並列処理してるんだっけ？
dec と sub を並列実行することで早くなってるとかでもないんかね？＜ /G7 で 2 が早くなるっての。
dec の演算器は全部使っちゃっててデータハザード起きてて、
それが sub に置き換えると（本来は sub の方が遅いけど、データハザード起こさない分）早くなるとか。
0444デフォルトの名無しさん
2006/01/07(土) 01:48:14遅延分岐って、フラグが確定するまで待つってこと？
x86で実装されてるの？
>>443
最近のCPUではdecもsubもほぼ変わらない。使うユニットも同じ。
命令長がdecの方が短いのがわずかに利点。
ただ、Pen4ではdecのが遅い。
これはパーシャルフラグの扱いがPen4では異なるため。
0445デフォルトの名無しさん
2006/01/07(土) 01:56:54アウトオブオーダーして、フラグを決める命令と分岐命令を先に実行する。
分岐命令が早めに実行されれば、予測ミスが発覚するのも早くなる。
つまり分岐ミスのペナルティが減る。
0446デフォルトの名無しさん
2006/01/07(土) 01:59:34>>442 は何か勘違いしてたかも。流して。
dec の方が遅いんか。
CPU は昔 RISC と DSP 中心で勉強したんで Pen4 は結構異文化だわ。
0447デフォルトの名無しさん
2006/01/07(土) 02:01:06あっ、それそれ。
Pen4 ってアウトオブオーダー実行してるんだっけ？
フラグ決めと実際の分岐の間に命令挟むようなことしてたら、
インライン展開の結果次第では・・・という。
0448デフォルトの名無しさん
2006/01/07(土) 02:01:09まあ、「別の処理」がないとアウトオブオーダーできないけどね。
PentiumMでは、通常14clk程度のペナルティだが、少なくなることも多い。
ただ、どうやっても7～9clkのペナルティはあった。
0449デフォルトの名無しさん
2006/01/07(土) 02:04:40ただ、この場合はさむものがないからねえ。
Pentium4ならminと次のrand()を並列実行できたりしてｗ
0450デフォルトの名無しさん
2006/01/07(土) 02:07:27min 関数単体でループ繰り返す限りには、「別の処理」なさ過ぎて >>445 みたいなのが全く役に立たないけど、
インライン展開後に「別の処理」があるようなコードでループすればどうなのかなぁと。
まあ、でも、予測の効かないランダムな値相手だとどうしても分岐は遅いのかな。
0451デフォルトの名無しさん
2006/01/07(土) 02:17:10なるへそ。
>>448のように、ランダムでもペナルティを半分くらいにはできるはずだけど。
でも実際は、普通は0が速いし、ランダムなら6使っとけば安心ということで
あんまり気にしなくてもいいのかもしれないけどね。
0452デフォルトの名無しさん
2006/01/07(土) 02:23:18Pen4 みたいに相当分岐に弱い環境でも10％くらいしか不利つかないんだと、
パイプラインの短いのなら普通は 0 が早そうよね。
2とか5は、よっぽど算術論理演算のクロックが短いか、
演算器が結構な数並列になってないと早くない気もするし、
6が使える条件も、0 か 1 かでレジスタを切りかえれないと駄目なわけだけど、
たいていの処理系ってそれできるんだっけ？
0453431
2006/01/07(土) 02:28:42__asm{
mov eax,a
cmp eax,b
cmovg eax,b
}
}
8:38clk
インラインアセンブラを使ってみた。6に負けたorz
>>452
どっこいPentiumMでは分岐ありの0は30%も遅い。
>たいていの処理系ってそれできるんだっけ？
フラグを汎用レジスタに転送できればいいのだから
大概大丈夫でしょう。
0454デフォルトの名無しさん
2006/01/07(土) 02:33:59IA32系じゃなくMIPS系CPUだったので
int32_t min8( int32_t a, int32_t b ) {
int32_t f = (a <= b);
return (a & (-f)) | (b & (f - 1));
}
( と floatに対してはmin6 )を使ってみたが、
計ったら min0() のほうが速かった
0455デフォルトの名無しさん
2006/01/07(土) 07:57:59MIPS 系は２個しか触ってないけど、FPU 積んでて min.s が無い石があるんだね・・・
0456431
2006/01/09(月) 02:59:06ほとんどレジスタだけで処理を済ませている。
それに対し>>453のmin8では、インライン展開はされているものの
展開先で、インラインアセンブラの範囲には最適化が全くかからないため、
無駄にメモリを介在することになってしまう。
0457デフォルトの名無しさん
2006/01/22(日) 07:42:080458デフォルトの名無しさん
2006/01/26(木) 22:01:580459デフォルトの名無しさん
2006/01/30(月) 08:23:220460デフォルトの名無しさん
2006/01/30(月) 13:20:30AMDがIntelに対して起こした告訴理由の一つとして
「ICCにおいてAMDプロセッサを使ってコンパイルすると糞コードを吐く」
を主張している。
ttp://www.itmedia.co.jp/news/articles/0507/14/news031.html
0461デフォルトの名無しさん
2006/01/30(月) 13:21:24+AMDがIntelに対して起こした訴訟の告訴理由の一つとして
0462デフォルトの名無しさん
2006/01/30(月) 13:34:26これって、コンパイルした実行ファイルを実行するときの話じゃなくて、
コンパイラの動作自体がCPU依存になってるってこと？
だとしたらとんでもないな。
0463デフォルトの名無しさん
2006/01/30(月) 13:36:29とりあえずSPECなんかみてるとOpteron+ICCの構成はいくらでもみつかる。
0464デフォルトの名無しさん
2006/02/02(木) 06:18:46劣化したコードにもかかわらずこれだけ出ているのはすごいな
0465デフォルトの名無しさん
2006/02/02(木) 10:55:11のであれば、IntelCPUでコンパイルしてAMDCPUで実行しても
遅くならないんじゃまいか。
0466デフォルトの名無しさん
2006/02/02(木) 11:26:01実行時にCPUを判別して分岐する
0467デフォルトの名無しさん
2006/02/02(木) 11:35:27MSVCとICCとGCCもいれて全部比較してみれたら面白そうだなぁ。
0468デフォルトの名無しさん
2006/02/03(金) 02:17:18これどうして、k, lをrand()にしているの?
min*()よりずっと重い処理になるけれど。
0469デフォルトの名無しさん
2006/02/03(金) 09:53:14ランダムにしないと分岐予測が当たっちゃうから。
まあ、ランダムにしたせいで分岐ペナルティの最も多い場合になるわけだが。
0470デフォルトの名無しさん
2006/02/03(金) 10:41:17l = i-j;
にするとだいぶ結果が変わってくるな。
0471デフォルトの名無しさん
2006/02/03(金) 10:53:33全く同じOS構成、ICC構成で、CPUだけ違う環境を用意して
ICCが吐くコードをバイナリ比較すりゃいいじゃん。
0472デフォルトの名無しさん
2006/02/03(金) 11:18:27うそー、コンパイル環境で吐くバイナリが変わるのか？
0473デフォルトの名無しさん
2006/02/03(金) 13:07:17コンパイラがgccって事もあって、どちらもmin0が一番速かった。
ちなみにどちらも最適化オプションは同じ(-O4)で、
コンパイラのバージョンは
OSX gcc 3.3
cygwin gcc 3.4.4
0474デフォルトの名無しさん
2006/02/06(月) 16:49:32出鱈目だろ。
実行時に判別して～云々は、よくマニュアル読んでないだけか、ただの言いがかり。
たとえば/QaxNとかでビルドすると、SSE2の使用有無にかかわらずPentium 4でしか最適化された
パスを通らないコードができるがそれは当たり前の動作。AMDのCPUであろうがなかろうが跳ねられる。
CPU毎の最適化を使いつつICCのスタートアップルーチンを使わない手ならいくらでもあるけどな。
一番簡単なのは、最適化対象の関数だけターゲット数分別名で作って、ファイルごとにコンパイルオプション
変えて(/G6, /G7, /QxK, /QxN, /QxP, /QxB, ....)専用にコンパイルし、全部リンクする。
自前で関数テーブルを作ってやる必要があるが、CPUIDで自動判別させるのを自前でやるなり、
ユーザーに選ばせるなりできる。
信用しきれないなら/FAでasmコード生成してそいつをVC++で利用するのも悪くないお
0475デフォルトの名無しさん
2006/02/12(日) 15:28:250476デフォルトの名無しさん
2006/02/12(日) 17:05:31大きくない
他のインリンされそうにない関数よばない
0477デフォルトの名無しさん
2006/02/12(日) 17:35:45>476は血迷っているので信じないように。
コンパイラによって違うから、一概に言えないとしか言いようがないのがinline化。
例えば、分岐やループがあろうが標準関数を呼ぼうがinline化される環境ならinilne化される。
0478デフォルトの名無しさん
2006/02/12(日) 20:14:39あとエロテロリストにきくのが一番いいとおもうけど
0479デフォルトの名無しさん
2006/02/12(日) 23:36:35もう一度>>475が何を訊ねているのかを読むべき。
0480デフォルトの名無しさん
2006/02/12(日) 23:46:43477は日本語が不自由なんだよ
0481デフォルトの名無しさん
2006/02/12(日) 23:57:350482デフォルトの名無しさん
2006/02/13(月) 00:17:540483デフォルトの名無しさん
2006/02/13(月) 02:57:02そろそろプギャーとか言い出すぞ。
0484デフォルトの名無しさん
2006/02/13(月) 07:10:20-O3 -Qipioより-O2 -Qip -Qunroll0で最適化したほうがなぜか速いケースがある。
0485デフォルトの名無しさん
2006/02/13(月) 11:10:28菊地美香をなんとかインリン化できないものでしょうか？
0486デフォルトの名無しさん
2006/02/13(月) 12:10:17カプセル化されてるから難しい
0487デフォルトの名無しさん
2006/02/13(月) 17:20:360488デフォルトの名無しさん
2006/02/14(火) 14:39:32#define inline __forceinline
0489デフォルトの名無しさん
2006/02/14(火) 17:38:570490デフォルトの名無しさん
2006/02/14(火) 17:46:520491デフォルトの名無しさん
2006/02/14(火) 18:07:00つC++/CLI
0492デフォルトの名無しさん
2006/02/14(火) 18:08:20今となっちゃIA-32のアセンブラ自体中間言語みたいなもんだ
0493デフォルトの名無しさん
2006/02/14(火) 19:26:00ずいぶんと古い今だな。
0494デフォルトの名無しさん
2006/02/26(日) 07:30:310495デフォルトの名無しさん
2006/02/26(日) 09:13:22むかしは条件判定もったいないとかで関数ポインタ駆使したりと
小手先なことしてたが、最近はスイッチで十分だと。
言語から仮想関数とかの支援があればそれを使うのも結構だけど、
分岐そのものがその場に書いてあるスイッチやバカチョンif判定
書いてあるスイッチはやはり後で見て分かりやすい
0496デフォルトの名無しさん
2006/02/26(日) 09:32:200497デフォルトの名無しさん
2006/02/26(日) 10:32:19連続する数値は
case 'a' to 'z': とかできたらいいのに
0498デフォルトの名無しさん
2006/02/26(日) 10:41:24case 0:
case 1:
case 2:
case 3:
処理
0499デフォルトの名無しさん
2006/02/26(日) 12:20:27連続してなくても(半ば強引に)展開するコンパイラもあるね。
>>497
case 'a': case 'b': ... case 'z':
を自動生成させてはいかが?w
>>495
半島人を中途半端に馬鹿にする発言はよくない。
きちんと、「馬鹿でも朝鮮人でもできるような単純な判定」と書きましょう。
0500・∀・）っ-○●◎- ◆Pu/ODYSSEY
NGNGGCCの独自拡張で to → ..
0501デフォルトの名無しさん
2006/03/01(水) 13:57:02「バカチョン」は朝鮮人とは何の関係もない言葉なのだが…。
0502デフォルトの名無しさん
2006/03/01(水) 14:02:27その言葉は「バカでもチョンでも」から来たとする説と
｢バカでもチョンと押すだけで」から来たとする説の二つがある。
前者が存在する時点で使うのをためらうべき言葉だとは思わないか？
0503デフォルトの名無しさん
2006/03/01(水) 14:11:15「『ちょん』は明治時代には日本語として存在していて
バカや間抜けと同義。」らしい。
まあ、言葉狩りに意味があるとも思えんが。
0504デフォルトの名無しさん
2006/03/01(水) 14:41:07二つ意味があるってだけでどっちにしろ同じことじゃないかな？
起源について二つの説がある「バカチョン」という言葉の問題か
二つの意味を持つ「ちょん」という言葉の問題かってだけで。
まあ最適化とは関係ないからそろそろ次の人どうぞ。
0505デフォルトの名無しさん
2006/03/01(水) 14:46:04お そ .い ヽ
か の や |
し り ｀ ,. -──- ､
い .く ／ /⌒ i'⌒iヽ､
つ / ,.-'ゝ__,.･･_ノ-､ヽ
は i ‐'''ﾅ''ｰ-- ● =''''''ﾘ _,....:-‐‐‐-.､
l -‐i''''~ﾆ-‐,....!....、ｰ`ﾅ `r'=､-､､:::::::ヽr_
￣ ＼ヽー' !. t´ r''"´､_,::、::::} ノ` ,.i'・ ,!_`,!::::::::::::ヽ
ヾ、 ゝゝ､,,ﾆ=====ﾆ／r'⌒; rｰ`ｰ' ,! ﾘ::::::::::::ﾉ
i`''''ｙ--- (,iﾃ‐,'i~´,ゝ'´ ￣￣ヽ` :::::::::::ノ
.| !、,............, i }'´ _ ､ｰ_',,...`::::ｨ'
●､_!,ヽ-r⌒i-､ノ-''‐､ ゝ`ｰt---''ヽ'''''''|`ーt-'つ
( `ｰｲ ﾞi 丿 ;'-,' ,ノｰ''''{`' !ﾞヽﾉ ,ヽ,
`ー--' --'｀￣ ｀ｰ't,´｀ヽ;;;､,,,,,,___,) ヽ'-ﾞ'"
(`ー':;;;;;;;;;;;;;;;ﾉ
｀`''''''｀`'''''´
0506デフォルトの名無しさん
2006/03/01(水) 16:34:00ただ、本人には、反駁があってバカにされたあげくにスレが荒れたら責任を感じてもらいたい。
0507デフォルトの名無しさん
2006/03/01(水) 16:49:110508デフォルトの名無しさん
2006/03/01(水) 18:33:18来るべき質問を予測して投機的に回答しておいたり、引用はinline展開したりするべきだな。
0509デフォルトの名無しさん
2006/03/01(水) 19:44:110510デフォルトの名無しさん
2006/03/01(水) 19:46:410511デフォルトの名無しさん
2006/03/01(水) 19:52:52思考停止はお前。
0512デフォルトの名無しさん
2006/03/01(水) 20:38:10同趣旨のレスは一箇所で定義しておいて、他で参照するようにするとか。
0513デフォルトの名無しさん
2006/03/01(水) 21:30:41脊髄反射はお前。
0514デフォルトの名無しさん
2006/03/02(木) 00:10:070515デフォルトの名無しさん
2006/03/02(木) 11:35:530516デフォルトの名無しさん
2006/03/02(木) 12:02:140517デフォルトの名無しさん
2006/03/02(木) 12:03:100518デフォルトの名無しさん
2006/03/02(木) 12:45:250519デフォルトの名無しさん
2006/03/02(木) 14:14:04そうです。よくこのスレの秘密がわかりましたね。
みんなで暗号化して一見C,C++の話やちょんの話を
しているように見せかけて実はずいずいずっころ
ばしのことを延々と話していたんですが。
0520デフォルトの名無しさん
2006/03/02(木) 15:10:070521デフォルトの名無しさん
2006/03/02(木) 15:46:210522デフォルトの名無しさん
2006/03/02(木) 16:20:18う
ん
こ を延々と していた
こうですか？わかりません！
0523デフォルトの名無しさん
2006/03/02(木) 22:40:58で
な
い
の
0524デフォルトの名無しさん
2006/03/02(木) 23:40:410525デフォルトの名無しさん
2006/03/03(金) 00:37:32流石ﾌﾟﾛﾊｶｰ!
0526デフォルトの名無しさん
2006/03/03(金) 22:30:020527・∀・）っ[F32vec4] ◆Pu/ODYSSEY
2006/03/03(金) 22:47:260528デフォルトの名無しさん
2006/03/03(金) 23:36:59SSE2とか使うのは難しくないけど、
それでより効率よく演算できるようにしようとすると、俺のレベルじゃ無理だ。
0529デフォルトの名無しさん
2006/03/04(土) 02:49:39しかも効率ってSSEじゃなくてメモリアクセスのほうが問題になるだろ。
0530デフォルトの名無しさん
2006/03/04(土) 08:07:32Ｉｎｔｅｌ C++ Compilerならある程度の自動ベクタライズをしてくれる。
でも、いろいろコンパイラに指示しなくてはならないし複雑なものには対応してくれない。
結局は自分で直接SIMD命令を書くのが効率がよい。
アセンブラで書くのが面倒なら組み込み命令(xmmintrin.h)を使ってみるといい。
0531デフォルトの名無しさん
2006/03/04(土) 09:19:080532・∀・）っ-○●◎- ◆Pu/ODYSSEY
2006/03/04(土) 14:06:41パイプラインを考慮したスケジューリングはコンパイラ任せでも十分速度出る。
むしろハードウェアのレジスタリネーミングやOoOである程度畳み込みやってくれる。
0533デフォルトの名無しさん
2006/03/04(土) 20:54:53でも、その最適化って年末あたりに出る次の世代のx86じゃ使えないんだろ
0534デフォルトの名無しさん
2006/03/04(土) 21:05:500535デフォルトの名無しさん
2006/03/04(土) 23:05:03MMXはx64で使えなくなってるね。 SSE系が使えなくなるって話はまだ聞いてないけど。
>526
>530が言ってるようにxmmintrin.h使うといいよ。
ICCとVC6以降で使えたと思う。 MSDNに英語のドキュメントがあるから参考にするといい。
(ドキュメントはC++ LanguagesのCompiler Intrinsic以下)
レジスタ割付を考えなくてすむので、アセンブリで書くよりは大分楽になる。
// あるいは、Direct3Dで用意されてる各構造体を使うという手も。 確か自動的にSSE使ってくれたと思う。
0536・∀・）っ-○●◎- ◆Pu/ODYSSEY
2006/03/04(土) 23:07:54mmintrin.h使うとIA64でもx64でも64bit汎用整数使ったコードに展開される。
0537デフォルトの名無しさん
2006/03/05(日) 01:17:50あれ？ おいらが試したときはリンクエラー出たんだけど＞MMXのintrinsic
0538デフォルトの名無しさん
2006/03/05(日) 04:12:15今のショートベクトルよりでかいベクトル演算器がのることはないだろ。使い道ないし。
0539デフォルトの名無しさん
2006/03/05(日) 04:20:17http://pc8.2ch.net/test/read.cgi/tech/1140510670/117-
0540・∀・）っ-○●◎- ◆Pu/ODYSSEY
2006/03/05(日) 04:28:31ごめん、ビット論理（pandとかpxor）やシフトとかのごく一部だけかもしれん。また機会があったら試してみる。
リンクエラー？コンパイルエラーじゃなくて？
0541デフォルトの名無しさん
2006/03/05(日) 04:30:20スレ違い
0542デフォルトの名無しさん
2006/03/05(日) 04:36:54それを100msで処理したいそうです。
0543・∀・）っ-○●◎- ◆Pu/ODYSSEY
2006/03/05(日) 04:42:52実は３次元なんじゃね？XGA×奥行きｗｗｗ
0544デフォルトの名無しさん
2006/03/05(日) 06:15:33なんで糞質問糞レスをしてる暇は湯水のようにあるくせに
4900ms程度を待てないようなバカが平気で生きてるんだろう？
ホント避妊は大事だよな。
0545デフォルトの名無しさん
2006/03/05(日) 10:06:25コンピュータに100msでやらせたいってんなら
ある意味すげえけどな。
0546デフォルトの名無しさん
2006/03/05(日) 11:00:370547デフォルトの名無しさん
2006/03/05(日) 12:52:120548デフォルトの名無しさん
2006/03/05(日) 13:51:07基本的なとこでずれてる。
0549デフォルトの名無しさん
2006/03/07(火) 02:21:31質問スレに誘導した方がいいね。
内容うんぬんより、質問者の質問の仕方に問題有りそうだ。
『こうすれば解決するはず』と思いこんでいて解答者が
求める情報を出し渋るパターン。
他、解答者が求める情報を『問題とは関係無い』と出さなかったり。
まだ続きそうだったら↓のスレに案内するのはどうかな。
(3)(4)はちょっと失礼なので(1)(2)あたりで。
(1)C統合・質問スレッド
http://pc8.2ch.net/test/read.cgi/tech/1068359871/l50
(2)すれ立てるまでもない質問はここで 第74刷
http://pc8.2ch.net/test/read.cgi/tech/1140269442/l50
(3)はきだめC/C++下級者の質問箱
http://pc8.2ch.net/test/read.cgi/tech/1124256027/l50
(4)【漏れは】猫でもわかる質問スレ【猫以下です】
http://pc8.2ch.net/test/read.cgi/tech/1054813207/l50
0550デフォルトの名無しさん
2006/03/07(火) 06:35:56>(1)C統合・質問スレッド
>http://pc8.2ch.net/test/read.cgi/tech/1068359871/l50
ちょｗｗｗｗそれC#のｽﾚだからｗｗｗｗｗ
# なんかｽﾚﾀｲに"#"を使うと消えちゃうらしいｗ
0551デフォルトの名無しさん
2006/03/13(月) 11:13:350552デフォルトの名無しさん
2006/03/14(火) 04:12:59C・しゃーぷっ 統合質問スレッド
で解決だな
0553デフォルトの名無しさん
2006/03/14(火) 11:17:21なにかデジャブを覚えると思ったらおじゃ魔女だったorz
0554http://www.vector.co.jp/soft/win95/util/se072729.html
2006/03/18(土) 22:20:36もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？
そういや64bitにネイティブ対応している２ｃｈブラウザてありましたっけ？
0555デフォルトの名無しさん
2006/03/19(日) 01:46:210556デフォルトの名無しさん
2006/03/29(水) 17:45:010557デフォルトの名無しさん
2006/03/29(水) 18:12:190558デフォルトの名無しさん
2006/03/29(水) 18:30:280559デフォルトの名無しさん
2006/03/29(水) 18:38:310560デフォルトの名無しさん
2006/03/30(木) 00:05:500561デフォルトの名無しさん
2006/03/30(木) 00:11:42~~~~~~~
0562デフォルトの名無しさん
2006/03/30(木) 02:02:080563デフォルトの名無しさん
2006/03/30(木) 03:24:090564デフォルトの名無しさん
2006/03/30(木) 03:26:040565デフォルトの名無しさん
2006/03/30(木) 08:34:15お前ならいったいどんな条件を機械語で書くのか、小一時間問い詰めたい。
0566デフォルトの名無しさん
2006/03/30(木) 08:41:56例えば条件分岐の非成立の直後のみ無条件分岐の予測に成功する処理系とかか
存在するのか?
0567デフォルトの名無しさん
2006/03/30(木) 09:09:040568デフォルトの名無しさん
2006/03/30(木) 09:50:46条件分岐のコード吐くようじゃなんの意味もないな
0569デフォルトの名無しさん
2006/03/30(木) 10:00:080570デフォルトの名無しさん
2006/03/30(木) 10:02:240571デフォルトの名無しさん
2006/03/30(木) 10:03:480572デフォルトの名無しさん
2006/03/30(木) 10:04:120573デフォルトの名無しさん
2006/03/30(木) 10:45:50Z80系のCPUは無条件ジャンプよりも、条件ジャンプの方がクロックが短い。
(条件成立時は同じで非成立時が短い)
do { i--; } while(i >= 0);
これがZ80ではsignedの方が速い可能性がある。
まぁ、ループを抜けるとこまで考えなくても、Z80では無条件ジャンプも
条件ジャンプの成立時もクロックが同一なので、ループの判定が
コストフリーの場合は速くはならないな。
0574デフォルトの名無しさん
2006/03/30(木) 10:49:32>>569
0575デフォルトの名無しさん
2006/03/30(木) 10:56:56このｽﾚでは、一般論は無駄。
まずやってみろ。
0576デフォルトの名無しさん
2006/03/31(金) 22:08:55で
b=a/2;
と書くと、シフトにしてくれる
signedだと無理。
0577デフォルトの名無しさん
2006/03/31(金) 22:37:38お前の使っている処理系では、だな。
0578デフォルトの名無しさん
2006/03/31(金) 23:03:23日記乙。
0579デフォルトの名無しさん
2006/03/31(金) 23:40:140580デフォルトの名無しさん
2006/03/31(金) 23:44:07意味わかってる？
0581デフォルトの名無しさん
2006/03/31(金) 23:54:54可能性がある、という意味では必要条件を満たした
0582デフォルトの名無しさん
2006/03/32(土) 02:26:300583デフォルトの名無しさん
2006/03/32(土) 11:31:16-2わる2=-1
-3わる2=-1
だけど、signed charで
-2 = 0xfe,
-3 = 0xfd
でその算術シフトが
0xfe >> 1 = 0xff = -1
0xfd >> 1 = 0xfe = -2
で結果が違うからね。
unsignedなら論理シフトと一致。
signedでブランチなしのシフトを使った２の割り算は、
(n+((unsigned)n>>(bit数-1)))>>1
かな
0584デフォルトの名無しさん
2006/03/32(土) 11:43:57int divide_by_two(int n)
{
return n / 2;
}
mov eax, DWORD PTR _n$[esp-4]
cdq
sub eax, edx
sar eax, 1
unsigned int unsigned_divide_by_two(unsigned int n)
{
return n / 2;
}
mov eax, DWORD PTR _n$[esp-4]
shr eax, 1
0585デフォルトの名無しさん
2006/03/32(土) 13:41:04大して意味のある話でもないし。
0586デフォルトの名無しさん
2006/03/32(土) 14:06:05まあ、普通の人はそんな事は気にしなくても大丈夫だ。
そういう結論でいいだろ。
0587デフォルトの名無しさん
2006/04/02(日) 13:14:11C99で初めて定義されてた記憶があるんだが。
0588デフォルトの名無しさん
2006/04/03(月) 07:53:510589デフォルトの名無しさん
2006/04/03(月) 11:33:510590デフォルトの名無しさん
2006/05/07(日) 08:35:07*address = data;
address++;
*address = data;
address++;
*address = data;
address++;
*address = data;
address++;
と
2.
address[0] = data;
address[1] = data;
address[2] = data;
address[3] = data;
address += 4;
の処理があったとして、これをループ処理を行った場合、1と2ではどちらが速いでしょうか？
0591デフォルトの名無しさん
2006/05/07(日) 08:36:25MOV R1, @-R4
MOV R1, @-R4
MOV R1, @-R4
MOV R1, @-R4
と
2.
MOV R1, @R4
ADD #4, R4
MOV R1, @R4
ADD #4, R4
MOV R1, @R4
ADD #4, R4
MOV R1, @R4
ADD #4, R4
と
3.
MOV R1, @R4
MOV R1, @(4, R4)
MOV R1, @(8, R4)
MOV R1, @(12, R4)
ではどれが一番速いでしょうか？
0592デフォルトの名無しさん
2006/05/07(日) 08:38:050593デフォルトの名無しさん
2006/05/07(日) 09:23:32速度は実測が基本。
CPU とコンパイラの組み合わせで結果が違うだろうから、一般的なことは言えない。
0594デフォルトの名無しさん
2006/05/07(日) 21:56:20メモリをクリア＆確認する際に
１．
アドレスに0をセット
0になってるかORしてチェック
アドレスを加算
以下サイズ分ループ
２．
アドレス＋サイズを算出（終了アドレス＋１）
アドレスを減算
アドレスに0をセット
0になってるかORしてチェック
以下サイズ分ループ
1と2で、やってることは似たようなもののはずなのに（ただ単にアドレスを加算してるか減算しているかの違いぐらい）
なぜか処理速度（サイクル数）が異なってました。
原因として何が考えられますか？
0595デフォルトの名無しさん
2006/05/07(日) 22:02:40減算にするとループの終了判定が 0 との比較になるので
早くなることが、昔はよくあったものだ。
今時のコンパイラだと最適化かければ差はなくなると思ってたんだが、
どんなコンパイラ使ってんの？その前に最適化かけてないとか？
あとな、
「アドレスに0をセット」はわかりにくい。
文脈から「アドレスの指す位置に0をセット」と読み取るのに時間がかかった。
0596デフォルトの名無しさん
2006/05/07(日) 22:09:01ちなみに終了条件はサイズが0になっているかなので
アドレスの加算や減算とは特に関係はないと思っています。
＞どんなコンパイラ使ってんの？その前に最適化かけてないとか？
コンパイラはSuperH用のコンパイラでSHCというものの最新版です。
最適化はスピード優先でやっています。
アドレスの加算と減算に処理速度の違いはあるのでしょうか・・・
（実際に試した感じでは違いがありました）
0597デフォルトの名無しさん
2006/05/07(日) 22:21:03速度は実測が基本。
「試した感じ」ってなんだよ。やる気あんのか？
まだ気になるなら、まずはリストファイル吐かせて
アセンブリソースを確認するのがいいだろう。
SuperH は詳しくないけど、書き込み＋インクリメントが１命令にできて、
書き込み＋デクリメントは１命令にできないとか？
0598デフォルトの名無しさん
2006/05/07(日) 23:35:30この部分、
> アドレスに0をセット
> 0になってるかORしてチェック
(*addr) = 0;
if ((*addr | 0) != 0)
ってことですか。 それとも
(*addr) = 0;
if ((addr | 0) != 0)
でしょうか。
*何が* 0なのか解りません。
0599デフォルトの名無しさん
2006/05/08(月) 00:30:56unsigned long temp = 0;
*address = 0;
temp |= *address;
address++;
これをサイズ分
もしくはaddressを最初にaddress += size;を行い、終了アドレス＋１を算出後
address--;
*address = 0;
temp |= *address;
これをサイズ分
上記の処理を行ったとき、減算のほうが処理が早かったのです。
クリアサイズは
1024バイトで17サイクルの差
4096バイトで60サイクルの差
でした。
0600デフォルトの名無しさん
2006/05/08(月) 00:34:27address の型に volatile 付いてるか？
そうじゃなきゃ temp |= *address は最適化で消えるぞ。
0601デフォルトの名無しさん
2006/05/08(月) 00:39:39ようは、アセンブラコードを見た際に
アドレスを加算しながら先頭アドレスから終了アドレスまで処理を行うのと
アドレスを減算しながら終了アドレスから先頭アドレスまで処理を行うので
なぜ速度が変化するのかがアセンブラコード上ではわからなかったのです。
MOV @R1+, R2
と
MOV R1, @-R2
の違いでサイクル数が変わる理由です。
値をセット後アドレス加算と
アドレス減算後値をセットでなぜサイクル数が変わるのか・・・
CPUの問題でしょうか？
0602デフォルトの名無しさん
2006/05/08(月) 03:45:300603デフォルトの名無しさん
2006/05/08(月) 06:35:12君の場合、そういうもんだと思って使え
理由を理解するにはまだ早い。
0604デフォルトの名無しさん
2006/05/08(月) 08:07:23こりゃまずい、手に負えない、でも答えられず放っておくのも格好悪い、と考え、
まるで質問者に問題があるかのような（でもどう問題があるかは言えない）雰囲気を
頑張って作り出そうとしている、というところですかね :-)
0605デフォルトの名無しさん
2006/05/08(月) 08:29:430606デフォルトの名無しさん
2006/05/08(月) 08:33:59嫌なことを指摘されたので慌てて焦点を変えてみたというところですかね :-)
0607デフォルトの名無しさん
2006/05/08(月) 08:58:370608デフォルトの名無しさん
2006/05/08(月) 09:10:29お前のせいでさっき食ったソバ全部吐いちまったじゃねーか。
0609デフォルトの名無しさん
2006/05/08(月) 13:25:170610デフォルトの名無しさん
2006/05/08(月) 13:59:19口の中にあるもの全部じゃなく、胃の中全部かいな。
そりゃ難儀やったのう。
0611デフォルトの名無しさん
2006/05/08(月) 15:36:170612デフォルトの名無しさん
2006/05/08(月) 15:44:13もう帰っていいよ
0613デフォルトの名無しさん
2006/05/08(月) 20:50:510614デフォルトの名無しさん
2006/05/08(月) 23:34:40> これをサイズ分
ってあっさり書いてるけど、ループなんだからここがキモなんじゃ?
他にも一度で書くのは1バイトなのか4バイトなのか、とか。キャッシュの乗り方が
違ってくるし。
SHはワード未満のバイト単位のアクセスにペナルティがあったりしない?
>MOV @R1+, R2
>と
>MOV R1, @-R2
>の違いでサイクル数が変わる理由です。
と書いてるけど
>値をセット後アドレス加算と
>アドレス減算後値をセットでなぜサイクル数が変わるのか・・・
命令だけでなくて順序も違ってるし。パイプラインがストールするんじゃなくて?
どちらかというと、アドレス生成後にストアする方がペナルティありそうだけど。
0615デフォルトの名無しさん
2006/05/08(月) 23:42:31http://japan.renesas.com/fmwk.jsp?cnt=superh_family_landing.jsp&fp=/products/mpumcu/superh_family/
↑ここからたどったドキュメントにはアドレスをデクリメントしながら書き込む命令は
見当たらなかった。597 が正解なんじゃないかと思うんだけど、コンパイラの吐いた
アセンブラコード見たんだよな？
ほんとで MOV R1, @-R2 なんて命令あったか？
0616615
2006/05/08(月) 23:44:47アドレスをデクリメントしながら書き込む命令と
アドレスをインクリメントしながら読み込む命令
があった。
アドレスをインクリメントしながら書き込む命令はないってことで、
インクリメントのほうが遅くなるんじゃね？
0617デフォルトの名無しさん
2006/05/09(火) 15:50:12＞アドレスをインクリメントしながら読み込む命令
PUSH / POP か。
0618デフォルトの名無しさん
2006/05/09(火) 18:08:54push を使ったというのを聞いたことがある。
0619デフォルトの名無しさん
2006/05/09(火) 22:00:02機能はそのとおりだけどニーモニックは MOV だよ。
0620デフォルトの名無しさん
2006/05/10(水) 01:00:290621デフォルトの名無しさん
2006/05/10(水) 01:19:070622デフォルトの名無しさん
2006/05/10(水) 23:29:010623デフォルトの名無しさん
2006/05/10(水) 23:36:43const 修辞によって値が変わらないという前提を最適化機が得ることによって、
その値を使った式を定数の畳み込みに組み込む機会が増えるから。
0624デフォルトの名無しさん
2006/05/11(木) 00:15:37[constなし]
int X = hogehoge;
int Y = 0;
X += Y;
↓↓↓↓↓↓↓
MOVE PTR[X] ER1;
MOVE PRT[Y] ER2;
ADD ER1 ER2;
[constあり]
int X = hogehoge;
const int Y = 0;
X += Y;
↓↓↓↓↓↓↓
MOVE PTR[Y] ER2;
ADD #hogehoge ER2;
アセンブラがわからないので上に例は適当です。どこかで定数使ったほうが早くなる項があるってことで理解しました。
ありがとうございました。
0625デフォルトの名無しさん
2006/05/11(木) 00:31:33関数呼び出しの後でも、メモリが書き換えられてないことが期待できるから、
メモリからのロードをサボることができるなど。
0626デフォルトの名無しさん
2006/05/11(木) 00:33:18C にはグローバル変数などがあるので、一般的にそれはできない。
しかし const にまつわる一般的な誤解の一つでもある。
0627デフォルトの名無しさん
2006/05/11(木) 01:46:06もう一個質問なのです。
最適化目的ならば、constはこういう時に使えってものはあるのでしょうか？
例えば、
#define HOGEHOGE (2)
(中略)
const int temp = HOGEHOGE;
↑のような場合であれば、畳込みは起きるだろうなあと思うのです。
しかし、const宣言された変数の内容が動的に決まる場合にも、
定数の畳込みが起きる場合というのはあるのでしょうか？
例えば、
const int temp = pHoge->getHogeHoge();
コンパイラにここまでの解析能力があるのかってのが疑問です。
とりあえず、コンパイラが何をするのかわからないから、値が不変の変数は常にconst修飾しておくべきなんですかね？
0628デフォルトの名無しさん
2006/05/11(木) 01:54:49「最適化を目的に const を使うな。」という言葉を贈っておく。
0629デフォルトの名無しさん
2006/05/11(木) 01:57:28規格上は、その呼び出しが定数に最適化できれば、さらに畳み込むことは可能。
畳み込みじゃないが、下の temp のように const つきのオブジェクト定義が見えていれば、
たとえ &temp のようなポインタを取っていても >>625 の言うような
関数をまたぐ不変性が最適化に利用できる。
でも const は最適化への効果よりメンテナンス性への効果のほうがはるかに大きい。
おまけで最適化の助けになることもあるよ程度に考えたほうがいい。
0630デフォルトの名無しさん
2006/05/11(木) 02:04:21なるほどなるほど。ただ、健全に動いているソース部分に手を加えずに、
宣言部分にちょちょっと手を加えただけで、速度が改善できればなあ、って人情で許してください。
0631デフォルトの名無しさん
2006/05/11(木) 02:21:480632デフォルトの名無しさん
2006/05/11(木) 02:30:30最初からconstで宣言しておこうよ。
0633デフォルトの名無しさん
2006/05/11(木) 02:35:52constな変数が基本で、
書込できる変数にwriteとかって修飾子付けるべきだと思う。
0634デフォルトの名無しさん
2006/05/11(木) 02:37:40変数なのに・・・
0635デフォルトの名無しさん
2006/05/11(木) 02:44:08write定数
0636デフォルトの名無しさん
2006/05/11(木) 02:45:15そして究極的には書き込みという概念が無くなって関数型言語に向かう、と。
0637デフォルトの名無しさん
2006/05/11(木) 12:41:14のいってることを、自分のあいまいなマシン語の
知識で考えてみた。次の処理アドレスの入った
レジスタがあったような気がするけど、それでも、
終了アドレスから先頭アドレスまで処理するって
のは、そもそもできるんだろうか？知りたい。
0638637
2006/05/11(木) 12:43:290639デフォルトの名無しさん
2006/05/11(木) 16:36:07いまどきのPCで動くプログラムならばその程度では速度は大差ないと思うな。
そんなことよりもアルゴリズム見直すとか I/O 関係で非効率な入出力をして
いないかを調べた方がいいと思う。
0640デフォルトの名無しさん
2006/05/11(木) 19:25:21void copy(int*dst,int*src,int n){
int i;
for(i=0;i<n;i++) dst[i]=src[i];
}
この関数のsrc[]をconstで修飾すれば、
dstとsrcのエイリアスがないと思って
ループアンローリングしてくれんじゃね？
0641デフォルトの名無しさん
2006/05/11(木) 19:31:430642デフォルトの名無しさん
2006/05/11(木) 22:19:45それは restrict の仕事。
0643デフォルトの名無しさん
2006/05/11(木) 23:35:35って思いっきり環境依存でした。スマソ
0644デフォルトの名無しさん
2006/05/12(金) 06:25:51しかも、HPのコンパイラなんかでは最適化上無視してるとか
書かれていたような
0645デフォルトの名無しさん
2006/05/12(金) 12:25:57>restrictってC99でやっと仕様にはいったんじゃない？
是。
0646デフォルトの名無しさん
2006/05/12(金) 22:56:090647デフォルトの名無しさん
2006/05/13(土) 00:21:27なんか聞いたことあるな。オブジェクトの配置を ROM にするかどうか
制御する手段が無いと困るから、自然な流れにも感じる。
0648デフォルトの名無しさん
2006/05/13(土) 03:38:47Ritchieの「氏ねや、noalias！」
http://www.quut.com/c/dmr-on-noalias.html
付録に「noalias v.s. restrict」
http://www.lysator.liu.se/c/restrict.html
0649デフォルトの名無しさん
2006/05/13(土) 13:59:30でも、constなインスタンスもmutableなメンバを持てるでしょう？
その辺...なんか、面倒くさそうだなあ、って思う。
0650デフォルトの名無しさん
2006/05/13(土) 15:18:02constなオブジェクトでもコンストラクタ・デストラクタでは自由にメンバを書き換えられる。
0651デフォルトの名無しさん
2006/05/13(土) 17:54:31そういうのは ROM に置けない。
mutable についてはコンパイラが簡単に判別できるだろうけど、
コンストラクタとデストラクタについては、賢く判別するのは難しい。
現状では、 non-trivial なコンストラクタまたはデストラクタを持つクラスは
ROM に置けないという保守的な判別で済まされると思う。
0652デフォルトの名無しさん
2006/05/13(土) 20:25:00大規模なのは知らんが。ギガビット ROM 程度でやってるうちの会社じゃ問題ないよ
0653デフォルトの名無しさん
2006/05/13(土) 21:39:04何か根本的におかしい気がするんだが
0654デフォルトの名無しさん
2006/05/13(土) 21:44:30整数いっこをラップした固定小数点数クラスの配列を
ROM に格納したいと考えるのはおかしくないよね？
0655デフォルトの名無しさん
2006/05/14(日) 08:56:07コンストラクタ呼び出しのある場合は、
コンパイラ判断難しいよね。>>651
0656デフォルトの名無しさん
2006/05/14(日) 09:24:01どういう場合を言ってるのかわからない。
0657デフォルトの名無しさん
2006/06/02(金) 08:30:44基本的にスピードの点では配列と変わらないと考えて良いのでしょうか？
0658デフォルトの名無しさん
2006/06/02(金) 09:25:29そういう実装もできるのは確か。
しかしスピードは実測が基本。
0659デフォルトの名無しさん
2006/06/09(金) 13:52:03VCではループやgotoをインライン展開できるのですか？
BCCでは「for while goto switch 一部のif」は
インライン展開しませんが、VCはやっちゃってくれてるんですかね！？
インライン警告が出ないので本当にインライン化されているか不明なんで聞いてみました。
0660デフォルトの名無しさん
2006/06/09(金) 18:15:25インライン展開するほうがよいとコンパイラが判断すればインライン展開される。
そこにループだろうと何だろうとがあろうとも。
0661デフォルトの名無しさん
2006/06/09(金) 19:48:36神ですな
0662デフォルトの名無しさん
2006/06/09(金) 19:56:340663デフォルトの名無しさん
2006/06/10(土) 16:42:00static unsigned int aryA[ 1024 ];
void radixSort( unsigned int *src, unsigned int num )
{
unsigned int aryB[ 1024 ];
...
//細かい突っ込み禁止
}
みたいな時にAとBで速度が違うんだけど、
Aが速かったりBが速かったりするんだよね。
スタック領域か、静的領域かの違い(?)だと思うんだけどさ、
要素数は少ないことが分かってるんだけど、
どっちがいいのかねぇ。
個人的にはstaticの方がいいような気がするんだけどさ、
いや、マルチスレッドだと使えないのは分かってるけどさ、
最適化って難しいねぇ。
0664デフォルトの名無しさん
2006/06/10(土) 16:51:520665デフォルトの名無しさん
2006/06/10(土) 17:01:120666デフォルトの名無しさん
2006/06/10(土) 17:03:38確かに知識はないさ、趣味だし。
でも知識がなくても最適化の必要性とは関係ないしな。
もっと生産的なレスを頼むよ。
0667デフォルトの名無しさん
2006/06/10(土) 17:27:28つ関数内静的(Static)変数
それはともかく、自分でアセンブリ出力を見比べてみたらどうだ？
0668デフォルトの名無しさん
2006/06/10(土) 18:00:430669デフォルトの名無しさん
2006/06/10(土) 18:09:310670デフォルトの名無しさん
2006/06/10(土) 18:24:130671デフォルトの名無しさん
2006/06/10(土) 18:26:230672デフォルトの名無しさん
2006/06/10(土) 19:02:36確かに知識はないさ、趣味だし。
でも知識がなくても最適化の必要性とは関係ないしな。
もっと生産的なレスを頼むよ。
0673デフォルトの名無しさん
2006/06/11(日) 12:50:42俺もそんな知識はないが、そんなレスができる奴に惚れた
0674デフォルトの名無しさん
2006/06/12(月) 11:59:15そういう手間を惜しんでる奴が「生産性」とは片腹痛い
0675デフォルトの名無しさん
2006/06/12(月) 15:53:49バウンドチェッカ使ってるやつが多いのかね
0676デフォルトの名無しさん
2006/06/12(月) 15:57:470677デフォルトの名無しさん
2006/06/12(月) 16:05:500678デフォルトの名無しさん
2006/06/12(月) 16:07:39http://www.google.co.jp/search?hl=ja&q=%E7%B4%A0%E6%95%B0%E3%80%80%E9%AB%98%E9%80%9F%E3%80%80%E5%88%A4%E5%AE%9A&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=lang_ja
0679デフォルトの名無しさん
2006/06/12(月) 22:25:490680デフォルトの名無しさん
2006/06/29(木) 00:23:470681デフォルトの名無しさん
2006/06/29(木) 03:28:51includeが悪いと思う。importさえあれば。
( Objective-C にはimportがある...と聞いて色めき立ったが、
偽物だった.... )
0682デフォルトの名無しさん
2006/06/29(木) 03:34:40どういう条件で、なん%くらいちがうんかな。
ソート対象のデータの並びとか片よりとか、
何によって差が出るのかがはっきりしたら、
事前にデータを走査して、どっちを使うか決めたらいいんじゃなかろうか。
つか、基数ソートか。O(n)の走査も馬鹿にならんな。
aryAを使うようにするんなら、
void radixSort( unsigned int* src, unsigned int num, unsigned int* tmp )
見たく、作業用配列を外部から指定するようにしてもいいかもね。
0683デフォルトの名無しさん
2006/06/29(木) 04:09:420684デフォルトの名無しさん
2006/06/29(木) 06:39:52どっちが速いの？
0685デフォルトの名無しさん
2006/06/29(木) 08:39:55ぶっちゃけアドレスの計算は関係ない。
むしろキャッシュの効きの問題で静的領域とスタック領域を
交互にアクセスしたりすると最悪。
0686デフォルトの名無しさん
2006/06/29(木) 10:54:40それいつの時代のコンパイラ?
0687デフォルトの名無しさん
2006/06/29(木) 11:35:360688デフォルトの名無しさん
2006/06/29(木) 11:53:26いつの時代だろうと、スタックフレームからのオフセットを
ループ内で何度も計算しなおすコンパイラなどありません。
0689デフォルトの名無しさん
2006/06/29(木) 12:21:418080用のCあたりかと
0690デフォルトの名無しさん
2006/06/29(木) 13:42:38最適化のないコンパイラ、普通にあったよ。
そもそもが自分で色々やるための
算術可能なポインタ, ++/--, registerだったわけだし。
0691デフォルトの名無しさん
2006/07/07(金) 13:02:30なにかが錯綜してる。。。。。
0692デフォルトの名無しさん
2006/07/07(金) 13:04:420693デフォルトの名無しさん
2006/08/13(日) 03:24:29部分的特殊化によるループ展開やら
戻り値最適化関数やら用意してやってたんだ。
ところがほとんど効果がないのな。最高でも１０％ぐらいしか差がでない。
で、VC8でSSE2オプション指定したら
１００倍早くなって腰がぬけそうになった。
ついでに俺がガリガリ最適化したコードと
普通に二重ループするコードの速度差がなくなった(A')
0694デフォルトの名無しさん
2006/08/14(月) 03:46:540695デフォルトの名無しさん
2006/08/14(月) 04:59:380696デフォルトの名無しさん
2006/08/14(月) 07:29:23ハードウェアが一緒で変わらないままなのに速度が１００倍も
違うなら、最適化で消えていった部分とかあるんだろ。
常識で考えろ。
0697デフォルトの名無しさん
2006/08/14(月) 08:59:09SSE2の有無が違うだろ。
0698デフォルトの名無しさん
2006/08/14(月) 09:07:470699デフォルトの名無しさん
2006/08/14(月) 09:13:02でもSSE1からSSE2で100倍はあまりなさそう。ありえなくはないけど。
展開したコードを見たのか？って聞くのは間違ってないが
とりあえず696は今すぐアナルうｐ
0700デフォルトの名無しさん
2006/08/14(月) 09:19:330701デフォルトの名無しさん
2006/08/14(月) 21:36:48こっちのほうが技術レベルが高そうなので質問をさせてください
一般的にマルチスレッドを使っていると変数がレジスタに
割り当てられにくくなるかと思いますが、GC機構を採用している
C#やJavaなどはある変数を参照している部分がそのローカル関数内に
限定することができないので最適化が発揮しづらくなるのじゃないかと思います
しかしながらC#や最近のJavaは、C++の速度に匹敵するといわれています。
それはどうしてですか？
0702デフォルトの名無しさん
2006/08/14(月) 21:40:23>割り当てられにくくなるかと思いますが
何故？
0703デフォルトの名無しさん
2006/08/14(月) 21:49:52あるんだろう？
FPUを使ってエミュレートすれば100倍も差が付かないと思うんだが。
0704デフォルトの名無しさん
2006/08/14(月) 22:11:020705デフォルトの名無しさん
2006/08/14(月) 22:15:04マルチスレッドを使っているプログラムだと
同時に2カ所から同じ変数にアクセスされる可能性があるから
必然的に変数をレジスタに割り当てることができない。
ついでにいうとヒープ上にしかインスタンスを確保できない言語の場合は
どうがんばっても微々たる最適化しかできないと思うんだが
俺の認識がちがうのか・・・？
0706デフォルトの名無しさん
2006/08/14(月) 22:28:000707デフォルトの名無しさん
2006/08/14(月) 22:30:240708デフォルトの名無しさん
2006/08/14(月) 22:32:36話の前後はまったく繋がってないわ。1文がやたらと長いわ。
まったく意味が理解できないんだけど。
0709701
2006/08/14(月) 23:09:48誤解されているようだが、コンテキストスイッチの話をしているわけではないぞ。
最適化してコンパイルすると、メモリ上においておける変数は
極力レジスタに割り付けるようになっていると思うんだが、
それはスタック上に割り当てられた変数にしかできないよな？
C++/CLIのマネージ変数のように、強制的にヒープ上に配置される言語で
なぜC++並の最適化が可能なのか？
って質問かいただけ
0710701
2006/08/14(月) 23:10:41誤 ： 最適化してコンパイルすると、メモリ上においておける変数は
正 ： 最適化してコンパイルすると、レジスタ上においておける変数は
0711デフォルトの名無しさん
2006/08/14(月) 23:21:00マルチスレッドでも、関数のローカル変数はスレッド間で共有されないと考えてよいだろう。
となればそれはレジスタに割り当てて問題ない。
残るはグローバル・静的変数だが、こいつらはシングルスレッドでもレジスタに割り当てられることは無いだろう。
また、ヒープ上へ動的に作成するオブジェクトもあるが、これも当然レジスタには割り当てられない。
つまりマルチスレッドだから変数がレジスタに割り当てられにくくなるというのは間違い。
また、JavaもC#もたしかにGCを採用しているが、どちらもint等の基本的な型のオブジェクトに対しては、
（概念上）スタックに割り当てている。最適化でレジスタに割り当てることはC++同様できるはずだ。
Java/C#でヒープ上に割り当てられるのは主にクラス型のオブジェクトということになるが、
クラス型のオブジェクトは大抵レジスタに収まらない大きさになるので、
C++でローカル変数だったとしてもやはりレジスタに載らないことに変わりは無いだろう。
クラス作ってそれを操作するくらいのことなら、C++/Java/C#で表現できることに大差はないので、
最適化に関しては、どれも同じ性能になって当然。JITの手間やヒープからメモリを確保するのがせいぜいのオーバーヘッド。
最近になってJava/C#の最適化技術がC++のそれに追いついてきたという感じかな。
0712デフォルトの名無しさん
2006/08/14(月) 23:22:17で、その話がマルチスレッドだとレジスタ割付がしにくいという主張と何か関係あるのか？
それは単にHeap AllocationとStack Allocationの違いを話しているようにしか見えんのだが。
0713デフォルトの名無しさん
2006/08/14(月) 23:56:11void function()
{
static int number=0;
number = ・・・ // いろいろ計算
}
のようにスタティック変数で宣言したものはレジスタに割り当てられないという
ことでしょうか
これがシングルスレッドのコードであることが明示的に指定されて
いればnumberを計算の間はレジスタに割り当てておけると思うのだけれど
現在の最適化はそこまで進んでないってことですね。
マルチスレッドだとレジスタ割り付けがしにくいのでは？という理屈は
このあたりから来てます。
つまりC++とC#/Javaなどの最適化性能に大きな差がない理由というのは
・C#/Javaなどでも基本的な型はスタック上に配置される
・C++でも実際には様々な条件のそろった変数しかレジスタ割り付けされない
・JITの最適化技術の進歩
この３点に尽きるという感じなのかな・・・？
0714デフォルトの名無しさん
2006/08/15(火) 00:04:20考えていました。
なので一回変数にアクセスするたびにメモリアクセスが必要になり
C++と比べて速度が遅いはず
と勘違いしておりました。
実際問題ベンチマークテストしてみても大差がないことを確認しているので
不思議に思って質問したわけです。
0715デフォルトの名無しさん
2006/08/15(火) 00:06:06C#なら、IDEからアセンブリとMSILの混合画面を見れるよ。
最適化してもデバッグにしておけばOK。
0716デフォルトの名無しさん
2006/08/15(火) 00:12:17そのnumberがfunction内にいる間レジスタに置かれるということは有り得る。
逆にそうさせないためのvolatileというキーワードがあることだし。
そして、それがC++にできてJava/C#にできないわけがない。
0717デフォルトの名無しさん
2006/08/15(火) 00:36:45> GC機構を採用している
> C#やJavaなどはある変数を参照している部分がそのローカル関数内に
> 限定することができないので最適化が発揮しづらくなるのじゃないかと思います
勝手に思ってろ呆け
0718デフォルトの名無しさん
2006/08/15(火) 00:42:04.Netは若干まだ勉強中のためそんな機能があるとは知りませんでした。
ありがとうございます。
スレ違いになりそうなのでC#の話題はこれくらいでやめておくとして
>>716
のような話があるから最適化してスレッドを使うときは気をつけなければ
いけないわけですが、C#/Javaではそこまでの最適化は行われていないのか
上記の問題はおきていませんよね
iccなどのちゃんとしたコンパイラを買えばC++でも心配無用なのかな
時間とれるときに自動変数、スタティック変数、グローバル変数などで
違うコードが出力されるのかどうか試してみます。
0719デフォルトの名無しさん
2006/08/15(火) 00:44:29市ね呆け
0720デフォルトの名無しさん
2006/08/15(火) 00:52:18馬鹿の考え休むに似たり
0721デフォルトの名無しさん
2006/08/15(火) 00:53:29IBMのサイト辺りで勉強して。
0722デフォルトの名無しさん
2006/08/15(火) 01:05:36普通クリティカルセクションか何か排他制御するところだろ。
0723デフォルトの名無しさん
2006/08/17(木) 04:58:09人間だと思ってるんだろうけど、これまでのやりとりを見る限りそれはないか
らもうちょっと態度考えた方がいいと思う。
もし君が国立の学部生なら、周りにこの程度のこと説明できるやつ絶対いるは
ずなんでまずはそのひとに聞いていろいろ教わった方がいいと思う。ネットの
書き込み経由で勉強するには少し頭が悪い気がするので。
0724デフォルトの名無しさん
2006/08/21(月) 00:30:030725デフォルトの名無しさん
2006/08/21(月) 01:46:410726デフォルトの名無しさん
2006/08/22(火) 21:42:49プログラミングは想像や心配じゃなくて言語仕様やら実行環境の仕様や実装を元にして行った方がいいですよ。
マルチスレッド、マルチCPU、マルチコアのプログラムを書くときには、例えば最近のJava ならJSR-133に従う、
アセンブラやC++ の場合はIntelのItanium なら "A Formal Specification of Intel(R) Itanium(R) Processor
Family Memory Ordering"、というようにそのCPUのメモリモデルに従う、
C# (CLR) の場合にはECMA CLI specificationのPartition IのSection 12.6に従う、という風に。
0727デフォルトの名無しさん
2006/08/25(金) 00:10:58そもそもクロック単位の話をするのは最後の手段。
ここにいる奴らは当然アルゴリズムを極限まで最適化したうえで
話をしているんだよな？
0728デフォルトの名無しさん
2006/08/25(金) 00:53:430729デフォルトの名無しさん
2006/08/25(金) 02:06:170730デフォルトの名無しさん
2006/08/25(金) 09:22:05ジャンプの漫画じゃあるまいし。
0731デフォルトの名無しさん
2006/08/25(金) 10:07:470732デフォルトの名無しさん
2006/08/25(金) 10:43:420733デフォルトの名無しさん
2006/08/27(日) 00:43:480734デフォルトの名無しさん
2006/08/27(日) 07:12:410735デフォルトの名無しさん
2006/09/18(月) 14:34:08同じ計算をする場合、float と double のどちらの型を使うほうが高速でしょうか？
0736デフォルトの名無しさん
2006/09/18(月) 14:36:27速度は実測が基本。
0737デフォルトの名無しさん
2006/09/18(月) 14:43:190738デフォルトの名無しさん
2006/09/18(月) 15:34:520739デフォルトの名無しさん
2006/09/18(月) 15:46:30__declspec(noinline)
double Func1(void)
{
double sum = 0;
for (int i = 0; i < COUNT; i++) {
sum += sin(sum) + cos(sum);
}
return sum;
}
__declspec(noinline)
float Func2(void)
{
float sum = 0;
for (int i = 0; i < COUNT; i++) {
sum += sin(sum) + cos(sum);
}
return sum;
}
0740デフォルトの名無しさん
2006/09/18(月) 15:54:46計算時間の殆どがsin()とcos()に取られそうだが。VC2005なら
sinf()とcosf()を使うと違ってくるんでないかい？
0741デフォルトの名無しさん
2006/09/18(月) 16:45:50> とりあえずこういうコードで試してみたら、速度はほとんど同じだった。
「どちらも一瞬で終わりました」だったらｳｹﾙｗ
0742デフォルトの名無しさん
2006/09/18(月) 16:47:26どうせアセンブラ厨が自己満足のために立てたんじゃないか？ｗ
0743デフォルトの名無しさん
2006/09/18(月) 17:30:49いやvectorは仕様できまってるはずでは。
0744デフォルトの名無しさん
2006/09/18(月) 17:32:46それはメモリレイアウトが決まっているって話だろ。
メンバ関数やイテレータでどれだけのオーバーヘッドが加わるかは実装依存。
0745デフォルトの名無しさん
2006/09/18(月) 18:49:30まぁ、どうせそれで速度が決まるわけではないし。
0746デフォルトの名無しさん
2006/09/18(月) 19:29:44ttp://www.tietew.jp/cppll/archive/11793
0747デフォルトの名無しさん
2006/09/19(火) 11:59:49double
0748デフォルトの名無しさん
2006/10/07(土) 00:31:02int32_t min9( int32_t a, int32_t b ) {
return b-((b-a)&(-(a<b)));
}
ついでに、min6 のコンパイラがはいたコードみてて思いついたやつ。
int32_t min10( int32_t a, int32_t b ) {
return (&a)[a<b];
}
呼び出し規約依存の上にコンパイラにインライン展開されると死ねる。
ていうか、min6 がインライン展開されるとこいつになるのか、、、
0749デフォルトの名無しさん
2006/10/08(日) 15:45:360750デフォルトの名無しさん
2006/10/26(木) 16:01:120751デフォルトの名無しさん
2006/10/26(木) 16:07:54どのみちFPU上ではdoubleだったりそれ以上に変換されるんでどっちでも大差ないとか
最近のCPUだとCPUの演算速度よりメモリのアクセス速度のほうが重要なんで
それなりにでかい配列とかだとメモリ消費量の少ないfloatのほうが有利とか。
0752デフォルトの名無しさん
2006/10/26(木) 20:01:180753デフォルトの名無しさん
2006/11/08(水) 01:31:18D3DXVec4Normalizeのほうが早くてがっかり。
どうなってるんだと逆アセンブリ見たらD3DXのほうは3DNow使ってて、
使ってるCPUごとに命令セット変えてそうな感じだった(ジャンプテーブルをはさんでいる)
アセンブリを比較する限りだと
内積計算するためにfadd使いまくりだった点が決定的に違うのだけど
pfaccに相当する命令ってSSEには無いのかな
0754753
2006/11/08(水) 02:19:03内積で上手い手法は無いのかと探してたらIntelの最適化のpdfに乗ってたので
それいれたらアッサリD3DXより早くなってしまった…
やっぱりメモリオペランドを取り捲ってたのを取り払ったお陰なのかな？
0755デフォルトの名無しさん
2006/11/09(木) 21:39:500756デフォルトの名無しさん
2006/11/11(土) 08:08:09いや、ほんとたいしたもんじゃないす
擬似コードでアレですがこんな感じ(同意味のVC命令セット使ってます)
float4 dot( float4 v1, float4 v2 )
{
float4 t = mul(v1,v2);
float4 s = shuffle( t, t, SHUFFLE(2,3,0,1) ) + t;
return shuffle( s, s, SHUFFLE(0,1,2,3) ) + s;
}
float4 normal( float4 v )
{
float4 v2 = dot(v,v);
return mul( v2, rsqrt(v2) );
}
0757デフォルトの名無しさん
2006/11/11(土) 08:11:46float4 dot( float4 v1, float4 v2 )
{
float4 t = mul(v1,v2);
float4 a = shuffle( t, t, SHUFFLE(2,1,0,3) );
float4 b = shuffle( t, t, SHUFFLE(1,0,3,2) );
float4 c = shuffle( t, t, SHUFFLE(0,3,2,1) );
return t + a + b + c;
}
のほうが命令セットは多くてもペアリングできてるんで高速に動いてたような気はします
ちゃんと時間計っていませんが…
0758デフォルトの名無しさん
2006/11/11(土) 08:21:47float4 dot( float4 v1, float4 v2 )
{
float4 t = mul(v1,v2);
float s = t.x + t.y + t.z + t.w; // FPUで計算(これはやばかった)
return float4(s,s,s,s);
}
あと、>>756の方法だと精度が悪くて使い物にならないんで
午後こ～だのサイトにあるような精度向上をやってるんですけど
それをやった時点で3DNowの手法より遅くなってしまいました
3DNowは精度向上のための専用命令があるからその差がでかいのかな
0759デフォルトの名無しさん
2006/11/11(土) 12:24:06並列度上げないとまだ遅いんじゃないかね
0760デフォルトの名無しさん
2006/11/11(土) 13:27:41命令セットレベルで入れ替えしてくれるのかな？＞MSVC
でも正規化みたいな処理は突然1度だけ現れるみたいな処理がほとんどなので
あんまりそういう最適化を期待してもなぁ…っていう感じではありますが
0761デフォルトの名無しさん
2006/11/11(土) 14:44:390762デフォルトの名無しさん
2006/11/14(火) 03:07:13トータルで見たら何度も呼ばれるけど
その関数が局所的に何度も呼ばれることが無いって話ですよ。
0763デフォルトの名無しさん
2006/11/22(水) 04:12:540764デフォルトの名無しさん
2006/11/22(水) 04:23:220765デフォルトの名無しさん
2006/11/23(木) 09:38:42上手くすればレジスタ間のみの演算で済む。
グローバル変数にすると、必ずメモリ間のやりとりが
はいるので、その転送時間は相当に大きい。
局所的にしか使わない変数がある場合は
適当にブロック作って
ブロック内先頭で変数宣言して使ったりすることもある。
0766デフォルトの名無しさん
2006/11/23(木) 12:11:04＞適当にブロック作って
まあ、最適化にはあんまり関係ないけどな。
0767デフォルトの名無しさん
2006/11/23(木) 12:16:55> グローバル変数にすると、必ずメモリ間のやりとりが
> はいるので、その転送時間は相当に大きい。
いつのコンパイラやねん。
90年代はじめにはそんなコンパイラ淘汰されたわ。
0768デフォルトの名無しさん
2006/11/23(木) 12:20:36c++だとデストラクタ呼び出しのタイミングが変わるから
スタック消費量が変わるぞ
とはいえそれくらいか
0769デフォルトの名無しさん
2006/11/23(木) 12:22:36その場合はオブジェクトへのアクセスがあるんだから
最適化にならないでしょｗｗ
0770デフォルトの名無しさん
2006/11/23(木) 12:40:56関数内のブロックに入ったり出たりするタイミングで、ローカル変数の領域を、
縮めたり延ばしたりするコンパイラって、あんまりないとおもうぞ。
0771デフォルトの名無しさん
2006/11/23(木) 13:21:37Cの頃から再利用するコンパイラはあるよ。
func1()
{
{
A a1;
}
{
A a2;
}
}
func2()
{
A a1;
A a2;
}
func1のほうがスタック消費量は少ない。
スタック消費量が少ない＝キャッシュヒット率向上ってことで。
0772デフォルトの名無しさん
2006/11/23(木) 13:58:530773デフォルトの名無しさん
2006/11/23(木) 14:03:110774デフォルトの名無しさん
2006/11/23(木) 14:04:53you mean assembler?
0775デフォルトの名無しさん
2006/11/23(木) 15:56:440776デフォルトの名無しさん
2006/11/23(木) 16:46:18gccで簡単なコードを書いて見てみたけど、そんなことはやってなかったなぁ。。。
そういう最適化をする条件って、なにかあるの?
0777デフォルトの名無しさん
2006/11/23(木) 17:09:320778デフォルトの名無しさん
2006/11/23(木) 17:20:24領域の再利用ってことか。
まあ、でも、うちの環境で簡単なコードを書いてもぜんぜんかわらなかったな。
ローカル変数がデカかったりしたら、そういう最適化でもするのかね?
0779デフォルトの名無しさん
2006/11/23(木) 18:05:390780デフォルトの名無しさん
2007/01/06(土) 18:20:570781・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6
2007/01/06(土) 18:29:26関数の先頭でスタックに全部確保しちゃう。
動的オブジェクトのデストラクタの呼び出しのタイミングと変数のスコープだけは変わるだろうけど。
0782・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6
2007/01/06(土) 18:32:17実行クロック数を計測する。
キャッシュに収まってるか収まってないかでレイテンシの桁が違うはずなのでよくわかると思うけど。
0783デフォルトの名無しさん
2007/01/06(土) 18:47:31団子ちゃん、どうしてそんなこと知ってんの？
0784・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6
2007/01/06(土) 18:49:520785デフォルトの名無しさん
2007/01/06(土) 18:56:15変わるよ。
0786デフォルトの名無しさん
2007/01/06(土) 18:56:45単に、アセンブラの結果を見て、たまたまそーなってたってこと？
それじゃ、必ずしも >>781 のようなことになるとは限らんってことでおk？
0787・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6
2007/01/06(土) 19:03:460788デフォルトの名無しさん
2007/01/06(土) 19:06:340789デフォルトの名無しさん
2007/01/06(土) 19:10:282003でも違う結果になる可能性が十分にあると思うんだけど。
0790デフォルトの名無しさん
2007/01/06(土) 19:39:370791デフォルトの名無しさん
2007/01/06(土) 20:09:23>>781 の最後の一行に関しての話なら、C++として当たり前の挙動。
0792デフォルトの名無しさん
2007/01/06(土) 21:50:37変わるのはスタック消費量。
0793デフォルトの名無しさん
2007/01/06(土) 21:54:55じゃぁ、団子ちゃんが適当なこと吹いてたってことでFA？
0794・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6
2007/01/06(土) 21:57:57とりあえず配列なんだけど
0795・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6
2007/01/06(土) 23:09:210796デフォルトの名無しさん
2007/01/06(土) 23:16:22別々ってどういう意味？
スタックの消費量が実は変わってましたって話？
0797・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6
2007/01/06(土) 23:36:530798デフォルトの名無しさん
2007/01/06(土) 23:40:55vc2005では再利用しない
0799デフォルトの名無しさん
2007/01/06(土) 23:40:570800デフォルトの名無しさん
2007/01/06(土) 23:42:02g++はする
vc(2003/2005)はc/c++どちらもする
面白い
0801デフォルトの名無しさん
2007/01/08(月) 11:53:263つ以上、思い当たる点があればアナタの性格はひん曲がっており、ネガティブ負け組人生を歩んでいます。
□偽装派遣先の社員の意見にはたとえ間違っていても反対しない
□偽装派遣先から「いつまでもここで仕事してくださいね」と言われるようになりたい
□自社に仕事を持ち帰れるように言われるとムカつく
□自社で仕事なんてできるわけがない
□派遣/受託の差異を指摘する人間はムカつく
□偽装派遣先には仕事だけでなく自分のプライベートについても指示して欲しい
□自分の月額金額を知らない
□偽装派遣先社員より自分の生涯収入が低いのは当然だ
□偽装派遣先に尻尾を振り、いつまでも一緒に仕事をすることが大切だ
□今のプロジェクトが終わっても同じ偽装派遣先に常駐したい
0802デフォルトの名無しさん
2007/01/08(月) 12:54:39C++はデストラクタ呼び出しの順番があるから明示されたけども
0803デフォルトの名無しさん
2007/01/08(月) 19:58:00constならどこで宣言してもプログラム内では単に定数になるだけと思っていたのですが・・・
0804・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6
2007/01/08(月) 21:00:42自動変数にconstを付ける意味は、コンパイル時に書き換えやろうとしたらエラーや警告を出してくれるだけ。
あとはループの最適化指示とか。
0805デフォルトの名無しさん
2007/01/08(月) 21:00:530806・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6
2007/01/08(月) 21:43:550807デフォルトの名無しさん
2007/01/08(月) 21:58:37/* stack.c */
#include <stdio.h>
int main(int argc, char **argv) {
puts(argv[0]);
{
int a;
printf("%p ", &a);
} {
float b;
printf("%p\n", &b);
}
.
> cl
Microsoft(R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86
> gcc --version
gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
続く
0808デフォルトの名無しさん
2007/01/08(月) 22:00:21$ gcc stack.c -ostack.gccO0.exe
$ gcc stack.c -O2 -ostack.gccO2.exe
$ gcc -xc++ stack.c -ostack.g++O0.exe
$ gcc -xc++ stack.c -O2 -ostack.g++O2.exe
$ cl /TC stack.c /Festack.clOd.exe
$ cl /TC stack.c /Ox /Festack.clOx.exe
$ cl /TP stack.c /Festack.cl+Od.exe
$ cl /TP stack.c /Ox /Festack.cl+Ox.exe
$ for o in gccO0 gccO2 g++O0 g++O2 clOd clOx cl+Od cl+Ox; do ./stack.$o.exe; done
./stack.gccO0
0x22cce4 0x22cce0
./stack.gccO2
0x22cce4 0x22cce0
./stack.g++O0
0x22cce4 0x22cce0
./stack.g++O2
0x22cce4 0x22cce0
stack.clOd.exe
0012FF6C 0012FF68
stack.clOx.exe
0012FF70 0012FF70
stack.cl+Od.exe
0012FF6C 0012FF68
stack.cl+Ox.exe
0012FF70 0012FF70
VC++2005EEはスタックを再利用する
gccは再利用しない -mno-cygwinもたぶんしない
0809・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6
2007/01/08(月) 22:05:07だんごさんは１関数内に変数が200以上あるソースを平気で触ります
0810807
2007/01/08(月) 22:24:55環境は一緒
/* stack2.c */
#include <stdio.h>
#define decl1(x) decl2(0##x) decl2(1##x) decl2(2##x) decl2(3##x) decl2(4##x) decl2(5##x) decl2(6##x) decl2(7##x)
#define decl0(x) decl1(0##x) decl1(1##x) decl1(2##x) decl1(3##x) decl1(4##x) decl1(5##x) decl1(6##x) decl1(7##x)
#define decl2(x) int a##x;
#define use1(x) use2(0##x) use2(1##x) use2(2##x) use2(3##x) use2(4##x) use2(5##x) use2(6##x) use2(7##x)
#define use0(x) use1(0##x) use1(1##x) use1(2##x) use1(3##x) use1(4##x) use1(5##x) use1(6##x) use1(7##x)
#define use2(x) ,&a##x
int main(int argc, char **argv) {
puts(argv[0]);
{
decl0(0);
printf("%08p %08p %08p %08p %08p %08p %08p %08p\n%08p %08p %08p %08p %08p %08p %08p %08p\n"
"%08p %08p %08p %08p %08p %08p %08p %08p\n%08p %08p %08p %08p %08p %08p %08p %08p\n"
"%08p %08p %08p %08p %08p %08p %08p %08p\n%08p %08p %08p %08p %08p %08p %08p %08p\n"
"%08p %08p %08p %08p %08p %08p %08p %08p\n%08p %08p %08p %08p %08p %08p %08p %08p\n" use0(0));
}
続く
0811807
2007/01/08(月) 22:26:43puts("");
{
decl0(1);
printf("%08p %08p %08p %08p %08p %08p %08p %08p\n%08p %08p %08p %08p %08p %08p %08p %08p\n"
"%08p %08p %08p %08p %08p %08p %08p %08p\n%08p %08p %08p %08p %08p %08p %08p %08p\n"
"%08p %08p %08p %08p %08p %08p %08p %08p\n%08p %08p %08p %08p %08p %08p %08p %08p\n"
"%08p %08p %08p %08p %08p %08p %08p %08p\n%08p %08p %08p %08p %08p %08p %08p %08p\n" use0(1));
}
}
$ cl /Ox stack2.c /Festack2.clOx.exe
$ gcc -O2 stack.c -ostack2.gccO2.exe
まだ続く
0812807
2007/01/08(月) 22:27:33$ ./stack2.clOx.exe
stack2.clOx.exe
0012FF70 0012FF68 0012FF60 0012FF58 0012FF50 0012FF48 0012FF40 0012FF38
0012FF30 0012FF28 0012FF20 0012FF18 0012FF10 0012FF08 0012FF00 0012FEF8
0012FEF0 0012FEE8 0012FEE0 0012FED8 0012FED0 0012FEC8 0012FEC0 0012FEB8
0012FEB0 0012FEA8 0012FEA0 0012FE98 0012FE90 0012FE88 0012FE80 0012FE78
0012FE74 0012FF6C 0012FEEC 0012FF2C 0012FEE4 0012FF4C 0012FEDC 0012FF24
0012FED4 0012FF5C 0012FECC 0012FF1C 0012FEC4 0012FF44 0012FEBC 0012FF14
0012FEB4 0012FF64 0012FEAC 0012FF0C 0012FEA4 0012FF3C 0012FE9C 0012FF04
0012FE94 0012FF54 0012FE8C 0012FEFC 0012FE84 0012FF34 0012FE7C 0012FEF4
0012FEF4 0012FE7C 0012FF34 0012FE84 0012FEFC 0012FE8C 0012FF54 0012FE94
0012FF04 0012FE9C 0012FF3C 0012FEA4 0012FF0C 0012FEAC 0012FF64 0012FEB4
0012FF14 0012FEBC 0012FF44 0012FEC4 0012FF1C 0012FECC 0012FF5C 0012FED4
0012FF24 0012FEDC 0012FF4C 0012FEE4 0012FF2C 0012FEEC 0012FF6C 0012FE74
0012FE78 0012FE80 0012FE88 0012FE90 0012FE98 0012FEA0 0012FEA8 0012FEB0
0012FEB8 0012FEC0 0012FEC8 0012FED0 0012FED8 0012FEE0 0012FEE8 0012FEF0
0012FEF8 0012FF00 0012FF08 0012FF10 0012FF18 0012FF20 0012FF28 0012FF30
0012FF38 0012FF40 0012FF48 0012FF50 0012FF58 0012FF60 0012FF68 0012FF70
さらに続く
0813807
2007/01/08(月) 22:29:07./stack2.gccO2
0x22cbe8 0x22cbec 0x22cbf0 0x22cbf4 0x22cbf8 0x22cbfc 0x22cc00 0x22cc04
0x22cc08 0x22cc0c 0x22cc10 0x22cc14 0x22cc18 0x22cc1c 0x22cc20 0x22cc24
0x22cc28 0x22cc2c 0x22cc30 0x22cc34 0x22cc38 0x22cc3c 0x22cc40 0x22cc44
0x22cc48 0x22cc4c 0x22cc50 0x22cc54 0x22cc58 0x22cc5c 0x22cc60 0x22cc64
0x22cc68 0x22cc6c 0x22cc70 0x22cc74 0x22cc78 0x22cc7c 0x22cc80 0x22cc84
0x22cc88 0x22cc8c 0x22cc90 0x22cc94 0x22cc98 0x22cc9c 0x22cca0 0x22cca4
0x22cca8 0x22ccac 0x22ccb0 0x22ccb4 0x22ccb8 0x22ccbc 0x22ccc0 0x22ccc4
0x22ccc8 0x22cccc 0x22ccd0 0x22ccd4 0x22ccd8 0x22ccdc 0x22cce0 0x22cce4
0x22cae8 0x22caec 0x22caf0 0x22caf4 0x22caf8 0x22cafc 0x22cb00 0x22cb04
0x22cb08 0x22cb0c 0x22cb10 0x22cb14 0x22cb18 0x22cb1c 0x22cb20 0x22cb24
0x22cb28 0x22cb2c 0x22cb30 0x22cb34 0x22cb38 0x22cb3c 0x22cb40 0x22cb44
0x22cb48 0x22cb4c 0x22cb50 0x22cb54 0x22cb58 0x22cb5c 0x22cb60 0x22cb64
0x22cb68 0x22cb6c 0x22cb70 0x22cb74 0x22cb78 0x22cb7c 0x22cb80 0x22cb84
0x22cb88 0x22cb8c 0x22cb90 0x22cb94 0x22cb98 0x22cb9c 0x22cba0 0x22cba4
0x22cba8 0x22cbac 0x22cbb0 0x22cbb4 0x22cbb8 0x22cbbc 0x22cbc0 0x22cbc4
0x22cbc8 0x22cbcc 0x22cbd0 0x22cbd4 0x22cbd8 0x22cbdc 0x22cbe0 0x22cbe4
おしまい
やっぱりVC++2005EEは再利用する、gccは再利用しない
// いや、こんな極端な例はないと思うけどさ。
// それよりもVC++で順番が入れ替わってるのが気になる
0814・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6
2007/01/08(月) 22:33:110815デフォルトの名無しさん
2007/01/08(月) 22:41:36遅いってのはマルチスレッド用ライブラリしかないってこと？
なんでANSIだけ遅いの？UNICODEとどう違う？
0816・∀・）っ-○◎●創聖のダンゴリオン ◆DanGorION6
2007/01/08(月) 22:48:41UNICODEに変換して処理するからっぽいけど、2003まではそんなことはなかった。
逆にUNICODE API利用時のパフォーマンスは上がってるっぽいのでまあ察しの通りでしょう
0817デフォルトの名無しさん
2007/01/08(月) 22:57:13????よくわからん
msvcr80.libのnarrow charの関数が内部でUNICODEに変換して～W()を呼び出すってこと？
それなら/MDでmsvcrt.dllにリンクすれば今までと変わらないよねぇ
出来れば簡単なベンチとテストソースキボン
0818デフォルトの名無しさん
2007/01/09(火) 01:02:28あんまり信用できんな
0819デフォルトの名無しさん
2007/01/09(火) 01:03:29俺は最初からあぼーん登録してる
0820`∀´>っ-○◎●創聖のケンチャナヨ ◆DanGorION6
2007/01/09(火) 01:04:300821デフォルトの名無しさん
2007/01/09(火) 01:15:06じゃぁ、今度から団子ちゃんじゃなくてケンチャンって呼ぶね♪
0822デフォルトの名無しさん
2007/01/09(火) 06:42:520823`∀´>っ-○◎●創聖のケンチャナヨ ◆ED.hORoNBU
2007/01/09(火) 23:15:190824デフォルトの名無しさん
2007/01/10(水) 20:37:26ANSI関数が遅いのは結局妄想？
0825デフォルトの名無しさん
2007/01/10(水) 23:23:25VCがスタック再利用しないってのは結局捏造？
0826`∀´>っ-○◎●創聖のケンチャナヨ ◆ED.hORoNBU
2007/01/11(木) 02:07:46http://d.hatena.ne.jp/NyaRuRu/20060227/p1
>>825
具体的にはhttp://www.darkside.com.au/bitslice/
のdesevalをforceinlineで全部変数展開して実行してる。
少なくともVC2003では超がつく糞コード吐く
0827`∀´>っ-○◎●創聖のケンチャナヨ ◆ED.hORoNBU
2007/01/11(木) 02:09:460828デフォルトの名無しさん
2007/01/11(木) 20:32:270829デフォルトの名無しさん
2007/01/12(金) 23:12:01> 超がつく糞コード吐く
かわいそう
0830デフォルトの名無しさん
2007/01/14(日) 09:23:370831デフォルトの名無しさん
2007/01/14(日) 12:22:25std::basic_string<TCHAR>で追試してみた。
CString::Formatの代わりにstd::basic_stringstream<TCHAR>::operator <<を使った場合(3000回ループ)
narrow
add: 2179, search: 11674
MBCS
add: 2365, search: 11947
UNICODE
add: 5894, search: 32096
std::snprintf/std::snwprintfを使った場合(150000回ループ)
narrow
add: 764, search: 1614
MBCS
add: 775, search: 1622
UNICODE
add: 1558, search: 2822
cl.exe ver14.00.50727.42 for 80x86
/O2 /GL /FD /EHsc /MT /GS- /TP
# いやー、sstream遅いねー、実測するとよくわかるや
# UNICODEはバイト長が単純に倍になるからその分不利なんだろーな
# ATLは使わないから知らん
0832デフォルトの名無しさん
2007/01/14(日) 12:37:46cppllあたりの過去ログでも嫁。
0833デフォルトの名無しさん
2007/01/14(日) 12:56:07下手でスマソ、cppllは最近登録したばっかだ
でもさ、operator <<(sstream &, int)に使い方も糞もあるの？
intから文字列へ変換する移植性のある方法ってsnprintfかoperator <<かboost::lexical_castくらいしかないよね？
それともresize()しとけってだけの話？
さらに追試
cl.exe ver13.10.3077 for 80x86
/O2 /FD /EHsc /M{L,T} /TP
/ML{add,search}, /MT{add,search}の順に
sstream
narrow
4420, 24104, 4382, 24183
MBCS
4286, 23185, 4415, 24319
UNICODE
6412, 32975, 6434, 35718
sprintf
narrow
997, 2021, 1001, 2038
MBCS
930, 1956, 1012, 2067
UNICODE
1413, 2628, 1761, 3735
# むしろこっちのほうが相対的にMBCS遅いんですが。
# sstreamだと特にひどい。しかも全体的に遅いし。
0834デフォルトの名無しさん
2007/01/14(日) 22:55:450835デフォルトの名無しさん
2007/01/22(月) 23:23:33>>53
1の開発環境はWindowsだと思うのでx86。
スタックポインタの場合、[esp-8]などと一発でアクセスできるが、
そうでない場合[eax]とアクセスする前にeaxにポインタを格納する手間が要る。
もしくは、eaxをポインタに占有されて使えるレジスタが減ってしまう。
60 名前： デフォルトの名無しさん [sage] 投稿日： 2007/01/22(月) 23:08:00
>>55
例えば mov edx,[MemAddress] と言う形式の指定方法があるので、
わざわざアドレスをレジスタにロードする必要は無い。
俺は55だが、なるほど、MemAddressは即値なのね。
あらかじめアドレスはわかってるようにできるものなの？
0836デフォルトの名無しさん
2007/01/22(月) 23:42:58命令が相対アドレス指定なら、リンカはそのまま値を確定してしまうし、
絶対アドレス指定命令の場合は、普通は実行形式にアドレス再配置
情報が記録されて、実行前にOSが絶対アドレスを全部補正するはず。
0837デフォルトの名無しさん
2007/01/22(月) 23:59:12アドレス再配置とかすごいな。
俺の方が勉強不足だったようだ。
質問になってしまうが、グローバル変数のアドレスを決めてしまって
mov edx,[MemAddress]式のアクセスで高速化というのは、あり？
0838デフォルトの名無しさん
2007/01/23(火) 00:08:10なったので、重くなったソフトを軽々と動かすためにCPUの
高速化が必要になった希ガスｗ
0839デフォルトの名無しさん
2007/01/23(火) 00:26:40それはレジスタに置いておく代わりに mov edx,[MemAddress] という事？
メモリから読む場合は、データをとってくるのに時間がかかったり制限も色々あるので、
出来る限りレジスタに残しておいたほうがいいと思う。
mov edx,[ebp-8]とどっちがいいかという話なら、実行コストはちょっと分からない。
詳しい実行コストが知りたいのなら↓のスレあたりが詳しいのでおすすめ。
x86命令の所要クロック計測スレPart3
http://pc10.2ch.net/test/read.cgi/tech/1168399966/
0840デフォルトの名無しさん
2007/01/23(火) 00:28:41あり、というより大抵のコンパイラ・リンカはそうしていると思う。
0841デフォルトの名無しさん
2007/01/23(火) 00:49:02いや、おいらはグローバル変数のアドレスは決まってないと思っていたので、
数字を決めておくのと決めないのと、どちらがいいのかと思って。
>>840ということなので、決めた方がいいようですね。
おいらはそのスレの住人なので、まず周辺を勉強し直してから測定してみまつｗ
>>839>>840ありがとうございました。
0842`∀´>っ-○◎●創聖のケンチャナヨ ◆ED.hORoNBU
2007/01/23(火) 01:48:46決まってる。
ただしプロセスローカルな仮想アドレスでの話だけど。
IA-32ではアドレス空間は仮想化されてて別々のプロセスでも同じアドレス値を持てる。
ただし他のプロセスのメモリ空間へは普通の方法では直接アクセスできない。
マルチスレッド化とか考えるなら、なるべく使わず自動変数とか、構造体を
アドレス渡しして操作したほうがいい。
多少命令長が増えるが[ecx+OffsetAddress] みたいな相対アドレス指定のほうが
何かと便利。
セットしたい値が決まってるなら即値使った方がいい。
これは特に意識しなくとも最適化でそうなるが。
なによりグローバル変数はバグの根源。定数ならまだいいが。
0843デフォルトの名無しさん
2007/01/23(火) 07:27:26ちょっと整理しておこうか。
・ローカル変数はスタックに置かずにレジスタに置くかも知れない。
・グローバル変数は(必要となる範囲の先頭で)レジスタに保持してしまうかもしれない。
#一般的に最適化は関数単位だから、関数脱出までには書き戻すはずだが。
従って、グローバル変数だから速いとか遅いとか、一概には言えない。
また、関数への引き渡しに際しても、インライン展開できるコンパイラでは
呼び出し元のローカル変数をレジスタにキープしたまま呼び出し先で参照するかもしれない。
この点でも、グローバル変数の方が速いとは言えなくなる。
0844デフォルトの名無しさん
2007/01/23(火) 12:01:11キャッシュヒット率が高いことが期待できるよ。
もはやこっちのほうが重要。
あと命令長は考えても無駄。
0845デフォルトの名無しさん
2007/04/05(木) 08:58:10書かなければならない場合、最初に持ってきた方がよいのですか？
それとも最後に持ってきた方がよいのでしょうか？
0846デフォルトの名無しさん
2007/04/05(木) 09:41:470847デフォルトの名無しさん
2007/04/06(金) 09:01:450848デフォルトの名無しさん
2007/04/06(金) 09:19:480849デフォルトの名無しさん
2007/04/06(金) 10:09:060850デフォルトの名無しさん
2007/04/06(金) 21:26:51IntelのCPUならこれを読め
IA-32 インテル(R) アーキテクチャー最適化リファレンス・マニュアル
http://download.intel.com/jp/developer/jpdoc/IA32_Final_i.pdf
2-14 静的予測
0851デフォルトの名無しさん
2007/04/06(金) 21:27:31って言うと来てくれるよ
0852`∀´>っ-○◎●
2007/04/06(金) 21:42:240853デフォルトの名無しさん
2007/04/06(金) 23:32:040854デフォルトの名無しさん
2007/04/07(土) 08:22:55賢いコンパイラは何故無いのでしょうか？
0855`∀´>っ-○◎●
2007/04/07(土) 08:26:37どこのロートルがそんなこと言ったのよ
そんなんでコードの効率が変わるようなコンパイラなんていまどき有りません
0856デフォルトの名無しさん
2007/04/07(土) 09:05:33逆に寧ろ、a = a + 1とa++で違うコードを吐くコンパイラをご存知なら教えてください。
って言ってやれ。
0857デフォルトの名無しさん
2007/04/07(土) 14:29:030858`∀´>っ-○◎●
2007/04/07(土) 14:45:42実際は最適化を阻害するんだが。
0859デフォルトの名無しさん
2007/04/07(土) 14:46:04a++より++aの方が速い。
賢いコンパイラなら変わらないかもしれないが。
0860デフォルトの名無しさん
2007/04/07(土) 14:58:06組み込み型に限って言うなら、
a++; と ++a; で違うコード吐くコンパイラ知らない。
b = a++; と b = ++a; なら違うだろうけど。
0861デフォルトの名無しさん
2007/04/07(土) 15:15:440862`∀´>っ-○◎●
2007/04/07(土) 15:20:57ねーよｗｗｗｗｗｗｗ
0863デフォルトの名無しさん
2007/04/07(土) 16:36:01+= -> 文字列の結合
だったとしたらどうするつもりだ。
0864デフォルトの名無しさん
2007/04/07(土) 17:05:39前置でいいところは前置で書くべきだな。
ループはwhile(a++ < b)よりもwhile(++a <= b)にすべきだな。
0865`∀´>っ-○◎●
2007/04/07(土) 18:48:200866デフォルトの名無しさん
2007/04/08(日) 02:29:280867`∀´>っ-○◎●
2007/04/08(日) 09:52:110868デフォルトの名無しさん
2007/04/08(日) 22:41:280869デフォルトの名無しさん
2007/04/08(日) 22:49:200870デフォルトの名無しさん
2007/04/09(月) 00:44:12今のは複雑らしいから大変だろうねぇ
0871デフォルトの名無しさん
2007/04/09(月) 11:11:42>a++が++aより速くなる可能性は0だから
それが式中ではなく単体で使われてれば、
a++が++aより遅くなる可能性も殆どないですが。
0872デフォルトの名無しさん
2007/04/09(月) 15:16:02可読性を落とさずに速くなる可能性があるんだから、a++を使う意味もないだろう。
ユーザ定義型だと最適化も期待できないし、前置++を使う癖を付けておくことは
悪くないと思うけどな。
0873デフォルトの名無しさん
2007/04/09(月) 21:38:19inc(a)よりa.inc()の方が分りやすいと思うのは日本人の性？
0874デフォルトの名無しさん
2007/04/09(月) 21:57:190875デフォルトの名無しさん
2007/04/09(月) 22:15:28そういう合目的的でない直感を排していけない人は、
プログラマに向いてないと思う。いつか必ず落とし穴になる。
0876`∀´>っ-○◎●
2007/04/09(月) 23:39:330877873
2007/04/10(火) 00:28:30A(B(C(D(E(f), g, h)), k))
とかなってると括弧の対応がエディタの機能に頼らないと分らなくね？
対応している括弧が分っても引数が何処の関数に所属しているか戸惑う。
実際の解決はだらだら全部の処理の行を分けて記述する事になるんだが、
f.E().D(g, h).C().B(k).A()
という表記が出来た方がいくらかマシだなあと。
あくまで例だからな。本当にそんな実装するくらいならx86のfvecみたいに演算子作る。
0878873
2007/04/10(火) 00:39:03でもa.inc()がaを1だけインクリメントしてくれるとした場合
a++ + bとa.inc() + bは結果が異なるから本当にだだだな。
どうみても妄想です、本当に(ry
0879デフォルトの名無しさん
2007/04/10(火) 00:42:13inc(a)とa.inc()の違いって
全然違うところに無いか？
0880879
2007/04/10(火) 00:42:59スマソ
0881`∀´>っ-○◎●
2007/04/10(火) 00:44:48__m128i tmp = _mm_load_si128( &a[i] );
とかやるじゃん
a => eax
i => edx
とするとx86のアドレッシングモードに、「16倍」って無いから、
shr edx, 4
movdqa xmm0, [eax + edx]
とかいちいちやんないといけないのよね。
だから、添字じゃなくてポインタとかをバイト数のオフセット値として持ったほうが効率いいんだけど
_mm_load_si128( (__m128i)(((char*)a) + offset) );
てらめんどくさす('A`)
0882デフォルトの名無しさん
2007/04/10(火) 01:05:16C++なら適当なメンバ関数でreturn *this;しとけば大体希望通りの記述が出来るんじゃないか。
intrinsics＋inlineならパフォーマンス上のペナルティもないし。
0883デフォルトの名無しさん
2007/04/10(火) 03:09:04"パースエラー" の検索結果 約 35,100 件中 1 - 10 件目 (0.14 秒)
0884デフォルトの名無しさん
2007/04/10(火) 08:37:08辞書引くとどっちの発音でもいいみたいだが...
0885デフォルトの名無しさん
2007/04/10(火) 09:18:51カーネルサンダーズ
0886デフォルトの名無しさん
2007/04/10(火) 09:21:42ただ慣用から外れた表記で己を誇示するのはどうかと
それが団子クオリテイか
0887デフォルトの名無しさん
2007/04/10(火) 10:44:030888`∀´>っ-○◎●
2007/04/10(火) 21:53:370889デフォルトの名無しさん
2007/04/11(水) 13:01:480890デフォルトの名無しさん
2007/04/11(水) 17:51:00エラない状態で指定してもあぼーん出来ません。
レスはたとえばhttp://pc11.2ch.net/test/read.cgi/tech/1084676298/888とか
0891デフォルトの名無しさん
2007/04/11(水) 17:52:170892( ・～・）－◎○－m
2007/04/11(水) 18:07:040893デフォルトの名無しさん
2007/04/12(木) 03:44:26書くと対策しやがるから書かないでおくが・・
0894デフォルトの名無しさん
2007/04/12(木) 13:16:57SSEに優しい、コードの書き方とかってどこかに解説されていませんか？
0895デフォルトの名無しさん
2007/04/12(木) 13:25:40どれだったか思い出せない
0896デフォルトの名無しさん
2007/04/12(木) 18:14:38これじゃないか？
0897デフォルトの名無しさん
2007/04/12(木) 18:36:09ttp://download.intel.com/jp/developer/jpdoc/apps_simd_j.pdf
0898デフォルトの名無しさん
2007/04/12(木) 20:35:04変態c++テンプレート希望
0899デフォルトの名無しさん
2007/04/13(金) 06:42:08CClass a[100]；
の様なやり方が、自然ですが、SoAとOOPをうまく融合する方法はないでしょうか？
0900デフォルトの名無しさん
2007/04/13(金) 09:43:33オブジェクト指向的には、複数のオブジェクトの集まったオブジェクトとして扱うとか。
0901デフォルトの名無しさん
2007/04/13(金) 09:50:590902デフォルトの名無しさん
2007/04/13(金) 09:54:260903デフォルトの名無しさん
2007/04/13(金) 14:56:31ほとんどの演算をSIMDで行わないと
mmx(xmm)←→汎用レジスタの変換に時間取られるから、
データの並びをSoAにするだけじゃダメなわけだし。
0904( ・～・）－◎○－m
2007/04/13(金) 16:22:170905デフォルトの名無しさん
2007/04/14(土) 00:26:23でも、pextrwとかばっかり使ってるとやっぱおそいっしょ。
普通のクラスってintとかbyteとかを混在して持ってるから、
クラスの並びを CClass[250][4] (>>899から) とかにするだけじゃうまくいかないと思うんだよな。
SoAで大切なのは、SIMDで素直に扱える型を実現することだから、
結局CClass側でも、float[4]やdouble[4]を持つ、もしくはfloatやbyteのみ持つ
とかの工夫をしないといけないだしょ？
そうすると、なんというか、
CClassのもつデータによってClass[500][2]とかClass[125][8]とか分割の仕方を変えないといけないし、
どんなクラスでも適切にSoA型に並べる汎用コンテナクラスを作るのはちょっと難しいと思う。
あと、与えられるクラスの条件もかなり厳しくなるはず。
(もてるデータはPODのみとか、vtableが必要になる継承は禁止とか……)
結局、SIMDで演算させるためには設計の段階からデータ配置を意識しないといけない。
そう考えるとfvec.hやdvec.hにあるクラスを最初から使うのが
手軽で分かりやすいということになると思うんだよな。
0906デフォルトの名無しさん
2007/04/14(土) 00:38:35とりあえず、汎用コンテナクラスを作るくらいなら、
必要になってからドメイン スペシフィック(？)にコンテナ作った方が
多分分かりやすいし間違いなく速度は出ますよ、
と言いたかった。
0907`∀´>っ-○◎●
2007/04/14(土) 02:49:41AMDだけじゃねそれ
Vectorパスでデコードするから使う度にストールする。
つーか、pextrwはロード・ストアユニットを使わないから良いのです。
Core2ならpextrwはレイテンシ3-スループット1でアクセスできるから
ちょっとしたローカルストア代わりに使える。
MM/XMMレジスタで計96個のWORD値を保持できるｗｗｗ
（ちなみにpinsrwはCore 2でも遅い）
ロード・ストアって一番利用頻度高いから、1回の操作で
8個のWORD値を読み書きできる意味は大きい。
と、たまにモグリのソフト屋の集まりでそういうネタがよく出るんだが
実用性には疑問符が。
つか、ここ、うちのオフの参加者いる悪寒
（団子の中の人ってことは知られてない筈だけど）
0908デフォルトの名無しさん
2007/04/14(土) 13:36:06AMDでpextrw使ったらえらい遅くなったから、
この命令はずっと避けてたんだが・・・
実際はそうでもないのね。
mm/xmmレジスタをローカルストア代わりに使えたら嬉しいなぁ。
pinsrwとpextrwの性能がいいＣＰＵならかなり使えそう。
ただ、遅い石のことも考慮するとそう簡単にはいかないか……
ってか、ほんとにAthlonXPでの遅さは異常。
AMD系だとたしか op reg [mem] 系の命令が推奨されていて、
Ｌ１のレイテンシ-スループットが大抵3-1くらいだと考えると、
素直にスタック使った方が速そうではある。
(いや、たしかにロードストアユニットは使うけどさ^^)
AMDマンセーな自分としては避けたい気分なんだけど、
Intel系でpinsrwやpextrwが速い石ならかなり可能性はありそうだと思った。
当然、要プロファイルだけど^^
とりあえず、レジスタでＬＳな発想自体は面白いと思う。
あと自分はオフの参加者ではないよ。
そういうのに参加したことは一度もない；；
0909デフォルトの名無しさん
2007/04/14(土) 13:44:15VectorPathについての理解が甘かった。
ちょっとピントをはずしてるぽ。
勉強してきます。
0910デフォルトの名無しさん
2007/04/14(土) 14:44:290911デフォルトの名無しさん
2007/04/14(土) 15:13:44めちゃくちゃ厨くせえ。だって所詮団子レベルだろ？
願わくばその団子クラスのオタモダチがム板になだれ込んで来ないことを希望。
0912デフォルトの名無しさん
2007/04/14(土) 16:11:240913デフォルトの名無しさん
2007/04/14(土) 16:29:00厨くさい会話の中に、どれだけ利用できる情報があるやらw
#あると思うのが>910だろうし、ないと思うのが>911なんだろうね。
0914デフォルトの名無しさん
2007/04/14(土) 18:37:48Webページでも良いので教えてください。
0915デフォルトの名無しさん
2007/04/14(土) 20:13:30まぁ910と911よりは「うちのオフ」の面々のほうが有用な雰囲気。
0916デフォルトの名無しさん
2007/04/14(土) 20:27:090917デフォルトの名無しさん
2007/04/14(土) 20:30:59日本の販売元であるエクセルに問い合わせたら?
0918デフォルトの名無しさん
2007/04/14(土) 20:46:160919デフォルトの名無しさん
2007/04/14(土) 20:52:48なさげ。
C/C++だったら、まっとうなコード書いてれば普通に速い。
特別に速くしたいのだったら、英語版の最適化ガイドをいっしょうけんめい
読んでちょうだい。実際にはあまり役に立たないけど。
具体的に困ってるコード例を貼ったら添削してもらえるとオモ。
0921デフォルトの名無しさん
2007/04/15(日) 13:13:11これをしないように指示する方法はないでしょうか？O0だとすべての最適化がきかなくなってしまうので
この置き換えだけを抑制したいのですが。
0922`∀´>っ-○◎●
2007/04/15(日) 13:17:09{
volatile double tmp = x;
tmp /= 10;
}
0923`∀´>っ-○◎●
2007/04/15(日) 13:19:57volatile double Ten = 10.0;
x/Ten
0924デフォルトの名無しさん
2007/04/15(日) 13:45:52no fast math とか、そんなん無かったか？
0925デフォルトの名無しさん
2007/04/15(日) 14:19:04gccの3の途中からか、constant foldingのやりかたがガラっと変わって、
桁あふれや丸めを期待したコードのコンパイル結果が変わって困った、
という話があったような。
x/10*10がxになるとかだったかなあ。
0926デフォルトの名無しさん
2007/04/15(日) 14:23:41gcc4.2でやってみたけど期待した結果になるけど？
ひょっとしてこれが4.2の遅い理由？
0927デフォルトの名無しさん
2007/04/15(日) 14:56:000928`∀´>っ-○◎●
2007/04/15(日) 15:00:43定数DIVを加算・乗算・シフトで代用するのは大昔からある最適化
DIV命令そのものがない石もあるし。
0929デフォルトの名無しさん
2007/04/17(火) 18:41:380930デフォルトの名無しさん
2007/04/17(火) 23:39:49不確実にエイリアシングが起こるようにしたいの?
0931デフォルトの名無しさん
2007/04/18(水) 01:53:38エイリアシングって何？
0932デフォルトの名無しさん
2007/04/18(水) 01:58:59アンチエイリアシングの逆・・・かと、思ったんだが、
別にここはCG系のスレじゃないし、なんか他に意味あったっけ？
0933`∀´>っ-○◎●
2007/04/18(水) 02:03:56それなんてエイリアンソング？ｗｗｗｗｗｗ
ダーリンおしおきだっちゃ
エスパーするとたぶんこれ
http://docs.hp.com/ja/B3906-90007/ch07s09.html
IntelアーキのL1は8Wayセットアソシエイティブ、つまり同じ下位アドレスに対して
8つのキャッシュライン・エントリを持てる。だからそんなに頻繁に起きるもんじゃない。
AMDは2Wayだから・・・（キャッシュ容量の割に性能良くないのはそのせい）
0934デフォルトの名無しさん
2007/04/18(水) 04:24:30int &b = a;
a = b++;
こういうのもエイリアシング問題と言ったような気がする
0935デフォルトの名無しさん
2007/04/18(水) 04:43:270936デフォルトの名無しさん
2007/04/18(水) 06:53:310937デフォルトの名無しさん
2007/04/18(水) 09:09:41エイリアシングはCG用語ってわけじゃないよ。
和訳すると別名とか偽名みたいな意味で、色々なところで使われる言葉。
一番よく使われるのがサンプリング関係で、CGもその一種。
>>935
一語で表すと「別名」以上に適切な言葉は思い当たらないな。
動詞形なら>>936かね。
名前に限ったことではないので、全ての状況で適切というわけではないが…
0938デフォルトの名無しさん
2007/04/18(水) 10:34:20それただのエイリアス(別名)。
単に可読性のため意図的に読み替える機能であって、ポインタとは違ってアドレスを変えられない。
従って、予期しない動作はアホでも起こさないから避けるものでもなんでもない。
参照と実体の区別がつかなくなっちゃう痛い子はハンガリアン記法でも使っとけばいい。
そういうのは機能問題であって性能問題じゃないし。
普通に考えて下位アドレスの競合によるキャッシュの性能低下のことだと思うよ。
下位アドレスを自分で選べばいい。
たとえば配列を動的に確保するときに容量を多めに確保しておいて配列の開始アドレスを都度決めるとか。
0939デフォルトの名無しさん
2007/04/18(水) 18:01:56C99のrestrict修飾
ttp://seclan.dll.jp/c99d/c99d07.htm#dt19991018
0940デフォルトの名無しさん
2007/04/18(水) 18:50:46それってエイリアシングがないと仮定してプログラマとコンパイラがコードを書けるというだけで、
実際にエイリアシングさせないのはプログラマの責任であることに変わりはないと思う。
0941`∀´>っ-○◎●
2007/04/18(水) 20:29:58>>940
賢いコンパイラなら、restrictポインタを受け取る関数を利用時、
コンパイル時に検出可能なものについてはエラーや警告を出せるかも。
0942デフォルトの名無しさん
2007/04/20(金) 02:08:27> 賢いコンパイラなら、restrictポインタを受け取る関数を利用時、
> コンパイル時に検出可能なものについてはエラーや警告を出せるかも。
エラーや警告ではなくて, 関数の最適化をもっと高度にこなせる
memcpy を inline 展開するときに
src, dst に重複した部分がなければチェックコードその他を省略できるとか
そっち方向の話だったはずだが...
あと, ライブラリーなんかも restrict 付いてればチェックコード手抜きでき
るんだっけか? > 識者
0943`∀´>っ-○◎●
2007/04/20(金) 02:39:02関数側はまあその通りでしょう
0944デフォルトの名無しさん
2007/04/21(土) 03:40:08void func(float *x){
*x=sin(*x);
}
for (int i=0;i<n;i++)
{
func(&a[i]);
}
このような関数内で書き換えを伴う関数を呼び出すと、
loop was not vectorized: mixed data types
と出て、ベクトル化できません。何か方法はないでしょうか？
0945デフォルトの名無しさん
2007/04/21(土) 04:52:34実際のソースを頼む。
それから、sin()ではなくsinf()を使え。
0946デフォルトの名無しさん
2007/04/21(土) 12:27:36のほうがコンパイラにとっては優しかったりしないのかな
0947デフォルトの名無しさん
2007/04/21(土) 12:35:40優しいかどうかは知らんが、大差ないだろ。
手元にiccはないから、gccは後で試してみよう。
0948デフォルトの名無しさん
2007/04/21(土) 18:31:580949デフォルトの名無しさん
2007/04/21(土) 18:54:100950デフォルトの名無しさん
2007/04/21(土) 19:25:24全然最適化してくれないなんてことも普通にあるし、
最適化に期待するのはあんまりよくない。
やってくれたら儲けものぐらいで捉えておくのがいいと思う。
0951デフォルトの名無しさん
2007/04/21(土) 19:29:460952デフォルトの名無しさん
2007/04/21(土) 19:37:110953デフォルトの名無しさん
2007/04/21(土) 21:02:330954デフォルトの名無しさん
2007/04/22(日) 00:00:16オレ古い人間だから>>946にしちゃうよ
0955デフォルトの名無しさん
2007/04/22(日) 01:54:03Intrinsics(or インラインASM) + sinhの近似値を自前で導出！
ttp://www.musicdsp.org/showone.php?id=175
0956`∀´>っ-○◎●
2007/04/22(日) 01:56:23L/Sの節約が必要になるが
0957デフォルトの名無しさん
2007/04/22(日) 06:11:590958デフォルトの名無しさん
2007/04/22(日) 06:29:130959`∀´>っ-○◎●
2007/04/22(日) 06:34:43SPU 128
逆だろレジスタの豊富さがL/Sの狭さを補ってるんだろ
0960デフォルトの名無しさん
2007/04/22(日) 07:02:580961デフォルトの名無しさん
2007/04/22(日) 11:29:460962`∀´>っ-○◎●
2007/04/22(日) 11:31:320963デフォルトの名無しさん
2007/04/22(日) 12:10:370964デフォルトの名無しさん
2007/04/22(日) 13:22:320965デフォルトの名無しさん
2007/04/22(日) 15:17:110966デフォルトの名無しさん
2007/04/22(日) 18:21:090967デフォルトの名無しさん
2007/04/22(日) 20:23:42生温かく見守ってあげてください
0968`∀´>っ-○◎●
2007/04/22(日) 22:09:170969デフォルトの名無しさん
2007/04/24(火) 11:35:39生暖かいと黴びが生えるぞ
#食い物の足が早ぇぇよ！
0970デフォルトの名無しさん
2007/04/24(火) 20:26:10使ったC++コードを徹底するって案はどうかのお。
0971デフォルトの名無しさん
2007/04/24(火) 23:36:02printf("%d");
if( i%8!=0 ){
if( i+1<MAX ){
printf(",");
}
}else{
if( i+1<MAX ){
printf("\n");
}
}
}
これを分かりやすいままエレガントに書き直したいんだけど
どうしたらいい？
0972デフォルトの名無しさん
2007/04/25(水) 00:45:47printf("%d");
if (i + 1 < MAX) {
printf("%c", i % 8 ? ',' : '\n');
}
}
0973デフォルトの名無しさん
2007/04/25(水) 01:24:060974971
2007/04/25(水) 01:57:18ありがとう！
if (i + 1 < MAX) {
の部分が、ループの判定とかぶるから なんとかしたいんだよね。
>>973
そうですすみません。ごめんなさい。
0975デフォルトの名無しさん
2007/04/25(水) 02:18:43for(i=0;i<MAX-1;i++){
printf("%d%c", i, i % 8 ? ',' : '\n');
}
printf("%d", i);
0976デフォルトの名無しさん
2007/04/25(水) 02:18:49printf("%d%c", i % 8 ? ',' : '\n');
}
printf("%d", MAX);
こうとか。
0978デフォルトの名無しさん
2007/04/25(水) 09:56:36特定した
0979デフォルトの名無しさん
2007/04/26(木) 01:07:32「お前の脳ミソ最適化したほうがええんちゃうん???」
ってな, 奴等がほとんどだって事だ!
0980デフォルトの名無しさん
2007/04/26(木) 01:52:39団子ちゃんの悪口を言うな！
0981`∀´>っ-○◎●
2007/04/26(木) 02:43:270982デフォルトの名無しさん
2007/04/28(土) 00:19:51ですが、逆に遅くなりました。5%くらい。
10回くらい測定しましたが。。。
こんなことってあるのでしょうか・・・
0983`∀´>っ-○◎●
2007/04/28(土) 00:25:390984デフォルトの名無しさん
2007/04/28(土) 01:03:01オペレータを効率的に実装してなかったら意味がない。
最大限に効率を求めた実装をすると、後置++は一時オブジェクトが
必要な分だけ前置++よりも遅くなる。
0985デフォルトの名無しさん
2007/04/28(土) 01:08:34やっぱ実測してみたいと分からないものですね。
0986デフォルトの名無しさん
2007/04/28(土) 01:48:03イテレータの++演算子の前置、後置に関しては実測以前の問題だよ。
984が書いている事をもう一度読んでごらん。
0987デフォルトの名無しさん
2007/04/28(土) 02:29:330988デフォルトの名無しさん
2007/04/28(土) 02:42:040989デフォルトの名無しさん
2007/04/28(土) 02:58:030990デフォルトの名無しさん
2007/04/28(土) 04:01:03こういう実装だったんだろう。
0991デフォルトの名無しさん
2007/04/28(土) 08:46:250992デフォルトの名無しさん
2007/04/28(土) 10:39:49わざと言ってんだろうけど。
＞全てのforループ
プログラム全体にわたってコンパイル後のコードが微妙にずれて
キャッシュの乗り具合がずれたんじゃねーの？
0993デフォルトの名無しさん
2007/04/28(土) 10:59:150994デフォルトの名無しさん
2007/04/28(土) 11:01:21>983
処で次スレは?
0995デフォルトの名無しさん
2007/04/28(土) 11:11:250996デフォルトの名無しさん
2007/04/28(土) 11:29:250997デフォルトの名無しさん
2007/04/28(土) 11:36:150998デフォルトの名無しさん
2007/04/28(土) 12:04:39X& operator ++(){ (*this)++; return *this; }
こういう実装だったんだろう。
991 名前：デフォルトの名無しさん[sage] 投稿日：2007/04/28(土) 08:46:25
無限再帰？
0999デフォルトの名無しさん
2007/04/28(土) 12:09:21何その無駄なコード
1000デフォルトの名無しさん
2007/04/28(土) 12:10:45>>982の理由
1001１００１
Over 1000Threadもう書けないので、新しいスレッドを立ててくださいです。。。
レス数が1000を超えています。これ以上書き込みはできません。