GCは失敗。メモリは自分で管理せよ！その2©2ch.net

**デフォルトの名無しさん転載ダメ©2ch.net** · 2015/11/18(水) 23:24:59.79

GC、ガベージコレクション、ガベージコレクタ、ガーベジコレクション、ガーベジコレクタは使えない。
以下GCと記す

プログラマをメモリ管理から開放する！
といいつつ、メモリリーク問題の文献が大量にある。
これすなわち、メモリリーク問題が全然解決していないということ。
さらに、メモリ解放のタイミングの文献まで大量に生み出した。
これすなわち、新たなるメモリ管理に関する問題を生み出したということ。

malloc、freeじゃないが
結局のところ、メモリを管理するという技術は、今しばらくは、身につける・教える・学ぶべきではないだろうか？
使って、そのまま放置しても、基本的にはGCがなんとかしてくれている。
ランジョブからジョブ終了までさほどの時間を要さない。メモリも大して使わないならいいだろう。
しかし、規模が大きくなり常駐ジョブやメモリ大量使用のジョブになってくると、そんなメモリ管理の方法でやっていると、
上記「文献」を生み出されてしまう。

入門時は、メモリに無頓着でもいいだろう。それよりも、目的を達成することが先決だ。
しかし、慣れてきたら、やはりメモリの管理まで余裕を持って自分で行うべきだろう。

前スレ
GCは失敗。メモリは自分で管理せよ！
http://peace.2ch.net/test/read.cgi/tech/1412986420/

**デフォルトの名無しさん** · 2016/03/27(日) 20:35:08.73

RAII信者の痛さは異常
オブジェクトをコピーされたら破綻するのに

**デフォルトの名無しさん** · 2016/03/27(日) 21:10:56.38

グローバルインスタンスホルダーは明確にインスタンスの状態を把握したいときに積極的に使うべき

**デフォルトの名無しさん** · 2016/03/27(日) 22:32:53.86

>「いつか」全員が所有権を手放したら「即座に」破棄される
>「いつか」全員が所有権を手放したら「いつか」GCで破棄される
>どう違うというのか。

少なくとも最善が尽くされるという意味で違うし
同じデータと同じプログラムで有れば、常に同じタイミングで開放処理が走るという再現性が有る

それから、自分しか所有権を持っていない場合、つまり参照数が常に1というシンプルな状況ですら
参照カウンタ方式の方が開放処理が自動化されて楽

参照カウンタ方式で有れば、スマポを使っておけば済む
scoped_ptrでも良い

マークスイープ系GCであれば、自身しか所有権を持たない単純な場合でも
非常に面倒なことになる
自身にDisposeを実装して自身のメンバのDisposeを呼び出すコードを手動で書かなければならない
何故こういったコードをコンパイラが自動生成できず、手動で書かなければならないのかの根底に
まさにマークスイープGCの存在が有る
マークスイープ系GCは何処からも参照されなくなったことがその場ですぐに分からない
GCを発動してみるまで保証することが出来ない

自分のDisposeが呼び出された、まさにその瞬間に、自分のメンバに対してもDisposeしてよいのかどうなのか
参照数がリアルタイムで即座に分からないので判断する材料が何も無く
コンパイラはC++のデストラクタのように自動で芋づる式に開放処理を呼び出すコードを生成することが出来ない

要するにマークスイープ系GCではDisposeのコンパイラによる自動生成が出来ないという大きなマイナスが有る

**デフォルトの名無しさん** · 2016/03/27(日) 22:36:05.37

>>438
しねーよ

**デフォルトの名無しさん** · 2016/03/27(日) 22:41:25.16

>>440
子要素をDisposeしていいかどうかもわからないってそりゃ設計サボってる以外のなんでもないだろう
ちゃんと設計してればいつ削除してよいかなんてわかるはずだろ
まともに設計もできないレガシーエンジニアは黙っててよ
設計に時間使わないとリソース云々以前に別のバグだらけになるぞ

