トップページ > プログラム > 2015年06月14日 > VB29lk6s

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

2 位/176 ID中時間01234567891011121314151617181920212223Total
書き込み数10210100000007120000000015



使用した名前一覧書き込んだスレッド一覧
379
デフォルトの名無しさん
423
429
C++相談室 part117 [転載禁止]©2ch.net

書き込みレス一覧

C++相談室 part117 [転載禁止]©2ch.net
382 :379[sage]:2015/06/14(日) 00:38:14.97 ID:VB29lk6s
>381のは漏れジャナイ、
分野によってはmalloc()の使用すら悪設計と看做される
シンプルな造りにすべきときは極限までシンプルに作るべき、だとは思う
C++相談室 part117 [転載禁止]©2ch.net
388 :379[sage]:2015/06/14(日) 02:13:56.77 ID:VB29lk6s
>>386
メモリはあらかじめ大きさを設計した固定長の配列を使うのですよ
全コードにそれを通底させれば(C++流では無いやり方でだが)メモリリークの悪夢からは完全におさらばできるし、
デバッガできわめて追いやすい(万が一現実にクラッシュしたとして、メモリダンプからでも簡単に追える
そんな感じで作るなら、アロケータ以外についてSTLに相乗りするのはコードが不透明になるだけでメリットがあんまり無い

malloc()が悪、とにかく動的メモリ確保全般悪、というのは少なくともニコニコ動画の初期のWebサービスを書いてたプログラマの話としてあった(彼らはC++で書いてた

ようわからんが宇宙機のプログラムなんかも原則動的メモリ確保禁止なんじゃね?
ハードエラーを起こしたメモリ領域を回避するプログラムを後からアップロードしたりした事例があるし…
C++相談室 part117 [転載禁止]©2ch.net
392 :デフォルトの名無しさん[sage]:2015/06/14(日) 02:57:28.00 ID:VB29lk6s
>>391
返す必要は無いしやりくりすらしない。単に上書きするだけ〜
{ 書き込む主体 } × { 書き込み内容 } と{ 書き込み先アドレス(メモリ) }を1対1で紐付けるという発想の転換、
{ 書き込む主体 }すなわちスレッド(タスク)の数が固定ならこれで書ける
極限まで推し進めれば例外としてはキューだけが残るが、キューに入れたが出し忘れるとかはさすがにコードを見ればわかるのでは…
C++相談室 part117 [転載禁止]©2ch.net
396 :デフォルトの名無しさん[sage]:2015/06/14(日) 03:16:15.32 ID:VB29lk6s
>>394
グローバル変数int g_hoge[3][1000];と書くのはプールからの割当なのやろうか…
OSのプロセス起動メカニズムからするとプールからの割当なのかもしれんが、OSは十分デバッグ済み(バグ無し)と看做すなら今の話の筋ではないし、
そもそもOS無しというケースもあるし、(その場合、ブートストラップコードがMAPファイルに従って(つまりガチで固定アドレスの領域であるところの)BSSをゼロクリアする。
C++相談室 part117 [転載禁止]©2ch.net
402 :デフォルトの名無しさん[sage]:2015/06/14(日) 05:04:41.91 ID:VB29lk6s
どこがどうおかしいのか説明できない>401ェ、
まあもう良いか
C++相談室 part117 [転載禁止]©2ch.net
410 :デフォルトの名無しさん[sage]:2015/06/14(日) 13:01:51.04 ID:VB29lk6s
>>407
スレッドごとの記憶をスレッドローカルにすればスレッドごとの競合は考えなくとも良いし、これは配列で実現できる
実は>396にて
 int g_hoge[3][1000];
という2次元配列の例にしたのは、2つめの添え字をスレッド別にする、という想定があったから
(そこまで突っ込んで説明する段階で無かったからその場では説明しなかったが、2つめの添え字をスレッド番号にすれば良い

キューの読み書きは読む側と書く側で当然排他制御する
これはSTLのコンテナを使おうがなんだろうが、マルチスレッド想定では避けられないから漏れの主張とは独立だから漏れのへの批判としては筋違い

やっぱ>407の人のはいまいち発想の転換力が不足しとりますなあ(>392付近の流れあたりから思ってたけどね)…
C++相談室 part117 [転載禁止]©2ch.net
414 :デフォルトの名無しさん[sage]:2015/06/14(日) 13:15:32.85 ID:VB29lk6s
>>411
実現可能性については納得していただいたということでおk
(>410が通じないほどマルチスレッドに疎かったらどうしようかと思った;
>388以降の流れは実現可能性の議論のつもりなので…

>>412
少なくとも現行のx86やx64では特には不要。配列内のスレッドごとのアクセス領域の境界がキャッシュライン境界と一致してようがしまいが安全にスレッドローカルにできる、
(スレッドAのアクセスの巻き添えを食ってスレッドB用の領域がぶち壊れるという心配は無い
C++相談室 part117 [転載禁止]©2ch.net
416 :デフォルトの名無しさん[sage]:2015/06/14(日) 13:18:58.39 ID:VB29lk6s
>>412補足
もっとも、スレッドごとのアクセス領域の境界がキャッシュライン境界と一致させたほうがキャッシュのREFILL回数が減るのでパフォーマンスが上がるから、
両境界は合わせた方がモアベターなのは確か
C++相談室 part117 [転載禁止]©2ch.net
418 :デフォルトの名無しさん[sage]:2015/06/14(日) 13:20:43.30 ID:VB29lk6s
>>415
論点後出しで食い下がりモードですな…
C++相談室 part117 [転載禁止]©2ch.net
423 :デフォルトの名無しさん[sage]:2015/06/14(日) 13:41:04.32 ID:VB29lk6s
>>421
それはひょっとして人格に対する批判であって、内容に対する批判になっていないのでは…

かつ、その批判にしたって成立しないのでは…
1. コストの話を最初に持ち出したのは>>376であって漏れジャナイ
 (その後実行時コスト偏重に話を誘導したのは確かに漏れではあるがこれは話の発展ということで容赦願いたいね…)
2. thread_localでできて配列ではできない例がない限り、>>410に対しては>>414で完全な答えになってると思うが
 使い勝手のことなんて>>410に書いてないし、漏れは>>388以降実現可能性にフォーカスを当てているつもり

>>419
キャッシュのrefillはマルチコアCPUで一般にキャッシュ不整合を起こすのですよ
(するとスレッドAの書き込みでスレッドBの領域が打ち壊れる危険性が生じる
インテルの現行のはハードウェアで全コア安全にrefillしてくれるから安全、というだけ
マルチコアまで話が発展してなかったから脱線だったかもしらんが、内容そのものについては批判される言われはない希ガス
C++相談室 part117 [転載禁止]©2ch.net
425 :423[sage]:2015/06/14(日) 13:45:53.88 ID:VB29lk6s
訂正
誤: >>410
正: >>407
C++相談室 part117 [転載禁止]©2ch.net
427 :423[sage]:2015/06/14(日) 13:47:10.43 ID:VB29lk6s
スマン>>423再訂正orz
誤: >>410
正: >>412
C++相談室 part117 [転載禁止]©2ch.net
430 :429[sage]:2015/06/14(日) 14:01:23.69 ID:VB29lk6s
>>429
>君が言いたいのは元々malloc不要論だろうに
おkその通り

>なぜか飛躍して、配列固定で自分で話進めて
おk、まあこれもそう

>それじゃ何もできないと知って
どこにそんなレスが…?固定配列で実現できる、というスタンスは一貫してるし説明もしたし、

>OS側でスレッド管理、排他処理から始まって
OS側でスレッド管理というのは最初からの想定として良い(漏れ(ら)はそこのメカニズムまで変える話はしていない
排他制御については>>407が言い出したことだが、これも同様で、漏れ(ら)はそこのメカニズムまで変える話はしていない

>ついにスレッドローカル(普通は動的割当)の導入まで来たもんだ
スレッドローカルな記憶を配列で静的割当でやっても可能ということは示したし、(つまりスレッドローカル記憶と、割当メカニズムは独立の話
普通はどうするか、というのは>>388以降の実現可能性の議論とはあんま関係無い感じなのでは…
C++相談室 part117 [転載禁止]©2ch.net
433 :デフォルトの名無しさん[sage]:2015/06/14(日) 15:36:41.52 ID:VB29lk6s
>>432
>君がキュー可能と言い出したんだし
なんか誤解があるようだが、キューというのは単なるFIFO、すまりSTLでいうところのstd::queueであって、
漏れの>>388以降の議論とは独立に(もともと存在する)メカニズム。
FIFOを固定配列でも実現可能なのは自明。ただ>>391の言うとおり、メモリをやりくりする必要性があり、リークし得るというのは当てはまるから、
>>392でリークを起こす危険性に言及し、回答もした

>というかOS側セマフォ使うなんて完全にリソースの動的割り当てだし
最初から言ってるのはアプリ側の動的メモリ確保の排除であってOSの中を変えるとは言ってないし、
>>396で
>OSのプロセス起動メカニズムからするとプールからの割当なのかもしれんが、OSは十分デバッグ済み(バグ無し)と看做すなら今の話の筋ではないし、
という前提を表明しているから、いまさら「OSの内部で動的確保している(かもしれない)から藻前の論理は成立しない」というのは
食って掛かってる以外の何者でも無いって言うか、
話が追えていない人に墓穴の存在を言われてもなあ…
C++相談室 part117 [転載禁止]©2ch.net
434 :デフォルトの名無しさん[sage]:2015/06/14(日) 15:46:46.05 ID:VB29lk6s
>>432
>というかOS側セマフォ使うなんて完全にリソースの動的割り当てだし
>スレッドローカルもこちらからは動的、カーネル側が静的実装かは関係ないよ
>自分で実装したらただのグローバル
これは正直意味わからんkwsk、

>自分で実装したらただのグローバル
これはその通り。だが,、スレッド番号を配列の添え字にするという>>410のやり方で、
スレッドローカルな記憶として機能を果たす(実現可能ではある)ことは>>411には合意いただいたはずだが
つまりグローバルかどうかはあんま論点じゃないっていうか、


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