Go language part 6 (70レス)
前次1-
抽出解除 必死チェッカー(本家) (べ) 自ID レス栞 あぼーん

39
(1): デフォルトの名無しさん [sage] 2025/06/15(日) 03:34:28.75 ID:r3H8nvWy(1/4) AAS
コンパイラというのは数少ないGC有りのほうが有利な分野
全力で駆け抜けて終了するまでに一度もコンパクションが発生しなければメモリ管理のコストを丸ごと踏み倒せてGC無し言語よりも速くなる
41
(2): デフォルトの名無しさん [sage] 2025/06/15(日) 03:57:51.31 ID:r3H8nvWy(2/4) AAS
>>40
そんなことはない。ヒープの構造はGCのほうがコンパクションを前提にできるのでシンプルで割り当ても速いし
手動で解放があることを前提とした前処理も不要になる
C言語でも同タイプの用途には特化したプールを用意して一切解放を行わない最適化戦略は行われる
43: デフォルトの名無しさん [sage] 2025/06/15(日) 04:08:44.02 ID:r3H8nvWy(3/4) AAS
>>42
既存のGC有り言語は大抵他の凝った機能を備えていてそのペナルティが大きい
JITは勿論、Goならゴルーチン、Haskellなら辞書によるディスパッチ、OCamlなら値の1ビットをタグにしてる
D言語は保守的GCなのでGC特有の最適化が充分にできない等
純粋にGC有りC言語として評価できる言語は実はあんまりない
44: デフォルトの名無しさん [sage] 2025/06/15(日) 04:22:57.87 ID:r3H8nvWy(4/4) AAS
だから大抵の場合GC部分のみの評価になってない
(もちろんこれらの言語はそうした機能のお陰で保守性良く改良ペースが上がり結果速度向上になる場合もあるので悪いことばかりではない)

あとgoやdmdはC言語で書かれたコンパイラと比べても充分速いと思うけどね
前次1-
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル

ぬこの手 ぬこTOP 0.640s*