Go language part 6

**デフォルトの名無しさん** · 2025/06/14(土) 23:10:53.20

>>27
回避可能か不可能かの問題ではない
移植にあたっては、絶対に既存の挙動を変えないために、一行一行単位の逐次翻訳を行なっている
Rustでそれができると思うならアンダース氏に凸撃してきたらいい

**デフォルトの名無しさん** · 2025/06/14(土) 23:21:32.37

>>23
ああ確かにRustで駄目な理由を述べてるだけで、Rustにするとは言ってないな
不用意に信者を召喚してしまう発言は申し訳なかった
(が、まあ、そこは本筋ではない)

>>25
そこはそう言ってるが、ASTなんてただの木構造だし、相互に複雑に参照されたところで、寿命は同一だろ
(＝その中のオブジェクトの全てはソースコードの寿命と同じ)
だから全く問題にならない
全部のオブジェクトをルート点の寿命で管理すればいいだけだし、何ならこれはただのグローバルだろ
C++的に参照カウンタで管理した場合は無駄にクソ遅くなるが、これはGCなGoでも同じ
Rust的に代入/参照する際にいちいち寿命管理しろと言われたら、手間が全く無駄なだけだが、グローバルにも出来たはず
まあ最初からグローバルと分かりきってるなら、Cが一番楽ということになるが

ソースコード(当然静的)を解析してASTを作りました、なら、
当たり前だが各オブジェクトはソースコードの寿命以上にはならないので、苦労することはないよ

func somefunc(){
// ソースコード読み込み
// AST木生成
// いろいろ処理
// AST木破棄
}

にしかならんだろ
複雑な循環参照はそりゃあるのだろうが、問題になるのは、
『寿命の異なるオブジェクト間の』複雑な循環参照であってね、26のとおり

**デフォルトの名無しさん** · 2025/06/14(土) 23:35:56.94

>>28
> 移植にあたっては、絶対に既存の挙動を変えないために、一行一行単位の逐次翻訳を行なっている
これなら納得だが、なら最初からそう言えよヘルズバーグ、とは思う
ただまあ、「TSの方が型が多くて、enumのないGoでは‥」と似たようなことは言ってたが
(多分そもそもこの動画がTSer向けで、界隈の状況をある程度知ってる前提で、
俺みたいな門外漢が見る用には出来てないのだろう)

逐次変換するなら、機能的にスーパーセットでないと厳しいので、Rustは論外、Cもまあ無理、
C++は多分行けるはず、C#もおそらく可能、でもGoが一番マシ、というのは分かるかも
(しかし厳密に逐次変換を目指すなら《無駄に全部入りの》C++が常道だとも思うが)

**デフォルトの名無しさん** · 2025/06/14(土) 23:43:33.04

>>7
それは特殊なケースだから一般的にGoを採用する理由にはならない

今回は正確には移植による言語移行ではない
約5万行のchecker.tsで実装されていてそのままTSのCompiler API として公開されていてこれも維持を継続しなければならない
それに加えて並行して別言語によるスピードアップを叶えることが目的
つまりTSと別言語のソースコード二重管理となる負荷を最も下げられることが最重要という特殊な条件がある

C#ではクラスベースとなるためTSから大きく書き換える必要性から条件に合わない
CやRustはその点では問題ないがGCに任せている部分を新たに対応することになるため条件に合わない
そこで今回の条件ではたまたまGoが合致して採用に至っている

もし単なる移植ならば設定から見直し効率よくRustで書けばもっとスピードアップできたであろう

**デフォルトの名無しさん** · 2025/06/14(土) 23:54:18.51

>>31
> つまりTSと別言語のソースコード二重管理となる負荷を最も下げられることが最重要という特殊な条件がある
無いぞ
ブログの方見れば分かるが、
https://devblogs.microsoft.com/typescript/typescript-native-port/
JSはTS6.xで止め、TS7.0はGo、の予定だ
(JSベースのTS7.x系が出る予定はない)

そしてRust信者は死ね

**デフォルトの名無しさん** · 2025/06/14(土) 23:57:18.48

元のTSコードと合わせる必要がないならC#でも問題ないよ
だからGoにする必要がない

**デフォルトの名無しさん** · 2025/06/14(土) 23:59:27.91

>>26
Rustでもアリーナ管理すればよいため循環があろうと大丈夫だよ

**デフォルトの名無しさん** · 2025/06/15(日) 00:24:06.66

>>26
>単なる循環参照(親→子→親で、まとめて廃棄可能＝寿命が同一のオブジェクト間の相互参照…Rustでも楽勝)
親→子→親の構造を表現するためにはRc/RefCell/WeakRefの組み合わせみたいなのが必須
何も気にせず全自動でやってくれる言語と比べれば相当面倒くさいよ
要は前者でも後者でも基本同じ

