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

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

前スレ

C、C++の最適化について語るスレ
http://pc11.2ch.net/test/read.cgi/tech/1084676298/

２げｔｔ

ポインタ使ったほうが速いの?

コンテナにオブジェクト詰めるときは
newしてそのポインタを詰めるとめがっさ軽くなる

>>3-4
オブジェクトのコピーがボトルネックになってる場合に限るけどな。

GPOを行う場合、1000回計算を行うループがあったとして、10回程度ループを回して計測して、最適化することはできないでしょうか？
一旦プログラムのすべてを実行しなければならないとしたら、毎回実行条件の違う
科学計算などではどのように最適化すればよいのでしょうか？

それは分岐予測というカタチでハードウェアが実行している。
コンパイラはそれが機能しやすいようにする。

ダンゴさんに声かけたか？

GPO? PGO?

　

ダンゴは糞だからイラネ

>>11
団子ちゃんが馬鹿にするな！

が？

がががーが・がーがが

そりゃぁ、自分の基準にそって馬鹿だと思えば馬鹿にもするだろうよ。
団子じゃなくたってね。

int型の配列を特定の数値で埋めたいのですが、forループで一つ一つ回していく以外に
何か高速な方法はありませんか？

スレ違いの気がするが
・初期化
・memset

>>16
SSE2の使えるCPU用でいいなら、真っ当なコンパイラに適当なオプションを指定すれば、
勝手にベクタ化してくれる。
但し、極真っ当にループを書くこと。

memset使えば、コンパイラによっては最適化でより高速な命令に置き換えてくれることもある。


たとえばx86なら要素数4の倍数個で16バイトアラインされてれば

for (i = 0; i < ARRAY_SIZE; i++) {
　　　a[i] = foo;
}

↓

__m128i xfoo = _mm_set1_epi32(foo);
for (i = 0; i < ARRAY_SIZE; i+=4) {
　　　mm_store_si128(&a[i], xfoo);
}

みたいな明示的ベクトル化は可能。

ビット演算についての質問です。
やりたいことは、最大値511 (2^9 - 1) で負の可能性がある
あるint型の値の値域を 0〜255 に絞りたいのです。
つまり、
　x = (x <= 0 ? 0 : (x >= 255 ? 255 : x));
ですが、これを出来るだけ速くしたいのです。
(ちなみに、最終的に行いたいことはアドレス計算です)

一応自分なりに考えたのが、
　x |= (0x100 - (x >> 8)); // 最大値を制限
　x &= ~(0x100 - (x >> 31)) & 0xff; // 最小値を制限
または
　x |= ((x >> 8) + 0x7f) ^ 0x7f; // 最大値を制限
　x &= ((x >> 31) + 0x7f) ^ 0x80; // 最小値を制限
です。
最小値もある程度決めてしまって構わないのですが、
これ以上高速に値を得る方法はありませんか？

最小値がある程度小さいなら、最小値の制限は
x &= ~((unsigned)x >> 24);
でいいかと。

>>16 std::fill()

>>17,19
memset() は埋める値が 0 とか 0xff とかじゃないと使えないだろ。

>>21
それいいですね！
~の方が速そうなんですが、
最後は0xffでマスクしないとゴミがのる可能性があるので、
ちょっと変えて、((unsigned)x >> 24) ^ 0xff として使わせてもらいます。
ありがとうございました^^

あ、すまん。間違えてたわ。
その通り。

(unsigned)~x>>24
のほうが速そうに見える

なるほど。

>>26
たしかにそうですね。
と思い、コードを変更して計測してみました。
結果が、クロック単位でまったく同じだったのでおかしいと思い、
コンパイラの生成コードを見てみたのですが、、、
なんと、(((unsigned)x >> 24) ^ 0xff) が>>26とまったく同じようにコンパイルされてました
vc8すごい・・・
>>26さんもありがとうございました

コンパイラ＜やれやれ、やっと俺の優秀さに気づいたか・・・

ダンゴさんに言わせれば、VCはクズだがな(笑)

Pentium Pro時代の癖が抜けずに未だに
アドレッシングモード使うのを期待する場面で
ロード＋レジスタ間オペレーションに展開する
VC++は駄目な子

まあ、Intel謹製以外では一番マシだけどなｗ

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

いまさらだがスレタイはこんな感じのにスレばよかったのに。

AoSよりSoAの方が高速に動く理由を教えてください

C、C++の最適化についてダンゴ先生が篤く語るスレ
がいい

以下、団子に変わりましてイカがお送りします

関数の引数で、スタックのオーバーヘッドをなくす為に
const hoge_t& hoge なんて参照渡しが使われるけど
これってVC8とか今時のコンパイラでも意味ありますかね？

参照するとスタック使わなくなるわけでねえでがす

>>37
オブジェクトの作成を勝手に省略することは、
一部の例外を除いて規格上認められていないから、
今でも有効。

ま、ダンゴさんに言わせれば、VCはクズだがな(笑)

>>40はゴキブリかな

>>34
ものによるが、キャッシュが効きやすくなるか、ベクタ化しやすくなるか、ループの最適化をしやすくなる。
AoS の方がこれらに有効なこともあるので、ものによるとしか言えん。

グローバル変数Aを算出し、算出した関数内でAを参照したいときは、

�@直読み
�A算出時にローカル変数で一度算出しておき、それを参照（レジスタ参照で高速化を狙う）。Aは適当なところでローカル変数を代入

どちらがより良いソースコードになるでしょうか・・・。

�@は見やすくてコード量も減りますが、いちいちRAMにアクセスしそうなので実行速度に懸念があります。
�Aはローカル変数を用いることにより実行速度の向上を狙いますが、コード量の増加（ローカル変数増えまくり）や
　オブジェクトサイズに懸念があります。

いまいちどちらにしたらよいかの判断が出来ませぬ・・・。
みなさまはどうされてます？
　

よくわからんが、関数・グローバル変数あたり、
待避と復旧用のコードが増えるだけでそ？

あと、レジスタに振られたローカル変数は消えるから。

>>44
レスどうもです。
「関数・グローバル変数あたり」が分かりませんでしたが・・。

ローカル変数を用いてレジスタアクセスを狙っても結局スタックに退避したら
変わらないってことでしょうか？

実測するしかないだろ。常識的に考えて。

>>43
俺様用語で抽象的なコードの質問されてもなぁ。
自分で最低限のコードを書いて、コンパイラに最適化させてアセンブリ出力見比べてみなよ。
まぁ、>46って結論が待っているけど。

最適化第一法則 最適化するな
最適化第二法則 まだ最適化するな

の意味の深さがまだ理解できていないと見えるな。

GCCってforループのiをインクリメントからデクリメントに変えるだけで
性能上がったりするよな

VC++なんかはループの最適化だけはアグレッシブだから
ほとんど気にする必要ないんだが

終了条件がたまたま 0 だったりするからじゃなくて？

0との比較のほうが命令数が少なくてすむんだよ

restrictedが使えるコンパイラってアルの？

あります。

>>53
bcc32を使っているのですが、うまくいきません

そんなもんに期待する方が間違っています。

あとiccもダメでした。

iccではちゃんと使えます。

そんなもんに期待する方が間違っています。

iccは9.1あたりから対応してるはず。VC2005コンパチだし。

そもそも restricted じゃなくて restrict だな。
GCC も余裕で使える。

そんなもんに期待する方が間違っています。

VC++は、2005から__restrictが導入されている。

__ かよ。
C++ でも使えるってことなのかな？

VCはc99じゃないからね。

ダンゴ先生に言わせればVCはクズだしなｗ

>>65は屑

烏賊自重しろ

長い数式の場合、複数の文に分けて書いた方が最適化しやすいのでしょうか、それとも一気に一つの文に詰め込んでしまった方がよいのでしょうか？

場合による

っ 実測

そういう最適化は尚早な最適化や、個人の好みでしかない事の典型的な例

オーバーロードしてるような時は
コピーコンストラクタが実行されないように
分けた方がいいやね。

>>68
先ずは読み易く書き、適切なコンパイルオプションでコンパイルし、そこが速度上のネックになっていないか測定し、
ネックになっているようならそこで初めて、そこを抜き出して両方のケースを測定してみることだ。
まぁ、コンパイラが適当に最適化してくれるから大差ないと思うよ。

ダンゴさんの締めのレスが待ち遠しいな

団子って良く呼ばれるけど、
書き込んだら書き込んだで叩かれるんだよな

呼ばれてしゃしゃり出て叩かれることを学習させないと。
赤子と同じ。

赤子みたいなレスだなｗ

赤子はこれから学習するが
団子は学習した結果

スキルの無い奴の粘着人格攻撃を受けられれば、コテも一流だな。
団子の圧勝か・・・。

団子は好きだけど思い込みが激しいから反芻してから発言して欲しい。
オレモナー

試しに >>80 を反芻してみた。

込みいからが発言して欲モ激しから反芻してい団しい。 
オレ子は好きだけど思ナー

団子が負けたところを見たことがない
はっきり言って最強

逃げるが勝ちってか

糞壁と一緒だな

お塩先生に負けますた
矢田亜希子たん取られますた

>81
どういうアルゴリズムを適用するとその並びになるのか教えてくれ

反芻アルゴリズム
攪拌ではない

vectorは[]でアクセスできますが、これってメモリ上でも連続しているということでしょうか？
配列と比べても、実行速度は変わらないと考えてよいのでしょうか？

最新の仕様では連続してる事が保証されてた気がする。
ただ、それは別に [ ] でアクセスできるからという理由ではない。
こいつは演算子オーバーロードされてるから。
例えば deque なんかも [ ] でアクセスできるけど、
こいつはメモリ上の連続性は保証されてない。

>>88
vectorは連続している事が保証されているので、いざとなったら先頭アドレスを取り出して配列としてアクセスすることも出来るよ。
あと、配列の[]やvectorのoperator[]は境界チェックをしないけど、vectorのat()は境界チェックをするよ。知ってたらごめんね。

>>88
逆に言えば、添え字演算子[]で読み書きできるからといって、
メモリ上で要素が連続している保障があるとは限らない。
dequeとかmapとか。

>88の人気に嫉妬

Intel compilerのx64版を使っているのですが、
レジスタにある筈の値を何度もメモリに読みにいったり、
もう使わないローカル変数をメモリに書き込んだりしています。
ループの奥底なので許容できません。VTune で見てもボトルネックになって
いるようです。
深い理由があってのことででしょうか？
それとも、x64版の熟成が未完なのでしょうか？

32bit版との賢さの違いについてどんな印象をお持ちですか？

64bit版は知らんけど、32bit版もインテルが自分で言うほど
飛びぬけた性能でもないような…。

体験版で試して、俺のプログラムはVCに全敗したから、買う
のやめた。Linuxだと他に選択肢が無いのかも知れんけどね。

ウチの場合はICCのが何割か速かったよ。画像処理で。
GCCとVCと比較してもっとも早かった。
64bit版はさすがに知らないけど。

マルチコアならレジスタにある値だけだとあんまり信用できないからかね？

ポインタをdereferenceした値なんじゃないの

>>93
const付けられるところには全て付けてるよな？
関数ローカルのauto変数とか、クラスのメンバ関数（not変数）とかにも。

それでエイリアス問題とかが片付くから、割と変わるぞ。

エイリアス問題はconstじゃ解決しないぞ
restrictキーワードが要る

ん？
メンバ関数がconstなら、その関数内から見たらクラスのメンバ変数は皆const扱いだろ？
となると、複数のポインタor参照でメンバ変数を参照したり、キャッシュを持ったりしても実害が無いだろ？
変更がありえないんだから。
つまりエイリアスが発生しても、それが問題にならないケースがあるわけだ。
（グローバル関数経由の変更というものもあるので、確実じゃないけどな）

もちろん、クラスのメンバ以外を操作するならrestrictが必要だな。
それはおっしゃる通り。

constは、「プログラマが」変数を書き換えないという表明であって、
値が変化しないことの保証にはならない。

ポインタor参照経由の値は、
常にaliasの可能性があるとコンパイラはみなさなければならない。

というか、最適化のためのconstnessの判断はコンパイラがやることなので、
最適化フェーズではregisterキーワードよろしく無視されると考えていい。

と似たことを以前constでメシがナンタラというスレで書いた気がする。

こういうことかな・・・？

class A{
public:
int x;
void foo(int*) const;
};
main(){
A *a = new A();
a->foo(&a->x);
}
void A::foo(int* p) const
{
int x1 = x;
*p += 1;
int x2 = x; // x 読み直し
}

うーん、そういうケースも多いだろうけど
constがオプティマイザに無視されるということはないと思うぞ。

以前関わったプロジェクトで、constがろくについていなかったので
片端から付けた事があるんだよ。
結果リリースビルドのバイナリが大幅に変わってしまった。
速度的にはそれほどの向上は無かったのが残念だけど（ホットスポットは変わらなかった）
全体的にconstメンバ関数のインライン化が行われていた。

約１％ほどバイナリが肥大化したのはご愛嬌＾＾；

そりゃまたアホなコンパイラだな・・・

それにその例だと、速度かわらず、バイナリが増えてるんなら無意味じゃないか。

ホットスポットが変わらないから速度の有意差が出なかったのだろ。

>>102
そこまで言うならメンバ関数への const の有無で出力コードの変わるソースを
出してみて欲しい。

ちょっとやってみたが、短いサンプルだとconstの有無に関わらずインライン展開されて
結局同じになってしまうな……

まあこの場合「const の有無で出力コードの変わるソース」が存在することを
証明できればいいのだから、最適化オプションの調整を含めて
もうちょっと詰めてみる。

こっちもデスマ中なので何日かかるかもしれないが、期待しないで待ってろ。

必要なのは「出力コードが変わる」じゃなくて「速度向上に貢献する」だぜ

つか、なにもデスマ中にやらんでも(´･∀･｀)

元気なときにやろうぜ

いや、>>105がそう言っているんでな。
とりあえず「constで変わりうる」ということを出しておこうかなと。

C/C++では完全な参照透過性を保証する構文が無いから、
コンパイラにとって論理レベルでの最適化は難しいだろうが、
不可能では無い事を明示したい。

まあ今日は寝る。おやすみ。

>>108
そこまでわかっていて不可能ではないと思う根拠はなんだろう？
楽しみにしてるよ。

今年プログラム初めてまだまだわからないことだらけで助けてほしいことがある。
複数のファイルより条件に合う行を抜き出して一つのファイルに出力するプログラムを作ったんですが
処理に結構時間がかかってしまいます。何とか速度向上させたいのですが何か良い方法はないでしょうか？
本当は自分でいろいろ試行錯誤してやりたいのですが分け合って時間が取れなくて書き込みました。

グレップツール使いな

>>110
秀丸つかっとけ

>> 93 です。
色々アドバイス頂きながら、返信せず申し訳ありません。
const はきちんと付ける主義です。
わざわざ、{} を追加して、スコープを絞っても、ローカル変数の
無駄な書き込みを止めさせることはできませんでした。

何となく、ICC x64のコンパイル結果って回りくどい気がするのです。
命令のレイテンシとかキャッシュ効率とか考慮された結果かな？

restrictについては言及ナシですか。

つーか、具体的なコードも出さずにあーだこーだ言われても
「あーそうですか」としか言いようがないなぁ。

>>114
何故か書き込み不能になった返信がさらに遅れました。

restrictを使っても、コンパイル結果が同じでした。
仕事絡みなのでコードを出せません。ご了承下さい。

ごく一部を出しても、実害はないと思いますがバレると
厄介なことになりますもので...

別にその仕事とは全く関係ないコードを書けばいいのに。

○○○は糞、だけど証拠は出せません

いい流れだ

constによる最適化を主張する俺が戻ってきましたよ
とりあえずサンプルを作るのは諦めました。そこで
既存のプロジェクトからメンバ関数のconstを外す ⇒ エラーが出たところだけconstに戻す
という手順で相違点を調べました。（バージョン管理ツールは便利だねえ）

>>102の環境はVC7.1でしたがライセンスの関係で問題があるので
今回の環境は別のプロジェクトのCodeWarriorです。
で、リリースビルドの結果は以下の通り。

全関数（メンバ関数でないものやライブラリも含む） 12256個
constメンバ関数 253個
検証時にconstを削除出来なかったメンバ関数 24個
const削除前のコードサイズ 2899400 bytes
const削除後のコードサイズ 2899084 bytes

constを付けた方がコードサイズが増える傾向がありますが、CodeWarriorの場合は
インラインされやすくなるという傾向はありませんでした。
また、極端にパフォーマンスが変化するということはありませんでした。
（づづく）

逆アセンブリで見られる具体的な差異としては

const有りだと分岐命令の後に来ている命令が
const無しだと分岐命令の前に来ている

という現象が所々に見られました。
いつ評価しても同じなら分岐の後で評価したほうが得、ということなんでしょうか。
（遅延評価に似てる？）

サンプルを上げようかと思ったけど、きわめて眠いのでまた今度。
明日か明後日までに適当なアップローダの紹介を希望。

ではおやすみなさい。

分岐命令をまたいで命令が移動するってのは、動作が変わってるような気がする。

よくわからんからサンプルが欲しいな。ろだ↓
http://kansai2channeler.hp.infoseek.co.jp/cgi-bin/joyful/joyful.htm

ほい、上げておいた。
ttp://kansai2channeler.hp.infoseek.co.jp/cgi-bin/joyful/joyful.cgi?mode=thr&no=4841

全部上げるわけにもいかんので加工してある。
詳細は添付のreadme.txtを読んでくれ。

じゃ俺は戦場に戻る。

>>122
リストファイル中のソースとの対応がずれてたり、命令数の違いでアドレス部が
ずれてたりしてるけど、本当に命令レベルの違いだけを抽出すると、２箇所だけになった。

--
const無し:
　lw v1,-21056(v0)
　addiu a0,v1,436
　lw v1,436(v1)
const付き:
lw a0,-20672(v0)
lw v1,436(a0)
--
const無し:
lw v0,-21056(v0)
addiu v1,v0,436
lw v0,436(v0)
const付き:
lw v1,-20672(v0)
lw v0,436(v1)
--

２箇所いずれも app->CheckMenu() のところね。逆読みすると、
app 内のポインタが指す配列か構造体から１つ値を読み出してるって感じ
なんだけど、やっぱり CheckMenu() のソースが欲しいな。ダメ？

const無しのほうにある addiu の結果は使われて無いように見える。

あれ？ const 付けたほうがコード増えるって言ってたけど、ここでは
１命令減ってるね。

const の有無で最適化に影響が出てるんじゃなくて、オーバーロードに影響が
出て処理が変わってるだけじゃないだろうか？

たとえば std::bitset::operator [] (size_t) なんかだと、 const 版は単に bool が
返るけど、非 const 版は代入もできるプロキシオブジェクトが返るのでかなり
違った処理になるはず。

あ、 addiu の結果はその後の sw で使われるみたい。

app のメンバオブジェクトについて const 版が int を返して、
非 const 版が int& を返すようなオーバーロードが使われてる予感。
んで int& だと続く書き込みに使いまわせるからレジスタに置かれた、と。

やっぱり、単純にはなんとも言えないという結論か。

いや、大方の予想通りメンバ関数の const は最適化の助けにはならないって結論だろう。

お待たせしました。一時帰宅しました。
辛辣なツッコミを期待していたんだけど、ちょっと物足りないかしら。
まあ、相手してくれてありがとう。
以下質問に対するごお返答。

>>122
CheckMenu()は以下のようなコードになっている。オーバーロードはされていない。
bool CApplication::CheckMenu(int n) { return (m_MenuStatus == n); }
ちなみにappはCApplication型のグローバル変数。constではない。

