Go language part 6

**デフォルトの名無しさん** · 2025/06/15(日) 21:07:20.22

それはRust特有の事情でしかなくない？

**デフォルトの名無しさん** · 2025/06/15(日) 21:27:39.74

同じ
arenaはownerを一本化できるためshared_ptrやRc管理をなくせて楽

**デフォルトの名無しさん** · 2025/06/15(日) 23:28:01.42

>>59
手動リファレンスカウンティングと手動アリーナ管理を比べられてもね
Goのアリーナ使うコードと使わないコードでも比べたら？

**デフォルトの名無しさん** · 2025/06/15(日) 23:38:51.16

C++とRustにとってはArenaを使うと管理が楽で高速化されて良いこと尽くし
Goは手間増大か

**デフォルトの名無しさん** · 2025/06/16(月) 01:19:26.26

>>49
mallocひとつとっても解放のために確保時点でヘッダーを構成しないといけない
それに根っこから染み付いてて意識してないだろうが、きちんと後で解放できるような構造を取らなくていいならできる最適化は意外と多い

**デフォルトの名無しさん** · 2025/06/16(月) 07:43:44.87

>>64
まず俺は40ではない(そしてGo使いでもない)
> mallocひとつとっても解放のために確保時点でヘッダーを構成しないといけない
最低限空き領域リンクリストを構成する必要があるが、
遅いのはヘッダ整備O(1)ではなく、空き領域スキャンO(n)だと思う(が、まあこれはいい)
> C言語でも同タイプの用途には特化したプールを用意して一切解放を行わない最適化戦略は行われる (41)
OOPは各オブジェクト毎にちまちまmalloc/freeしてるから遅い
プールの場合にはこれが1回で済む、ここまではいい

そして
> それに根っこから染み付いてて意識してないだろうが、きちんと後で解放できるような構造を取らなくていいならできる最適化は意外と多い
とは具体的に何？
プールだと確保/開放1回分のコストになるので、これ以上速くするにはallocaくらいしか無いと思うが
(まあ俺はalloca賛成派だし、何ならmalloc禁止でallocaだけで組めとも思うが)

**デフォルトの名無しさん** · 2025/06/16(月) 09:14:01.69

>>57続き
java 0.32s 40MB graal
java 0.44s 202MB
zig 0.55s 16MB arena
go 0.58s 25MB arena

**デフォルトの名無しさん** · 2025/06/16(月) 20:51:33.51

>そしてGo使いでもない
なんでこのスレを覗いてるんですかね…？

**デフォルトの名無しさん** · 2025/06/16(月) 21:29:49.53

>>67
お前みたいな馬鹿ではないから

**デフォルトの名無しさん** · 2025/07/14(月) 16:18:19.14

>>67
使ってない言語見てもいいだろうに。

**デフォルトの名無しさん** · 2025/07/25(金) 02:43:51.32

>>67
現実では誰も相手にしてくれない嫌われてるおじだからどこにでも顔突っ込んで荒らすのかわいい街の寂しい存在www

**デフォルトの名無しさん** · 2025/11/02(日) 14:59:56.69

goが言語年収ランキングで上位だけどなんでなんだろう

**デフォルトの名無しさん** · 2025/11/02(日) 15:00:46.79

てかなんでdockerてgoで作ろうと思ったんやろう

**デフォルトの名無しさん** · 2025/11/03(月) 10:08:44.01

>>71
「Goを使うと年収が上がる」ではなく、「年収の高い組織においてGoが使われてる」ということだと思うよ
Goを最も使ってる組織は Google だから Google 社員の給料に引っ張られるみたいな話