25/06/15 08:34:30.23 757F+le4.net
>>41
ところでGoは生ポなのでコンパクションは出来ないだろ
コンパクションありのGCは、フラグメンテーションを気にする必要がないので、割り当て自体は速いが、
**pになるのでpのアクセスが無駄に遅くなる
対してコンパクション無しのGCは、最低限サイズ毎の分別は必要なので、割り当て自体は多少遅くなるが、
*pでアクセス出来るので、使用時はCと同速度になる
だから、GCと一括りはまずくて、
コンパクション無しのGC: Go
コンパクションありのGC: C#/Java、多分その他もほぼこっち
と別扱いにしないといけないと思うが
この意味では、「割り当てるだけ割り当てたけど使いませんでした」なオブジェクトが多い場合(＝割と糞コード)は他GC言語と比べてGoは比較的遅くなる
例えば、ディープコピーして一部だけ変更し、他の部分はほぼ使わず破棄とか
それ以外の場合はGoの方が速いはず
51:デフォルトの名無しさん
25/06/15 09:11:35.32 vsQD4t+X.net
RustもGoも詳しくないけど、これらの言語にもRails や Django みたいなフルスタックのフレームワークってあるの？
52:デフォルトの名無しさん
25/06/15 10:28:32.52 ujM9EzWd.net
>>50
それは間違い
GCのコンパクションは移動対象となるオブジェクトに対する全てのオブジェクト参照のアドレスを直接更新する
>>51
あるが一般的ではない
RustやGoはバックエンドに徹し、HTMLの生成(レンダリング)はNext.jsなど別のサービスが行うのが普通
53:デフォルトの名無しさん
25/06/15 11:42:31.83 757F+le4.net
>>52
> GCのコンパクションは移動対象となるオブジェクトに対する全てのオブジェクト参照のアドレスを直接更新する
それはそれで凄いが、
それだとコピーの際に「参照カウンタ＋１」のみならず「コピー先アドレスも控えておく」必要があるので、コピーが重くなる
だから結局、GC方式が異なるので一緒くたには出来ないのは変わらない
まあ各者でそれぞれ一番速いと思ってる方式を採用してはいるのだろうけどね
54:デフォルトの名無しさん
25/06/15 12:31:52.55 aUao3Hkb.net
>>47
GC戦略の違いだよ
RustやC++もArena使って別途手動管理しないとGC言語より遅くなる典型例
55:デフォルトの名無しさん
25/06/15 12:43:40.73 HdrNQych.net
>>54
逆
管理を楽にするためにArenaを使う
もちろん速度も上がる
56:デフォルトの名無しさん
25/06/15 13:57:26.71 nsaCurRA.net
ﾜｯﾁｮｲの無いスレでRustの話するとすぐこれだ
57:デフォルトの名無しさん
25/06/15 17:27:15.63 dAJ+nMeh.net
>>46(Input depth: 18)のarena version
zig 0.55 (arena)
go 0.58 (arena)
v 0.75
go 1.59
zig 2.78
58:デフォルトの名無しさん
25/06/15 18:20:07.09 lEreEG4E.net
>>55
何の逆だよ
まさかArenaは”自動管理”とか言わないよね？
>管理を楽にするためにArenaを使う
それは比べる対象を間違えてるでしょ
59:デフォルトの名無しさん
25/06/15 18:48:04.01 /MYgDLVa.net
アリーナ使うと管理が楽になるのは事実
ライフタイムが統一されてめちゃ楽
60:デフォルトの名無しさん
25/06/15 21:07:20.22 vsQD4t+X.net
それはRust特有の事情でしかなくない？
61:デフォルトの名無しさん
25/06/15 21:27:39.74 neMcJSIx.net
同じ
arenaはownerを一本化できるためshared_ptrやRc管理をなくせて楽
62:デフォルトの名無しさん
25/06/15 23:28:01.42 woCxiWNy.net
>>59
手動リファレンスカウンティングと手動アリーナ管理を比べられてもね
Goのアリーナ使うコードと使わないコードでも比べたら？
63:デフォルトの名無しさん
25/06/15 23:38:51.16 LkTvbUTI.net
C++とRustにとってはArenaを使うと管理が楽で高速化されて良いこと尽くし
Goは手間増大か
64:デフォルトの名無しさん
25/06/16 01:19:26.26 vcrz/bj1.net
>>49
mallocひとつとっても解放のために確保時点でヘッダーを構成しないといけない
それに根っこから染み付いてて意識してないだろうが、きちんと後で解放できるような構造を取らなくていいならできる最適化は意外と多い
65:デフォルトの名無しさん
25/06/16 07:43:44.87 ZGVdfSpP.net
>>64
まず俺は40ではない(そしてGo使いでもない)
> mallocひとつとっても解放のために確保時点でヘッダーを構成しないといけない
最低限空き領域リンクリストを構成する必要があるが、
遅いのはヘッダ整備O(1)ではなく、空き領域スキャンO(n)だと思う(が、まあこれはいい)
> C言語でも同タイプの用途には特化したプールを用意して一切解放を行わない最適化戦略は行われる (41)
OOPは各オブジェクト毎にちまちまmalloc/freeしてるから遅い
プールの場合にはこれが1回で済む、ここまではいい
そして
> それに根っこから染み付いてて意識してないだろうが、きちんと後で解放できるような構造を取らなくていいならできる最適化は意外と多い
とは具体的に何？
プールだと確保/開放1回分のコストになるので、これ以上速くするにはallocaくらいしか無いと思うが
(まあ俺はalloca賛成派だし、何ならmalloc禁止でallocaだけで組めとも思うが)
66:デフォルトの名無しさん
25/06/16 09:14:01.69 ZCbjnjWl.net
>>57続き
java 0.32s 40MB graal
java 0.44s 202MB
zig 0.55s 16MB arena
go 0.58s 25MB arena
67:デフォルトの名無しさん
25/06/16 20:51:33.51 GI5I1Imf.net
>そしてGo使いでもない
なんでこのスレを覗いてるんですかね…？
68:デフォルトの名無しさん
25/06/16 21:29:49.53 ZGVdfSpP.net
>>67
お前みたいな馬鹿ではないから
69:デフォルトの名無しさん
25/07/14 16:18:19.14 ScqQ9XOL.net
>>67
使ってない言語見てもいいだろうに。
70:デフォルトの名無しさん
25/07/25 02:43:51.32 STYBTcxW.net
>>67
現実では誰も相手にしてくれない嫌われてるおじだからどこにでも顔突っ込んで荒らすのかわいい街の寂しい存在www