>>128
出力バイナリは違っているのに、そう言いきれるのはなぜ？

小林洋平

>>129
関数の中身を晒してくれてありがとう。そういうことなら、素の int 型メンバ変数の
読み取りについてコンパイラ内部で >>126 の言うオーバーロードと似たような扱いが
されているんだろう。

今回の例では const が無い場合に int& をキャッシュするために命令数が一つ
増えたとすると、前後の処理内容によってはその int& のキャッシュによって効率が
上がることも考えられる。いつでも const を付けたほうが効率が良いとは言えない。

今回の例で、コンパイラが const 無しの場合に const 付きの場合と同じコードを
吐いても何ら規格に違反しない。最適化の詰めが甘かっただけとも言える。

constは保守のための手助けみたいなもんだろ
mutableしてない変数に代入しようとしてたらエラー吐くだけの

gcc の _attribute((const)) みたいなもんがあればいいのかも。

・関数の戻り値が引数とインスタンスの内容にのみ依存する。

つまり、

class Test {
public:
　int foo() __attribute__((const));
　void bar() const;
};

Test T;

int a = T.foo();
T.bar();
int b = T.foo(); // int b = a; に最適化できる。

>>132
変数定義時の const はそうでもないよ。 const 付きで宣言された変数は
ポインタや参照を関数に渡した後でも、値が元のままであることを期待して
最適化してもいい。

これに対してポインタ・参照の指す先の型や、メンバ関数に付ける const は
ほとんどコード生成に影響しないという話。

>>133
それはダメでしょ。
T の宣言に const が付いてないので T.bar() の中で const_cast して
値を変更しても合法なはず。

intメンバ変数一個のstructで試してみたが、
＞ポインタや参照を関数に渡した後
では読み直しをやってるなあ。
環境はVC8とgcc3.4.4(cygwin)

>>136
どんなソースで試したの？

以下のソースだと s に対する const によって読み直しが消えて return 10 に最適化される。
const 外すと当然メモリ上の s.x が読み出される。

struct S { int x; };
void f(struct S const* p);
int g(void)
{
struct S const s = { 10 };
f(&s);
return s.x;
}

あ、確認した環境は Cygwin gcc 3.4.4 の -O3 ね。

似せるとこういう感じ。gccは-O3、vc8は/Oxです。

struct S { S(int x_):x(x_){} int x; };
void f(struct S const * p);
int g(void)
{
struct S const s(10);
f(&s);
return s.x;
}

つーか分からないのは仕方ないか。ということで

struct S { S(int x_):x(x_){} int x; int getX() const { return x; } };
void f(struct S const * p);
int h(int);
int g(void)
{
struct S const s(10);
h(s.getX());
f(&s);
return s.getX();
}

vc8もgcc3.4.4も、分かってるんだか分かってないんだか分からないコードを吐く。

さらに、このコードの int x を const int x にすると、gccは読み直しをしなくなる。
これはsのconst修飾に依存しない。（あれれ？）

>>139
ほんとだ。これは期待はずれだなぁ。

コンストラクタ内での代入を許すために const として定義されたという情報が
途切れてしまっている、って感じ？
メンバのほうに const を付ければ代入を許すタイミングは無いから、 >>137 と
同様に最適化できる、と。

const 談義中に割り込み質問ですみません。

VTune で、Clockticks をサンプリングすると"No Samples were collected."
になってしまいます。
Sample After Value を変えろ、との記述を見つけて試しましたが、
うまくいきません。（他の event は収集できます）

対策をご存知の方はいらっしゃらないでしょうか？

>>141 です。自己解決しました。

使っていたのが一つ前のバージョンのVTune だったので、
quad core に対応していなかったようです。
最新版の体験版をインストールしたらうまくいきました。

それにしても、何のエラーメッセージも出ず、Clockticks
だけ収集できないとは、恐ろしい。

switchの場合分けにおいて、記述したcase以外は絶対にありえないと
コンパイラにヒント出す方法って無いですか？

分岐の先頭でcase以外を範囲外として弾くのが状況として
ありえないのでもったいないです。

環境非依存でもVC6,7,8限定の方法でもかまいません。
よろしくお願いします。

>>143
こういう場合だったら、
switch(hoge)
{
case 1:
//1の処理
case 2:
//2の処理
default:
//ここに来ることは絶対にない
}

こうすればいいんでないの？
switch(hoge)
{
case 1:
//1の処理
default:
//2の処理
}

>>143
環境非依存ではそんなものはない。
c++であれば、enum型を使うことで慮ってくれるコンパイラがあるかもしれない。

>>144
アセンブラコードを見てみたところ
１・範囲外チェック
２・テーブルジャンプ

という流れにコンパイルされていました。

case 1:
//1の処理
default:
//2の処理

これだとdefaultの処理＋テーブルジャンプの処理になってしまって、
結果的に範囲外チェックしているのと負荷は変わらないようです。

>>145
enum試してみます。

ありがとうございました。

sage失敗すみません

VC7以降なら __assume を使え

>>146
なるほど。こちらが勉強させてもらいました。
確かに範囲外だったら大変だから、コンパイラとしてはチェックせざるをえないんだね。

>>143
>144の前者のケースなら、
switch (hoge)
{
case 1:
...;
case 2:
default:
...;
}
でいいんでない?

つーか、二項しかないのにテーブルジャンプにしか最適化できないコンパイラが蛸な希ガス。

>>148
__assumeが意図にかなっているようです。ありがとうございました。

>>143
gcc限定ならコメントでなんか記述すればコンパイラが理解してくれた気がする。

関数テーブル＋__forceinlineじゃ駄目だったっけ

gccはassert()が__assumeと同じ動作したはず。

assert(0);だな

　　　　　　　 ♪　　　　　　∧,, ∧　　　　　　　　　　　 ♪
♪　　　　　　　　　　∧,, ∧´･ω･) 美脚♪
　　　　　　　　 ∧,, ∧´･ω･)　　 )
　　　 ♪∧,, ∧´･ω･)　　 )っ＿_フ　　 ♪　　　 ∧,, ∧
　 ∧,, ∧´･ω･)　　 )っ＿_フ(_/ 彡　　　 .∧,, ∧　　　 )
　(´･ω･)　　 )っ＿_フ(_/彡　　　　∧,, ∧　　　 )　　　)
　(っ　　)っ＿_フ(_/彡　　　 .∧,, ∧　　　 )　　　)　Οﾉ
　　( ＿_フ(_/彡　　　∧,, ∧　　　　)　　　)　Οﾉ ヽ_)
　　 (_/彡　　　　　　(　　　　)　　　)　Οﾉ 'ヽ_)
　　　　　　　　　　　 (　 　　)　 Οﾉ 'ヽ_)
　　　　　　　　　　　(ゝ. Οﾉ 'ヽ_)　　　　　 ♪
　　　　 ♪　　　　ミ　 ヽ_)

C++特有じゃないとは思いますが質問させてください。
ある処理をループしようと思っているんですが、その時に、
カーソルとして使用するポインタを(ローカル変数として)毎回宣言するのと、
あらかじめ外部で宣言したものを使いまわすのではどちらが高速なのでしょうか？

>>158
大丈夫、そんなもんは真っ先にコンパイラの最適化の餌食になるから。
それ以前に、ポインタで回すよりも配列参照で回す方が速いかも知れない。
いずれにしても、ケース・バイ・ケースだから実測するべし。

 　　　　　　　 ♪　　　　　　∧,, ∧　　　　　　　　　　　 ♪
♪　　　　　　　　　　∧,, ∧´･ω･) 美脚♪
　　　　　　　　 ∧,, ∧´･ω･)　　 )
　　　 ♪∧,, ∧´･ω･)　　 )っ＿_フ　　 ♪　　　 ∧,, ∧
　 ∧,, ∧´･ω･)　　 )っ＿_フ(_/ 彡　　　 .∧,, ∧　　　 )
　(´･ω･)　　 )っ＿_フ(_/彡　　　　∧,, ∧　　　 )　　　)
　(っ　　)っ＿_フ(_/彡　　　 .∧,, ∧　　　 )　　　)　Οﾉ
　　( ＿_フ(_/彡　　　∧,, ∧　　　　)　　　)　Οﾉ ヽ_)
　　 (_/彡　　　　　　(　　　　)　　　)　Οﾉ 'ヽ_)
　　　　　　　　　　　 (　 　　)　 Οﾉ 'ヽ_)
　　　　　　　　　　　(ゝ. Οﾉ 'ヽ_)　　　　　 ♪
　　　　 ♪　　　　ミ　 ヽ_)

>>159
なるほど。コンパイラに頼れそうですね。
配列については任意の位置に追加、削除等の関係から使えませんでした。
ありがとうございました。

グローバル変数は最適化に良くない。これ豆知識な。

グローバル変数は最適化に良い。これ豆知識な。

確かに、既存ソフトの高速化の仕事をしていると、グローバル変数があったら狙い目だとは思うけどね。

>>164
高速化の仕事ってどんな感じなの？
今の職場では高速化の効果が工数の割に合わないと言われることが多くて
バグ改修時についでに高速化する程度しかやらせて貰えない。

既存機能を維持しつつどうやって安全に高速化してるの？
グローバル変数触るなら単体テストだけじゃ足りないよね？

既存機能を維持しないでどうやって危険に高速化してるの？
そんなんだからやらせて貰えないんだぜｗ？

単体テストで完全に見えるスコープで、グローバル使いまくる馬鹿は沢山いる

高速化で受ける業務はソースで引き渡しだから、コード解析結果と単体テスト結果しか出さない罠。

>>168
高速化で受けた業務なら性能試験はやるんじゃないの？
単体テストしかしないなら関数単位の高速化なのかな？　ライブラリ系？
参考までに、使ってる測定ツールとか教えてくれないかな。

それにしても、コード解析結果と単体テスト結果で話がつくとはな。
俺んとこだと結合試験と性能試験やらずに改修完了なんてまず了承されないよ。

そりゃぁ、「何」で金取っているかの違いだろ。
依頼主だって全部の環境晒せるような物ばかりとは限らんわけだし。

結合と性試験やらずに

単体テスト＝手淫

  　　　　　　　 ♪　　　　　　∧,, ∧　　　　　　　　　　　 ♪
♪　　　　　　　　　　∧,, ∧´･ω･) 美脚♪
　　　　　　　　 ∧,, ∧´･ω･)　　 )
　　　 ♪∧,, ∧´･ω･)　　 )っ＿_フ　　 ♪　　　 ∧,, ∧
　 ∧,, ∧´･ω･)　　 )っ＿_フ(_/ 彡　　　 .∧,, ∧　　　 )
　(´･ω･)　　 )っ＿_フ(_/彡　　　　∧,, ∧　　　 )　　　)
　(っ　　)っ＿_フ(_/彡　　　 .∧,, ∧　　　 )　　　)　Οﾉ
　　( ＿_フ(_/彡　　　∧,, ∧　　　　)　　　)　Οﾉ ヽ_)
　　 (_/彡　　　　　　(　　　　)　　　)　Οﾉ 'ヽ_)
　　　　　　　　　　　 (　 　　)　 Οﾉ 'ヽ_)
　　　　　　　　　　　(ゝ. Οﾉ 'ヽ_)　　　　　 ♪
　　　　 ♪　　　　ミ　 ヽ_)

for (int i=10;i--;)
{
    //ループの中身
}
って
for (int i=0;i<10;i++)
{
    //ループの中身
}
より高速？

>>174
上の方がループの回数が多いから遅い。

すみません
for (int i=0;i<9;i++) 
{ 
    //ループの中身 
} 
でした

>>176
>175は間違い。>174でループ回数は同じになっている。
で、どちらも同じ速度のコードになったよ(icc -fastで)。
実測したら、後者の方が気持ち速かった。と言っても、差は10msオーダーだけど。
--
for (int i = 0x7000 * 0x10000; i--;) func();
for (int i = 0; i < 0x7000 * 0x10000; i++) func();
--

速度は実測が基本。

>>177
ありがとう、やっぱりふつうに記述した方が、コンパイラにとってもいいようですね。

forよりdo-whileが速い。
まあ自動で最適化してくれるけど

/*1*/
for (i = 0; i < n; i++)

これと、誘導変数を使った

/*2*/
for (ii = -n; ii < 0; ii++)
i = n + ii;

それぞれについて、生成コードを予想
また実際の処理系に生成させたコードを評価せよ (n点)

変数の型が分からないと予想できねえよ。

nは正数？

クラスかもな。

宿題？

実行コストについてはダウンカウンタと大差ない感じ。
こりゃ使える。いただき。

a[i]みたいにiをインデックスで使う場面では
a[n+ii]に対して&a[n]==a+nがループ内不変になるね。

つかiは符号付き整数だろｗ
で、おれ何点？

for文の中身は？変数がintだとすると

for (i = 0; i < n; i++);
は i=n; という式に展開される可能性がある。

for (ii = -n; ii < 0; ii++) i = n + ii;
もnが定数ならば定数代入式に展開される可能性がある。

ていう最適化機能がgccにあったような…？記憶違い？

空ループの話で盛り上がって 参りました

全然

乱数が１００個必要だとして、単にループで１００回乱数を発生させるのではなく、
１つの乱数から、分割するなどして１００個効率よく発生させることはできないでしょうか？

分割って何？
並列化するってこと？
100個乱数拾うだけならたいした変化は無いと思われ

使い道や欲しい乱数の範囲など具体的に

MTなら実装によっては624個の乱数が一度に得られる
でも内部的にはループだしな

>>190

64bitの乱数があったとしてそれをそれを8bit区切りに4つに分けて
8bitの乱数4つとして使えるかってこと？
乱数の質は悪くなると思うけど、どうだろ？

用途はモンテカルロシミュレーションです。
現在はMTを使っています。
計算精度は32bitのfloatでやっているのですが、乱数は64bitのdoubleなので、
それを単純に上位と下位に分けて、一回で２回分使えないかと考えています。

もうひとつ考えているのは、64bitで生成された乱数を、ローテートで1bitずつずらして
一回のMTで64個の乱数が生成できないかということです。
ただ、この場合、乱数の質が元のMTに対してどのようになってくるのかがわかりません。

MTやめてXorShift使うとか

>>195
少なくとも2番目の方法はいくない。
例えば一番左のビットが0の場合、左にローテートしたら元の数の2倍になる。
つまり64個の乱数の中に、大量のaとa*2が入り込む非常に膣の悪い乱数になるよ。

＞膣の悪い乱数
乱れすぎｗ

>>195
最初の方法もダメ。
MTのdoubleは基本的に仮数部32bitなので分割した下の方は精度が腐る。
仮数部53bitの方は乱数を2個使っているし。

皆さんありがとうございます。
とりあえず、2^128-1周期のXorShiftを使ってみようと思います。
ところでXorShiftのseedのとり方ですが、オリジナルの文献では
x=123456789,y=362436069,z=521288629,w=88675123;
となっていますが、たとえば、x=1,y=2,z=3,w=4;とすると最初の
数十個は
2061
6175
4
8224
4194381
8396986
8388750
25174430
8652983179
25875070649
8636205711
60369541016
17600805477257
35210146488062
52785194351115
70428979519260
36239912164446735
ように非常に悪い乱数系列になってしまいます。
最初の数百個を捨てればよいのかもしれませんが、seedの選び方には何か決まりがあるのでしょうか？

>>190
sineくれくれ厨

お前がsine

>>200
質が悪いって言うけど、どの一部を取り出してもそういった偏りが全く無いほうが質が悪いでしょ。
固定の種にしたいなら好きなだけ選びなよ。

つーか擬似乱数スレでやれよ

sine、cosine

tangent

cosecant

俺には >>200 の乱数列のどこが質が悪いのか分からん
誰か説明してくれ

>>208
このスレは馬鹿なお前のためにあるんじゃない

>>200

乱数の種で複数の値とるとき
互いに素ってのと2の累乗を自分は使わないようにしているけど…
根拠がない。それに小さすぎる値も使わないようにしている。(1とか2とか…)

>>200
void srand_xor128(void){ w^=(unsigned)time(0)*1812433253; }

とかwだけ変更すればたぶんおk。心配なら最初の十万個位捨てたら。

PSP用ゲームのVCとGCCの両用ソースなんですが
関数内でstaticな配列を使ってはならないという社内ルールが付けられているんですが
理由わかります？

void hoge()
{
static const int array[100] = { 123, 456, 789, 123, 456, 789, };
,,,,
}
このようなstaticは駄目で
const int array[100] = { 123, 456, 789, 123, 456, 789, };
にしろということなのです。
メモリが厳しいらしいのですが、これで本当に節約になるんでしょうか。

>>212
実際にコンパイルしてアセンブリ出力を眺めてみれば?
前者は静的領域に確保されることが保障されていて消えることは多分ないが、
後者は最適化で消える可能性がある。
しかし、後者は静的領域からスタックにコピーする最悪なコードになるかもしれない。

それはさておき、100要素指定しておいて6個しかないと激しく無駄だと思う。

>>212
メモリの節約にはならないだろう。

一般的な実装を予測すると、 static をはずしてもスタックに確保された配列を
初期化するためのコピー元となる配列が作られてしまう。この初期値の配列が
static をつけた場合に確保される実体と同等のはずなので、 static をはずすと
スタックの領域と初期化用コピーの処理時間が余計に増えるだけになる。

動作上の違いは、再帰呼び出ししたときに配列のアドレスが別物になるかどうか、
という点しかないはず。

はっきり言って逆効果だろう。そのルール決めた人に理由を問い詰めたほうがいい。

非 const な変数に限ってローカル static を禁止するのなら、メンテナンス性の観点から
まだ理解できる。

次に静的記憶域期間(static)です。

こちらは宣言されている場所にかかわらずプログラムの開始直前にメモリを確
保し初期化します。初期化を忘れた場合値は０になります。
また、確保された領域はプログラムが終了するまで保持されるので関数の終了
時に値が消えることがありません。２回目以降関数内のstaticオブジェクトを
利用するときは前回の値から始まります。

もっとも時間食っているところ、メモリ食っているところを押さえればよい
あとはいちいち細かいモジュールに制限加えることはない

>>212
逆(実際はstatic推奨)か、厳しいのはスタックか。

400バイトくらいで厳しいのかよ
2M = 2000000バイトくらいは使用できるんだろ? 400を繰り返し使ってメモリリークするとかなら
考慮するひつようあるだろうけど使用後に解放されるなら他のプログラムに影響しないと思うが
500K = 500000バイトくらい使うところから節約しろよ

for (int i=0;i<100;i++)
a[i]=b[i]*xx;

だと問題なくベクトル化されるのですが

for (int i=0;i<100;i++)
a[i]=a[i]*xx;

だと
 remark: loop was not vectorized: dereference too complex.
となってベクトル化されません。
自分自身が式の中に入っているとベクトル化できないのでしょうか？
コンパイラはicc ver 10で、OSはFedora 7です。

ベクトル化がわからない
配列に掛け算できないならコンパイラが壊れている

>>219
非常にシンプルなサンプルを作って試したら、どちらのケースもベクタ化できるようだよ。
配列aが何か特殊なことになってないかい?
再現できるソースは貼れないかな?

ありがとうございました。
私は開発機でコンパイルする権限も無い下っ端なのですが、
腑に落ちなかったモヤモヤが少し晴れました。

ループを200回くらい繰り返すとき、全部展開しておいた方が速いですか
インライン展開とかも出来て
あと、1万回するときに100回と100個展開した方が良いですか?

>>223
余計なことせずにコンパイラに全て任せるのが正解だ。

基本がなってない奴は気にするだけ無駄

誰かいませんか！
助けてください！！

どうしたの

スレ違いかもしれませんが
C言語の宿題がわからなくてこまってます！

明日ってか今日までなんです〜
一緒に考えてくれる人いませんか？
お願い助けて〜

宿題スレで聞けば？






って既にマルチしてるな。

staticだとスレッドセーフじゃなくなるよね？

場合による

>>230
読み込みのみなら気にしなくていい
書き込みが絡む場合はスレッドセーフではない
手軽にスレッドセーフにしてくれる拡張構文も最近はあったりする
（スレッドローカルストレージ）

>>232
初期化のときに問題にならない？

static変数の初期化より先にどこかでスレッド走らせ始めるつもりか

お前ら Binary Hacks の Hack 37 読むといいですよ

今日Binary Hacks買ってきたにょー
予定つまってて2週間ほど読めないけど…

Linux系の本だと思ってスルーしてたけど、Windowsプログラミングにはどう？

かったはいいがぱらぱらめくっただけな自分は
やはりLinuxの本という印象。

Windowsしかまともに開発してないから
あんまり楽しめなかった。

mallocダメ絶対な俺としてはスタック領域の調べ方Windows版が載ってただけで大満足

>>238
ありがとう。やっぱりそうか。

age

newの遅さはどうしてる〜？

pool allocator使う

あげ

V(･∀･)V

割る2、掛ける2はシフトを使うと速い。
これ豆知識な。

俺のCPUは割り算よりシフトの方が時間かかるんだけど

最近のCPUではよくあることだな。
「１足すならaddよりincの方が速い」とかも同様。

俺の様なジジイの豆知識はほとんど役に立たん。

C/C++の範囲では、どっちがいいかなんてコンパイラの最適化に任せるのが正解。

いや、それを言っちゃうとこのスレ終わっちゃう。
つうか、だから伸びないんだなorz

VCの吐くコードとか見てると感動するけど、時々「？」と感じるときがあるのも事実。
そういうのを減らすための豆知識とか、誰か披露してくれまいか。

それじゃ、「?」と感じたものを挙げてみてくれ。可能な限り、説明しようじゃないか。

inc は使うなというのは正式な資料に書いてあるが
>俺のCPUは割り算よりシフトの方が時間かかるんだけど
こういうCPUは寡聞にして知らない．教えてくれないか？

割り算は普通遅いからね。

定数の乗除は最適化してくれるんじゃないの？

CPU はって言ってるからには
アセンブリで比較してると信じたいのだが・・・
C でやってる悪寒

まあ、バレルシフタ持ってない CPU だと、それなりに時間かかるからな。

　３ビットのシフトの方が÷２より時間がかかる

と言う詭弁は可能かと。

割り算を逆数近似で計算してればあり得る？
まともな割り算は必ずシフタ使うから普通はないが．

デバッグで実行しての実測なんて意味がない、ただただ使う側のPCスペックと環境だけ

何の話だ？

foreachの最適化は無理無理無理無理いいいいいいいいいいいいいいいいいい

PenrynだとRadix-16のおかげでdivのクロック数は最小で６
昔とはだいぶ違うよ

>>261
あれ、14じゃね？

if((a == 1) && (b == 1)){ asdf; } という処理は論理積 && を使っている以上、分岐が2つある
if(a == 1){ if(b == 1){ asdf } } に等しくて、これだと条件分岐が多くその分投機予想も外れる可能性があがるので
if((a == 1) & (b == 1)){ asdf; } にすべきだ、っていう話を聞いたんですが、これは本当なんでしょうか？
もしくは、そんな事は演算子がオーバーロードされていない限り明確に分かりきった事なので
あらかじめコンパイラが論理積を (a == 1) & (a == 1) と同等の処理に最適化してくれたりとかはないんでしょうか？

>>263
実験してみた。最適化できるみたい。
$ cat test.c
void g(void);
void f(int a, int b) { if ((a == 1) && (b == 1)) { g(); } }
$ gcc --version
gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc -S -o - -Os test.c
.file "test.c"
.text
.globl _f
.def _f; .scl 2; .type 32; .endef
_f:
pushl %ebp
movl %esp, %ebp
cmpl $1, 8(%ebp)
sete %al
xorl %edx, %edx
cmpl $1, 12(%ebp)
sete %dl
testl %eax, %edx
je L1
popl %ebp
jmp _g
L1:
popl %ebp
ret
.def _g; .scl 3; .type 32; .endef

>>263
使っているコンパイラでは結果が違うかもしれない。そういう環境で、且つ、実際に
そのレベルの高速化が必要ならビット AND への置き換えもありうる。ただしその場合は
しっかりコメントで実験結果に基づくコードだと添えておく必要があるだろうね。

なるほど、ありがとうございます。

実装が長くても1度しか呼ばれない関数って、普通最適化でインライン展開されますよね？

試してみれば？

インライン展開されます

コンパイラによってはインライン関数がちゃんと展開できたか教えてくれるコンパイルオプションがあるよ
gccの話だけど

ごめんなさい忘れてください

同じ内容の関数を複数用意して使い分ける意味ってあるんでしょうか？

>>272
唐突に質問されても何を聞きたいのか判りませんが。
同じ内容でも型が違う場合はC++ではテンプレート関数で一つで済ませることもできますが、
Cではできません。その辺りの話でしょうか?

>>273
そうではなく、

void foo1(int hoge){};
void foo2(int hoge){};
void foo3(int hoge){};
中の処理も全く同一な関数です

オーバーロードだとかそういうのでも全くないです

>>274
別に意味なんてないと思うが。訳が分からん。
typedef void (*func_t)(int);
とやっておいて、どこかでfunc_tの変数を宣言してそれらを代入し、
fptr1 = foo1;
fptr2 = foo2;
if(fptr1 == fptr 2){ ... }else{ .. }
として、処理は同じだけど違うものとして動作させたいと言うくらいしか思いつかないな。
意味があるかないか、どちらにしろそのソースコードを書いた人に直接訊いてみれば良い。

ただのアホな作りなのか、後の仕変に対応するための措置なのか見極める必要はある。
現状で言えばまとめてしまって構わないとは思うが。

I キャッシュの関係で、そういうのを最適化のために使えるケースというのはあった。リンカスクリプトも直す必要があるが。
多分違うケースなんだろうけど。

>>272
目的があれば意味があるんじゃないの？

string::size と string::length は全く同じメソッドだな。
文字列としては length という言葉を使う方がしっくりくるが、
コンテナとしての要件を満たすには size がないと困る。
なら両方作っちゃえって感じなんだろう。
こういう例ならありうると思う。

ファイルやフォルダをコピーしたり消したり作ったり、.NETで言うFileInfoクラスやDirectoryInfoクラスを
自分で実装するのは.NETに頼らなくて済む、以外のメリットないのかなぁ・・
このまま行くと.net病になりそうだ・・・

どうすりゃ効率いいかなぁ・・

既存のクラス使う方が仕事の効率は良さそうだな。

微妙に誤爆・・だけど平気かぎりぎり・・・いやごめんなさい

うひょー、れすがついちゃってた

>>281
Windows専用なら.NET全然良いかな、と思う
でも趣味でやってる分には微妙に素直に割り切れないというかなんというか

というかそのFileInfoクラスだけならともかくさ、他にも色々必要だろ
言い過ぎの誇張表現になるけどそのすべてにおいてMS開発陣の書いたコード以上のものを書けるのかってことになる

つまり.NETを1箇所以上で使うなら出来得る限り.NETで実装を

効率ってのが速度を表すなら、全ての.NETコードは効率が悪いことになる。

個人でやる分には安心感はあるけどねえ

>>279
lengthはsizeを呼ぶだけとかってなら、アリだね。
極力重複コードは避けるべき。

うあー、こんなんにレスつけてくれてありがとうございます

>>284
コードの数割は.NETのを利用したもので、主要な処理の部分だけちょっとがんばって
頼らず書こうかなと思ってたんだけどそのままにしときます

まあ.NETのあるクラスのすべてのメソッドをフル活用する状況ならいんじゃないかねえ

>>287
重複コードは inline 関数のおかげで簡単に避けられるね。

Ruby とか同じ動作の別名関数が用意されてる事が多い。
A という言語では a という名前で、
B という言語では b という名前な関数を Ruby に作る時には、
a と b の両方の名前を採用しちゃえ、みたいな。

そういえばC++には識別子のalias機能がないんだね。

で、でふ

変数は参照で、
関数はインライン関数で、
型は typedef で、
名前空間は namespace a = b; で、
クラステンプレートは継承でそれぞれ可能ではある。

ただ、インライン関数使うのと、
クラステンプレートを継承するのとは、
結構面倒臭い。

このスレ地味に常駐多くないかい

C++0xであるかも知れないが、テンプレートのエイリアスは作れないよな。

typedef std::vector my_vector;

みたいなの。>>293にも書いてある継承は可能ってレベルではない。
コンストラクタやらオペレータやら全部知っていて、尚かつ書かないといけない。

オペレータは必要ないと思う。
コンストラクタは作らないとダメだけど。

>>296これで例として成立してるか自身無いけど。
継承しちゃうとoperatorの返す型と継承した型が異なっちゃうからうまくいかない。

struct c {
  int v;
  c operator+(int n) {
    c t;
    t.v = v + n;
    return t;
  }
};
struct d:public c {};
main() {
  d e, f;

  f + 1; // OK
  e = f; // OK
  e = f + 1; // Error
}

>>297
ああ、なるほど。
というか、色んな状況を考えると継承では不完全なのか。

if(hoge.piyo == hogehoge.piyo)
　hoge.piyo = hoge.piyo & ~sym.att;

こんなのはこれ以上どうにもなりませんよね？

