- 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/
- 263 名前：デフォルトの名無しさん mailto:sage [2015/12/08(火) 22:59:22.32 ID:RKxPG6yJ.net]
- >>255 shared_ptrと恒等なものは無いけど、ポインタ的に使える型がBox, Rc, Cell(あるいはRefCell)とあって、
Boxはヒープ領域であること、Rcは複数の所有者がいる(つまり所有者全員が死ぬまでは生きている)こと、Cellは複数の書き込みが作れること、
とか機能とコストが別れているから、これらを組み合わせて使う。
で、Thread Safetyを実現させる機構は上記には無いので、Atomicityを導入させるRcの類似形であるArcと、
書き込みもしたいならMutexっていう型も合わせて使う。
すると、例えば整数のベクトルをスレッド間で共有したい、とかになるとArc<Mutex<Vec<i32>>>という目が滑るような型表記をすることになる。
あんま詳しくないので、ケース毎にもっと簡単なやり方があるとは思うんだけどね。
- 264 名前：デフォルトの名無しさん mailto:sage [2015/12/08(火) 23:55:28.64 ID:NMHe7TFl.net]
- >>258
ああ、Arcってのが別にいるのね。納得
個人的にもう一点気になる所があるから聞いてしまう
BoxやDropを使ってるとコピー禁止になるらしいけど
これ面倒な場合ない？
最初はコピー可能な型としてガンガンコピーしてたけど
途中から終了処理を書きたくなったらコピーしてる箇所
全部直すって事？
ちなみにググってたらRWArcっての見つけたんだけど
これ読み書き可能なArcなんじゃね
- 265 名前：デフォルトの名無しさん mailto:sage [2015/12/09(水) 00:46:02.26 ID:WVnNYSfg.net]
- >>249
javaは世代別管理でGCの種類は色々選べるはずでは
- 266 名前：デフォルトの名無しさん [2015/12/09(水) 01:14:15.85 ID:wAGGTtTq.net]
- >>260
起動時に切り替えられるだけであって
オブジェクトごとには切り替えられないのでは
- 267 名前：デフォルトの名無しさん mailto:sage [2015/12/09(水) 01:50:08.36 ID:x/ryIvcR.net]
- >>259 コピーしまくっているような変数の型をTからBox<T>に変えた場合、確かに面倒なことになる。
けど、基本的に単純な代入(let x = y)はコピーじゃなくてmoveになるし、
Box<T>の値をコピーしてBox<T>の値を生成するっていうのは、同じヒープ領域を指すポインタを作るんじゃなく、
新しいヒープ領域を確保して中身をコピーし、そのポインタを返すという意味なんで、
変数の型を後でTをBox<T>に変える、という場面はあまり無い(少なくとも自分は学んでいる最中にそういうことをしたくなったことがない)
値をコピーする場面では、元の変数の型がBox<T>であってもTであっても、参照型&Tを受け取ってTを生成、ということをするのが定石。
&Tはほぼ無制限に安全に作ることができるし、安全じゃない可能性があったらコンパイルが通らない。
で、コピーした型Tの値は呼び出し元がBoxに包んでヒープ領域に置いたりするのが定石
Dropも別にコピーを禁止することは無いよ。後からつけたらエラーまみれ、ということにはならない。
あと、自作じゃない型に自作じゃないトレイト(インターフェイスみたいなもの)をつけることができないので、
例えば標準ライブラリのFileやTcpStreamはCopyできるようには決してできない。メモリ以外の資源管理も安全だよ。
- 268 名前：デフォルトの名無しさん [2015/12/12(土) 10:36:13.53 ID:mXWFWn5f.net]
- freeし忘れるとか、そんな超ウルトラ素人ミスを大前提に議論するのは間違いだよなｗ
freeしきれないとかｗｗｗｗ
- 269 名前：デフォルトの名無しさん [2015/12/12(土) 11:52:29.69 ID:v/VbuB+R.net]
- >>263
規模が大きくなれば管理が難しくなるのは普通のことだよ。
ライフサイクルはオブジェクトごとに異なるものだし、
人間に頼らずにGCにメモリ管理を任せるっていうのは良いやり方だよ。
- 270 名前：デフォルトの名無しさん mailto:sage [2015/12/12(土) 12:05:07.06 ID:yfUf7LLZ.net]
- shared_ptrって参照カウント式のGCじゃないの？
- 271 名前：デフォルトの名無しさん mailto:sage [2015/12/12(土) 12:44:09.71 ID:7G0ybzbE.net]
- 循環を綺麗に扱えるなら参照カウントの方が良いと思うけど
VB6は循環参照の扱いどうやってるんだろう
- 272 名前：デフォルトの名無しさん mailto:sage [2015/12/12(土) 14:25:51.97 ID:npRd3MLZ.net]
- >>265
RAIIじゃろ
- 273 名前：デフォルトの名無しさん mailto:sage [2015/12/12(土) 15:20:38.55 ID:tVgJgcBS.net]
- >>265
GCの一種だけど、文脈的にはプログラマが
管理が非局所的で明確な型宣言もなしに使えるのをGCと言ってるわけで
議論で揚げ足にしかならない野暮な突っ込みはやめようぜ
- 274 名前：名無しさん＠そうだ選挙に行こう [2015/12/14(月) 08:16:09.53 ID:hn3965Zz.net]
- >>264
いや、下手って一言で片付けられるよ。
よっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっぽど、出ない限り
- 275 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2015/12/14(月) 08:38:44.84 ID:sXTPVO5Q.net]
- 片付ける奴が馬鹿なのだ。素人ほど簡単だと言いたがり、上級者ほど簡単ではないとはっきり言うものだ。
どの分野でもな。
- 276 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2015/12/14(月) 09:09:02.89 ID:lNUL9lX8.net]
- freeとか言ってる奴はC++使えよ。いつまでＣ使ってんだ。
- 277 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2015/12/14(月) 09:20:53.11 ID:MauTQhQ/.net]
- >>270
東大生が人に教えるとき、何がわからないのかわからないというのがわからない。
上級者になればなるほど自分がやってることなんて簡単に見えてくる
- 278 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2015/12/14(月) 09:35:23.70 ID:sXTPVO5Q.net]
- >>272
何が分らないか分らない、つまり東大生も生徒がどういう思考をしてるか分析できず分らないと言ってるのだ。
低学歴ほど、分らないのはおまえが馬鹿だからと簡単に片付けるものだ。
- 279 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2015/12/14(月) 09:37:05.77 ID:eBJzgHzn.net]
- それ中級者
あと、東大生は教えるの上手いのもいるから想像で話すな馬鹿
- 280 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2015/12/14(月) 09:41:37.74 ID:sXTPVO5Q.net]
- このようにおまえのようなコンテキストすらまともに読めないPGは五万といる。
スレッドがデッドロックしてメモリを開放できないなんてよくあることだ。
- 281 名前：名無しさん＠そうだ選挙に行こう [2015/12/14(月) 10:59:16.82 ID:hn3965Zz.net]
- >>275
。。。。。完全な設計ミスじゃん
- 282 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2015/12/14(月) 11:15:19.23 ID:eBJzgHzn.net]
- >>275
俺は272に向けてたんだが
そりゃコンテキスト読めてないように見えるよなw
- 283 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2015/12/14(月) 11:40:27.14 ID:ETDpPCfc.net]
- スレッドがデッドロックしたらメモリリークどころじゃないじゃないかwww
- 284 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2015/12/14(月) 14:48:51.74 ID:MOnxQz3f.net]
- スレッドがデッドロックしちゃってメモリ解放できない（泣）
っていうPGが五万といるのかよｗ
- 285 名前：名無しさん＠そうだ選挙に行こう [2015/12/14(月) 15:51:19.55 ID:hn3965Zz.net]
- まぁfreeやdeleteやnullやらすらできないPGに、「僕はそんなこと管理しきれる脳みそ持ってない！」って言われたらソレは真実なんだろうけど・・・。
そんな脳みそPGに「もっと複雑な業務使用」を理解できるとは思えないんだ。
そんなPGにプログラミングの場を与えるのが間違い。
- 286 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2015/12/14(月) 15:58:21.86 ID:2JSVZtRY.net]
- そもそも実務でスレッド使うＰＧなんてゴマンもいない
- 287 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2015/12/14(月) 17:06:58.52 ID:eBJzgHzn.net]
- Javaのプロジェクトだとほぼ使ってるけどな隠蔽してるだけで
そのせいで共有リソース壊したり、逆に個人情報の領域が共有されたりして、とんでもないインシデントが発生する
そんな奴等にメモリ管理なんて任せられんし、共有リソースも触らせたくないから
更に隠蔽したフレームワークもどきが出来上がる
- 288 名前：名無しさん＠そうだ選挙に行こう [2015/12/14(月) 17:59:33.07 ID:hn3965Zz.net]
- >>282
勝手に使うな。勝手にトリッキーコードにすんな。
素直に、設計書通りに作れ。
勝手なことやって勝手に自爆してるだけじゃねーか。
- 289 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2015/12/14(月) 18:15:27.90 ID:Z4FycFda.net]
- javaってc++のconst参照に対応するものが無いのに、素人みたいなプログラマを大量にかき集めているのが怖すぎる。
- 290 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2015/12/14(月) 18:28:13.63 ID:eBJzgHzn.net]
- >>283
理解してないのに無理してレスしなくていいから
- 291 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2015/12/14(月) 18:42:08.38 ID:CJqGCki1.net]
- C#はマルチスレッド使いまくりだけど事故の話はあまり聞かないな
マイクロソフトが優秀なのか低品質プログラマがいないのか
- 292 名前：名無しさん＠そうだ選挙に行こう mailto:sage [2015/12/14(月) 19:01:59.11 ID:2+GDL4RD.net]
- JAVA自体がDQN
- 293 名前：uy ◆Qawu9.2l1E [2015/12/14(月) 20:57:26.55 ID:J5PYIleC.net]
- Freeし忘れ
↑これ。
ソースコード書いてる人間の注意力次第でバグが入るなら
言語も設計も間違ってるよ
- 294 名前：デフォルトの名無しさん mailto:sage [2015/12/14(月) 21:54:10.80 ID:ETDpPCfc.net]
- 動的型言語
↑
これ
コード書いている人間の注意力次第でtypoするだけで
実行するまでわからないバグが入るなら
言語も設計も間違ってるよ
- 295 名前：デフォルトの名無しさん mailto:sage [2015/12/14(月) 22:23:00.81 ID:lNUL9lX8.net]
- C#でcatchやfinally書くの嫌すぎる
C++に戻りたい
- 296 名前：デフォルトの名無しさん mailto:sage [2015/12/14(月) 22:43:08.79 ID:bhzmg0NL.net]
- >>290
おかえり
- 297 名前：デフォルトの名無しさん mailto:sage [2015/12/15(火) 06:39:51.52 ID:gQhFMQgY.net]
- (ヽ´ω`)眠い
- 298 名前：デフォルトの名無しさん mailto:sage [2015/12/16(水) 08:46:15.45 ID:fgV80IeN.net]
- >>290
C++/CLR「こっちこいよ」
- 299 名前：デフォルトの名無しさん [2015/12/17(木) 17:18:40.36 ID:Szn4FINI.net]
- COMのVariantとかJSとかリークしまくりだし
- 300 名前：デフォルトの名無しさん mailto:sage [2015/12/17(木) 23:16:36.40 ID:kltDf5Nv.net]
- そういやVBScriptって参照カウンタ以外のGC積んでんのあれ
必要には見えないんだけど
- 301 名前：デフォルトの名無しさん [2015/12/18(金) 23:17:49.50 ID:b1Otx84Y.net]
- プログラマはMacを使ってるってマジ？
hayabusa3.2ch.net/test/read.cgi/news/1450395043/
- 302 名前：デフォルトの名無しさん mailto:sage [2015/12/19(土) 07:07:37.11 ID:qL4RiVer.net]
- マカーってどんだけアホなの？
- 303 名前：デフォルトの名無しさん [2015/12/19(土) 12:49:09.79 ID:EW8XrhCB.net]
- 解放処理
すら、まともにお前ら管理できねーのかよ・・・・・・・・・・・・・・・・。そらオレが完璧な仕様書渡してもバグってるわけだ
- 304 名前：デフォルトの名無しさん mailto:sage [2015/12/19(土) 13:38:07.82 ID:i3zp3GbO.net]
- 開放処理を手動でやれって書いてある仕様書かw
御免こうむるwwwww
- 305 名前：デフォルトの名無しさん [2015/12/19(土) 14:42:49.35 ID:iG82T79N.net]
- ガベコレのあるPyObjectをラップするクラスをガベコレのあるDで書いたら
wxPythonで書いたクラスをDから使ったとき意味不明なタイミングで落ちるようになった
二重に管理するとだめなんかな
- 306 名前：デフォルトの名無しさん [2015/12/19(土) 15:57:38.71 ID:qL4RiVer.net]
- >>298
ﾌﾟﾌﾟﾌﾟ 馬鹿だこいつw
- 307 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 08:46:23.14 ID:gr0U1KS4.net]
- ガベージコレクションはたしかに便利だ
だからといって「本来はてめぇのケツはてめぇで拭け＝自分で解放すること」を忘れてはならない
そんだけ
- 308 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 11:55:11.08 ID:HXRBhwTH.net]
- C#ではSafeHandleだけ作って後は放置
usingも使わないってのがトレンドだけどね
自分で解放とかバカバカしい
面倒はランタイムに見させて開発者はドメイン設計に集中するって目的を見失うな
- 309 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 12:13:23.36 ID:ofrSOHxv.net]
- >>303
オブジェクトの開放を他と独立にやれるケースばかりならそう言えるかもしれんが
オブジェクトAとBがリソースCに依存しているケースでA、Bの開放の少なくとも片方をGCに任せる場合、
リソースCの参照カウンタなりをつかった防護策をプログラマーが書かねばならない
しかしそんな嫌ったらしい雑用を増やすぐらいなら
Cオープン
A生成
B生成
A, B使用
B開放
A開放
Cクローズ
でええやん？
さらにダンプファイルとかからの障害解析において、オブジェクトが生きているべきなのか死んでいるべきなのか決まっていないとか、
アドレスがはっきりしないとか言う状況は地獄
- 310 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 12:21:54.48 ID:ofrSOHxv.net]
- つかこの世はうつろうもののであって、物理的ハードウェアでプログラムを実行する限り、
計算モデルは明らかに状態遷移ベース（チューリングマシン）の方に分がある
GCとかチューリングマシンで無理矢理関数型プログラミングを行うためのつなぎの技術、
いわば邪道
どんだけ蛇が出てくるか、GCの方がかえってわからん
- 311 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 13:48:14.94 ID:HXRBhwTH.net]
- >>304
設計が悪い
使い終わったという言葉が示す通り使い終わったならどうなろうが知った事ではない
知らなきゃ困るような設計にしたのが間違いだね
- 312 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 13:52:55.68 ID:8RLYRFXT.net]
- メモリ空間は無限であるべき
使い終わったメモリの断片化なにそれ？
仮想メモリを管理するのはCPUの責任だろ
- 313 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 14:03:49.29 ID:ofrSOHxv.net]
- >>306
>>304の例で、さらにCを上書き更新したいオブジェクトDがいたらどうすんの？
GCがA、B両方開放してくれるまでDは期限不定で待たされるけどそれが>>306的に良い設計なの？
つまり、ハードウェアリソースの有限性を考慮する限り
>使い終わったという言葉が示す通り使い終わったならどうなろうが知った事ではない
が常に成立はしないという話
- 314 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 14:28:20.48 ID:i39XsMQ2.net]
- >>308
そんなあっちこっちから同時にリソース掴みに行く設計が悪いって最初からわかってて言ってるんだろ？
意見を否定するためだけの極端な反例(この場合は例にすらなっていないが)を引き合いに出すのは不毛だよ
- 315 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 14:35:53.96 ID:xl2QwS3M.net]
- >>303
いい加減だなぁw
- 316 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 14:36:58.02 ID:ofrSOHxv.net]
- >>309
>そんなあっちこっちから同時にリソース掴みに行く設計が悪いって最初からわかってて言ってるんだろ？
極論なもんｶﾖ；
例： 表示デバイスの数＞表示したいスレッドの数
というのはざらにある
で、>>308のオブジェクトDのケースはどう解決すんのさ…
GCが「いつ開放してくれるかわからない」ブツである以上解消しない問題だとおもうんだけど
（A、BにCのための明示的closeメソッドを付けるぐらいならGCに頼らずに順序管理するわ；
- 317 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 14:42:20.07 ID:ofrSOHxv.net]
- 解決策の一つはActive ObjectパターンでリソースCの管理を1スレッドXにやらせて
Cに対する要求を全部Xのキューにシリアル化して入れさせるというのがあるが、それはそれで
リソースCを使う全てのオブジェクトがスレッドXに依存するから、Xの開放コードが面倒なことになりかねない
かつ、シリアル化はマルチコア時代のせっかくの並列実行性能を殺してしまう
GCに合わせて生きることは、神仙にでもならねば到底かなわぬ…
- 318 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 14:44:35.05 ID:ZDEpjFBd.net]
- つくづく、ARC最強だな。
- 319 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 14:46:27.58 ID:i39XsMQ2.net]
- >>311
その例じゃ308の状況にならないよ
どんなコード書いてんだよw
- 320 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 14:48:11.36 ID:ofrSOHxv.net]
- >>314
>その例じゃ308の状況にならないよ
なんで？ビデオメモリに2スレッドから同時に書いて無事に済むと思ってるの…；
- 321 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 14:51:52.93 ID:i39XsMQ2.net]
- だから同時に書く設計が悪いんだって
気合入れて設計を見直してみろ
そんな必要はないってわかるから
- 322 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 14:55:30.48 ID:ofrSOHxv.net]
- ていうか>>316の言っていることはますます矛盾で、
>同時に書く設計が悪い
>そんな必要はないってわかる
というのは明白に「書き込みの順序を設計できる」ということを言っていて、
それはその通り（チューリングマシンの計算モデルに合致する）ので別段漏れの立場と対立するものではなく、
かつ気合を入れて設計すれば順序で全て解決する（GCは不要である）という言明でもある
- 323 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 15:17:45.93 ID:14eB8c4R.net]
- >>315
もはやGCがどう関係するのかわからない
- 324 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 15:20:28.11 ID:i39XsMQ2.net]
- >>318
彼は敵対意見に反論する材料が欲しいというだけで変な例をでっち上げて出してしまったんだ
本人も今頃困ってるんじゃないかな
- 325 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 17:05:42.48 ID:6vo8OCaj.net]
- >>319
>>308を変な例変な例というばかりでGCを用いた正しい解決方法が一向に示されない件について：
繰り返しになるが、>>308のオブジェクトDのケースはどう解決すんのさ…
たとえ変でも反例は反例だし
>>308のリソースCがファイルなのだとしたら、病的な反例というほど例外的想定でもない
読み書き順序の設計の必要性（破壊的代入前提のプログラミング）を口にしつつ
>使い終わったという言葉が示す通り使い終わったならどうなろうが知った事ではない （>306）
と言い切ることはできないとかそういう話
で、現実のハードウェアは破壊的代入前提のブツばかりであるという、（>306)
>>318
ウィンドウシステムでの描画は一般に裏VRAMに描いてハードウェアでBitBlt転送するが
裏VRAMに書く際のデバイスコンテキストが複数使えるが数に限りがある場合…
とか細かい話をしても通じないようならリソースCをファイルと考えてくんな
- 326 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 17:12:24.84 ID:6vo8OCaj.net]
- ﾌﾟﾁ訂正
誤: で、現実のハードウェアは破壊的代入前提のブツばかりであるという、（>306)
正: で、現実のハードウェアは破壊的代入前提のブツばかりであるという、（>308)
- 327 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 17:19:25.13 ID:HXRBhwTH.net]
- 読み込みと書き込みを別のリソースに分離したり読み書きが同時に出来るように作る
書き込みたいから読み込み終わるの待ってますってリソースの無駄だろ
- 328 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 17:21:31.86 ID:ZDEpjFBd.net]
- なんか参照カウントの話とマルチスレッドの話がごっちゃになってね？
- 329 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 17:33:49.10 ID:6vo8OCaj.net]
- >>322
>読み込みと書き込みを別のリソースに分離したり読み書きが同時に出来るように作る
破壊的代入の世界ではそいつは常に可能とは限らない
>308の例で、リソースCがファイルXなのだとしたら、オブジェクトDが上書きすべきもあくまでファイルXでないといけない。
つまりリソース分離の余地など無い
（正確には、無理矢理ファイルA、BはファイルX、DはファイルYに分ける設計もありえるが、XとYに対する変更をいつどのように統合するかという超難題が生じる
この手の混乱は、A、BがアクセスするリソースCの開放タイミングの決定をGCに任せてサボったがために生じるのである
- 330 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 18:10:09.92 ID:ZDEpjFBd.net]
- おいおい、バージョン管理のマージの話にまで拡張したら収集つかなくなるぞw
- 331 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 19:32:49.85 ID:i39XsMQ2.net]
- >>324
ファイルの分割は必ずしも必要ではないし更新モデルから読み取りモデルへの同期も必要ないよ
- 332 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 19:44:06.53 ID:9YX+2XWA.net]
- >>323 (Rust信者で)すまんな。
ttp://smallcultfollowing.com/babysteps/blog/2015/12/18/rayon-data-parallelism-in-rust/#data-race-freedom
マルチスレッドで起きるデータ競合といった問題も、シングルスレッドで起きうるdangling pointerなどの問題も、
どっちも所有権を持つオブジェクトが無闇にいたり、変な参照関係があるから起きるんじゃないか？って言う人がおる。
根っこが同じ、あるいは近しい問題なんで、横滑りに見えても堪忍な。
- 333 名前：デフォルトの名無しさん mailto:sage [2015/12/20(日) 19:49:46.85 ID:kaqci566.net]
- メモリ管理もできないんだから
データの依存関係とか関係ねえ～～～～～～～～～～～～
でおわりでは
- 334 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 05:26:25.94 ID:ejqZ3DMD.net]
- GoogleChrome動作中のタスクマネージャーのイメージ名にsvchost.exeが見当たらない
GoogleChromeでは、svchost.exeを使用せずに、chrome.exe自身で制御しているらしい
Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36 Width/1360px/1920px
- 335 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 05:32:28.99 ID:ejqZ3DMD.net]
- その理由・・・GCは失敗。メモリは自分で管理せよ！
peace.2ch.net/test/read.cgi/tech/1447856699/l50
- 336 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 05:35:31.18 ID:ejqZ3DMD.net]
- メインメモリに対するGC・・・MGC
HDDならストレージGC・・・SGC
- 337 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 05:38:11.78 ID:ejqZ3DMD.net]
- GoogleChromeかsvchost.exeを使わなくなった理由・・・ページメモリGC制御が遅過ぎでお粗末だからか？
- 338 名前：デフォルトの名無しさん mailto:sage [2
]
- [ここ壊れてます]
- 339 名前：015/12/21(月) 05:42:27.02 ID:ejqZ3DMD.net mailto: GoogleChrome動作中のタスクマネージャーのイメージ名にsvchost.exeが見当たらない
GoogleChromeでは、svchost.exeを使用せずに、chrome.exe自身で制御しているらしい
Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36 Width/1360px/1920px [] - [ここ壊れてます]
- 340 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 05:45:15.43 ID:ejqZ3DMD.net]
- 「Svchost Process Analyzer」
svchost.exeのプロセスの中身が何かを調べて表示するフリーソフト
gigazine.net/news/20131114-svchost-process-analyzer/
- 341 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 05:51:39.30 ID:ejqZ3DMD.net]
- そろそろsvchost.exeを使うソフトは使用禁止なのかも？
- 342 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 06:11:17.64 ID:ejqZ3DMD.net]
- svchost.exeを使わないことでGoogleChromeは確実に応答性能が速くなって�
- 343 名前：｢る
・・・動画マルチ再生でクラッシュしたFirefoxは見習うべき [] - [ここ壊れてます]
- 344 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 06:17:26.48 ID:ejqZ3DMD.net]
- 残念だがスリープだ！
pds.exblog.jp/pds/1/201104/11/06/e0026606_2391337.jpg i.imgur.com/qrjJDgC.jpg
- 345 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 06:40:32.08 ID:ejqZ3DMD.net]
- Wave
aurorawave.atspace.tv/?sop:v/jfgn-S6JzfM!RDtSvhh7Sq1OU i1.ytimg.com/vi/jfgn-S6JzfM/mqdefault.jpg #AuroraWaveTV
- 346 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 06:42:41.39 ID:ejqZ3DMD.net]
- LG OLED TV : You Dream We Display
aurorawave.atspace.tv/?sop:v/VenG8TF90yA!RDVenG8TF90yA i1.ytimg.com/vi/VenG8TF90yA/mqdefault.jpg #AuroraWaveTV
- 347 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 06:43:24.61 ID:ejqZ3DMD.net]
- LG OLED TV - The Ultimate Display
aurorawave.atspace.tv/?sop:v/JubFjalfNIY!RDJubFjalfNIY i1.ytimg.com/vi/JubFjalfNIY/mqdefault.jpg #AuroraWaveTV
- 348 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 07:08:24.86 ID:ejqZ3DMD.net]
- LG 4K OLED: Paris and Chicago
aurorawave.atspace.tv/?sop:v/Hi_WWhih4n4!RDHi_WWhih4n4 i1.ytimg.com/vi/Hi_WWhih4n4/mqdefault.jpg #AuroraWaveTV
- 349 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 09:26:05.64 ID:ejqZ3DMD.net]
- 国別ISO登録件数 ⇒ 技術マフィア ⇒ 技術流出状況
www.jicqa.co.jp/09info/07newsletter/2012/no168_news1201.html
www.jicqa.co.jp/09info/07newsletter/2012/img/2012-0105-1741.JPG
www.jicqa.co.jp/09info/07newsletter/2012/img/2012-0105-1818.JPG
www.jicqa.co.jp/09info/07newsletter/2012/img/2012-0105-1742-a.JPG
www.google.co.jp/search?q=ISO%E6%9C%AC%E9%83%A8&num=100&ie=utf-8
pds.exblog.jp/pds/1/200909/06/87/a0137487_22475768.jpg
- 350 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 09:41:02.29 ID:ejqZ3DMD.net]
- 中国、ダークマターの検出に挑む探査衛星「悟空」を打ち上げ
news.mynavi.jp/news/2015/12/17/495/
n.mynv.jp/news/2015/12/17/495/images/001l.jpg
n.mynv.jp/news/2015/12/17/495/images/002l.jpg
n.mynv.jp/news/2015/12/17/495/images/003l.jpg
- 351 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 09:44:40.17 ID:ejqZ3DMD.net]
- 京がお仕置き候補に???
gigazine.net/news/20130618-fastest-supercomputers/
◆1位：Tianhe-2(天河二号)、中国人民解放軍国防科学技術大学
i.gzn.jp/img/2013/06/18/fastest-supercomputers/01_m.jpg
IntelのIvy Bridge(12コア・2.2GHz)とXeon Phi(57コア・1.1GHz)を採用し、
コア数は312万、計算速度は33.9ペタフロップス、消費電力は17.8MW
◆2位：Titan、アメリカのオークリッジ国立研究所
i.gzn.jp/img/2013/06/18/fastest-supercomputers/02_titan2_m.jpg
AMD Opteron 6274(16コア・2.2GHz)とNvidia Kepler(14コア・0.732GHz)を採用し、
コア数は56万640、計算速度は17.6ペタフロップス、消費電力は8.3MW
◆3位：Sequoia、アメリカのローレンス・リバモア国立研究所
i.gzn.jp/img/2013/06/18/fastest-supercomputers/03_8716842181_3f50ae207a_o_m.jpg
IBM BlueGene/Qを採用し、中のプロセッサーはPower BQC(16コア・1.60GHz)、
コア数は157万2864、計算速度は17.2ペタフロップス、消費電力は7.9MW
◆4位：スーパーコンピュータ京、独立行政法人理化学研究所 計算科学研究機構(AICS)
i.gzn.jp/img/2013/06/18/fastest-supercomputers/04_01_m.jpg
富士通 SPARC64 VIIIfx(8コア・2.0GHz)を採用し、コア数は70万5204、
計算速度は10.5ペタフロップス、消費電力は12.7MW
◆5位：Mira、アメリカのアルゴンヌ国立研究所のエネルギー部門
i.gzn.jp/img/2013/06/18/fastest-supercomputers/05_30292D004-72dpi_m.jpg
BM BlueGene/Qを採用し、中のプロセッサーはPower BQC(16コア・1.60GHz)、
コア数は78万6432、計算速度は8.6ペタフロップス、消費電力は3.95MW
- 352 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 09:50:17.19 ID:ejqZ3DMD.net]
- 気づかないかISOは中国のためにある
www.jicqa.co.jp/09info/07newsletter/2012/img/2012-0105-1742-a.JPG
- 353 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 10:45:57.17 ID:1HvlxK+M.net]
- >>344
蓮舫さんに次の選挙は次点で良いですよねって言ってきて
- 354 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 11:12:03.51 ID:1HvlxK+M.net]
- >>336
ほんそれ
- 355 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 12:31:40.33 ID:ejqZ3DMD.net]
- https://ja.wikipedia.org/wiki/%E8%93%AE%E8%88%AB
- 356 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 12:34:04.50 ID:ejqZ3DMD.net]
- https://www.google.co.jp/search?q=%E3%81%BB%E3%82%93%E3%81%9D%E3%82%8C
- 357 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 12:36:38.19 ID:x6st9rMu.net]
- ただしChromeはプロセスが一杯できるから
タスクマネージャ覗いた時に気持ち悪い
- 358 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 16:06:45.56 ID:ejqZ3DMD.net]
- 64の時代だから、そろそろCore64ぐらいでイイのでは？
blogs.msdn.com/cfs-filesystemfile.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-43-metablogapi/3568.Windows_2D00_7_2D00_CPU_2D00_Usage_2D00_History_5F00_3E37E697.png
download.intel.com/newsroom/kits/xeon/phi/gallery/images/XeonPhiDie_02.jpg
- 359 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 16:21:26.45 ID:ejqZ3DMD.net]
- ラーメン
www.chikuwachan.com/ramen/
www.chikuwachan.com/ramen/image/ramen/1430/10_417_512.jpg
- 360 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 16:33:49.61 ID:ejqZ3DMD.net]
- www.dospara.co.jp/ad/stick_mv.html
www.dospara.co.jp/ad/img/stick_mv/title_main.gif
- 361 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 16:35:11.77 ID:ejqZ3DMD.net]
- diginnos stickpc_02
www.youtube.com/watch?v=OPt0OGNQhnU&list=RDOPt0OGNQhnU
- 362 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 18:37:51.00 ID:ejqZ3DMD.net]
- Holiday Glam
aurorawave.atspace.tv/?sop:v/tEdxHgCoXss!RDtEdxHgCoXss i1.ytimg.com/vi/tEdxHgCoXss/mqdefault.jpg #AuroraWaveTV
- 363 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 18:38:29.84 ID:ejqZ3DMD.net]
- Midnight Luster
aurorawave.atspace.tv/?sop:v/DBTd9qv_sJI!RDDBTd9qv_sJI i1.ytimg.com/vi/DBTd9qv_sJI/mqdefault.jpg #AuroraWaveTV
- 364 名前：デフォルトの名無しさん mailto:sage [2015/12/21(月) 18:43:07.58 ID:ejqZ3DMD.net]
- Chromeの調子が良い件について・・・TCL 4K Demo: Ultra-Running Beauty
aurorawave.atspace.tv/?sop:v/Gg54Miwa8K4!RDHi_WWhih4n4 i1.ytimg.com/vi/Gg54Miwa8K4/mqdefault.jpg #AuroraWaveTV
- 365 名前：デフォルトの名無しさん [2016/01/10(日) 12:45:59.41 ID:LOFSek54.net]
- 723 : 名無しさん＠お腹いっぱい。 2016/01/10(日) 12:24:00.06 ID:rlcuxF0A0
Vivaldiの起動が遅いのは
タブのサムネイルに関係しているかもしれない
Blinkは負荷分散のため？かHDDアクセスも遅いらしい
ローカルストレージ関係がとても遅いからだ
724 : 名無しさん＠お腹いっぱい。 2016/01/10(日) 12:31:29.50 ID:rlcuxF0A0
タブサムネイルを
ローカルストレージで保存するのは止めたほうがいい
タブサムネイルは直接アクセスする事
fopen();ランダム書込:fclose();ランダム読込:fopen();
読取だけならオーバーヘッドを避けるためfopen();しない
725 : 名無しさん＠お腹いっぱい。 2016/01/10(日) 12:33:41.35 ID:rlcuxF0A0
命題・・・Vivaldiは遅い起動を早期解消せよ！
726 : 名無しさん＠お腹いっぱい。 2016/01/10(日) 12:37:50.17 ID:rlcuxF0A0
ランダム書込用HDDスペースを作る 個数*固定サイズ
１トランザクション 個数1024個、固定サイズ256kバイト
727 : 名無しさん＠お腹いっぱい。 2016/01/10(日) 12:40:34.65 ID:rlcuxF0A0
そしたら、ランダム読み書きでfopen()すればいい
オーバーヘッドを避けるためfopen();は終了のときだけ
オーバーヘッド無いだけで1000倍ほど速くなるケースも
728 : 名無しさん＠お腹いっぱい。 2016/01/10(日) 12:44:26.42 ID:rlcuxF0A0
オーバーヘッドはドコにあるのか？
それはWindowsOSのフォルダ構造検索にある
フォルダ構造検索回数を省けば速くなるのだ
- 366 名前：デフォルトの名無しさん [2016/01/10(日) 12:47:28.36 ID:LOFSek54.net]
- Vivaldiの起動が遅いのは
タブのサムネイルに関係しているかもしれない
Blinkは負荷分散のため？かHDDアクセスも遅いらしい
ローカルストレージ関係がとても遅いからだ
タブサムネイルを
ローカルストレージで保存するのは止めたほうがいい
タブサムネイルは直接アクセスする事
fopen();ランダム書込:fclose();ランダム読込:fopen();
読取だけならオーバーヘッドを避けるためfopen();しない
命題・・・Vivaldiは遅い起動を早期解消せよ！
ランダム書込用HDDスペースを作る 個数*固定サイズ
１トランザクション 個数1024個、固定サイズ256kバイト
そしたら、ランダム読み書きでfopen()すればいい
オーバーヘッドを避けるためfopen();は終了のときだけ
オーバーヘッド無いだけで1000倍ほど速くなるケースも
オーバーヘッドはドコにあるのか？
それはWindowsOSのフォルダ構造検索にある
フォルダ構造検索回数を省けば速くなるのだ
- 367 名前：デフォルトの名無しさん [2016/01/10(日) 12:52:32.51 ID:LOFSek54.net]
- fopen();のときフォルダ構造検索するようだ
- 368 名前：デフォルトの名無しさん [2016/01/26(火) 06:48:44.23 ID:v48l+1vS.net]
- やっとこの気色の悪い仕組みにトドメが刺されたか
javaとかGCが基本だけどflash();とかできるの？
- 369 名前：デフォルトの名無しさん mailto:sage [2016/01/26(火) 07:35:03.77 ID:RBo8KHcc.net]
- ゴミ言語は所詮ゴミ
- 370 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 17:10:09.80 ID:eULyfEEH.net]
- GCのすべてを否定するつもりはないけど・・・
GCはメモリ管理を自動化する技術だけど、今のコンピュータはメインメモリを何十ギガ積んでたりするのも普通で
メインメモリが足りなくなることはほぼ無くて、しかも仮想メモリもあるから、なおさらメモリは潤沢で・・・
むしろメインメモリ以外のリソースの方が余程貴重で、もし仮にメインメモリが足りなくなるまで
GCを発動しないアホなGCが有ったとしたらメインメモリより先に他のリソースが枯渇する状況
だからメインメモリは無駄遣いしてもよいけど、他のリソースは使い終わったら
こまめに開放しないとダメだから、いつ実行されるか分からないマークスイープ系GCの余計にRAIIな仕組みも必要なわけ
しかしこのRAIIが付け焼刃でなまっちょろい出来だったりする
C#で言えばDisposeが有るけど、C++のデストラクタのように特別扱いされておらず
ただの普通の関数でしかないので、C++のデストラクタみたいに自身のメンバ変数について
自動で芋づる式に呼び出してくれない
だから手動でメンバのDisposeを芋づる式に呼び出すコードを記述しなければならない
いちいち自身のメンバ変数にIDisposableなものが有るか無いか調べるのもひと手間かかるし
もしそうだったら自身もIDisposableにする必要があり、例の一連のイディオムを書かなければならない
当たり前にDisposeの呼び出し忘れが有ってもいけない
まるで、mallocしたらfreeするのと似ている
しかもIDisposableはコンポジションで増殖する
IDisposableなオブジェクトをコンポジションしたら、自身もIDisposableといった具合
C#のようにコンパイラマジックでなんでも実現する言語で
どうしてDisposeをC++のデストラクタみたいに特別扱いしなかったのか謎だ
- 371 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 17:24:38.54 ID:eULyfEEH.net]
- 謎だといったが、理由ははっきりしていて
メンバのDisposableを自動で呼び出す為には
他で使われてないことを保証する必要があって
参照カウンタ方式のようにローコストなものなら簡単に分かるが
これでは循環参照の問題が出る
プログラマが循環参照を気にしなくてもよいことが前提の
マークスイープ系のGCを搭載した言語では設計思想が破たんするので
参照カウンタ方式は採用できないし
マークスイープ系GCでは何処からも参照されていないことがローコストに分からないので
自動でDisposeを呼び出す仕組みを用意できない
どうにもならない
結局C++の方式が一番優れている
循環参照が発生する場合はweak_ptrを使う事だけ注意を払えば
GCにまつわる他の問題が一切発生しない
- 372 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 17:46:52.79 ID:eULyfEEH.net]
- もっと言えばC#でDisposeを実装する場合でも↑は問題になる
自身のメンバのDisposeを呼んでよいのかどうなのか
完全に自分しか使ってないことが分かっているのであればDisposeを呼び出して問題ないが
あちこちから参照されている可能性があるメンバなら勝手にDisposeを呼び出してはいけない
GC任せにするか、自分で参照カウンタを実装するか
どちらにせよ、RAIIと相性が悪い
- 373 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 17:58:09.12 ID:aloDWtjb.net]
- 前から何度も言ってるがDisposeの実装はしていいが呼び出しは禁止
これがC#では基本だからね
リソースの使用効率が悪いとか軟弱な反論をするバカがたまにいるが
実行効率気にするならそもそも別の言語使えって話になるからな
C++CLIを使えってこった
本質を見誤るなよ
- 374 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 18:38:52.76 ID:XmqLFQFE.net]
- c#の欠点はデストラクタが呼び出されるタイミングが分からないこと。
不便で仕方ないや。
- 375 名前：デフォルトの名無しさん mailto:sage [2016/01/27(水) 18:56:08.53 ID:VDkVQpP+.net]
- 最近VB.NETを使い始めたんだけど
new したオブジェクトが不要�
- 376 名前：ﾉなった時にDispose()よんだり参照にNothing代入する必要ってない（やってもいいが無意味・無駄）なのかな？ []
- [ここ壊れてます]
- 377 名前：デフォルトの名無しさん mailto:sage [2016/01/28(木) 08:05:17.75 ID:oip5UtLa.net]
- c++のデストラクタは例外投げられないウンコ仕様
だから皆デストラクタ内で発生したエラーは握り潰してる
他の言語はあんなバカなの真似する必要ない
- 378 名前：デフォルトの名無しさん mailto:sage [2016/01/28(木) 17:53:06.50 ID:M0BYpVOa.net]
- デストラクタで投げるなよ。迷惑な奴だな。
- 379 名前：デフォルトの名無しさん mailto:sage [2016/01/28(木) 18:02:00.92 ID:xwQj4KRs.net]
- javaはファイナライザで発生した例外は握りつぶすことが仕様で決まっているな。
c++の場合は、デストラクタでどうしても例外を外に伝えたかったらやりようはある。
- 380 名前：デフォルトの名無しさん mailto:sage [2016/01/30(土) 01:11:50.31 ID:QZN0GaAw.net]
- そら伝えたかったらやりようはいくらでもあるでしょう？C++に限らず
- 381 名前：デフォルトの名無しさん [2016/02/10(水) 11:29:59.19 ID:lL2Wg2mH.net]
- Javaは強制的に解放させることもできるようにすべきだったな。
- 382 名前：デフォルトの名無しさん mailto:sage [2016/02/10(水) 11:41:46.63 ID:83b7Yxnh.net]
- Java(VM)は(すべてのプラットフォームで)強制的に解放させることもできるようにすべきだったな。
- 383 名前：デフォルトの名無しさん mailto:sage [2016/02/10(水) 12:19:44.29 ID:k9iR7lzz.net]
- 都度メモリ管理するよか、GCに任せた方がスループット的に有利な場合も多いでしょ。
- 384 名前：デフォルトの名無しさん mailto:sage [2016/02/10(水) 14:29:59.29 ID:CcpqYYAq.net]
- GCはメモリ管理に関しては成功してる、
でも、メモリブロックをオブジェクトに昇格させたにも関わらず、相変わらず「メモリ管理」だから失敗。
- 385 名前：デフォルトの名無しさん mailto:sage [2016/02/10(水) 17:29:46.71 ID:+sMp0qjD.net]
- そうそう、メインメモリの管理に関しては100%成功している
しかし、今やメインメモリはそれほど貴重なものではないわけだがな
コンシューマでも数十GB積んでたりは珍しくない
メインメモリがなくなるより他のリソースが枯渇する方が現実的
だからメインメモリ以外のリソースに関しては使い終わったら即座に開放してほしいから
GCとは別にRAIIを行う仕組みを導入するわけだが
真剣に考えていくと、RAIIはGCと相性が悪い
そもそも使い終わったら自動で即座に開放(RAII)できるなら全てのGCはそう実装すべきで
それが出来ないからわざわざコストのかかるマークスイープを遅延して実行しているわけだからな
C++みたいにGCを参照カウンタ方式にして、プログラマが人力で循環参照が無いことを保証する以外に
あちこちから参照されるオブジェクトのRAIIを自動化する方法は無い
- 386 名前：デフォルトの名無しさん mailto:sage [2016/02/10(水) 20:59:51.38 ID:rEABlirv.net]
- JAVAはクソ
- 387 名前：デフォルトの名無しさん mailto:sage [2016/02/10(水) 21:00:45.91 ID:ZQ/yQmxu.net]
- 簡単だよ
スレッド立ててGCをフルサイクル実行し続けるだけ
- 388 名前：デフォルトの名無しさん mailto:sage [2016/02/11(木) 16:22:39.56 ID:vxbPXQEr.net]
- javaもsandy-bridge以降でSSDとかならそれほど重いってわけじゃないけど
相変わらずatomでeMMCだったりする環境も並行して存在してて
そこで動かすと改めて糞だと思うわけよ
GCが悪いんじゃなくてjavaランタイムが悪いんだろうけどね
- 389 名前：デフォルトの名無しさん mailto:sage [2016/02/11(木) 19:04:56.18 ID:EuRhj+pR.net]
- フラッシュとJAVAは、システムに見つかり次第、速攻アンインストールしている
- 390 名前：デフォルトの名無しさん mailto:sage [2016/02/12(金) 08:32:20.35 ID:Uwfak+5B.net]
- >>377
Pythonみたいに参照カウント+GC（循環参照を解放するため）が最強ってこと？
- 391 名前：デフォルトの名無しさん mailto:sage [2016/02/13(土) 15:34:22.04 ID:OKKAbu21.net]
- 最近のPC環境でも贅沢が過ぎるプログラムは動かん。
最近の奴だと、Node.jsのパッケージマネージャnpmが`npm search`と初回に打つとパッケージ検索用のインデックスを作ろうとするんだけど、
1つのjsonオブジェクトにまとめようとするからかOOMエラーを吐いて失敗するっていう不具合。
npmに登録されてるパッケージ数が膨大になったせいもあるが、設計を間違えると遅いどころか動かなくなる。
- 392 名前：デフォルトの名無しさん mailto:sage [2016/02/13(土) 22:32:48.48 ID:6Xm9VASh.net]
- GCがある言語でRAIIみたいな事したいのなら
loan patten使えばいいだけでは
- 393 名前：デフォルトの名無しさん mailto:sage [2016/02/13(土) 23:42:47.95 ID:VLo29AwR.net]
- リソースを共有した上で最後の参照が切れた時点で回収してほしい
しかし誰が共有するかもその寿命も実行時までわからない
そういう前時代的なダサい設計をした時の話しなんだろ
Loan Patternはこの状況では役に立たない
- 394 名前：デフォルトの名無しさん mailto:sage [2016/02/14(日) 00:56:38.97 ID:mwiD0ozs.net]
- しかし、言語側は、そういうダサい設計も許さないといけないので
マークスイープ系GC搭載で、循環参照が有っても良いことが前提になっている言語で
「使い終わったら自動で即座に開放」を実現するのは困難
そんなことが可能なら、マークスイープは要らないからな
- 395 名前：デフォルトの名無しさん mailto:sage [2016/02/14(日) 19:42:04.72 ID:I7Qc+kxz.net]
- 循環参照なんて放置すればいいの
どうせプロセスが終了すればOSが開放してくれるの
- 396 名前：デフォルトの名無しさん [2016/02/14(日) 20:10:25.23 ID:EqhxGdNa.net]
- >>387
Windowsのように定期的に再起動しなければいけないソフトウェアができあがっちゃいそう
- 397 名前：デフォルトの名無しさん mailto:sage [2016/02/15(月) 18:16:17.47 ID:TvNTryet.net]
- ErlangでOS作るか
- 398 名前：デフォルトの名無しさん [2016/02/15(月) 19:50:44.55 ID:L+A+Kd2h.net]
- そこはRustで
- 399 名前：デフォルトの名無しさん mailto:sage [2016/03/01(火) 15:00:17.89 ID:QERDe7Jh.net]
- 5分でわかるガベージコレクションの仕組み
https://geechs-magazine.com/tag/tech/20160229
- 400 名前：デフォルトの名無しさん [2016/03/23(水) 02:31:06.32 ID:MFzvJNSi.net]
- 常識的に考えてカーネルの実装にはGCなんて使えないし
業務アプリケーションではパフォーマンスより開発速度がはるかに重要になる
結局適材適所だ
GCを強制されるのは苦痛だが使えないのも苦痛だ
好きな時に使える言語がいいよね！
- 401 名前：デフォルトの名無しさん mailto:sage [2016/03/23(水) 03:41:39.64 ID:SoMbpeP6.net]
- パフォーマンスが問題にならないGCが一つだけあって、それが参照カウンタ方式のGC
パフォーマンスが問題にならない→即座に逐一削除できる→RAIIが出来る
非常に強力だがプログラマが循環参照が無いことを保証しなければならない
しかし、循環参照が発生する場合は設計段階で分かるのでそれほど深刻では無いのだ！
- 402 名前：デフォルトの名無しさん mailto:sage [2016/03/23(水) 03:47:03.14 ID:VzK80P8k.net]
- androidでもう何も判らん状態でプログラミングして
それなりに動くのができたからおれは許したよ
でもサービスまで勝手に回収されちゃうとは思わなかったわ
アホだろグーグル
- 403 名前：デフォルトの名無しさん mailto:sage [2016/03/23(水) 07:53:14.58 ID:JT2FURwc.net]
- RAIIに必要なのはデストラクタが呼ばれることであって実際にメモリが解放されることじゃないから
GC言語でもRAIIができないわけじゃない。
- 404 名前：デフォルトの名無しさん mailto:sage [2016/03/23(水) 10:07:19.06 ID:SB04Y3rp.net]
- RAIIに必要なのは適切なタイミングで確実に解放処理が呼ばれることであって
いつ呼ばれるかわからないデストラクタではだめ
- 405 名前：デフォルトの名無しさん mailto:sage [2016/03/23(水) 18:24:05.29 ID:jWiL+V+6.net]
- かつてStandard MLの実装で、GCじゃないメモリ管理方法をやってみたのがあったな。
コンパイラが全部自動でやるからコードの見た目はSMLなんだけど、いざ動かすとGCより遅かった。
ある程度プログラマがリソース管理のためのヒントを与えないと、GCを捨てられない。
- 406 名前：デフォルトの名無しさん mailto:sage [2016/03/23(水) 20:05:29.02 ID:JT2FURwc.net]
- >>396
おまえが言っているのはファイナライザ。
それと、デストラクタはメモリの解放なんかしないよ。デストラクトするだけ。
- 407 名前：デフォルトの名無しさん mailto:sage [2016/03/23(水) 21:43:30.89 ID:SoMbpeP6.net]
- この際、呼び名はどうでも良い
参照カウンタ方式以外のGCでは、どこからも参照されなくなったことが、即座にはわからない
だから、自動で即座に開放関数を呼び出すことが出来ない→RAIIが出来ない
C#で言うところのusingみたいに、プログラマが手動で情報を与えるなら出来る
だが、usingはGCでは無い
- 408 名前：デフォルトの名無しさん mailto:sage [2016/03/24(木) 00:53:54.57 ID:smGLwjga.net]
- いまさら、ゲームキューブ叩いてどうするんだ？
- 409 名前：デフォルトの名無しさん [2016/03/26(土) 05:40:22.28 ID:vD3g1idC.net]
- >>393
間違い
マークスイープのように負荷が集中しないだけでありパフォーマンスへの影響はある
特にツリー状のデータついてルートが削除された時子要素もデクリメントする必要があるため負荷が大きい
カウンタはオブジェクト毎に持つためコピーオンライトとの相性が悪い
また言語の機能として実装されなければ明示的に行う必要がある（例えばCとか）
そのためgcない言語ではマークスイープと比べ非常に面倒なことになる
- 410 名前：デフォルトの名無しさん mailto:sage [2016/03/26(土) 10:35:48.15 ID:GKwGPSgf.net]
- androidで原因不明のフリーズが発生、プロジェクトはデスマーチに突入した
これだからGCは
- 411 名前：デフォルトの名無しさん mailto:sage [2016/03/26(土) 11:39:27.66 ID:drxQ1xsy.net]
- これだからGCに頼りきった未熟者は
- 412 名前：デフォルトの名無しさん mailto:sage [2016/03/26(土) 11:39:40.83 ID:MgEq8J/o.net]
- >>401
そりゃどんなものだって多少の負荷は有るよ
しかし参照カウンタの上げ下げの負荷なんか
マークスイープに比べれば無いも同然
- 413 名前：デフォルトの名無しさん mailto:sage [2016/03/26(土) 18:02:09.56 ID:2IjmMYr5.net]
- マルチスレッド環境だと参照カウンタとかいうクソアルゴリズムは使い物にならない
- 414 名前：デフォルトの名無しさん mailto:sage [2016/03/26(土) 18:52:26.07 ID:QL60ocAy.net]
- 参照カウンタがオーバーフローしたらどうなんの？
- 415 名前：デフォルトの名無しさん mailto:sage [2016/03/26(土) 19:10:36.57 ID:nXtJgRqN.net]
- >>405
SSOのが遅いだろ
>>406
size_t にしとけばオーバーフローしない
- 416 名前：デフォルトの名無しさん mailto:sage [2016/03/26(土) 19:44:45.11 ID:R9brpoqy.net]
- >>406
殿堂入りさせて、回収しない
- 417 名前：デフォルトの名無しさん mailto:sage [2016/03/26(土) 20:22:44.37 ID:QL60ocAy.net]
- >>407
確かに現実的にオーバーフローしないと言えると思うけど
STLとかもそういう実装になってる？
- 418 名前：デフォルトの名無しさん mailto:sage [2016/03/26(土) 20:52:01.21 ID:rTAUpSul.net]
- 使う側は少なくとも１つのポインタを持たなくちゃいけないんだからオーバーフローし得ないだろ
- 419 名前：デフォルトの名無しさん mailto:sage [2016/03/26(土) 22:10:23.58 ID:6zuFQelp.net]
- マルチスレッドでGCスレッド立ち上げて、再配置起こる可能性のある普通のGCだと、オブジェクト毎にLock,Unlockできる何らかの機構が必要だし、参照カウンタ増減するより高頻度でその機構使うよね。
- 420 名前：デフォルトの名無しさん mailto:sage [2016/03/26(土) 22:34:25.82 ID:2IjmMYr5.net]
- そうでもない
- 421 名前：デフォルトの名無しさん mailto:sage [2016/03/26(土) 23:56:59.65 ID:MgEq8J/o.net]
- 例えばWindowsだとInterlocked系のAPIを使えば
マルチスレッドでも安全に参照カウンタを増減できるから
パフォーマンスは何の問題もない
- 422 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 00:13:33.76 ID:MdJCnp0Y.net]
- C#なら参照のコピーはただのワード代入で済む
メモリ確保もポインタへの加算だけで済むから圧倒的に速い
回収もマルチスレッドで処理されるから圧縮フェーズ以外はUIへの影響もなくユーザ目線では実質コストゼロ
良いコードを書いてるなら圧縮もたまにしか起こらないし起こっても大した事ない
- 423 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 00:26:17.07 ID:vj+h39OC.net]
- >>399からの流れを見ればわかるがそういう話ではない
参照カウンタ方式以外のGCは、オブジェクトがどこからも参照されなくなったことが「即座」にわからない
だからRAIIが出来ない、そういう話
もちろん、参照の値が書き換わるたびに毎回マークスイープを実行すれば
即座にゴミが分かるがのでRAII出来るが、マークスイープは重いので参照が書き換わるたびに毎回実行できない
その意味で、循環参照以外のGCは重いと言っている
参照カウンタ方式は軽いので毎回実行できる
即座にゴミが分かるからRAIIが出来る
参照カウンタ方式で問題になるのは循環参照が起こった場合だが
循環参照が発生する箇所は設計段階で分かるので、実際には大した問題ではない
C++であれば、片方をweak_ptrにすればよいというだけの話
そこさえ気を付ければ、参照カウンタ方式とデストラクタの組み合わせは非常にうまく機能する
IDisposableのようなものも要らない
- 424 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 00:27:10.73 ID:vj+h39OC.net]
- >循環参照以外のGCは重いと言っている
↑間違えた
参照カウンタ方式以外のGCは重いと言っている
- 425 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 00:41:23.52 ID:15KjVKPo.net]
- >>413
安全が何で保証されてるのかを知るためにアセンブラを勉強しなさい。
その上で「パフォーマンスは何の問題もない」かどうかを語りなさい。
- 426 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 00:59:17.81 ID:kBj57j3O.net]
- 前にも書いたが、RAIIとGCは直接の関係はないよ。
現にC++/CLIでは、ローカルスコープのオブジェクトがスコープを抜けた時点、あるいは
gcnewで作成されたオブジェクトがdeleteされた時点で即座にデストラクタが実行されて
メモリの回収自体はGCで行われる。
- 427 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 01:02:24.98 ID:MdJCnp0Y.net]
- >>415
そもそも不可視のコードでリソースを解放するのが愚行そのもの
プログラマとしての良識があるならusingを使いなさい
RAIIなどというくだらないバッドノウハウはC#では必要ない
- 428 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 01:31:49.74 ID:vj+h39OC.net]
- >ローカルスコープのオブジェクトがスコープを抜けた時点、あるいは
>gcnewで作成されたオブジェクトがdeleteされた時点で即座にデストラクタが実行されて
>メモリの回収自体はGCで行われる。
それはGC関係ないRAIIの話だろ
C#でもusing使えばRAII出来るが
usingも、ローカル変数も、deleteも、何れもGCじゃない
手動で寿命管理しているに過ぎない
寿命管理を自動化(GC)しつつ、RAIIを実現する話をしているわけだが
どんな場合でも、GCで有ろうが無かろうが、手動でデストラクタなりファイナライザなり呼び出せば
RAII出来るに決まっているだろ、それに何の意味が有るんだよ
自動化の話だよ
- 429 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 01:33:16.88 ID:vj+h39OC.net]
- >そもそも不可視のコードでリソースを解放するのが愚行そのもの
その最たるものが、マークスイープ系GCなわけですが
いつ実行されるかすら分からない
まさに不可視
- 430 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 01:51:43.15 ID:vj+h39OC.net]
- 極端な話
mallocして使い終わったらfreeして
はい、手動でRAII出来ました！って主張
それ何の意味が有る話なの？ってね
- 431 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 07:41:27.84 ID:kBj57j3O.net]
- >>420
>それはGC関係ないRAIIの話だろ
メモリはGCで回収されると書いたが？あと、そもそもRAII自体がGCと直接関係ないとも書いた。
>usingも、ローカル変数も、deleteも、何れもGCじゃない
いずれもメモリ領域はGCで回収される。
>どんな場合でも、GCで有ろうが無かろうが、手動でデストラクタなりファイナライザなり呼び出せば
>RAII出来るに決まっているだろ、それに何の意味が有るんだよ
ローカルスコープに置いたオブジェクトは手動で呼ぶ必要はない。
gcnewで作成したものにはdeleteを使うってのは普通のC++と同じだ。
ローカルスコープの変数を基点に、スコープを抜けたときに連鎖的にデストラクタが呼ばれて
delete等の後始末がされるってのがRAIIだからな。
普通のC++ではそのdeleteのときにoperator deleteでメモリ領域が解放されるが、C++/CLIでは
GCで回収されるというだけ。
「GCで有ろうが無かろうが」「RAII出来るに決まっている」ということを理解したならまぁそれでいい。
できないってのを否定しただけで、別に意味があるかないかを話していたわけじゃないからな。
要は、GCを使う多くの言語でRAIIができないのはデストラクタの仕組みを持っていないからであって、
それがあるC++/CLIならRAIIも可能ということ。逆にGCを使わない言語でも、デストラクタがなければ
RAIIは不可能。
つまり最初の結論、RAIIとGCの有無に直接の関係はない。
- 432 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 10:01:03.80 ID:MdJCnp0Y.net]
- メモリとその他のリソースを混同して考えるからダメ
まずその他のリソースは不可視のコードで解放しちゃダメ
リソースのスコープは明示的でなければならない
これはデストラクタにもGCにも任せられない
逆にメモリは不可視のコードで解放してもよい
まずこの基本原則から話を進めよう
- 433 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 10:12:42.93 ID:Ap0rkncx.net]
- schemeにはdynamic-windみたいな他所に継続が飛んでも後処理が保証される仕掛けがあるし
デストラクタがない==RAIIできないにはならないと思うの・・・
- 434 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 11:03:59.82 ID:+zMq83Ww.net]
- >>424
んな事はない。
あらゆるリソースの寿命はライブラリでデフォルトの管理がされるべきであり、使用者の完全性を前提にすべきではない。
- 435 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 11:16:32.31 ID:MdJCnp0Y.net]
- >>426
銀の弾丸は無い
あらゆるリソースのあらゆる利用形態に対してデフォルトの動作を定義できるなら話は別だが無理だよね
結局は人が方針を決めて書くしか無い
幸いにしてメインメモリにはRAIIやマークスイープという正解が見つかっているのでそれを使えばいい
だが他のリソースはダメだ
- 436 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 16:21:42.54 ID:vj+h39OC.net]
- >>423
そんな基本的なことを言って何がしたいの？
RAIIとGCは密接な関係が有るんだよ
君はローカル変数が好きみたいだから、ローカル変数の事例で説明するとする
(嫌ならC#のusingと読み替えてもらっても構わない)
ローカルに確保したオブジェクトが、メンバ変数に他のオブジェクトを持っていたとする
いわゆるコンポジションの状態、よくある話
C++で言えば、class my_class{ object *obj; }; といった感じのクラスになる、分かるよね？
で、ローカル変数はスコープを抜けたら解放される、usingも似たようなもの、これはRAIIの基本、良いね？
このとき、マークスイープ系GCだと、my_classのobｊに他からの参照が有るかどうか、即座にわからないので
objを開放してよいのか判断が付かない→my_classは破棄されてもobjはGC発動まで保留される→objは残るのでRAIIの意味がない
もしくは、my_classのobjに他からの参照が全く無いことをプログラマが保証して
my_classの開放部にobjをdeleteなりdisposeなりするコードを記入する
しかしこれは、objの所有権がはっきりしていないことには使えない上に、「手動」である
C++の場合はスマポが有るのでまだましだが、C#のDisposeは完全に手動で呼ばなければならない
自身のメンバにIDisposableなメンバいたら、自身もIDisposableにしなければならず、Disposeメソッドを実装して
自身のメンバのDisposeを芋づる式に呼び出すコードを手動で書かなければならない
mallocしたらfreeしましょうと一緒で、C言語レベルの全くの手動になってしまう
参照カウンタ方式のGCではこれらの問題は発生しない
他からの参照が有るか無いかは即座にわかるし、参照カウンタが0になれば、その場で即座に破棄される
自身のメンバに対して、デストラクタは芋づる式に呼び出されるので、C#のDispose実装のような面倒さは無い
>>424
お前言ってること無茶苦茶すぎるだろ
>リソースのスコープは明示的でなければならない、デストラクタにもGCにも任せられない
GCはともかく、デストラクタでもダメって意味不明すぎるんだが
考えの根本がおかしい
- 437 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 16:43:31.54 ID:vj+h39OC.net]
- C++で書けば
struct A{ *obj };
void func()
{
A a;
}
こういったRAIIの場合のobjの開放はどういう扱いにするんだって話
aが完全にobjを所有しているケースなら、Aのデストラクタにdelete obj;とでも書くかscoped_ptrでも使えばよい
しかし、objが彼方此方から参照されている可能性もあるので
そこんとこコンパイラは判断が付かないので、自動化はきない
あくまで、プログラマが保証する形になる
C#のDisposeのような仕組みを言語側で用意したところで、自身のメンバにIDisposableなメンバが有るかどうか
いちいち調べなきゃならなないし、調べ忘れや呼び出し忘れをするという問題が出てくる
しかも、所有権が単一である場合にしか成り立たない
一方でマークスイープ系GCに任せっぱなしにすると、objの開放はGC発動まで遅延してしまうだろう
参照カウンタはこれらの問題をすべて解決する
参照数はどのタイミングでも直ぐに分かるし、0になれば遅延なしで即座に削除される
デストラクタは自身のメンバに対して芋づる式に自動で呼び出されるので
スマポを使っておけば呼び出し忘れるということもないし
Disposeのような冗長なコードを書く必要もない
- 438 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 16:44:43.86 ID:vj+h39OC.net]
- 訂正
struct A{ *obj };
void func()
{
A a;
}
↓
struct A{ object *obj };
void func()
{
A a;
}
- 439 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 17:07:08.54 ID:vj+h39OC.net]
- 結局、C#のDisposeはどこまで行ってもどんなに進化しても手動で書かなければならない
自身のDisposeが呼ばれたからと言って、自身のメンバ変数のDisposeを芋づる式に勝手に呼び出して良いかは
コンパイラにはまったく判断が付かない
他からも参照されていて今まさに使われている可能性がある以上
コンパイラが勝手に自動でDisposeを呼び出すコードを生成することはできない
GCを発動してみるまでは、どこからも参照されなくなったことが保証できない
しかし、GCの発動まで開放が遅延しても良いのであれば、そもそもDisposeは要らないわけで
Disposeの実行はGC発動より先行していなければならず、GCに頼れないということになる
なので、自身のDisposeが呼ばれたときに、自身のメンバのDisposeをしてよいかは
プログラマが考え、手動で呼び出す必要が有る
所有権が単一であれば、手動でメンバのDisposeを呼び出せばよい
手動で記述しなければならないので面倒くさいし、ミスの元ではあるが、一応できる
所有権が複数であれば参照カウンタを使うしか現実的な方法は無いだろう
マークスイープ系GCなのに参照カウンタで独自に管理するのは馬鹿げているがな
参照カウンタ方式＋デストラクタ
であればこれらの問題は一切発生しない
参照カウンタが0になったことは即座にわかるし、デストラクタはメンバ変数に対して芋づる式に呼び出されるので
開放に関しての特別なコードを手動で書く必要は無い
開放処理も一本化される
- 440 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 17:16:20.56 ID:UGnRhUEw.net]
- 長文は漏れなく基地外
- 441 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 17:17:01.33 ID:MdJCnp0Y.net]
- >>428
バカすぎる
細かい事気にせずデストラクタで解放すりゃそれでおkって感じの適当な現場でしか働いた事無いんだろうな
- 442 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 17:22:53.59 ID:/D0vdPDd.net]
- ポインタがメンバ変数になってたら公開しちゃいかんでしょ
- 443 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 17:24:21.54 ID:MdJCnp0Y.net]
- まずDisposeは生成できる
めんどくさいという奴は知識が無いだけ
リソースを共有する事は少ない
というか設計段階で可能な限り少なくする
そして共有するならするでしっかり管理して自動解放などという手抜きはしない
基本中の基本だ
- 444 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 17:32:09.52 ID:+zMq83Ww.net]
- デストラクタで解放してはいけないリソースをデストラクタで解放しなければいいだけで、デストラクタで解放すればいいリソースはデストラクタで自動的に解放すべき。
- 445 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 20:12:26.78 ID:kBj57j3O.net]
- >参照カウンタ方式＋デストラクタ
>であればこれらの問題は一切発生しない
.NETのマーク&スイープGCの上でRAIIを実現している実例としてC++/CLIを説明したんだが、
「基本的なこと」とか言いながら結局何も理解してないんだな。
そもそもRAIIの話で所有権が共有されたオブジェクトを持ち出すのが意味不明すぎる。
>参照カウンタが0になったことは即座にわかるし、
「いつか」全員が所有権を手放したら「即座に」破棄される
「いつか」全員が所有権を手放したら「いつか」GCで破棄される
どう違うというのか。
- 446 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 20:35:08.73 ID:Ng/EIIMI.net]
- RAII信者の痛さは異常
オブジェクトをコピーされたら破綻するのに
- 447 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 21:10:56.38 ID:N7IGtcj3.net]
- グローバルインスタンスホルダーは明確にインスタンスの状態を把握したいときに積極的に使うべき
- 448 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 22:32:53.86 ID:vj+h39OC.net]
- >「いつか」全員が所有権を手放したら「即座に」破棄される
>「いつか」全員が所有権を手放したら「いつか」GCで破棄される
>どう違うというのか。
少なくとも最善が尽くされるという意味で違うし
同じデータと同じプログラムで有れば、常に同じタイミングで開放処理が走るという再現性が有る
それから、自分しか所有権を持っていない場合、つまり参照数が常に1というシンプルな状況ですら
参照カウンタ方式の方が開放処理が自動化されて楽
参照カウンタ方式で有れば、スマポを使っておけば済む
scoped_ptrでも良い
マークスイープ系GCであれば、自身しか所有権を持たない単純な場合でも
非常に面倒なことになる
自身にDisposeを実装して自身のメンバのDisposeを呼び出すコードを手動で書かなければならない
何故こういったコードをコンパイラが自動生成できず、手動で書かなければならないのかの根底に
まさにマークスイープGCの存在が有る
マークスイープ系GCは何処からも参照されなくなったことがその場ですぐに分からない
GCを発動してみるまで保証することが出来ない
自分のDisposeが呼び出された、まさにその瞬間に、自分のメンバに対してもDisposeしてよいのかどうなのか
参照数がリアルタイムで即座に分からないので判断する材料が何も無く
コンパイラはC++のデストラクタのように自動で芋づる式に開放処理を呼び出すコードを生成することが出来ない
要するにマークスイープ系GCではDisposeのコンパイラによる自動生成が出来ないという大きなマイナスが有る
- 449 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 22:36:05.37 ID:15KjVKPo.net]
- >>438
しねーよ
- 450 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 22:41:25.16 ID:VNvh7E4d.net]
- >>440
子要素をDisposeしていいかどうかもわからないってそりゃ設計サボってる以外のなんでもないだろう
ちゃんと設計してればいつ削除してよいかなんてわかるはずだろ
まともに設計もできないレガシーエンジニアは黙っててよ
設計に時間使わないとリソース云々以前に別のバグだらけになるぞ
- 451 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 23:42:37.04 ID:Ng/EIIMI.net]
- RAII信者は頭が悪いな
- 452 名前：デフォルトの名無しさん mailto:sage [2016/03/27(日) 23:59:39.99 ID:15KjVKPo.net]
- >>443
自分の頭を検証しな
- 453 名前：デフォルトの名無しさん mailto:sage [2016/03/28(月) 00:10:58.97 ID:h9yZCrPP.net]
- メンバにDispose持たせる設計って大抵ダメだよね
- 454 名前：デフォルトの名無しさん mailto:sage [2016/03/28(月) 00:20:40.85 ID:j/beyn8U.net]
- >>440
前者(参照カウントGC)はRAIIができるが後者(マーク&スイープGC)ではできないというお前の
主張について言っているんだが？
「最善が尽くされる」からRAIIができて、尽くされないからRAIIができないとでも言うのだろうかｗ
>要するにマークスイープ系GCではDisposeのコンパイラによる自動生成が出来ないという大きなマイナスが有る
何度も例に挙げているC++/CLIでは、デストラクタを記述するとコンパイラによってDisposeが追加される。
そして、ローカルスコープに置いたオブジェクトに対してはスコープを抜ける際に自動的にdeleteが呼ばれる。
そこからdelete→Dispose→デストラクタと呼び出される。RAIIに必要なものは揃っているし、事実、可能だ。
もちろん、そのメモリ領域は別のタイミングでGCによって回収される。
ここまで説明しても理解できない低脳ならしょうがない。
やはりデストラクタとファイナライザの違いが理解できてないようだからそこから勉強しなおせ。
- 455 名前：デフォルトの名無しさん mailto:sage [2016/03/28(月) 00:39:52.48 ID:2h3yopdG.net]
- {
std::shared_ptr<my_namespace::my_class> p(new my_namespace::my_class(...));
/* unko_code */
}
using(var obj = new MyClass(...)) {
/* GoodCode */
}
美しいという事はいい事だね
C#は書いてある事がシンタックス的にもセマンティック的にも明確だ
リソース管理はこうでなければならない
- 456 名前：デフォルトの名無しさん mailto:sage [2016/03/28(月) 01:22:52.25 ID:khgTmo3F.net]
- >>447
C++にもusing使えやw いらない波括弧外せやw
- 457 名前：デフォルトの名無しさん mailto:sage [2016/03/28(月) 03:34:15.37 ID:d3YBhLBG.net]
- >>447
usingの方が全然明確だね
objがコピーされてても問題ない
RAII脳ではわからないんだろう
- 458 名前：デフォルトの名無しさん mailto:sage [2016/03/28(月) 03:36:11.96 ID:d3YBhLBG.net]
- schemeに何十年も前から存在するwith-xxxx 系を一般化した構文だね
- 459 名前：デフォルトの名無しさん mailto:sage [2016/03/29(火) 01:23:53.57 ID:Qm5oX8hY.net]
- アレを更にtypedefされたりされると
ワケワカランくなるよな
- 460 名前：デフォルトの名無しさん mailto:sage [2016/03/29(火) 01:50:13.51 ID:40IzaG0J.net]
- c++なら普通こうだな
{
my_class obj(...);
...
}
そういやc#でp.release()相当の事って簡単にできるの？
{
auto p(make_unique<my_class>(...));
...
}
nullって代入可能？
- 461 名前：デフォルトの名無しさん mailto:sage [2016/04/04(月) 02:47:24.69 ID:+1V6ohqL.net]
- GCがあるのになぜJavaはメモリリークしまくるソフトウェアを量産するのか
- 462 名前：デフォルトの名無しさん mailto:sage [2016/04/04(月) 02:55:18.29 ID:FhdBY7IF.net]
- >>453
Javaだから
- 463 名前：デフォルトの名無しさん mailto:sage [2016/04/12(火) 23:15:42.48 ID:ZWvwh7J9.net]
- Rust使えばいいのさ
- 464 名前：デフォルトの名無しさん mailto:sage [2016/04/13(水) 10:33:47.16 ID:+hJ3fPVS.net]
- >>455
会社にいるよな、そういうやつ
- 465 名前：デフォルトの名無しさん mailto:sage [2016/04/13(水) 15:29:31.16 ID:oOcEPJTu.net]
- GC大好きっ子に聞きたいんだが
完璧な（理想的な）GCを搭載したメジャーな言語処理系って何があるの？
これで開発すればリークも管理も気にしないでOKってやつ
- 466 名前：デフォルトの名無しさん mailto:sage [2016/04/13(水) 16:22:35.14 ID:s5MRiDQ8.net]
- 無い
マークスイープ系GC → 循環参照OK、しかし即座に開放されない
参照カウンタGC → 即座に開放される、しかし循環参照NG
ということで、理想のGCは無い
全てのGCは何かを妥協している
それから、たとえGCを使ったとしても
要らなくなったオブジェクトの参照をいつまでも握っている奴が居たら解放されないから
リソースの管理をしなくてよいということは無い
あと、GCは基本的にメインメモリに対してしか有効に機能しないから
例えばファイルオブジェクトなんかは要らなくなったら即座にcloseするなりすべきで
リソース管理フリーというわけにはいかない
- 467 名前：デフォルトの名無しさん mailto:sage [2016/04/13(水) 16:54:16.68 ID:s5MRiDQ8.net]
- つまりは、GCを使っていたとしても
君がオブジェクトを何処かに登録したなら
オブジェクトが要らなくなったら登録解除してあげないと
そのオブジェクトは解放されないのだ
これはちょうどmallocしたらfreeしましょうに似ていて
GCを使ったとしても全てのリソースの管理が自動になるわけではないということだね
究
- 468 名前：極的にはGCの利点は自分でfree/deleteをしなくても良いところにある
これはつまり、ダングリングポインタが発生しないということだ [] - [ここ壊れてます]
- 469 名前：デフォルトの名無しさん mailto:sage [2016/04/14(木) 20:54:37.84 ID:f1hhftJp.net]
- >>457
C+BoehmGC
- 470 名前：デフォルトの名無しさん [2016/04/17(日) 16:17:55.58 ID:j/f/oFPY.net]
- そして無視されてしまうコピーGC君
GCの利点は自分で大量にメモリの確保＆解放するプログラムにおいてバグが出にくくスループットも出るってところだと思う
もしheapをそんなに頻繁に確保＆解放しないんだったらGCない言語の方がいい
ただ近代的な言語は少数の例外を除いて大抵GC積んでるけど
- 471 名前：デフォルトの名無しさん [2016/04/17(日) 16:21:44.96 ID:j/f/oFPY.net]
- ＞リソース管理フリーというわけにはいかない
リソース管理フリーについてはrustみたいなGCない言語のほうが達成できてるよね（あとは関数型言語か）
でもrustでもリソースの解放時にエラーを吐く可能性がある処理なら自分で解放する処理書かなきゃいけないっぽいけど
- 472 名前：デフォルトの名無しさん mailto:sage [2016/04/17(日) 18:35:17.89 ID:SAR9JCaP.net]
- RAIIでも結局どのタイミングで解放されるか意識しなくてもいいってわけじゃないし
リソース解放処理を書かなくていいだけで
- 473 名前：デフォルトの名無しさん mailto:sage [2016/04/17(日) 18:43:59.82 ID:cFoKw8Zx.net]
- メモリ管理系のバグが顕在化しにくいだけで、そこら辺適当なまま中途半端にキャリアを積む開発者を量産するという害悪が大きい。
JNIやらで他のAPI使う必要が出てくると結局いろいろ配慮しなきゃいけなくなるし。
- 474 名前：デフォルトの名無しさん mailto:sage [2016/04/17(日) 19:43:44.44 ID:oNE1M7I6.net]
- >>460
コンサバじゃ完璧にほど遠いぞな
- 475 名前：デフォルトの名無しさん mailto:sage [2016/04/17(日) 19:50:47.36 ID:1R/4ebGS.net]
- >メモリ管理系のバグが顕在化しにくいだけ
結局これだよね
本当に丸投げできるなら乗っかるのもいいと思う
性能問題はハードの進化で一部の用途を除けば問題無くなると思うし
でも現実は中途半端だから意識して書いたほうがマシだと
- 476 名前：デフォルトの名無しさん [2016/04/17(日) 21:19:09.59 ID:IB74e9ph.net]
- ムーブセマンティクスのおかげでずいぶん便利に。
- 477 名前：デフォルトの名無しさん mailto:sage [2016/04/17(日) 23:09:38.99 ID:j/f/oFPY.net]
- あと正確にはGCには含まれないけどメモリコンパクションをやってくれる処理系が多いのも
GCを使う利点になるかも
- 478 名前：デフォルトの名無しさん mailto:sage [2016/04/17(日) 23:17:23.70 ID:cFoKw8Zx.net]
- 今どき意図的にやらない限りメモリフラグメンテーションで困るような場面があるか？
アドレス空間も余裕出てきたし、多少おかしな確保パターンで浪費してもGCほど実メモリを食わないし。
今どき主流のサイズ毎に空きを管理するmallocは優秀だしね。
これがダメならlinuxカーネルとか先に落ちちゃうぞ。
- 479 名前：デフォルトの名無しさん [2016/04/18(月) 15:56:44.18 ID:kcE0qDSU.net]
- >>469
昔、C/C++を駆使して日本が誇るスパコン京に投入するタスクセットを書き上げたのだが
実行するとどうも性能が出ない。
色々調べた結果、どうやらメモリーが断片化していることが分かった。
そこで多大な投資を行いJavaで書き直したらなんと100倍も性能が上がったのです！
これが>>468さんの経験してきたことなんです。
- 480 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 16:30:17.23 ID:BDPQ12Es.net]
- 自前のメモリ管理が超下手くそなだけやろ
修業して出直してこいや
- 481 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 16:37:09.21 ID:OvHIqTOi.net]
- 自慢になってないような
- 482 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 16:44:52.62 ID:9yQABY6F.net]
- ゲームだとフラグメント問題になること多いよ
ゲーム専用機なら特に
最近は特にオープンワールドが当たり前になってるけど
あれストリーミングでどんどんメモリ置き換えていくしね
- 483 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 16:47:31.98 ID:/wa5LIj
]
- [ここ壊れてます]
- 484 名前：H.net mailto: jemallocのようなモダンなmalloc実装使えば良かったのでは。 []
- [ここ壊れてます]
- 485 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 17:47:00.91 ID:IBBVu28x.net]
- ゲーム専用機でフラグメンテーションおこすとか開発者としての適性を疑われても不思議ではない。
オブジェクトの寿命管理すらしないのか？
- 486 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 18:51:08.61 ID:RPQ9NKJO.net]
- メモリのフラグメンテーションをC/C++でコントロールする方法ってあるの？
mallocの実装頼りじゃなく。
- 487 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 19:05:27.63 ID:OvHIqTOi.net]
- mallocの挙動がわかってれば、ある程度は・・・・
- 488 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 19:14:30.71 ID:OvHIqTOi.net]
- 細かくメモリ要求するから、下回りで時間がかかる
メモリ分断されてもオンメモリでの検索はさほど時間がかからない
（空きができても、そこに入らないときに）
- 489 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 19:15:14.97 ID:9yQABY6F.net]
- >>475
フラグメンテーションって何かわかってないでしょ？
寿命管理だけでは解決できないよ
- 490 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 19:21:39.69 ID:IBBVu28x.net]
- 寿命管理で解決できないとか、フラグメンテーションがどういう現象か分かっているの？
汎用の寿命管理APIみたいなのを使うとか言うのと勘違いでもしている？
- 491 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 20:02:22.75 ID:3yZKjOEp.net]
- >>480
おいおい・・
この場合寿命を管理できないってのはgiven conditionとして考えないと
そりゃ寿命があらかじめわかってるなら苦労しないっての
大規模なプログラムでそんな恵まれた状況は例外的だよ
- 492 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 20:57:42.92 ID:IBBVu28x.net]
- 専用ゲーム機上のゲームだよ。
リソースが逼迫したら何を優先するかの戦略も含めてほぼ理想的なgiven conditionだろうに。
ユーザーの行動による不確定性も全てコントロール下にあるだろうに。
- 493 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 21:13:59.16 ID:RPQ9NKJO.net]
- >>482 専用ゲーム機と普通のPCの1アプリケーションとで何が違うのか。mallocも使わないってこと？
NoGC, 各GCでメモリ空間がどう使われるかを視覚化
ttps://spin.atomicobject.com/2014/09/03/visualizing-garbage-collection-algorithms/
黒: 未使用
灰: 確保
緑: 読み込み
黄: 書き込み
赤: GC用のアクセス(参照カウンタ、マーク用ビットetc)
緑と黄は時間経過で退色していく
メモリフラグメンテーションという観点から見ると、コピー型GCが綺麗。
- 494 名前：デフォルトの名無しさん mailto:sage [2016/04/18(月) 21:15:59.31 ID:3yZKjOEp.net]
- まぁテトリスとかならその程度の理解でいいんじゃない？w
- 495 名前：デフォルトの名無しさん [2016/04/18(月) 21:33:24.92 ID:kcE0qDSU.net]
- Javaの寿命管理APIは最強ですな。
- 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が無いのが面倒すぎるってことなんだけどね
- 597 名前：デフォルトの名無しさん mailto:sage [2016/08/24(水) 20:32:21.12 ID:N/sC1Ga3.net]
- >>580
> 処理を中断する手段が関数側に用意されてなかったりする
具体的には？
- 598 名前：デフォルトの名無しさん mailto:sage [2016/08/24(水) 22:11:21.77 ID:2RMcAgaj.net]
- いやそんなもん、中断する手立てが用意されている方が珍しいだろ
- 599 名前：デフォルトの名無しさん mailto:sage [2016/08/24(水) 22:31:11.60 ID:N/sC1Ga3.net]
- >>586
で、具体的には出せないと言うことね
- 600 名前：デフォルトの名無しさん mailto:sage [2016/08/25(木) 11:39:37.19 ID:rs2QvvZe.net]
- 元々はスレッドが軽量プロセスって呼ばれていたりしたんだがな（アドレス空間の切り替えが不要だからプロセスより切り替えが軽い）
まあそれはおいておいて
forkを使うと軽量プロセス？とやらの機能が実現できるらしい理屈がわからない
forkしたら別プロセスだぞ？
vforkとかなら実行直後は共有しているけど変更を加えた時点で分かれるし
まあどちらにしろGCじゃメモリーをはじめとする資源管理からは完全には解放されないって事だ
- 601 名前：デフォルトの名無しさん mailto:sage [2016/08/25(木) 11:59:23.81 ID:8gaIkILP.net]
- メモリ空間がつながっていること自体はそれほど考慮してないんよ
単にWindowsはマルチプロセスがしにくい
forkあったらちょっとした処理を別プロセスで実行するの、便利じゃん
片づけはプロセスごと殺して終わりだし
- 602 名前：デフォルトの名無しさん mailto:sage [2016/08/25(木) 15:41:54.51 ID:8f3yfXIl.net]
- ほしいのはLinuxでいうclone(2)やね
- 603 名前：デフォルトの名無しさん [2016/09/03(土) 00:41:24.79 ID:XSHFkVCg.net]
- https://cedil.cesa.or.jp/cedil_sessions/view/1484
リアルタイムGCの実装が凄い
- 604 名前：デフォルトの名無しさん mailto:sage [2016/10/22(土) 08:52:04.68 ID:v44cYKg6.net]
- GCもハードウェアに支援させれば全部解決するよ
リアルタイム処理含めてね
- 605 名前：デフォルトの名無しさん mailto:sage [2016/10/22(土) 10:51:46.42 ID:O48rD9qT.net]
- 再起動最強説
- 606 名前：デフォルトの名無しさん [2016/11/14(月) 22:33:26.01 ID:A2iFoZHP.net]
- 固定領域として静的にグローバル変数化、バッファ�
- 607 名前：ｻすればいいだろ、
それを汚い言うやつがいるが、
潜在ＢＵＧだらけでどうにもできないそれのほうが汚いわ。 [] - [ここ壊れてます]
- 608 名前：デフォルトの名無しさん mailto:sage [2016/11/14(月) 23:45:18.91 ID:JD+cxKWX.net]
- 例えばChromeとかFirefoxとかが静的にメモリアロケートしてたらどうなるか
- 609 名前：デフォルトの名無しさん mailto:sage [2016/11/14(月) 23:59:22.37 ID:f4osfHdm.net]
- そういう発想、嫌いじゃないよ
静的にできるものは、なるべく静的にすべし
俺もそう思う
妙なからくりじみたことにはもう興味が湧かなくなった
最初のころはGCのメカニズムが面白いと感じていたが、もうそういうの、無い
いかに静的にシンプルに書くか、こっちのがパズルみたいで面白い
すべての事は明確であるべきで、コードはそのようになっているべきだ、と
俺が特に嫌いなのは、何がどの順番に実行されるか、コードを見ただけで
よくわからない類のプログラムだ
コールバックも基本的に嫌いだ
なのでいつ実行されるか分からないマークスイープGCは好きではない
参照カウンタ方式のほうが根本的に安全であり、シンプルであると思う
というのも参照カウンタ方式のGCはバグの再現性があるから
唯一の問題は循環参照だが、これも弱い参照を使えば解決する
たったそれだけの工夫でマークスイープGCの複雑な仕組みがいらなくなるなら
おれはそちらのほうが良いと考える
開放するというただそれだけのことに、あれだけ巨大な仕組みが必要になるのはおかしい
- 610 名前：デフォルトの名無しさん mailto:sage [2016/11/15(火) 00:00:47.13 ID:PldPJ2O3.net]
- マークスイープ系GCはメモリ管理に関しては完璧かもしれないが
それ以外のリソースの面倒は一切見てくれない
そういったものはファイナライザで開放すればよいわけだが
要らなくなったらすぐさま開放してほしい時に困るので、例えばC#ではDisposeを用意している
しかしながら根本的に本当にDisposeを呼んで良いのかは誰にもわからない部分がある
もしかしたら他の誰かが使用中かもしれない、という場面もありうる
だから誰も使ってないことをプログラマが保証する格好になる
その意味ではfree()と大差ないわけで
usingという構文が用意されていて、ある程度自動で呼ばれるというだけである
本当に誰も使ってないことを保証するにはマークスイープを走らせなければわからない
しかしマークスイープはコストがかかるので、そんな都度都度気軽に走らせられない
その点、参照カウンタ方式は参照カウンタを見るだけで使われているかどうかわかるので
都度都度チェックできるし、要らなくなったらその場で即開放できるので
Disposeのような仕組みもいらず、解放処理をデストラクタに一本化できるし
スマポを使えばデストラクタ自体、書く必要すらないかもしれない
そして有り難いことに、デストラクタはメンバ変数やベースクラスに対しても
芋づる式に自動で呼ばれる
これはDisposeには無い機能だ
何故無いのか？答えは、勝手にDisposeして良いのかどうか、コンパイラは判断がつかないからだ
誰か他の人が使っているかもしれないわけで、勝手にDispose出来ない
Disposeして良いかどうかはプログラマが保証しなければならないので自動化できないのだ
- 611 名前：デフォルトの名無しさん mailto:sage [2016/11/15(火) 00:02:48.22 ID:PldPJ2O3.net]
- 本当にC#で解放処理をまともに書こうと思うと
自身のクラスのメンバ変数にIDisposableを実装しているものがあるかどうかを調べ
もし、実装しているものがあれば、自身もIDisposableにし
Disposeメソッドを作り、その中で、先ほど調べたメンバのDisposeを呼び出さなければならない
これを手作業でやる
C#をやったことのある人なら知っている通り、マイクロソフトの示すIDisposableの実装例自体が
非常に煩雑であるわけだが、ともかく、もれがないように、手作業で頑張る
まず、IDisposableかどうか調べ忘れるだろうし、Disposeの呼び出し忘れもありうる
mallocしたらfreeしましょうと同レベルのことを強いられる
このように面倒なIDisposableであるが
IDisposableなオブジェクトをメンバに持つと、自身もIDisposableになるということは
IDisposableはどんどん伝染していくわけで、手動でDisposeしまくるコードを書き続ける羽目になる
このように、まじめに考えると、破たんした方法であることが分かる
根本の問題はDisposeが自動で呼ばれるコードをコンパイラが生成してくれないこであるが
確実にDisposeして良いかどうかを判断するためにはマークスイープを走らせる必要があるので
どうやっても自動化は困難であり、プログラマが開放してよいことを保証するという
ある種手作業なusingがせいぜいである
参照カウンタ方式であれば、ほぼノーコストで開放して良いかどうか分かるので
これらの問題は一切発生しない
解放処理はデストラクタ一本であるし、芋づる式に自動的に呼ばれるので
手動でコードを書かなければならないということもない
ランタイムもシンプルであり、バグった時も再現性が期待できる
- 612 名前：デフォルトの名無しさん mailto:sage [2016/11/15(火) 00:24:03.03 ID:PldPJ2O3.net]
- これがC++が未だにかたくなにマークスイープ系GCを搭載しない理由である
C++を書くプログラマはweak_ptrを適切に使えるものだという前提のもとに
マークスイープ系GCにまつわる数々の問題点を排除したのだ
マークスイープ系GCで有利なのは唯一循環参照だけであり
そこさえ気を付けることができれば
それ以外の部分に関しては参照カウンタのほうが優れている
C++は別に時代遅れなわけじゃなく、そういう選択をしたというだけ
今になって考えるとその選択は正しかったと思う
- 613 名前：デフォルトの名無しさん mailto:sage [2016/11/15(火) 04:04:15.16 ID:9A/eUvIY.net]
- メンバーにdisposeしなければならないような設計が良くない。そんなものはメソッド内のローカル変数に止めるべき。
それすらも理解できず(考え付かず)にただ一律なんにでも同じ考え方を押し込むのはただの愚行。
ありもしない、回避可能な杞憂をただ恐れるのは、勉強不足か進歩が止まっているだけ。
だから皮肉を込めて老害と呼ばれる
- 614 名前：デフォルトの名無しさん mailto:sage [2016/11/15(火) 04:09:46.64 ID:9A/eUvIY.net]
- 日本語おかしかった。
メンバーにdisposeしなければならないような物を持たせるのが良くない
でした。
- 615 名前：デフォルトの名無しさん mailto:sage [2016/11/15(火) 05:19:19.06 ID:ulUg8AFG.net]
- >>594
参照カウンタよりも固定バッファを動的に確保ですね判ります
- 616 名前：デフォルトの名無しさん mailto:sage [2016/11/15(火) 05:20:35.14 ID:ulUg8AFG.net]
- >>595
firefoxは解放が遅いのでそれやってるのと実質同じ
realplayerとかもそうだったな
- 617 名前：デフォルトの名無しさん mailto:sage [2016/11/15(火) 08:18:37.29 ID:wcWx6QZb.net]
- >>600-601
よくないって言われてそうせざるを得ない場合はいくらでもあるしなぁ
例えば動的に出力先を切り替えられるログクラスみたいな奴をどう書けと言うんだろ？
- 618 名前：デフォルトの名無しさん [2016/11/15(火) 09:05:11.25 ID:P8K+NdWV.net]
- >>597
スマポとデストラクタの必要性は関係ないだろ…
deleteの必要がない、とか、デストラクトを考えなくて良いってことだと思うけど。
- 619 名前：デフォルトの名無しさん mailto:sage [2016/11/15(火) 10:48:15.69 ID:4QSE1fRA.net]
- スタック変数の 0 クリアすら嫌がる C/C++ が GC 搭載とか夢見すぎ
- 620 名前：デフォルトの名無しさん mailto:sage [2016/11/15(火) 10:53:43.30 ID:PldPJ2O3.net]
- struct test
{
std::shared_ptr<int> ptr;
test(){ ptr = new int; }
};
上のコードはデストラクタを書く必要があるのかないのか
スマポを使えばデストラクタを書かなくてよい場合もあり得るということ
スマポを使わないのであれば当然デストラクタでdeleteをしなければならないだろう
なので、「スマポ」と「デストラクタを書く必要性」は、関係がある
ちなみにC#のDisposeはただのメソッドであるので
このような芋づる式にメンバ変数のDisposeを呼び出してくれる機能はないし
マークスイープなので原理上不可能である
他で使用中でないことをプログラマが保証しないとにはDisposeは呼べないので
自動化できない
- 621 名前：デフォルトの名無しさん mailto:sage [2016/11/15(火) 11:05:47.46 ID:TNYjuRyh.net]
- >>606
ツボったw
効率至上が利点であり特徴だもんな
- 622 名前：デフォルトの名無しさん mailto:sage [2016/11/15(火) 12:45:52.53 ID:LZ5unIkv.net]
- >>607
それptr.reset()使うんじゃないの？
- 623 名前：デフォルトの名無しさん mailto:sage [2016/11/15(火) 13:34:38.18 ID:bbRnuBLg.net]
- グローバルが嫌われたのは
疑似マルチプロセスでメモリを共有していた時代の汚物だろ
今みたいなOSのメモリ管理ならアプリ単位グローバル常套
- 624 名前：デフォルトの名無しさん mailto:sage [2016/11/15(火) 23:45:20.82 ID:nDIaGem/.net]
- C#/C++よりRustだろ
参照カウンタのオーバーヘッドすらない
Firefoxに期待
- 625 名前：デフォルトの名無しさん mailto:sage [2016/11/16(水) 04:04:29.47 ID:EhKul/vA.net]
- >>604
ideone.com/9L3kQp
これじゃいかんのか？
おかしかったら教えて
- 626 名前：デフォルトの名無しさん mailto:sage [2016/11/16(水) 12:42:03.97 ID:KQ3Yixih.net]
- >>612
Write する度に WriteTypeA とかを生成/破棄するってこと？
ログとかならその方が望ましいケースもあるかもしれないけど、例えば性能上の問題でストリームは開きっぱなしにしたいとかもあるでしょ
- 627 名前：デフォルトの名無しさん mailto:sage [2016/11/16(水) 14:56:37.10 ID:a2T+Z3SD.net]
- >>613
開きっぱなしにしたいスコープは？
スコープを一つのメソッドにして、同じようにすればいいじゃない
コードが必要なら夜にでも書くよ
- 628 名前：デフォルトの名無しさん mailto:sage [2016/11/16(水) 19:17:42.21 ID:KQ3Yixih.net]
- >>614
スコープを動的に変えたい場合を想定してるんだが
実行中にログファイルを変更できるアプリケーションとか見たことないの？
- 629 名前：デフォルトの名無しさん mailto:sage [2016/11/16(水) 23:34:22.54 ID:EhKul/vA.net]
- >>615
ログファイルであれば日付で切り替えとかあるね。
そしたらストリーム開きっぱで日付が切り替わったら、閉じて新しいの開き直すとかあるわ。
いつもlog4とか使って主処理と切り離してたから考慮から抜けてたわ。
俺の意見はdb接続とかで一部にしか当てはまらんので、
「基本的には」とか
「リソースを管理する必要があるもの」とか前提がつくね。すまん。
- 630 名前：デフォルトの名無しさん mailto:sage [2016/11/19(土) 06:41:14.49 ID:4ie0coBz.net]
- ログファイルはログが確実に記録されるのが使命であって性能は二の次なのだよ
よって開きっぱなしは論外
性能で問題が出るなら吐く量を調節すればいいだろう
- 631 名前：デフォルトの名無しさん mailto:sage [2016/11/19(土) 08:38:51.71 ID:eBLDMII7.net]
- 開きっぱはなんでダメなん？
- 632 名前：デフォルトの名無しさん mailto:sage [2016/11/19(土) 08:52:00.55 ID:YtkNE2sc.net]
- flushすればいいな
- 633 名前：デフォルトの名無しさん mailto:sage [2016/11/19(土) 10:16:22.36 ID:HaGDkE41.net]
- >>618
アプリケーションエラーとか異常終了した時にバッファされてる内容が書かれないことがあるから
異常終了した時はまさにそのエラーになる直前のログが欲しいのに～
ってなる w
ただログってそういうログばかりじゃないし Apache のアクセスログみたいにいちいち閉じてたら全然間に合わないって現実を知らない >>617 はもう少し経験積むまで黙ってた方がいいと思う
- 634 名前：デフォルトの名無しさん mailto:sage [2016/11/19(土) 14:20:53.96 ID:YtkNE2sc.net]
- >>620
それは開きっぱなしが問題なんじゃなくてflushしてないことが問題なだけで見当違い
- 635 名前：デフォルトの名無しさん mailto:sage [2016/11/19(土) 14:29:51.71 ID:HaGDkE41.net]
- >>621
>>604 から読み直せよ
見当違いはお前の方だよ...
- 636 名前：デフォルトの名無しさん mailto:sage [2016/11/19(土) 14:34:26.96 ID:WWFUnGVk.net]
- とこのように、相手を互いに見当違いであると罵り合うのであった
しかし、それは正しい
両者とも正しい
- 637 名前：デフォルトの名無しさん mailto:sage [2016/11/19(土) 15:37:17.31 ID:O7mQP4/b.net]
- スコープの話してるのに flush とか頭わいてるだろ
- 638 名前：デフォルトの名無しさん mailto:sage [2016/11/19(土) 21:51:13.35 ID:WZ8TOo4I.net]
- null安全をアピールしてる人間はObjCerから見ると補助輪付き自転車を渡してきてこれ安全だから絶対に乗れよと言ってくる頭おかしいおじさんにしか見えない
Swift移行がこじれるだけだから黙っといて欲しい
- 639 名前：デフォルトの名無しさん [2016/11/21(月) 14:59:21.88 ID:qSFgYSXv.net]
- 浜矩子・著
『アホノミクス完全崩壊に備えよ』
『どアホノミクスへ最後の通告』
『みんなで行こうアホノミクスの向こう側』
抑制のない成長に基づく経済政策は終焉
日本国民はどう対処すればいいのか。
新しい政権は民意を反映し、
食糧、住宅、健康、教育、最後に防衛です。
国民の意志を裏切ることは、
極端な場合、自殺や殺人にまでつながります。
民衆の指導者は
職業的政治家ではない人々から見つかるのです。
世界平和の脅威は、
イスラエル、イラン、アメリカです。
イスラエルの役割は跪いて、
パレスチナに許しを請うことです。
アメリカによる他国の虐待に
反対の声を上げなければなりません。
彼らは今世紀（21世紀）を
この帝国が出来上がるアメリカの世紀と呼ぶ。
しかし、そうはならないでしょう。
彼らが世界中に‘民主的’制度を確立したい
という衝動(世界を支配する)をコントロール
するのは、マイト レーヤの任務です。
非常に間もなく
マイト レーヤをテレビで見るでしょう。
彼は「匿名」で働いております。
- 640 名前：デフォルトの名無しさん mailto:sage [2016/12/08(木) 09:10:56.35 ID:FEYStmIt.net]
- 小規模ならGCのメリットは大きいのかもしれないが、大規模または大量にメモリを食うプログラムにはGCは向いてないのではないか。
あんまり例を知らないが、JAVAで動くマインクラフトのデバッグ画面でメモリ使用量みたら、めまぐるしく増加して一気に減ってるのみてびっくりした。
- 641 名前：デフォルトの名無しさん [2016/12/13(火) 13:02:48.84 ID:XUF2n21y.net]
- GC周りに付いて書かれたネットの記事読んできたけど
オブジェクトが生成されては次々と死んでいき
生きてるオブジェクトより死んだオブジェクトが多い場合の方が速くなるっぽい
>>627
そう考えると長命のオブジェクトが大量にある方が(性能的には)問題だが
マインクラフトがそれかは知らない
- 642 名前：デフォルトの名無しさん mailto:sage [2016/12/15(木) 23:33:53.51 ID:Z/98FfuD.net]
- >>606
C++はGC支援のメモリモデルが標準に入った
と言ってもコンサバGCライブラリ向けだけどな
- 643 名前：デフォルトの名無しさん [2017/01/18(水) 11:38:56.79 ID:A+XqqRn6.net]
- 漏れたときの調査が大変
安心してると痛い目にあう
- 644 名前：デフォルトの名無しさん [2017/01/20(金) 16:23:16.03 ID:4Q3o1w03.net]
- 参照カウントは循環参照の問題が起こるだけじゃなくて
意外と遅いって聞くけどマジで？
・メモリをOSから直接確保・解放するのは意外と遅い
・マルチスレッドで参照カウントを使うにはアトミックな操作が必要
・カウントを自動化すると不必要な参照カウントが起こる
とかで
対してトレーシングGCの弱点は回収時に止まる時間が長いところか
その対策か、V8やOracle JavaにはGCの時間を制限する機能があるみたいだが
それってどうなんだ？
- 645 名前：デフォルトの名無しさん mailto:sage [2017/01/20(金) 23:17:39.79 ID:2XlTkpSB.net]
- まじ
- 646 名前：デフォルトの名無しさん [2017/01/22(日) 15:00:56.26 ID:lyHWqZIh.net]
- ^ナマポ
- 647 名前：デフォルトの名無しさん [2017/01/22(日) 18:20:35.13 ID:CvVvUjG5.net]
- ストップ・ザ・ワールドの問題さえなくなればGCが最強ってこと？
- 648 名前：デフォルトの名無しさん mailto:sage [2017/01/22(日) 18:44:59.67 ID:2ikRDhsq.net]
- >>634
フルGCの危険があるという点で最強になりえない
- 649 名前：デフォルトの名無しさん mailto:sage [2017/02/20(月) 19:16:44.90 ID:NKdiRgAe.net]
- バイオハザード7は28万行のC#コードでできててビルド10秒らしい。
独自VM、独自GCだとか。
- 650 名前：デフォルトの名無しさん mailto:sage [2017/03/20(月) 22:46:15.84 ID:USOySpAW.net]
- >>636
ゲームで28万ステップって長すぎね？
- 651 名前：デフォルトの名無しさん mailto:sage [2017/04/01(土) 12:49:43.55 ID:ZgIqHRoc.net]
- バイオの資料見つけた。
https://www.slideshare.net/mobile/capcom_rd/re-engine-72302524
FrameGCって独自アルゴリズムなのか。
- 652 名前：デフォルトの名無しさん [2017/05/26(金) 12:05:46.50 ID:uY9cFHyF.net]
- >>638
FrameGCはゲームというかRTSに特化したGCだね
・ローカルに発生したオブジェクトは溜め込んでフレームの終わりにまとめて開放する
・グローバルに結びついたオブジェクトにはカウンタGCを適用する
・フレーム毎に循環参照のチェックを少しずつ行う
ざっくりこんな感じ？
- 653 名前：デフォルトの名無しさん mailto:sage [2017/05/26(金) 20:16:13.14 ID:0194UVlm.net]
- 内部的にC#をC++に変換してるからC#をスクリプト的に使ってるだけで実質C++だな。当然GC・メモリアロケータ周りも身内実装。
- 654 名前：デフォルトの名無しさん mailto:sage [2017/05/26(金) 22:20:13.64 ID:uY9cFHyF.net]
- >>640
C++のスマートポインタみたいな形で実装できるのかな？
俺は検討してみたけど無理だったw
- 655 名前：デフォルトの名無しさん mailto:sage [2017/06/03(土) 06:38:16.81 ID:MyiMvGI/.net]
- そこまでやって既存のフレームワーク使えるのって疑問が。
- 656 名前：デフォルトの名無しさん mailto:sage [2017/06/03(土) 10:06:08.23 ID:sCohk93m.net]
- GCがconflictするんですね判ります
- 657 名前：デフォルトの名無しさん [2017/09/11(月) 12:41:54.43 ID:YXmvV/7e.net]
- 「メモリ」+「フラグメンテーション」で検索すると色々と詳しい話が出てくるね。
- 658 名前：デフォルトの名無しさん [2017/09/11(月) 13:14:06.52 ID:YXmvV/7e.net]
- ここが分かりやすかった
ttps://www.uquest.co.jp/embedded/learning/lecture17.html
ttp://www.kaede-software.com/2015/06/post_655.html
- 659 名前：デフォルトの名無しさん mailto:sage [2017/09/11(月) 13:44:59.20 ID:I3u+9T/v.net]
- メモリのフラグメンテーションなど実質的には気にする必要は全くない
なぜなら現実のコンピュータにはMMUが付いてるから
物理メモリの連続空間が枯渇することは考えなくてもよい
あり得るとしたら32bitプロセスでの論理アドレスの連続空間の枯渇であるが
64bitプロセスにすれば問題ない
もともと論理アドレス空間が枯渇するかもしれないほどメモリを使うのなら
64bitプロセスにするのが当たり前なので・・・
というわけでメモリのフラグメンテーションは気にしなくてよい
CPUのキャッシュのヒット率を上げるとか、そういうことでなければ
- 660 名前：デフォルトの名無しさん mailto:sage [2017/09/11(月) 17:53:09.29 ID:P5pczjP2.net]
- そうなん？
ガベコレの回収効率が悪くなって
無駄な使用領域が増えて枯渇しやすくなるんじゃね
- 661 名前：デフォルトの名無しさん mailto:sage [2017/09/11(月) 18:13:16.59 ID:SGfZs9nE.net]
- >>647
GCのアロケートサイズとページングサイズの区別もついてないアホはスルーでよろしく
- 662 名前：デフォルトの名無しさん mailto:sage [2017/09/11(月) 20:33:05.66 ID:I3u+9T/v.net]
- 程度の問題であって
世のプログラムがフラグメンテーションなど気にせずとも
普通に動いているのを見てわかる通り、問題になってない
MMUがあるから
- 663 名前：デフォルトの名無しさん mailto:sage [2017/09/11(月) 21:54:05.93 ID:khvQxUtn.net]
- >>646
そういうぬるい環境で済むところもあればそうじゃないところもある
ゲームコンソールだと物理メモリサイズに最適化するからな
STLとかdefault allocatorで気軽に使ってヒープ汚しまくってると
そのうち物理メモリ足りなくなってページアウト
- 664 名前：デフォルトの名無しさん mailto:sage [2017/09/12(火) 10:09:32.99 ID:g0xsLkF6.net]
- 必ず来ると思った、その反論
しかし、稀な事例を持ち出して、どうこう言っても仕方がない
- 665 名前：デフォルトの名無しさん mailto:sage [2017/09/12(火) 12:38:17.20 ID:E3lbzyXM.net]
- MMU のお陰でふらぐめんてーしょんが起きない環境の方が希だと思うが
- 666 名前：デフォルトの名無しさん mailto:sage [2017/09/12(火) 13:22:19.16 ID:crCgFvVY.net]
- フラグメンテーションはアドレス空間や実メモリ量が限定される環境をどううまく使うかの話だから
MMUがあって64bit空間なら平気と言われてもな
- 667 名前：デフォルトの名無しさん [2017/09/13(水) 03:53:58.25 ID:TAF2DPKT.net]
- そそ、複雑なプログラムって書こうと思えばいくらでも複雑化するからな。
で、簡潔で高度と思われる機能を追加していくほど難易度は指数関数的に増大するし。
- 668 名前：デフォルトの名無しさん [2017/09/13(水) 05:10:44.22 ID:t818hmCa.net]
- でも実際スマホアプリ作ってんのにフラグメンテーションを防ぐ為に最初に使用する分全部確保しておいて、その中で割り当てするんだーとかいって、オレオレアロケーター作ろうとする頭の悪いやつがいて困る。
逆にお前の作ったそのアロケーターの中でフラグメンテーションして枯渇するわと。
- 669 名前：デフォルトの名無しさん mailto:sage [2017/09/13(水) 07:42:12.50 ID:7O+lQKpp.net]
- 組み込みなんかでよくあるそういうのは、どっちかというと最初に確保したメモリ以上を
使用しないことを保証するためにやるもんだろう。
- 670 名前：デフォルトの名無しさん mailto:sage [2017/09/13(水) 08:52:01.48 ID:Vaq5SeW/.net]
- アロケータ置き換えるだけでは普通解決しないでしょ
>>655 こそが置き換えて何するのか理解できてない気がする
- 671 名前：デフォルトの名無しさん mailto:sage [2017/09/13(水) 22:09:52.04 ID:PcFMQESF.net]
- むしろ一定時間を保証する（なのでサイズは固定長とかが多い）もんだろ
- 672 名前：デフォルトの名無しさん [2017/09/17(日) 13:06:26.21 ID:S40DCpdn.net]
- いくら64bitあっても設計が雑ならメモリ枯渇するでしょ
ページング方式でメモリ消費されてんだし
- 673 名前：デフォルトの名無しさん mailto:sage [2017/09/17(日) 13:32:06.14 ID:2kxiy1Rb.net]
- MMUのアドレス変換コストもタダじゃない。
TLBキャッシュ外れたら遅くなる。
- 674 名前：デフォルトの名無しさん [2017/09/17(日) 13:32:07.34 ID:S40DCpdn.net]
- 1回のメモリ取得で4kづつ消費されるわけか
- 675 名前：デフォルトの名無しさん [2017/09/17(日) 13:49:19.58 ID:S40DCpdn.net]
- ツリー状のメモリ管理するとあっという間にメモリ無くなるな
class CTree{
std::vector<CTree>;
};
とか
- 676 名前：デフォルトの名無しさん [2017/09/17(日) 14:00:55.72 ID:S40DCpdn.net]
- こうするとさらにメモリが消えていくな
class CTree{
std::map<std::string,CTree>;
};
- 677 名前：デフォルトの名無しさん [2017/09/17(日) 14:12:30.87 ID:S40DCpdn.net]
- 間違えた。
class CTree{
std::vector<CTree> m_Tree;
};
class CTree{
std::map<std::string,CTree>m_Tree;
};
で、ツリーのノード一つ毎に上は4kづつ下は8kづつメモリを消費するわけで・・・
- 678 名前：デフォルトの名無しさん mailto:sage [2017/09/17(日) 15:23:52.56 ID:iyMogwhx.net]
- 一回のメモリ取得で4KBってのが嘘だから意味が無い話だね
MMUついてたって、そんなアホな実装は無い
4KBだかの1ページ分の中での細かなメモリ断片化はおおむね無視できる、ということ
メモリ断片化で困るのは大きなサイズのメモリを確保しようと思ったとき
連続したアドレスが確保できなくてコケる、ということだからね
これに対してMMUは有効ということ
メモリが断片化で多少無駄遣いされる分にはスワップしてでも動くから
そんでこれは程度問題
大概の場合は問題にならない
- 679 名前：デフォルトの名無しさん [2017/09/17(日) 15:38:01.00 ID:S40DCpdn.net]
- https://ja.wikipedia.org/wiki/動的メモリ確保
＞また、粒度の細かいページングは、ページングテーブル
＞(物理アドレスと論理アドレスの対応表)が大きくなるため、
＞4KB程度の大きなブロック単位でしか割り当てることができない。
ウィキペディア見るとそのアフォな実装がまかり通ってると読めるんだが・・・
- 680 名前：デフォルトの名無しさん mailto:sage [2017/09/17(日) 15:48:55.35 ID:iyMogwhx.net]
- アホだなぁ
OSレベルのメモリ確保と言語レベルのnew、mallocは別
- 681 名前：デフォルトの名無しさん [2017/09/17(日) 16:00:06.71 ID:S40DCpdn.net]
- こっちも参考になる
https://ja.wikipedia.org/wiki/%E3%83%A1%E3%83%A2%E3%83%AA%E7%AE%A1%E7%90%86%E3%83%A6%E3%83%8B%E3%83%83%E3%83%88
CPUによってMMUの実装が異なる点は面倒だな
- 682 名前：デフォルトの名無しさん [2017/09/17(日) 16:06:24.06 ID:S40DCpdn.net]
- >>667
ちゃんとmallocやnew時のアドレス確認はしたか？？かなりアフォな動作してるぞ？
まあ、多少のrealloc程度の処理なら何とかしてくれるけどな。
- 683 名前：デフォルトの名無しさん mailto:sage [2017/09/17(日) 16:13:26.66 ID:iyMogwhx.net]
- mallocやnewは
大きなサイズを確保するときと
小さなサイズを確保するときで
アルゴリズムが切り替わる
- 684 名前：デフォルトの名無しさん mailto:sage [2017/09/17(日) 16:17:08.43 ID:iyMogwhx.net]
- VC++2015での実行結果
auto a = malloc( 10 );
auto b = malloc( 10 );
wchar_t tmp[ 100 ];
::swprintf_s( tmp, 100, L"a = %x, b = %x \n", a, b );
::OutputDebugString( tmp );
----------------------------------------
a = 10a4f0, b = 10a508
残念でしたね
- 685 名前：デフォルトの名無しさん [2017/09/17(日) 16:17:49.54 ID:S40DCpdn.net]
- MMUは多少以上の処理をすると簡単にフォールト返すのが困りもの
結局初心者レベルのプログラマしか想定してないんだよな
- 686 名前：デフォルトの名無しさん [2017/09/17(日) 16:30:36.71 ID:S40DCpdn.net]
- >>671
realloc使った事ある？
- 687 名前：デフォルトの名無しさん mailto:sage [2017/09/17(日) 16:34:30.81 ID:iyMogwhx.net]
- お前が残念なことと何の関係が？
あほらし
- 688 名前：デフォルトの名無しさん [2017/09/17(日) 16:37:39.46 ID:S40DCpdn.net]
- 複雑なことをしていると、それがまるで正しいかのように思う点がアフォ
多少複雑なことをしていてもアフォな挙動をする可能性はあると考えるべき
- 689 名前：デフォルトの名無しさん [2017/09/17(日) 17:05:23.31 ID:S40DCpdn.net]
- malloc,newの挙動の説明ってまんまMMUの説明なんだよな
だから複雑なアルゴリズムを使われていると思うのはMMUが複雑な挙動をしているから
でも、そんなに複雑な挙動してるか？？
単に過去のアプリとの互換性の問題で変な事をしているだけだぞ
- 690 名前：デフォルトの名無しさん [2017/09/17(日) 17:16:19.17 ID:S40DCpdn.net]
- たいがいのmalloc,newはMMU次第でいくらでも挙動が変化するからな
ちゃんとPC毎に動作確認したか？？
- 691 名前：デフォルトの名無しさん mailto:sage [2017/09/17(日) 17:44:23.50 ID:4FsrO7aF.net]
- ID:S40DCpdn しったかしすぎ
mallocの挙動はヒープのアルゴリズム次第
- 692 名前：デフォルトの名無しさん [2017/09/17(日) 17:55:14.06 ID:S40DCpdn.net]
- malloc,newの挙動はハードとOSによって変化するという記述は見たことあるけどな
- 693 名前：デフォルトの名無しさん [2017/09/17(日) 18:02:58.95 ID:S40DCpdn.net]
- ごめん、ハードとソフトウェアだった
- 694 名前：デフォルトの名無しさん mailto:sage [2017/09/17(日) 18:10:58.66 ID:hRPbVJUN.net]
- ヒープの管理しないでなんとかなるレベルのものはgc言語使えばいいんでは？
このスレの趣旨的にそうでしょ？
- 695 名前：デフォルトの名無しさん [2017/09/17(日) 21:59:59.26 ID:S40DCpdn.net]
- 自分はメモリ対策プログラムを作って対応したけどな。
メモリサイズを三種類用意して、メモリに対するガードの確実な作りにした。
現在のサイズに使われてるサイズにリミットサイズの三種類のサイズな。
外に出てくるサイズは現在のサイズ、
使われてるサイズはメモリを増やした場合の最大取得サイズで、事実上の取得サイズ、
リミットサイズは取得できるメモリの上限。
で、これらを組み合わせてスーパークラスを作って基本的に対応させてる。
- 696 名前：デフォルトの名無しさん [2017/09/17(日) 22:08:00.63 ID:S40DCpdn.net]
- メモリの増減には現在のサイズで対応し、このサイズが必要以上に大きくなると
使われてるサイズを拡張するようにした。リミットサイズは滅多に使わないけれども、
一応対応させた。
メモリに対する読み書きは専用関数を経由して読み書きするようにしたから、
素人が使っても安全なぐらいのプログラムになってる。
- 697 名前：デフォルトの名無しさん [2017/09/17(日) 22:27:01.93 ID:S40DCpdn.net]
- あと、動的配列ってのを作って、複数のメモリ取得に対応させた。
メモリにヘッダとフッタを用意して、フッタには複数配列のデータに対応させ、
ヘッダには配列数とメモリサイズを入れてる。フッタには>>682のデータを持たせた。
ある意味では拡張コンパクションみたいなモノになった。
- 698 名前：デフォルトの名無しさん [2017/09/17(日) 22:33:12.53 ID:S40DCpdn.net]
- で、アローケートが一回だけになるようにして、あとはリアロークで対応させた。
おかげでメモリの消費効率は異常なまでに効率よく使えるようになったよ。
あと、動的配列使う場合はいったんメモリをフォーマットするようにしたけどね。
- 699 名前：デフォルトの名無しさん [2017/09/17(日) 23:21:53.67 ID:S40DCpdn.net]
- それから、動的配列は入れ子構造にすれば色々と応用がきくようになってるけどな。
で、追記式みたいにデータが動くツリー構造とかが使えるようになってる。
- 700 名前：デフォルトの名無しさん mailto:sage [2017/09/17(日) 23:27:13.12 ID:2kxiy1Rb.net]
- アセンブラできない馬鹿がC++使うことを想定するとGCは成功と言わざるをえない。
- 701 名前：デフォルトの名無しさん mailto:sage [2017/09/18(月) 05:14:41.46 ID:4HKrfROv.net]
- ID:S40DCpdn は壊れたプログラマ
- 702 名前：デフォルトの名無しさん [2017/09/19(火) 04:18:18.94 ID:GmtdcLyZ.net]
- メモリを動かして処理すれば出来る事なのにな
出来る事を出来ないというのは間違い
- 703 名前：デフォルトの名無しさん mailto:sage [2017/09/19(火) 09:15:50.12 ID:sOczhhK4.net]
- 誰へのレスかすらわからないというね
誰も何も「出来ない」という趣旨のレスはしてないと思うが
独り言かね
- 704 名前：デフォルトの名無しさん [2017/09/19(火) 12:34:55.99 ID:kI9ocUjD.net]
- 前日に連続して意味不明な独り言してるやつがいるからそれの続きだろ
- 705 名前：デフォルトの名無しさん mailto:sage [2017/09/19(火) 17:17:32.47 ID:xxOzXrDl.net]
- ワッチョイ推奨
- 706 名前：デフォルトの名無しさん mailto:sage [2017/09/23(土) 13:33:17.07 ID:J7EIO5I9.net]
- malloc()関数の内部はOSからメモリをまとめて取ってくる処理と、
すでに取ってきたメモリを（free()で空きが生じたとき）やりくりする処理の2本立て
前者の処理（システムコールの呼び出し）は比較的高コストなのでmalloc()の度に呼びはしない
また後者の処理は、連続したアドレス範囲のメモリを確保できている前提で動く
ページングはもっと下のレイヤーで行われるので、
malloc()のコード自体がMMUの有無やOSの違いを関知したりはしない
- 707 名前：デフォルトの名無しさん mailto:sage [2017/09/23(土) 13:35:30.80 ID:J7EIO5I9.net]
- 例外的な変態実装は知らんが、まあ普通は
- 708 名前：デフォルトの名無しさん mailto:sage [2017/09/23(土) 14:27:08.01 ID:Dvp9BlYO.net]
- 最近はjavascriptのレイヤーとかまで出来てさらに複雑面倒に
- 709 名前：デフォルトの名無しさん mailto:sage [2017/10/26(木) 07:49:10.45 ID:7YV3WIz9.net]
- かなり無駄な処理してそうだ
- 710 名前：デフォルトの名無しさん [2018/03/11(日) 23:00:34.15 ID:gpjOI+baf]
- スタック構造、服を着たり脱いだりすることに例えられますね。
- 711 名前：デフォルトの名無しさん [2018/05/23(水) 21:27:23.53 ID:Au5e7VGg.net]
- 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
3682F
- 712 名前：デフォルトの名無しさん [2018/07/05(木) 00:30:07.61 ID:RfoszcD2.net]
- IZ6
- 713 名前：デフォルトの名無しさん mailto:sage [2018/08/31(金) 07:07:54.70 ID:EIZBTnQd.net]
- 保守
- 714 名前：デフォルトの名無しさん mailto:sage [2018/08/31(金) 23:14:14.49 ID:qeyIwfZb.net]
- 結論：GCは失敗
- 715 名前：デフォルトの名無しさん [2018/10/30(火) 23:04:20.19 ID:POwfr3jz.net]
- GCをルンバで例えたらどうだろう
自動
しかしテーブルの上や
冷蔵庫の中は片付けない
日常生活にさしさわりなく動いてほしい
- 716 名前：デフォルトの名無しさん mailto:sage [2018/10/30(火) 23:46:35.14 ID:j0ABINKp.net]
- それに加えてルンバが動けるように床は片付けておかないといけないとか
自動で上手く機能させるために気にしないといけない事が色々ある
- 717 名前：デフォルトの名無しさん mailto:sage [2019/07/03(水) 08:55:46.04 ID:XKc3eOoC.net]
- もういらないって明示的に書かなきゃならないのなら自前で管理するのと一緒だよな。
アマチュアがサンデープログラムしたり、短時間で終了するアプリならむしろ楽チンだけど、
365日24時間稼働し続けるシステムには致命的な問題になるからなぁ
- 718 名前：デフォルトの名無しさん [2020/02/13(木) 08:56:02.27 ID:B+Fb/epo.net]
- まあ落ちるアプリの多いこと
- 719 名前：デフォルトの名無しさん mailto:sage [2020/02/13(木) 15:29:41.61 ID:z5cRWLgY.net]
- GCがある言語でも、shallow copy と deep copy のどちらにすべきかの判断が難しくて、結局、間違えてバグの原因になる可能性がかなり残る。
また、C/C++ポインタのミスを危険視する人がいるが、多くの場合はプログラム開発時にテストをすれば間違いが発見できる。
C/C++でのバッファオーバーランを気にする人がいるが、逆にGCがある言語でも、間違って1つ右隣の要素にしてしまったり、処理する個数を1つ間違ったりするミスは有り得て、その場合、厳密な意味でのバッファオーバーランは無くても処理内容自体はバグる。
- 720 名前：デフォルトの名無しさん [2020/02/22(土) 01:52:20.63 ID:eI8xgqVo.net]
- No GC派なんだけど、WebサーバーをC++とかで実装しても結局力持て余す感はあるよな
それだからかなり性能下げてもいいからちょっとでも早く作れるスクリプト言語採用されるってのもありそう
- 721 名前：デフォルトの名無しさん mailto:sage [2020/02/25(火) 21:09:3
]
- [ここ壊れてます]
- 722 名前：6.95 ID:EsX3m3+2.net mailto: GCのメリットは言語の文法が簡単になること。
GCはスクリプト言語のためにある。 [] - [ここ壊れてます]
- 723 名前：デフォルトの名無しさん [2020/02/26(水) 10:49:39.07 ID:wiEfavJ1.net]
- (destructor)()
dispose()
destroy()
close()
free()
delete
- 724 名前：デフォルトの名無しさん [2020/12/29(火) 01:21:48.14 ID:qxevuYQ38]
- 数学は「定義」にかえることが大事！
https://www.youtube.com/watch?v=yhrUT4bLm7Q
大学で本気で学問をしたい人へのアドバイス
https://www.youtube.com/watch?v=7G7XbRSdk9k
高校生でも雰囲気だけ分かるガロア理論
https://www.youtube.com/watch?v=LiPv0VuSvaE
高校生でも雰囲気だけわかる圏論
https://www.youtube.com/watch?v=D2GU4cmm3Ys&t=225s
高校生でも雰囲気だけ分かるゼータ関数とリーマン予想
https://www.youtube.com/watch?v=MaerL2XLaqk
高校生でもわかる】いろいろな積分 リーマン，ルベーグ..
https://www.youtube.com/watch?v=jzfaFCDn5JY
数を創る話?自然数から複素数への構成?
https://www.youtube.com/watch?v=dQ2nFUTNchU
高校数学と何が違うの？大学数学でつまずかないためのアドバイス！［大学数学準備講座1/4］
https://www.youtube.com/watch?v=duXZGbRviG4
【高校数学】極限の誤解を解く
https://www.youtube.com/watch?v=cPNttp7b1Gs
- 725 名前：デフォルトの名無しさん mailto:sage [2021/10/13(水) 08:41:51.52 ID:Qk99MJFD.net]
- 今やGCのない言語でweb framework書く人間は絶滅危惧種
- 726 名前：デフォルトの名無しさん mailto:agete [2022/12/27(火) 13:22:02.97 ID:k0608tOt.net]
- このスレってガイジ扱いされてたけどRustとか出てきて実は正論だったんじゃね？って見直してるわ
- 727 名前：デフォルトの名無しさん [2022/12/27(火) 15:08:00.70 ID:ITKU+yxr.net]
- てへっ(∀｀*ゞ)ﾃﾍｯ
- 728 名前：デフォルトの名無しさん [2022/12/28(水) 20:55:42.01 ID:kKtGrfmE.net]
- おれはGCが最初から分かりづらいなぁと思ってたよ。mallocやnewより
- 729 名前：デフォルトの名無しさん [2022/12/29(木) 10:46:26.29 ID:jCj0trE4.net]
- >>709
release
- 730 名前：デフォルトの名無しさん mailto:sage [2022/12/29(木) 16:52:23.68 ID:HWC94+Gl.net]
- GCは停止時間問題を解決できないまま生涯ふわふわした存在で居続けるのだよ
- 731 名前：デフォルトの名無しさん [2023/01/01(日) 09:16:28.52 ID:A1pcbmVG.net]
- >>1は、2014年に問題提起してるのか・・・。
Rustとかは2010年ころ発表だけど、実際に一般に知られるようになったのって2021年頭から
>>1は、それなりに的を射た技術理解・評価をしてるんだな
俺は人気の言語を覚えて、周りが言ってるメリットを、反対派にコピペするだけだけどｗｗ
ま、Pythonのお手軽さを超えることはないと思うけど、どこまでRustは伸びるのかなぁ
- 732 名前：デフォルトの名無しさん mailto:sage [2023/02/08(水) 15:30:25.91 ID:MLBtrq1u.net]
- やはりGCは必要だった
WebAssemblyにガベージコレクション機能が登場、Chrome 111で試験的実装に。Dartなど高級言語のWebAssembly対応へ前進
https://www.publickey1.jp/blog/23/webassemblychrome_111dartwebassembly.html
- 733 名前：デフォルトの名無しさん mailto:sage [2023/02/10(金) 09:06:41.51 ID:fIr5pCup.net]
- すべてがBASICに戻る
- 734 名前：デフォルトの名無しさん [2023/02/11(土) 11:51:58.99 ID:2GIAa1ZP.net]
- >>719
それもいいな
- 735 名前：デフォルトの名無しさん mailto:sage [2023/03/08(水) 00:10:24.00 ID:ZNO423TE.net]
- GCを含め、「機械に不慣れな人でも簡単にプログラミングできるようにする」という
これまで高級言語が行ってきたような試みはすべてAIに取って替わられるような気がする
まあ、現時点のAIは使い物にならないかもしれないが、いずれは…
- 736 名前：デフォルトの名無しさん mailto:sage [2023/03/10(金) 23:04:44.35 ID:hNo+M64i.net]
- AIに「これはゴミか？」を学習させていって人間がゴミ認定される日も近い
- 737 名前：過去ログ ★ [[過去ログ]]
- ■ このスレッドは過去ログ倉庫に格納されています
|
 |
