Go language part 6 (70ﾚｽ)
Go language part 6 http://mevius.5ch.net/test/read.cgi/tech/1747750228/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
必死ﾁｪｯｶｰ(本家)
(べ)
自ID
ﾚｽ栞
あぼーん
37: デフォルトの名無しさん [sage] 2025/06/15(日) 01:14:15.92 ID:757F+le4 >>35 > 親→子→親の構造を表現するためにはRc/RefCell/WeakRefの組み合わせみたいなのが必須 それがarenaで簡単になるらしいぞ、詳しくは知らんが > これがAがResponseを参照している、BがResponseを参照しているの意味なら そうだが、 > AやBより先に他の誰かがResponseを生成して所有しているはずで これはその下のCの話になってる 問題が起きるケースは、 A->Response のオブジェクトAがあり、 オブジェクトBにもResponseの参照が欲しくなったので、B->Responseをつけようとするが、 この際に、元のAと追加するBのオブジェクトの寿命が別々に管理されており、どちらが長いか判断できない場合 だから上位なりで確実にAとBの寿命を内包する階層や > 他の誰か を作り、それで管理するという話 Rustのコードなんて書けんし、Goでも怪しいからJSで書いておくと、(この辺正確にしておかないと余計に混乱するだろうから) function add_ref(A,B){ B.Response = A.Response; return [A,B]; // 2値返し } とBにAのプロパティをコピーするだけのマヌケな関数で、AもBも所有権を渡された場合に、書きようがないだろ だからおそらく上位でこういうことがないように対応するはずだが ただ調べてたら Leakpocalypse が2015年に発見されて、それ以来「Rustではメモリリークは防げません」になってるようだな まあ俺はRustは死ぬと見てるし、ザマアとしか思えないが (Rustの方法でメモリ管理するのは無理だと思ってる) http://mevius.5ch.net/test/read.cgi/tech/1747750228/37
38: デフォルトの名無しさん [sage] 2025/06/15(日) 01:41:02.18 ID:757F+le4 >>37、例を修正、 (まあ俺がRustに詳しいわけではないからコンセプトだけだが、) function add_ref(Response, A, B){ // Response,A,Bはすべて所有権を与えられるとする A.Response = Response; // この辺が書けない B.Response = Response; // この辺が書けない return [A,B]; // 2値返し、A,Bのどちらが長寿命かはわからない } かな。Responseが与えられ、A,Bにそれぞれ参照を付加するだけだが、 Responseオブジェクトの寿命(所有権？)をどちらに与えればよいか分からない だからまるごと管理してしまえってのがCなりarenaなのだろうし、 無理やりでも個別に管理して1バイトも無駄にしない、というのがRc/RefCell/WeakRefで、 これを全自動でやってくれるのがGCなわけだが http://mevius.5ch.net/test/read.cgi/tech/1747750228/38
49: デフォルトの名無しさん [sage] 2025/06/15(日) 06:46:13.05 ID:757F+le4 >>41 > 手動で解放があることを前提とした前処理 とは何ぞ？ 仕様的に、何もしなくていいと分かりきってるのなら、本当に何もしないCがどう考えても一番速い 多分お前が言ってるのは、「GCヒープに対して、手動で開放があるオブジェクトを割り当てる場合、『前処理が必要になる』」ということなのだろうが、 それはVC++のように、マネージドヒープ(=GCされるヒープ=CLR側のヒープ)と アンマネージドヒープ(GCされないヒープ=C++側のヒープ)を明示的に分離してしまえば、実行時の『前処理』等のコストは不要となる http://mevius.5ch.net/test/read.cgi/tech/1747750228/49
50: デフォルトの名無しさん [sage] 2025/06/15(日) 08:34:30.23 ID:757F+le4 >>41 ところでGoは生ポなのでコンパクションは出来ないだろ コンパクションありのGCは、フラグメンテーションを気にする必要がないので、割り当て自体は速いが、 **pになるのでpのアクセスが無駄に遅くなる 対してコンパクション無しのGCは、最低限サイズ毎の分別は必要なので、割り当て自体は多少遅くなるが、 *pでアクセス出来るので、使用時はCと同速度になる だから、GCと一括りはまずくて、 コンパクション無しのGC: Go コンパクションありのGC: C#/Java、多分その他もほぼこっち と別扱いにしないといけないと思うが この意味では、「割り当てるだけ割り当てたけど使いませんでした」なオブジェクトが多い場合(＝割と糞コード)は他GC言語と比べてGoは比較的遅くなる 例えば、ディープコピーして一部だけ変更し、他の部分はほぼ使わず破棄とか それ以外の場合はGoの方が速いはず http://mevius.5ch.net/test/read.cgi/tech/1747750228/50
53: デフォルトの名無しさん [sage] 2025/06/15(日) 11:42:31.83 ID:757F+le4 >>52 > GCのコンパクションは移動対象となるオブジェクトに対する全てのオブジェクト参照のアドレスを直接更新する それはそれで凄いが、 それだとコピーの際に「参照カウンタ＋１」のみならず「コピー先アドレスも控えておく」必要があるので、コピーが重くなる だから結局、GC方式が異なるので一緒くたには出来ないのは変わらない まあ各者でそれぞれ一番速いと思ってる方式を採用してはいるのだろうけどね http://mevius.5ch.net/test/read.cgi/tech/1747750228/53
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.572s*