**デフォルトの名無しさん** · 2016/03/27(日) 23:42:37.04

RAII信者は頭が悪いな

**デフォルトの名無しさん** · 2016/03/27(日) 23:59:39.99

>>443
自分の頭を検証しな

**デフォルトの名無しさん** · 2016/03/28(月) 00:10:58.97

メンバにDispose持たせる設計って大抵ダメだよね

**デフォルトの名無しさん** · 2016/03/28(月) 00:20:40.85

>>440
前者(参照カウントGC)はRAIIができるが後者(マーク&スイープGC)ではできないというお前の
主張について言っているんだが？
「最善が尽くされる」からRAIIができて、尽くされないからRAIIができないとでも言うのだろうかｗ

>要するにマークスイープ系GCではDisposeのコンパイラによる自動生成が出来ないという大きなマイナスが有る

何度も例に挙げているC++/CLIでは、デストラクタを記述するとコンパイラによってDisposeが追加される。
そして、ローカルスコープに置いたオブジェクトに対してはスコープを抜ける際に自動的にdeleteが呼ばれる。
そこからdelete→Dispose→デストラクタと呼び出される。RAIIに必要なものは揃っているし、事実、可能だ。
もちろん、そのメモリ領域は別のタイミングでGCによって回収される。

ここまで説明しても理解できない低脳ならしょうがない。
やはりデストラクタとファイナライザの違いが理解できてないようだからそこから勉強しなおせ。

**デフォルトの名無しさん** · 2016/03/28(月) 00:39:52.48

{
std::shared_ptr<my_namespace::my_class> p(new my_namespace::my_class(...));
/* unko_code */
}

using(var obj = new MyClass(...)) {
/* GoodCode */
}

美しいという事はいい事だね
C#は書いてある事がシンタックス的にもセマンティック的にも明確だ
リソース管理はこうでなければならない

**デフォルトの名無しさん** · 2016/03/28(月) 01:22:52.25

>>447
C++にもusing使えやw いらない波括弧外せやw

**デフォルトの名無しさん** · 2016/03/28(月) 03:34:15.37

>>447
usingの方が全然明確だね
objがコピーされてても問題ない
RAII脳ではわからないんだろう

**デフォルトの名無しさん** · 2016/03/28(月) 03:36:11.96

schemeに何十年も前から存在するwith-xxxx 系を一般化した構文だね

**デフォルトの名無しさん** · 2016/03/29(火) 01:23:53.57

アレを更にtypedefされたりされると
ワケワカランくなるよな

**デフォルトの名無しさん** · 2016/03/29(火) 01:50:13.51

c++なら普通こうだな
{
my_class obj(...);
...
}
そういやc#でp.release()相当の事って簡単にできるの？
{
auto p(make_unique<my_class>(...));
...
}
nullって代入可能？

**デフォルトの名無しさん** · 2016/04/04(月) 02:47:24.69

GCがあるのになぜJavaはメモリリークしまくるソフトウェアを量産するのか

**デフォルトの名無しさん** · 2016/04/04(月) 02:55:18.29

>>453
Javaだから

**デフォルトの名無しさん** · 2016/04/12(火) 23:15:42.48

Rust使えばいいのさ

**デフォルトの名無しさん** · 2016/04/13(水) 10:33:47.16

>>455
会社にいるよな、そういうやつ

**デフォルトの名無しさん** · 2016/04/13(水) 15:29:31.16

GC大好きっ子に聞きたいんだが
完璧な（理想的な）GCを搭載したメジャーな言語処理系って何があるの？
これで開発すればリークも管理も気にしないでOKってやつ

**デフォルトの名無しさん** · 2016/04/13(水) 16:22:35.14

無い

マークスイープ系GC　→　循環参照OK、しかし即座に開放されない
参照カウンタGC　→　即座に開放される、しかし循環参照NG

ということで、理想のGCは無い
全てのGCは何かを妥協している