分岐は無くせるけどね。
hoge.piyo = ~(sym.att & -(hoge.piyo==hogehoge.piyo) & hoge.piyo;

x86でPentiumPro以降に限定するなら
hoge.piyo = ~(hoge.piyo == hogehoge.piyo ? sym.att : 0) & hoge.piyo;
はCMOVになる可能性がある。

SSEで書けば次のようにも出来る。
// hoge.piyo = ~(sym.att & -(hoge.piyo==hogehoge.piyo) & hoge.piyo;
hige.piyo = _mm_andnot_ps(_mm_and_ps(sym.att, _mm_cmpeq_ps(hoge.piyo, hogehoge.piyo)), hoge.piyo);

ただSIMD以外は保守性が悪くなるだけであんま効果無いと思う。
実測した方がいい。

>>300
なるほど・・-ってのを初めてみたんで調べてきます、ありがとうございます

ANSI Cの仕様ではA==Bが真なら1になるから-1(全ビットON)にしてマスク作ってるだけだよ。
x86なら分岐せずにSETcc + NEGにコンパイルされるはず。

偉そうな割には右括弧が足りないぞ。

どの道やってること同じではないのか

まぁ、>299程度ならコンパイラに任せて実測してみてからだな。
CMOVになったところで大した差は出ないだろ。

Windows環境でのファイルなんかのコピーを大きくする手段ってないですよね・・

どのみちOSの機能頼りなわけだから

コピーしたつもりがおっきくなっちゃうのかー。そりゃねーな。

すんません、ガチで寝ぼけてる

早くする、ですほんとごめんなさいごめんなさいごえｍんあい

早くする手段ならいくらでもあるだろ。
速いかどうかは知らんが。

ストライピング
コードレベルの最適化とは無縁だが。

高速化っていうんだから速くか

ストライピング、調べてきました
それだと送り先が2箇所なのかな・・・
コピー元も先も1箇所なんです

というかコードレベルって話じゃないですよね、把握しました

単純にバッファをいじるとか

HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet
/Control/Session Manager/Memory Management
ここの数値を

というか普通こんなことしねえよな・・

>>311
実際問題、ファイルアクセスの速度はデバイス側の事情で決まってしまう。
と言うことで、単純に速くする方法はない。
寧ろ、本当にファイルコピーの時間が問題なのか、例えばレスポンスが問題なのか、検討した方がいい。

うちの環境だと10Mにしてるけどよく考えたら馬鹿すぎる方法だ

確か再起動必要だった気がするし

>>313
最近、.NETFrameworkというものを触ってみまして
色々試してみようとコンソールなんですがファイルをコピー（バックアップ？）する
ものを作ってみたんですが、そこでコピー自体速くならないかなあと思った次第です

>>312>>314
再起動必要じゃあれですね・・・
Win32APIとかってのもWindowsの機能を使うやつだって聞いたんで
それでファイルのコピーするとこを実装すれば速いんだろうか

>>315
先ず、.Netって時点でスレ違い。
次に、ファイルコピー自体の速度はデバイス依存だ。
.Netでファイルコピーしていて遅いと思うのなら、コードレベルの最適化ではなく.Netの使い方の問題だ。

C/C++でファイルコピーなんてファイル開いて読み取って書き込むの繰り返しなんだからさ
たぶん.NETでもAPIでも使った方が良い

ということでもうそれで完成でいいじゃない

>>311
Windows 限定なら FastCopy.exe のソースとか見ればいいんじゃないか。

オープンソースとか見ると趣味人でもない限りC/C++やWinAPIを使うのってことがどういうことかわかっちゃうよな

俺は、お前の言ってることがどういうことかわからん。

開発効率と現状溢れかえってるPCのスペックの話だろうか

まあ例外は確かに往々にあるけど例外は圧倒的にマイノリティ
うちも業務じゃC/C++なんて使わないわ

何言ってんだこいつ。
Webでもやってろ。

webは全然分類違うだろ、どこのアマグラマだよ

業務でC++主流だと思ってるのか・・

マジョリティマイノリティでわけちゃうとなぁ

まあ業務になると大抵どっちかだけ向いてればいいんだが

スレチ自重

ここに適当なコード張ってみんなで最適化とか考えたけど適当な長さのコードが見当たらなくて10分で諦めた

AMD向けの最適化に関するマニュアルはAMDのホームページにありますが、インテル用のはどこかでダウンロードできなうのでしょうか？

>>328
http://www.intel.co.jp/jp/download/index.htm

>>328
ttp://www.agner.org/optimize/

おいお前ら、俺のこいつをみてどう思う？

class Vector3
{
public:
union
{
struct {float x, y, z;}
float data[3];
};
Vector3() {}
Vector3(float ix, float iy, float iz)
{
x = ix;
y = iy;
z = iz;
}
};

inline Vector3 operator+(const Vector3 & va, const Vector3 & vb)
{
return Vector3(va.x + vb.x, va.y + vb.y, va.z + vb.z);
}

ベクトル化されるかな

人に読んでもらうんならもうちょっとマシなコードを書いて欲しい所

横レスだが、別に普通じゃねえかw

全角スペースでいいからインデントをだな

コードがマシかどうかとは関係ないじゃん

>>332
「もうちょっとマシなコード」をｋｗｓｋ

>>334だけど>>332じゃないです

ここで一つ自演を見付けると

分かった、インデントが無いのは謝る
コンパイラ通してないのも謝る

ただ俺は…ベクトル化について語って欲しかっただけなんだ…

コンパイルしてみりゃいいじゃん。

>>336
・classじゃなくて別にstructでいいんじゃ？
・無名共同体内無名構造体の後のセミコロンがない
・デフォルトコンストラクタ邪魔
・メンバ初期化子を使って欲しい　そして出来れば引数もconst type&で受け取った方が
・演算子オーバーロードを行う関数の引数名はrhs, lhsにするのが普通

>>341
・classじゃなくて別にstructでいいんじゃ？
俺は変数だけならstruct、関数あるならclass使ってるが

・無名共同体内無名構造体の後のセミコロンがない
struct {float x, y, z;} ←これか。スマン

・デフォルトコンストラクタ邪魔
コンパイラによっては0で初期化される・・・っていう記憶があるから、
不定値のままでいいから一応書いた

メンバ初期化子を使って欲しい　そして出来れば引数もconst type&で受け取った方が
うぉ？！全くその通りだw
Vector3(const float & ix, const float & iy, const float & iz)
: x(ix), y(iy), z(iz)
{}
これでおｋ？

・演算子オーバーロードを行う関数の引数名はrhs, lhsにするのが普通
知らんかった

レスありがとう

忘れるところだった。俺はベクｔ（ｒｙについて聞いてたんだ
return Vector3(va.x + vb.x, va.y + vb.y, va.z + vb.z);
こいつはベクトル化されるのか？

それとも、
Vector3 v;
for (int i = 0; i < 3; i++) {v.data[i] = lhs.data[i] + rhs.data[i];}
return v;
とか書かないとダメかな

まぁコンパイラ依存な訳だが、どこまで美味く最適化してくれるか知りたいんだ

そこだけ見てもベクタ化されるかどうかは不明。
ってことで、クラスの作りだけ見ると、unionにする理由が判らん。
配列のようにも構造体のようにも使いたいのならそういうアクセッサを用意すればいいだけだから、
そもそもデータメンバを公開する理由が判らん。
あーそれから、floatを引き数とするコンストラクタなら参照にしなくて充分。

>>343
だから、コンパイラが何か、どんな使い方をするかなども書かれていないのにベクタ化されるかは不明だってば。
わざわざforループにしなくても、ベクタ化できるコンパイラならベクタ化すべきときにはしてくれるだろうよ。

これは３次元ベクトルのクラス。できる限りの高速化が望まれる
xyz公開してるのはGetX()とか作ったり使ったりするのが面倒くさいからだ
コンパイラはVisual Stdio 2005のやつ

「できる限りの高速化」を望みつつ、条件も出さずに実測もしないで、
挙句の果てに「面倒くさい」って、阿呆ですか?

>>347
俺が求めてるのは実測とかじゃなくて、最適化についての経験談なんだが
こうした方がベクトル化され易い、とか…
あと、
void Vector3::GetX() const {return x;}
void Vector3::GetY() const {return y;}
void Vector3::GetZ() const {return z;}
とか実装しろと？
最適化、いや高速化に関係するのか？

>>348
だから、いろんなサンプル作って実測してみろって。
クラスを作るのなら効率よく組めて且つ速いものも狙うのは当然だろうし、
そうでないなら速度重視でがりがり書くことになるからクラスなんて作る意味がないって。

要は、やることが半端なの。

float を参照渡しする意味はあるのか？

>>349
自己矛盾乙

むしろだめだろう、リテラルわたせないじゃないか

一時オブジェクトが生成されるから問題ない。

インライン化されるだろうから多分変わりはないだろうが、
積極的に参照にする理由は無いな。

そうでしたかごめんなさい

>>351
どこが自己矛盾?

他人に訊く暇があったらまずやってみろ！
それで自分の力だけではどうにもならない事が起きた時初めて他人を頼る
でないといつまでたっても他人に頼る癖が抜けないぞ

インライン化される事を前提としているならconst参照渡しは問題ないというかコンパイラの助けにある程度なるだろうけど、
確かに中途半端に長い関数で1ワードごときの変数を参照にする必要は無い。

>>357
ここは相談の場でなくて語り合う場だが？

void float Func(const float &f)
{
　return (f + f - f) * f / f;
}

イコール

void float Func(const float *f)
{
　return (*f + *f - *f) * (*f) / *f
}

だと思ってた。それとも

void float Func(const float *f)
{
　float g = f;
　return (g + g - g) * g / g;
}

こうか？参照渡しって内部的にどういう処理が行われてるの

>>360
最適化されると、後2者の区別はなくなりますが。
# void float とかfloat g = f は兎も角

>>360
最適化されると、内部的に変数の所在を渡すよりも変数の値をそのまま渡した方が速度が出るので

void float Func(const float f)
{
　return (f + f - f) * f / f;
}

になる。

適当にコピペして解説したんだけど
>void float
まさかこんな風に書いてあったなんて

>>362
最早意味不明だし。インライン展開されない限り、参照やポインタ渡しが値渡しになることは有り得ません。
# インライン展開されたらされたで、Func()自体が(その呼び出しについては)消えてなくなるだろうけど。

>>364
不動小数点数の演算って、足して引いて 0 とか、かけて割って 1 とか、畳んでいいんだっけ？

>>365
実際に最適化されるときに、引き数が明らかなら可能。
そういう意味では、>364は不正解。

＞実際に最適化されるときに、引き数が明らかなら可能。
あー失礼しました。
gccでの確認ですが、確かにFunc(1.2f)とかは消えてなくなるけど
Func(atof(argv[1]))とかだとちゃんと四則演算してますね。
--
call __strtod_internal
fstps -4(%ebp)
movss -4(%ebp), %xmm3
movss %xmm3, %xmm1
addss %xmm3, %xmm1
subss %xmm3, %xmm1
mulss %xmm3, %xmm1
divss %xmm3, %xmm1
subl $8, %esp
cvtss2sd %xmm1, %xmm0
movsd %xmm0, (%esp)

C/C++でGUIを実装する場合、どういった手段が適当でしょうか？（Windows環境）

色々調べてみたところ
・実際の職業プログラマさんなんかはC#やVB.NETみたいなのを使う
・WinAPIを直接、みたいなことは趣味でやる人が使う
（山を登るのに、ロープウェイを使うのが賢いが趣味で山登りを楽しむ人がいるみたいな意味で）

で、実際人に聞くと今度はMFCという意見が出てきました
調べるとWinAPIを糖衣したようなもののように感じたものの情報がすごく少ない

と、こんな感じでして、どっちに進むべきか悩んでいます
やりたいのはどっちだ、というのは手段と目的がｒｙってやつでGUIの実装の手段をどうしたものか、という質問です
C#/VB.NETというものも一応考慮のうちに入れておきたいです
（GUIの実装はC/C++の枠を超えればそれがベターだから、という意見も考慮したいからです）
それではよろしくお願いします

スレタイ読め

スマン、遅レスだがvoidは間違いだ
floatもマズかったかな

double Func(const double &d)
{
　return (d + d - d) * d / d;
}

こいつはコンパイルされた後ってどうなるんだ？
アセンブリ知らないから、とりあえずCの文法的に書いてみるけど

double Func(double d)
{
　return (d + d - d) * d / d;
}

になるのか。それとも

double Func(double *d)
{
　return (*d + *d - *d) * (*d) / *d;
}

になるのか。まさか後者みたいなコード吐かないよね
もちFunc関数自体が省略されない場合で

>>370
アセンブリ知らないという見方なら C の規格上の実行モデルで考えることになり、
その場合にはそれら２つは引数が値渡しである点を除いてほぼ等価。

違いを知りたければアセンブリを見るしかないでしょ。

コンパイルして逆アセンブルしてみればいいんじゃないの？

すんませんごばく

>>370
参照で書かれた関数は、ポインタで書かれた関数と同じコードを吐くよ。
その例では、後者と同じと言うことになる。
勿論、後者自体がdouble Func(double * d) {double tmp = * d; return (tmp + tmp - tmp) * tmp / tmp;}
と殆んど同じコードを吐くという前堤でね。

ちょっとコンパイルしてみた。
--
double func(double const d) {return (d + d - d) * d / d;}
double func(double const & d) {return (d + d - d) * d / d;}
double func(double const * d) {return (* d + * d - * d) * * d / * d;}
double func(double const * d) {double tmp = * d; return (tmp + tmp - tmp) * tmp / tmp;}
-- 以下適当に行を圧縮
_Z4funcd:
movapd %xmm0, %xmm1 addsd %xmm0, %xmm1
subsd %xmm0, %xmm1 mulsd %xmm0, %xmm1
divsd %xmm0, %xmm1 movapd %xmm1, %xmm0
ret
_Z4funcRKd:
movsd (%rdi), %xmm1 movapd %xmm1, %xmm0
addsd %xmm1, %xmm0 subsd %xmm1, %xmm0
mulsd %xmm1, %xmm0 divsd %xmm1, %xmm0
ret
_Z4funcPKd:
movsd (%rdi), %xmm1 movapd %xmm1, %xmm0
addsd %xmm1, %xmm0 subsd %xmm1, %xmm0
mulsd %xmm1, %xmm0 divsd %xmm1, %xmm0
ret
_Z4funcPKd:
movsd (%rdi), %xmm1 movapd %xmm1, %xmm0
addsd %xmm1, %xmm0 subsd %xmm1, %xmm0
mulsd %xmm1, %xmm0 divsd %xmm1, %xmm0
ret

>>375
VC++2003で最適化オプションを全て有効にして、その4つの関数を定義して
連続で呼び出してみたら、インライン展開されて計算は1回だけで結果を
4回コピーするだけのコードになった。完全に同一とみなされてるね。

あと、インライン展開されてないコードではSSEを使っているけど、展開された
部分ではSSEは使ってなかったな。

俺の環境(VS2005SE)で速度重視ならこんな感じ
展開はされてない

func1:
fld qword ptr [esp+4] fld st(0)
fadd st,st(1) fsub st,st(1)
fmul st,st(1) fdivrp st(1),st
ret

func2:
fld qword ptr [eax] fadd st(0),st
fsub qword ptr [eax] fmul qword ptr [eax]
fdiv qword ptr [eax] ret

func3:
fld qword ptr [eax] fadd st(0),st
fsub qword ptr [eax] fmul qword ptr [eax]
fdiv qword ptr [eax] ret

func4:
fld qword ptr [eax] fld st(0)
fadd st,st(1) fsub st,st(1)
fmul st,st(1) fdivrp st(1),st
ret

あれ、これってSSE使われてないよね。なんで？

>>370
参照はポインタで渡されるので、関数を呼び出す場合は後者の関数が生成される。
インライン展開されるばあいは、最適化されてポインタが使われない前者と同等になるよ。
>>376
2005proではインライン展開もSSE2になってた。
>>377
SSE2のオプションは確認した？

>>378サンクス。オプション忘れてたw
インライン展開されているものは全て同じコード吐いてるっぽい
されていないものはこんな感じ

double func1(double const d) {return (d + d - d) * d / d;}
004018A0 movapd xmm0,xmm1
004018A4 addsd xmm0,xmm1
004018A8 subsd xmm0,xmm1
004018AC mulsd xmm0,xmm1
004018B0 divsd xmm0,xmm1
004018B4 ret

double func2(double const & d) {return (d + d - d) * d / d;}
double func3(double const * d) {return (* d + * d - * d) * * d / * d;}
double func4(double const * d) {double tmp = * d; return (tmp + tmp - tmp) * tmp / tmp;}
00401880 movsd xmm1,mmword ptr [eax]
00401884 movapd xmm0,xmm1
00401888 addsd xmm0,xmm1
0040188C subsd xmm0,xmm1
00401890 mulsd xmm0,xmm1
00401894 divsd xmm0,xmm1
00401898 ret

func1の方が短い事にちょっぴり驚いた。引数でdoubleそのまま使うのも有りって事か？

このスレに来て学んだことは「とりあえず素直に書いておけ」

結局、最適化器を書いてるのは人間だから、
「彼らが想定する人間であること」
が大事になってくるわな。

double を参照渡しはまずせんわな。

たしかに直接にdoubleを参照渡しにすることは無いけど、テンプレートを使うときに引数を参照渡しにすることはよくある。
その結果、doubleを参照渡しにしてしまうことも多々ある。インライン展開なら参照渡しもしっかり最適化されるので助かる。コンパイラ屋さんに感謝だな。

値渡し用の型を取得するためのテンプレート使うといいよ。

値渡し用の型、じゃねえや。
そういった引数用の型、だ。

テンプレートだと、問答無用に値渡ししないか？
と思ったが、bindとかfunctionとか参照渡しだったな。

特定の基本型のみ値渡しにし、
他の型は全部 const 参照にするってやつ。
要するに boost::call_traits<T>::param_type 。

凄いことができるんだな。テンプレートって奥が深いな

つかフツウやるやろ

まあ実装はかなり泥臭いがな。
基本的に const 参照にして、基本型全部で特殊化。
実際にはもうちょっと階層的に作ってあるけど、
基本的にはそんなとこ。

分かりやすいのが一番だと思ってる。でも必要な所はあるわけですよ
・・・このスレに何しに来たっけ

これをどうするか聞きに来たんだっけかw
//----------
class Vector4
{
public:
　float x, y, z, w;

　Vector4(float ix, float iy, float iz, float iw)
　　: x(ix), y(iy), z(iz), w(iw)
　{}
};

void Add(Vector4 * pO, const Vector4 & iA, const Vector4 & iB)
{
　pO->x = iA.x + iB.x;
　pO->y = iA.y + iB.y;
　pO->z = iA.z + iB.z;
　pO->w = iA.w + iB.w;
}
//----------
ベクトル和を計算するAdd関数がある訳だが、とにかく速度が欲しい。
SSEのパックド単精度実数関連の命令（ADDPSとか）使えば早くなるはずだと
というか、最適化で勝手にやってくれると思っていたんだが、パックド使ってるようには見えない
まさか、この程度なら使わない方が早いのか・・・
おまいらならどうコーディングする？

完全にぶりかえしですまん

コンパイラが場合によって速いほうを選べるように inline にする。
必要な箇所があれば intrinsic でもアセンブラでも使う。

残念だがそれをaddps1個に翻訳できるほど現時点でのコンパイラは賢くない。だからこそのIntrinsicsなわけで。

//----------
#include <dvec.h>
class Vector4 : public F32vec4
{
public:
　Vector4(float ix, float iy, float iz, float iw)
　　: vec(ix, iy, iz, iw)
　{}
};

void Add(Vector4 * pO, const Vector4 & iA, const Vector4 & iB)
{
　*pO = iA + iB;
}

この程度だとラップする意味が無い

Intel C++ or VC++なら
#include <fvec.h>

でF32vec4を使う。
テキトーにラップしてよし。
あと、インライン化しないとあんまり効果ないよ。
実関数化するとコールのオーバーヘッドに食われる

class Vector4 : public F32vec4
{
public:
　Vector4(float ix, float iy, float iz, float iw)
　　: F32vec4(ix, iy, iz, iw)
　{}
};

に訂正

ダンゴさんの連投でスレが活気付いたな

活気づいたっていうのかよこれは

1人だけで盛り上がっていては活気付いたとはいえない。
実際に活気付くのは397からだから397の話題振りで活気付いたということにしないと。

>>391
こうならばどうか？
//----------
class Vector4
{
private:
　float x, y, z, w;
public:
　Vector4(float ix, float iy, float iz, float iw)
　　: x(ix), y(iy), z(iz), w(iw)
　{}
void Add(Vector4 * pO, const Vector4 & iA, const Vector4 & iB)
{
　pO->x = iA.x + iB.x;
　pO->y = iA.y + iB.y;
　pO->z = iA.z + iB.z;
　pO->w = iA.w + iB.w;
}
//或いは
void Add(Vector4& pO, const Vector4 & iA, const Vector4 & iB)
{
　pO.x = iA.x + iB.x;
　pO.y = iA.y + iB.y;
　pO.z = iA.z + iB.z;
　pO.w = iA.w + iB.w;
}

>>400
最後の行に括弧が抜けてた。
};

駄目。それでもスカラにしかならない。

addpsに展開されることが目的なら、配列にして
for(int i=0; i<4; i++) vD[i] = vA[i] + vB[i];

全要素に同じ操作をしてますよってヒントにはループが一番効果的。
手動アンロールしちゃうと効果ない。

それバールだったのか。釣竿だと思ってたぜ。

内部をバラの変数にしても配列にしても外からはわからない。
これぞクラスで隠蔽する良さだな。

遅レスすまん
f・・・vec.h・・・？こんなの知らなかったよ。
fvec.h は実数、dvec. h　は整数の CPU　拡張機能を用いた演算関連のヘッダー、でいいのかな

class Vector4 : public F32vec4
{
public:
　Vector4() {}
　Vector4(float ix, float iy, float iz, float iw) : F32vec4(ix, iy, iz, iw) {}
　Vector4 & operator =(const F32vec4 & rhs) {*this = rhs; return *this;}
};

inline void Add(Vector4 * pO, Vector4 & iA, Vector4 & iB)
{
　*pO = iA + iB;
}

inline void Normalize(Vector4 * pO, const Vector4 & i)
{
　F32vec4 v2(i * i);
　F32vec4 norm(sqrt(v2[0] + v2[1] + v2[2] + v2[3]));
　*pO = i / norm;
}

正規化関数も作ってみた。俺の理解力だと今はこれが限界
Vector3　とかも作ってみたいが、float * 4 をパックにしなくちゃいかんから、float　１つ分余計にメモリ必要なんだな
fvec.h ＆ dvec.h は xmmintrin.h をインクルードしてるが、直接使っても構わないかな

>>400
今まではそうしてた。あと、「};」が抜けてるからメンバ関数が inline か否か判らんぞ

追伸：Intrinsics の発音はイントリンシックスでおｋ？

>>405
＞\in-?trin-zik, -?trin(t)-sik\
＞ttp://cougar.eb.com/soundc11/i/intrin01.wav
よって、「イントリンジク」。

>>405
VC++なら
class Vector4
{
public:
　union {
　　float d[4];
　　struct { float x, y, z, w; };
　};
};
これでAddをforループにしたら、SSE使ってくれたよ。

class myvec
{
public:
　union {
　　T array[N];
　　struct { T a, b, c, d, ... };
　};
};

とする場合、特にTがマシンが扱う1Wordの倍数でないと
元々struct { T a, b, c, d, ... }; 部分の各要素の連続性が保証されてないからどう動くかが分からなくなる。
つまり T array[N] では T はきっちり詰め込まれているものの、 struct { ... }; は中で要素の間に空白のブロックが入る可能性がある。
ふじこふじこ

ごめん、407を訂正する。
SSE使っていることには使っているが
　movss　xmm4, DWORD PTR [eax-8]
　addss　xmm4, xmm0
　movss　DWORD PTR [eax-8], xmm4
こんなコード吐いてた。(要素数の数だけ繰り返し)
VC++2003ではベクトル化してくれるほど頭よくないようだ。

これでも普通にFPU使うよりは速いの？

>>407
クラスメンバの実体は

private:
float r[4];

にしといて、メンバ関数で

public:
float &x(){return r[0];};
const float &x()const{return r[0];};

などとするのがC++的。

>>409
x86-64はSSE使う方が速いし、FPUの利用は推奨されていない。

自動ベクトル化は何故かVC++ではやってくれないね。何年もなるのに未だに対応しない。
まあIntrinsicsを使うのがいいでしょう。

どのみち配列にしちゃうと仮に運よくベクトル化できてもメモリアクセスが必ず発生しちゃうので
性能落ちる。F32vec4かもしくは__m128iから派生するのがヨシ。

>>410
そういう仕様のベクトル演算クラスって少ないよ。C++でも

より汎用化したいならテンプレートにしてIntrinsicsベッタリな部分はtraitsで実装するとかいう手もあるわな

fvecやdvecはラッパークラスの実装サンプルだと思ってもいい。ちなみにSSE3〜4には対応してない。

なるほど、実装サンプルね。じゃあdvecが参照してるヘッダを活用して
独自にラッパー作ってもいいわけだ

>どのみち配列にしちゃうと仮に運よくベクトル化できてもメモリアクセスが必ず発生しちゃうので
>性能落ちる
ここの意味がわかりませんぜ親分。うまくベクトル化できてもIntrinsics使ったコードには勝てないのか？

配列＝かならずアドレスを持つ＝レジスタ変数にできない。
いっぽうで__m128の実体はレジスタに割り当て可能。

レジスタ上に置いて演算を繰り返すような用途には、ロード・ストアは無駄。

なんでバールの人はそんなに詳しいの

>>416
> 配列＝かならずアドレスを持つ＝レジスタ変数にできない。

これってどんなコンパイラでもそうなっちゃうの？

>>418
最適化によってずっとレジスタに保持するケースもあるとは思うが、
それでも一応メモリ領域に置くだけは置くようだ。

>>419
へぇ。そんなこともあるんだ。

で、それは特定のコンパイラでの実験結果であて、規格上レジスタだけで
済ませることができない制約がある、というわけじゃないよね？

でもC++はregister変数のアドレスを取れちゃうから不思議。

ふと、メンバ変数も仮想関数もない空のクラスでも
アドレス取れないといけないからサイズ0にならないって話を
思い出した。

>>421
register はコンパイラへのヒントであって
必ずレジスタに割り付けする必要はないからな

>>423
それでもCだと文法エラーなんだよ
この辺が解せない

>>424
でも本来の意味的にアドレス取れちゃおかしいよね。

インライン関数のアドレスが取れるくらいだからいいんじゃね。

ひょっとしてアドレスを取るコードを書いた時点でレジスタに入らなくなったりインライン化されなくなったりする？

ローカル変数のスタック・レジスタへの割り当てについては
ダンゴさんが鋭い意見を持っていると思う

再利用とか

CellのSPE用コンパイラはregisterキーワードつけただけでアドレスをとるコードはコンパイルエラー吐く。
レジスタが十分に多くレジスタ間オペレーション前提のアーキはこんなもんでしょ

関数はアドレスとろうとどうしようと、インライン展開の妨げにはなりませんな。
なんせ、通常版を展開しておきさえすれば後は何でもありだから。
gccなんかだと、再帰関数でも一段目だけインライン展開してたりして楽しい。

>>427
アドレス取る可能性があると、最適化の掛かりが悪くなるな気がする。がっちりprivateで包んで、メンバ変数のポインタを外から取れなくすると効果ある様な気がする。

>>427
メンバ変数はすでに this でアドレス取られてるようなもんだろ。 private とか関係ないと
思うよ。

アンカーミスった >432 は >>431 ね。

アクセス属性は最適化のかかりには関係ないです。
friend属性で完全に読めるしね。


なんにせよ「レジスタ型」のラッパークラスって扱いが難しいだろうな

fvecやdvec使ってても、各要素に配列インターフェイスでにアクセスしようとすると
いったんメモリ上にストアしてから各要素を読み出す動作になる。
なぜならそういう作りだから。
SSE4.1のextractps/dならレジスタ間渡しができるだろうけど。

正直、クラスメンバはぶっちゃけグローバル変数なんで最適化かかりにくい。

大分関係無いけどだんごさんのクロージャに対する意見を聞きたいです

変態boostはおなかいっぱい

ダンゴさんは本当に知識豊富だな

別に「変態boostはお腹一杯」では何も有益な事は読みとれんだろｗｗ
むしろ「もうこりごりだ」っていう反応にも取れるくらいだ。
C++のクロージャについてはgccなんかがサポートしてるから、アセンブラを吐かせてみて
そのコードを見るって言うのはどう？結構面白い実装になっていると聞いたことがある。

439は本当に知識豊富だな

クロージャ使うと遅くなるってイメージがある

っていうかboostってコードサイズをboostするんだよ。

別に「別に\「変態boostはお腹一杯\」では何も有益な事は読みとれんだろｗｗ\
むしろ\「もうこりごりだ\」っていう反応にも取れるくらいだ。\
C++のクロージャについてはgccなんかがサポートしてるから、アセンブラを吐かせてみて\
そのコードを見るって言うのはどう？結構面白い実装になっていると聞いたことがある。」では何も有益な事は読みとれんだろｗｗ
むしろ「もうこりごりだ」っていう反応にも取れるくらいだ。
C++のクロージャについてはgccなんかがサポートしてるから、アセンブラを吐かせてみて
そのコードを見るって言うのはどう？結構面白い実装になっていると聞いたことがある。

