トップページ > プログラム > 2015年12月05日 > NRX1k+Is

書き込み順位&時間帯一覧

2 位/210 ID中時間01234567891011121314151617181920212223Total
書き込み数00020000001200232210011320



使用した名前一覧書き込んだスレッド一覧
デフォルトの名無しさん
C言語なら俺に聞け(入門編)Part 131 [転載禁止]©2ch.net
C++相談室 part120 [転載禁止]©2ch.net
GCは失敗。メモリは自分で管理せよ! その2©2ch.net
C++相談室 part121 [無断転載禁止]©2ch.net

書き込みレス一覧

C言語なら俺に聞け(入門編)Part 131 [転載禁止]©2ch.net
153 :デフォルトの名無しさん[sage]:2015/12/05(土) 03:01:58.22 ID:NRX1k+Is
改行コードをどうするかとかプレゼンテーション層かアプリケーション層で任意に取り決め可能なんじゃないの(適当
C++相談室 part120 [転載禁止]©2ch.net
997 :デフォルトの名無しさん[sage]:2015/12/05(土) 03:16:50.47 ID:NRX1k+Is
>>994
レスdクス、
しかし>>993のリンク先の記事が示すことは、
struct Foo { int m_x; } g_foo;
int main() {
 int a = g_foo.m_x; // ・・・(1)
 何がしかの非restrictなポインタ操作(外部リンケージの関数呼び出しは含まない!)
int b = g_foo.m_x; // ・・・(2)
printf("a=%d, b=%d\n", a, b);
}
上の(1)と(2)のような書き方をしたとき、(1)と(2)の両方でメモリアクセスが生じる
(g_foo.m_xのリードアクセスについて、(1)〜(2)を通してのレジスタ割り当ては行われない
ということなのdeath、

これソースコードを極力変えずに速くする(g_foo.m_xをレジスタ割り当てさせっぱなしにする)方法は無いですかいのう…
GCは失敗。メモリは自分で管理せよ! その2©2ch.net
162 :デフォルトの名無しさん[sage]:2015/12/05(土) 10:18:00.14 ID:NRX1k+Is
>>158
ちょっ漏れが作ったわけでも漏れの使い方に問題があるわけでもない階層で起きるメモリリークの責任を漏れに負わされても困る…
それに他人が作ったモジュール内でのメモリリークも結局は開放が書かれていなかったか、書かれていても正しくなかったからリークしているはず…

>>161
全面同意だが同意したからと言ってメモリリークがゼロになるかっていうと以下略
単純にクリティカルセクションとかキューによるシリアライズ(Active Objectパターン)で排他して
マルチコアを活かさずパフォーマンスをドブに捨てて良ければ平和なんだが…
C++相談室 part121 [無断転載禁止]©2ch.net
7 :デフォルトの名無しさん[sage]:2015/12/05(土) 11:13:41.33 ID:NRX1k+Is
>>6
レスdクス、
まあint b = aと同じことなんですが、既存コードの高速化のため、
関数先頭に片っ端からconst int m_x = g_foo.m_x;(Fooのメンバ関数ならconst int m_x = Foo::m_x;)を挿入する「だけ」のソースコード変更で実験中なう

>ポインタ操作があっても一回しか読まれないわけで。
グローバル変数g_xと、別のグローバル変数のメンバg_foo.m_xが同一実体のaliasでありえないことはコンパイラにもひと目でワカルんでしょうけども、
問題はg_xのアドレスが関数引数で渡され、その関数内でg_foo.m_xを直接読むケースが悩ましい…
該当するケースについて、渡されてくるポインタを__restrictにすれば解決なんですが、これは怖くて機械的にはやれない
および参照で渡されたとき、参照の___restrictは比較的新しいコンパイラでないと対応していない…

>型ベースの aliasing rule もあるし。
言わんとすることは多分わかるんですが、
そこまで逝くともはやどこまでコンパイラの気持ちになれば良いのかわからん…
C++相談室 part121 [無断転載禁止]©2ch.net
9 :デフォルトの名無しさん[sage]:2015/12/05(土) 11:44:20.03 ID:NRX1k+Is
>>8
ものすごい深さの多重ループと本質的に同じやつ(ソースコードは既存)の高速化を今せねばならないのデス、
GCは失敗。メモリは自分で管理せよ! その2©2ch.net
171 :デフォルトの名無しさん[sage]:2015/12/05(土) 14:36:53.80 ID:NRX1k+Is
shareed_ptrはC++で比較的効率よくやれることと、GCしたい人が真にやりたいことの妥協の産物であって
どんなシチュでもベストにフィットするような一押しの決定版ってほどでも無い…

参照カウンタの排他が不要で循環参照が無いことも保証できるまで設計が詰められているなら
スレッドごとに、メモリを確保して使って返す処理を直に書くのが一番良い
GCは失敗。メモリは自分で管理せよ! その2©2ch.net
175 :デフォルトの名無しさん[sage]:2015/12/05(土) 14:52:20.59 ID:NRX1k+Is
>>172
>特に例外が絡むとやってられない状況になる
そこだけはstd::unique_ptr<T>の一押し
これで例外状況でのRAIIが完成するので真にGCが要らんところまで逝く

ていうか大概のアプリなら、例外を生じたらFatal errorなことをユーザーに知らせて終了、でいいんじゃ…
C++相談室 part121 [無断転載禁止]©2ch.net
12 :デフォルトの名無しさん[sage]:2015/12/05(土) 15:01:18.43 ID:NRX1k+Is
>>10
C++のconstは1 bitの書き換えも許さないという意味では無いので
const付きオブジェクトであってもコンパイラはalias経由で書き換えられる可能性を想定せざるを得ず、最適化結果は変わらないはず
VC++2010で実験する限り実際変わらないようである

それよかローカル変数化で10倍早くなった;
C++相談室 part121 [無断転載禁止]©2ch.net
16 :デフォルトの名無しさん[sage]:2015/12/05(土) 15:27:17.32 ID:NRX1k+Is
>>13
あー>>12でconstつきオブジェクトと言ったのは適切ではなくて、constつきポインタで指し示されたオブジェクト、と訂正します、

で、毎度おなじみn3337.pdf(タダのやつ)から
>7.1.6.1 The cv-qualifiers
>...
>A pointer or reference to a cv-qualified type need not actually point or refer to a cv-qualified object, but it
>is treated as if it does; a const-qualified access path cannot be used to modify an object even if the object
>referenced is a non-const object and can be modified through some other access path. [ Note: Cv-qualifiers
>are supported by the type system so that they cannot be subverted without casting (5.2.11)
下から2行目の
>can be modified through some other access path.
に注目

const_cast<T*>でconst外しを行った結果に書くことは未定義動作、という規定があり、
それと混同している人が多そうな気がするが、それとは別のwrite access方法であることに注意
C++相談室 part121 [無断転載禁止]©2ch.net
17 :デフォルトの名無しさん[sage]:2015/12/05(土) 15:34:44.74 ID:NRX1k+Is
例としては単純にこれ。
int g_a = 10;
void foo() {
 const int* p = &g_a;
 printf("[1] *p=%d\n", *p); // (1)
 g_a += 11;
 printf("[2] *p=%d\n", *p); // (2)
}
コンパイラは外部シンボルの呼び出しやアクセスで*pがもろともに書き換えられる可能性がある想定で最適化せねばならないから、
(1)と(2)のそれぞれで*pをメモリからロードする。
C++相談室 part121 [無断転載禁止]©2ch.net
22 :デフォルトの名無しさん[sage]:2015/12/05(土) 16:17:49.62 ID:NRX1k+Is
>>20
無い
最適化は別スレッドからの干渉を仮定しない
volatileで最適化を抑止することならできる

>>17でコンパイラが気にしているのは、同一スレッドコンテキスト内で起きる副作用
GCは失敗。メモリは自分で管理せよ! その2©2ch.net
187 :デフォルトの名無しさん[sage]:2015/12/05(土) 16:59:06.52 ID:NRX1k+Is
例外発生はバグ、というプログラミングしかしたことないからよくは知らんが、
try {
 try {
  /*...*/
 } catch (std::badalloc()) {
  /*...*/
} catch (UserException e) {
  /*...*/
}
} catch (...) { // fainally節の代わり
 /*...*/
}
じゃあいかんの?実行時コストは知らん
GCは失敗。メモリは自分で管理せよ! その2©2ch.net
188 :デフォルトの名無しさん[sage]:2015/12/05(土) 17:00:08.66 ID:NRX1k+Is
スマン
誤: } catch (std::badalloc()) {
正: } catch (std::badalloc e) {
C++相談室 part121 [無断転載禁止]©2ch.net
24 :デフォルトの名無しさん[sage]:2015/12/05(土) 17:25:14.88 ID:NRX1k+Is
>>23
>ただし呼び出し側は関数から戻ってきた時に*pが変化していないことを仮定できるので最適化に寄与する
そんな仮定は成立しない
証拠はこれ。
a.cpp
--------
int g_a = 10;
extern void bar();
void foo() {
 const int* p = &g_a;
 printf("[1] *p=%d\n", *p);
bar();
 printf("[2] *p=%d\n", *p);
}
--------

b.cpp
--------
extern int g_a;
void bar() { ++g_a; }
--------
GCは失敗。メモリは自分で管理せよ! その2©2ch.net
191 :デフォルトの名無しさん[sage]:2015/12/05(土) 18:00:14.20 ID:NRX1k+Is
>>189
内側のtry〜catchから再throwするのを忘れたorz
内側のtry〜catchから再throwして外側ので再捕捉したらいいんじゃ…
C++相談室 part121 [無断転載禁止]©2ch.net
29 :デフォルトの名無しさん[sage]:2015/12/05(土) 21:50:32.30 ID:NRX1k+Is
やっぱ最適化の話題はカオスになる運命なんじゃのう…

>>28
これでどうよ?
ttp://ideone.com/fSabJr
C++相談室 part121 [無断転載禁止]©2ch.net
34 :デフォルトの名無しさん[sage]:2015/12/05(土) 22:45:21.68 ID:NRX1k+Is
変な例に反応する>>28に朗報
__restrictの効果が目に見えてワカル例(__restrictの有無で動作が変わる)を書いたわ;
http://ideone.com/iVcFhs

↑のコードの
//#define __restrict
というコメントアウトのままだと__restrictが効いて、s=55になる。(誤ったコードでありながら、1〜10の総和を正しく計算する。)
コメントアウトを外すと、__restrictが無効となり、s=110になる。(書いたとおりに間違う。)

案外難しかったわ;
C++相談室 part121 [無断転載禁止]©2ch.net
36 :デフォルトの名無しさん[sage]:2015/12/05(土) 23:13:10.74 ID:NRX1k+Is
>>35
>だいたい俺は動作が変わるかどうかじゃなくconstの有無で最適化が効くかどうかという話をしてるつもりなんだが
それ系の話題はそっちで勝手に振って進めてホスイ☆

漏れは>>16に書かれているうちの
>can be modified through some other access path.
の実例(constつきポインタで指し示されたオブジェクトがalias経由で書き換えられる例)を述べたまでなわけだが…
C++相談室 part121 [無断転載禁止]©2ch.net
37 :デフォルトの名無しさん[sage]:2015/12/05(土) 23:28:51.67 ID:NRX1k+Is
ただし、>>23の主張
>ただし呼び出し側は関数から戻ってきた時に*pが変化していないことを仮定できる(29)
に対しては、>>24および>>30にて、字面上pを含まないbar()の呼び出し前後で*pが指すオブジェクトが変更される例を挙げたから、
反例を示したことになる。(関数呼び出しの前後で*pが変化していないことは「無条件には」仮定できない)

>barの引数がconstじゃないんだからその動作は当たり前だろ(35)
は、当たり前だという結論が誤りであり、かつ主張(29)に対して後出しジャンケンである

やpっぱカオスやな…
C++相談室 part121 [無断転載禁止]©2ch.net
39 :デフォルトの名無しさん[sage]:2015/12/05(土) 23:45:07.55 ID:NRX1k+Is
>>26
> >>23 が言いたいのは
> > 関数の引数については
> のところじゃね?
そうかもしれないが漏れは例示したコード>>17、>>24、>>29の中でpを関数の引数に使った事実は無いので知らん
>>28が別の話をはじめるのはいいが漏れに苦情を言われるのは困る

>>38
では1チャンやるから>>23で主張したかったことに適切な言葉を補い誤解の余地無く述べよ


※このページは、『2ちゃんねる』の書き込みを基に自動生成したものです。オリジナルはリンク先の2ちゃんねるの書き込みです。
※このサイトでオリジナルの書き込みについては対応できません。
※何か問題のある場合はメールをしてください。対応します。