それから、たとえGCを使ったとしても
要らなくなったオブジェクトの参照をいつまでも握っている奴が居たら解放されないから
リソースの管理をしなくてよいということは無い

あと、GCは基本的にメインメモリに対してしか有効に機能しないから
例えばファイルオブジェクトなんかは要らなくなったら即座にcloseするなりすべきで
リソース管理フリーというわけにはいかない

**デフォルトの名無しさん** · 2016/04/13(水) 16:54:16.68

つまりは、GCを使っていたとしても
君がオブジェクトを何処かに登録したなら
オブジェクトが要らなくなったら登録解除してあげないと
そのオブジェクトは解放されないのだ
これはちょうどmallocしたらfreeしましょうに似ていて
GCを使ったとしても全てのリソースの管理が自動になるわけではないということだね

究極的にはGCの利点は自分でfree/deleteをしなくても良いところにある
これはつまり、ダングリングポインタが発生しないということだ

**デフォルトの名無しさん** · 2016/04/14(木) 20:54:37.84

>>457
C+BoehmGC

**デフォルトの名無しさん** · 2016/04/17(日) 16:17:55.58

そして無視されてしまうコピーGC君
GCの利点は自分で大量にメモリの確保＆解放するプログラムにおいてバグが出にくくスループットも出るってところだと思う
もしheapをそんなに頻繁に確保＆解放しないんだったらGCない言語の方がいい
ただ近代的な言語は少数の例外を除いて大抵GC積んでるけど

**デフォルトの名無しさん** · 2016/04/17(日) 16:21:44.96

＞リソース管理フリーというわけにはいかない
リソース管理フリーについてはrustみたいなGCない言語のほうが達成できてるよね（あとは関数型言語か）
でもrustでもリソースの解放時にエラーを吐く可能性がある処理なら自分で解放する処理書かなきゃいけないっぽいけど

**デフォルトの名無しさん** · 2016/04/17(日) 18:35:17.89

RAIIでも結局どのタイミングで解放されるか意識しなくてもいいってわけじゃないし
リソース解放処理を書かなくていいだけで

**デフォルトの名無しさん** · 2016/04/17(日) 18:43:59.82

メモリ管理系のバグが顕在化しにくいだけで、そこら辺適当なまま中途半端にキャリアを積む開発者を量産するという害悪が大きい。
JNIやらで他のAPI使う必要が出てくると結局いろいろ配慮しなきゃいけなくなるし。

**デフォルトの名無しさん** · 2016/04/17(日) 19:43:44.44

>>460
コンサバじゃ完璧にほど遠いぞな

**デフォルトの名無しさん** · 2016/04/17(日) 19:50:47.36

>メモリ管理系のバグが顕在化しにくいだけ
結局これだよね
本当に丸投げできるなら乗っかるのもいいと思う
性能問題はハードの進化で一部の用途を除けば問題無くなると思うし
でも現実は中途半端だから意識して書いたほうがマシだと

**デフォルトの名無しさん** · 2016/04/17(日) 21:19:09.59

ムーブセマンティクスのおかげでずいぶん便利に。

**デフォルトの名無しさん** · 2016/04/17(日) 23:09:38.99

あと正確にはGCには含まれないけどメモリコンパクションをやってくれる処理系が多いのも
GCを使う利点になるかも

**デフォルトの名無しさん** · 2016/04/17(日) 23:17:23.70

今どき意図的にやらない限りメモリフラグメンテーションで困るような場面があるか？
アドレス空間も余裕出てきたし、多少おかしな確保パターンで浪費してもGCほど実メモリを食わないし。
今どき主流のサイズ毎に空きを管理するmallocは優秀だしね。
これがダメならlinuxカーネルとか先に落ちちゃうぞ。

**デフォルトの名無しさん** · 2016/04/18(月) 15:56:44.18

