Go language part 6 (70ﾚｽ)
Go language part 6 http://mevius.5ch.net/test/read.cgi/tech/1747750228/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
ﾘﾛｰﾄﾞ規制
です｡10分ほどで解除するので､
他のﾌﾞﾗｳｻﾞ
へ避難してください｡
46: デフォルトの名無しさん [sage] 2025/06/15(日) 04:44:29.40 ID:ZyRwwozc >>45 横だけどGC言語が速い例(ただしJVM系はpeak-memとのバランスが悪い) https://programming-language-benchmarks.vercel.app/problem/binarytrees http://mevius.5ch.net/test/read.cgi/tech/1747750228/46
47: デフォルトの名無しさん [sage] 2025/06/15(日) 05:43:13.21 ID:8ok6jSUv Goが5倍も遅いのはなぜ？ まともなベンチに見えない http://mevius.5ch.net/test/read.cgi/tech/1747750228/47
48: デフォルトの名無しさん [sage] 2025/06/15(日) 06:29:15.12 ID:gNMJii7n まともなベンチマークでGC言語が速い例は存在しないからね http://mevius.5ch.net/test/read.cgi/tech/1747750228/48
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
51: デフォルトの名無しさん [sage] 2025/06/15(日) 09:11:35.32 ID:vsQD4t+X RustもGoも詳しくないけど、これらの言語にもRails や Django みたいなフルスタックのフレームワークってあるの？ http://mevius.5ch.net/test/read.cgi/tech/1747750228/51
52: デフォルトの名無しさん [sage] 2025/06/15(日) 10:28:32.52 ID:ujM9EzWd >>50 それは間違い GCのコンパクションは移動対象となるオブジェクトに対する全てのオブジェクト参照のアドレスを直接更新する >>51 あるが一般的ではない RustやGoはバックエンドに徹し、HTMLの生成(レンダリング)はNext.jsなど別のサービスが行うのが普通 http://mevius.5ch.net/test/read.cgi/tech/1747750228/52
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
54: デフォルトの名無しさん [sage] 2025/06/15(日) 12:31:52.55 ID:aUao3Hkb >>47 GC戦略の違いだよ RustやC++もArena使って別途手動管理しないとGC言語より遅くなる典型例 http://mevius.5ch.net/test/read.cgi/tech/1747750228/54
55: デフォルトの名無しさん [sage] 2025/06/15(日) 12:43:40.73 ID:HdrNQych >>54 逆 管理を楽にするためにArenaを使う もちろん速度も上がる http://mevius.5ch.net/test/read.cgi/tech/1747750228/55
56: デフォルトの名無しさん [sage] 2025/06/15(日) 13:57:26.71 ID:nsaCurRA ﾜｯﾁｮｲの無いスレでRustの話するとすぐこれだ http://mevius.5ch.net/test/read.cgi/tech/1747750228/56
57: デフォルトの名無しさん [sage] 2025/06/15(日) 17:27:15.63 ID:dAJ+nMeh >>46(Input depth: 18)のarena version zig 0.55 (arena) go 0.58 (arena) v 0.75 go 1.59 zig 2.78 http://mevius.5ch.net/test/read.cgi/tech/1747750228/57
58: デフォルトの名無しさん [sage] 2025/06/15(日) 18:20:07.09 ID:lEreEG4E >>55 何の逆だよ まさかArenaは”自動管理”とか言わないよね？ >管理を楽にするためにArenaを使う それは比べる対象を間違えてるでしょ http://mevius.5ch.net/test/read.cgi/tech/1747750228/58
59: デフォルトの名無しさん [sage] 2025/06/15(日) 18:48:04.01 ID:/MYgDLVa アリーナ使うと管理が楽になるのは事実 ライフタイムが統一されてめちゃ楽 http://mevius.5ch.net/test/read.cgi/tech/1747750228/59
60: デフォルトの名無しさん [sage] 2025/06/15(日) 21:07:20.22 ID:vsQD4t+X それはRust特有の事情でしかなくない？ http://mevius.5ch.net/test/read.cgi/tech/1747750228/60
61: デフォルトの名無しさん [sage] 2025/06/15(日) 21:27:39.74 ID:neMcJSIx 同じ arenaはownerを一本化できるためshared_ptrやRc管理をなくせて楽 http://mevius.5ch.net/test/read.cgi/tech/1747750228/61
62: デフォルトの名無しさん [sage] 2025/06/15(日) 23:28:01.42 ID:woCxiWNy >>59 手動リファレンスカウンティングと手動アリーナ管理を比べられてもね Goのアリーナ使うコードと使わないコードでも比べたら？ http://mevius.5ch.net/test/read.cgi/tech/1747750228/62
63: デフォルトの名無しさん [sage] 2025/06/15(日) 23:38:51.16 ID:LkTvbUTI C++とRustにとってはArenaを使うと管理が楽で高速化されて良いこと尽くし Goは手間増大か http://mevius.5ch.net/test/read.cgi/tech/1747750228/63
64: デフォルトの名無しさん [sage] 2025/06/16(月) 01:19:26.26 ID:vcrz/bj1 >>49 mallocひとつとっても解放のために確保時点でヘッダーを構成しないといけない それに根っこから染み付いてて意識してないだろうが、きちんと後で解放できるような構造を取らなくていいならできる最適化は意外と多い http://mevius.5ch.net/test/read.cgi/tech/1747750228/64
65: デフォルトの名無しさん [sage] 2025/06/16(月) 07:43:44.87 ID:ZGVdfSpP >>64 まず俺は40ではない(そしてGo使いでもない) > mallocひとつとっても解放のために確保時点でヘッダーを構成しないといけない 最低限空き領域リンクリストを構成する必要があるが、 遅いのはヘッダ整備O(1)ではなく、空き領域スキャンO(n)だと思う(が、まあこれはいい) > C言語でも同タイプの用途には特化したプールを用意して一切解放を行わない最適化戦略は行われる (41) OOPは各オブジェクト毎にちまちまmalloc/freeしてるから遅い プールの場合にはこれが1回で済む、ここまではいい そして > それに根っこから染み付いてて意識してないだろうが、きちんと後で解放できるような構造を取らなくていいならできる最適化は意外と多い とは具体的に何？ プールだと確保/開放1回分のコストになるので、これ以上速くするにはallocaくらいしか無いと思うが (まあ俺はalloca賛成派だし、何ならmalloc禁止でallocaだけで組めとも思うが) http://mevius.5ch.net/test/read.cgi/tech/1747750228/65
66: デフォルトの名無しさん [sage] 2025/06/16(月) 09:14:01.69 ID:ZCbjnjWl >>57続き java 0.32s 40MB graal java 0.44s 202MB zig 0.55s 16MB arena go 0.58s 25MB arena http://mevius.5ch.net/test/read.cgi/tech/1747750228/66
67: デフォルトの名無しさん [sage] 2025/06/16(月) 20:51:33.51 ID:GI5I1Imf >そしてGo使いでもない なんでこのスレを覗いてるんですかね…？ http://mevius.5ch.net/test/read.cgi/tech/1747750228/67
68: デフォルトの名無しさん [sage] 2025/06/16(月) 21:29:49.53 ID:ZGVdfSpP >>67 お前みたいな馬鹿ではないから http://mevius.5ch.net/test/read.cgi/tech/1747750228/68
69: デフォルトの名無しさん [sage] 2025/07/14(月) 16:18:19.14 ID:ScqQ9XOL >>67 使ってない言語見てもいいだろうに。 http://mevius.5ch.net/test/read.cgi/tech/1747750228/69
70: デフォルトの名無しさん [] 2025/07/25(金) 02:43:51.32 ID:STYBTcxW >>67 現実では誰も相手にしてくれない嫌われてるおじだからどこにでも顔突っ込んで荒らすのかわいい街の寂しい存在www http://mevius.5ch.net/test/read.cgi/tech/1747750228/70
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.027s