Boostつかうと一気に実行ファイルサイズが10倍に?！

\7

>>444
でも使わないと実行時に要するメモリサイズが10倍に！？

boost使うとコンパイル時間が４倍位に

それはリアルな

boost――それは決して便利とは言えない、そして無駄にコンパイルの時間とファイルサイズだけを喰っていってしまう。
しかし必要とあれば使わなければならんのだ――漢にはそういう時が来るものなのだ。

必要でもあえて使わないのが漢じゃねーのか？

１クロック１バイトまでこだわった俺仕様ライブラリを作るのが漢ってものじゃないのか。

昔, RAM 1k とかで 8bit マシンのアセンブラ書いて時は
メモリの 1byte は血の一滴って感じだったけどな…

>>450
人、それを馬鹿と言う。

＞昔, RAM 1k とかで 8bit マシンのアセンブラ書いて時は
1024バイトなんて随分贅沢だなぁ、おい。

いや、1Kbitじゃないか。

6810か

>>456
それだったら4114x2の方が安いんじゃないだろうか？

2114のまちがい

"？"不要 話にならない＜当時の価格

＜←これってどこの文化なの

こんにちはー(^^)＞おーる

>>460
DOSのリダイレクト

仮にもマなら半角の>を使え

てｓ

実行速度重視よりもメモリ使用量重視の方が早くなるときがあることについて

>>465
単一のアプリだけで動いている訳じゃないからな
たとえば残り100Mで全部使用したら、OSや他のアプリがメモリ必要とするから追い出されることになる
しかし自分が動くときにはメモリ上に再び持ってくるから、追い出すのとを繰り返しかなり遅くなる
メモリは最低限にするのが速い

あとCPUのキャッシュに乗るとものすごく速くなるんで、そのへんも絡んでくるかと

省メモリで動くならCPUキャッシュを考えて良いけど、
スワップが起こりうるならその時間の方が圧倒的にかかる

結局実測するしかないんだよな

それもあらゆる環境で。

>>470
馬鹿? あらゆる環境で最適な最適化なんてあるわけないじゃん。
「ターゲットとする」と形容するなら兎も角。

実際、Woodcrestで速くなるように最適化したら、Pen4で遅くなったなんてよくある話だ。
# それ以前に、「あらゆる」だと一体どこまで対象にするんだ? Pen3か? 486か?w

>>471
日本語読めない馬鹿？

自分が説明できていないことを棚に上げて他人をけなすバカ？ｗ

恥ずかしい誤読で鼻息を荒くするのも、
まぁ、人生経験のうちではある。

>>471
woodcrest, pen4云々とCレベルの最適化技法とは次元が違うでしょw

>>465
実際にどんなケースで省メモリコンパイルのほうが速くなる？

>>475
>471じゃないが、Cレベルの最適化限定なのか?
だとしたら、キャッシュやスワップがどうこうなんて関係ないと思うのだが。
逆に、キャッシュやスワップを云々するならそれらのサイズに影響するわけだから、
CPUに依存した話になってしまうだろうし。

>>477
Pen4が、Pen3がってのは、吐き出すコードの並べ順とかそういう要因だから、Cコード側でどうにもならんだろ。
キャッシュどうこうは、配列や構造体のサイズを変えたりなどのCコードレベルでの最適化ができるだろ。

SSEを使ったベクトル化もベクトル化しやすいCコードにするなどCレベルでの最適化の範疇だな。

アセンブリまで意識した時点でCレベルではない。
たいていCプログラマに求められるものではあるが。

ダンゴさんの鋭い意見が望まれるな

かわいそうな奴はもう放っとけよ

通院中だから、ちょっと待っててね。

VC++の浮動小数点ですが、
/fp:precise fast strict
の中でどれが一番精度が高いのでしょうか？
デフォルトのpreciseだと思っていたのですが、
floatをdoubleに変えたときの結果に一番近かったのが
fastだったのですが。

>>484
まず、floatをdoubleにした結果に一番近いの意味が不明

>>484
x86のFPUはfloatだろうとdoubleだろうと、内部では80bitで計算している。
そのために、floatの計算で本来なら丸め誤差が発生するはずのところで、
誤差が発生しないという問題が生じる。

厳密に規格で決められた通りの精度で計算するためには、1つの計算が
終わるたびに丸め操作が必要になる。

その辺のコントロールをするのが/fpオプションで、fastは速度優先で
最低限の丸め操作しかしないので計算の精度が必要以上に上がってしまう。
また、どのタイミングでメモリにストアされるかによっても、計算結果が
変わってしまうので、全く同じ入力を与えても常に同じ結果になることが
保証できない。

>>480
命令の並び順こそモダンなCPUではOoOがあるからあんまり影響しない。

レイテンシの極端に大きい命令に展開されるのがわかってる場合は
アンロールしてソフトパイプライニングするのも有効。もちろんCレベルでできる。

C++なら機種依存の手続きをトレーツ(笑)にしてインターフェイスを汎用化する手もあるね。

>>481
黙れスイーツ(笑)

>>****
ご希望にお答えしてお前は放置

>>483
おう、闘病がんがれよ

NGnameが増えたのか？

どうぞどうぞ

>>486
コードが同じならメモリにストアされるタイミングも同じで、
同じ入力を与えたら同じ結果になるんじゃないの？
それとも、入力ってのはソースファイル（コンパイラに対する入力）のことかな？

>>490
レジスタからあふれてメモリに追い出されるときに丸めが生じる。
同じ式が違う場所にあるときに丸めるタイミングが違ってくる可能性がある。

同じ位置にあるコードでの話じゃなかったのか。

同じ位置にあっても、コンパイルされるたびに毎回同じ結果に
なることが保証できない。

つまり、入力ってのはソースファイル（コンパイラに対する入力）のことになるわけだね？

いや、関数に対する入力のつもりで書いたんだが。
言いたいことは491の言ってることだな。
クライアントとサーバで同じ式を書いても同じ結果にならなかったり、
デバッグ用のコードを入れたら結果が変わったり、インライン展開
されるかどうかで結果が変わってしまう。

コンパイルしてしまった後のプログラムがあって、
それの全く同じタイミングに実行される全く同じ位置のコード（マシン語レベルで）に
全く同じ入力を与える場合を想定してたんだぜ。

ダンゴさんのレスでスレが一気に加熱したな。

メモリ４倍にしたらCPUの処理速度が４０％以上遅くなった。

CPU の問題じゃなくて、サイズの違うメモリを使ってるからじゃないのか？

単純に、交換したメモリが遅いだけじゃないの?

CPU が遅くなったと言うなら、
レジスタのみの演算をぶん回して
比較しないとな。

Intel入ってないだけじゃないの？
Athlon 64の前のモデルではメモリ増やすと逆に遅くなる現象があるらしーな。

PenDの速さの実感できなさ具合は異常

あぼーん推奨ワード:ダンゴさんの

同意

ダンゴさんが復活したおかげでレス数がうなぎのぼりだな

あぼーん推奨ワード：ダンゴさんが

あぼーん推奨ワード：ダンゴ、団子

だんご大家族♪

DANGOさんのおかげでEDが直りました

superπでチェックしたが明らかにＣＰＵトロくなった。256を1Gに変えたのだが。

弾固さんのおかげで層化学会に入ることができました

どうせ128MBの板を何枚もポトペタしただけなんだろ？

板です。128kgまで耐えられます。

面白くないから黙ってろ

>>511
OSは？Windows 2000は512MB以上はほとんど管理してないよ

>>515
お前も面白くない。自分に適用しないジャッジを人に適用しないようにな。

以降、面白さを最適化するスレになりますた。

面白さのサイズが最小になるのか

以降、面白さを最適化するスレを最適化するスレになりました。

>>1 に goto >>1000 って入れときゃいいんじゃね？

僕らが一つと半分のスレッド、時間にしてほぼ4年の月日を消費して分かった事、それは
どんなにメモリを必要とするプログラムを書いても副作用がなければそのプログラムは
何もせずにOSに制御を返す1024バイトにも満たないデータ列と同じだという事。

いや、今わかったのはたぶんあんただけよ。

ＤＡＮＧＯさんのベンチマークは副作用で満たされているな

それを言うな

副作用でスレが荒れる

メモリ2G積んでるけどそっちがフル稼働するずっと前にCPUがまんまんになる

以降下ネタ禁止

ISAバスのEMSメモリカードが遅くて泣いたのはいい思い出

私のPCは、CPU温度は低いのにGPUはちんちんに熱くなる。

それ普通

>>527
それは今時普通ですから

ある C++ のメソッドを アセンブラに書き換えたら、かえって実行速度が遅くなった orz

あるある。
コンパイラってマジ賢いわ。

それがさー 多倍長整数の１ビットシフトと論理積処理なんだぜ

r = (r << 1) & mask; // r, mask は多倍長整数

こんな単純な処理はキャリービットを使ったシフト命令が使えるアセンブラの方が絶対速いはずなのだが
アセンブラにすると、グローバルな最適化がうまくできないみたいで、C++ よりも遅くなったみたい

そう言うときはどういう処理吐いてるか見た方がいいよ。

>>535
差し支えなければC++とasm双方晒してくれ。

局所的な最適化は必ずしも大局的な最適化とはならない事のいい例だね。
例えば最近のコンパイラなんかは、一回のコンパイル時間が長くなっても
エラーメッセージなどを丁寧に出力するから、結果的にコードを修正する時間が短くなって
コンパイル回数も減り、開発時間が短くなる事に寄与している。
コンパイラ賢い。

>>535
パイプラインが詰まるようなコード書いたんじゃねーの。

キャリーっていう１つしかない資源を使う限り、
詰まらざるを得ないんじゃないかな。

多少コードが増えてもCPIが上がれば逆転するから、安易なインラインアセンブラの使用は割に合わない。

asmのおかげで回りの最適化が効かなくなってんじゃないか？処理時間の短い関数をasmにしても逆効果だよ。
ループを含めるとか、ある程度処理時間がかかる部分をasmに直そうよ。

もちろんコンパイラが吐き出してるソースチェックしたよ
そしたら グローバルに最適化されてるってことがわかったんだよ

>>537
うーん、そのままだとちょっと差し支えがあるので、
晒せるように書き直せるかどうか試してみるよ

＞グローバルに最適化

の意味が解らん

以下のようなクラスがあって

class CShiftAnd
{
uint m_nReg;
uint *m_pR;
uint *m_pCV;
uint m_exitIndex;
uint m_exitMask;
public:
CShiftAnd(int);
~CShiftAnd();

bool setEntryState();
void transition(uchar);
void transition_asm(uchar);
};

bool CShiftAnd::setEntryState()
{
*m_pR |= 1;
return (m_pR[m_exitIndex] & m_exitMask) != 0;
}

void CShiftAnd::transition(uchar ch)
{
uint *ptr = m_pR;
uint *pCV = m_pCV + (ch * m_nReg);
uint carry = 0;
for(uint i = 0; i < m_nReg; ++i, ++ptr) {
uint nextCarry = *ptr >> 31;
*ptr = (*ptr << 1) + carry;
*ptr &= *pCV++;
carry = nextCarry;
}
}

void CShiftAnd::transition_asm(uchar ch)
{
uint *pR = m_pR;
uint *pCV = m_pCV + (ch * m_nReg);
uint nReg = m_nReg;
__asm {
mov edi, pR ;; edi = m_pR
mov esi, pCV
mov ecx, nReg
xor eax, eax ;; clear carry
L01:
mov eax, [edi]
adc eax, [edi]
and eax, [esi]
mov [edi], eax
lea edi, [edi+4]
lea esi, [esi+4]
loop L01
}
}

以下のコードでタイムを計測した
buf のサイズは1000なので、10億回ループする
{
StopWatch<> sw;
CShiftAnd sa(31);
for(int i = 0; i < 10000 * 10; ++i) {
int count = 0;
for(cchar *ptr = buf; ptr < buf + sizeof(buf); ) {
if( sa.setEntryState() )
count += 1;
sa.transition(*ptr++);
}
}
}

おいらの環境でタイムを計測すると
1.125秒

sa.transition(*ptr++); を sa.transition_asm(*ptr++); に変えてタイムを計測すると
1.469秒
だった

中身全然理解してないけど
なんでedxを使わないでレジスタ変数に使われる(push/popが必要な)esiやediを使ってるの、とか
あなたの読んだ最適化に関する文書に、LOOPを使うことについて何か触れられてなかったのか、とか

>>551
じゃ、アセンブラでどう書いたら高速になるのかコードを晒してくおくれ

何が「じゃ」なんだろ。まったく話が繋がってない。

>>552
最適化技法の専門書でも読め

C++のソースレベルで見ても
ロード/ストアの形にするのも基本だし
カウンタ(i)を用意して非定数のlimitと比較するくらいなら、first/last形にするのが常識だし
(まあこれは0との比較に変えてるみたいだからいいか)

といっても、その程度は最適化コンパイラなら当たり前にやっていることだけど

で、結局、「グローバルに最適化」とは何なのだろう。

>>538の「大局的な最適化」と同じ意味だろう。
別に何かの規格で定められた専門的な用語ではないはずだ。

いや、わかっててネチっこく絡んでるだけなら、野暮な説明だけど。

おまいらもっと速いアセンブラのコード晒してやれよ

>>557
いや、だから「どこを見てコンパイラが大域的な最適化をしていると判断したか」という話よ。
単に「自分の書いた(付け焼刃の)アセンブラより速かったから
大域的な最適化をしているに違いない」と言ってるとしか見えないわけさ。

>>559
543 名前：536[sage] 投稿日：2008/03/13(木) 19:09:16
もちろんコンパイラが吐き出してるソースチェックしたよ
そしたら グローバルに最適化されてるってことがわかったんだよ

VC++は、インラーインアッセンブルルルルァ使った関数はインライン展開とかできません。

余計意味わかりませんけど。
例えば、そのグローバルな最適化によって、
>>547はどのようなアセンブラコードになるのですかね？

　　　　　　☆ ﾁﾝ　　　　　ﾏﾁｸﾀﾋﾞﾚﾀ〜
　　　　　　　　　　　　　　　　　　　　　　　　ﾏﾁｸﾀﾋﾞﾚﾀ〜
　　 　 　 ☆　ﾁﾝ　　〃　 ∧＿∧　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣
　 　 　 　　ヽ　＿＿_＼（＼・∀・）　＜　速いアセンブラソースまだ〜？
　 　 　 　 　 　 ＼＿／⊂　⊂＿ )　　 ＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　 　 　 　 　 ／￣￣￣￣￣￣ ／|
　　　　　　　|￣￣￣￣￣￣￣|　 |
　　　　　　　|　　愛媛みかん　|／

団子さんのレスが期待されるところだ

いやもうレスしただろ

SSEの使えないコードは汗んブラないのが俺のモナー
よく読んでないけど使えそうだけどな

>>559
> いや、だから「どこを見てコンパイラが大域的な最適化をしていると判断したか」という話よ。
このタイミングで急に新しい話題始めるんですかー。

loop は遅いから使わないってのは基本だと思うんだがなあ。

コンパイラより自分でアセンブったコードの方が速いと根拠もなく信じてる人もたまにいるので。

そんなん信じてる馬鹿ここにはまずこないんじゃないの

x86・RISCやキャッシュてんこ盛りのプロセッサだと今時のコンパイラを超えるのは至難だろうな。
組み込み系の貧弱な石ならアセンブラの方が速い事は多々あるけど。

コンストラクタ無し/デストラクタ無し/初期化されず説明の無いメンバ変数。
速いコードは書けないが、動かないコード晒されると更にやる気を削がれるな。

>>556 SSE使えるならむしろCって考え方も。
>>568 最近はmicro op fusionとかやってるから高級な命令の方がAMDみたく都合よくなるんじゃない?

安価ミスった。556じゃなくて>>566

VCなんかだとthisポインタはecx渡しになるからそこんとこ考えてコード組む必要がある。

>>548
ところで、このコードは正しい結果が出るか確認したか？

んでもって>>548はecx使っちゃってるね

>>548
86のアセンブラなんて１０年以上やってないんで自信ないんだが、途中でキャリーフラグ消えてないか？
キャリー使わずにCで書いても同じくらいの速さのコードは出そうだが。

>>577
mov, lea, loop はキャリーに影響しない
add edi, 4 でなく lea edi, [edi + 4] とするのはそのためでもある

>>578
andも？

>>579
少しは自分で調べろ

andは書き換えるだろ。

MMX/SSEもフラグレジスタを書き換えない。

Cとインラインアセンブラのソースを睨めっこしても意味ないだろ
逆汗しないと

はぁ?

はぁ。

ハァ〜ン

例A)
gethoge()->fuga();
gethoge()->piyo();

例B)
hoge *p = gethoge();
p->fuga();
p->piyo();

gethogeはprivate変数へのアクセサと仮定して、
この場合例AとBでどっちの方が早いのだろう？

fugaやpiyoがもっとたくさんあるのなら後者だろうけど
2回だけだとポインタこさえるコストも考えるとごっちゃになってきた。

ちゃんとインライン化されれば同じようなもんだろ。

>>586
処理時間で A >= B って感じ。

「ポインタこさえるコスト」とか言うが、 A でもコンパイラが
ポインタを作る。しかも繰り返し。

fugaの中でhogeが書き換わる可能性を考慮すると、AとBでは結果が異なる可能性がありそうな気も

それをいうならgethogeじゃない？ fuga一回しか呼んでないじゃん

fugaとpiyoを呼んでprivate変数の状態を変えるとか考えないのか？

vtuneって各関数でのメモリアクセス数って調べられますか？

遅延量や、キャッシュミスもわかる。

memoryのpageinput/outputを監視すれば
各関数のメモリアクセスは調べられそうですね
ありがとうございます。

>>594
writeとreadはいらないの？

>>595
メモリアクセスはin/outだけじゃ・・・

vtunesの使いかた分かんね。
どうやったらプログラム実行終了時の
各関数のそれぞれにおいてのメモリアクセス数が出るんだ

>>597
命令ごとのメモリや演算器、キャッシュ、バスのタイミングが見える。プロファイラなんかとは次元が違う。

>>598
それぞれのメモリアクセスはどこみればいいのか分からん
全体の1秒あたりのメモリアクセスは出てるけど

vectorって配列に比べて最適化されにくい？

そうでもないよ

ダンゴさんは博識にもほどがあるな

スタックに置く場合以外は同じだろうね。

602 名前：あぼ〜ん[あぼ〜ん] 投稿日：あぼ〜ん

上に同じ

「TASさん」みたいなノリですね、わかります。

ダンゴさんの書き込みでスレが再加熱したな

607 名前：あぼ〜ん[あぼ〜ん] 投稿日：あぼ〜ん

608 名前：あぼ〜ん[あぼ〜ん] 投稿日：あぼ〜ん

あぼ〜ん推奨ワード：ダンゴ、だんご、団子

610 名前：あぼ〜ん[あぼ〜ん] 投稿日：あぼ〜ん

>>610-611
ｗ

ｗ　ってどういう意味？

藁ｗ

>>614 には失望した

なら俺は干草

>>600
コンパイラによるがされにくい。
PGIでは、vectorのまま[]でアクセスしたループはベクトル化してくれないが、
一旦ポインタに変換してループを書くとベクトル化する。

vector使うなら、operator[]を使わずにiteratorを使うだろ。常考

iteratorなんかつかったら余計に最適化されねーっての。

されますが何か。

その手があったか。
vectorに限って言えばiteratorはまず間違いなくポインタだろ。
ということは最適化される。

