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

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

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

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

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

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

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

**デフォルトの名無しさん** · 2015/12/09(水) 01:14:15.85

>>260
起動時に切り替えられるだけであって
オブジェクトごとには切り替えられないのでは

**デフォルトの名無しさん** · 2015/12/09(水) 01:50:08.36

>>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できるようには決してできない。メモリ以外の資源管理も安全だよ。

**デフォルトの名無しさん** · 2015/12/12(土) 10:36:13.53

freeし忘れるとか、そんな超ウルトラ素人ミスを大前提に議論するのは間違いだよなｗ
freeしきれないとかｗｗｗｗ

**デフォルトの名無しさん** · 2015/12/12(土) 11:52:29.69

>>263
規模が大きくなれば管理が難しくなるのは普通のことだよ。
ライフサイクルはオブジェクトごとに異なるものだし、
人間に頼らずにGCにメモリ管理を任せるっていうのは良いやり方だよ。

**デフォルトの名無しさん** · 2015/12/12(土) 12:05:07.06

shared_ptrって参照カウント式のGCじゃないの？

**デフォルトの名無しさん** · 2015/12/12(土) 12:44:09.71

循環を綺麗に扱えるなら参照カウントの方が良いと思うけど
VB6は循環参照の扱いどうやってるんだろう

**デフォルトの名無しさん** · 2015/12/12(土) 14:25:51.97

>>265
RAIIじゃろ

**デフォルトの名無しさん** · 2015/12/12(土) 15:20:38.55

>>265
GCの一種だけど、文脈的にはプログラマが
管理が非局所的で明確な型宣言もなしに使えるのをGCと言ってるわけで
議論で揚げ足にしかならない野暮な突っ込みはやめようぜ

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 08:16:09.53

>>264
いや、下手って一言で片付けられるよ。
よっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっっぽど、出ない限り

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 08:38:44.84

片付ける奴が馬鹿なのだ。素人ほど簡単だと言いたがり、上級者ほど簡単ではないとはっきり言うものだ。
どの分野でもな。

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 09:09:02.89

freeとか言ってる奴はC++使えよ。いつまでＣ使ってんだ。

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 09:20:53.11

>>270
東大生が人に教えるとき、何がわからないのかわからないというのがわからない。
上級者になればなるほど自分がやってることなんて簡単に見えてくる

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 09:35:23.70

>>272
何が分らないか分らない、つまり東大生も生徒がどういう思考をしてるか分析できず分らないと言ってるのだ。
低学歴ほど、分らないのはおまえが馬鹿だからと簡単に片付けるものだ。

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 09:37:05.77

それ中級者
あと、東大生は教えるの上手いのもいるから想像で話すな馬鹿

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 09:41:37.74

このようにおまえのようなコンテキストすらまともに読めないPGは五万といる。
スレッドがデッドロックしてメモリを開放できないなんてよくあることだ。

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 10:59:16.82

>>275
。。。。。完全な設計ミスじゃん

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 11:15:19.23

>>275
俺は272に向けてたんだが
そりゃコンテキスト読めてないように見えるよなw

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 11:40:27.14

スレッドがデッドロックしたらメモリリークどころじゃないじゃないかwww

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 14:48:51.74

スレッドがデッドロックしちゃってメモリ解放できない（泣）
っていうPGが五万といるのかよｗ

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 15:51:19.55

まぁfreeやdeleteやnullやらすらできないPGに、「僕はそんなこと管理しきれる脳みそ持ってない！」って言われたらソレは真実なんだろうけど・・・。
そんな脳みそPGに「もっと複雑な業務使用」を理解できるとは思えないんだ。

そんなPGにプログラミングの場を与えるのが間違い。

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 15:58:21.86

そもそも実務でスレッド使うＰＧなんてゴマンもいない

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 17:06:58.52

Javaのプロジェクトだとほぼ使ってるけどな隠蔽してるだけで
そのせいで共有リソース壊したり、逆に個人情報の領域が共有されたりして、とんでもないインシデントが発生する
そんな奴等にメモリ管理なんて任せられんし、共有リソースも触らせたくないから
更に隠蔽したフレームワークもどきが出来上がる

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 17:59:33.07

>>282
勝手に使うな。勝手にトリッキーコードにすんな。
素直に、設計書通りに作れ。
勝手なことやって勝手に自爆してるだけじゃねーか。

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 18:15:27.90

javaってc++のconst参照に対応するものが無いのに、素人みたいなプログラマを大量にかき集めているのが怖すぎる。

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 18:28:13.63

>>283
理解してないのに無理してレスしなくていいから

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 18:42:08.38

C#はマルチスレッド使いまくりだけど事故の話はあまり聞かないな
マイクロソフトが優秀なのか低品質プログラマがいないのか

**名無しさん＠そうだ選挙に行こう** · 2015/12/14(月) 19:01:59.11

JAVA自体がDQN

uy ◆Qawu9.2l1E · 2015/12/14(月) 20:57:26.55

Freeし忘れ

↑これ。

ソースコード書いてる人間の注意力次第でバグが入るなら
言語も設計も間違ってるよ

**デフォルトの名無しさん** · 2015/12/14(月) 21:54:10.80

動的型言語
↑
これ

コード書いている人間の注意力次第でtypoするだけで
実行するまでわからないバグが入るなら
言語も設計も間違ってるよ

**デフォルトの名無しさん** · 2015/12/14(月) 22:23:00.81

C#でcatchやfinally書くの嫌すぎる
C++に戻りたい

**デフォルトの名無しさん** · 2015/12/14(月) 22:43:08.79

>>290
おかえり

**デフォルトの名無しさん** · 2015/12/15(火) 06:39:51.52

(ヽ´ω`)眠い

**デフォルトの名無しさん** · 2015/12/16(水) 08:46:15.45

>>290
C++/CLR「こっちこいよ」

**デフォルトの名無しさん** · 2015/12/17(木) 17:18:40.36

COMのVariantとかJSとかリークしまくりだし

**デフォルトの名無しさん** · 2015/12/17(木) 23:16:36.40

そういやVBScriptって参照カウンタ以外のGC積んでんのあれ
必要には見えないんだけど

**デフォルトの名無しさん** · 2015/12/18(金) 23:17:49.50

プログラマはMacを使ってるってマジ？
http://hayabusa3.2ch.net/test/read.cgi/news/1450395043/

**デフォルトの名無しさん** · 2015/12/19(土) 07:07:37.11

マカーってどんだけアホなの？

**デフォルトの名無しさん** · 2015/12/19(土) 12:49:09.79

解放処理
すら、まともにお前ら管理できねーのかよ・・・・・・・・・・・・・・・・。そらオレが完璧な仕様書渡してもバグってるわけだ

**デフォルトの名無しさん** · 2015/12/19(土) 13:38:07.82

開放処理を手動でやれって書いてある仕様書かw
御免こうむるwwwww

**デフォルトの名無しさん** · 2015/12/19(土) 14:42:49.35

ガベコレのあるPyObjectをラップするクラスをガベコレのあるDで書いたら
wxPythonで書いたクラスをDから使ったとき意味不明なタイミングで落ちるようになった
二重に管理するとだめなんかな

**デフォルトの名無しさん** · 2015/12/19(土) 15:57:38.71

>>298
ﾌﾟﾌﾟﾌﾟ　馬鹿だこいつw

**デフォルトの名無しさん** · 2015/12/20(日) 08:46:23.14

ガベージコレクションはたしかに便利だ
だからといって「本来はてめぇのケツはてめぇで拭け＝自分で解放すること」を忘れてはならない

そんだけ

**デフォルトの名無しさん** · 2015/12/20(日) 11:55:11.08

C#ではSafeHandleだけ作って後は放置
usingも使わないってのがトレンドだけどね
自分で解放とかバカバカしい
面倒はランタイムに見させて開発者はドメイン設計に集中するって目的を見失うな

**デフォルトの名無しさん** · 2015/12/20(日) 12:13:23.36

>>303
オブジェクトの開放を他と独立にやれるケースばかりならそう言えるかもしれんが
オブジェクトAとBがリソースCに依存しているケースでA、Bの開放の少なくとも片方をGCに任せる場合、
リソースCの参照カウンタなりをつかった防護策をプログラマーが書かねばならない
しかしそんな嫌ったらしい雑用を増やすぐらいなら
　Cオープン
　A生成
　B生成
　A, B使用
　B開放
　A開放
　Cクローズ
でええやん？

さらにダンプファイルとかからの障害解析において、オブジェクトが生きているべきなのか死んでいるべきなのか決まっていないとか、
アドレスがはっきりしないとか言う状況は地獄

**デフォルトの名無しさん** · 2015/12/20(日) 12:21:54.48

つかこの世はうつろうもののであって、物理的ハードウェアでプログラムを実行する限り、
計算モデルは明らかに状態遷移ベース（チューリングマシン）の方に分がある
GCとかチューリングマシンで無理矢理関数型プログラミングを行うためのつなぎの技術、
いわば邪道
どんだけ蛇が出てくるか、GCの方がかえってわからん

**デフォルトの名無しさん** · 2015/12/20(日) 13:48:14.94

>>304
設計が悪い
使い終わったという言葉が示す通り使い終わったならどうなろうが知った事ではない
知らなきゃ困るような設計にしたのが間違いだね

**デフォルトの名無しさん** · 2015/12/20(日) 13:52:55.68

メモリ空間は無限であるべき
使い終わったメモリの断片化なにそれ？
仮想メモリを管理するのはCPUの責任だろ

**デフォルトの名無しさん** · 2015/12/20(日) 14:03:49.29

>>306
>>304の例で、さらにCを上書き更新したいオブジェクトDがいたらどうすんの？
GCがA、B両方開放してくれるまでDは期限不定で待たされるけどそれが>>306的に良い設計なの？

つまり、ハードウェアリソースの有限性を考慮する限り
>使い終わったという言葉が示す通り使い終わったならどうなろうが知った事ではない
が常に成立はしないという話

**デフォルトの名無しさん** · 2015/12/20(日) 14:28:20.48

>>308
そんなあっちこっちから同時にリソース掴みに行く設計が悪いって最初からわかってて言ってるんだろ？
意見を否定するためだけの極端な反例(この場合は例にすらなっていないが)を引き合いに出すのは不毛だよ

**デフォルトの名無しさん** · 2015/12/20(日) 14:35:53.96

>>303
いい加減だなぁw

**デフォルトの名無しさん** · 2015/12/20(日) 14:36:58.02

>>309
>そんなあっちこっちから同時にリソース掴みに行く設計が悪いって最初からわかってて言ってるんだろ？
極論なもんｶﾖ；
例：　表示デバイスの数＞表示したいスレッドの数
というのはざらにある

で、>>308のオブジェクトDのケースはどう解決すんのさ…
GCが「いつ開放してくれるかわからない」ブツである以上解消しない問題だとおもうんだけど
（A、BにCのための明示的closeメソッドを付けるぐらいならGCに頼らずに順序管理するわ；

**デフォルトの名無しさん** · 2015/12/20(日) 14:42:20.07

解決策の一つはActive ObjectパターンでリソースCの管理を1スレッドXにやらせて
Cに対する要求を全部Xのキューにシリアル化して入れさせるというのがあるが、それはそれで
リソースCを使う全てのオブジェクトがスレッドXに依存するから、Xの開放コードが面倒なことになりかねない
かつ、シリアル化はマルチコア時代のせっかくの並列実行性能を殺してしまう

GCに合わせて生きることは、神仙にでもならねば到底かなわぬ…

**デフォルトの名無しさん** · 2015/12/20(日) 14:44:35.05

つくづく、ARC最強だな。

**デフォルトの名無しさん** · 2015/12/20(日) 14:46:27.58

>>311
その例じゃ308の状況にならないよ
どんなコード書いてんだよw

**デフォルトの名無しさん** · 2015/12/20(日) 14:48:11.36

>>314
>その例じゃ308の状況にならないよ
なんで？ビデオメモリに2スレッドから同時に書いて無事に済むと思ってるの…；

**デフォルトの名無しさん** · 2015/12/20(日) 14:51:52.93

だから同時に書く設計が悪いんだって
気合入れて設計を見直してみろ
そんな必要はないってわかるから

**デフォルトの名無しさん** · 2015/12/20(日) 14:55:30.48

ていうか>>316の言っていることはますます矛盾で、
>同時に書く設計が悪い
>そんな必要はないってわかる
というのは明白に「書き込みの順序を設計できる」ということを言っていて、
それはその通り（チューリングマシンの計算モデルに合致する）ので別段漏れの立場と対立するものではなく、
かつ気合を入れて設計すれば順序で全て解決する（GCは不要である）という言明でもある

**デフォルトの名無しさん** · 2015/12/20(日) 15:17:45.93

>>315
もはやGCがどう関係するのかわからない

**デフォルトの名無しさん** · 2015/12/20(日) 15:20:28.11

>>318
彼は敵対意見に反論する材料が欲しいというだけで変な例をでっち上げて出してしまったんだ
本人も今頃困ってるんじゃないかな

**デフォルトの名無しさん** · 2015/12/20(日) 17:05:42.48

>>319
>>308を変な例変な例というばかりでGCを用いた正しい解決方法が一向に示されない件について：
繰り返しになるが、>>308のオブジェクトDのケースはどう解決すんのさ…
たとえ変でも反例は反例だし
>>308のリソースCがファイルなのだとしたら、病的な反例というほど例外的想定でもない

読み書き順序の設計の必要性（破壊的代入前提のプログラミング）を口にしつつ
>使い終わったという言葉が示す通り使い終わったならどうなろうが知った事ではない（>306）
と言い切ることはできないとかそういう話

で、現実のハードウェアは破壊的代入前提のブツばかりであるという、（>306)

>>318
ウィンドウシステムでの描画は一般に裏VRAMに描いてハードウェアでBitBlt転送するが
裏VRAMに書く際のデバイスコンテキストが複数使えるが数に限りがある場合…
とか細かい話をしても通じないようならリソースCをファイルと考えてくんな

**デフォルトの名無しさん** · 2015/12/20(日) 17:12:24.84

ﾌﾟﾁ訂正
誤: で、現実のハードウェアは破壊的代入前提のブツばかりであるという、（>306)
正: で、現実のハードウェアは破壊的代入前提のブツばかりであるという、（>308)

**デフォルトの名無しさん** · 2015/12/20(日) 17:19:25.13

読み込みと書き込みを別のリソースに分離したり読み書きが同時に出来るように作る
書き込みたいから読み込み終わるの待ってますってリソースの無駄だろ

**デフォルトの名無しさん** · 2015/12/20(日) 17:21:31.86

なんか参照カウントの話とマルチスレッドの話がごっちゃになってね？

**デフォルトの名無しさん** · 2015/12/20(日) 17:33:49.10

>>322
>読み込みと書き込みを別のリソースに分離したり読み書きが同時に出来るように作る
破壊的代入の世界ではそいつは常に可能とは限らない

>308の例で、リソースCがファイルXなのだとしたら、オブジェクトDが上書きすべきもあくまでファイルXでないといけない。
つまりリソース分離の余地など無い
（正確には、無理矢理ファイルA、BはファイルX、DはファイルYに分ける設計もありえるが、XとYに対する変更をいつどのように統合するかという超難題が生じる

この手の混乱は、A、BがアクセスするリソースCの開放タイミングの決定をGCに任せてサボったがために生じるのである

**デフォルトの名無しさん** · 2015/12/20(日) 18:10:09.92

おいおい、バージョン管理のマージの話にまで拡張したら収集つかなくなるぞw

**デフォルトの名無しさん** · 2015/12/20(日) 19:32:49.85

>>324
ファイルの分割は必ずしも必要ではないし更新モデルから読み取りモデルへの同期も必要ないよ

**デフォルトの名無しさん** · 2015/12/20(日) 19:44:06.53

>>323 (Rust信者で)すまんな。
ttp://smallcultfollowing.com/babysteps/blog/2015/12/18/rayon-data-parallelism-in-rust/#data-race-freedom
マルチスレッドで起きるデータ競合といった問題も、シングルスレッドで起きうるdangling pointerなどの問題も、
どっちも所有権を持つオブジェクトが無闇にいたり、変な参照関係があるから起きるんじゃないか？って言う人がおる。
根っこが同じ、あるいは近しい問題なんで、横滑りに見えても堪忍な。

**デフォルトの名無しさん** · 2015/12/20(日) 19:49:46.85

メモリ管理もできないんだから
データの依存関係とか関係ねえ～～～～～～～～～～～～
でおわりでは

**デフォルトの名無しさん** · 2015/12/21(月) 05:26:25.94

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

**デフォルトの名無しさん** · 2015/12/21(月) 05:32:28.99

その理由・・・GCは失敗。メモリは自分で管理せよ！
http://peace.2ch.net/test/read.cgi/tech/1447856699/l50

**デフォルトの名無しさん** · 2015/12/21(月) 05:35:31.18

メインメモリに対するGC・・・MGC
HDDならストレージGC・・・SGC

**デフォルトの名無しさん** · 2015/12/21(月) 05:38:11.78

GoogleChromeかsvchost.exeを使わなくなった理由・・・ページメモリGC制御が遅過ぎでお粗末だからか？

**デフォルトの名無しさん** · 2015/12/21(月) 05:42:27.02

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

**デフォルトの名無しさん** · 2015/12/21(月) 05:45:15.43

「Svchost Process Analyzer」
svchost.exeのプロセスの中身が何かを調べて表示するフリーソフト
http://gigazine.net/news/20131114-svchost-process-analyzer/

**デフォルトの名無しさん** · 2015/12/21(月) 05:51:39.30

そろそろsvchost.exeを使うソフトは使用禁止なのかも？

**デフォルトの名無しさん** · 2015/12/21(月) 06:11:17.64

svchost.exeを使わないことでGoogleChromeは確実に応答性能が速くなっている
・・・動画マルチ再生でクラッシュしたFirefoxは見習うべき

**デフォルトの名無しさん** · 2015/12/21(月) 06:17:26.48

残念だがスリープだ！　
http://pds.exblog.jp/pds/1/201104/11/06/e0026606_2391337.jpg http://i.imgur.com/qrjJDgC.jpg

**デフォルトの名無しさん** · 2015/12/21(月) 06:40:32.08

Wave
http://aurorawave.atspace.tv/?sop:v/jfgn-S6JzfM!RDtSvhh7Sq1OU http://i1.ytimg.com/vi/jfgn-S6JzfM/mqdefault.jpg #AuroraWaveTV

**デフォルトの名無しさん** · 2015/12/21(月) 06:42:41.39

LG OLED TV : You Dream We Display
http://aurorawave.atspace.tv/?sop:v/VenG8TF90yA!RDVenG8TF90yA http://i1.ytimg.com/vi/VenG8TF90yA/mqdefault.jpg #AuroraWaveTV

**デフォルトの名無しさん** · 2015/12/21(月) 06:43:24.61

LG OLED TV - The Ultimate Display
http://aurorawave.atspace.tv/?sop:v/JubFjalfNIY!RDJubFjalfNIY http://i1.ytimg.com/vi/JubFjalfNIY/mqdefault.jpg #AuroraWaveTV

**デフォルトの名無しさん** · 2015/12/21(月) 07:08:24.86

LG 4K OLED: Paris and Chicago
http://aurorawave.atspace.tv/?sop:v/Hi_WWhih4n4!RDHi_WWhih4n4 http://i1.ytimg.com/vi/Hi_WWhih4n4/mqdefault.jpg #AuroraWaveTV

**デフォルトの名無しさん** · 2015/12/21(月) 09:26:05.64

国別ISO登録件数　⇒　技術マフィア　⇒　技術流出状況　　　
http://www.jicqa.co.jp/09info/07newsletter/2012/no168_news1201.html
http://www.jicqa.co.jp/09info/07newsletter/2012/img/2012-0105-1741.JPG
http://www.jicqa.co.jp/09info/07newsletter/2012/img/2012-0105-1818.JPG
http://www.jicqa.co.jp/09info/07newsletter/2012/img/2012-0105-1742-a.JPG
http://www.google.co.jp/search?q=ISO%E6%9C%AC%E9%83%A8&;num=100&ie=utf-8
http://pds.exblog.jp/pds/1/200909/06/87/a0137487_22475768.jpg

**デフォルトの名無しさん** · 2015/12/21(月) 09:41:02.29

中国、ダークマターの検出に挑む探査衛星「悟空」を打ち上げ
http://news.mynavi.jp/news/2015/12/17/495/
http://n.mynv.jp/news/2015/12/17/495/images/001l.jpg
http://n.mynv.jp/news/2015/12/17/495/images/002l.jpg
http://n.mynv.jp/news/2015/12/17/495/images/003l.jpg

**デフォルトの名無しさん** · 2015/12/21(月) 09:44:40.17

京がお仕置き候補に???
http://gigazine.net/news/20130618-fastest-supercomputers/

◆1位：Tianhe-2(天河二号)、中国人民解放軍国防科学技術大学
http://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、アメリカのオークリッジ国立研究所
http://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、アメリカのローレンス・リバモア国立研究所
http://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)
http://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、アメリカのアルゴンヌ国立研究所のエネルギー部門
http://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

**デフォルトの名無しさん** · 2015/12/21(月) 09:50:17.19

気づかないかISOは中国のためにある
http://www.jicqa.co.jp/09info/07newsletter/2012/img/2012-0105-1742-a.JPG

**デフォルトの名無しさん** · 2015/12/21(月) 10:45:57.17

>>344
蓮舫さんに次の選挙は次点で良いですよねって言ってきて

**デフォルトの名無しさん** · 2015/12/21(月) 11:12:03.51

>>336
ほんそれ

**デフォルトの名無しさん** · 2015/12/21(月) 12:31:40.33

https://ja.wikipedia.org/wiki/%E8%93%AE%E8%88%AB

**デフォルトの名無しさん** · 2015/12/21(月) 12:34:04.50

https://www.google.co.jp/search?q=%E3%81%BB%E3%82%93%E3%81%9D%E3%82%8C

**デフォルトの名無しさん** · 2015/12/21(月) 12:36:38.19

ただしChromeはプロセスが一杯できるから
タスクマネージャ覗いた時に気持ち悪い

**デフォルトの名無しさん** · 2015/12/21(月) 16:06:45.56

64の時代だから、そろそろCore64ぐらいでイイのでは？
http://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
http://download.intel.com/newsroom/kits/xeon/phi/gallery/images/XeonPhiDie_02.jpg

**デフォルトの名無しさん** · 2015/12/21(月) 16:21:26.45

ラーメン
http://www.chikuwachan.com/ramen/
http://www.chikuwachan.com/ramen/image/ramen/1430/10_417_512.jpg

**デフォルトの名無しさん** · 2015/12/21(月) 16:33:49.61

http://www.dospara.co.jp/ad/stick_mv.html
http://www.dospara.co.jp/ad/img/stick_mv/title_main.gif

**デフォルトの名無しさん** · 2015/12/21(月) 16:35:11.77

diginnos stickpc_02
http://www.youtube.com/watch?v=OPt0OGNQhnU&;list=RDOPt0OGNQhnU

**デフォルトの名無しさん** · 2015/12/21(月) 18:37:51.00

Holiday Glam
http://aurorawave.atspace.tv/?sop:v/tEdxHgCoXss!RDtEdxHgCoXss http://i1.ytimg.com/vi/tEdxHgCoXss/mqdefault.jpg #AuroraWaveTV

**デフォルトの名無しさん** · 2015/12/21(月) 18:38:29.84

Midnight Luster
http://aurorawave.atspace.tv/?sop:v/DBTd9qv_sJI!RDDBTd9qv_sJI http://i1.ytimg.com/vi/DBTd9qv_sJI/mqdefault.jpg #AuroraWaveTV

**デフォルトの名無しさん** · 2015/12/21(月) 18:43:07.58

Chromeの調子が良い件について・・・TCL 4K Demo: Ultra-Running Beauty
http://aurorawave.atspace.tv/?sop:v/Gg54Miwa8K4!RDHi_WWhih4n4 http://i1.ytimg.com/vi/Gg54Miwa8K4/mqdefault.jpg #AuroraWaveTV

**デフォルトの名無しさん** · 2016/01/10(日) 12:45:59.41

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のフォルダ構造検索にある
フォルダ構造検索回数を省けば速くなるのだ

**デフォルトの名無しさん** · 2016/01/10(日) 12:47:28.36

Vivaldiの起動が遅いのは
タブのサムネイルに関係しているかもしれない
Blinkは負荷分散のため？かHDDアクセスも遅いらしい
ローカルストレージ関係がとても遅いからだ
タブサムネイルを
ローカルストレージで保存するのは止めたほうがいい
タブサムネイルは直接アクセスする事
fopen();ランダム書込:fclose();ランダム読込:fopen();
読取だけならオーバーヘッドを避けるためfopen();しない
命題・・・Vivaldiは遅い起動を早期解消せよ！
ランダム書込用HDDスペースを作る　個数*固定サイズ　
１トランザクション　個数1024個、固定サイズ256kバイト　
そしたら、ランダム読み書きでfopen()すればいい
オーバーヘッドを避けるためfopen();は終了のときだけ
オーバーヘッド無いだけで1000倍ほど速くなるケースも
オーバーヘッドはドコにあるのか？
それはWindowsOSのフォルダ構造検索にある
フォルダ構造検索回数を省けば速くなるのだ

**デフォルトの名無しさん** · 2016/01/10(日) 12:52:32.51

fopen();のときフォルダ構造検索するようだ

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

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