>A->Response
>B->Response
これがAがResponseを参照している、BがResponseを参照しているの意味なら
AやBより先に他の誰かがResponseを生成して所有しているはずで
その誰かはAやBより長生きするんだから何の問題もないよ
Rustだからといって面倒くさくなるパターンでもない

**デフォルトの名無しさん** · 2025/06/15(日) 00:53:43.71

TSで循環定義が書けるからコンパイラも同じ構造のまま扱いたいだけでは

**デフォルトの名無しさん** · 2025/06/15(日) 01:14:15.92

>>35
> 親→子→親の構造を表現するためにはRc/RefCell/WeakRefの組み合わせみたいなのが必須
それがarenaで簡単になるらしいぞ、詳しくは知らんが

> これがAがResponseを参照している、BがResponseを参照しているの意味なら
そうだが、
> AやBより先に他の誰かがResponseを生成して所有しているはずで
これはその下のCの話になってる

問題が起きるケースは、
A->Response のオブジェクトAがあり、
オブジェクトBにもResponseの参照が欲しくなったので、B->Responseをつけようとするが、
この際に、元のAと追加するBのオブジェクトの寿命が別々に管理されており、どちらが長いか判断できない場合
だから上位なりで確実にAとBの寿命を内包する階層や
> 他の誰か
を作り、それで管理するという話

Rustのコードなんて書けんし、Goでも怪しいからJSで書いておくと、(この辺正確にしておかないと余計に混乱するだろうから)

function add_ref(A,B){
B.Response = A.Response;
return [A,B]; // 2値返し
}

とBにAのプロパティをコピーするだけのマヌケな関数で、AもBも所有権を渡された場合に、書きようがないだろ
だからおそらく上位でこういうことがないように対応するはずだが

ただ調べてたら Leakpocalypse が2015年に発見されて、それ以来「Rustではメモリリークは防げません」になってるようだな
まあ俺はRustは死ぬと見てるし、ザマアとしか思えないが
(Rustの方法でメモリ管理するのは無理だと思ってる)

**デフォルトの名無しさん** · 2025/06/15(日) 01:41:02.18

>>37、例を修正、
(まあ俺がRustに詳しいわけではないからコンセプトだけだが、)

function add_ref(Response, A, B){ // Response,A,Bはすべて所有権を与えられるとする
A.Response = Response; // この辺が書けない
B.Response = Response; // この辺が書けない
return [A,B]; // 2値返し、A,Bのどちらが長寿命かはわからない
}

かな。Responseが与えられ、A,Bにそれぞれ参照を付加するだけだが、
Responseオブジェクトの寿命(所有権？)をどちらに与えればよいか分からない
だからまるごと管理してしまえってのがCなりarenaなのだろうし、
無理やりでも個別に管理して1バイトも無駄にしない、というのがRc/RefCell/WeakRefで、
これを全自動でやってくれるのがGCなわけだが

**デフォルトの名無しさん** · 2025/06/15(日) 03:34:28.75

コンパイラというのは数少ないGC有りのほうが有利な分野
全力で駆け抜けて終了するまでに一度もコンパクションが発生しなければメモリ管理のコストを丸ごと踏み倒せてGC無し言語よりも速くなる

**デフォルトの名無しさん** · 2025/06/15(日) 03:49:42.94

>>39
それは初心者がよくする勘違い
GC言語は常に不利で遅くなる

**デフォルトの名無しさん** · 2025/06/15(日) 03:57:51.31

>>40
そんなことはない。ヒープの構造はGCのほうがコンパクションを前提にできるのでシンプルで割り当ても速いし
手動で解放があることを前提とした前処理も不要になる
C言語でも同タイプの用途には特化したプールを用意して一切解放を行わない最適化戦略は行われる

**デフォルトの名無しさん** · 2025/06/15(日) 04:03:23.77

GCしなくてもGC言語が遅い
だから速いコンパイラはGC言語で書かれていない

**デフォルトの名無しさん** · 2025/06/15(日) 04:08:44.02

>>42
既存のGC有り言語は大抵他の凝った機能を備えていてそのペナルティが大きい
JITは勿論、Goならゴルーチン、Haskellなら辞書によるディスパッチ、OCamlなら値の1ビットをタグにしてる
D言語は保守的GCなのでGC特有の最適化が充分にできない等
純粋にGC有りC言語として評価できる言語は実はあんまりない

**デフォルトの名無しさん** · 2025/06/15(日) 04:22:57.87

