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

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/ 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ない言語ではマークスイープと比べ非常に面倒なことになる

---

---

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

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