すんません。
vector<double>::iterator p = v.begin();
を使って、
p[i]
でアクセスしたらポインタと同等の最適化されました。

ただ、for文の終了条件を p != v.end() なんてことしたら
ループの回数が不明ということで最適化除外されました。

std::vector<F32vec4>

から派生の方向で

アクセッサ？ほぼ再実装だね

>>622
コンパイラは？

ダンゴさんはVCの最適化については一言言いたいところがあるようだな

>>624
PGI

623 名前：あぼ〜ん[あぼ〜ん] 投稿日：あぼ〜ん

＞p != v.end()
毎回インスタンス変数見るのか。

for(int i=0,sz=v.size(); i<sz; i++){...}

for(iterator i=0,end=v.end(); i!=end; i++){...}

のどちらかだろ常考。

本来その程度の事は自動でやってくれるべきだけどね。
高級アセンブラだから細かいところに気を使うんだよな。

それを自動でやったらvolatileを勝手に外すくらいの暴挙じゃね？

正当にやれるのは、v自体がローカル変数で、
ポインタを取られてないことを解析出来る場合だけど、
その前提を維持するより一時ローカル変数に移した方が簡単だと思う。

ああそうか。あー!面倒くさい!
もうローカルでポインタを取得してないメンバ変数やグローバル変数が
外から変更される可能性がある場合は全部volatile付けるって事でいいよw

なんてやってるとvolatileだらけでどっちが面倒くさいんだか分からなくなってくるな。

パソコンだとマルチスレッドなんてあるから、
volatileが付いていてもいなくても
付いているのと同じように扱われている気がする（ローカルな自動変数以外）。

volatileは厳密にメモリのアクセス回数を決めるための物だから
同じってことは無いだろうけどね。

>>633
釣りかネタだよね？