だから大抵の場合GC部分のみの評価になってない
(もちろんこれらの言語はそうした機能のお陰で保守性良く改良ペースが上がり結果速度向上になる場合もあるので悪いことばかりではない)

あとgoやdmdはC言語で書かれたコンパイラと比べても充分速いと思うけどね

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

Goが必ず遅い

**デフォルトの名無しさん** · 2025/06/15(日) 04:44:29.40

>>45
横だけどGC言語が速い例(ただしJVM系はpeak-memとのバランスが悪い)
https://programming-language-benchmarks.vercel.app/problem/binarytrees

**デフォルトの名無しさん** · 2025/06/15(日) 05:43:13.21

Goが5倍も遅いのはなぜ？
まともなベンチに見えない

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

まともなベンチマークでGC言語が速い例は存在しないからね

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

>>41
> 手動で解放があることを前提とした前処理
とは何ぞ？
仕様的に、何もしなくていいと分かりきってるのなら、本当に何もしないCがどう考えても一番速い

多分お前が言ってるのは、「GCヒープに対して、手動で開放があるオブジェクトを割り当てる場合、『前処理が必要になる』」ということなのだろうが、
それはVC++のように、マネージドヒープ(=GCされるヒープ=CLR側のヒープ)と
アンマネージドヒープ(GCされないヒープ=C++側のヒープ)を明示的に分離してしまえば、実行時の『前処理』等のコストは不要となる

**デフォルトの名無しさん** · 2025/06/15(日) 08:34:30.23

>>41
ところでGoは生ポなのでコンパクションは出来ないだろ

コンパクションありのGCは、フラグメンテーションを気にする必要がないので、割り当て自体は速いが、
**pになるのでpのアクセスが無駄に遅くなる
対してコンパクション無しのGCは、最低限サイズ毎の分別は必要なので、割り当て自体は多少遅くなるが、
*pでアクセス出来るので、使用時はCと同速度になる

だから、GCと一括りはまずくて、

コンパクション無しのGC: Go
コンパクションありのGC: C#/Java、多分その他もほぼこっち

と別扱いにしないといけないと思うが
この意味では、「割り当てるだけ割り当てたけど使いませんでした」なオブジェクトが多い場合(＝割と糞コード)は他GC言語と比べてGoは比較的遅くなる
例えば、ディープコピーして一部だけ変更し、他の部分はほぼ使わず破棄とか
それ以外の場合はGoの方が速いはず

**デフォルトの名無しさん** · 2025/06/15(日) 09:11:35.32

RustもGoも詳しくないけど、これらの言語にもRails や Django みたいなフルスタックのフレームワークってあるの？

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

>>50
それは間違い
GCのコンパクションは移動対象となるオブジェクトに対する全てのオブジェクト参照のアドレスを直接更新する

>>51
あるが一般的ではない
RustやGoはバックエンドに徹し、HTMLの生成(レンダリング)はNext.jsなど別のサービスが行うのが普通

**デフォルトの名無しさん** · 2025/06/15(日) 11:42:31.83

>>52
> GCのコンパクションは移動対象となるオブジェクトに対する全てのオブジェクト参照のアドレスを直接更新する
それはそれで凄いが、
それだとコピーの際に「参照カウンタ＋１」のみならず「コピー先アドレスも控えておく」必要があるので、コピーが重くなる
だから結局、GC方式が異なるので一緒くたには出来ないのは変わらない
まあ各者でそれぞれ一番速いと思ってる方式を採用してはいるのだろうけどね

**デフォルトの名無しさん** · 2025/06/15(日) 12:31:52.55

>>47
GC戦略の違いだよ
RustやC++もArena使って別途手動管理しないとGC言語より遅くなる典型例

**デフォルトの名無しさん** · 2025/06/15(日) 12:43:40.73

>>54
逆
管理を楽にするためにArenaを使う
もちろん速度も上がる

**デフォルトの名無しさん** · 2025/06/15(日) 13:57:26.71

ﾜｯﾁｮｲの無いスレでRustの話するとすぐこれだ

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

>>46(Input depth: 18)のarena version

zig 0.55 (arena)
go 0.58 (arena)
v 0.75
go 1.59
zig 2.78

**デフォルトの名無しさん** · 2025/06/15(日) 18:20:07.09

>>55
何の逆だよ
まさかArenaは”自動管理”とか言わないよね？

>管理を楽にするためにArenaを使う
それは比べる対象を間違えてるでしょ

**デフォルトの名無しさん** · 2025/06/15(日) 18:48:04.01

アリーナ使うと管理が楽になるのは事実
ライフタイムが統一されてめちゃ楽

**デフォルトの名無しさん** · 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 社員の給料に引っ張られるみたいな話