- 1 名前：デフォルトの名無しさん mailto:sageteoff [2015/11/18(水) 23:24:59.79 ID:BUQ68wTG.net]
- GC、ガベージコレクション、ガベージコレクタ、ガーベジコレクション、ガーベジコレクタは使えない。
以下GCと記す
プログラマをメモリ管理から開放する！
といいつつ、メモリリーク問題の文献が大量にある。
これすなわち、メモリリーク問題が全然解決していないということ。
さらに、メモリ解放のタイミングの文献まで大量に生み出した。
これすなわち、新たなるメモリ管理に関する問題を生み出したということ。
malloc、freeじゃないが
結局のところ、メモリを管理するという技術は、今しばらくは、身につける・教える・学ぶべきではないだろうか？
使って、そのまま放置しても、基本的にはGCがなんとかしてくれている。
ランジョブからジョブ終了までさほどの時間を要さない。メモリも大して使わないならいいだろう。
しかし、規模が大きくなり常駐ジョブやメモリ大量使用のジョブになってくると、そんなメモリ管理の方法でやっていると、
上記「文献」を生み出されてしまう。
入門時は、メモリに無頓着でもいいだろう。それよりも、目的を達成することが先決だ。
しかし、慣れてきたら、やはりメモリの管理まで余裕を持って自分で行うべきだろう。
前スレ
GCは失敗。メモリは自分で管理せよ！
peace.2ch.net/test/read.cgi/tech/1412986420/
- 496 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 21:49:39.41 ID:9yQABY6F.net]
- >>482
GTAみたいなゲーム考えてみ？
あれ全てオブジェクトの寿命を事前に決められると思う？
原理的には不可能じゃないだろうがそんな職人的な作りしてたら開発に10年かかるわw
- 497 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 21:56:15.95 ID:IBBVu28x.net]
- 普通のmallocで足りるならそれでもいいけど。
基本メモリ容量ギリギリまで使うから、最初に描画、ゲーム内部状態、音声、ディスクキャッシュなどでどのくらい使うか決めておく。
終始一貫して静的に決めるのが楽だけど、場合によっては場面ごとに配分を切り替えたりする。
で、例えば広いマップ上を自由に動き回るようなゲームだと、マップを複数のパーツに分割して、詳細モデルから簡易モデルまで用意する。
- 498 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 22:12:01.61 ID:3yZKjOEp.net]
- ゲームプログラムとかならメモリ確保は直接システムコール呼び出して
ページ単位でアロケートするのが定石
必要ならmspaceとかインスタンスベースのヒープを自分で作る
- 499 名前：デフォルトの名無しさん mailto:sage [2016/04/19(火) 01:49:46.30 ID:KVIhh3Hm.net]
- 使用できるメモリのサイズも空きメモリのサイズも最初か
- 500 名前：ら分かってて、ユーザーからの入力も限られてて、
そいつら全部自分で管理できる「恵まれた」環境でしか通用しないアプローチだよなそれ。 [] - [ここ壊れてます]
- 501 名前：デフォルトの名無しさん [2016/04/19(火) 01:58:46.65 ID:fq3yh1do.net]
- レーシングゲームは出てくる車が決まっていてコースも決まっているから。
- 502 名前：デフォルトの名無しさん mailto:sage [2016/04/19(火) 08:28:57.71 ID:YcewE61x.net]
- 昨今はレースゲームでも汎用的なゲームエンジン使うことが多いから
その場合事前に寿命が決まってる前提の作りにはしていないと思うぞ
GDCとかGame Gemとかでも昔からフラグメンテーション対策を含む
メモリ管理の手法はいろいろ議論されているから調べてみるとよろし
- 503 名前：デフォルトの名無しさん mailto:sage [2016/04/20(水) 12:56:58.01 ID:r07pzD8i.net]
- >>489
ハードリアルタイムなシステムならごく普通
って言うかそうでないと作れない
- 504 名前：デフォルトの名無しさん mailto:sage [2016/04/20(水) 13:09:41.53 ID:DLw9rf+F.net]
- >>486
ああいうFPSのオブジェクトは全部管理されてるし
gcなんか使ってないよ
- 505 名前：デフォルトの名無しさん mailto:sage [2016/04/20(水) 19:22:46.02 ID:bj66dBvK.net]
- >>493
フラグメンテーションの話だっての
- 506 名前：デフォルトの名無しさん mailto:sage [2016/04/20(水) 19:58:58.01 ID:CuR1I1mj.net]
- やり手のゲーム系の方たちに、逆らうようなことは・・・・
- 507 名前：デフォルトの名無しさん mailto:sage [2016/04/21(木) 01:20:25.83 ID:jf1w54Av.net]
- >>494
そんなのどうにでもなるでしょ
汎用のmallocなんかとは事情が違う
- 508 名前：デフォルトの名無しさん mailto:sage [2016/04/21(木) 02:16:29.96 ID:G+xv7xqn.net]
- >>496
どうとでもなるって？
へーじゃあ試させてもらうわ
GDC 2016でもこういう講演があった
schedule.gdconf.com/session/building-a-low-fragmentation-memory-system-for-64-bit-games
64bitならなぜフラグメンテーションが軽減できるか説明してもらおうか？
物理メモリが多いからじゃないからな
あればあるだけメモリ使うのがゲームなのでメモリに余裕があるわけじゃない
- 509 名前：デフォルトの名無しさん mailto:sage [2016/04/21(木) 11:32:02.27 ID:EjzxVVPK.net]
- ゲーム機含む組み込み系は結果が不確定な動的メモリー確保なんかしないのが鉄板（しようとする奴は未熟な馬鹿）だったが
PCと合わせて組み込み機器もスペックが潤沢になって富豪的プログラムが一般的になってきたからね
無知ゆえ聞きたいんだが
最近のゲームソフトやら>>497やらってどういうGC使ってるの？
- 510 名前：デフォルトの名無しさん mailto:sage [2016/04/21(木) 13:09:31.92 ID:pog3nPgL.net]
- ゲームだって組込みだって今どき動的メモリー確保しないなんて化石みたいな発想が通るわけないだろ
かといって普通のGCは問題外
賢いメモリアロケーションをするしかないんだよ
>>497は「こんなすごい講演するぞ」って言う宣伝だけだけど中身はどこにあるの？
- 511 名前：デフォルトの名無しさん mailto:sage [2016/04/21(木) 16:14:15.43 ID:lEi5GQja.net]
- >>497
MMUが付いているから
物理メモリがフラグメンテーションすることは、ある程度これで防げる
しかもハードウェアの機能だから高速だし、勝手にやってくれるから素晴らしい
速度が重要なゲームでは、これは有り難い
ソフト的なアプローチでこれ以上の細工は遅くなるだけで効果が薄い
問題は論理アドレスの方
32bit空間だと例え物理メモリが余っていても
論理アドレスがフラグメンテーションを起こして連続したメモリを確保できなくなる
物理アドレスが枯渇するよりもさきに、そちらの方が問題になることが多い
64bitだと、これが防げる
- 512 名前：デフォルトの名無しさん mailto:sage [2016/04/21(木) 16:37:13.61 ID:lEi5GQja.net]
- 各ゲーム機の事情は知らないが
PCで有れば、64bitプロセスは、論理アドレスの空間が256TB(48bit)もある
ゲーム機も似たようなものだろう
256TBもの物理メモリを積んだPCやゲーム機は存在していないし
例え論理アドレスが激しくラグメンテーションを起こしても
256TBもの論理アドレス空間を使い切るという事態は考えなくてよい
つまり、64bitプロセスなら、論理アドレスの心配はしなくてよい
一方で、物理アドレスのフラグメンテーションはMMUに任せておけばよい
これはハードウェアで自動で行われるし、とても高速
その余計にソフトウェア的アプローチで頑張ってみたところで
多少物理メモリのフラグメンテーションは改善されるかもしれないが
徒労というかなんというか、労力に見合わないし
しかも遅くなるのでゲームには向いていないし、やらなくてよい
物理アドレスは自分だけが使っているわけではなく、OSを含めたほかのプロセスも使っているので
自分のプロセスが使っている物理メモリだけフラグメンテーションを解消しようと
コンパクションするのも何か完璧感が無いし
自分のプロセス内だけで考えても、外部ライブラリやXBoxならDirectXが使用している物理メモリの
フラグメンテーションは手が出せないので解消しようがない、やはりやるだけ徒労
自分の管理出来る部分だけ物理メモリのコンパクションをかけても
「これで計算上、必ずあと200MBの物理メモリを使用できる筈」とかといった保証はどこにもない
理由は、外部のライブラリ内での物理メモリの使用状況が分からないし、手が出せないから
とにかく徒労であり、MMUに任せておけばよい
- 513 名前：デフォルトの名無しさん mailto:sage [2016/04/21(木) 17:22:28.74 ID:7dcTEyv0.net]
- ただの物理メモリ不足の話がなんでと思ってしまった
swapはじまったら、fpsなゲームはどうなるんでしょうね
- 514 名前：デフォルトの名無しさん mailto:sage [2016/04/21(木) 19:18:25.46 ID:zEEe/DNn.net]
- 論理アドレスが64bitだったらフラグメンテーション対策なんていらんということ？いや自分もそうは思うんだが。
上の方で「専用ゲーム機開発ならフラグメンテーション対策も行うのが常識！」みたいに主張してる人がいて、
それって自作のmalloc相当のアロケータ作るってことだよね？と思ったんだが、
メモリ節約術とごっちゃにしてる人もいてわけが分からなくなってきた。
- 515 名前：デフォルトの名無しさん mailto:sage [2016/04/21(木) 22:14:27.41 ID:WHT47icf.net]
- なんで馬鹿に限って長文書きたがるんだろうか
- 516 名前：デフォルトの名無しさん mailto:sage [2016/04/22(金) 08:58:47.78 ID:imh5rD9T.net]
- >>500
すばらしい、正解
まぁ>>488で答え言ってたわけだけど
某ゲーム機ならコンパクションも実装できるよ
>>503
ページ単位という制限がつくし、速いって言ってもシステムコールなので
ユーザランドで完結するヒープライブラリに比べると遅い
フラグメンテーション対策がいらなくなるわけじゃないよ
- 517 名前：デフォルトの名無しさん mailto:sage [2016/04/22(金) 11:30:03.69 ID:+Z1ZyILi.net]
- わかってなさそうな方がそれっぽいこと・・・・
- 518 名前：デフォルトの名無しさん mailto:sage [2016/04/22(金) 12:23:02.13 ID:UzNl+aCx.net]
- わかってる方は完結に書いてみればいい
- 519 名前：デフォルトの名無しさん mailto:sage [2016/04/22(金) 15:49:44.48 ID:+Z1ZyILi.net]
- 学校の先生にそう教わったんですね
- 520 名前：デフォルトの名無しさん mailto:sage [2016/04/22(金) 19:23:46.16 ID:cAq2nbH2.net]
- 用途ごとにセグメント分けて使い回すのが無難じゃないの
オブジェクトの数が足りなくなったら透明でいいのよ
- 521 名前：デフォルトの名無しさん mailto:sage [2016/04/22(金) 20:32:21.23 ID:1FeuO5Gj.net]
- 結局のところ、物理アドレスのフラグメンテーションはMMUが勝手になんとかしてくれるからあまり問題にならない
しかし論理アドレスの方は何にもしてくれないのでフラグメンテーション起こして
連続したアドレスが確保出来なくなると、それで終わり、どうしようもない
32bitプロセスだと4GBしか空間がないから、まれに問題になる
64bitプロセスだと無尽蔵に空間があるから問題になることは現状ありえない
- 522 名前：デフォルトの名無しさん mailto:sage [2016/04/22(金) 23:54:45.31 ID:imh5rD9T.net]
- >>510
> 結局のところ、物理アドレスのフラグメンテーションはMMUが勝手になんとかしてくれるからあまり問題にならない
MMUってのはアドレス変換するハードウェア
勝手に物理メモリを仮想メモリにマップしたりはしない
それをやるのはOS
- 523 名前：デフォルトの名無しさん mailto:sage [2016/04/23(土) 00:19:34.35 ID:43LRl8T1.net]
- そもそも、ページサイズより粒度が細かいフラグメンテーションにはMMUはなんの効果もないしな。
- 524 名前：デフォルトの名無しさん [2016/04/23(土) 05:06:22.41 ID:TwuNXQH0.net]
- autorelease()呼んだらコアダンプ糞osがｗｗｗ
- 525 名前：デフォルトの名無しさん mailto:sage [2016/04/23(土) 18:49:46.90 ID:RPK9BpXO.net]
- 小さな粒度のフラグメンテーションは気にする必要ない
4KBならUTF-16で2000文字ぐらいしかない
32biｔビットマップなら32x32ほとのサイズ
- 526 名前：デフォルトの名無しさん mailto:sage [2016/04/23(土) 20:33:25.39 ID:PodTlhvX.net]
- キャッシュヒット率が落ちそう(コナミ)
- 527 名前：デフォルトの名無しさん mailto:sage [2016/04/24(日) 01:18:30.93 ID:9YSuZOIq.net]
- >>512
お前のプログラムはメモリを1ページしか使わんのかｗ？
フラグメンテーションで使用率が低いスカスカのページだらけになるのが問題なんだろうが。
- 528 名前：デフォルトの名無しさん mailto:sage [2016/04/24(日) 01:38:34.87 ID:ai61/62A.net]
- >>516
へーお前はヒープを使わないのか
漢だな
- 529 名前：デフォルトの名無しさん [2016/04/24(日) 08:38:51.73 ID:65va2BTL.net]
- メモリー512バイトでどうやってヒープを使えと。
- 530 名前：デフォルトの名無しさん mailto:sage [2016/04/24(日) 09:31:32.99 ID:HSA/nLEW.net]
- ネイティブコードが必要な場面で中途半端に GC に頼るのが問題なのかもしれないが、もうネイティブコードが必要な戦場は限られた一部だけになってて、主戦場では GC は大前提の技術なんだから必要ないとか言われましてもですわ。
- 531 名前：デフォルトの名無しさん mailto:sage [2016/04/24(日) 10:14:15.47 ID:W23a3TIA.net]
- ページがスカスカになっても大丈夫
1ページ4KBとかだからね、十分小さい
32x32-32bitビットマップより小さい
最近のゲームで使われるような大きなサイズのテクスチャなど
でかいサイズを確保する場合はどうせ新しいページが割り当てられるし
小さなサイズを確保する場合は、スカスカになったページから空いているところを探して割り当てられるので
問題ない
- 532 名前：デフォルトの名無しさん mailto:sage [2016/04/24(日) 10:14:59.78 ID:TFb7efu7.net]
- androidしか知りませんみたいな事言われてもな
- 533 名前：デフォルトの名無しさん mailto:sage [2016/04/24(日) 10:27:10.54 ID:W23a3TIA.net]
- 物理アドレスはページサイズで切り売りされるので
元から連続しているアドレスは必要ではなく
フラグメンテーションは問題にならない
連続したアドレスが必要になるのは論理アドレスのほうであり
32bitプロセスでは4GBしか空間がないから問題になることがある
64bitプロセスであれば現状問題にならない
- 534 名前：デフォルトの名無しさん [2016/04/24(日) 10:37:41.02 ID:65va2BTL.net]
- 実はQtでデーモン作って動かしてるのだが、もう半年以上動き続けてる。
まさかこんなに問題が起きないとは。
案ずるより産むがやすしですぞ皆の衆。
- 535 名前：デフォルトの名無しさん [2016/04/24(日) 10:58:37.83 ID:65va2BTL.net]
- Qtで作ったのは一日ででっち上げる為だったのだが、意外なことに堅牢に動き続けてる。
- 536 名前：デフォルトの名無しさん mailto:sage [2016/04/24(日) 12:08:49.17 ID:HSA/nLEW.net]
- Qt でデーモン?
GUI が必要なデーモン?
- 537 名前：デフォルトの名無しさん [2016/04/24(日) 12:13:06.27 ID:ynYywbEh.net]
- >>525
デーモンは通常フォアグラウンドじゃないのでUIを持ちませんぜ旦那。
- 538 名前：デフォルトの名無しさん mailto:sage [2016/04/24(日) 12:25:33.24 ID:HSA/nLEW.net]
- ならば何に何故どのように Qt を使うのだ？
- 539 名前：デフォルトの名無しさん mailto:sage [2016/04/24(日) 12:45:58.38 ID:TFb7efu7.net]
- >>526
だからQtでデーモン？(クエスチョン)…なんじゃね？
加えてQtってGC関係あるのか？
たしかC++のライブラリーだよね？
- 540 名前：デフォルトの名無しさん [2016/04/24(日) 13:02:46.55 ID:ynYywbEh.net]
- 等と意味不明な供述をしており。
- 541 名前：デフォルトの名無しさん mailto:sage [2016/04/24(日) 14:52:01.10 ID:fu8W/E1c.net]
- >>525
Qt 使ってるからと言って QtGui 使ってるとは限らんけどね
>>528
Qt 本体は C++ で書かれてるけ
ど Java, Ruby, Python, Perl, C# 等からも利用できるよ
- 542 名前：デフォルトの名無しさん mailto:sage [2016/04/24(日) 14:52:56.88 ID:UKiBgwvV.net]
- daemonじゃなくてdemonなんじゃない？
デスクトップマスコット的な
- 543 名前：デフォルトの名無しさん [2016/04/24(日) 14:59:36.53 ID:ynYywbEh.net]
- 俺が作ったのはウェブソケットによってサービスを提供するプログラムだ。
エンジンエックスをリバースプロキシとした。
このプログラムは常時数千の接続から大量のリクエストを受け付ける。
接続してくるクライアントは専用に作られQtで書かれている。
大量のリクエストはそれぞれ複数のデータベース検索を引き起こす。
こう書くと結構負荷が高そうなのだが、さすがC++、ほとんど塵程度の負荷しかなく、
当然のことながらリプライに遅延もない。
そこで案ずるよりも生むが易しというわけ。
Qtは出自からしてGUIのためのライブラリではあるのだが、GUIが無いと使えないというわけでもない。
むしろボリュームからすれば、GUI以外の方がより大きい。
そして、半年動きっぱなしで大丈夫ことからして、実は断片化は気にしなくても
良さそうだ。
- 544 名前：デフォルトの名無しさん [2016/04/24(日) 15:05:02.69 ID:ynYywbEh.net]
- ちなみにQt使ってなかったら一日でサービスを書き上げることは不可能だっただろう。
Qtは、その他のGUIライブラリ同様バグが多いのだが、GUIを抜いてみるとどうだろう、
意外なほどに堅牢なのだ。
何しろもう半年動きっぱなし。
俺はこの経験から一つの予測を立てた。
これからのサービスは、C++で書かれるようになる可能性がある。
何しろ圧倒的に速い。
一つのリクエストに対するレスポンスが速いため、平均負荷率が圧倒的に下がるのだ。
この事実に世の中が気づくにはそう時間がかからないはず。
そしてsystemdがこの動きを促進するはず。
ちなみにWindowsで書いてLinuxで動かしてます。
- 545 名前：デフォルトの名無しさん mailto:sage [2016/04/24(日) 15:05:44.58 ID:ai61/62A.net]
- 一例をもって一般化はできないだろ
- 546 名前：デフォルトの名無しさん mailto:sage [2016/04/24(日) 15:05:53.54 ID:TFb7efu7.net]
- >>530
色々な言語から使えるのか
そういう場合Qtが使うメモリーなんかはどういう扱いなんだろうね
GC適用外な気がするけど知らないからこれでやめとくわ
- 547 名前：デフォルトの名無しさん [2016/04/24(日) 15:08:01.90 ID:ynYywbEh.net]
- Windowsで書いてLinuxで動かすことに、systemdは大いに貢献した。
従来のデーモンの作り方では、いろいろ煩雑なことがありすぎ、時間の制限から難しかっただろう。
Qt+systemd、この直観的な選択は大成功であった。
- 548 名前：デフォルトの名無しさん [2016/04/24(日) 15:11:43.89 ID:ynYywbEh.net]
- Qtのバグの多くは、複数の環境に対応するため、その差異によって引き起こされているという結論を得た。
systemd万歳！
- 549 名前：デフォルトの名無しさん [2016/04/24(日) 15:16:24.95 ID:ynYywbEh.net]
- 更にもう一つヒントがある。
複数のクライアントから多様なリクエストがあるとはいえ、一つのプログラムが擁する
データ構造などたかが知れているのだ。
クライアントAのリクエストにこたえるため使用された記憶空間は、解放されたのち
クライアントBのためにそのまま使われる可能性があるのだ。
そういったわけで断片化は気にする必要が無い。
若者よ、案ずるより産むが易しですぞ。
- 550 名前：デフォルトの名無しさん [2016/04/24(日) 15:28:56.74 ID:u6qUQj/U.net]
- ねえ訳分かんないんだけど
本人以外で理解してる人要るの？
- 551 名前：デフォルトの名無しさん mailto:sage [2016/04/24(日) 15:55:24.75 ID:fu8W/E1c.net]
- むやみに連投してる奴はたいていスルーでok
- 552 名前：デフォルトの名無しさん [2016/04/24(日) 20:02:15.39 ID:ynYywbEh.net]
- むしろ、わからないのに何故、一生懸命主張していたのかと。
- 553 名前：デフォルトの名無しさん mailto:sage [2016/04/24(日) 20:22:44.80 ID:fcfJojCV.net]
- 誰と戦っているんだろう…
- 554 名前：デフォルトの名無しさん mailto:sage [2016/04/24(日) 22:39:17.85 ID:WrdDgWl7.net]
- マークスイープでメモリリークってどうやって起きるんだ？
初心者だから優しく説明してほしい
- 555 名前：デフォルトの名無しさん [2016/04/25(月) 01:16:56.77 ID:/Pmm49fe.net]
- 狭義の意味では起きない
もし君が気付かない間にオブジェクトへの参照を保持していたらどんなGCだろうが解放されない
それをリークというならリークする
- 556 名前：デフォルトの名無しさん mailto:sage [2016/04/25(月) 13:44:57.25 ID:HSarKqaj.net]
- 言い換えればダングリングポインタが発生しない
それだけ
- 557 名前：デフォルトの名無しさん mailto:sage [2016/04/25(月) 14:51:13.10 ID:0xpbBk2N.net]
- マーク＆スイープでもポインタの型情報を記録してないとリークしまくる
無関係な数値をアドレス参照と勘違いしてマーク→未開放
某言語ではこのために巨大なメモリブロックが
- 558 名前：開放されない []
- [ここ壊れてます]
- 559 名前：デフォルトの名無しさん mailto:sage [2016/04/25(月) 20:35:07.72 ID:4DDlKiNG.net]
- >>543
どこからマークを始めるかが問題
- 560 名前：デフォルトの名無しさん mailto:sage [2016/04/29(金) 18:58:56.34 ID:I1ppYkAy.net]
- >>10
C#はGCの掃除処理を任意で呼び出せるだけだろ
C++/CLIなら自分でdelete呼べば即座に消え去るが
もちろんC++と同じくデストラクタも確実に起動する。
- 561 名前：デフォルトの名無しさん mailto:sage [2016/04/29(金) 22:46:31.85 ID:wZxrhoKH.net]
- C++/CLIはデストラクタが呼ばれるだけで、managedメモリの解放がGC任せなのは変わらんよ。
- 562 名前：デフォルトの名無しさん [2016/05/01(日) 07:57:30.30 ID:tKi6j9CT.net]
- 匿名通信（Tor、i2p等）ができるファイル共有ソフトBitComet（ビットコメット）みたいな、
BitTorrentがオープンソースで開発されています
言語は何でも大丈夫だそうなので、P2P書きたい！って人居ませんか？
Covenantの作者（Lyrise）がそういう人と話したいそうなので、よろしければツイートお願いします
https://twitter.com/Lyrise_al
ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーｗ
The Covenant Project
概要
Covenantは、純粋P2Pのファイル共有ソフトです
目的
インターネットにおける権力による抑圧を排除することが最終的な目標です。 そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します
特徴
Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW)
接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です
DHTにはKademlia + コネクションプールを使用します
UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります)
検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません
w
- 563 名前：デフォルトの名無しさん mailto:sage [2016/05/01(日) 09:11:45.10 ID:qHyjCjkk.net]
- 無視リストに追加と
- 564 名前：デフォルトの名無しさん [2016/05/02(月) 21:54:41.51 ID:KYdaomRZ.net]
- GCCは失敗、Clangを使え。
- 565 名前：デフォルトの名無しさん mailto:sage [2016/05/02(月) 22:21:36.97 ID:btgv3pKW.net]
- うるせーバーカ
- 566 名前：デフォルトの名無しさん [2016/05/04(水) 17:42:43.75 ID:M8+arjAJ.net]
- gccは失敗。
- 567 名前：デフォルトの名無しさん [2016/05/27(金) 12:06:01.84 ID:FwT+WNvC.net]
- 良スレ発見した。Windowsは32bitで十分だな。32bitでもPAEで4GB超の
メモリ認識するし、仮想メモリは4GBのままだが、AWEを使うことにより
バンク切り替え的にメモリウインドウを切り替えられる
- 568 名前：デフォルトの名無しさん mailto:sage [2016/05/27(金) 19:30:30.19 ID:hSijlNU2.net]
- >>555
アプリはよくてもカーネルはつらい
- 569 名前：デフォルトの名無しさん [2016/05/28(土) 04:39:26.17 ID:rTGB9SNh.net]
- メモリーは俺が確保してやる、任せろ。
- 570 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 07:51:44.19 ID:Ai+IvVh7.net]
- おう、この手は絶対、絶対に、死んでも離さねぇ！！
- 571 名前：デフォルトの名無しさん mailto:sage [2016/05/29(日) 11:50:15.87 ID:9WWbP5OA.net]
- OSに載った気持ちでいなさい
- 572 名前：デフォルトの名無しさん mailto:sage [2016/05/31(火) 22:56:21.68 ID:mtPUDASJ.net]
- >>1みたいなやつは
研究室にヒキって、社会に出たことないんやろ
おまえ、本気の糞コードで書かれたペチプ〜とか見たらチビるで
あんなんに加えてメモリ管理なんてやらせたら
それこそHELLO END OF THE WORLD
この世の終わりですわ
- 573 名前：デフォルトの名無しさん mailto:sage [2016/06/07(火) 12:20:18.65 ID:4vppD7oq.net]
- >>558
死んだら離せw
- 574 名前：デフォルトの名無しさん mailto:sage [2016/06/12(日) 09:40:01.67 ID:mfUrI2Z0.net]
- 死後硬直ですね
- 575 名前：デフォルトの名無しさん [2016/06/18(土) 23:15:40.44 ID:03AgrRUX.net]
- 指摘してるレスがなかったので言っとくが
循環参照は参照カウント方式＋Cycle Collectorでも回収できるから
GCは必須じゃないぞ
興味があるならBacon Cycle Collectorで調べてみろ
- 576 名前：デフォルトの名無しさん [2016/06/18(土) 23:22:46.70 ID:/B2fY0/K.net]
- 学生の頃は循環参照できないことに困ってたけど、今となっては何時
循環参照が必要になるかさえ思い出せんな。
- 577 名前：デフォルトの名無しさん mailto:sage [2016/06/19(日) 21:38:00.28 ID:evh9vaek.net]
- 双方向リスト構造
- 578 名前：デフォルトの名無しさん mailto:sage [2016/06/19(日) 22:17:16.01 ID:ao4WLgfX.net]
- >>563
＞Cycle Collector
いわゆるmark&sweep式とどう違うの？
- 579 名前：デフォルトの名無しさん [2016/06/20(月) 01:16:50.71 ID:30YoNw6z.net]
- （コンパクションしてくれるんだろうか）
- 580 名前：デフォルトの名無しさん mailto:sage [2016/06/22(水) 08:52:46.04 ID:I9Ep4uZo.net]
- vmが諸悪の根源な気がしてきた
- 581 名前：デフォルトの名無しさん mailto:sage [2016/07/06(水) 07:12:12.60 ID:aYInvTWe.net]
- >>568
まずガベージだらけの頭の中を整理すべき
- 582 名前：デフォルトの名無しさん mailto:sage [2016/07/16(土) 10:10:08.78 ID:+8wH/95N.net]
- >>565
別に
単方向リストでもなるだろＪＫ
ていうかリストの要素をshared_ptrにするのは現代でも有効
リストのリンクヘッダ自体の寿命は要素が明示的にdeleteされるかリスト全体が廃棄されるまでなので
リンクヘッダも管理したければリスト固有のストレージ丸ごとな単位でshared_ptrにしたら良い、
希ガス
- 583 名前：デフォルトの名無しさん mailto:sage [2016/07/16(土) 10:13:41.67 ID:+8wH/95N.net]
- △: リストの要素
○: リストの要素が保持するデータ
つか開放タイミングをshared_ptrに任せておk、などという発想のは管理しているうちに含めれないがな…
- 584 名前：デフォルトの名無しさん mailto:sage [2016/07/16(土) 10:38:52.53 ID:6AR6MH2z.net]
- 一般のグラフじゃなくてリスト構造の話だろ？
双方向リストはheadとtailへの参照があるが、単方向リストで循環参照は生じようがないが。
- 585 名前：デフォルトの名無しさん mailto:sage [2016/07/16(土) 11:51:50.13 ID:+8wH/95N.net]
- >>572
すまんの>>570の単方向リストは正確には循環リストもしくは環状リストと呼んだ方が良いかも試練、
だが、循環リストもしくは環状リストも単方向リストの実装方式の一つではある（初期の『プログラミング言語C++』か何かのslist等
のじゃ…！
- 586 名前：デフォルトの名無しさん mailto:sage [2016/08/22(月) 17:06:41.08 ID:oW9zLe2W.net]
- 循環してるかは後付けでオブジェクトをマークすれば判るんだし
扱うデータ構造から可能性の有無は予測できるし循環自体は大した問題じゃないよ
あ、これリークするなと思ったら対策すればいいだけ
問題は他人様のブラックボックスなライブラリを使う場合
- 587 名前：デフォルトの名無しさん mailto:sage [2016/08/22(月) 19:24:37.36 ID:csr3LedD.net]
- ？
今の議論はプログラマーが何も考えないアホでもGC(言語)使ってれば問題無いのか
そうでなければ結局なんらかの管理が必要でちゃんとする事しないとリークするから本質的には管理から開放されないよねって話だと思うが
- 588 名前：デフォルトの名無しさん mailto:sage [2016/08/22(月) 19:33:58.37 ID:01M+MFvA.net]
- いまどきの子はブラウザアプリしか作れないから
ブラウザ再起動とかページ遷移で解決でしょうな
- 589 名前：デフォルトの名無しさん mailto:sage [2016/08/23(火) 19:56:22.47 ID:cEt4cHHx.net]
- 現在のGCが不完全なだけであって、
メモリは人が管理すべきでないという考え自体は正しいよ。
- 590 名前：デフォルトの名無しさん [2016/08/23(火) 20:17:10.56 ID:xIKUFX4H.net]
- 潤沢なメモリを用意してGCしない戦略
起動時間に限ってGCしなくても問題ない範囲であればGCしない戦略
結局こういうのが勝つ
- 591 名前：デフォルトの名無しさん mailto:sage [2016/08/23(火) 20:29:14.30 ID:uPhg+qti.net]
- プロセスを細かく分けて寿命を短くすればそんなの考えなくて済む
- 592 名前：デフォルトの名無しさん mailto:sage [2016/08/24(水) 13:32:09.69 ID:2RMcAgaj.net]
- 本当の意味での軽量プロセスをOSがサポートしてくれたら良いんだけどね
メモリプールみたいなもんなんだけど、OSのリソースも紐づいてて
メモリプール解放時にOSのリソースもちゃんと解放されるようなもの
マルチプロセスは非常に強力で良いんだけど
メモリ空間が別になるから色々面倒だしパフォーマンスも出にくい
世の中には呼び出したらしばらく処理が返ってこない時間のかかる関数があるけど
とうぜんUIが固まったら困るから別スレッドで実行するわけだけど
処理中にユーザーがキャンセルボタンを押したとき
処理を中断する手段が関数側に用意されてなかったりすると、困る
外からスレッドごと殺しても、リソースリークの問題が出る
真っ先に困るのが同期オブジェクト
同期オブジェクトを握った状態で死なれると、それ以降デッドロックを引き起こす
それ以外にも、プログラムの整合性が壊れているかもしれないので、以降正しく動く保証がない
だから別プロセスで実行して、キャンセルされたときはプロセスごと殺すしか方法が無い
しかし別プロセスにするとメモリ空間が繋がってないので面倒
だからその中間がほしい
- 593 名前：デフォルトの名無しさん [2016/08/24(水) 16:03:33.76 ID:Ku8YOB4B.net]
- erlang最強
- 594 名前：デフォルトの名無しさん [2016/08/24(水) 19:53:51.27 ID:B7v3wZLf.net]
- 軽量プロセスより重量スレッドの方が実現できそう。
- 595 名前：デフォルトの名無しさん mailto:sage [2016/08/24(水) 20:02:24.36 ID:971rg3P3.net]
- いつ無くなってしまうかわからんようなメモリのアクセスが簡単になってもほとんど使いみちないだろ。
安全性重視なら別プロセスにして、必要なデータだけ共有メモリで受け渡してのが妥当なところだろう。
- 596 名前：デフォルトの名無しさん mailto:sage [2016/08/24(水) 20:18:52.71 ID:2RMcAgaj.net]
- 結論から言うと、Windowsにforkが無いのが面倒すぎるってことなんだけどね
|
 |
