- 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/
- 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と相性が悪い
|
 |
