C、C++の最適化について語るスレ

コンパイラ性能、コンパイルオプション、コードの最適化などについて語りましょう。
主に速度面の最適化を中心としますが、サイズなどの最適化もどうぞ。
なお、OS、CPU、コンパイラなどは限定しません

このスレ削除して板の最適化

>>1
最初の具体的な話題提起は無いの?

単にノウハウを吸い上げたいだけかと。
こんなとこでは一般的なことしか書かないよ。

↓ちんこのＡＡ

g++で-O3以外に、何付けてる？

おてもやん

関連サイトのリンクすらないのは、>>1が無能で怠惰で生きているだけ酸素の無駄使いだという証。

198名無しさん＠お腹いっぱい。[sage] 04/05/16 13:33 ID:gWLHvqYc
圧縮ファイルを閲覧でき、さらにその中から任意の画像を１枚単位で
抽出できるビューアってありますか？
現在はビューアで圧縮ファイル内閲覧→欲しい画像名をメモ→WinRarで抽出…という手順なもので。

199名無しさん＠お腹いっぱい。[sage] 04/05/16 13:41 ID:O4RkkSrF
> ありますか？
あるよー。
ソフトの名称までは当然答える必要無いよね。

202新参者にマジレス[sage] 04/05/16 14:17 ID:O4RkkSrF
199の回答は意地悪く揚げ足を取ったのではなく、教えて厨を蔓延させない為に
テンプレに挙がってるソフトくらい試してから質問しろという趣旨のものですよ。
｢ありますか？｣と聞かれても、その答えがテンプレに載ってないものならソフト名でこたえますが、
｢既出上等、初心者歓迎、教えて君いらっしゃい｣なスレじゃなければ、
テンプレに挙がってるものくらいは、質問する前に試すのが当然です。

↓ちんこ