バカの可能性もあるな。(w

流れ見てないんだが…
ここは「volatile 宣言最強！！！」って言わなくちゃいけないところですか?
はずしてたらごめんなさい

volatile は毎回メモリにアクセスするようにするものだとか
マジレスしたらいけない流れなんだろうな。

お前らボラれてるぞ

volatileは最適化抑制です。

>>637
> volatile は毎回メモリにアクセスするようにするもの
なのは, いいんだけど >>634 な, ものがあったから
ちょっと言ってみたかった

>>639 そんなもん分かってて遊んでるんだからほっとけや

volatile is a hint to the implementation to avoid aggressive optimization
involving the object because the value of the object might be changed
by means undetectable by an implementation.

ダンゴさんのレスがピシッと決まったな。

643 名前：あぼ〜ん[あぼ〜ん] 投稿日：あぼ〜ん

さすがダンゴさん

644 名前：あぼ〜ん[あぼ〜ん] 投稿日：あぼ〜ん

＞名前：あぼ〜ん[あぼ〜ん] 投稿日：あぼ〜ん

これもあぼ〜んしとくわ

>volatileは最適化抑制
厳密には違うけどまぁ別にいいや

volatile は処理系には検知できない手段によってオブジェクトの値が変更をうける可能性がある場合に
オブジェクトへの積極的な最適化を抑制するための処理系へのヒントである。

1: int i;
2: i = 1;
3: i = 2;
4: i = 3;

こうしたとき2行目3行目の代入された数値は使われないので、最適化されて消される。
しかしデバイス制御などでiがデバイスのアドレスの場合、消されては困る場合がある。
こういう時、宣言の前にvolatileを付けたら最適化されないので意図した動きを得られる。

マルチスレッドかメモリマップド I/O で使うのが定番だな。

> マルチスレッド

マルチスレッドでのvolatileについてはダンゴさんが一言ありそうだ

クリティカルセクション自身も volatile にするだろ？

フラグ程度なら害はない。

volatileで万全！

double-checked locking とか泥くせえよなあ

メモリオーダリングはしょうがない。volatileは悪くない。

もう -O0 でいいじゃん。

-O0 で毎回メモリ読みに行くことは保証されてるのか？

それ以前に volatile では保証されてんのか？

> 処理系へのヒントである。

とか書いてあるとちょっと不安なんだが。

規格上はメモリアクセスは保証されない
ターゲットにメモリが存在するとも限らないし

Java だと昔 volatile がちゃんと実装されてないとか聞いた事あったけど、
C/C++ でそういう処理系は聞いた事ないな。
inline や register みたいにヒント扱いだから
規格上はそのあたりの挙動は処理系依存なのかもしんないけど、
先ず心配しないでいいとは思う。

A8.2 型指定子によると
| volatileオブジェクトについては、処理系独立な意味付けは行われていない。
とあるから安心していいのでは。

register を無視するコンパイラがあるように
volatile を無視するコンパイラ程度はあってもいい気はする。

>>664
volatileを無視するコンパイラは最適化禁止だな。

特に最適化しなければ volatile だから
全て volatile なコンパイラはあっても
volatile 無視するコンパイラは少なそうか？

元の意味が「揮発性」だっけ。



規格準拠をうたうコンパイラで、そういうのは聞いたことはない。

まあ、そういう処理系を作ろうと思えば作れるんじゃないの？

こうですか？
#define volatile

__declspec(align(32)) みたいなのを規格化してほしーな

アラインメント関連は C++0x にもう入ってるだろ？

どっちかというとCに入れて欲しいんだが

それは確かにw

ダンゴさんの書き込みへのレスのすばやさは宇宙一とおもわれるほどだな

673 名前：あぼ〜ん[あぼ〜ん] 投稿日：あぼ〜ん

メモリバリアはcpuか評価環境で変わってくるんじゃないの?
ほとんどosにそれを通知するような機構があると思うんだけど。
javaのvolatileはそれを保証するものになるらしいが。

本当に意味のある最適化が仕様的に禁止されてる言語に対して何期待してるんだ?
実質的に高級アセンブラじゃん, 言語仕様が…

なんか、また変なのが涌いてきたぞ...

まぁマテ、じっくり話を聞いたらなんてこたぁない普通の話かもしれん。
聞きたかないが。

ポインタがあるせいで禁止される最適化の話じゃないのかな？

>>666
gccに-fvolatileと-fvolatile-globalってオプションがあったらしい。
前者はポインタからの間接参照、後者はグローバル変数の参照を
全てvolatile扱いするというもの。

見付けたドキュメントは古そうなのだったから、
最近のgccにもあるかどうかは知らないけど。

スレが静まり返ったな

組み込み行きたい、.net開発とかいやだよもう

>>682
私と一緒に働きましょう!
就職フェアでお待ちしてます。

後置インクリメント/デクリメントなんて消えればいいのに

消えてるし

後置インクリメントを使ってるソースは消えればいい
特にパラメータ化された型のインスタンスに対して使ってるやつ

一時オブジェクトが必要になるしな。

わたしのこと、そんなに嫌い・・・？

むしろ後置の動作が前置になって前置がなくなればいいと思う

それもそうだな。

>>683
もう働いてるんだって、前は自動車のOSとかやってた

>>691
最近だとトヨタさんががんばってるみたいだけどあれどうよ？

あー、うちの課の私の隣のチームがトヨタさんのシステムやってますね。
# 私は非組み込み。

実際他社のそれってあんま知らない

というか正直1年もいないで他のチームいったからな
あの数ヶ月は楽しかった
Javaを経てそっちいって今は標準化（）わらいチームだ

むしろ標準化の方がよっぽどいきたくないな、いい会社ならやりがいありそうではあるが・・

自分のソースを貼ったら最適化してくれるスレってある？

張ってみ

貼るなら普通にSourceForgeとかに置いて、
その辺のスレで添削のお願いとかした方がいいんじゃね？
運が良ければバグとか直してくれる暇人とか来るだろうし。

>>696
数学板とかいくとアルゴリズムレベルで最適化してくれるが
# 早い話、俺はどこまでアフォなのかを教えてくれる

2次元拡散方程式の最強のコードを教えてください

>>700
貴方がこれから知ったことをすべて教えてくれるのなら...

>>700
ちょっと調べて見たけど、隣り合うところとしか計算しないから
並列化することで計算速度はあがりそうに思える。
しかし単純にスレッド化しても、パフォーマンスがあがるわけではない。
なぜならCPUのキャッシュにヒットするかどうかが鍵になるので
キャッシュ漏れが発生するような並列化をしてしまうと
ペナルティが発生してしまうためである。

またL2キャッシュ漏れが発生して当然というぐらい大量の要素数について
計算するのであれば、並列化することで高速化は図れると思うが
やってみないとわからないし、環境に依存する。

よって最強を求めるならば
要素数や初期条件で最適化は変わるのは当然なので
何がやりたいかちゃんとかかないとだめ。

最強 == 汎用
汎用 != 最強

キャッシュ漏れってなんだ？

キャッシュミスのことかな？

　

>>702
「ラムダ持ち上げとかやって本当にグローバルに取らなきゃいけない変数は
まとめて局所的に集約した形でヒープに、そうでない変数はスタックに取る」
とか
「計算方法と使用可能なリソースを分析して配列自体の要素のならびを
スパースに取る(CPU n 個いれば, キャッシュラインサイズ * n で集めら
れるように配列を配置しておいて, N スレッドに自動配分する」
ってのが、賢いコンパイラ

高級アセンブラの C とか C++ とかは上記のような最適化を許されない言語
仕様が結構あると思うんだが…

# 結構がんばってるんだけどな, 大規模並列用の C コンパイラ
# だけど fortran とか, チューニングされた lisp 系言語には負けてるよな

下手に最適化しすぎるとgccに対するLinusみたいにボロクソ言われるしな。
言語仕様として低レベルと高レベルを同じ次元で扱ってるのが問題。

スピルアウト？

誤爆

キャッシュミスのことです。L2キャッシュに乗らない場合のことね。

アセンブラ無しのCと計算目的に最適化されてる言語と比較したら
Cには軍配あがらないよなー
てか、それでCのほうが早かったらその言語の意味ないし。
Cにこだわらないで目的に応じたツールを使うってのは
研究者としては全然ありだと思う。

最近のコンパイラは割りと賢くなってきて、
固定値になる場合は計算した結果を使ってくれるようになったけど
基本C言語ってそういうのは実装する人が考えて実装するのであって
最適化はしてくれたらラッキーぐらいのものが多い。

あくまでもC/C++のフレームワークの範囲での最適化といったら
コンパイル結果がどれぐらい小さくなるか考えたりとか、
わざとキャッシュにヒットしないようにデータを配置するとか
その程度だろうし。
あとはそういう計算に向いている汎用ライブラリを使う。OpenMPとか。

で、本当の本当に最適化したかったらアセンブラになってしまい
すれ違いになってしまうという。

そういうのに向いている高級言語って何?
アセンブラってマイクロレベルじゃよいと思うけど大域的には無理じゃない?

FORTRANなんか最適化に有利なんじゃないか

> 最近のコンパイラは割りと賢くなってきて、
> 固定値になる場合は計算した結果を使ってくれるようになったけど
> 基本C言語ってそういうのは実装する人が考えて実装するのであって
> 最適化はしてくれたらラッキーぐらいのものが多い。

いったいいつの時代の人なんだ？

VCなんかは最近はセキュリティオプション強化してるから
最適化とは逆の方向にいってるよね。

#define SECURE_SCL 0

つければ大丈夫みたいだけど、
知らないと最新の最適化するコンパイラを使っているはずなのに
パフォーマンスが落ちる。
コンパイラの努力をライブラリが無駄にしてるわけですよ。

あとCの最適化って基本的に書いて見てコンパイルさせて
アセンブラ見て最適化されてるか確認して初めてわかるものじゃない？
バージョンがかわったりオプションかわったりすれば
コードが変わるから、それが正しいかどうか判断できないし。
ちょっと上にも誰かが書いてあるけど、最適化するには条件があって
その条件をちょっとでも外れると最適化されないし。

どこまで要求するかで話変わるし
最適化と一言でいっても人によって受け止め方は違うんですよ
自分は最適化してくれたらラッキーぐらいのコードを書くことが大半ですから
最適化がそのプログラムの根幹に関わるようなことはあんまりないです。
ある場合はSSEの出番だし。

自分にとっての最適化はアセンブラだし
人によってはいかにコピーを発生させないかというレベルのものだろうし
研究用との人なんかは結果が速く出れば計算機資源は関係ない人もいるだろうし

ただ、下手なコード書いても速くならないこともしっている。
コンパイラも賢いからね。

コンパイラは何を使ってる？

まぁ、SSE使うのも今のコンパイラだったら当然視野に入っているしね。
一番困るのは、「forよりwhileが速い」とか「[]で書くより*で書くほうが速い」と言った古い流儀を引き摺ることだったり。
特にiccのようなコンパイラは、典型的なforの使い方をした場合により最適化するようだしね。

>>707, >>711, >>715, >>717
ネットかなんかで見たこと書いてるだけなんだろうけど、微妙に理解力が
足りない感が痛々しいな。

inline fortranはまだか

extern "FORTRAN" のほうが欲しい

>>718
どこが足りないのか指摘してください。
勉強になるんで。

「微妙」とか「感」という表現からして、あんまり期待はできないかと。

自分のふとした思いつきとか、「何となくそんな気がする」というフィーリングが、
この世の何かを「ピタリ当てている」と信じたい、そういう年頃ってあるでしょ。

48歳位か

実際、人によっては一生モノではあるね。

>>718
715の最適化についてのレスを書いたのは俺だが
715はメインがSSEとかアセンブラって言ってるから的を外してないと思うぞ。

>>719, 720
俺の経験上、ベクトル化はマジ信用出来ない。
有効に働くのは全要素に単純に四則演算と超越関数を与えるときだけだから
融通のきかなさはGPU以上。
ぶっちゃけそんな単純なコードならCでfor回したって読みにくくならないし、gccもVC++もベクトル化してくれるんだよ。

ただその他のレジスタの使い方とかインライン化みたいな
帯域的な最適化は賢いから高級アセンブラとしては依然有効。
あとcomplexをベクトル化するのも面倒くさいから有効。

分かりにくかったな。
俺は715じゃなくて、715が参照してる最適化についてのレスを書いた人。

んで、超越関数はgccやVC++ではベクトル化出来ないから
単純な計算式に超越関数が入ってる時はIntelのコンパイラが有効。

まあそれにしたって対象が全要素じゃない事も多いし
結局自分でSSEで書いてる。

丁度今日はとあるメモリアクセスを伴うロジックで最適化オプションをいろいろ試してた。
--
gccのオプション→　　なし　-O　　-O2　-O3　Xeon w/icc
旧アルゴリズム(SoA)　1.06　0.71　0.82　0.98　　　0.05
新アルゴリズム(SoA)　0.16　0.12　0.06　0.06　　　0.03
新アルゴリズム(AoS)　0.42　0.10　0.03　0.02　　　0.02
--
旧アルゴリズムは何故かO2以降で遅くなるし、
新アルゴリズムは最適化しない場合を除きAoSの方が速いし。
最後のXeonを除くと、他はPen4なのでその所為なのかも知れず。
つーか、折角の新アルゴリズムの効果がXeonだとあんまり目立たないのねん。

Xeonだからって10倍も速くなるものだらうか。
gcc/icc の違いによるのではないだらうか。

ベクトル化でうまくはまれば10倍も十分ありうる。

新アルゴリズムはgccとiccの(時間的な)差は出ませんでしたね。
結論から言えば、CPUをWoodcrestXeonにしてiccをv10にして-Xtにすればもう少し速くなるのだけれど。

超越関数ってexpとか？

超越数でぐぐれ

キャッシュのヒット率大きいんじゃあないか

キャッシュベンチしてもねえ

キャッシュにヒットするようにコンパクトにするっていうのも
最適化の一つだけどね。
ベンチが自分のやりたいことにあってるかどうかが重要。

キャッシュサイズがどんどん大きくなってるから
そういうチューンは無駄かも

L1は増えない

何でAMDは、Intel C++ Compilerみたいなの出さないのかなぁ・・・。

ライフがすでにマイナスだから（笑）

2のベキ乗間隔でメモリアクセスするとキャッシュミスヒットしやすいと、RS6000だかの説明にあった。

うん、キャッシュラインが上書きされる可能性が高くなって、キャッシュに存在する可能性が下がって効率が悪くなるからだね。

結論: メモリアクセスは素数間隔で行うべし

系）配列のサイズ（一番下）を２の冪にしてはいけない

そうは言ってもループバッファとか扱ってると余りは求めたくないしねえ。

ループ？
全部展開しろカス

リングバッファって言えばいいか。

２のべき乗の配列を取りたいなら、
セットのサイズ（キャッシュサイズをセット数で割った数）の倍数のアクセスが増えると効率が悪くなるので、計算順序を変えるとかでそれを外せばＯＫ。
セットのサイズに満たない配列は気にする必要はないかな。

>>747
セットってのは, コンパレータの個数で ok?
でもって、ラインサイズと素な数で戦えば ok と言ってる?

間違ってた
ラインサイズxコンパレータ数と素な数

>>748
下の絵でアドレスでコーダがセットのライン数になる
http://upload.wikimedia.org/wikipedia/ja/d/d2/Read_4waycache.png
素因数にラインサイズｘライン数が含まれると効率が下がる。
でもラインサイズに合わせるのは正解なので、ラインサイズｘ素数または、ラインサイズｘ（ライン数を因数として含まない数）がいいんじゃないかな。

int[][]こんな感じのデータ構造に対する
効率化の手法まとめたページどこにいったっけ？

if(n % 2 == 0) n / 2
if(n % 2 == 1) n * 3 + 1

int *[]にして列を都度割り当てすれば・・・

ダンゴさんの書き込みでスレがdat落ちの危機に瀕したな。

ダンゴさん兄弟

やはり皆、半月以上レスが無くてもスレ見てるんだなｗ

専ブラ使っているんで、レスがあれば一目で分かります。

風呂から出てチンチンブラブラしてますたー

それは非専ブラ組の発想ではないかな。
専ブラ組からすれば、新着レスのあるスレを一覧上部に集めて順に見ていく作業の一過程。
つまりdat削除しない限り、忘れてても縁は切れない。新着レスがあるたび、こうして思い出すことになるｗ

う、かぶった。

実際、専ブラによって色々とスタイル変わってくるよね。
・・・良いんだか悪いんだかわからないけどｗ

ごめん、名前間違えた。
これも専ブラならではか？（マウスホイールしちゃって、前回別の場所で使った名前が出た）。

ずっともぐってたスレが一度あがって半端におちてると見失うｗ

そういう時は履歴！

代々木の
カレーライスうまいよね

uint64_tの値を

16bitずつ小分けに取得したいのですが
何型にキャストするのが正しいのですか？

uint16_t でええんちゃう？
そもそも、質問の意図が、そう言う話とはちゃってる？

union知らんのって話でしょ

>>765
キャストは最後の手段にしようぜ。
ふつうに u64 & 0xffff, (u64 >> 16) & 0xffff, .... でいいでしょ。

ここは最適化のスレだから、一番最適化がかかりそうな
方法を聞いているに違いない。
配列としてアクセスするのが一番期待できるかな？

>>769
動作保証が無けりゃ問題外でしょ。ビットシフトで取り出すように書いとけば、
コンパイラが勝手に 16 ビットずつメモリから読み出すように最適化することも
できるだろうし。むしろメモリへのアクセスを陽に書かないほうが早い可能性もある。

union

>>767,771
エンディアンに依存したらダメじゃね？

そんなあなたに #if

最適化するんだからマシン固有の癖(エンディアン)に
依存する問題まで考えて移植性を重視する必要ねーだろ

それぞれの環境ごとに最適化すればいい

pextrwで（ｒｙ

bswapも(ry

小分けしたいだけなんだからエンディアン考えなくてもいいんじゃないかと思う

union 使うなら考えんといかんだろ？

そもそも今時のプロセサならバレルシフタぐらいは積んでるだろうから、
>>768 で十分だと思うが。

ビット演算だけで、剰余を求める方法を教えてください

646 名前：デフォルトの名無しさん[] 投稿日：2008/01/23(水) 21:06:35
割り算を掛け算とビットシフトに置き換える計算式求めるプログラムできた

#include <iostream>
using namespace std;
main(){
unsigned int N,n,k;
for(N=2; N<65000 ; N++){
for(n=0; (1<<n)<N ; n++); n+=15;
double X=(pow(2,n)/N);
unsigned int Y=(unsigned int)X;
unsigned int d=0;
if(X-Y<=Y+1-X)d=(unsigned int)(pow(2,n)- (N-1)*Y)-1; else Y++;
printf("x /%5d = ( x * %5d + %5d ) >> %2d",N,Y,d,n);
for(k=1; k<(1<<16) ; k++) if(k/N != ((k*Y+d)>>n))break;
if(k==(1<<16))printf(" OK\n"); else printf(" ERR\n");
}}

647 名前：646[] 投稿日：2008/01/24(木) 15:42:18
64bit機か、内部で64bitまで計算結果を保持しているなら
32bitの割り算も出来るけど646は16bit同士です

2^n の剰余　とそれに近い数の剰余は簡単にも止まる。

止めんなw

>>780
あらかじめ除数がわかってないと>>781は使えないよ。

ナベアツコンピュータ
配列が2のn乗の時だけキャッシュミスヒットが増えて、ループに条件分岐がある時だけベクトル化できなくなります。

その2^nで不意にキャッシュミスヒットが増える条件ってなんだっけ

同じラインに乗る

というか、除算・剰余にビット演算を使うような厨テクなんて
最近のCPUじゃマイクロコードレベルで同等かそれよりエレガントなことやってるだろうから
よっぽどガチガチのRISCでも使わない限り覚えても意味ないよ

>>788
具体的に

ダンゴさんがCELLプログラミングをアツく語りたいようだ

>>788
一例をどぞ

http://journal.mycom.co.jp/column/architecture/090/index.html
ここにも書いてあるけど、SRT法といってROM上のテーブルから2ビットないし4ビットずつ辞書引きして
求める方法が大分前から主流

実装方法は
http://www.iit.edu/~upadsau/ece529/html_report/ece529_report.html

Radix-16レベルになるとNewton法ですら歯が立たんケースが多い。

うわひどい画像で嫁ん
PDFのほうがいいみたいだな
http://www.iit.edu/~upadsau/ece529/ece529_report.pdf

ダンゴさんのレスのおかげで太陽系が終焉を迎えたな。

古いCPUと枯れたコンパイラの仕事はもう無いっておもってるのか？
それとも、ダンゴがアホなのか？

そんな仕事もうないです
あってもそんな奴隷ドカタ仕事したくありません

8051はいまだ現役なんだが

お値段手頃なプロセッサはまだ現役なんだがなぁ、だんごはx86しかしらんらしい

まぁ主語をでかく言うやつ多いよな
8051なんて数人しかいないだろ

一例を出されたらマイナーなプロセッサの話にシフトしてﾜﾛﾀ

日本語変ですよん

意味が伝われば良いんだよ。
分からないなら別だけどなｗ

アホなのは>>795

俺は仕事でMC6805の末裔を使ってるが、
組み込みって、仕事の数としてはどうなんだろう？

ゲーム機向けCPUは今でも整数除算が遅いから、今でも役には立つ。
ただ、不動小数点数除算がそこそこ速いから、場面にもよる。
まあ、役に立つ場面があるわけだから、知識として知っておく分にはデメリットは無いだろう。

ところで、ゲーム以外の組み込みって、ホントに応答時間を重視してる？
家電の何触っても遅い気がするし、このペースなら最適化とか関係ないだろ。

>>805
組み込みは、ユーザーから見えない所のハードウェア制御の応答時間の制限ががマジ厳しい。

家電 UI のうんこ加減は殺意を覚えるな

UI以外のリアルタイム性が最重要ですから・・・

これだから組み込みを知らない奴らは・・・

いや、どっちかって言うと UI を知らなさ杉。

機器によっては UI と機器制御が別になってるのに糞な UI の機器も
あるから、>>808 の言うことは当てはまらない。

つうか普通UIの応答時間も要求仕様の内なんだが・・

UIってCPUパワーも必要だしメモリを食うし、それなのにコストや消費電力の制限で遅いCPUとわずかなRAMでやってるんだよ。

制限も理解出来るし、糞なUIとまでは言わないけど、
もうちょっとどうにか、って思うことはある。

うちのテレビの設定が右矢印キーで変更モードに入るんだけど、
左矢印キーでなく決定キーでないと変更モードから抜けられない。
で、決定キーでは変更モードに入れない。なんでやねん、と。

お前ら組み込みの大変さを理解してないだろ。

糞とか言う前にさ。

>>807や>>809が具体的にどう駄目と言ってるのかは知らないけど、
分かりやすさとか、一貫性とかの話じゃないの？
それなら組み込みの大変さとか関係無いし。

遅いから最適化関係ないだろってのが発端だし>>805

浮動小数点数を不動小数点数ってtypoする奴ってなんなの？バカなの？
固定小数点数との区別も付かないの？

typoはあくまでtypoだろう
本当に不動小数点数と思ってる奴は別だろうけど

とりあえずATOK17では、「浮動」と「小数点」が別個に変換される。
この場合、typoもありうるね。

以前、太極拳を大極拳って書いてる奴が居て、これは（少なくともATOK17では）
「たいきょくけん」で変換すれば必ず「太極拳」になるのに、わざわざ区切って変換して
わざわざ間違えてるケースだから、いやちょっと待て、って思ったけど。

>>813
あと５０円高いチップ使ってくれたらと思う事は結構ある

>>808,811,813
家電 UI がクズになる理由がよくわかる書き込みだなぁ

つうか釣りだよな?
本気で言ってないよね?

>>820
iPodなんかは、早くないしすごく使いやすい訳じゃないけど統一感もあるし、うまくできてるよね。

日本（まあ、アップル以外ということだが）の家電の組み込みは、十分練られたUIのガイドラインなしに
思いつきで作ってるようにみえる。UI次第で動作速度を10倍速く感じさせることもできるんだけどね。

ファームウェアの一部という認識しかないからね。
機器制御が第一、使いやすさ等はそっちのけ。

客が安物を望むから、仕方のないこと

整数除算（特に除数が定数のとき）なんざそれこそコンパイラのノウハウを信じろよ

彼は日本語が読めないんだ。いいか、スルーしろよ。

また例の話の流れを読まずに
ボクちゃんスゴいんだぞカキコか

スレタイが読めない人（組み込み戦士ｗｗｗ）には甘いのにね

それだけチミが嫌われてるんだよｗｗｗ

>>828 流れが読めないならスルーしてくれよ。
後半話が逸れてるが、あの馬鹿はそこを指摘してるわけじゃなくてちゃんと本題の整数除算の話をしてる。そこまではいい。

あの馬鹿の馬鹿たる所以は、肝心の整数除算についてはスレタイ通りである事。
そして自分の開発環境しか知らず、必要としている分野があるかもしれないことを想像出来ない事。
仮に必要なかった所で、スレチでもないし他に話題があるわけじゃないんだからぶった切る必要はない。
事実と自分の宗教を分けて考えろと言っているのに。

>>829
だから他所でも散々言われているとおり
人間性が根本的におかしいって話だろう
そういう相手に対し論理的にモノを考える時点で負けだぞ

おいばか、整数の定数除算を「DIV命令で処理しろ」なんて一言も言ってないぞタワケ
そもそも/演算子が常にDIVに対応するわけではないし、それこそコンパイラの最適化に委ねるべきでしょ。
「ビット演算＝トリッキーで速い」と思ってる厨が多杉

PCには左7ビットシフトよりadd eax,eax×7のほうが速い(低レイテンシ)ような
プロセッサだってあったんだぜ？そういうの含めてコンパイラに任せればいいんだよ

マイコンなんかじゃ除算そのものの利用頻度少ないだろ
高級言語レベルで除算をビット演算で置き換えることに価値があると思うなら
まともにボトルネック分析できてないから、まあマ辞めろ

浮動小数演算はdoubleが速いんですっ！

＞人間性
技術力がない奴は二言目にはこれを言うね。
そして実際口に出す奴は両方欠落してるのが定説。

ダンゴさんのレスのおかげで銀河系中心のブラックホールがまた拡大したようだ

倍精度が単精度の数分の１という悲しいCPUもある。
つかx86も最近は単精度のほうが速いんでないの？


ちなみに*printfは内部でmalloc呼んでるから除算よりよっぽどボトルネックだよ。
そっちの再実装の方がよっぽど価値あるぞ
（書式が必要ない文字列はputsとかfwriteで代用できる）

printfの最適化なんて、それこそコンパイラの仕事だろうし、実際gccではやってるわけだが。

相変わらず団子は偏ってるなw


>＞人間性
>技術力がない奴は二言目にはこれを言うね。
>そして実際口に出す奴は両方欠落してるのが定説。

おまいさんが言うべきじゃなかろうw

>>836
gccはやるな。
でもgccが使えないような人たちはそもそもprintfなんて使わない事に気づいてない。

VCではやってないから案外有効かもよ。
printfのオーバーヘッドの問題は最適化に触れてる本では必ずといっていいほど出てくる。

定数除算の乗算＋シフトなどへの置き換えによる最適化はHacker's Delightくらいでしか見たことがない。
popcountやビットスキャンすらハードワイヤードロジックでの実装が増えてるくらいだ。
たしかCellにもその手の命令があった。

>>835
> ちなみに*printfは内部でmalloc呼んでるから除算よりよっぽどボトルネックだよ。
BSD 由来の printf 系関数のように, 内部で malloc 呼ばない実装もあるんだが………

このスレおもれーなｗｗｗ
GCC以外のコンパイラでは*printfが不要らしいぜｗｗｗ
馬鹿でぇｗｗｗ

一般人の俺から見れば、お前らみんな仙人だよ。

>>840
malloc使うか使わないかだけの問題じゃないな。
そもそもヒープは再利用するからOSの呼び出しが常に発生する訳じゃないし。

書式文字列含む含まないにかかわらず % が含まれるかスキャンするのだけでも
ものすごいクロック数の無駄だと思わないか？

いやコンパイラはGCCだけしか必要ないと思ってる人には無駄だけど

だから相手にするなよ。

かまってちゃんスルーで

ダンゴちゃんは話の流れを無視して
いきなりオレサマ話をはじめるから
会話にならないよ
相手するのは無駄

でも、かわいいから許す

ダ・ン・ゴさんのレスでスレが一気にヒートアップしたな

>>820
確かに。
ユーザーが遅くて使いづらいといえば、
それが正しい。作り手の言い訳が挟まる余地はないよ。

団子が珍しく痛いｗ
おまえはx86限定のスレから出てくるなよ、あそこなら神扱いされても文句言われないだけの知識あるから。

でも俺はDANGOさんのファンだからこのスレを更新チェックしてるんだぜ

団子って
書き込む前に前提書いてくれると, 反論なり同意なりしやすいんだが
何に反応してカキコしてるんだかわからん時が………

ダンゴさんにはお世話になってるから全面的に支持するぜ！
でも提示された資料はまだ読みきってないから内容については･･･、とりあえず信頼するぜ！

ダンゴさんの仲間の書き込みでスレが落ち着いたな

ここまでの組み込み戦士くん(笑)のまとめ

・除算がプログラム全体のパフォーマンスを左右しかねないくらいに遅い
・コンパイラがヘタレで除算の最適化を行わない
・なぜか高級言語レベルでのビット演算・乗算への置き換えで劇的に性能改善できる

これ全部満たすのってどんなCPUとコンパイラだよｗｗｗ

俺がマイナーCPU無知だからと思ってありもしない環境をでっち上げるのは感心できない

・GNU以外のコンパイラではprintfは不要 [New!]

除算だとやっぱ68系の時は気を使うよな。あと、マイナーな内部CPUとか。
特にコーディング規約で最適化オプション切らないと駄目なときとか
古いコンパイラ（gccの2.95系ベースだったり)のときもあるし。

劇的な性能改善じゃなく、ループ内とかの小さな積み重ねの問題だし。
変なバス付いてると、その読むだけでウェイトかかったり、
時間制約だけ仕様書に厳しく書いてたり、だし。
結局、小さいことからコツコツやって、アセンブリの出力確認して・・・。
せめてプロファイラくらい欲しくなる時もあるけど・・・。
ICE

こういうのって俺だけ？(´・ω・`)

＞ 特にコーディング規約で最適化オプション切らないと駄目なときとか
おかしな規約だな
でも最適化するなと指示したのに性能が必要なの？

変数にvolatile付けて副作用のある最適化を抑制したりpragma使って部分指定したりとか
そういう回避手段はいくらでもあると思うが

昔の基板の改修とかって仕事だと、既に動作実績がある環境
とか言われて前の基板のソースとコンパイラとを引き継ぐなんざ
ざらだよ。コンパイラスイッチまで指定されてるし。
前の基板と同じCPUにして保守部品の在庫コスト下げる必要も
あるし、しゃーねーけど。
そうなると古い環境と古いCPUだから、必然的に枯れた技術で
対応しないと駄目になる。

まあ性能改善名目で4バイトのmemcpyを32ビット整数のロード・ストアに置き換えるだけでも
コードレビューに単体テストやらされた覚えがある。

除算なんか得体の知れない演算に置き換えたりしたら、
まあ全パターンテストどころじゃ済まないな
何のために最適化を抑止する規約になってるのか意図を考えれば本末転倒な話だ

黙れ基地外！
別スレでも最後散々証拠見せろとか喚いていたがテメェが日本語読めてないだけだ。

ダンゴは廃棄するぞコラ

ＤＡＮＧＯさんの説法が炸裂してスレが平和になったな

貢献度が高い団子ちゃんのため、次スレのスレタイは

【団子ちゃん】C、C++の最適化について語るスレ 3【専用】

が良いのではないか。

そうだ団子ちゃんが書き込んでるスレは全部これにしよう!

そこまで嫌うこともないだろ
実際盛り上がってるんだしｗ

やっぱりその条件だと68kだよな
新規は無さそうだが

>>860
IA32だとアライメントが合ってなくても遅くなるだけだが、
ミスアライメント例外が発生するCPUも結構あるから
ターゲットによってはテストが必要だろう。

>>867
最近のIA-32のロードユニットは64ないし128ビットのロード＋シフトで構成されてるので、
8ないし16バイト境界さえ跨いでなかったら実は殆ど同じ。

長さが決まってるstrncpyやmemcpyをDWORD単位のL/Sに展開する最適化はVCでもやってるな。

いってること自体は間違ってないんだが、根本的に会話がすれ違ってるって自覚はある？>>868

XGATEとCodeWarriorの組み合わせなんかそれっぽいな。

>>865
各情報は間違ってないが、全部持論に持って行こうとしているだけの構ってちゃん。
最終的には根本的に間違ってる。
(情報は合ってるが、導いている方向が間違ってる)

ならお前さんが正しいと思う方向に導けばいいだけじゃね？

ダンゴさんは本当に愛されているな

対案を用意できない奴の反論とは常に見苦しいもの哉

>>869
もちろんターゲットはx86だけど。
いや、アラインメント不整合で遅くなるとか、だいぶ知識古いなと思って

チューリング・テストに落ちそうな奴が約2名いるな…

ダンゴロイドは最適化の夢を見るか？

対案を用意するとお前が泣いて喚くんだろ。
上のレスが全部そうじゃねえかwww

技術系板で一二をあらそう
見苦しい団子が何言ってんだかｗ

しかしム板の連中は優しいよな
UNIX板みたいに有無を言わさず
追い出したりしないし

度々釘刺すけど、時代に取り残されたマイナーCPUと古いコンパイラの保守なんて知ったこっちゃないよ。
COBOLer未満のマイナー人種じゃねーか
x86,ARM,SuperH,PowerPCあたりより市場規模大きいなら謝るが
マイノリティはマイノリティらしくしろボケ

ちなみにXGATEは2005年頃発表されたS12Xに入ってる２つのコアのうちの１つで、車載用でバリバリ現役だ。

つーか、最適化するなというコーディング規約のもとで
高級言語レベルでの最適化を論じなきゃいけないようなケースなんて
まずないですから。
どことも知らない過疎の山村の「おらが村のシキタリ」
なんて、世の大半は一生知らなくても生きていけるように
本当に無駄な知識なんです。
本当に視野が狭いのは、マイノリティを自覚できないマイノリティですよ。

車選びのスレ
Q.普段は買い物程度ですが、たまに家族4人で出かけられる車を探しています。予算は250万円です。
A.スポーツカー以外知ったこっちゃないよ。オートマとかどんだけw

こうですか？わかりません(><)

で、ルネサスやモトローラのマイコンより市場でかいの？

2008年4月で累積出荷数３億個だな。

てか、S12Xはフリースケールだよ。モトローラと比べてどうするｗ

>>884
四人乗りならダイハツMOVE(笑)でも十分だな。
カローラでももったいないな。

大体にその例はおかしい。
大衆車の話の最中に農機の話をするくらいナンセンス

え、そういうスレだったの？
弱小は質問しちゃいけないの？

>>882

この団子ちゃん本物?

アレなのは判ってたけど
ここまでとは

>モトローラのマイコン

もしかして偽者？

わかりやすくコテ付けて馬鹿やってんだから、素直にあぼーんしちまえばいいだけ。

単純な荒しじゃないから
あぼーんで済まなくて厄介なのさ

ダンゴさんをアボーンしようという勢力の工作がことごとく失敗しているな

ダンゴって、電車も乗らないし、飛行機も乗らないし、電話もしないし、電気も使わないし、
水道もガスも使わない人なんだな。
組み込みのカバーエリアがわかってて寝言ほざいてんのか？
おまえがしたクソ流す水道局の制御も枯れたマイコンでやってんだよ。

パソコンとゲームしかしらない引篭もりは黙ってろ（ｗ

知らないことを知らないと言えないおこちゃまなんだよ

>>833

この発言があろうが無かろうが関係ないし、
ましてや議論が正しかろうが間違っていようが関係ない。

いい歳して論調がおかしすぎる。
丁度本人が言ってくれたから>>833をそっくりそのまま返してあげたい。

ダンゴは最初よりはだいぶ成長したけど増長気味だなぁ

いい年っていくつなの団子は
中学くらいにしか見えん

少なくとも社会人はできんだろう

増長してないダンゴさんなんてダンゴさんじゃないよ

具体的な指摘もせずにダンゴダンゴ言う奴は皆死ねばいいのに

名無しだったら誰も文句言わずスルーすると思うんだけど。

小松をスルーも袋叩きもできずに構ってしまうム板のレベルの低さつうことで

ダンゴさんのレベルの高さがうかがい知れるな

>>899
憶測だけど多分25前後。

>>903-904
いや、シャシャリ出てこないだけで話を理解出来る奴もいるよ。
奴は持論、空論、論理のすり替えは多いがCPUのアーキテクチャは人一倍理解している。たまに勘違いしてるが、突っ込みどころは少ない。

それよりファミリーカーの話題にスポーツカーとか農機とか平気で語り出して、それで結論づけて話を終わらせるのが問題なんだよ。

ダンゴさんの理解者が現れたがまったくフォローになっていないな

>CPUのアーキテクチャは人一倍理解している
理解力はあると思うが、後付けが多いのは話題が出てから調べてるせいじゃねのか？

そんなに詳しいか〜。
せいぜいヘネパタ読んだレベルだと思うんだが。

詳しいのは逞しいが
現実問題を解決できる人格と器量が
無いのが最大の問題点

どっちでもいーけどよー。
実務の人は現場の実情に縛られすぎで、団子は空論すぎ。
でも、逆の視点から見るのも新鮮だから、お前は空論とか、無駄な制約に縛られすぎとか一度忘れようぜ

詳しいだけって何の価値もないよ

そこらに居るレベルなのに
自分を神のように思い込んでしまう痛さ

もう少し修行すれば東京kittyみたいになれるぞ！

自分じゃ内容のあること書き込まない/書き込めないで
批判してるヤシはここには無用の存在なんだが

だから団子さん専用スレが必要なんだよ

x86 専用スレと一般スレに分けて、団子には x86 専用のほうへ行ってもらいたい。

まあ組み込みCPUは安いけど数は出るからそれなりの市場規模あるのは認める

でも【ソフト市場の】規模は・・・

たしかに組み込み分野において非x86にかかわるソフト技術者の需要も
拡大してるのは認めるべき事実だね。

でも個々のCPU単位でみるとまだ遠く及ばないんだよね。
Web・オープンとかパッケージとかでいうジャンルに分類されるソフトの動く
システムの大半はx86ベースだ。
ソフト資産の面で圧倒的な最大勢力だから需要が需要を呼ぶ状態。

＃大体にエンベデッドシステムの受験者の少なさ加減を見れば何が解らんかや

>>896
それまさに大衆車に対する耕運機とかトラックのポジションじゃんｗｗ

もちろん組み込みソフト屋に多重派遣比率が高いのも知ってる。
ピラミッドには底辺が必要なのも事実だよ。

レガシーCPU組み込み専用スレ立てればいいと思うんだがね。

x86に限らず、ここ最近のRISC系統のプロセッサなら大概、
除算そのものの命令はなくとも逆数や逆数平方根を求めるのにRadix4-SRTかそれ同等の手法を使ってる。
Radix-16はまだ少ない。x86ではIntelが45nmで実装を始めたばかりだ。

壁打ち乙

Ｃ＋＋に関する本で、演習(解答も)ついてるおすすめの本ってありますか？

なぜここで聞く？

>>921
どこでいいか聞けばわからないし、早く意見が聞きたいから・・・
多くの閲覧者がいるスレッドを選ぼうと。

次はマルチすな糞といわれて相手にされなくなるな

王道は「プログラミング言語C++第三版」と「〃ソリューション」
前者はC++98の規格書も同然だから持っておいたら？
あと「C++プライマー」もいい本。



たしかに
定数除算の最適化(笑)にテンプレートも使えないロートルが威張り散らすようなスレで
聞くべきじゃないな

>>917
論理のすり替え。
件の例は、回答が質問とはあさっての方向って意味だろ。

>>924
どうもありがとう。「プログラミング言語C++第三版　ソリューション」 には、
「 98年刊「プログラミング言語C++ 第3版」の練習問題の解答を提示し、
C++のより深い概念・構文・機能を詳細に解説。
ソフトウェア設計の際に新たな指針となるアイデアを提供するための補助問題
も掲載。」らしいけど、「プログラミング言語C++ 第3版」の練習問題はないの
かな？

>>924
どうもありがとう。「プログラミング言語C++第三版　ソリューション」は、
「 98年刊「プログラミング言語C++ 第3版」の練習問題の解答を提示し、
C++のより深い概念・構文・機能を詳細に解説。
ソフトウェア設計の際に新たな指針となるアイデアを提供するための補助問題
も掲載。」らしいけど、「プログラミング言語C++ 第3版」の練習問題は載って
ないのかな？

ごめんマイノリティがマジョリティのごとく振る舞うのが滑稽なだけよ
それともソフトの市場規模がハードの個数だけで決まるとでも思ってたの？


つか組込ソフト市場でのシェアすら携帯やゲーム機で使われてる
MIPSとかARMなんかの方がずっと大きいと思ってるんだが
68kのノウハウなんて何の役に立つの？

>>927
C++第三版自体に練習問題が載ってる。
規格の説明がメインなので問題数自体はそんなに多くないが、
解答だけで一冊分厚い本が作れた程度には問題の中身は濃い。
飲み込みのいい人にはこれだけで十分。
まあプライマーが一番いいんだけど、でかすぎるので気力のない人にはおすすめできない。

あとiostream周りはミス設計なので無理知らなくてよい。
STLも全部使ってみる必要はない。

君には役に立たなくても、例えばx68kで質問された時に
OoOが云々言われてもそれこそ役に立たないだろ。

専用スレを立てるべきという意見とかは過疎るだけな気もするが別に異論はない。

他にあさってな例は、某スレでの「クタざまぁ」と言いたげな発言。
スレの住民には何の意味もないし。
嫌いなら、そしてスレタイどおりの議論をしたくないなら出ていけばいいだけ。

俺もx86は団子並みに得意だけど、他の環境は詳しくないからもっと情報欲しいんだ。
ぶったぎらないで建設的な会話をしてくれ。

>>929
>あとiostream周りはミス設計なので無理知らなくてよい。
kwsk

basic_stringをハーブ・サッターがボロクソに叩いてるのは
知ってるけど、それは初めて聞いたな

たとえば
iostreamまわりだけで入出力やろうとするとcstdioよりかえって手間がかかるんだよね。

printfはJavaにも移植されたくらいメジャーな機能。
C++においても誇りを持って使うべき。
boost::formatを使うという手もあるんだけど、
実行ファイルサイズがでかくなるわ、sprintf併用より遅いわで実用は考えない方がいい。

まぁ、PC市場そのものがマイノリティーだからな。

毎度ダンゴさんの後付けっぷりは見ていて清々しいくらいだな。

おお、printfなんてmalloc使うから糞とか言ってたくせにｗｗｗｗｗｗ

だんごは、規模が大きいから携帯やゲームやるけどクソは流さないんだな。
シェアが低い、原子炉の制御やら火力発電所の制御はどうでもいいと。
衛星の管理もどうでも良いと。

だれも威張ってないし、マジョリティぶってんじゃないのよ。
マジョリティな話題しか出来ないなら、マイノリティの話題が出たときには口を噤む位の
脳みそを示してほしいだけ。
こっちは、別に最新の最適化を否定しているわけじゃねーんだからよ。

俺はprintfのパフォーマンスが問題になるようなプログラムは
組んだことがないな。
それよりも、国際化を意識しているとprintfの書式はちょっと不満。
言語によって単語の順番を変えた方が自然になることが多いからね。
まぁ、こういう話はスレ違いになってくるが。

昔のAppleの広告思い出した。
パーソナルコンピュータ市場で1位がCompaq、Appleは2位のシェアを獲得しました。
ってやつ。
3位がIBMですっていう・・・

団子は自分のblogでやれよ
2chにくるな

>>937
Posix拡張使えばいいじゃない。
今時、VC++も_printf_pなどといった関数で同じ順序指定の書式が使える。

DA☆N☆GOさんはスレの活性化のために必要です
というか2chにくるなとか、2chはお前の家かってｗ

お前知らないのかよだんごの家はここしか残ってないし

名無しになるだけでいいんだけど

ダンゴさんのおかげでスレに活気がある。

意図的に話題をすり替えるのは確信犯ですかな

俺が言ってるのは首尾一貫して、その68kだかでしか通用しない【除算の厨テク】の需要がある人がマイノリティってことなんだけどな。
組み込みソフト市場そのもが小さいことに言及したのは、あくまで主論の一環だよ。
もちろん組み込みソフト市場は拡大してるしこれからも増える。

でも、前世紀の厨テクなんて無くてもソフトが組めるしそもそも一生知る必要がない人のほうが多い
そもそも性能の要求があるからもっと近代的なプロセッサを採用すべきじゃね？

もちろんprintfのパフォーマンスなんざ本質的にはどうでもいいものの代表例だし、
除算はもっとどうでもいい。速かれ遅かれそもそも組み込みCPUは遅いものだから大局には影響がない。

＃原子炉(笑)下水道(笑)
＃68kがなければARMを使えばいいじゃない。
＃Atomでもいいよ

自分が調べてない事は、無かった事にする点では首尾一貫してるな。

早く別に世の中になくても構わないものの設計に戻るんだ

組み込みCPUでコードサイズを気にしない最適化(笑)が必要なこと自体が信じがたい。

ARMのthumb命令セットなんてコードサイズ＞実行効率の代表格だし
SuperHなんかももともとの命令セットが小さいよね。

80:20だとか90:10だとかいうけど本当にプログラム全体の性能のボトルネックになってる部分は
コード全体の2割にも満たないという経験則がある。

それこそ頻度の高い処理の最適化だけで十分だね。

>>947
逆に必要のあるものなんてあるの？
原子力がなければ自家発電でいいじゃない。
火打ち石で火でもおこせばいいじゃない。

ソフト産業なんて須く本質的に必要のないものを作ってるんだよ。

そうだな。
医療機器が無ければ死ねばいいじゃない。

>>950
なあに、かえって免疫力がつく

須らく　にすべての意味はありません

ソフト産業は本質的に必要の無いものを作らなくてはならない。
と言っているんだよ、きっと。

聞かれてもないのに１＋１＝２レベルの話を言い出す痛い子一名

>>953
日本語おかしいです

ダンゴさんの連投でスレに火がついたな

人類有史5000年くらい(？)の間、ソフトが必要だった時代はありません。

ソフト産業なんてサービス業ですよ
でも本質的に必要の無いところにこそビジネスチャンスがある

スルーすればごまかせる訳じゃねーよ。団カス

黙れ腐れ団こん（←なぜか変換できない）世代めが

貴様も所詮紙の上にのみ知性を見出す人間だな。道徳にそまった小物。
おさらば

>＃原子炉(笑)下水道(笑)
>＃68kがなければARMを使えばいいじゃない。
>＃Atomでもいいよ

勝手に使ってろよ（ｗ
今現在の現実問題を無視して、突然自分の理想世界でオナニーかよ。
お前はそうゆう世界に引っ越せよ。今は68はまだ現役なんだからよ。

時間がたてば世代交代して、今のプロセッサを組み込みで使うようになるなんざ、
アホでもわかるんだよ。えらそーに垂れんな（ｗ
ただし、その時はARM（笑)やAtom（爆笑)は「最新のプロセッサ」じゃなくなってんだよ（ｗ
68kが最新だった時代があるって脳みそが理解できんのか？

マイノリティに対して「マイノリティだ！厨テクだ！」って一々嬉々として攻撃して
「最新を知ってる自分は、より上位」とかいう態度がアホだって言ってんだよ。
見てて痛いから、話題に関係無い時はすっこんでろ。こっちが恥ずかしいんだよ。

ARMが この先生 きのこれるか は知らないが、最初から組み込み前提の設計だし、
それなりに柔軟性があるから今後も進化していけるんでね？
x86が出てから何十年もたつけど、時代遅れになった時代なんてないな。
AtomでもVIA C7でもいいけど、真面目な話、組み込みも含めてx86オンリーの時代は来つつあるね。
新たに命令セットを起こして市場を征するような時代は前世紀で終わったよ。

まあインフラ向け組み込みも本質的に他のCPUでこと足りる分野であって
そのCPUそのものが必須ではないことがわかってるならそれでいいよ。
68kは進化から取り残され、最新鋭(笑)だった時代の技術者が引退しちゃったらそれまでだろうし
技術者は今やCOBOLerなみに貴重なのは認めるよ

>68kが最新だった時代が
今、現役(稼働中という意味でなく、新たにプログラムが組まれているという意味で)じゃないなら、
今後書くコードでそのテクを使う必要は無い、
って言ってるんじゃないの？団子は。

レス書いてる間に本人来てるとかｗ

だから、必死になっていいわけすんなって（ｗ
おまえが、「不要だ」っていってる話題は、今現在、現実の世界で「必要」って人もいるのよ。
しかも、その分野は、現実世界でそれなりに意味のあることやってんのよ。
それがわからずに「そんなもん不要だ！」とか「マジョリティぶるな！」とか言って、
おもむろに全否定はじめるから、みんなはソレが痛いって言ってんのがわかんねーのか？

68が今後廃れるのはわかってるしPPCやARMがシェア伸ばしてるのが現状なのは
お前よりは現場の人間の方が味わってわかってるのよ。
けど、インフラの世代交代なんていつもの事だし、どーでもいいのよ。

お前の頭の中の未来(笑)がx86で埋め尽くされてようが、こっちしったこっちゃねーの。
他人の話題を否定する前に、自分の知ってる世界とは違う世界があって、そこでは、
お前のも含めて、水流せばクソがちゃんと明後日の方向にすっ飛んでくよう頑張ってる
人たちもいるって考えるようにしとけよ。ただでさえ痛いコテなんだからよ。

>>963
保守の見積もり工数昇華のために都度車輪を再発明しないといけない人なんでしょ。

おまえらプールでもいってこい

ダンゴさんのありがたいお言葉に黙らざるを得ないな

68k自体はいいよもう。
問題は、保守の度に都度除算を書かされ、その最適化をコンパイラにやらせることができない人がどれだけいるかだ。
そもそも最適化なんて本当に必要なの？無駄な作業じゃね？
いい加減意図を読もうよ

まあ68kの質問や議論をここでするような状況だといろんな意味で終わっているがな
団塊退職の穴埋め云々の怖い話は正直聞きたくない

誰か次スレ用意してくれ。

そーか？
Cなんてつかってるの、デカイ範囲じゃもはや組み込みくらいじゃねーの？
そういう意味じゃここでやってもかまわん話題だと思うが。
いまさらな話題だし、度々されても困るけど。スレチとは思えん。
何時までもヒステリックに否定するほどの事でもないだろ。
ダンゴは負けたくないんだろうけど。人格全否定されてるもんな〜。

ColdFireはいまでも新製品が発表されているんだがな。
ま、68kと言っていいかどうかは意見の別れるところだが。

>>972
井の中の蛙大海を知らず。

Web・オープンの世界では確かにLAMPとかRailsが最近人気だがC/C++もまだまだ使われてる。
Windowsではネイティブのほうがまだ多い。
むしろ保守のしようのなくなったレガシーの置き換えにJavaとかC#が使われ始めてるのが現実。

文字通りパフォーマンスが必要な部分についてはC/C++(場合によってはASMも併用)は必要なんだよね。
高級言語でSIMD拡張を直に叩けるのは少ないし。

>井の中の蛙大海を知らず。
ダンゴさんが言うと説得力あるな、具体例として。

C++じゃなくてあえてCをということならわかる

>>973
命令セット同じってだけでx86を語ってるアホもいるんだし、CFも68系でいいんじゃね？
誰かさんに言わせると、「進化からとりこのされた」らしいけど（ｗ

いまさら常識だけど、C/++の最適化はターゲットプロセッサと使ってるコンパイラの
組み合わせを意識しないと駄目って事を忘れて、突然「最新のx86と最新のコンパイ
ラじゃないと駄目」とか言い出してる痛いボケが、このスレじゃはりついてるってわけか。

仕事で使うのに「僕、最新のプロセッサとコンパイラじゃないと嫌です！車輪の最発明は
愚かも者のする事なんです」とか言えねーだろ。普通。みんな与えられた環境で
ベストつくしてるだけだっての。
「組み込みも含めてx86オンリーの時代」とかって、超イタ過ぎ。

>>974
だから、>>>972はCっつってんだろ。
Cなんて最近じゃねーよ。ほとんど＋＋だっての。アホか。
みんな知ってるわかりきったこと偉そーに語んなっていってんだろ（ｗ

組み込みの話なら電気・電子板の方がプロセッサコア別にスレッドがあっていいぞ。

つか組み込みC技術者は人手不足なだけだろ。
僻地における老人介護の需要的な意味で。
別にC/C++使いの需要が組み込みが高いわけではない。
だから孫請け曾孫請け偽装派遣が横行する。

つーかC++は組み込みではまだ少ないだろ。ｼﾝﾋﾞｱﾝ使ってるとこぐらいだな。
当然68Kなどお呼びでないな。

組み込みもLinux乗っけるような用途もあるけどな。
ま、少ないことにかわりはないが。

だれも、Cの組み込み利用が少ないなんて言ってないし、
C++の組み込み利用が多いとも言ってないんだが・・・。
どうしたんだ？

> 別にC/C++使いの需要が組み込みが高いわけではない。

日本語がもう少しまともに使えるようになるまで ROM ってろよ、低脳。

俺がやりたいことやれるなら別にCellでもClearSpeedでも構わんよ。
仕事でコンパイラの機能で不満感じたことはないし、
そもそも性能要求が大きい分野なら、それなりに予算おちる。

むしろ上に規約の改善提案できんようじゃ終わっとるな。
どんだけ人月商売の消耗品だよ。

CR2032で3ヶ月動作するんなら月10Kの注文が入る。
そういう世界では手間の割に効果の高い方法は採用したいのだ。

あ、ダンゴさんへのレスじゃないよ。

悔しいのはわかったから、勝利宣言でもしてさっさと口閉じろって。

やりたいことが出来るならちょっと古いCPUでもかまわんと思うが。
つうか、シチュエーションもわからずに「規約の改善」とかいってるけど、
なんか理由があって規約が出来た可能性もあるしな。
その手の「客の指定でコンパイラ代えれません」とか政治的理由のある
変な規約があるなんてザラだし。
ダンゴって学生？

こと最適化に関しては凡人一人増やすよりコンパイラ替えた方が成果はあがることが多い。
LUTに展開したりとかの手動最適化はスクリプトで迅速かつ確実に。
基本的にこういう分野は人要らないんだよ。
一度作ってしまえば再利用可能。


それを、何度も新たに除算を書き直さないといけないなんて、
人月単価何十万の商売でマージンで稼ぐのが目的の派遣業の常套手段ですね。
わかります。

次スレは
【ダンゴは】C、C++の最適化について語るスレ 3【クソを流さない】
って感じか？

【原子炉無いなら】C、C++の最適化について語るスレ 3【自家発電】

別に、再利用してないとはだれも言ってないんじゃね？
何度も同じコード書くって言い張ってるのもダンゴだけだし。

>>986
なんだ客に提案もできない会社なのか。聞いちゃ悪いけど何次請け？

間接的だが俺の提案で客にPentium Mサーバ入れさせたことがある。
Intelプロセッサだからできたんだけどな。ちょうど産業用マシン出してるメーカーもあったし。
これがAMDだと極端に嫌われる。

【人類有史5000年】C、C++の最適化について語るスレ 3【ソフトは不要だった】
ほんま、ダンゴさんは、名言のオンパレードやで。

発端は >>780- からの、>>788 >>798 あたりか
ダンゴもアレだが、除算の最適化が厨テクってのは同意だな
余程ボトルネックになってる箇所限定なら有りだけどさ

とうとう、相手を「下請け」って事にして上位に立った事にし始めたな。
面白れー。

【ケーキが無いなら】C、C++の最適化について語るスレ 3【パンでも食ってろ】
つまりこういうことですね。

>>993
そもそも組み込みCPU評価ボードがお手軽とかさ

ATOM載ったマザーがいくらで買えるか考えたら、お手頃でもなんでもねーって。
ましてバルクで1000個単位の価格なんざ興味ないし

アセンブリで直記述も厨テクニックですね。わかります。
余裕の無い環境で必要ならやればいいでしょ。
リソースに余裕ある場合は厨テクになるけど。

>>997
極論だねぇ

あくまで、x86なんだ（ｗ
おもしれー奴だよな。

必要なら使うってのは極論なのか？

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。