>>469
昔、C/C++を駆使して日本が誇るスパコン京に投入するタスクセットを書き上げたのだが
実行するとどうも性能が出ない。
色々調べた結果、どうやらメモリーが断片化していることが分かった。
そこで多大な投資を行いJavaで書き直したらなんと100倍も性能が上がったのです！
これが>>468さんの経験してきたことなんです。

**デフォルトの名無しさん** · 2016/04/18(月) 16:30:17.23

自前のメモリ管理が超下手くそなだけやろ
修業して出直してこいや

**デフォルトの名無しさん** · 2016/04/18(月) 16:37:09.21

自慢になってないような

**デフォルトの名無しさん** · 2016/04/18(月) 16:44:52.62

ゲームだとフラグメント問題になること多いよ
ゲーム専用機なら特に
最近は特にオープンワールドが当たり前になってるけど
あれストリーミングでどんどんメモリ置き換えていくしね

**デフォルトの名無しさん** · 2016/04/18(月) 16:47:31.98

jemallocのようなモダンなmalloc実装使えば良かったのでは。

**デフォルトの名無しさん** · 2016/04/18(月) 17:47:00.91

ゲーム専用機でフラグメンテーションおこすとか開発者としての適性を疑われても不思議ではない。
オブジェクトの寿命管理すらしないのか？

**デフォルトの名無しさん** · 2016/04/18(月) 18:51:08.61

メモリのフラグメンテーションをC/C++でコントロールする方法ってあるの？
mallocの実装頼りじゃなく。

**デフォルトの名無しさん** · 2016/04/18(月) 19:05:27.63

mallocの挙動がわかってれば、ある程度は・・・・

**デフォルトの名無しさん** · 2016/04/18(月) 19:14:30.71

細かくメモリ要求するから、下回りで時間がかかる
メモリ分断されてもオンメモリでの検索はさほど時間がかからない
（空きができても、そこに入らないときに）

**デフォルトの名無しさん** · 2016/04/18(月) 19:15:14.97

>>475
フラグメンテーションって何かわかってないでしょ？
寿命管理だけでは解決できないよ

**デフォルトの名無しさん** · 2016/04/18(月) 19:21:39.69

寿命管理で解決できないとか、フラグメンテーションがどういう現象か分かっているの？

汎用の寿命管理APIみたいなのを使うとか言うのと勘違いでもしている？

**デフォルトの名無しさん** · 2016/04/18(月) 20:02:22.75

>>480
おいおい・・
この場合寿命を管理できないってのはgiven conditionとして考えないと
そりゃ寿命があらかじめわかってるなら苦労しないっての
大規模なプログラムでそんな恵まれた状況は例外的だよ

**デフォルトの名無しさん** · 2016/04/18(月) 20:57:42.92

専用ゲーム機上のゲームだよ。
リソースが逼迫したら何を優先するかの戦略も含めてほぼ理想的なgiven conditionだろうに。
ユーザーの行動による不確定性も全てコントロール下にあるだろうに。

**デフォルトの名無しさん** · 2016/04/18(月) 21:13:59.16

>>482 専用ゲーム機と普通のPCの1アプリケーションとで何が違うのか。mallocも使わないってこと？
NoGC, 各GCでメモリ空間がどう使われるかを視覚化
ttps://spin.atomicobject.com/2014/09/03/visualizing-garbage-collection-algorithms/
黒: 未使用
灰: 確保
緑: 読み込み
黄: 書き込み
赤: GC用のアクセス(参照カウンタ、マーク用ビットetc)
緑と黄は時間経過で退色していく

メモリフラグメンテーションという観点から見ると、コピー型GCが綺麗。

**デフォルトの名無しさん** · 2016/04/18(月) 21:15:59.31

まぁテトリスとかならその程度の理解でいいんじゃない？w

**デフォルトの名無しさん** · 2016/04/18(月) 21:33:24.92

Javaの寿命管理APIは最強ですな。

**デフォルトの名無しさん** · 2016/04/18(月) 21:49:39.41