│　　　　_、_
│　 ヽ(　,_ﾉ`)ノ　残念、私のおいなりさんだ
│　へﾉ　　 /
└→　ω ノ
　　　　　 >

一つ疑問がある。
袋はあるのに、何故棒が無いんだ？

>>14
存在はするけれども見えないんだよ。
つっこんだら可哀想じゃないか。

つっこめないよ

ちいさすぎて？

まんこに見えるが。
ところでよ、インテルのコンパイラだが、今のバージョンには
次世代CPUプレスコットをサポートみたいに誇らしげに書いてあるけど、
今後はPentium Mベースだから、オプションの説明を見てると
涙を誘うぞ。

unn

Optimizing Your Code with Visual C++
http://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

PentiumM向けの最適化指示enumは何になるんだろー
i686指定でオッケーなんだろうか

　　　DATTE　やってらんないじゃん♪
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
　　　　 ∩＿＿＿∩ 　　　　　　. ∩＿＿＿∩ 　　　　　　　　 ∩＿＿＿∩ 　　　　　　　　　　　
　　　 /　　　　　　ヽ | 　　　　　. /　　　　　　ヽ | 　　　　　　 /　　　　　　ヽ 　　　　
　　　 | ●　　　●　　ヽ 　　　.　| ●　　　●　　ヽ 　　　　　 | ●　　　●　　ヽ 　
　　　ミ　(_●_ )　　　　|　　　.　 ミ　(_●_ )　　　　|　 　　　　ミ　(_●_ )　　　　|　 　　
　　　　ヽ　|∪|　　　　ミ　　　　　ヽ　|∪|　　　　ミ 　　　　　　　ヽ|∪|　　　　ミ　　
　　　　/ 　ヽノ　　⌒ヽ 　　 　　　/　ヽノ　　⌒ヽ 　　　　　　　/ .ヽノ　　⌒ヽ 　　 　
　l⌒Ｖ　　　　　　　　 ヽ 　　l⌒Ｖ　　　　　　　　ヽ　　　 　l⌒Ｖ　　　　　　　　ヽ 　　　　　 　　　　　　　　　　　　　　　　　　　　　　　　　　
　ヽ､_,.'/　　　　　/>　 〉 　　ヽ､_,.'/　　　　　/>　 〉 　　　ヽ､_,.'/　　　　　/>　 〉
　　　 /　　　　　/(_ ／　　　　　../　　　　　/(_ ／　 　　　　　/　　　　　/(_ ／　　　　　　　　
　　　/ 　 /＼　 ＼　　　　　　　/ 　 /＼　 ＼　　　 　　　　./ 　　/＼　 ＼　　　　　　 　　　
　　(＿_／　（＿／　　　　　　.(＿_／　（＿／ 　　　　　　　(＿_／　（＿／　　　　

http://www.zakzak.co.jp/top/2004_05/t2004052809.html
皇太子の激怒している写真

>>23
皇太子殿は実がぎっしり詰まった方なのですね。

>>8
-fomit-frame-pointer -funroll-loops

-null -pointer-exception

>>26
-ga

>>8
-O99

↑それなんか、馬鹿の一つ覚えみたいで嫌。

-O157

ちょっとﾜﾛﾀ

gccは-O4までサポートしてるべ？　-O3だと最適化たりなくなるよ。

O4なんてないよ

↓おいなりさん

↓　　　　　　　 ↑
↓　　　　　　　 ↑
→→→→→→↑

コンパイラの最適化に頼りっきりなじてんで(ry

http://www.emit.jp/prog/prog_opt0.html
このスレはこういうのを語ればいいの？

いいや、そんな低レベルな話は語る前に各自勝手にやれ。
といいたいが、スレの主旨はそっちであってる。
というかそのページの最適化房丸出し。

煽るワケじゃないんだが、どの辺が厨房なのか指摘してくれ。

38ではないが、問題点を上げると、
テストプログラムが単に代入だけのループを使っていると言うこと。
ループ中で除算を数回しただけで、速度の違いなどほとんど存在しなくなる。
どうも最適化云々という人間は、そういった部分を考証することに欠けている。

const float c[] = {...};
const 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;

ではコンパイラの最適化に違いは出るのかな？

気になるなら自分で試せよ。

めんどくさいよ。

そのまま何もせずに餓死するまで転がってろ。

>>41はなんでわざわざFPUレジスタを使うような事してるのか、
まったくわからん。最適化どうこう以前にプログラム組めない悪寒・・・

>>45
言っている意味がわからん。
確かに>>41のコードは、もっと効率よく出来るが
それでもFPUレジスタを使うことにかわりないし・・・

>>37があげたHP以外で、最適化について書かれた、HPってある？
日本語で頼む。

>>47
http://homepage1.nifty.com/herumi/
考察にいろいろ
アセンブラのサイトだけどところどころCのコードも見かける。

日本語で頼むって…

ﾁｮｿ語の方がいいんじゃない？ｗ

最適化について書かれた日本語のサイトなんていっぱいある。
最適化手法の名前でググれ

全部コンパイラ任せにしてるけど、だめ？
やっぱり、ある程度は自分でやったほうがいいの？

>>41
45じゃないんだけどさ、最適化どうこう聞く以前の問題だよ。

>それでもFPUレジスタを使うことにかわりないし・・・

FPUレジスタを使うこと自体、最適化では極力控えるんだ。
そのくらいの知識はあってほしいものだね。
だから、変わりないなんていう前に極力FPUを使わないようなコードを取るか、
アセンブラで書くか、どちらかの手法をとらないと最適化の意味を
なさないんだよ。わかるかな？

たとえば、32bit長のfloatの絶対値を求める場合の
fabsの代用とか同符号の大小比較とか、
とにかくいろいろあるけれど、きみは最適化どうこうの前に
プログラムの勉強をしたほうがいいのではないかな？

CPUによってはFPUの方が速いぞ。

ﾌﾟｹﾞﾗ

最近はFPUの方が計算速い事多いよな
PS2とかは
a+b
a-b
acc+=a*b
acc-=a*b
max(a,b)
min(a,b)
abs(a)
-a
が全部１クロック実行レイテンシ４クロックだったりするし、
これを整数レジスタでやったりすると掛け算辺りはえらい事になる。

藻前ら馬鹿で塚？とマジ突込み

std::stringを返すよりconst std::string&を返した方が速いのは分かります。
では、
boolを返すのとconst bool&を返すのはどっちが速いですか？
intやcharやdoubleではどうでしょう？

一応書いておくと返す変数はメンバ変数です。
ローカル変数や即値ではありません。
(ローカル変数だったらconst bool&は返せないし、即値ならconst bool&よりboolの方が速いに決まってるから)

ＷｉｎＸＰでＧＣＣやりたいんですが、ＶＣ＋＋やＢＣＣと比べて、性能出ますか？
それと、ＷｉｎＡＰＩとか使えるんでしょうか？

>>60
Win32APIはつかえるよ

>>58
あまり変わらないと思う。
ポインタ・参照を返す・渡す目安はsizeof (返す型) > sizeof (返す型 *)になったら。

>>53
ネタなのか何なのかよくわからんが
fabsとかはバリバリ使うよ。

VC最強

VC3000のど飴最強

最強と言えばCodeWarriorだよね

fabsとかはバリバリ使うよ。
ﾌﾟｹﾞﾗ

時代の流れに付いていけないCISClerがいます

大昔の80x86の浮動小数点レジスタって
確かスタック型とかいうアホな仕様だったような。
あれってやっぱ遅かったの？

FPUが別チップのやつもあったなあ。。。

>>70
秋葉原に行って大枚はたいて買ってきてわくわくしながらつけたけど
N88BASICのマンデルブロ集合の描画は1.5倍も速くならなかったよ...orz

FPU乗っけたからって、N88BASICが直接FPUをドライブするのか？

>>72
FPUはメモリー空間やIO空間にくっついているディバイスじゃないよ、
CPU命令のセット拡張するんだよ。
だからドライバは有りません。

>>61
そうですか。cygwinでかじってみようと思います。ｶﾞﾘ　う、

>>69
アホな仕様つうか当時流行りの、ってとこなんだが。
別にスタックマシンだから
遅くなくてはいけないという理由はない。
しかも過去形でもない。

でもx87はコンパイラ屋から冷遇されてるので遅い。

確かに最終的にはMMXにレジスタとか奪われてたしなぁ・・・。

え、すぐに分離されたっしょ

それはSSEでしょ。

ICC > VC++7.1 > gcc3.3 > CodeWariror > OpenWatcom > DigitalMars >>>>>>>>>(越えられない壁)>bcc>最適化無

age

SSEって苦労の割にはあまり速くならないことが多い。

普通SSEを使った最適化はコンパイラに任せるものだ。
MMXとはまた違うんだよ

>>82
C++やCといったコンパイル対象言語がベクトルに対応していないのに
ベクトルや行列演算をコンパイラに任せることが出来るのか？
基本データ型にfloat4だのfloat4x4だの定義されたHLSLのような言語きぼんぬ。

>>83
そういうのはCPUの種類に依存するから言語仕様に盛り込むべきじゃないと思われ。
CPU製造メーカ謹製のライブラリを使えと。

>>83
SSEの用途はMMXと違ってSIMDだけじゃないんだよ。

>>85
逆に言うとSIMDもあるってこったな。

opteron使っています。
最高の最適化オプションてなんですか？

ちなみにコンパイラはgcc3.4.1です

--Replace CPU to more fast

学校の図書館に20年くらい前の科学誌、ニュートンが置いてあってコンピュータの未来について語ってた。そこでは
「高速化の技術にはMIMD、SIMD、(あと一つあったが忘れた）があるが、(忘れたやつ）が主流になり、限界が近いSIMDは使われなくなっていくだろう」
だってさ。世の中はどう動くか分からないねぇ

5年先すらわからない。

>>79 のような情報のベンチマークデータはないですか？

79ってソースてうか根拠があるの？

79のような情報があってるとしても間違ってるとしてもいいけど
そういう情報を掴むデータが俺も欲しかったりする

とりあえずbccの最適化が限りなくアフォなのは合ってると思う

http://www.coyotegulch.com/reviews/linux_compilers/
GCCはもうICCより速くなってる

なってないじゃん。
lameだけgccの方が速いのは元々のコードがgccで速くなるように書かれてるだけ。

SSEの使い方を解説しているページとかあったら教えてください

intelのサイトにある最適化ﾏﾆｭｱﾙとか

>>90
MISD

最適化でSSEを使うかどうかをコンパイラに指令を出すにはどうしたらよいのでしょうか？

QxW

#include <stdlib.h>
const 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

bがグローバル変数なのが原因っぽいねえ

>>104
static const struct b {
  const int a;
} b = {
  6
};
このようにしても結果は同じでした。

あーいや、staticだけどそれもグローバル変数。

GCCで試してないけどこれで十分だろ

const struct b {
enum { a = 6 };
};

hajimekara assemblerで格

科学計算ライブラリはどれが一番使いやすいですか？

>>109
libm

つ１１１

opteron上でgccを使ってC++のプログラムをコンパイルしています。
最速にするオプションを教えてください。

g++ -fmottohayaicpunikaikaeru

最速だろ？
-fichibantakaicpuwokattekuru
だよ

二番煎じはねぇ…

>>112
http://www.cqpub.co.jp/interface/column/freesoft/default.htm

コンパイラって自動的にSSEとかを使ってくれるものなのでしょうか？
それともSSEなどは自分でコードを書かないとダメなのでしょうか？

>>117
Intelのコンパイラなら使ってくれる。

自動では使ってくれないだろ

自動で使ってくれるよ…？

自動でSSEが使われたら、386 - Pentiumの中の人が黙っちゃいないだろうな。

>>121
起動時にCPU判別するコードが埋まるよ？

>>122
それはいいけど、大きなEXEが出来るとしたら嫌だな。

デフォじゃ使わないので問題ない。

メンバ関数をinlineで書いてコンパイルした結果、
実際にinline化されているかどうかを調べるにはどうしたらいいのでしょう？

>>125
逆アセが妥当だと思う。

逆アセ見るとか

開発環境はVS.net(小出しになってしまいすみません)です
Debugでアセンブリコード表示してみたんですが、
非inlineと__forceinline(M$の強制inline化)との違いは見られませんでした
Debug構成だとinlineすらされないのでしょうか？

で、Release構成にして調べようと思ったのですが…
アセンブラはマイコン(PIC)で触れた程度でほとんど知らないので何がなにやら…＾＾；
inline化されているかどうかの目印になるようなコードなどあれば教えてください

てかアセンブラも知らないのにインライン化なんて気にする必要あるの？

>>128
通常、Debugビルドでは一切のinline化を行なわない。
#デバッグに便利なように。

アセンブリコードで、ぶっちゃけcallが関数呼び出し。
但し、明示的な関数呼び出し以外にもcallが置かれることがあるので要注意。

inlineはとりあえずつけておく方がいいのですか？副作用を教えてください。

inline=コピペだからむやみに指定するとコードサイズが
無駄に大きくなってキャッシュの効率が下がる。
とりあえずつけない方がまだまし。
C++ならヘッダに書けるくらい短いコードをinlineにするのが吉。

>>132
まあ、いわゆる getter/setter とかだね。

最近はコードサイズで最適化をかけるケースが増えてきたな。

型チェック機能付きマクロくらいに考えているのが良いのではないか？

>>132
あと、絶対に1度きりしか呼ばれない関数も。
1関数内の処理が長くなっちゃったから途中で別の関数に分けたとかそういうときに。

そういうケースは得てしてinlineにならない罠。

警告 W8027 mbwc.h 22: 一部の return 文を含む関数はインライン展開できない(関数 ToMBStr(const wchar_t *) )
OTL

確かWindows用のフリーのコンパイラだったと思ったが、
一時オブジェクトが必要な関数はインライン展開できなかったな。
いや、正確にはinline指定に対して警告が出たというべきか。

仮にできても>>136みたいな使い方はたぶんしないだろうな。
まとまった量のコードなら相対的に関数呼び出しのオーバーヘッドなんて無視できるだろうし。

ローカル、グローバル、スタティック
変数の種類はどれを使っても最適化には関係ない？

コード的にはローカル変数を使いたいのですが、グローバル変数の方が高速なの？

この馬鹿は何いってんだろうね

>>141
ローカル変数の方が良い。
最適化でレジスタに割り当ててくれる。

どうしてもグローバル・スタティック変数を使わなければならない時、関数内で何度もその変数を使う時は、
レジスタに入れられるような型なら一旦関数内でローカル変数にコピーして関数内ではそれを使い、
関数を抜けるときに元の変数に代入するようにすると、やはりローカル変数をレジスタに割り当てて高速化へ繋がる。

ローカル変数はスタックフレームを形成しますよ？

グローバル変数にregisterを付ける

あと２点

・スタックの先頭付近はキャッシュに乗っている可能性が高い、
　というか乗りっぱなし
・エイリアスの可能性を考慮すると、グローバル変数/スタティック変数を
　レジスタに入れっぱなしにするような最適化がしにくい

とはいえ差がでるようなことはほとんどないと思うがな。

>>146
スタックの先端ってプログラム終了の瞬間しか通らないmainの変数か速攻で消滅するちょい関数のどっちかだとおもわれ。どっちにしろ価値無くないですか？

少しは脳内シミュレーションしろよ。低脳。

>>148は>>146に対してな。

あ、訂正。
>>148は>>147に対して。

>>147はICEデバッグ半年の刑

148は誤射の罪により軍法会議

エイリアスの可能性ってﾅﾆ？

googleしろよボケカス。

ボケカスって何ですか？

153 名前：デフォルトの名無しさん 投稿日：04/11/17 01:19:38
エイリアスの可能性ってﾅﾆ？


漏れもわからん
ﾅﾆ？

>>157
要するにポインタ・参照のことだよ。

だったら最初からそう書け

一般的にエイリアスって言うんだけどなー

もうおまえの脳内の話は勘弁

int f_count; // グローバル

void func(int& x)
{
　f_count++; // 関数が呼ばれた回数をカウントする
　x = 0; // 入力引数を0クリアする
}

たとえば、かような関数があったとして

func(x);とかやって関数を呼ぶと、その回数が
f_countに記録されるわけだが
ここで、

func(f_count);

とやると、関数二行目のx = 0; のステートメントで
f_countの値は0になってしまう

こういう風に、グローバルと参照する入力引数がかぶることを
エイリアスというのではなかったか？
うろ覚え

from MSDN
> エイリアスとは、同じメモリ位置を複数の名前によって参照することを言います。
少なくとも160の脳内の話ではない。
このスレのレベルの低さが伺えるな・・・。

もうおまえの脳内のMSDNの話は勘弁

脳内gccにもあんだけど？

はじめてのＣに書いてないこと書くから粘着が沸くんだよ

いい加減マジレスすると，ローカル変数でも，必ずコンパイラが
エイリアスになっていないことの証明に成功するとは限らない．

一切エイリアスなしのコンパイラオプション，もしくは const,
restrict キーワードをつければ，グローバル領域で実体を確保
しても問題ない．問題あるようなコンパイラは捨ててしまおう．

ローカル変数にする実行速度的長所はキャッシュにのる可能性が
大きいことだけで，短所は実体を複製（初期化）しなければならな
いこと．

結局，実行速度が重要な場所では，ローカルとグローバルの
2通りを実際に作ってターゲットの環境で実際に試すしかない
と思う．

>>145
おまい頭いいな

>>168
本当にそう思うか？register指定子はあくまでサジェスチョンに過ぎないし、
百歩譲って本当にレジスタがグローバル変数に割り当てられたとしたら、
プログラムの終了までそのレジスタは他の用途にずっと使えなくなる恐れ
もある。

賢いコンパイラなら関数の入り口でその都度レジスタにグローバル変数を
ロードしてくれるかもしれないが、CPUのアーキテクチャによってはx86の
ようにレジスタの極端に少ないものもあり、たかだか数個しか割り当てられ
ないし、それにしても関数内のローカル変数の扱いに障害を与えるだけだ。

皮肉だと思っていたんだが

>>170
悪かった。マジレスしてしまった。

そもそもグローバル変数にregisterは指定できない。

エイリアスによる最適化の妨げっていうネタは
C99の仕様にも盛り込まれてるんだがなー

ホントに知らんの？ネタかな？

C99って使われてんの？

gccが片手間に対応しようとしているが完全ではない。C/C++メインだからな。
商品として売られてる例があったら教えて欲しい。

CWが対応してるだろ

>>176 それなに？

コード戦死

CodeWarriorじゃない？

コード勇士

restrict ってどの程度つかえるん?
constは丁寧にコードを書けば 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);
}

検査できないから最適化の妨げになっているので、使用者が明示することで
最適化に役立てようという意図なのがrestrict・・・だと思ったけど。

>>182
その通り。restrictポインタでないと、ポインタの指す領域同士のコピーの
ループに、その都度ポインタからアドレスをロードしてしまうようなコードを
吐く所を、restrictポインタはアドレスをレジスタに代入しっぱなしのコードに
最適化しても良くなる。

volatileの事情とよく似て、ポインタ変数の領域を上書きしてしまって、レジスタ
の値と整合が取れなくなるのを防止するために最適化が抑制されてしまって
いたエイリアシングの問題を、restrictキーワードはパスしても構わない事を
コンパイラに伝える。

ベクトル化しやすいforループの書き方を教えてください

少ないなら中身を全部分解する。
並列処理しやすいようにいくつかに分けて書く。
↓
for(i=0;i<100;i++)
a=A;
のようなものより
for(i=0;i<50;i++){
a=A;
b=B;
}
のような感じ
ループに依存しない部分はループの外に出す
など

ありがとうございました

>>185
素人にいい加減なことを言うのはやめて〜。
回りまわってコンパイラに苦情がくる。

どういう苦情？

>>187
お前、素人だなw

>>183

ちょっと違くない？　そもそも書いてることの意味がわからん．
「修正されたオブジェクトが，他のポインタ等で参照されていない
ことをコンパイラに伝える．」という意味ならば納得なんだけど...
どう意味だったの？ volatileと事情は似てないよ．むしろ，しいて
言うなら反対だよ．しかも，restrict ポインタのアドレスは今は関係
ないだろ．いや，ポインタのポインタが restrict だっていうのならば
そういう事もあるかもしれないが...


>>185

これもちがくない？　それはコンパイラがベクトル化可能かどうか認識する
のを助けるテクニックではないぜ．むしろ妨げてる気がする．いや，たしか
にそんな高速化のテクニックもあるけどさぁ．

restrictポインタについてはこの説明が分かりやすいと思う。
前から全く内容が改変されてないし、間違いないんだろう。
http://seclan.dll.jp/c99d/c99d07.htm#dt19991018

>>190
volatileとrestrictはどちらも、プログラム上に明示的に表れていない
意味情報をコンパイラに伝えるという点で事情が似ている、という
ことなのだろう。たぶん。

ところで、C99のrestrictは、参照しかされない場合は別名を持っても
いいんだっけ？　昔調べたとき、美しくないなあ、と思った記憶がある。

>>185はループのアンロールだな。単純にジャンプ命令を減らす事で
パイプライン・ストールを減らすという効果が主に期待される。

VC6/7.1などでdouble型の配列にループを適用して最適化かけると
勝手にアンロールされる事がある。そして効果はかなり大きい。

もちろん他の型の配列にループを掛けてもアンロールされるけど・・・・
余計な突っ込みを入れられそうなので一応追加。

>>185や>>193のような人を想定して、たいていのベクトル化コンパイラや並列化コンパイラには
人手でunroll化されたコードを巻き戻す機能があります。

んで、エイリアスの可能性ってﾅﾆ？

オマエには一生縁がないから知らなくていいよ

>>192

有効な寿命の間に修正されなければ，別名を持っていても構わない
んじゃないかな．そもそも，配列やポインタを使っているにもかか
わらず，別名を持たないなんて事は在り得るのだろうか．a[i] とし
た時点で既に a[j] とか a[0] のエイリアスの可能性がある．

>>193

単純にジャンプ命令を減らす事以外にもアンロールの利点はあるっす．
out-of-order execution っすよ．185 の例だと，a=A を処理してる間
に b=B の処理をしはじめれるかもしれないっす．

>>198
アンロールはもうコンパイラに委ねる方が賢いやり方だとおもわれ。
で、コンパイラが巧くやってくれなかったら、コンパイラベンダーに
文句を言うのです。

そうも言ってられないこともあるだろうけどね。

>>199

基本的には賛成なのだ．でもそうも言っていられない． :)

sum1=sum2=0.0;
for (i=0;i<N;i+=2) {
sum1+=a[i]; sum2+=a[i+1]; }
sum=sum1+sum2;

なんてのが有名な例だとおもう．浮動小数点演算順序の自動変更
は一切コンパイラにやってもらいたくないっすよ．

とりあえずここのAMD Athlon Processor x86 Code Optimization Guide
を読め。Cでの最適化の仕方についてくわしく書かれている。athlonの場合を
想定して書いてあるが、x86全般に共通する説明が多い。
http://www.amd.com/jp-ja/Processors/TechnicalResources/0,,30_182_739_3748,00.html

>>181
  memcpy(bar, bar+16, 16);
これは重なってないからいいのでは?

>>198
a[j]やa[0]が出てこなければ別名ないだろ。

{ int a[N]; for(i=0;i<N;i++) a[i]=0; }

これなら別名はない。インデックス解析で分かる。

>>198

すまん，書き方が悪かった．「配列やポインタを使って何か意味のある事を
しようとしているにもかかわらず，」と読んでくれ．

今考え直してみたけど，要素数1の時とかは別名参照の可能性が一切ない
ように書けそうだ．void foo( hoge_t * restrict p );　なんて感じ
で関数 foo を宣言し，hoge_t hoge; ... foo(&hoge);　なんてする事は
結構あると思う．で，関数 foo 内では *p 以外の名前はない．

いや，そもそもどうでもいい事だな．

たとえば、下のプログラムはrestrictの言語仕様を満たしているのでしょうか？

int a[10];

int f(restrict int *p)
{
　　return *p + a[2];
}

int g(void)
{
　　f(&a[2]);
}

>>205

満たしてないのだ．restrict キーワードはポインタの値そのものを修飾でき
ないっす．

たとえ int f(int * restrict p ) としても *p と a[2] は実際にエイリ
アスの関係にあるから，厳密には許されていない気がする．ISO のドラフ
トしか読んでないから嘘を言ってるかもしれないけど．

でも，この例の場合，pに別名なしの仮定をしたことによって引き起こされる，
プログラムが正常に動かなくなるような最適化はありえないと思うな．きっと
コンパイラエラーもなければ実行も正常に行われるよ．

そもそも，この例の場合，restrict を使う意味がまったくないし．やっぱ，
restrict ポインタの指す値が左辺値にこないとねぇ．

>>205
restrictの位置の間違いを直せば、それは言語仕様を満たしている。
>>192も言っているが、嫌な仕様だ。

ところでさ、エイリアスの可能性ってどういう意味？
単なるしったかクンだよね？

>>208
そういうお前はうまく説明できるのか？知ったか君。

自分の知らないことは全部知ったかですね。

tedy

エイリアスの可能性

int 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を返すことになりかねない

エイリアスの可能性を最適化コンパイラは
考慮しないとだめなのは、そういったことが理由

restrict って、const と一緒で、あくまで
「その関数内では」エイリアスが無い
という事の表明でいいんですよね？

馬鹿にいちいち教えてんじゃねーよ

>>207

修正されない場合は言語仕様を満たしているの？　そんな事をいってる文章
を読んだことがないんだ．いや，煽っているわけではないんだ．本当に教え
てもらいたいんだ．できれば 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 の文法は満たされていると思う．演算子 / の
後に定数がくることは許されていて，「定数はゼロではいけない」とい
う文法上の決まりごとはないはずだ．いや，最適化とは関係ないかもし
れないけどさ．長文ですまん．

本当に教えてもらいたいから，生意気にも age てみます．

あ，ちなみに

>>213

restrict-qualifier を指定された変数のスコープがその関数内ならば
そのとうり．

>>215
http://www.jisc.go.jp/app/pager?id=293
79ページにポインタ型以外をrestrict修飾してはならないと書いてある。

>>217

それは僕の質問に対しての答えじゃないのだ．でも，返事ありがと．

restrict 修飾されたポインタが指すオブジェクトが修正されていな
いがエイリアスされている場合は許されるのかって事だったのだ．

>>205 の例の restrict の位置を直したものがまさにそうなっている
のだ．ちなみに，僕はそのページを見れないっす．

>>218
規格を読めよ。基本的な知識の無い人間が「〜なはずだ」なんて良く言えるな。
jisc行ってデータベースからX3010を検索。

>>219
JISかよw原文読め

>>220
原文ってANSI? ISO(とその翻訳であるJIS)って何かまずいの？
あと、それがタダでみられる所を教えてくれ。

C++相談室 part38
http://pc5.2ch.net/test/read.cgi/tech/1101473340/4
のPDF。ただし違法。

>>222
それはC++であってC(99)じゃないと思うが。

失礼。こっち。
ttp://www.google.co.jp/search?q=9899+ISO+filetype%3Apdf&hl=ja&ie=UTF-8&oe=UTF-8&c2coff=1
ただし違法。

>>224
ありがとーーー この web page は読めた！

この文章では、どのような状況でプログラムの振る舞いが undefined になるかの
説明があるだけで「restrict ポインタが指すオブジェクトが修正されない場合は
エイリアスを許す」とは書いていないのだ。まぁ、それはそうだ。たとえ修正され
なくても振る舞いがおかしくなる状況はあるからね。

ちなみに、この文章の 6.3.7.1 の 10 に、修正されない別名を持つオブジェクト
のポインタに restrict-qualifier をつけた場合で振る舞いが defined になる
例が紹介されているね。

結局、「動く」とプログラマが判断した場合に restrict を使えと言っている
ように、僕は思えた。

>>219
この文章では / 演算子の 2 つめのオペランドの値が 0 の場合、振る舞いは
undefined だとかいてある。で、結局定数 0 で割る c99 プログラムは言語
仕様を満たしているといえるのかな？ 言えないのかな？

「言語仕様を満たす」という言葉の意味がわからん。

undefinedの意味も規格に書いてある。

規格書はどこで手にはいるの？

>>227
http://www.jisc.go.jp/app/pager?%23jps.JPSH0020D:JPSO0010:/JPS/JPSO0020.jsp=
規格番号X3010でC99、X3014だとC++の日本語の規格書が手に入る。

そのURLじゃタイムアウトしないか？
www.jisc.go.jp から行け。ただし、規格書を「見る」だけな。
本物は大きな本屋で売ってる。

C++のJIS、できたんだ。

>>228
DLすんのできなくね？

>>231
C++相談室 part38
ttp://pc5.2ch.net/test/read.cgi/tech/1101473340/258-259
あと、↑のスレの303辺りから。

>>231
>>229読め

STLをつかうと本当に100倍効率的にかけるのですか？

>233は>232を読めないらしい。

>>235
すみません、あなたのレス、リンクが付いてないので読みにくいです。

>>236
文句があるならば、2chブラウザを使えば?

>>234
このSTLをお前のコンパイラに取り付けろ。すごいぞぉ。プログラムの作成効率は100倍に跳ね上がる。
もってけ。そしてすぐに取り付けて試すんだ。

>>238は酸素欠乏症

>>234
文字列関係のコーディングが信じられないくらい楽になるぞ

どうせくっ付けたり切り離したりするのが楽になるだけでしょ
日本語処理ができるわけでもないし

>>241
そのくっ付けたり切り離したりが楽になるだけで十分楽できる。

std::basic_string<wchar_t>みたいのを常用してもいいわけで。

>>243
その証拠にstd::wstringがtypedefされているわけだが。

STLを使うとコード的にもgoodなのですか？

一般に実行ファイルのサイズが大きくなる傾向にありますが

それは、とてーもbadでーす

>>246
環境によるだろ。
俺はBorland-C++5.6.2に -D_RTLDLL オプションを指定して、極力
ランタイムを使用するようにして使っているが、例えばstd::vectorを
使っても使わない時と比べ10Kほどしか増えない。

10k増えてるってことだろ
馬鹿？

>>248
すげえ。ダイナミックリンクしといてファイルサイズが増えないとかいってるよ。この人。

なんか既視感があるなと思ったらツマンネ

じゃあ、あるなと思わなければ面白いということ？ｗ

>>248-250
この流れ、何ヶ月か前にも見たような…

なんか既視感があるなと思ったらツマンネ

該当スレがわからないので、ここで質問します。
C++ ( コンパイラ 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として配置するのも手なんですが...）

リンクするまで知らんものを
コンパイル時に即値で書ける訳ないだろ
そもそも、即値だと本当に速いんか？

>>255
コンパイラに　/GL
で、
リンカに　/LTCG

>>257
>>1を読んで他所でやってくれ。

>>256
＞リンク云々...
そう言われるとそうですね。

＞そもそも、即値だと本当に速いんか？
環境によりけりとは思いますが、
自分の環境では速かったです。

>>257
ありがとうございます。

>>258
すいません。これで失礼します。

>>249
(´,_ゝ｀)プッ

>>260
;｀;:ﾞ;｀(;ﾟ;ж;ﾟ; )ﾌﾞｯ

>>249
マジレス来たーｗ

10kも増えたらメモリにおさまんねーよ馬鹿

あまりいじめるなよ…
>>263
歴代のC++本スレの最初をどれでもいいから読んでこい

最適化が最強なコンパイラはどれ？

るｂｙ

最適化よりキャッシュ効率のほうが重要。

http://www.ueda.info.waseda.ac.jp/~ishizaki/pukiwiki/pukiwiki.php?prefetch%A4%CB%B4%D8%A4%B9%A4%EB%BC%C2%B8%B3

キャッシュといえばプリフェッチやストリーム。

最適化とキャッシュ効率(ヒット率かね？)は比べられる物ではない。

キャッシュを考慮したプログラミングも最適化の一つ。

C++のRVOはもう期待していいことになってるよね？

キャッシュ効率が良いプログラムとは
キャッシュ容量をあまり消費しないプログラムの事です

>>271
妙な副作用を起こさせるための期待はするべきではない

ある演算を大量に行おうと思った場合、キャッシュは再利用されにくい
データをただ垂れ流すだけになる。
そのようなストリームデータはキャッシュに対してプリフェッチを
行うこと。

>>272
アドレス下位ビットが同じメモリだけを使うと、キャッシュ効率が上がるぞ！

弾幕系シューティングで画面に500発の弾が出ていたとして、
この弾の処理をキャッシュを考慮したら速く出来ますか？

速くなるかはわかりませんが、キャッシュを使うとキャッシュ効率が落ちます。

>>276
500発って弾幕薄くないか？

そうだな。お前の精液なみに薄い

１個の弾をでかくすればいいじゃん。

http://www.hiroiro.com/index.php?eid=493
じゃあ弾の数はこんぐらいで。
こーゆーのはキャッシュ利きそうにないね。

ゲームの話なんて板違いじゃないかなあ。
なんで板が分かれてるか知ってるか？

http://pc5.2ch.net/gamedev/

>>282
総合的なゲームに関して話す場が当時なかったためそれぞれ分散してた上に
どこもゲームが絡むと敬遠される傾向にあったから

ゲーム→ゲーム製作

きりしまＣＩＷＳの発射速度は３０００発／分らしいが、アーガマはどのくらい？

最適化全開にしたらSTLportのDLLが2M超えた

今度のgcc最適化はまともになるのだろうか？

gccやintelのコンパイラは自動的にMMXやSSEを使った命令を生成してくれますが、
コンパイラが生成しやすいようにするには、どのようなコードを書くのがよいのですか？

gcc作った人に聞けばあ？

小さなループは手動でアンロールしておく
ループに依存しない部分はループの外に出すようにしておく
ループのカウンターのようなものはintじゃなくてunsigned intを使う
構造体は16バイト境界に合わせる
構造体のメンバはサイズがでかい物から配置する
割り算より掛け算を使用する
関数に引数を渡す時は、関数の中でその引数用の一時変数を使うようにする
ポインタはなるべく使わず、配列を使用する

>ループのカウンターのようなものはintじゃなくてunsigned intを使う 

unsignedの方が演算が高速と言うことでしょか？

ここにAMD Athlon Processor x86 Code Optimization Guideというのが
あるから読め。Athlon向けだけど、内容はほとんど、一般的なx86
プロセッサ向けだから問題は無かろう。具体例を出して説明しているので
分かりやすいと思う。
ttp://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_739_3748,00.html
それと、インテルのコンパイラのマニュアルにも最適化しやすい
コードの書き方が出ている。xlsoftから日本語版のマニュアルだけ
落とせたような気がした。

俺はunsignedよりもsize_tを使う。こっちも符号なしだ。

XLのやついま落とせなくね？

>>293
unsignedが32ビットで、size_tが64ビットの環境もあるので要注意。

>>295
もちろんわかっている。

http://www.intel.com/jp/developer/download/index.htm

ポインタに関係するループカウンタなら size_t
それ以外なら、unsigend だな

>>298
そうか、unsigendという型があるのか。知らなかった。

あんしげんど

> 299 名前：デフォルトの名無しさん [sage] 投稿日：2005/04/30(土) 19:33:39
> >>298
> そうか、unsigendという型があるのか。知らなかった。

なんだおまえらunsigendも知らないのか
俺はいつもtypedefしてるよ
コレでtaipoも怖くない

磯野たいぽさん

それじゃあunsigend shortとかが、エラーになるだろ
#define するのがプロ

予約語は色やフォントが変わるエディタを使用し
たいぼを防ぐのが本当のブ□

typoは防げねぇなぁ。
即座に修正できるかも知れねぇが。

GUIなエディタを使って、「signed」や「int」や「identifier」ボックスを配線しながらコーディングしてます。
予約語のtypoが0になりました。

何のエディタ？

属性文法系エディタとか。

インテル系のCPUの最適化に関する情報はどこで手に入りますか？

>>310
インテルのサイトのデベロッパページを探ればある。

bool 値を取る変数
bool IsX;
があるとして、
if(IsX)
と
if(!IsX)
では速度的に同じになるのでしょうか？それとも!IsXの方が余計な計算コストがかかるのでしょうか

>>312
IsXへの値の設定から条件分岐後の処理まで提示しないと一概には言えない。
#勿論、コンパイル環境の違いもある。

ほとんどの場合変わらん。最適化していれば。

試せばいいじゃん。

同じバイト数の領域をコピーする場合、連続したメモリ領域の方がランダムに配置された領域からコピーするよりも圧倒的に速いのでしょうか

同じメモリページにデータが入ってれば速い

メモリインタフェースやキャッシュの効果次第

コンパイラオプションだけでfor文をsseなどで並列に実行させることは出来ますか？

>>312
気にするなﾏｼﾞﾚｽ

>319
iccなら最適化でやってくれる

gccは？

if( b )
{
確立が高いほう
}
else
{
低いほう
]

でFA？

compare b,0
jump if equal　ラベル1
ほげ
ふが
jump ラベル2
ラベル1:
はげ
ひげ
ラベル2:
合流

...この場合、たぶん
はげとひげのコンビに逝ったほうが
無条件分岐がないので、
はやい?

速いが気にするほどでもない。

合流せずにretするパターンだと明らかにほけふがの方が
パイプラインを壊さない分速いな。

ほけふがだけキャッシュに載ってないかもしれないじゃん。

ttp://search.yahoo.co.jp/bin/query?p=vectorC+download&fr=top

ほげふがだけキャッシュに載ってない可能性もあるが、
同様にはげひげがキャッシュに載っていない可能性もある。

ほげふがの手前まで実行することが分かってるので、
どっちかというとはげひげがキャッシュから落ちていて
ほげふががキャッシュに載っている確率のほうが高い。

どんな確率だよ。明らかに速いなんて言ってる奴よりはずいぶんましだが。

「場合による」が正解だ。

繰り返し実行するならキャッシュに乗ってる。
１回しか実行しないなら実行速度を気にする必要なし。

無条件ジャンプがある方が1clk程度遅い。CPUによるけど。
ジャンプがある方が速いなんてケースはほとんどない。
あったとしても、329がそこまで理解しているとは思えない。

だからCPUや状況によるんだよ。
1クロックなんて具体的な数値がどっから出てくるんだ？

場合によるに決まってるけどさ。
それじゃ質問への答えとしては生産性がないと思うんだ。
ジャンプした方が速い例を１つ挙げてみてよ。

>>326に書いてある。

>>330を読め。繰り返しならキャッシュにのってる。

仮にジャンプした方だけキャッシュにのってて速くても、
ほげふがとはげひげを逆に書いたらキャッシュへの乗り方も逆になって
逆にする意味がなくなる。

いつのまにか繰り返しが前提なのか？
>>324からそれをどう読み取ったんだ？
結局なにか別の条件を付けないと分からないって事だろ。

無条件ジャンプのレイテンシなど0にできる。
無条件ジャンプの前に検討すべき事はいくつもある。

ごめん。ムキになりすぎた。
お互い、相手にケチつけるのが目的で、
324氏にとって役に立つ議論ではなくなっている。

＃このままいつまでも続きそうで、それはそれで面白いがｗ

面白いから続けてくれ。

面白いか？
じゃあ、

call func1
...
call funcn
compare b,0
jump if equal　ラベル1
ほげ
ふが

となってて、func*がほげふがと同じキャッシュラインを使う無茶苦茶
レアなケースを考えよう。
同じラインに載らないように最適化するリンカってあるのかなあ？
ダイレクトマップのプロセッサでひどい目に合った事がある。

ふつーicacheのconflictは気にせんと思う。
dcache用にはコンパイラがpaddingを入れたりするが。

>>329
>>318とかもそうだが、正しいけど答えになってない。
明らかに速いと言ってる奴の方がずいぶんましだと思った。
それが気に入らなかったから、>>330でトゲのあるレスをしてしまった。

>>335
繰り返しでないなら、ますますジャンプのコストを気にする必要がない。
他に検討すべき事があるのは同意。


で、大事なことを忘れていた。
jump if equal で、前方分岐の静的分岐予測は分岐しないと予測するのが普通。
つまり初回の実行は、ふげほが の方がずっと速いことになる。

PentiumMでだけど、アセンブラで実験してみた。
静的予測は、初めの４回はジャンプしないと予測するようだ。
はげひげ だけ実行すると最終的には合計50clk程度の不利となり、
100回以下のループなら、ふげほが が速い。
繰り返し回数を十分大きくとると、はげひげ の方が平均0.5clkほど速かった。
命令数が１つ少ないのが出ている。
処理内容によっては、まれに逆転することもある。

というわけで、かなり場合による。
他のCPU、特にPC用x86以外だと更に違うと思われる。
まあ、どちらが速いかで困ったら、２つ作って自分で比較しろということだ。

結局そこに落ち着くわけで＞場合による

>>341
ぐっはあ。むかつくぜ。
だから俺が言いたいのは・・・

どうしても大枚はたいて買ったPentiumMを擁護したい、それだけだろ？

ん？擁護などしてないが。確かにPentiumMは好きだけど。

「場合による」って答え方が嫌いなだけだよ。

>>344
一言「場合による」と答えれば、初心者なら「気にすることない」と知ることができ
もう少し経験値があれば自分で調べようと思うこともできる。
>340のようにくどくど書くと、初心者には「なんだかよくわからない」という印象しか残らない。
場合によっては、「場合による」という回答の方が適当であることも知ったほうがいい。

「場合に拠るから実際に測定しろ」とは
これまた当たり前かつ普遍の結論ですね。

>>345
「場合による」と「気にすることない」は違うと思うが。
俺は「気になる初心者」だったのでそう思うのかな。

まあ、助言サンクス。気をつけます。

>>345
中級者以上が専門のスレッドで議論する時には、「場合による」という一般論的回答でなく
「こういう条件では〜、こういう条件では〜」という対象の構造に踏み込んだ回答が望ましい。
>329のようにただ「場合による」と書くと、「そんなのは当たり前だ」という印象しか残らない。
このような場合には、「場合による」という回答が不適切であることも知ったほうがいい。

でも、明らかに速いなんて嘘じゃん。
嘘よりまし。

逆に明らかに速い時に「場合による」といったら嘘になる。
従って、「場合による」という回答は当り前ではなく意味がある。

明確な言明であれば，嘘なら嘘でそれが何故，どういう条件だから嘘だという風に議論が深まることもある．
「場合による」よりましかどうかは場合による．

まあそんな順序付けをするより>>348のように書く方が建設的だな．

仄めかしに過ぎないが、条件らしきものは>>326とその反論(?)は>>328に
出てるんだよな。

まずいのは、新たな条件の場合の話を始めた>>330が、そのように
読み取れないことだな。次の段落で>>326向けみたいな話をしてるし。

おまえらケンカしてないで最適化の話に戻れ。

ケンカを最適化しる！

確かに、この喧嘩は冗長すぎる。

>>348
俺もバシッとこういうこと言えたらヨカタ。。orz

>>351
326はあげあしとりだろう。命令キャッシュまで考えるケースじゃないよ。

すまん、煽りなら無視できるんだが・・・。

「場合による」君はいい加減退場しなって。

「場合による」君は往生際が悪いな。
ファビョってないでどっか逝けよ。もしかして在日チョンか？

age

「場合による」というよりは
初期条件をより明確にしないと意味無し

deleteを実行してもすぐにメモり使用量が減らず、しばらくしてから減るのですが、プログラム側から
これはコントロールできないのでしょうか？OS側の問題でしょうか？

inlineを指定した場合の速度向上はかなりのものでしょうか？

>>360
OSによる

>>361
場合による

>>360
それはこのスレの趣旨から外れる。

>>361
inlineを指定したからといって、必ずしもインライン展開されるわけではない。
その関数内で複雑な処理をしたり多数のローカル変数を使うとコンパイラが音を上げやすくなる。
また、インライン展開による速度向上よりも、もっと効果がある最適化もある。

>>363はあげ足取りだろう。
そんな複雑な処理をする場合まで考えるケースじゃないよ。

>>364
そんなケースではないとどこに?

>>361
頻繁に呼ばれる短い関数だったら速くなる。
複雑な関数だと大して速くならないか、かえって遅くなる。

>>366
寡聞にしてそのような例を知らないのだが、具体例を挙げてもらえまいか。

そんなに最適化したいならVectorC{PC}でも買え

おまいら >>348 も見えんのか。

>>369
無視されたからってファビョるなよｗ

>>370
意味判らん。精薄？

意味わからない奴が精薄だろ普通。

>>367
一般論としては>>366だと思ったのだが、違う？
確かに実験もせずに悪かった。確かめるから少し待ってくれ。

>>366
一般的に、遅くなるほど複雑な関数はインライン化されない。
コンパイラはその程度には賢い。

簡単な関数だとinlineを指定しなくても埋め込まれてしまう。
逆にちょっと複雑にするとinlineにしてくれなくなるが、
これもPeniumMのスタックエンジンのおかげか、
呼び出しオーバーヘッドがほとんどない。

つーわけで、最近のCPUとコンパイラならどっちでもいいと思った。

どっちでもいいわけないじゃん
アフォか

inlineの効果は関数呼び出しのオーバーヘッドの削減だけではなく、適用される最適化が増えるという利点もある。
ただ、クリティカルな部分ではコンパイラが信用できないのでマクロにしてしまう人も多いと思う。
例えばGCC4とかはバグがあってやばい感じだ。

>>377
だからinlineは強制ではなく、あくまでもコンパイラに対する示唆に過ぎないと何度（ｒｙ

registerみたいなものか

確実性は薄いが __forceinline とか。
コンパイラ依存だが。

インライン化をされやすくするこつを教えてください

高性能なコンパイラを買ってくる

>>381
・inline指定する
・ローカル変数を減らす
・一時オブジェクトも減らす
・複雑な条件分岐を減らす

関数を適当にテーブル化すればインライン化されない。
関数を関数引数に入れて呼び出したりとかはうまくすると展開される。
Lispでは常識の最適化だけど。

一番有効な方法

・プログラムを1ファイル化する

VC++7.1 の最適化について質問です。たとえば次のループにおいて、
if (i = 0; i < n; i++) …
i も n も整数型の変数だとすると、n > 0 であることが保証されていれば、
マシン語コードにおいて最初の継続条件 (i < n) のチェックは不要になりますよね。
そこで __assume(n > 0) を入れて最適化のためのヒントを与えてみたのですが、
コンパイルされたコードを確認しても、最初の継続条件のチェックは消えていません。
どこか使い方が間違っているのでしょうか。それとも、他に何か条件がありますか？
この場合は、どうしても嫌なら do 〜 while を使えばいいだけなんですが、
__assume() が使えるといろいろ応用が効きそうなので…よろしくお願いします。

なんだそりゃ！？

>>381
絶対にそこに展開したいんなら#defineが確実

>>386
よく解らんが、__assume(i >= 0) も入れてみたらどうなる？

assumeってそんな賢いかなあ

VCだとReleaseビルドでは単に無視するだけじゃないのかな?
#つーか、defined(NDEBUG)か。

>>389
__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() の話だったりしませんか？

素直に
{ assert(n > 0); int i = 0; do { ... } while (++i < n); }
にしる

>>398
それこそ無意味

>>398
つーかお前の存在自体無意味

>>398
お前がこの世に存在する意味あるの？

実は398=394

生まれてすいません。

http://www.geocities.jp/hanran9/tyairo.htm

>>392
最初の条件判定（1回）を排除するために
定型表現を無視して見づらいコード作るのはやりすぎじゃね？

最初の条件判定（1回）がボトルネックになってるならいいんじゃね？

どんだけ細かいボトルネックだよｗ
そこまで最適化したいのなら、素直にdo-whileを使えって話でもあるし。

>>400-402
いえ…早い話が、__assume() の可能性について知りたかっただけなんです。
今回の件は __assume() の挙動について調べるために一例として取り上げただけでして、
普通はコードの可読性を優先させて、定型表現を使うべきだと思います。
そもそも定型表現にこだわる必要がないのなら、はじめに >>386 でも触れましたように、
最初から for ではなく do 〜 while で書いてしまえばいいわけですから…。

つーか >>386 の２行目、if じゃなくて for の間違いだよ…今頃気が付いた　＿|￣|○

>>386
… ようするにもともと話の切り出し方も例もその後の情報の出し方も
ようを得ないで気も利かないから、みんなも興味ない喰いつきが悪いかと。
その例だともともと do{}while で書けばよい類のものだし、効果も小さいし、
hint与えたからといって、最適化しなくてもなんら不思議は無い、
逆に何を根拠にそれを期待するのか、のほうが冷ややかに不思議、程度かと。

>>404
そうですね。いろいろ気が利かなくてすみませんでした。
というわけで、これにて消えまーす。

MSDNみたけど微妙なキーワードだな。
例示してあるような限定的なケースだけ最適化の対象になるのかも。
面白いネタ思いついたらまた戻っておいで。

分岐命令、分岐予測系の命令の選択にほぼ直結しているんじゃないのかな?
コンパイラ内の実装もdirty hack系のような気がする。

MSDNの"Example"では、式である必然性を疑わせる例なのに、
#pragmaじゃなくて、式の拡張になっているのも謎。

#pragmaの中の人と担当違うんだよ

sseなどはコンパイラが自動的に使ってくれるのですか？

>>381
全部forceinlineに汁

一番早いminはどれ？
typedef 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 );
}

乗算が含まれている時点で俺としては1, 3, 4を却下する。

>>411
俺も一時期、この手のヤツいろいろ試してみたけど十中八九 min0 が最速になるよ。

>>413
そっか。一番短いもんなあ。
なんか三項演算子ってジャンプしそうだから、
ジャンプしなさそうなのがいいかなって思ったけど。

>>412
整数型でも、かけ算ってやっぱまだ遅いのか。
ｻﾝｷｭ

>>414
いや、三項演算子ってジャンプするけどな。
それでも 0 が他と比べて早いと思う。
DSP とか、条件命令実行機能持った CPU だと条件ジャンプのコストはかなり低いし。

super scaler とか hyper threading でバリバリに最適化かかったら 1 が早いかもしれないけど、
十中八九 0 かと。

乗算はやっぱ遅い。
ただ、MMX 命令みたいに、複数の乗算を同時に出来る命令持った CPU もあるから、
そういうのだと積和演算なんかのスループットは結構早い。

int32_t min5(int32_t a, int32_t b) {
　int32_t d = a - b;
　return a - (d & (~(d ^ (a^b)&(d^a)) >> 31));
}

int32_t min6( int32_t a, int32_t b ) {

int32_t r[2] = { a, b };
return( r[a<b] );

}

int32_t min7( int32_t a, int32_t b ) {
  if (MB_YES == MessageBox(NULL, "a は b より大きいですか？", "('A`)", MB_ICONINFORMATION |MB_YESNO)) {
    return a;
  } else {
    return b;
  }
}

