[過去ログ] GCは失敗。メモリは自分で管理せよ! その2©2ch.net (720レス)
前次1-
抽出解除 必死チェッカー(本家) (べ) 自ID レス栞 あぼーん

このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
リロード規制です。10分ほどで解除するので、他のブラウザへ避難してください。
505: デフォルトの名無しさん [sage] 2016/04/22(金) 08:58:47.78 ID:imh5rD9T(1/2) AAS
>>500
500(1): デフォルトの名無しさん [sage] 2016/04/21(木) 16:14:15.43 ID:lEi5GQja(1/2) AAS
>>497
MMUが付いているから

物理メモリがフラグメンテーションすることは、ある程度これで防げる
しかもハードウェアの機能だから高速だし、勝手にやってくれるから素晴らしい
速度が重要なゲームでは、これは有り難い
ソフト的なアプローチでこれ以上の細工は遅くなるだけで効果が薄い

問題は論理アドレスの方
32bit空間だと例え物理メモリが余っていても
論理アドレスがフラグメンテーションを起こして連続したメモリを確保できなくなる
物理アドレスが枯渇するよりもさきに、そちらの方が問題になることが多い
64bitだと、これが防げる
すばらしい、正解
まぁ>>488
488(1): デフォルトの名無しさん [sage] 2016/04/18(月) 22:12:01.61 ID:3yZKjOEp(3/3) AAS
ゲームプログラムとかならメモリ確保は直接システムコール呼び出して
ページ単位でアロケートするのが定石
必要ならmspaceとかインスタンスベースのヒープを自分で作る
で答え言ってたわけだけど
某ゲーム機ならコンパクションも実装できるよ

>>503
503(1): デフォルトの名無しさん [sage] 2016/04/21(木) 19:18:25.46 ID:zEEe/DNn(1) AAS
論理アドレスが64bitだったらフラグメンテーション対策なんていらんということ?いや自分もそうは思うんだが。
上の方で「専用ゲーム機開発ならフラグメンテーション対策も行うのが常識!」みたいに主張してる人がいて、
それって自作のmalloc相当のアロケータ作るってことだよね?と思ったんだが、
メモリ節約術とごっちゃにしてる人もいてわけが分からなくなってきた。
ページ単位という制限がつくし、速いって言ってもシステムコールなので
ユーザランドで完結するヒープライブラリに比べると遅い
フラグメンテーション対策がいらなくなるわけじゃないよ
511: デフォルトの名無しさん [sage] 2016/04/22(金) 23:54:45.31 ID:imh5rD9T(2/2) AAS
>>510
510(1): デフォルトの名無しさん [sage] 2016/04/22(金) 20:32:21.23 ID:1FeuO5Gj(1) AAS
結局のところ、物理アドレスのフラグメンテーションはMMUが勝手になんとかしてくれるからあまり問題にならない

しかし論理アドレスの方は何にもしてくれないのでフラグメンテーション起こして
連続したアドレスが確保出来なくなると、それで終わり、どうしようもない
32bitプロセスだと4GBしか空間がないから、まれに問題になる
64bitプロセスだと無尽蔵に空間があるから問題になることは現状ありえない
> 結局のところ、物理アドレスのフラグメンテーションはMMUが勝手になんとかしてくれるからあまり問題にならない

MMUってのはアドレス変換するハードウェア
勝手に物理メモリを仮想メモリにマップしたりはしない
それをやるのはOS
前次1-
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル

ぬこの手 ぬこTOP 0.034s