>>482
GTAみたいなゲーム考えてみ？
あれ全てオブジェクトの寿命を事前に決められると思う？
原理的には不可能じゃないだろうがそんな職人的な作りしてたら開発に10年かかるわw

**デフォルトの名無しさん** · 2016/04/18(月) 21:56:15.95

普通のmallocで足りるならそれでもいいけど。
基本メモリ容量ギリギリまで使うから、最初に描画、ゲーム内部状態、音声、ディスクキャッシュなどでどのくらい使うか決めておく。
終始一貫して静的に決めるのが楽だけど、場合によっては場面ごとに配分を切り替えたりする。
で、例えば広いマップ上を自由に動き回るようなゲームだと、マップを複数のパーツに分割して、詳細モデルから簡易モデルまで用意する。

**デフォルトの名無しさん** · 2016/04/18(月) 22:12:01.61

ゲームプログラムとかならメモリ確保は直接システムコール呼び出して
ページ単位でアロケートするのが定石
必要ならmspaceとかインスタンスベースのヒープを自分で作る

**デフォルトの名無しさん** · 2016/04/19(火) 01:49:46.30

使用できるメモリのサイズも空きメモリのサイズも最初から分かってて、ユーザーからの入力も限られてて、
そいつら全部自分で管理できる「恵まれた」環境でしか通用しないアプローチだよなそれ。

**デフォルトの名無しさん** · 2016/04/19(火) 01:58:46.65

レーシングゲームは出てくる車が決まっていてコースも決まっているから。

**デフォルトの名無しさん** · 2016/04/19(火) 08:28:57.71

昨今はレースゲームでも汎用的なゲームエンジン使うことが多いから
その場合事前に寿命が決まってる前提の作りにはしていないと思うぞ
GDCとかGame Gemとかでも昔からフラグメンテーション対策を含む
メモリ管理の手法はいろいろ議論されているから調べてみるとよろし

**デフォルトの名無しさん** · 2016/04/20(水) 12:56:58.01

>>489
ハードリアルタイムなシステムならごく普通
って言うかそうでないと作れない

**デフォルトの名無しさん** · 2016/04/20(水) 13:09:41.53

>>486
ああいうFPSのオブジェクトは全部管理されてるし
gcなんか使ってないよ

**デフォルトの名無しさん** · 2016/04/20(水) 19:22:46.02

>>493
フラグメンテーションの話だっての

**デフォルトの名無しさん** · 2016/04/20(水) 19:58:58.01

やり手のゲーム系の方たちに、逆らうようなことは・・・・

**デフォルトの名無しさん** · 2016/04/21(木) 01:20:25.83

>>494
そんなのどうにでもなるでしょ
汎用のmallocなんかとは事情が違う

**デフォルトの名無しさん** · 2016/04/21(木) 02:16:29.96

>>496
どうとでもなるって？
へーじゃあ試させてもらうわ
GDC 2016でもこういう講演があった
http://schedule.gdconf.com/session/building-a-low-fragmentation-memory-system-for-64-bit-games
64bitならなぜフラグメンテーションが軽減できるか説明してもらおうか？
物理メモリが多いからじゃないからな
あればあるだけメモリ使うのがゲームなのでメモリに余裕があるわけじゃない

**デフォルトの名無しさん** · 2016/04/21(木) 11:32:02.27

ゲーム機含む組み込み系は結果が不確定な動的メモリー確保なんかしないのが鉄板（しようとする奴は未熟な馬鹿）だったが
PCと合わせて組み込み機器もスペックが潤沢になって富豪的プログラムが一般的になってきたからね

無知ゆえ聞きたいんだが
最近のゲームソフトやら>>497やらってどういうGC使ってるの？

**デフォルトの名無しさん** · 2016/04/21(木) 13:09:31.92

ゲームだって組込みだって今どき動的メモリー確保しないなんて化石みたいな発想が通るわけないだろ
かといって普通のGCは問題外
賢いメモリアロケーションをするしかないんだよ
>>497は「こんなすごい講演するぞ」って言う宣伝だけだけど中身はどこにあるの？