min7 は逆じゃないか？

>>417
それ、メモリアクセスになって余計に遅かったりはしない？
あるいは最適化が効いて結局 0 と同じコードになるか。

std::min つかえば、ライブラリ実装者が最適な実装を提供してくれる、
といいなぁ。

CPUによっては条件ビットセットがあるから問答無用でmin0が速いべ。

>>420
メモリアクセスってもスタックは大概キャッシュにあるだろ。
0 の方が速いが。

PPCの命令セットには、「値の小さい方をとる」命令が含まれていたよ。

この程度じゃパイプラインがストールしたりはしないのか。ためになったよ。

こういうよくあるケースで躓くような設計はしないよね。

for(i=0; i<1000; ++i) {
　for(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が最速

>>427
さすがパイプライン深いな。
5が速いのは倍速ALUかな？遅いシフトも1回だけだし。

6はシンプルに分岐をなくすいい手だね。

ほんと流石 Pen4 だな。
いろんな意味で。

>>427
それぞれの実測値は？
7以外は測定誤差の範囲内だったりしないか？
ちゃんとQueryPerformanceCounterとか使った？

俺はPentiumMで測ってみました。
VC++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になってた。
つまりメモリアクセスをしていないから速い。

>>431
eax と ecx は ID が1違いのレジスタってことなんかな？

>>432
32bitのx86は8個の汎用レジスタがあって、espがスタックポインタな他は
どれも同じ種類のレジスタと考えて差し支えないと思いまんもす。
別にebxとesiに割り当てても速度や動作に違いは出ない。

>>431
7は？

>>434
僕がボタンを押すのに40clkとかの時間で済むと思いますか。

>>433
いや、min6 が分岐じゃないから早いという理屈から察するに、
a < b の演算結果が 0 か 1 かという事実から、
条件分岐ではなく値の違いでレジスタを選択できなきゃ駄目でしょ。
そういうことじゃないん？

>>436
その通り。。俺の勘違いですた。
メモリアクセスはその後でしています。

>>430
timeBeginPeriod(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 に置き換わってるだけだった。
そんなに違うもん？

>>435
頑張れ！

>>438
Pentium4だと、decとsubでレイテンシが0.5clk違う。
まあ、1〜2%の差なら生まれてもおかしくない。

意外だが、0と6の差がPentiumMより少ないね。

俺はサボってしまったが、427氏は7もちゃんと測ったんだろうか。

そういえば、インラインに展開のされ方によってはどうなんだろう。

min0 が遅い理由、まあ Pen4 のパイプライン段数が糞多いのが直接の原因だけど、
普通は遅延分岐とかで多少マシになるでしょ。
入力がランダムだから予測は意味ないけど、遅延分岐なら。

min 関数の場合、遅延させるほど命令がないからどうしようもなくなってるわけで、
min 関数の前とかに別の処理とか入ってたらひょっとすると遅延分岐が効いてこないかな？

>>440
Pen4 はよく知らないけど、普通は dec の方が早くないの？

Pen4 って内部的には算術命令を複数個並列処理してるんだっけ？
dec と sub を並列実行することで早くなってるとかでもないんかね？＜ /G7 で 2 が早くなるっての。
dec の演算器は全部使っちゃっててデータハザード起きてて、
それが sub に置き換えると（本来は sub の方が遅いけど、データハザード起こさない分）早くなるとか。

>>442
遅延分岐って、フラグが確定するまで待つってこと？
x86で実装されてるの？

>>443
最近のCPUではdecもsubもほぼ変わらない。使うユニットも同じ。
命令長がdecの方が短いのがわずかに利点。
ただ、Pen4ではdecのが遅い。
これはパーシャルフラグの扱いがPen4では異なるため。

実際に、分岐ミスでパイプラインの段数分損しないケースはある。
アウトオブオーダーして、フラグを決める命令と分岐命令を先に実行する。
分岐命令が早めに実行されれば、予測ミスが発覚するのも早くなる。
つまり分岐ミスのペナルティが減る。

>>444
>>442 は何か勘違いしてたかも。流して。

dec の方が遅いんか。
CPU は昔 RISC と DSP 中心で勉強したんで Pen4 は結構異文化だわ。

>>445
あっ、それそれ。
Pen4 ってアウトオブオーダー実行してるんだっけ？
フラグ決めと実際の分岐の間に命令挟むようなことしてたら、
インライン展開の結果次第では・・・という。

>>445の続き。
まあ、「別の処理」がないとアウトオブオーダーできないけどね。

PentiumMでは、通常14clk程度のペナルティだが、少なくなることも多い。
ただ、どうやっても7〜9clkのペナルティはあった。

PenPro以降のCPUはみんなアウトオブオーダーしてるよ。
ただ、この場合はさむものがないからねえ。
Pentium4ならminと次のrand()を並列実行できたりしてｗ

>>448
min 関数単体でループ繰り返す限りには、「別の処理」なさ過ぎて >>445 みたいなのが全く役に立たないけど、
インライン展開後に「別の処理」があるようなコードでループすればどうなのかなぁと。

まあ、でも、予測の効かないランダムな値相手だとどうしても分岐は遅いのかな。

>>450
なるへそ。
>>448のように、ランダムでもペナルティを半分くらいにはできるはずだけど。

でも実際は、普通は0が速いし、ランダムなら6使っとけば安心ということで
あんまり気にしなくてもいいのかもしれないけどね。

ま、大体 CPU 依存だしねぇ。
Pen4 みたいに相当分岐に弱い環境でも10％くらいしか不利つかないんだと、
パイプラインの短いのなら普通は 0 が早そうよね。

2とか5は、よっぽど算術論理演算のクロックが短いか、
演算器が結構な数並列になってないと早くない気もするし、

6が使える条件も、0 か 1 かでレジスタを切りかえれないと駄目なわけだけど、
たいていの処理系ってそれできるんだっけ？

int32_t min8( int32_t a, int32_t b ) {
　__asm{
　　mov eax,a
　　cmp eax,b
　　cmovg eax,b
　}
}

8:38clk

インラインアセンブラを使ってみた。6に負けたorz

>>452
どっこいPentiumMでは分岐ありの0は30%も遅い。

>たいていの処理系ってそれできるんだっけ？
フラグを汎用レジスタに転送できればいいのだから
大概大丈夫でしょう。

去年、これに似た件で計測した覚えが...
IA32系じゃなく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() のほうが速かった

>>454
MIPS 系は２個しか触ってないけど、FPU 積んでて min.s が無い石があるんだね・・・

コンパイラの出力を見ると、min6とかはインライン展開されていて
ほとんどレジスタだけで処理を済ませている。

それに対し>>453のmin8では、インライン展開はされているものの
展開先で、インラインアセンブラの範囲には最適化が全くかからないため、
無駄にメモリを介在することになってしまう。

これが最適化ヲタの巣窟か

これがオタに見えるって、どんな素人だよｗ

AMDのプロセッサでもIntelコンパイラでコンパイルするとgccなどよりも高速なコードが生成されますか？

>>459
AMDがIntelに対して起こした告訴理由の一つとして
「ICCにおいてAMDプロセッサを使ってコンパイルすると糞コードを吐く」
を主張している。

ttp://www.itmedia.co.jp/news/articles/0507/14/news031.html

-AMDがIntelに対して起こした告訴理由の一つとして
+AMDがIntelに対して起こした訴訟の告訴理由の一つとして

>>460
これって、コンパイルした実行ファイルを実行するときの話じゃなくて、
コンパイラの動作自体がCPU依存になってるってこと？
だとしたらとんでもないな。

>>459
とりあえずSPECなんかみてるとOpteron+ICCの構成はいくらでもみつかる。

>>463
劣化したコードにもかかわらずこれだけ出ているのはすごいな

「ICCにおいてAMDプロセッサを使ってコンパイルすると糞コードを吐く」
のであれば、IntelCPUでコンパイルしてAMDCPUで実行しても
遅くならないんじゃまいか。

>>465
実行時にCPUを判別して分岐する

AMD向けの最適化を謳ってる商用コンパイラってPGIとPathScaleだよね。
MSVCとICCとGCCもいれて全部比較してみれたら面白そうだなぁ。

>>427
これどうして、k, lをrand()にしているの?
min*()よりずっと重い処理になるけれど。

>>468
ランダムにしないと分岐予測が当たっちゃうから。
まあ、ランダムにしたせいで分岐ペナルティの最も多い場合になるわけだが。

k = i+j;
l = i-j;

にするとだいぶ結果が変わってくるな。

>>460
全く同じOS構成、ICC構成で、CPUだけ違う環境を用意して
ICCが吐くコードをバイナリ比較すりゃいいじゃん。

>>471
うそー、コンパイル環境で吐くバイナリが変わるのか？

手元のPowerPC G4(OSX)とWindowsXP(cygwin)で試してみた。
コンパイラがgccって事もあって、どちらもmin0が一番速かった。

ちなみにどちらも最適化オプションは同じ(-O4)で、
コンパイラのバージョンは
OSX gcc 3.3
cygwin gcc 3.4.4

>>472
出鱈目だろ。
実行時に判別して〜云々は、よくマニュアル読んでないだけか、ただの言いがかり。
たとえば/QaxNとかでビルドすると、SSE2の使用有無にかかわらずPentium 4でしか最適化された
パスを通らないコードができるがそれは当たり前の動作。AMDのCPUであろうがなかろうが跳ねられる。

CPU毎の最適化を使いつつICCのスタートアップルーチンを使わない手ならいくらでもあるけどな。
一番簡単なのは、最適化対象の関数だけターゲット数分別名で作って、ファイルごとにコンパイルオプション
変えて(/G6, /G7, /QxK, /QxN, /QxP, /QxB, ....)専用にコンパイルし、全部リンクする。
自前で関数テーブルを作ってやる必要があるが、CPUIDで自動判別させるのを自前でやるなり、
ユーザーに選ばせるなりできる。

信用しきれないなら/FAでasmコード生成してそいつをVC++で利用するのも悪くないお

インリンをつけた関数がインリン化されやすくなるようにするにはどのようなことに気をつければいいですか？

分岐・ループしない
大きくない
他のインリンされそうにない関数よばない

>>475
>476は血迷っているので信じないように。
コンパイラによって違うから、一概に言えないとしか言いようがないのがinline化。
例えば、分岐やループがあろうが標準関数を呼ぼうがinline化される環境ならinilne化される。

forceinlineみたいのはいかんのん

あとエロテロリストにきくのが一番いいとおもうけど

血迷っているのは>>477のほうだな。
もう一度>>475が何を訊ねているのかを読むべき。

>>479
477は日本語が不自由なんだよ

ん？>>477は環境によって違うと言っているだけだろ？

>>477と>>481は屁理屈気違いなので放置の方向で。

そいつの存在は他スレでも確認した。
そろそろプギャーとか言い出すぞ。

インテル C++コンパイラ9.0での話だけどSIMDのintrin命令を多用したコードでは
-O3 -Qipioより-O2 -Qip -Qunroll0で最適化したほうがなぜか速いケースがある。

>>475 に便乗しますが
菊地美香をなんとかインリン化できないものでしょうか？

>>485
カプセル化されてるから難しい

インド人をカリー化するほうが簡単だな

ヨーダ「フォースを使うのだ」


#define inline __forceinline

つうか、C/C++も中間言語までのコンパイルにして実行時にCPUにあわせて最適化かけるで良いじゃないか

よくねーよハゲ(^^)

>>489
つC++/CLI

>>489
今となっちゃIA-32のアセンブラ自体中間言語みたいなもんだ

>>492
ずいぶんと古い今だな。

大発見！！！スイッチで12分岐以上位だとどれも速度が変わらないぞ！

だよね。（12分岐と言う数字はケースバイケースだと思うが）

むかしは条件判定もったいないとかで関数ポインタ駆使したりと
小手先なことしてたが、最近はスイッチで十分だと。

言語から仮想関数とかの支援があればそれを使うのも結構だけど、
分岐そのものがその場に書いてあるスイッチやバカチョンif判定
書いてあるスイッチはやはり後で見て分かりやすい

caseの値が連続しているswitchは、jumptableに展開するコンパイラたくさんありますよ。

c、c++のcase文って複数纏めて指定できないから嫌
連続する数値は
case 'a' to 'z': とかできたらいいのに

複数が狭い範囲なら
case 0:
case 1:
case 2:
case 3:
処理

>>496
連続してなくても(半ば強引に)展開するコンパイラもあるね。

>>497
case 'a': case 'b': ... case 'z':
を自動生成させてはいかが?w

>>495
半島人を中途半端に馬鹿にする発言はよくない。
きちんと、「馬鹿でも朝鮮人でもできるような単純な判定」と書きましょう。

>>497
GCCの独自拡張で to → ..

>>499
「バカチョン」は朝鮮人とは何の関係もない言葉なのだが…。

>>501
その言葉は「バカでもチョンでも」から来たとする説と
｢バカでもチョンと押すだけで」から来たとする説の二つがある。
前者が存在する時点で使うのをためらうべき言葉だとは思わないか？

>>502
「『ちょん』は明治時代には日本語として存在していて
　バカや間抜けと同義。」らしい。
まあ、言葉狩りに意味があるとも思えんが。

>>503
二つ意味があるってだけでどっちにしろ同じことじゃないかな？
起源について二つの説がある「バカチョン」という言葉の問題か
二つの意味を持つ「ちょん」という言葉の問題かってだけで。

まあ最適化とは関係ないからそろそろ次の人どうぞ。

　　　　　　　＼
　お　そ　.い　ヽ
　か　の　や　　|
　し　 り　　｀　 ,. -──- ､
　い　.く　　 ／　　 /⌒ i'⌒iヽ､
　　　 つ　/　　 ,.-'ゝ__,.･･_ノ-､ヽ
　　　 は　i ‐'''ﾅ''ｰ--　●　=''''''ﾘ　 　 　　_,....:-‐‐‐-.､
　　　　　　l -‐i''''~ﾆ-‐,....!....、ｰ`ﾅ　 　 　 `r'=､-､､:::::::ヽr_
￣ ＼ヽー' !.　t´ r''"´､_,::、::::} ノ`　　 　 ,.i'・　,!_`,!::::::::::::ヽ
　　　 ヾ、 ゝゝ､,,ﾆ=====ﾆ／r'⌒;　 　　rｰ`ｰ'　,! ﾘ::::::::::::ﾉ
　　　　　　 i`''''ｙ--- (,iﾃ‐,'i~´,ゝ'´　　 　￣￣ヽ` :::::::::::ノ
　　　　　　 .|　　!、,............, i }'´　　　　_　　 ､ｰ_',,...`::::ｨ'
　　　　 ●､_!,ヽ-r⌒i-､ノ-''‐､　　　　ゝ`ｰt---''ヽ'''''''|`ーt-'つ
　　　　　 　 (　　`ｰｲ　 ﾞi　　丿　　　;'-,' ,ノｰ''''{`' 　 　!ﾞヽﾉ　,ヽ,
　　　　　 　　`ー--' --'｀￣ 　 　 　 ｀ｰ't,´｀ヽ;;;､,,,,,,___,)　ヽ'-ﾞ'"
　　　　　 　　　　　　　　　　　　　　　　　(`ー':;;;;;;;;;;;;;;;ﾉ
　　　　　　　　　　　　　　　　　　　　　　 ｀`''''''｀`'''''´

ここは放送倫理に縛られる場所じゃないから、結局は自己責任で使え。
ただ、本人には、反駁があってバカにされたあげくにスレが荒れたら責任を感じてもらいたい。

スレは全然最適化されてないな

>>507
来るべき質問を予測して投機的に回答しておいたり、引用はinline展開したりするべきだな。

差別用語として意識しつつ、敢えて使う。これ、最強。

それは思考停止状態のサル並ということだが、たしかに最強だな。

>>510
思考停止はお前。

>>508
同趣旨のレスは一箇所で定義しておいて、他で参照するようにするとか。

>>511
脊髄反射はお前。

ここで脊椎反射ですよ

それなら俺は骨髄反射

脊髄反射割り込みのオーバーヘッドを最適化したいのですが

関係ないけどすっとんで脊髄反省しに来ました。

ずいずいずっころばしのスレはここですか？

>>518
そうです。よくこのスレの秘密がわかりましたね。
みんなで暗号化して一見C,C++の話やちょんの話を
しているように見せかけて実はずいずいずっころ
ばしのことを延々と話していたんですが。

ごまみそずい

これはもうだめかもしれんね。

>>519
　う
　ん

　　　こ　を延々と　していた


こうですか？わかりません！

>>522
　　で
　　な
　　い
　　の

www

冗長だったのが最適化された！
流石ﾌﾟﾛﾊｶｰ!

VC8とか、SSE最適化しても4次元ベクトルとかをSIMD計算してくれなくてｶﾞｯｶﾘ。

アレはx87演算をSSEのスカラ演算に置き換えるものなので。

うーん。
SSE2とか使うのは難しくないけど、
それでより効率よく演算できるようにしようとすると、俺のレベルじゃ無理だ。

C、C++とは関係無い話だな。
しかも効率ってSSEじゃなくてメモリアクセスのほうが問題になるだろ。

>>526
Ｉｎｔｅｌ C++ Compilerならある程度の自動ベクタライズをしてくれる。
でも、いろいろコンパイラに指示しなくてはならないし複雑なものには対応してくれない。
結局は自分で直接SIMD命令を書くのが効率がよい。
アセンブラで書くのが面倒なら組み込み命令(xmmintrin.h)を使ってみるといい。

ハートで感じるパイプライン講座ってないかな...

*mmintrin.hとそのラッパーの*vec.h使っておけばいい。
パイプラインを考慮したスケジューリングはコンパイラ任せでも十分速度出る。
むしろハードウェアのレジスタリネーミングやOoOである程度畳み込みやってくれる。

>>530
でも、その最適化って年末あたりに出る次の世代のx86じゃ使えないんだろ

民生機用CPUとしてベクトル演算機がダイ上に実装される日はくるか

>533
MMXはx64で使えなくなってるね。 SSE系が使えなくなるって話はまだ聞いてないけど。

>526
>530が言ってるようにxmmintrin.h使うといいよ。
ICCとVC6以降で使えたと思う。 MSDNに英語のドキュメントがあるから参考にするといい。
(ドキュメントはC++ LanguagesのCompiler Intrinsic以下)
レジスタ割付を考えなくてすむので、アセンブリで書くよりは大分楽になる。
// あるいは、Direct3Dで用意されてる各構造体を使うという手も。 確か自動的にSSE使ってくれたと思う。

>>535
mmintrin.h使うとIA64でもx64でも64bit汎用整数使ったコードに展開される。

>536
あれ？ おいらが試したときはリンクエラー出たんだけど＞MMXのintrinsic

>>534
今のショートベクトルよりでかいベクトル演算器がのることはないだろ。使い道ないし。

すみません、こちらのスレでこの方を引き取って頂けませんか？
http://pc8.2ch.net/test/read.cgi/tech/1140510670/117-

>>537
ごめん、ビット論理（pandとかpxor）やシフトとかのごく一部だけかもしれん。また機会があったら試してみる。

リンクエラー？コンパイルエラーじゃなくて？

>>539
スレ違い

要約すると、彼はいま1024*768画像の合成に5秒かかっていて、
それを100msで処理したいそうです。

どうやれば５秒もかかるんだ？

実は３次元なんじゃね？XGA×奥行きｗｗｗ

リンク先読まずにレスするが
なんで糞質問糞レスをしてる暇は湯水のようにあるくせに
4900ms程度を待てないようなバカが平気で生きてるんだろう？

ホント避妊は大事だよな。

自分の頭で計算して5秒かかるのを
コンピュータに100msでやらせたいってんなら
ある意味すげえけどな。

脳と比べりゃもっとはえーだろ

>>546の脳はノイマン型

ざっと読んだだけだがAPIコールしすぎとかキャッシュコヒーレンス無視すんなとか
基本的なとこでずれてる。

>>539
質問スレに誘導した方がいいね。

内容うんぬんより、質問者の質問の仕方に問題有りそうだ。
『こうすれば解決するはず』と思いこんでいて解答者が
求める情報を出し渋るパターン。
他、解答者が求める情報を『問題とは関係無い』と出さなかったり。

まだ続きそうだったら↓のスレに案内するのはどうかな。
(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

>>549
>(1)C統合・質問スレッド
>http://pc8.2ch.net/test/read.cgi/tech/1068359871/l50

ちょｗｗｗｗそれC#のｽﾚだからｗｗｗｗｗ

# なんかｽﾚﾀｲに"#"を使うと消えちゃうらしいｗ

volatile

それの次スレ作る時は

C・しゃーぷっ　統合質問スレッド

で解決だな

>552
なにかデジャブを覚えると思ったらおじゃ魔女だったorz

TextSS　のWindowsXP(Professional)64bit対応化おながいします

もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？

そういや64bitにネイティブ対応している２ｃｈブラウザてありましたっけ？

スパム乙

unsignedをつけると高速化する可能性はありますか？

あります

可能性は常にある。

inlineですら可能性に過ぎないからな。

でもまあ、ほとんどの場合変わらんだろ、符号有無じゃ

いや、比較命令が少なく済む可能性がある。
　　　　　　　　　　　　　　　　　 ~~~~~~~

while(i > 0) はunsignedだと速くなる可能性はあるな。

while(i>=0) なら確実に早くなるぞ。

いや、CPUの命令セットによるから、確実はあり得ない。

>>564
お前ならいったいどんな条件を機械語で書くのか、小一時間問い詰めたい。

>>564
例えば条件分岐の非成立の直後のみ無条件分岐の予測に成功する処理系とかか
存在するのか?

っていうか、コンパイラの最適化依存だから、確実でもないだろう。

最適化というオプションが備わってるのに、これで
条件分岐のコード吐くようじゃなんの意味もないな

ただ反論したいだけちゃうんかと

いや、逆に賢いコンパイラでループを展開するなんて可能性も。

無限ループを展開？

ごめん、よく見てなかったｗ

563を否定する可能性を見つけた。

Z80系のCPUは無条件ジャンプよりも、条件ジャンプの方がクロックが短い。
(条件成立時は同じで非成立時が短い)

do { i--; } while(i >= 0);

これがZ80ではsignedの方が速い可能性がある。

まぁ、ループを抜けるとこまで考えなくても、Z80では無条件ジャンプも
条件ジャンプの成立時もクロックが同一なので、ループの判定が
コストフリーの場合は速くはならないな。

>>573
>>569

>>556
このｽﾚでは、一般論は無駄。
まずやってみろ。

unsigned int a,b;
で
b=a/2;
と書くと、シフトにしてくれる
signedだと無理。

>>576
お前の使っている処理系では、だな。

>>576
日記乙。

だから可能性なんだろ？

>>577
意味わかってる？

実際にそういう処理系が存在したので
可能性がある、という意味では必要条件を満たした

"arithmetic shift" でググってみよう

Cでは
-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
かな

VC++ 7.1でのコンパイル例。

int 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

もうこの話題やめないか？ｗ
大して意味のある話でもないし。

たしか、2進数を使ってない奴は、昔に組み込み系であったような記憶があるが、
まあ、普通の人はそんな事は気にしなくても大丈夫だ。

そういう結論でいいだろ。

負数の除算の丸めは未定義じゃなかったっけか？
C99で初めて定義されてた記憶があるんだが。

未定義ではなく処理系定義

負数の除算如きでいちいち鼻から悪魔が出てきたんじゃ堪らんなあ。

1.
*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ではどちらが速いでしょうか？

1.
MOV 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)

ではどれが一番速いでしょうか？

ｘ86じゃないです

>>590
速度は実測が基本。

CPU とコンパイラの組み合わせで結果が違うだろうから、一般的なことは言えない。

色々試しましたところ、
メモリをクリア＆確認する際に

１．
アドレスに0をセット
0になってるかORしてチェック
アドレスを加算
以下サイズ分ループ

２．
アドレス＋サイズを算出（終了アドレス＋１）

アドレスを減算
アドレスに0をセット
0になってるかORしてチェック
以下サイズ分ループ

1と2で、やってることは似たようなもののはずなのに（ただ単にアドレスを加算してるか減算しているかの違いぐらい）
なぜか処理速度（サイクル数）が異なってました。

原因として何が考えられますか？

>>594
減算にするとループの終了判定が 0 との比較になるので
早くなることが、昔はよくあったものだ。

今時のコンパイラだと最適化かければ差はなくなると思ってたんだが、
どんなコンパイラ使ってんの？その前に最適化かけてないとか？

あとな、
「アドレスに0をセット」はわかりにくい。
文脈から「アドレスの指す位置に0をセット」と読み取るのに時間がかかった。

すみません、言葉足らずでした。
ちなみに終了条件はサイズが0になっているかなので
アドレスの加算や減算とは特に関係はないと思っています。

＞どんなコンパイラ使ってんの？その前に最適化かけてないとか？
コンパイラはSuperH用のコンパイラでSHCというものの最新版です。
最適化はスピード優先でやっています。

アドレスの加算と減算に処理速度の違いはあるのでしょうか・・・
（実際に試した感じでは違いがありました）

>>596
速度は実測が基本。
「試した感じ」ってなんだよ。やる気あんのか？

まだ気になるなら、まずはリストファイル吐かせて
アセンブリソースを確認するのがいいだろう。

SuperH は詳しくないけど、書き込み＋インクリメントが１命令にできて、
書き込み＋デクリメントは１命令にできないとか？

>>594
この部分、

> アドレスに0をセット
> 0になってるかORしてチェック

(*addr) = 0;
if ((*addr | 0) != 0)

ってことですか。 それとも

(*addr) = 0;
if ((addr | 0) != 0)

でしょうか。
*何が* 0なのか解りません。

ようは

unsigned long temp = 0;

*address = 0;
temp |= *address;
address++;
これをサイズ分

もしくはaddressを最初にaddress += size;を行い、終了アドレス＋１を算出後
address--;
*address = 0;
temp |= *address;
これをサイズ分

上記の処理を行ったとき、減算のほうが処理が早かったのです。
クリアサイズは
1024バイトで17サイクルの差
4096バイトで60サイクルの差
でした。

>>599
address の型に volatile 付いてるか？
そうじゃなきゃ temp |= *address は最適化で消えるぞ。

とりあえず、アセンブラコードで消えないように最適化の設定はしましたので大丈夫です

ようは、アセンブラコードを見た際に
アドレスを加算しながら先頭アドレスから終了アドレスまで処理を行うのと
アドレスを減算しながら終了アドレスから先頭アドレスまで処理を行うので
なぜ速度が変化するのかがアセンブラコード上ではわからなかったのです。

MOV @R1+, R2
と
MOV R1, @-R2
の違いでサイクル数が変わる理由です。
値をセット後アドレス加算と
アドレス減算後値をセットでなぜサイクル数が変わるのか・・・
CPUの問題でしょうか？

( ﾟρﾟ)ﾎﾟｶｰﾝ

>>601
君の場合、そういうもんだと思って使え
理由を理解するにはまだ早い。

というより、「回答者を気取るにはまだ早い」人達が
こりゃまずい、手に負えない、でも答えられず放っておくのも格好悪い、と考え、
まるで質問者に問題があるかのような（でもどう問題があるかは言えない）雰囲気を
頑張って作り出そうとしている、というところですかね :-)

だったら君が答えてやれ。と言う事になる。

なにが「だったら」なのか意味不明ですね。
嫌なことを指摘されたので慌てて焦点を変えてみたというところですかね :-)

頼む、教えて下さい。

>>606
お前のせいでさっき食ったソバ全部吐いちまったじゃねーか。

おろろろろろ

>>608
口の中にあるもの全部じゃなく、胃の中全部かいな。
そりゃ難儀やったのう。

基地外が住み着いたか。

自己紹介乙
もう帰っていいよ

・・・で結局結論は誰もわからないっと。

>>599
> これをサイズ分
ってあっさり書いてるけど、ループなんだからここがキモなんじゃ?
他にも一度で書くのは1バイトなのか4バイトなのか、とか。キャッシュの乗り方が
違ってくるし。
SHはワード未満のバイト単位のアクセスにペナルティがあったりしない?

>MOV @R1+, R2
>と
>MOV R1, @-R2
>の違いでサイクル数が変わる理由です。

と書いてるけど

>値をセット後アドレス加算と
>アドレス減算後値をセットでなぜサイクル数が変わるのか・・・

命令だけでなくて順序も違ってるし。パイプラインがストールするんじゃなくて?
どちらかというと、アドレス生成後にストアする方がペナルティありそうだけど。

>>601
http://japan.renesas.com/fmwk.jsp?cnt=superh_family_landing.jsp&fp=/products/mpumcu/superh_family/
↑ここからたどったドキュメントにはアドレスをデクリメントしながら書き込む命令は
見当たらなかった。597 が正解なんじゃないかと思うんだけど、コンパイラの吐いた
アセンブラコード見たんだよな？
ほんとで MOV R1, @-R2 なんて命令あったか？

ごめん。よく見たら
アドレスをデクリメントしながら書き込む命令と
アドレスをインクリメントしながら読み込む命令
があった。

アドレスをインクリメントしながら書き込む命令はないってことで、
インクリメントのほうが遅くなるんじゃね？

＞アドレスをデクリメントしながら書き込む命令と
＞アドレスをインクリメントしながら読み込む命令

PUSH / POP か。

昔々、PC-8801とかで、高速に画面を書き換えるために
push を使ったというのを聞いたことがある。

>>617
機能はそのとおりだけどニーモニックは MOV だよ。

（　ﾟдﾟ）ﾎﾟｶｰﾝ

>>618 Z80でいっぱい使った。

const指定で最適化が促進化される理由ってのは何でなんでしょう？

>>622
const 修辞によって値が変わらないという前提を最適化機が得ることによって、
その値を使った式を定数の畳み込みに組み込む機会が増えるから。

恥ずかしながら、定数の畳み込みというものをはじめて知りました。

[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;

アセンブラがわからないので上に例は適当です。どこかで定数使ったほうが早くなる項があるってことで理解しました。
ありがとうございました。

後は、関数の引数、特にポインタ、をconst指定すれば、
関数呼び出しの後でも、メモリが書き換えられてないことが期待できるから、
メモリからのロードをサボることができるなど。

>>625
C にはグローバル変数などがあるので、一般的にそれはできない。
しかし const にまつわる一般的な誤解の一つでもある。

ふーむふーむ、にゃるほど。
もう一個質問なのです。
最適化目的ならば、constはこういう時に使えってものはあるのでしょうか？
例えば、

#define HOGEHOGE (2)
(中略)
const int temp = HOGEHOGE;

↑のような場合であれば、畳込みは起きるだろうなあと思うのです。
しかし、const宣言された変数の内容が動的に決まる場合にも、
定数の畳込みが起きる場合というのはあるのでしょうか？
例えば、

const int temp = pHoge->getHogeHoge();

コンパイラにここまでの解析能力があるのかってのが疑問です。
とりあえず、コンパイラが何をするのかわからないから、値が不変の変数は常にconst修飾しておくべきなんですかね？

>>627
「最適化を目的に const を使うな。」という言葉を贈っておく。

>>627
規格上は、その呼び出しが定数に最適化できれば、さらに畳み込むことは可能。

畳み込みじゃないが、下の temp のように const つきのオブジェクト定義が見えていれば、
たとえ &temp のようなポインタを取っていても >>625 の言うような
関数をまたぐ不変性が最適化に利用できる。

でも const は最適化への効果よりメンテナンス性への効果のほうがはるかに大きい。
おまけで最適化の助けになることもあるよ程度に考えたほうがいい。

>628　>629
なるほどなるほど。ただ、健全に動いているソース部分に手を加えずに、
宣言部分にちょちょっと手を加えただけで、速度が改善できればなあ、って人情で許してください。

思うほど差はないとおもわれ

っていうか、ちょっと手を加える以前にconstでいいのは
最初からconstで宣言しておこうよ。

そもそもconstって概念が駄目だね。
constな変数が基本で、
書込できる変数にwriteとかって修飾子付けるべきだと思う。

>>633
変数なのに・・・

const変数
write定数

>>633
そして究極的には書き込みという概念が無くなって関数型言語に向かう、と。

>>601
のいってることを、自分のあいまいなマシン語の
知識で考えてみた。次の処理アドレスの入った
レジスタがあったような気がするけど、それでも、
終了アドレスから先頭アドレスまで処理するって
のは、そもそもできるんだろうか？知りたい。

あら、もうおわってたんだ。すんません。

>>630
いまどきのPCで動くプログラムならばその程度では速度は大差ないと思うな。
そんなことよりもアルゴリズム見直すとか I/O 関係で非効率な入出力をして
いないかを調べた方がいいと思う。

constは定数に使うよりも、

void copy(int*dst,int*src,int n){
int i;
for(i=0;i<n;i++) dst[i]=src[i];
}

この関数のsrc[]をconstで修飾すれば、
dstとsrcのエイリアスがないと思って
ループアンローリングしてくれんじゃね？

どうだろうね。memmoveは片側constだけどエイリアスあるし。

>>640
それは restrict の仕事。

VC8なら __restrict を付ければ・・・・

って思いっきり環境依存でした。スマソ

restrictってC99でやっと仕様にはいったんじゃない？
しかも、HPのコンパイラなんかでは最適化上無視してるとか
書かれていたような

>>644
>restrictってC99でやっと仕様にはいったんじゃない？
是。

constってのは、組み込み系からの派生概念と聞いた覚えがあるけど、そうなんかな？

>>646
なんか聞いたことあるな。オブジェクトの配置を ROM にするかどうか
制御する手段が無いと困るから、自然な流れにも感じる。

その頃からnoaliasって候補もあったな。

Ritchieの「氏ねや、noalias！」
http://www.quut.com/c/dmr-on-noalias.html
付録に「noalias v.s. restrict」
http://www.lysator.liu.se/c/restrict.html

>>647
でも、constなインスタンスもmutableなメンバを持てるでしょう？
その辺...なんか、面倒くさそうだなあ、って思う。

しかもコンストラクタ・デストラクタではconstかどうかという区別が存在せず、
constなオブジェクトでもコンストラクタ・デストラクタでは自由にメンバを書き換えられる。

>>649-650
そういうのは ROM に置けない。

mutable についてはコンパイラが簡単に判別できるだろうけど、
コンストラクタとデストラクタについては、賢く判別するのは難しい。
現状では、 non-trivial なコンストラクタまたはデストラクタを持つクラスは
ROM に置けないという保守的な判別で済まされると思う。

現状ではセクション単位でどれを ROM に置くかってのが簡便でいいんじゃね？
大規模なのは知らんが。ギガビット ROM 程度でやってるうちの会社じゃ問題ないよ

ROM上にオブジェクトをコンストラクト（新規作成）するってのは、
何か根本的におかしい気がするんだが

>>653
整数いっこをラップした固定小数点数クラスの配列を
ROM に格納したいと考えるのはおかしくないよね？

ただ定数式初期化じゃなくて、
コンストラクタ呼び出しのある場合は、
コンパイラ判断難しいよね。>>651

>>655
どういう場合を言ってるのかわからない。

vectorは通常の配列のように使う限りは
基本的にスピードの点では配列と変わらないと考えて良いのでしょうか？

>>657
そういう実装もできるのは確か。
しかしスピードは実測が基本。

BCC5.5からVC2005に乗り換えたのですが
VCではループやgotoをインライン展開できるのですか？

BCCでは「for while goto switch 一部のif」は
インライン展開しませんが、VCはやっちゃってくれてるんですかね！？
インライン警告が出ないので本当にインライン化されているか不明なんで聞いてみました。

>>659
インライン展開するほうがよいとコンパイラが判断すればインライン展開される。
そこにループだろうと何だろうとがあろうとも。

まあじですか！？
神ですな

むしろループ如きでインライン展開しなくなるBCC 5.5が古いというだけ。

ソート関数書いててさ、基数ソートなんだけど、
static unsigned int aryA[ 1024 ];
void radixSort( unsigned int *src, unsigned int num )
{
　　unsigned int aryB[ 1024 ];
　　...
//細かい突っ込み禁止
}
みたいな時にAとBで速度が違うんだけど、
Aが速かったりBが速かったりするんだよね。
スタック領域か、静的領域かの違い(?)だと思うんだけどさ、
要素数は少ないことが分かってるんだけど、
どっちがいいのかねぇ。
個人的にはstaticの方がいいような気がするんだけどさ、
いや、マルチスレッドだと使えないのは分かってるけどさ、
最適化って難しいねぇ。

その程度の知識しか無いならそんな最適化は必要ない。

すげえマジレス

レスがあると思えばただの煽りかよ。
確かに知識はないさ、趣味だし。
でも知識がなくても最適化の必要性とは関係ないしな。
もっと生産的なレスを頼むよ。

>>663
つ関数内静的(Static)変数
それはともかく、自分でアセンブリ出力を見比べてみたらどうだ？

アセンブリの出力方法がわかりません！＞＜；

(664に戻る)

その程度の知識しか無いならそんな最適化は必要ない。

すげえマジレス

レスがあると思えばただの煽りかよ。
確かに知識はないさ、趣味だし。
でも知識がなくても最適化の必要性とは関係ないしな。
もっと生産的なレスを頼むよ。

>>666
俺もそんな知識はないが、そんなレスができる奴に惚れた

速度に関しては実測するのが基本だろうに
そういう手間を惜しんでる奴が「生産性」とは片腹痛い

そういえばおまいら、速度チェックはどうしてますか？
バウンドチェッカ使ってるやつが多いのかね

あれはメモリリークだったっけ？

素数かどうかを高速で判定する方法を教えてください

ほい

http://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

最適化というか、アルゴリズムの問題で、過去にえらい人がいっぱい研究してますよ。

C++はPascalなどと比べてコンパイルが遅い。

>>680
includeが悪いと思う。importさえあれば。
( Objective-C にはimportがある...と聞いて色めき立ったが、
　偽物だった.... )

>>663
どういう条件で、なん%くらいちがうんかな。
ソート対象のデータの並びとか片よりとか、
何によって差が出るのかがはっきりしたら、
事前にデータを走査して、どっちを使うか決めたらいいんじゃなかろうか。
つか、基数ソートか。O(n)の走査も馬鹿にならんな。

aryAを使うようにするんなら、
void radixSort( unsigned int* src, unsigned int num, unsigned int* tmp )
見たく、作業用配列を外部から指定するようにしてもいいかもね。

そりゃアドレスがロード時に固定される静的変数と、アクセスするときにスタックポインタ＋オフセットを計算する必要がある自動変数で多少の速度差が在るのはあたりまえだろ。

>>683
どっちが速いの？

>>683
ぶっちゃけアドレスの計算は関係ない。
むしろキャッシュの効きの問題で静的領域とスタック領域を
交互にアクセスしたりすると最悪。

>>683
それいつの時代のコンパイラ?

CPUじゃなくてコンパイラなんだ

>>686
いつの時代だろうと、スタックフレームからのオフセットを
ループ内で何度も計算しなおすコンパイラなどありません。

>>688
8080用のCあたりかと

>>688
最適化のないコンパイラ、普通にあったよ。
そもそもが自分で色々やるための
算術可能なポインタ, ++/--, registerだったわけだし。

そもそも、コンパイルが遅いという話で、
なにかが錯綜してる。。。。。

このスレで遅いというと、頭に血が上るということか。ｗ

行列のサイズをテンプレート引数で指定する行列クラス作ってたんだけど
部分的特殊化によるループ展開やら
戻り値最適化関数やら用意してやってたんだ。
ところがほとんど効果がないのな。最高でも１０％ぐらいしか差がでない。
で、VC8でSSE2オプション指定したら
１００倍早くなって腰がぬけそうになった。
ついでに俺がガリガリ最適化したコードと
普通に二重ループするコードの速度差がなくなった(A')

ようするに、最近の最適化性能はすごいと？

最適になるコードの組み合わせが把握しにくいほど複雑であるという事じゃないの

１００倍違う？展開したコードをちゃんと見たんかい。
ハードウェアが一緒で変わらないままなのに速度が１００倍も
違うなら、最適化で消えていった部分とかあるんだろ。

常識で考えろ。

>>696
SSE2の有無が違うだろ。

まったくだｗ

非MMX,SSE1,2からSSE2指定で100倍ならありえない話じゃないよな。
でもSSE1からSSE2で100倍はあまりなさそう。ありえなくはないけど。

展開したコードを見たのか？って聞くのは間違ってないが
とりあえず696は今すぐアナルうｐ

倍精度使いまくりならありうるとは思うがな。

C++/CLIスレで聞くべきかともおもったのですが
こっちのほうが技術レベルが高そうなので質問をさせてください

一般的にマルチスレッドを使っていると変数がレジスタに
割り当てられにくくなるかと思いますが、GC機構を採用している
C#やJavaなどはある変数を参照している部分がそのローカル関数内に
限定することができないので最適化が発揮しづらくなるのじゃないかと思います

しかしながらC#や最近のJavaは、C++の速度に匹敵するといわれています。
それはどうしてですか？

>一般的にマルチスレッドを使っていると変数がレジスタに 
>割り当てられにくくなるかと思いますが
何故？

SSE2をONにしたから速度が100倍になるって、例えばどんな場合が
あるんだろう？
FPUを使ってエミュレートすれば100倍も差が付かないと思うんだが。

レジスタの本数、モデルの違い、使用するユニットの違い、デコーダの違いetc

>>702
マルチスレッドを使っているプログラムだと
同時に2カ所から同じ変数にアクセスされる可能性があるから
必然的に変数をレジスタに割り当てることができない。

ついでにいうとヒープ上にしかインスタンスを確保できない言語の場合は
どうがんばっても微々たる最適化しかできないと思うんだが
俺の認識がちがうのか・・・？

いや、スレッド切り替えるときにはレジスタ退避するから。

register記憶子を完璧に誤解している奴が現れたか。

>>701って結局何が言いたいん？
話の前後はまったく繋がってないわ。1文がやたらと長いわ。
まったく意味が理解できないんだけど。

いや、勘違いしてないわけだが。
誤解されているようだが、コンテキストスイッチの話をしているわけではないぞ。

最適化してコンパイルすると、メモリ上においておける変数は
極力レジスタに割り付けるようになっていると思うんだが、
それはスタック上に割り当てられた変数にしかできないよな？

C++/CLIのマネージ変数のように、強制的にヒープ上に配置される言語で
なぜC++並の最適化が可能なのか？
って質問かいただけ

誤　：　最適化してコンパイルすると、メモリ上においておける変数は

正　：　最適化してコンパイルすると、レジスタ上においておける変数は

>>701>>709
マルチスレッドでも、関数のローカル変数はスレッド間で共有されないと考えてよいだろう。
となればそれはレジスタに割り当てて問題ない。
残るはグローバル・静的変数だが、こいつらはシングルスレッドでもレジスタに割り当てられることは無いだろう。
また、ヒープ上へ動的に作成するオブジェクトもあるが、これも当然レジスタには割り当てられない。

つまりマルチスレッドだから変数がレジスタに割り当てられにくくなるというのは間違い。

また、JavaもC#もたしかにGCを採用しているが、どちらもint等の基本的な型のオブジェクトに対しては、
（概念上）スタックに割り当てている。最適化でレジスタに割り当てることはC++同様できるはずだ。

Java/C#でヒープ上に割り当てられるのは主にクラス型のオブジェクトということになるが、
クラス型のオブジェクトは大抵レジスタに収まらない大きさになるので、
C++でローカル変数だったとしてもやはりレジスタに載らないことに変わりは無いだろう。

クラス作ってそれを操作するくらいのことなら、C++/Java/C#で表現できることに大差はないので、
最適化に関しては、どれも同じ性能になって当然。JITの手間やヒープからメモリを確保するのがせいぜいのオーバーヘッド。
最近になってJava/C#の最適化技術がC++のそれに追いついてきたという感じかな。

>>709
で、その話がマルチスレッドだとレジスタ割付がしにくいという主張と何か関係あるのか？
それは単にHeap AllocationとStack Allocationの違いを話しているようにしか見えんのだが。

>>711
void function()
{
static int number=0;
number = ・・・　// いろいろ計算
}
のようにスタティック変数で宣言したものはレジスタに割り当てられないという
ことでしょうか
これがシングルスレッドのコードであることが明示的に指定されて
いればnumberを計算の間はレジスタに割り当てておけると思うのだけれど
現在の最適化はそこまで進んでないってことですね。

マルチスレッドだとレジスタ割り付けがしにくいのでは？という理屈は
このあたりから来てます。

つまりC++とC#/Javaなどの最適化性能に大きな差がない理由というのは
・C#/Javaなどでも基本的な型はスタック上に配置される
・C++でも実際には様々な条件のそろった変数しかレジスタ割り付けされない
・JITの最適化技術の進歩
この３点に尽きるという感じなのかな・・・？

GCを採用している言語ではint型などもヒープに配置されるのかと
考えていました。
なので一回変数にアクセスするたびにメモリアクセスが必要になり
C++と比べて速度が遅いはず

と勘違いしておりました。
実際問題ベンチマークテストしてみても大差がないことを確認しているので
不思議に思って質問したわけです。

>>714
C#なら、IDEからアセンブリとMSILの混合画面を見れるよ。
最適化してもデバッグにしておけばOK。

>>713
そのnumberがfunction内にいる間レジスタに置かれるということは有り得る。
逆にそうさせないためのvolatileというキーワードがあることだし。
そして、それがC++にできてJava/C#にできないわけがない。

>>701
> GC機構を採用している
> C#やJavaなどはある変数を参照している部分がそのローカル関数内に
> 限定することができないので最適化が発揮しづらくなるのじゃないかと思います

勝手に思ってろ呆け

>>715
.Netは若干まだ勉強中のためそんな機能があるとは知りませんでした。
ありがとうございます。

スレ違いになりそうなのでC#の話題はこれくらいでやめておくとして
>>716
のような話があるから最適化してスレッドを使うときは気をつけなければ
いけないわけですが、C#/Javaではそこまでの最適化は行われていないのか
上記の問題はおきていませんよね
iccなどのちゃんとしたコンパイラを買えばC++でも心配無用なのかな

時間とれるときに自動変数、スタティック変数、グローバル変数などで
違うコードが出力されるのかどうか試してみます。

>>717
市ね呆け

>>718
馬鹿の考え休むに似たり

とりあえず、最近のJIT, HotSpotがどれだけ激しい最適化しているか、
IBMのサイト辺りで勉強して。

713のコードでは、最適化でまずくなることを心配することではないだろ。
普通クリティカルセクションか何か排他制御するところだろ。

あー、なんというかあきれる。たぶん、自分のことを知識はまだ無いけど賢い
人間だと思ってるんだろうけど、これまでのやりとりを見る限りそれはないか
らもうちょっと態度考えた方がいいと思う。

もし君が国立の学部生なら、周りにこの程度のこと説明できるやつ絶対いるは
ずなんでまずはそのひとに聞いていろいろ教わった方がいいと思う。ネットの
書き込み経由で勉強するには少し頭が悪い気がするので。

目くそ鼻くそを笑う

大抵、説教はあとで読み返すと恥ずかしいこと書いたなと気づくもんさ

>>718
プログラミングは想像や心配じゃなくて言語仕様やら実行環境の仕様や実装を元にして行った方がいいですよ。

マルチスレッド、マルチ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に従う、という風に。

コンパイラでできる最適化なんぞ精々2倍がいいとこだし
そもそもクロック単位の話をするのは最後の手段。

ここにいる奴らは当然アルゴリズムを極限まで最適化したうえで
話をしているんだよな？

なんかまた頭悪そうなのが湧いてきましたよ。

夏ですからね。

2倍って何の話だろうな。
ジャンプの漫画じゃあるまいし。

ならば俺は3倍界王拳

gccでさえ再帰をtail jumpに書き換えるのに…

そもそも何を基準に2倍なのか。

倍率ドンの更に倍

Pentium 4 の上で Visual C++ 7.1 使っているのですが、
同じ計算をする場合、float と double のどちらの型を使うほうが高速でしょうか？

>>735
速度は実測が基本。

double

float

とりあえずこういうコードで試してみたら、速度はほとんど同じだった。

__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;
}

>>739
計算時間の殆どがsin()とcos()に取られそうだが。VC2005なら
sinf()とcosf()を使うと違ってくるんでないかい？

>>739
> とりあえずこういうコードで試してみたら、速度はほとんど同じだった。
「どちらも一瞬で終わりました」だったらｳｹﾙｗ

このスレは本当に C/C++ の最適化の話をしているのか？

どうせアセンブラ厨が自己満足のために立てたんじゃないか？ｗ

>>658
いやvectorは仕様できまってるはずでは。

>>743
それはメモリレイアウトが決まっているって話だろ。
メンバ関数やイテレータでどれだけのオーバーヘッドが加わるかは実装依存。

一応O記法で条件は定められているけどな。
まぁ、どうせそれで速度が決まるわけではないし。

>>735
ttp://www.tietew.jp/cppll/archive/11793

>>735
double

検索でこのスレひっかかったので蒸し返してみる。
int32_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 がインライン展開されるとこいつになるのか、、、

その最適化は最適か？

doubleとfloatでは演算速度も違いますか？

自分でベンチ取って調べろ。

どのみちFPU上ではdoubleだったりそれ以上に変換されるんでどっちでも大差ないとか
最近のCPUだとCPUの演算速度よりメモリのアクセス速度のほうが重要なんで
それなりにでかい配列とかだとメモリ消費量の少ないfloatのほうが有利とか。

SSE2使うと、floatだと4演算、doubleだと2演算実行だから、floatの方が速いだろうね。

四元ベクトルの正規化をSSEで書いてみたのだけど
D3DXVec4Normalizeのほうが早くてがっかり。
どうなってるんだと逆アセンブリ見たらD3DXのほうは3DNow使ってて、
使ってるCPUごとに命令セット変えてそうな感じだった(ジャンプテーブルをはさんでいる)

アセンブリを比較する限りだと
内積計算するためにfadd使いまくりだった点が決定的に違うのだけど
pfaccに相当する命令ってSSEには無いのかな

このスレ的には常識なのかもしれないけど
内積で上手い手法は無いのかと探してたらIntelの最適化のpdfに乗ってたので
それいれたらアッサリD3DXより早くなってしまった…
やっぱりメモリオペランドを取り捲ってたのを取り払ったお陰なのかな？

そーすきぼんぬ

>>755
いや、ほんとたいしたもんじゃないす
擬似コードでアレですがこんな感じ(同意味の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) );
}

あと内積のほうはIntelのソースのぱくりなんだけど

float4 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;
}

のほうが命令セットは多くてもペアリングできてるんで高速に動いてたような気はします
ちゃんと時間計っていませんが…

これで最後です。最初の遅かった奴はこんな感じ

float4 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は精度向上のための専用命令があるからその差がでかいのかな

とりあえずループアンローリングとかで
並列度上げないとまだ遅いんじゃないかね

ループアンローリングは全然頭に入れてませんでした。
命令セットレベルで入れ替えしてくれるのかな？＞MSVC

でも正規化みたいな処理は突然1度だけ現れるみたいな処理がほとんどなので
あんまりそういう最適化を期待してもなぁ…っていう感じではありますが

何度も呼ばれないなら最適化なんて不毛…

>>761
トータルで見たら何度も呼ばれるけど
その関数が局所的に何度も呼ばれることが無いって話ですよ。

ローカル変数の方が最適化されやすいの？

うん。

ローカル変数は、基本的にはレジスタが割り当てられ、
上手くすればレジスタ間のみの演算で済む。
グローバル変数にすると、必ずメモリ間のやりとりが
はいるので、その転送時間は相当に大きい。

局所的にしか使わない変数がある場合は
適当にブロック作って
ブロック内先頭で変数宣言して使ったりすることもある。

＞ 局所的にしか使わない変数がある場合は
＞適当にブロック作って

まあ、最適化にはあんまり関係ないけどな。

>>765
> グローバル変数にすると、必ずメモリ間のやりとりが
> はいるので、その転送時間は相当に大きい。

いつのコンパイラやねん。
90年代はじめにはそんなコンパイラ淘汰されたわ。

>>766
c++だとデストラクタ呼び出しのタイミングが変わるから
スタック消費量が変わるぞ
とはいえそれくらいか

>>768
その場合はオブジェクトへのアクセスがあるんだから
最適化にならないでしょｗｗ

>>768
関数内のブロックに入ったり出たりするタイミングで、ローカル変数の領域を、
縮めたり延ばしたりするコンパイラって、あんまりないとおもうぞ。

>>770
Cの頃から再利用するコンパイラはあるよ。

func1()
{
　{
　　A a1;
　}
　{
　　A a2;
　}
}

func2()
{
　A a1;
　A a2;
}

func1のほうがスタック消費量は少ない。
スタック消費量が少ない＝キャッシュヒット率向上ってことで。

具体的に処理系とアセンブリ晒せ

vc8, gcc3.4.4(cygwin)

>>772
you mean assembler?

アセンブラ晒してどうするよ。 gas 使ってますとか、 MASM 使ってますって言ってもねぇ。

>>771
gccで簡単なコードを書いて見てみたけど、そんなことはやってなかったなぁ。。。
そういう最適化をする条件って、なにかあるの?

簡単なコードを書いてみたら、スタックサイズが小さくなってたよ。

ブロックの出入りのタイミングで、スタックを伸び縮みさせるってわけじゃなくて、
領域の再利用ってことか。
まあ、でも、うちの環境で簡単なコードを書いてもぜんぜんかわらなかったな。
ローカル変数がデカかったりしたら、そういう最適化でもするのかね?

スタックポインタの計算回数が少いほうが速いよ

プログラムがCPUのキャッシュ内に収まっているかどうかはどのようにしたら分かりますか？

VC++はブロック区切ろうと区切るまいと使っても変数のスタックの消費量かわんないよ
関数の先頭でスタックに全部確保しちゃう。

動的オブジェクトのデストラクタの呼び出しのタイミングと変数のスコープだけは変わるだろうけど。

>>780
実行クロック数を計測する。

キャッシュに収まってるか収まってないかでレイテンシの桁が違うはずなのでよくわかると思うけど。

>>781
団子ちゃん、どうしてそんなこと知ってんの？

/FAs

>>781
変わるよ。

>>784
単に、アセンブラの結果を見て、たまたまそーなってたってこと？
それじゃ、必ずしも >>781 のようなことになるとは限らんってことでおk？

ちなみに2003でしか確認してない。

さっさとコード晒せよ

>>787
2003でも違う結果になる可能性が十分にあると思うんだけど。

2003, 2005両方で変わるよ。

>>790
>>781 の最後の一行に関しての話なら、C++として当たり前の挙動。

>>791
変わるのはスタック消費量。

>>792
じゃぁ、団子ちゃんが適当なこと吹いてたってことでFA？

オプション買えてみる


とりあえず配列なんだけど

すまん、どうやっても別々に確保してるんだが。

>>795
別々ってどういう意味？
スタックの消費量が実は変わってましたって話？

いや。スタックを再利用してない。

cygwinのgccでは再利用するな
vc2005では再利用しない

ヒント：>>771の A を、ある程度のサイズの構造体にする

gccは再利用しない
g++はする
vc(2003/2005)はc/c++どちらもする

面白い

【ネガティブ派遣根性チェック】

3つ以上、思い当たる点があればアナタの性格はひん曲がっており、ネガティブ負け組人生を歩んでいます。

□偽装派遣先の社員の意見にはたとえ間違っていても反対しない
□偽装派遣先から「いつまでもここで仕事してくださいね」と言われるようになりたい
□自社に仕事を持ち帰れるように言われるとムカつく
□自社で仕事なんてできるわけがない
□派遣/受託の差異を指摘する人間はムカつく
□偽装派遣先には仕事だけでなく自分のプライベートについても指示して欲しい
□自分の月額金額を知らない
□偽装派遣先社員より自分の生涯収入が低いのは当然だ
□偽装派遣先に尻尾を振り、いつまでも一緒に仕事をすることが大切だ
□今のプロジェクトが終わっても同じ偽装派遣先に常駐したい

Cではauto変数のextentが実はハッキリ定義されていなかったりするんだろうか
C++はデストラクタ呼び出しの順番があるから明示されたけども

constをローカルで宣言するより、グローバルで宣言した方が高速なのは仕様ですか？
constならどこで宣言してもプログラム内では単に定数になるだけと思っていたのですが・・・

「定数」にしたいなら　static const

自動変数にconstを付ける意味は、コンパイル時に書き換えやろうとしたらエラーや警告を出してくれるだけ。
あとはループの最適化指示とか。

コード晒せ

配列でも宣言してるんじゃねーのかｗ

試してみた。

/* 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)

続く

続き

$ 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もたぶんしない

VCはシンボル数が有る程度多くなると途端に馬鹿になるんだよ
だんごさんは１関数内に変数が200以上あるソースを平気で触ります

追試

環境は一緒

/* 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));
  }

続く

続き

  puts("");
  {
    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

まだ続く

まだ続き

$ ./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

さらに続く

$ ./stack2.gccO2.exe
./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++で順番が入れ替わってるのが気になる

2005もANSI APIが遅くなきゃさっさと乗り換えるんだが

>>814
遅いってのはマルチスレッド用ライブラリしかないってこと？
なんでANSIだけ遅いの？UNICODEとどう違う？

とにかく文字列関連のAPIが絶望的に遅い。
UNICODEに変換して処理するからっぽいけど、2003まではそんなことはなかった。

逆にUNICODE API利用時のパフォーマンスは上がってるっぽいのでまあ察しの通りでしょう

>>816
????よくわからん
msvcr80.libのnarrow charの関数が内部でUNICODEに変換して〜W()を呼び出すってこと？
それなら/MDでmsvcrt.dllにリンクすれば今までと変わらないよねぇ

出来れば簡単なベンチとテストソースキボン

ダンゴのいいかんげんさに笑った
あんまり信用できんな

あんまり、どころじゃねえよ
俺は最初からあぼーん登録してる

これでいくわ

>>820
じゃぁ、今度から団子ちゃんじゃなくてケンチャンって呼ぶね♪

トリップを考慮しない辺りが……

ﾓﾂ煮ﾀﾝとの共有ﾄﾘだけど

>>団子
ANSI関数が遅いのは結局妄想？

>>団子
VCがスタック再利用しないってのは結局捏造？

>>824
http://d.hatena.ne.jp/NyaRuRu/20060227/p1

>>825
具体的にはhttp://www.darkside.com.au/bitslice/
のdesevalをforceinlineで全部変数展開して実行してる。
少なくともVC2003では超がつく糞コード吐く

↑の場合ANSIってよりはMBCSかも

forceinline(笑)

> forceinlineで全部変数展開
> 超がつく糞コード吐く

かわいそう

お前初めてかここは？

>>826
std::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は使わないから知らん

そりゃsstreamの使い方がド下手なだけだな。
cppllあたりの過去ログでも嫁。

>>832
下手でスマソ、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だと特にひどい。しかも全体的に遅いし。

もうCでパフォーマンスうめぇｗｗｗっていう時代は終わったんだよなぁって感じがする

55 名前： デフォルトの名無しさん [sage] 投稿日： 2007/01/22(月) 22:51:26
>>53
1の開発環境はWindowsだと思うのでx86。
スタックポインタの場合、[esp-8]などと一発でアクセスできるが、
そうでない場合[eax]とアクセスする前にeaxにポインタを格納する手間が要る。
もしくは、eaxをポインタに占有されて使えるレジスタが減ってしまう。

60 名前： デフォルトの名無しさん [sage] 投稿日： 2007/01/22(月) 23:08:00
>>55
例えば mov edx,[MemAddress] と言う形式の指定方法があるので、
わざわざアドレスをレジスタにロードする必要は無い。


俺は55だが、なるほど、MemAddressは即値なのね。
あらかじめアドレスはわかってるようにできるものなの？

データの位置の決定、アドレスの数値決定はリンカの役目。

命令が相対アドレス指定なら、リンカはそのまま値を確定してしまうし、
絶対アドレス指定命令の場合は、普通は実行形式にアドレス再配置
情報が記録されて、実行前にOSが絶対アドレスを全部補正するはず。

>>836
アドレス再配置とかすごいな。
俺の方が勉強不足だったようだ。

質問になってしまうが、グローバル変数のアドレスを決めてしまって
mov edx,[MemAddress]式のアクセスで高速化というのは、あり？

C++のようにライブラリが重い言語が盛んに使われるように
なったので、重くなったソフトを軽々と動かすためにCPUの
高速化が必要になった希ガスｗ

>>837
それはレジスタに置いておく代わりに mov edx,[MemAddress] という事？

メモリから読む場合は、データをとってくるのに時間がかかったり制限も色々あるので、
出来る限りレジスタに残しておいたほうがいいと思う。

mov edx,[ebp-8]とどっちがいいかという話なら、実行コストはちょっと分からない。
詳しい実行コストが知りたいのなら↓のスレあたりが詳しいのでおすすめ。

x86命令の所要クロック計測スレPart3
http://pc10.2ch.net/test/read.cgi/tech/1168399966/

>>837
あり、というより大抵のコンパイラ・リンカはそうしていると思う。

>>839
いや、おいらはグローバル変数のアドレスは決まってないと思っていたので、
数字を決めておくのと決めないのと、どちらがいいのかと思って。
>>840ということなので、決めた方がいいようですね。
おいらはそのスレの住人なので、まず周辺を勉強し直してから測定してみまつｗ

>>839>>840ありがとうございました。

>>841
決まってる。
ただしプロセスローカルな仮想アドレスでの話だけど。
IA-32ではアドレス空間は仮想化されてて別々のプロセスでも同じアドレス値を持てる。
ただし他のプロセスのメモリ空間へは普通の方法では直接アクセスできない。

マルチスレッド化とか考えるなら、なるべく使わず自動変数とか、構造体を
アドレス渡しして操作したほうがいい。
多少命令長が増えるが[ecx+OffsetAddress] みたいな相対アドレス指定のほうが
何かと便利。

セットしたい値が決まってるなら即値使った方がいい。
これは特に意識しなくとも最適化でそうなるが。
なによりグローバル変数はバグの根源。定数ならまだいいが。

>>841
ちょっと整理しておこうか。
・ローカル変数はスタックに置かずにレジスタに置くかも知れない。
・グローバル変数は(必要となる範囲の先頭で)レジスタに保持してしまうかもしれない。
#一般的に最適化は関数単位だから、関数脱出までには書き戻すはずだが。
従って、グローバル変数だから速いとか遅いとか、一概には言えない。

また、関数への引き渡しに際しても、インライン展開できるコンパイラでは
呼び出し元のローカル変数をレジスタにキープしたまま呼び出し先で参照するかもしれない。
この点でも、グローバル変数の方が速いとは言えなくなる。

ローカル変数はスタックにおかれるから、
キャッシュヒット率が高いことが期待できるよ。
もはやこっちのほうが重要。

あと命令長は考えても無駄。

長いパイプラインを持つCPUを使い場合、プログラムでどうしても分岐(if文)を
書かなければならない場合、最初に持ってきた方がよいのですか？
それとも最後に持ってきた方がよいのでしょうか？

試して貼ってくれ。

400ｍ位?

極東から1ﾏｿ�`くらいあるでしょ？

これはダンゴ先生を呼ぶしかない。

>>845
IntelのCPUならこれを読め

IA-32 インテル(R) アーキテクチャー最適化リファレンス・マニュアル
http://download.intel.com/jp/developer/jpdoc/IA32_Final_i.pdf
2-14 静的予測

ダンゴを召喚するな
って言うと来てくれるよ

ホロン部です

むっ、明日の早朝に、下半身に性的予測あり。

a=a+1よりa++の方が速いと言いますが、a=a+1のようなコードに出会ったときに、自動的にa++に変換して最適化してくれるような
賢いコンパイラは何故無いのでしょうか？

> a=a+1よりa++の方が速いと言いますが

どこのロートルがそんなこと言ったのよ
そんなんでコードの効率が変わるようなコンパイラなんていまどき有りません

>>854
逆に寧ろ、a = a + 1とa++で違うコードを吐くコンパイラをご存知なら教えてください。

って言ってやれ。

しかもネトバの場合 inc より add の方が速いし。

アレだろ。頻繁に使う変数にはregister宣言した方が速いとかいうロートルだろ。
実際は最適化を阻害するんだが。

>>854
a++より++aの方が速い。
賢いコンパイラなら変わらないかもしれないが。

>>859
組み込み型に限って言うなら、
a++; と ++a; で違うコード吐くコンパイラ知らない。
b = a++; と b = ++a; なら違うだろうけど。

aの型に関してなにも想定せずに速いとか遅いとか言ってもナ。

なるほど、++と+=演算子に別の関数がオーバーロードされてるクラスのインスタンスなのか


ねーよｗｗｗｗｗｗｗ

++ -> マジックインクリメント
+= -> 文字列の結合
だったとしたらどうするつもりだ。

組み込み型に関しても、a++が++aより速くなる可能性は0だから
前置でいいところは前置で書くべきだな。
ループはwhile(a++ < b)よりもwhile(++a <= b)にすべきだな。

ループはdo-whileだよな

でも、最近、コンパイラ毎の最適化評価情報ってあまり聞かないな。

SPU-GCCが意味不明なコード吐きまくるから困る

自分で直しちゃえ

無理だってばｗ

rtx の頃はやらないと使い物にならなかったからやったけど
今のは複雑らしいから大変だろうねぇ

>>864
>a++が++aより速くなる可能性は0だから
それが式中ではなく単体で使われてれば、
a++が++aより遅くなる可能性も殆どないですが。

>>871
可読性を落とさずに速くなる可能性があるんだから、a++を使う意味もないだろう。
ユーザ定義型だと最適化も期待できないし、前置++を使う癖を付けておくことは
悪くないと思うけどな。

バリバリC++のoperator使いだからa++の非効率さは知ってるんだが、a++の方が好きだなあ。
inc(a)よりa.inc()の方が分りやすいと思うのは日本人の性？

後置はむしろ使える場面でも使わないな。紛らわしいから。

>>873
そういう合目的的でない直感を排していけない人は、
プログラマに向いてないと思う。いつか必ず落とし穴になる。

Rubyで++をうっかり使ってパーズエラー

もうここまで来ると子供のだだだが、SIMDとかで
A(B(C(D(E(f), g, h)), k))
とかなってると括弧の対応がエディタの機能に頼らないと分らなくね？
対応している括弧が分っても引数が何処の関数に所属しているか戸惑う。

実際の解決はだらだら全部の処理の行を分けて記述する事になるんだが、
f.E().D(g, h).C().B(k).A()
という表記が出来た方がいくらかマシだなあと。
あくまで例だからな。本当にそんな実装するくらいならx86のfvecみたいに演算子作る。

a++と何の関係があるんだって話だが、つまりa++と++aはa.inc()、inc(a)の関係にあって、a++とかa.inc()が使えるならそっち使っちゃうなという俺の腐れ脳内の紹介。

でもa.inc()がaを1だけインクリメントしてくれるとした場合
a++ + bとa.inc() + bは結果が異なるから本当にだだだな。
どうみても妄想です、本当に(ry

a++と++aの違いと
inc(a)とa.inc()の違いって
全然違うところに無いか？

878読んでなかった
スマソ

SSE*でDQWORDのアクセスするとさ

__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`)

>>877
C++なら適当なメンバ関数でreturn *this;しとけば大体希望通りの記述が出来るんじゃないか。
intrinsics＋inlineならパフォーマンス上のペナルティもないし。

"パーズエラー" の検索結果 約 40 件中 1 - 10 件目 (0.21 秒)
"パースエラー" の検索結果 約 35,100 件中 1 - 10 件目 (0.14 秒)

>>883
辞書引くとどっちの発音でもいいみたいだが...

ニューヨークヤンキーズ
カーネルサンダーズ

スティーヴ・ジョブズ


ただ慣用から外れた表記で己を誇示するのはどうかと
それが団子クオリテイか

タイガーズ

ティガー

だんこ

`∀´
エラない状態で指定してもあぼーん出来ません。

レスはたとえばhttp://pc11.2ch.net/test/read.cgi/tech/1084676298/888とか

ごめんなさい間違えました

全体何がしたいのかと。

俺はある方法で確実にあぼーんしてる
書くと対策しやがるから書かないでおくが・・

最近のコンパイラはSSEなどは、自動的に使用してくれるようなのですが、
SSEに優しい、コードの書き方とかってどこかに解説されていませんか？

インテルの技術資料pdfにあった気がするけど
どれだったか思い出せない

http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25112.PDF
これじゃないか？

Array-of-Structures(AoS)ではなくStructure-of-Arrays(SoA)を使えってのが定番だね。
ttp://download.intel.com/jp/developer/jpdoc/apps_simd_j.pdf

コードの見た目AoSだがメモリはSoAに配置にするような
変態c++テンプレート希望

オブジェクト指向に従えば、オブジェクトがいくつ、例えば
CClass a[100]；
の様なやり方が、自然ですが、SoAとOOPをうまく融合する方法はないでしょうか？

SoAなコンテナクラスを作ればいいんだろうけどね。
オブジェクト指向的には、複数のオブジェクトの集まったオブジェクトとして扱うとか。

つまり、リンゴが1つ2つではなくリンゴ袋レベルから物事をとらえろと？

そそ、そういうコンテナクラスがあればってことになってとどのつまりは>898w

SIMD最適化が必要になるクラスってかなり限定されないか。
ほとんどの演算をSIMDで行わないと
mmx(xmm)←→汎用レジスタの変換に時間取られるから、
データの並びをSoAにするだけじゃダメなわけだし。

そうでもない。

そうなの・・・？
でも、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にあるクラスを最初から使うのが
手軽で分かりやすいということになると思うんだよな。

うおっ。何が言いたいのかよく分からんな……

とりあえず、汎用コンテナクラスを作るくらいなら、
必要になってからドメイン スペシフィック(？)にコンテナ作った方が
多分分かりやすいし間違いなく速度は出ますよ、
と言いたかった。

>>903
AMDだけじゃねそれ
Vectorパスでデコードするから使う度にストールする。

つーか、pextrwはロード・ストアユニットを使わないから良いのです。
Core2ならpextrwはレイテンシ3-スループット1でアクセスできるから
ちょっとしたローカルストア代わりに使える。
MM/XMMレジスタで計96個のWORD値を保持できるｗｗｗ
（ちなみにpinsrwはCore 2でも遅い）
ロード・ストアって一番利用頻度高いから、1回の操作で
8個のWORD値を読み書きできる意味は大きい。



と、たまにモグリのソフト屋の集まりでそういうネタがよく出るんだが
実用性には疑問符が。
つか、ここ、うちのオフの参加者いる悪寒
（団子の中の人ってことは知られてない筈だけど）

Pentium4ではpinsrwが4-1、pextrwが7-2だったし、
AMDでpextrw使ったらえらい遅くなったから、
この命令はずっと避けてたんだが・・・
実際はそうでもないのね。

mm/xmmレジスタをローカルストア代わりに使えたら嬉しいなぁ。
pinsrwとpextrwの性能がいいＣＰＵならかなり使えそう。

ただ、遅い石のことも考慮するとそう簡単にはいかないか……
ってか、ほんとにAthlonXPでの遅さは異常。
AMD系だとたしか op reg [mem] 系の命令が推奨されていて、
Ｌ１のレイテンシ-スループットが大抵3-1くらいだと考えると、
素直にスタック使った方が速そうではある。
(いや、たしかにロードストアユニットは使うけどさ^^)

AMDマンセーな自分としては避けたい気分なんだけど、
Intel系でpinsrwやpextrwが速い石ならかなり可能性はありそうだと思った。
当然、要プロファイルだけど^^
とりあえず、レジスタでＬＳな発想自体は面白いと思う。

あと自分はオフの参加者ではないよ。
そういうのに参加したことは一度もない；；

908の補足；
VectorPathについての理解が甘かった。
ちょっとピントをはずしてるぽ。
勉強してきます。

「うちのオフ」がどんなものかにもよるけど、団子クラスの知識が集まっているなら覗いてみたい。

> 団子クラスの知識が集まっているなら覗いてみたい

めちゃくちゃ厨くせえ。だって所詮団子レベルだろ？
願わくばその団子クラスのオタモダチがム板になだれ込んで来ないことを希望。

団子レベルで理解してるほどのハッカーはあまりいないし、なにげに貴重だと思う。

付き合いたいともお知り合いになりたいとも書いてないからな。
厨くさい会話の中に、どれだけ利用できる情報があるやらw
#あると思うのが>910だろうし、ないと思うのが>911なんだろうね。

インテルコンパイラにおけるPGOの手順てどこに載っているのでしょうか？
Webページでも良いので教えてください。

>>913
まぁ910と911よりは「うちのオフ」の面々のほうが有用な雰囲気。

面々に糞団子を含める？

>>914
日本の販売元であるエクセルに問い合わせたら?

Opteronの最適化に関する日本語の資料ってありませんか？

>>918
なさげ。
C/C++だったら、まっとうなコード書いてれば普通に速い。
特別に速くしたいのだったら、英語版の最適化ガイドをいっしょうけんめい
読んでちょうだい。実際にはあまり役に立たないけど。

具体的に困ってるコード例を貼ったら添削してもらえるとオモ。

>>914
エクセルソフトのサイトからPDF落とせるはずだけど？

gccでコンパイルすると、例えばx/10.0はコンパイル時にx*0.1に置き換えられてしまいますが、
これをしないように指示する方法はないでしょうか？O0だとすべての最適化がきかなくなってしまうので
この置き換えだけを抑制したいのですが。

しないようにしたい理由って何？


{
　　volatile double tmp = x;
　　tmp /= 10;
}

↑は確かめてないわ。たぶんこれなら確実におｋ

volatile double Ten = 10.0;

x/Ten

>>921
no fast math とか、そんなん無かったか？

浮動少数じゃないけど関連ネタで

gccの3の途中からか、constant foldingのやりかたがガラっと変わって、
桁あふれや丸めを期待したコードのコンパイル結果が変わって困った、
という話があったような。

x/10*10がxになるとかだったかなあ。

>>925
gcc4.2でやってみたけど期待した結果になるけど？
ひょっとしてこれが4.2の遅い理由？

あーいや、桁あふれのほうだったかもしれん。

うんそれ精度保証だよ。
定数DIVを加算・乗算・シフトで代用するのは大昔からある最適化
DIV命令そのものがない石もあるし。

確実にエイリアシングが起きないようなコードの書き方というのはあるのでしょうか？

>>929
不確実にエイリアシングが起こるようにしたいの?

>>929
エイリアシングって何？

>>931
アンチエイリアシングの逆・・・かと、思ったんだが、
別にここはCG系のスレじゃないし、なんか他に意味あったっけ？

あんまりそわそわしないで

それなんてエイリアンソング？ｗｗｗｗｗｗ
ダーリンおしおきだっちゃ


エスパーするとたぶんこれ
http://docs.hp.com/ja/B3906-90007/ch07s09.html

IntelアーキのL1は8Wayセットアソシエイティブ、つまり同じ下位アドレスに対して
8つのキャッシュライン・エントリを持てる。だからそんなに頻繁に起きるもんじゃない。
AMDは2Wayだから・・・（キャッシュ容量の割に性能良くないのはそのせい）

int a = 0;
int &b = a;
a = b++;

こういうのもエイリアシング問題と言ったような気がする

適切な日本語訳はないのか？

別名化

>>932
エイリアシングはCG用語ってわけじゃないよ。
和訳すると別名とか偽名みたいな意味で、色々なところで使われる言葉。
一番よく使われるのがサンプリング関係で、CGもその一種。

>>935
一語で表すと「別名」以上に適切な言葉は思い当たらないな。
動詞形なら>>936かね。
名前に限ったことではないので、全ての状況で適切というわけではないが…

>>934
それただのエイリアス(別名)。

単に可読性のため意図的に読み替える機能であって、ポインタとは違ってアドレスを変えられない。
従って、予期しない動作はアホでも起こさないから避けるものでもなんでもない。
参照と実体の区別がつかなくなっちゃう痛い子はハンガリアン記法でも使っとけばいい。
そういうのは機能問題であって性能問題じゃないし。
普通に考えて下位アドレスの競合によるキャッシュの性能低下のことだと思うよ。
下位アドレスを自分で選べばいい。
たとえば配列を動的に確保するときに容量を多めに確保しておいて配列の開始アドレスを都度決めるとか。

>>929
C99のrestrict修飾
ttp://seclan.dll.jp/c99d/c99d07.htm#dt19991018

>>939
それってエイリアシングがないと仮定してプログラマとコンパイラがコードを書けるというだけで、
実際にエイリアシングさせないのはプログラマの責任であることに変わりはないと思う。

結局、アドレスの重複か？ｗ

>>940
賢いコンパイラなら、restrictポインタを受け取る関数を利用時、
コンパイル時に検出可能なものについてはエラーや警告を出せるかも。

>>941
> 賢いコンパイラなら、restrictポインタを受け取る関数を利用時、
> コンパイル時に検出可能なものについてはエラーや警告を出せるかも。

エラーや警告ではなくて, 関数の最適化をもっと高度にこなせる

memcpy を inline 展開するときに
src, dst に重複した部分がなければチェックコードその他を省略できるとか
そっち方向の話だったはずだが...

あと, ライブラリーなんかも restrict 付いてればチェックコード手抜きでき
るんだっけか? > 識者

いや、呼び出し側で、プロトタイプにrestrict修飾が付いてれば・・の話

関数側はまあその通りでしょう

intelコンパイラで、SSEを使っての計算を行おうとしています。

void func(float *x){
    *x=sin(*x);
}
for (int i=0;i<n;i++)
{
    func(&a[i]);
}

このような関数内で書き換えを伴う関数を呼び出すと、
loop was not vectorized: mixed data types
と出て、ベクトル化できません。何か方法はないでしょうか？

>>944
実際のソースを頼む。
それから、sin()ではなくsinf()を使え。

float func(float x) { return sinf(x); }
のほうがコンパイラにとっては優しかったりしないのかな

>>946
優しいかどうかは知らんが、大差ないだろ。
手元にiccはないから、gccは後で試してみよう。

一般的にintは参照よりは値渡しの方が速いね。

処がだ、>944程度の関数だと(>944はfloatだけど)インライン展開されてしまうからどっちでも同じコードになるんだ。

最適化って実際にやってみたら意外と
全然最適化してくれないなんてことも普通にあるし、
最適化に期待するのはあんまりよくない。

やってくれたら儲けものぐらいで捉えておくのがいいと思う。

「やってくれたら儲けもの」ではなく、「やらせるもの」だろ。

そういうスタンスだとうまく最適化できなかったときにテンパることになる。

やらぬなら、自分で書こうIntrinsics

今はポインタおっかけは普通にやってくれるんですかね
オレ古い人間だから>>946にしちゃうよ

最速を目指すなら、
Intrinsics(or インラインASM) + sinhの近似値を自前で導出！

ttp://www.musicdsp.org/showone.php?id=175

SPEでテーブル参照って結構有効だな
L/Sの節約が必要になるが

L/Sの狭さがレジスタの豊富さを打ち消してしまうSPE

Cellのレジスタ何本だっけ？

PPE 32GR+32FR+32VR
SPU 128


逆だろレジスタの豊富さがL/Sの狭さを補ってるんだろ

豊富なレジスタを使いたくても狭いL/S経由でしかデータを渡せないジャン。

豊富なレジスタはレイテンシを隠滅する為だろ

ダブルバッファリングしてDMA転送で十分じゃん。メモリ帯域はCore 2のL2より速いよ・・・・合計でだけど

逃げました

あんまりやるとスレ違いな悪寒。

団子ちゃんは何をしても許されるんですっ！

まだ団子さんのやることに文句言う奴がいるの？

団子くんは社会復帰のためのリハビリ中なんです。
生温かく見守ってあげてください

ﾆﾀﾞ

>>967
生暖かいと黴びが生えるぞ

#食い物の足が早ぇぇよ！

C++でCライクなコードでかつ、Cよりも高速化できるC++で拡張されたものだけを
使ったC++コードを徹底するって案はどうかのお。