Go language part 6 (73ﾚｽ)
上下前次1-新
1(1): 05/20(火)23:10 ID:C5OyrGcX(1) AAS
Goについて扱うスレッドです。
GoはGoogleによって開発された言語です。
公式
外部ﾘﾝｸ:golang.org
公式ドキュメント
外部ﾘﾝｸ:golang.org
公式外パッケージドキュメント
外部ﾘﾝｸ:godoc.org
ブラウザ上で試し書き
外部ﾘﾝｸ:play.golang.org
※前スレ
Go language part 5
2chｽﾚ:tech
44: 06/15(日)04:22 ID:r3H8nvWy(4/4) AAS
だから大抵の場合GC部分のみの評価になってない
(もちろんこれらの言語はそうした機能のお陰で保守性良く改良ペースが上がり結果速度向上になる場合もあるので悪いことばかりではない)
あとgoやdmdはC言語で書かれたコンパイラと比べても充分速いと思うけどね
45(1): 06/15(日)04:38 ID:sHWxg8n8(2/2) AAS
Goが必ず遅い
46(1): 06/15(日)04:44 ID:ZyRwwozc(1) AAS
>>45
横だけどGC言語が速い例(ただしJVM系はpeak-memとのバランスが悪い)
外部ﾘﾝｸ:programming-language-benchmarks.vercel.app
47(1): 06/15(日)05:43 ID:8ok6jSUv(1) AAS
Goが5倍も遅いのはなぜ？
まともなベンチに見えない
48: 06/15(日)06:29 ID:gNMJii7n(1) AAS
まともなベンチマークでGC言語が速い例は存在しないからね
49(1): 06/15(日)06:46 ID:757F+le4(3/5) AAS
>>41
> 手動で解放があることを前提とした前処理
とは何ぞ？
仕様的に、何もしなくていいと分かりきってるのなら、本当に何もしないCがどう考えても一番速い
多分お前が言ってるのは、「GCヒープに対して、手動で開放があるオブジェクトを割り当てる場合、『前処理が必要になる』」ということなのだろうが、
それはVC++のように、マネージドヒープ(=GCされるヒープ=CLR側のヒープ)と
アンマネージドヒープ(GCされないヒープ=C++側のヒープ)を明示的に分離してしまえば、実行時の『前処理』等のコストは不要となる
50(1): 06/15(日)08:34 ID:757F+le4(4/5) AAS
>>41
ところでGoは生ポなのでコンパクションは出来ないだろ
コンパクションありのGCは、フラグメンテーションを気にする必要がないので、割り当て自体は速いが、
**pになるのでpのアクセスが無駄に遅くなる
対してコンパクション無しのGCは、最低限サイズ毎の分別は必要なので、割り当て自体は多少遅くなるが、
*pでアクセス出来るので、使用時はCと同速度になる
だから、GCと一括りはまずくて、
コンパクション無しのGC: Go
コンパクションありのGC: C#/Java、多分その他もほぼこっち
と別扱いにしないといけないと思うが
この意味では、「割り当てるだけ割り当てたけど使いませんでした」なオブジェクトが多い場合(＝割と糞コード)は他GC言語と比べてGoは比較的遅くなる
例えば、ディープコピーして一部だけ変更し、他の部分はほぼ使わず破棄とか
それ以外の場合はGoの方が速いはず
51(1): 06/15(日)09:11 ID:vsQD4t+X(1/2) AAS
RustもGoも詳しくないけど、これらの言語にもRails や Django みたいなフルスタックのフレームワークってあるの？
52(1): 06/15(日)10:28 ID:ujM9EzWd(1) AAS
>>50
それは間違い
GCのコンパクションは移動対象となるオブジェクトに対する全てのオブジェクト参照のアドレスを直接更新する
>>51
あるが一般的ではない
RustやGoはバックエンドに徹し、HTMLの生成(レンダリング)はNext.jsなど別のサービスが行うのが普通
53: 06/15(日)11:42 ID:757F+le4(5/5) AAS
>>52
> GCのコンパクションは移動対象となるオブジェクトに対する全てのオブジェクト参照のアドレスを直接更新する
それはそれで凄いが、
それだとコピーの際に「参照カウンタ＋１」のみならず「コピー先アドレスも控えておく」必要があるので、コピーが重くなる
だから結局、GC方式が異なるので一緒くたには出来ないのは変わらない
まあ各者でそれぞれ一番速いと思ってる方式を採用してはいるのだろうけどね
54(1): 06/15(日)12:31 ID:aUao3Hkb(1) AAS
>>47
GC戦略の違いだよ
RustやC++もArena使って別途手動管理しないとGC言語より遅くなる典型例
55(1): 06/15(日)12:43 ID:HdrNQych(1) AAS
>>54
逆
管理を楽にするためにArenaを使う
もちろん速度も上がる
56: 06/15(日)13:57 ID:nsaCurRA(1) AAS
ﾜｯﾁｮｲの無いスレでRustの話するとすぐこれだ
57(1): 06/15(日)17:27 ID:dAJ+nMeh(1) AAS
>>46(Input depth: 18)のarena version
zig 0.55 (arena)
go 0.58 (arena)
v 0.75
go 1.59
zig 2.78
58: 06/15(日)18:20 ID:lEreEG4E(1) AAS
>>55
何の逆だよ
まさかArenaは”自動管理”とか言わないよね？
>管理を楽にするためにArenaを使う
それは比べる対象を間違えてるでしょ
59(1): 06/15(日)18:48 ID:/MYgDLVa(1) AAS
アリーナ使うと管理が楽になるのは事実
ライフタイムが統一されてめちゃ楽
60: 06/15(日)21:07 ID:vsQD4t+X(2/2) AAS
それはRust特有の事情でしかなくない？
61: 06/15(日)21:27 ID:neMcJSIx(1) AAS
同じ
arenaはownerを一本化できるためshared_ptrやRc管理をなくせて楽
62: 06/15(日)23:28 ID:woCxiWNy(1) AAS
>>59
手動リファレンスカウンティングと手動アリーナ管理を比べられてもね
Goのアリーナ使うコードと使わないコードでも比べたら？
63: 06/15(日)23:38 ID:LkTvbUTI(1) AAS
C++とRustにとってはArenaを使うと管理が楽で高速化されて良いこと尽くし
Goは手間増大か
64(1): 06/16(月)01:19 ID:vcrz/bj1(1) AAS
>>49
mallocひとつとっても解放のために確保時点でヘッダーを構成しないといけない
それに根っこから染み付いてて意識してないだろうが、きちんと後で解放できるような構造を取らなくていいならできる最適化は意外と多い
65: 06/16(月)07:43 ID:ZGVdfSpP(1/2) AAS
>>64
まず俺は40ではない(そしてGo使いでもない)
> mallocひとつとっても解放のために確保時点でヘッダーを構成しないといけない
最低限空き領域リンクリストを構成する必要があるが、
遅いのはヘッダ整備O(1)ではなく、空き領域スキャンO(n)だと思う(が、まあこれはいい)
> C言語でも同タイプの用途には特化したプールを用意して一切解放を行わない最適化戦略は行われる (41)
OOPは各オブジェクト毎にちまちまmalloc/freeしてるから遅い
プールの場合にはこれが1回で済む、ここまではいい
そして
> それに根っこから染み付いてて意識してないだろうが、きちんと後で解放できるような構造を取らなくていいならできる最適化は意外と多い
とは具体的に何？
プールだと確保/開放1回分のコストになるので、これ以上速くするにはallocaくらいしか無いと思うが
(まあ俺はalloca賛成派だし、何ならmalloc禁止でallocaだけで組めとも思うが)
66: 06/16(月)09:14 ID:ZCbjnjWl(1) AAS
>>57続き
java 0.32s 40MB graal
java 0.44s 202MB
zig 0.55s 16MB arena
go 0.58s 25MB arena
67(3): 06/16(月)20:51 ID:GI5I1Imf(1) AAS
>そしてGo使いでもない
なんでこのスレを覗いてるんですかね…？
68: 06/16(月)21:29 ID:ZGVdfSpP(2/2) AAS
>>67
お前みたいな馬鹿ではないから
69: 07/14(月)16:18 ID:ScqQ9XOL(1) AAS
>>67
使ってない言語見てもいいだろうに。
70: 07/25(金)02:43 ID:STYBTcxW(1) AAS
>>67
現実では誰も相手にしてくれない嫌われてるおじだからどこにでも顔突っ込んで荒らすのかわいい街の寂しい存在www
71(1): 11/02(日)14:59 ID:kxQN3KLf(1/2) AAS
goが言語年収ランキングで上位だけどなんでなんだろう
72: 11/02(日)15:00 ID:kxQN3KLf(2/2) AAS
てかなんでdockerてgoで作ろうと思ったんやろう
73: 11/03(月)10:08 ID:3zDb1MP2(1) AAS
>>71
「Goを使うと年収が上がる」ではなく、「年収の高い組織においてGoが使われてる」ということだと思うよ
Goを最も使ってる組織は Google だから Google 社員の給料に引っ張られるみたいな話
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.588s*