**デフォルトの名無しさん** · 2016/04/21(木) 16:14:15.43

>>497
MMUが付いているから

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

問題は論理アドレスの方
32bit空間だと例え物理メモリが余っていても
論理アドレスがフラグメンテーションを起こして連続したメモリを確保できなくなる
物理アドレスが枯渇するよりもさきに、そちらの方が問題になることが多い
64bitだと、これが防げる

**デフォルトの名無しさん** · 2016/04/21(木) 16:37:13.61

各ゲーム機の事情は知らないが
PCで有れば、64bitプロセスは、論理アドレスの空間が256TB(48bit)もある
ゲーム機も似たようなものだろう
256TBもの物理メモリを積んだPCやゲーム機は存在していないし
例え論理アドレスが激しくラグメンテーションを起こしても
256TBもの論理アドレス空間を使い切るという事態は考えなくてよい
つまり、64bitプロセスなら、論理アドレスの心配はしなくてよい

一方で、物理アドレスのフラグメンテーションはMMUに任せておけばよい
これはハードウェアで自動で行われるし、とても高速
その余計にソフトウェア的アプローチで頑張ってみたところで
多少物理メモリのフラグメンテーションは改善されるかもしれないが
徒労というかなんというか、労力に見合わないし
しかも遅くなるのでゲームには向いていないし、やらなくてよい
物理アドレスは自分だけが使っているわけではなく、OSを含めたほかのプロセスも使っているので
自分のプロセスが使っている物理メモリだけフラグメンテーションを解消しようと
コンパクションするのも何か完璧感が無いし
自分のプロセス内だけで考えても、外部ライブラリやXBoxならDirectXが使用している物理メモリの
フラグメンテーションは手が出せないので解消しようがない、やはりやるだけ徒労
自分の管理出来る部分だけ物理メモリのコンパクションをかけても
「これで計算上、必ずあと200MBの物理メモリを使用できる筈」とかといった保証はどこにもない
理由は、外部のライブラリ内での物理メモリの使用状況が分からないし、手が出せないから
とにかく徒労であり、MMUに任せておけばよい

**デフォルトの名無しさん** · 2016/04/21(木) 17:22:28.74

ただの物理メモリ不足の話がなんでと思ってしまった
swapはじまったら、fpsなゲームはどうなるんでしょうね

**デフォルトの名無しさん** · 2016/04/21(木) 19:18:25.46

論理アドレスが64bitだったらフラグメンテーション対策なんていらんということ？いや自分もそうは思うんだが。
上の方で「専用ゲーム機開発ならフラグメンテーション対策も行うのが常識！」みたいに主張してる人がいて、
それって自作のmalloc相当のアロケータ作るってことだよね？と思ったんだが、
メモリ節約術とごっちゃにしてる人もいてわけが分からなくなってきた。

**デフォルトの名無しさん** · 2016/04/21(木) 22:14:27.41

なんで馬鹿に限って長文書きたがるんだろうか

**デフォルトの名無しさん** · 2016/04/22(金) 08:58:47.78

>>500
すばらしい、正解
まぁ>>488で答え言ってたわけだけど
某ゲーム機ならコンパクションも実装できるよ

>>503
ページ単位という制限がつくし、速いって言ってもシステムコールなので
ユーザランドで完結するヒープライブラリに比べると遅い
フラグメンテーション対策がいらなくなるわけじゃないよ

**デフォルトの名無しさん** · 2016/04/22(金) 11:30:03.69

わかってなさそうな方がそれっぽいこと・・・・

**デフォルトの名無しさん** · 2016/04/22(金) 12:23:02.13

わかってる方は完結に書いてみればいい

**デフォルトの名無しさん** · 2016/04/22(金) 15:49:44.48

学校の先生にそう教わったんですね

**デフォルトの名無しさん** · 2016/04/22(金) 19:23:46.16

用途ごとにセグメント分けて使い回すのが無難じゃないの
オブジェクトの数が足りなくなったら透明でいいのよ

**デフォルトの名無しさん** · 2016/04/22(金) 20:32:21.23

結局のところ、物理アドレスのフラグメンテーションはMMUが勝手になんとかしてくれるからあまり問題にならない

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

**デフォルトの名無しさん** · 2016/04/22(金) 23:54:45.31

>>510
> 結局のところ、物理アドレスのフラグメンテーションはMMUが勝手になんとかしてくれるからあまり問題にならない

MMUってのはアドレス変換するハードウェア
勝手に物理メモリを仮想メモリにマップしたりはしない
それをやるのはOS

**デフォルトの名無しさん** · 2016/04/23(土) 00:19:34.35

そもそも、ページサイズより粒度が細かいフラグメンテーションにはMMUはなんの効果もないしな。

**デフォルトの名無しさん** · 2016/04/23(土) 05:06:22.41

autorelease()呼んだらコアダンプ糞osがｗｗｗ

**デフォルトの名無しさん** · 2016/04/23(土) 18:49:46.90

小さな粒度のフラグメンテーションは気にする必要ない
4KBならUTF-16で2000文字ぐらいしかない
32biｔビットマップなら32x32ほとのサイズ

**デフォルトの名無しさん** · 2016/04/23(土) 20:33:25.39

キャッシュヒット率が落ちそう(コナミ)

**デフォルトの名無しさん** · 2016/04/24(日) 01:18:30.93

>>512
お前のプログラムはメモリを1ページしか使わんのかｗ？
フラグメンテーションで使用率が低いスカスカのページだらけになるのが問題なんだろうが。

**デフォルトの名無しさん** · 2016/04/24(日) 01:38:34.87

>>516
へーお前はヒープを使わないのか
漢だな

**デフォルトの名無しさん** · 2016/04/24(日) 08:38:51.73

メモリー512バイトでどうやってヒープを使えと。

**デフォルトの名無しさん** · 2016/04/24(日) 09:31:32.99

ネイティブコードが必要な場面で中途半端に GC に頼るのが問題なのかもしれないが、もうネイティブコードが必要な戦場は限られた一部だけになってて、主戦場では GC は大前提の技術なんだから必要ないとか言われましてもですわ。

**デフォルトの名無しさん** · 2016/04/24(日) 10:14:15.47

ページがスカスカになっても大丈夫
1ページ4KBとかだからね、十分小さい
32x32-32bitビットマップより小さい

最近のゲームで使われるような大きなサイズのテクスチャなど
でかいサイズを確保する場合はどうせ新しいページが割り当てられるし
小さなサイズを確保する場合は、スカスカになったページから空いているところを探して割り当てられるので
問題ない

**デフォルトの名無しさん** · 2016/04/24(日) 10:14:59.78

androidしか知りませんみたいな事言われてもな

**デフォルトの名無しさん** · 2016/04/24(日) 10:27:10.54

物理アドレスはページサイズで切り売りされるので
元から連続しているアドレスは必要ではなく
フラグメンテーションは問題にならない

連続したアドレスが必要になるのは論理アドレスのほうであり
32bitプロセスでは4GBしか空間がないから問題になることがある
64bitプロセスであれば現状問題にならない

**デフォルトの名無しさん** · 2016/04/24(日) 10:37:41.02

実はQtでデーモン作って動かしてるのだが、もう半年以上動き続けてる。
まさかこんなに問題が起きないとは。
案ずるより産むがやすしですぞ皆の衆。

**デフォルトの名無しさん** · 2016/04/24(日) 10:58:37.83

Qtで作ったのは一日ででっち上げる為だったのだが、意外なことに堅牢に動き続けてる。

**デフォルトの名無しさん** · 2016/04/24(日) 12:08:49.17

Qt でデーモン?
GUI が必要なデーモン?

