[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 2ch.scのread.cgiへ]
Update time : 02/26 16:42 / Filesize : 210 KB / Number-of Response : 738
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

GCは失敗。メモリは自分で管理せよ! その2



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に任せておけばよい






[ 続きを読む ] / [ 携帯版 ]

全部読む 前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<210KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef