Go language part 6 (70ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
37(1): デフォルトの名無しさん [sage] 2025/06/15(日) 01:14:15.92 ID:757F+le4(1/5) AAS
>>3535(1): デフォルトの名無しさん [sage] 2025/06/15(日) 00:24:06.66 ID:lIZk6VUi(1) AAS
>>26
>単なる循環参照(親→子→親で、まとめて廃棄可能＝寿命が同一のオブジェクト間の相互参照…Rustでも楽勝)
親→子→親の構造を表現するためにはRc/RefCell/WeakRefの組み合わせみたいなのが必須
何も気にせず全自動でやってくれる言語と比べれば相当面倒くさいよ
要は前者でも後者でも基本同じ
>A->Response
>B->Response
これがAがResponseを参照している、BがResponseを参照しているの意味なら
AやBより先に他の誰かがResponseを生成して所有しているはずで
その誰かはAやBより長生きするんだから何の問題もないよ
Rustだからといって面倒くさくなるパターンでもない
> 親→子→親の構造を表現するためには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の方法でメモリ管理するのは無理だと思ってる)
38: デフォルトの名無しさん [sage] 2025/06/15(日) 01:41:02.18 ID:757F+le4(2/5) AAS
>>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なわけだが
49(1): デフォルトの名無しさん [sage] 2025/06/15(日) 06:46:13.05 ID:757F+le4(3/5) AAS
>>4141(2): デフォルトの名無しさん [sage] 2025/06/15(日) 03:57:51.31 ID:r3H8nvWy(2/4) AAS
>>40
そんなことはない。ヒープの構造はGCのほうがコンパクションを前提にできるのでシンプルで割り当ても速いし
手動で解放があることを前提とした前処理も不要になる
C言語でも同タイプの用途には特化したプールを用意して一切解放を行わない最適化戦略は行われる
> 手動で解放があることを前提とした前処理
とは何ぞ？
仕様的に、何もしなくていいと分かりきってるのなら、本当に何もしないCがどう考えても一番速い
多分お前が言ってるのは、「GCヒープに対して、手動で開放があるオブジェクトを割り当てる場合、『前処理が必要になる』」ということなのだろうが、
それはVC++のように、マネージドヒープ(=GCされるヒープ=CLR側のヒープ)と
アンマネージドヒープ(GCされないヒープ=C++側のヒープ)を明示的に分離してしまえば、実行時の『前処理』等のコストは不要となる
50(1): デフォルトの名無しさん [sage] 2025/06/15(日) 08:34:30.23 ID:757F+le4(4/5) AAS
>>41
ところでGoは生ポなのでコンパクションは出来ないだろ
コンパクションありのGCは、フラグメンテーションを気にする必要がないので、割り当て自体は速いが、
**pになるのでpのアクセスが無駄に遅くなる
対してコンパクション無しのGCは、最低限サイズ毎の分別は必要なので、割り当て自体は多少遅くなるが、
*pでアクセス出来るので、使用時はCと同速度になる
だから、GCと一括りはまずくて、
コンパクション無しのGC: Go
コンパクションありのGC: C#/Java、多分その他もほぼこっち
と別扱いにしないといけないと思うが
この意味では、「割り当てるだけ割り当てたけど使いませんでした」なオブジェクトが多い場合(＝割と糞コード)は他GC言語と比べてGoは比較的遅くなる
例えば、ディープコピーして一部だけ変更し、他の部分はほぼ使わず破棄とか
それ以外の場合はGoの方が速いはず
53: デフォルトの名無しさん [sage] 2025/06/15(日) 11:42:31.83 ID:757F+le4(5/5) AAS
>>5252(1): デフォルトの名無しさん [sage] 2025/06/15(日) 10:28:32.52 ID:ujM9EzWd(1) AAS
>>50
それは間違い
GCのコンパクションは移動対象となるオブジェクトに対する全てのオブジェクト参照のアドレスを直接更新する
>>51
あるが一般的ではない
RustやGoはバックエンドに徹し、HTMLの生成(レンダリング)はNext.jsなど別のサービスが行うのが普通
> GCのコンパクションは移動対象となるオブジェクトに対する全てのオブジェクト参照のアドレスを直接更新する
それはそれで凄いが、
それだとコピーの際に「参照カウンタ＋１」のみならず「コピー先アドレスも控えておく」必要があるので、コピーが重くなる
だから結局、GC方式が異なるので一緒くたには出来ないのは変わらない
まあ各者でそれぞれ一番速いと思ってる方式を採用してはいるのだろうけどね
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.647s*