**デフォルトの名無しさん** · 2016/04/24(日) 12:13:06.27

>>525
デーモンは通常フォアグラウンドじゃないのでUIを持ちませんぜ旦那。

**デフォルトの名無しさん** · 2016/04/24(日) 12:25:33.24

ならば何に何故どのように Qt を使うのだ？

**デフォルトの名無しさん** · 2016/04/24(日) 12:45:58.38

>>526
だからQtでデーモン？(クエスチョン)…なんじゃね？
加えてQtってGC関係あるのか？
たしかC++のライブラリーだよね？

**デフォルトの名無しさん** · 2016/04/24(日) 13:02:46.55

等と意味不明な供述をしており。

**デフォルトの名無しさん** · 2016/04/24(日) 14:52:01.10

>>525
Qt 使ってるからと言って QtGui 使ってるとは限らんけどね

>>528
Qt 本体は C++ で書かれてるけ
ど Java, Ruby, Python, Perl, C# 等からも利用できるよ

**デフォルトの名無しさん** · 2016/04/24(日) 14:52:56.88

daemonじゃなくてdemonなんじゃない？
デスクトップマスコット的な

**デフォルトの名無しさん** · 2016/04/24(日) 14:59:36.53

俺が作ったのはウェブソケットによってサービスを提供するプログラムだ。
エンジンエックスをリバースプロキシとした。
このプログラムは常時数千の接続から大量のリクエストを受け付ける。
接続してくるクライアントは専用に作られQtで書かれている。
大量のリクエストはそれぞれ複数のデータベース検索を引き起こす。

こう書くと結構負荷が高そうなのだが、さすがC++、ほとんど塵程度の負荷しかなく、
当然のことながらリプライに遅延もない。
そこで案ずるよりも生むが易しというわけ。

Qtは出自からしてGUIのためのライブラリではあるのだが、GUIが無いと使えないというわけでもない。
むしろボリュームからすれば、GUI以外の方がより大きい。
そして、半年動きっぱなしで大丈夫ことからして、実は断片化は気にしなくても
良さそうだ。

**デフォルトの名無しさん** · 2016/04/24(日) 15:05:02.69

ちなみにQt使ってなかったら一日でサービスを書き上げることは不可能だっただろう。
Qtは、その他のGUIライブラリ同様バグが多いのだが、GUIを抜いてみるとどうだろう、
意外なほどに堅牢なのだ。
何しろもう半年動きっぱなし。

俺はこの経験から一つの予測を立てた。
これからのサービスは、C++で書かれるようになる可能性がある。
何しろ圧倒的に速い。
一つのリクエストに対するレスポンスが速いため、平均負荷率が圧倒的に下がるのだ。
この事実に世の中が気づくにはそう時間がかからないはず。

そしてsystemdがこの動きを促進するはず。

ちなみにWindowsで書いてLinuxで動かしてます。

**デフォルトの名無しさん** · 2016/04/24(日) 15:05:44.58

一例をもって一般化はできないだろ

**デフォルトの名無しさん** · 2016/04/24(日) 15:05:53.54

>>530
色々な言語から使えるのか
そういう場合Qtが使うメモリーなんかはどういう扱いなんだろうね
GC適用外な気がするけど知らないからこれでやめとくわ

**デフォルトの名無しさん** · 2016/04/24(日) 15:08:01.90

Windowsで書いてLinuxで動かすことに、systemdは大いに貢献した。
従来のデーモンの作り方では、いろいろ煩雑なことがありすぎ、時間の制限から難しかっただろう。

Qt+systemd、この直観的な選択は大成功であった。

**デフォルトの名無しさん** · 2016/04/24(日) 15:11:43.89

Qtのバグの多くは、複数の環境に対応するため、その差異によって引き起こされているという結論を得た。

systemd万歳！

GCは失敗。メモリは自分で管理せよ！ その2©2ch.net

GCは失敗。メモリは自分で管理せよ！その2©2ch.net