[過去ﾛｸﾞ]
GCは失敗。メモリは自分で管理せよ！ その2©2ch.net (720ﾚｽ)
GCは失敗。メモリは自分で管理せよ！ その2©2ch.net http://mevius.5ch.net/test/read.cgi/tech/1447856699/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
71: デフォルトの名無しさん [sage] 2015/11/28(土) 15:20:08.61 ID:vL/aYykM >>68 意味はあるじゃん http://mevius.5ch.net/test/read.cgi/tech/1447856699/71
159: デフォルトの名無しさん [] 2015/12/05(土) 08:28:25.61 ID:Pfi54LUx >>158 具体的にいつのどのバージョンのライブラリで起きてるの？ 使い終わったらメモリを開放しろ。使い終わってないなら開放する必要はない。これとスレッドプールとどこに関連性があるの？ http://mevius.5ch.net/test/read.cgi/tech/1447856699/159
218: デフォルトの名無しさん [sage] 2015/12/06(日) 20:58:14.61 ID:wxELMJDc >>217 それはStringの+=の実装次第ではあんまり差が付かないケースなんじゃ… （左辺と右辺が別の実体である（アドレスが違う）ケースでは多分右辺を左辺の末尾に1回コピーするだけという実装が有り得る 真に糞なのは StringBuilder sb; String s = "Hello"; sb.Append("[" + s + "]"); が遅いからStringBuilderは糞、と結論付けるニンゲンであってコードではない、 みたいな？ http://mevius.5ch.net/test/read.cgi/tech/1447856699/218
340: デフォルトの名無しさん [sage] 2015/12/21(月) 06:43:24.61 ID:ejqZ3DMD LG OLED TV - The Ultimate Display http://aurorawave.atspace.tv/?sop:v/JubFjalfNIY!RDJubFjalfNIY http://i1.ytimg.com/vi/JubFjalfNIY/mqdefault.jpg #AuroraWaveTV http://mevius.5ch.net/test/read.cgi/tech/1447856699/340
353: デフォルトの名無しさん [sage] 2015/12/21(月) 16:33:49.61 ID:ejqZ3DMD http://www.dospara.co.jp/ad/stick_mv.html http://www.dospara.co.jp/ad/img/stick_mv/title_main.gif http://mevius.5ch.net/test/read.cgi/tech/1447856699/353
476: デフォルトの名無しさん [sage] 2016/04/18(月) 18:51:08.61 ID:RPQ9NKJO メモリのフラグメンテーションをC/C++でコントロールする方法ってあるの？ mallocの実装頼りじゃなく。 http://mevius.5ch.net/test/read.cgi/tech/1447856699/476
488: デフォルトの名無しさん [sage] 2016/04/18(月) 22:12:01.61 ID:3yZKjOEp ゲームプログラムとかならメモリ確保は直接システムコール呼び出して ページ単位でアロケートするのが定石 必要ならmspaceとかインスタンスベースのヒープを自分で作る http://mevius.5ch.net/test/read.cgi/tech/1447856699/488
501: デフォルトの名無しさん [sage] 2016/04/21(木) 16:37:13.61 ID:lEi5GQja 各ゲーム機の事情は知らないが PCで有れば、64bitプロセスは、論理アドレスの空間が256TB(48bit)もある ゲーム機も似たようなものだろう 256TBもの物理メモリを積んだPCやゲーム機は存在していないし 例え論理アドレスが激しくラグメンテーションを起こしても 256TBもの論理アドレス空間を使い切るという事態は考えなくてよい つまり、64bitプロセスなら、論理アドレスの心配はしなくてよい 一方で、物理アドレスのフラグメンテーションはMMUに任せておけばよい これはハードウェアで自動で行われるし、とても高速 その余計にソフトウェア的アプローチで頑張ってみたところで 多少物理メモリのフラグメンテーションは改善されるかもしれないが 徒労というかなんというか、労力に見合わないし しかも遅くなるのでゲームには向いていないし、やらなくてよい 物理アドレスは自分だけが使っているわけではなく、OSを含めたほかのプロセスも使っているので 自分のプロセスが使っている物理メモリだけフラグメンテーションを解消しようと コンパクションするのも何か完璧感が無いし 自分のプロセス内だけで考えても、外部ライブラリやXBoxならDirectXが使用している物理メモリの フラグメンテーションは手が出せないので解消しようがない、やはりやるだけ徒労 自分の管理出来る部分だけ物理メモリのコンパクションをかけても 「これで計算上、必ずあと200MBの物理メモリを使用できる筈」とかといった保証はどこにもない 理由は、外部のライブラリ内での物理メモリの使用状況が分からないし、手が出せないから とにかく徒労であり、MMUに任せておけばよい http://mevius.5ch.net/test/read.cgi/tech/1447856699/501
698: デフォルトの名無しさん [] 2018/07/05(木) 00:30:07.61 ID:RfoszcD2 IZ6 http://mevius.5ch.net/test/read.cgi/tech/1447856699/698
705: デフォルトの名無しさん [sage] 2020/02/13(木) 15:29:41.61 ID:z5cRWLgY GCがある言語でも、shallow copy と deep copy のどちらにすべきかの判断が難しくて、結局、間違えてバグの原因になる可能性がかなり残る。 また、C/C++ポインタのミスを危険視する人がいるが、多くの場合はプログラム開発時にテストをすれば間違いが発見できる。 C/C++でのバッファオーバーランを気にする人がいるが、逆にGCがある言語でも、間違って1つ右隣の要素にしてしまったり、処理する個数を1つ間違ったりするミスは有り得て、その場合、厳密な意味でのバッファオーバーランは無くても処理内容自体はバグる。 http://mevius.5ch.net/test/read.cgi/tech/1447856699/705
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.041s