Go language part 6 (70ﾚｽ)
Go language part 6 http://mevius.5ch.net/test/read.cgi/tech/1747750228/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
1: デフォルトの名無しさん [sage] 2025/05/20(火) 23:10:28.20 ID:C5OyrGcX Goについて扱うスレッドです。 GoはGoogleによって開発された言語です。 公式 https://golang.org 公式ドキュメント https://golang.org/doc/ 公式外パッケージドキュメント https://godoc.org ブラウザ上で試し書き https://play.golang.org ※前スレ Go language part 5 https://mevius.5ch.net/test/read.cgi/tech/1645915400/ http://mevius.5ch.net/test/read.cgi/tech/1747750228/1
2: デフォルトの名無しさん [] 2025/05/21(水) 10:10:58.26 ID:va6/rMba >>1 O2 http://mevius.5ch.net/test/read.cgi/tech/1747750228/2
3: デフォルトの名無しさん [] 2025/05/28(水) 04:54:08.94 ID:ZTLYIgKF つるつるわれめ つるつるわれめ http://mevius.5ch.net/test/read.cgi/tech/1747750228/3
4: デフォルトの名無しさん [sage] 2025/05/28(水) 08:11:47.00 ID:S8gLFyNo 安定してるなぁ http://mevius.5ch.net/test/read.cgi/tech/1747750228/4
5: デフォルトの名無しさん [] 2025/06/02(月) 15:52:23.57 ID:fdx4Ir3H なるほどわからん err := example1() a, err := example2() // OK b, err := example2() // OK // _, err := example2() // ダメー // err := example1() // ダメー http://mevius.5ch.net/test/read.cgi/tech/1747750228/5
6: デフォルトの名無しさん [sage] 2025/06/14(土) 07:49:57.64 ID:B+lix1t6 Goって人気とか将来性のある言語だと思う？ http://mevius.5ch.net/test/read.cgi/tech/1747750228/6
7: デフォルトの名無しさん [sage] 2025/06/14(土) 08:34:58.82 ID:BYlCuXj0 >6 マイクロソフト、TypeScriptのコンパイラなどをGo言語に移植することで10倍の処理速度に ttps://www.publickey1.jp/blog/25/typescriptgo10.html C#やRustよりもGoが選ばれました。人気も将来性もめちゃくちゃありまーす＾＾ http://mevius.5ch.net/test/read.cgi/tech/1747750228/7
8: デフォルトの名無しさん [sage] 2025/06/14(土) 10:43:58.28 ID:WiumTvVB >>6 書いてないなら関係なくね？ http://mevius.5ch.net/test/read.cgi/tech/1747750228/8
9: デフォルトの名無しさん [sage] 2025/06/14(土) 11:17:21.04 ID:dtGV1Vl4 もうどの言語が好きとかいう時代じゃないからねパフォーマンスの改善を目的としたJSからの単純移植をAIにやらせるにはGoは適していることが証明された、それだけのこと http://mevius.5ch.net/test/read.cgi/tech/1747750228/9
10: デフォルトの名無しさん [sage] 2025/06/14(土) 12:09:42.28 ID:+l0S6cSK これってAIによる移植なんか？ http://mevius.5ch.net/test/read.cgi/tech/1747750228/10
11: デフォルトの名無しさん [sage] 2025/06/14(土) 12:43:28.73 ID:4ihnDgSn AIによる移植でもなければJSからの移植でもない 基本的な認識が間違ってる、それだけのこと http://mevius.5ch.net/test/read.cgi/tech/1747750228/11
12: デフォルトの名無しさん [sage] 2025/06/14(土) 13:13:38.94 ID:/OxuSDvW > 性能向上の要因の半分はネイティブコード化によるものであり、残りの半分は並行処理の利用によるものだとしました。 つまりネイティブ化と並行で3.31倍ずつ 技術的にはそりゃそうだろで凄くはない http://mevius.5ch.net/test/read.cgi/tech/1747750228/12
13: デフォルトの名無しさん [sage] 2025/06/14(土) 15:21:50.33 ID:lU2qZKzs 当たり前のことを当たり前にやるのが大切なんでしょ http://mevius.5ch.net/test/read.cgi/tech/1747750228/13
14: デフォルトの名無しさん [] 2025/06/14(土) 17:10:26.41 ID:IqWN5A4e RailsとLaravel一筋だった3年目ですがなんかGo(Gin)やることになりました 僕の未来は安泰ですか ポインタでつまずきました http://mevius.5ch.net/test/read.cgi/tech/1747750228/14
15: デフォルトの名無しさん [sage] 2025/06/14(土) 17:46:49.96 ID:y4VinIhq まずはプログラミング言語がキャリアの軸になっているステージを脱することが大切 幸いにもGoはわりと言語どうでもいい段階の人が多いので、ステップアップには良い環境だ http://mevius.5ch.net/test/read.cgi/tech/1747750228/15
16: デフォルトの名無しさん [sage] 2025/06/14(土) 17:50:53.17 ID:/OxuSDvW >>13 それはその通りだが… Rust: GC前提のコードからのポーティングは(多分)かなり手間 C++: 全部shared_ptrにすれば『ほぼ』いけるはずだが、『ほぼ』が許せないなら無理 とはいえ、ビルドツールが多少リークしたところで大して問題ないが C#: 2014年頃からネイティブも出来るようになったらしい として、C#が落ちた(Goに負けた)理由は以下のどれだろう？ > すべてのプラットフォームで完全に最適化されたネイティブバイナリを生成できて、 > データレイアウトの細かな制御が可能で、 > ガベージコレクタによるメモリ管理が自動化され、 > 優れた並列処理が可能 ちな、最後については、元がJS(TS)なのでソースコード上でスレッド間は完全分離してるから、C#でも大して問題ない つまり、この点について、JS->Go、JS->C#の移植は問題ないが、Go->JSの移植はgoroutine使いまくりの場合厳しいかも？ 俺的にはC#でよかったんじゃね？とは思う(まあGoでも特に問題ないが) http://mevius.5ch.net/test/read.cgi/tech/1747750228/16
17: デフォルトの名無しさん [sage] 2025/06/14(土) 18:29:30.75 ID:R+Velb9Y >>16 >C#: 2014年頃からネイティブも出来るようになったらしい 2014年は.NET NativeのPreviewリリースのことだな そいつは今のAOTコンパイラとは全く別のもの 今のやつは2022年正式リリース C#を選ばなかった理由 https://youtu.be/10qowKUW82U?t=1208 http://mevius.5ch.net/test/read.cgi/tech/1747750228/17
18: デフォルトの名無しさん [] 2025/06/14(土) 19:21:06.66 ID:tKqSzfGn ポインタで躓くなら他の職種に行ったほうが幸せ お前の周り、ライバルはみんな理解するぐらいの能力有してるから http://mevius.5ch.net/test/read.cgi/tech/1747750228/18
19: デフォルトの名無しさん [sage] 2025/06/14(土) 20:02:28.20 ID:/OxuSDvW >>17 とりあえずその部分だけ見た つまりC#はclassを多用するOOPがベースで、 元のJSのfunctionalに合わず、Goは逆に合ってるそうな まあ納得の説明ではあるが、 OOPをウップス！と読むのか？(まあ単語としてはそうだが) classesがplusses(って何ぞ？)に聞こえるので、字幕無いと厳しいなこれは (ただ字幕は追従できてるので、俺の耳が悪いのも事実だが) http://mevius.5ch.net/test/read.cgi/tech/1747750228/19
20: デフォルトの名無しさん [sage] 2025/06/14(土) 21:14:48.29 ID:/OxuSDvW ついでに13:16のwhy not Rust?も見てみたが、 cyclic structureが使えねえから、とか言ってるんだが、これってどうなんだ？ 元がTS(JS)だから子が親を参照してるcyclicとかありまくりで、Rustだと苦労する、と言っている事自体には同意するが、 俺はそもそもcyclicが有用なことがない、という認識で、これは俺がC出身で、 「ヒャッハー、GCだぜ！！！ これまで(自分で寿命を管理しないといけない)Cでは出来なかった複雑怪奇な構造も楽勝だぜ！ ついに俺の真なる力が開放される時が来たぜ！」 と思って色々試したものの、俺的には寿命管理はどんなケースでも出来るし、Cでも全く問題ないとの結論になったから ただNimの連中は同様に「Cでは出来ないような構造もー」とか言ってるので、Nimも確認しないと駄目かとは思ってた 今回ヘルズバーグは「スクラッチから作るのならRustにするが、ポーティングだからね」なので、 彼の見立ては俺に近く、「Cyclicなんて無くても作れるし、スクラッチならそうするからRustで問題ない」なのだろうが、 元々がCyclicを多用してる理由を知りたい、というか、 ・Cyclic(や出鱈目参照ありまくり構造)を許可すれば楽勝に組めるが、無しでは手間が増える なケースなんて有るか？ まあこれが今回tscということなのだが、どういうケースでどういう選択でそうなったのか知りたい (つってもソースコード読めではあるが、知ってたらよろしく) http://mevius.5ch.net/test/read.cgi/tech/1747750228/20
21: デフォルトの名無しさん [sage] 2025/06/14(土) 21:28:21.25 ID:/OxuSDvW と思ったがTSの連中に聞くことにした https://mevius.5ch.net/test/read.cgi/tech/1640872622/376 http://mevius.5ch.net/test/read.cgi/tech/1747750228/21
22: デフォルトの名無しさん [sage] 2025/06/14(土) 21:29:08.75 ID:dtGV1Vl4 >>20 依存関係の循環じゃなくて参照の循環は普通にあるよ 例えば親コンポーネントがその上に乗っている子コンポーネントからの通知をコールバックで受け取るケースでは循環参照が発生する http://mevius.5ch.net/test/read.cgi/tech/1747750228/22
23: デフォルトの名無しさん [sage] 2025/06/14(土) 22:38:33.86 ID:GCb7U03w >>20 「スクラッチから作るのならRustにする」なんて言ってないだろ 「Cyclicなんて無くても作れるし、スクラッチならそうするからRustで問題ない」なんてことも言ってない 勝手に脳内変換しちゃいかんよ http://mevius.5ch.net/test/read.cgi/tech/1747750228/23
24: デフォルトの名無しさん [] 2025/06/14(土) 22:43:49.77 ID:eLCz0XU2 組み込みはメモリー周りが厳しいのでRust一択ですよね http://mevius.5ch.net/test/read.cgi/tech/1747750228/24
25: デフォルトの名無しさん [sage] 2025/06/14(土) 22:51:31.08 ID:GCb7U03w >>20 cyclic data structureの例はwhy not Rust?のところで説明しとるやろがい AST with both child and parent pointers symbols -> decorations -> AST -> reference back to symbols 循環参照のメモリ管理を自動でやってくれる言語の場合は 親子の相互参照みたいなのを特殊な状況を除くと何も気にせず作れる 特別な手順を踏む必要がないだけでなくモデルと実装が乖離しない CやRustではそうはいかない http://mevius.5ch.net/test/read.cgi/tech/1747750228/25
26: デフォルトの名無しさん [sage] 2025/06/14(土) 22:56:09.38 ID:/OxuSDvW >>22 そこは整理しないといけないと思う（といっても俺はRustは詳しくないが) ・単なる循環参照(親→子→親で、まとめて廃棄可能＝寿命が同一のオブジェクト間の相互参照…Rustでも楽勝) ・寿命がバラバラのオブジェクト同士の複雑な相互参照(…Rustで無理なのは多分これ) コールバックの結果に「親」も含めて返し、子としては自分でも参照できるようにしておく、 つまりxhr/fetchで {requester: parent, response: Response} で返せば循環参照自体は発生するが、 基本的にこの手のResponseは各所に回覧して終わり、 必要なら各自コピーとっとけ、で、回覧修了後に廃棄、で何も問題ない だから前者であって、後者の「Rustで苦労するタイプの『循環参照』」にはならない Rustで対応無理なのは、Rustの性質上、(ここらへんからだいぶ間違いが入るかもだが) ・誰が所有権を持ってるのか（＝そのローカルで誰が最長寿命なのか) ・誰が借りるのか（＝所有権保持者より短寿命) をソース上で確定させないといけないので、 A->Response B->Response とResponseを複数のオブジェクトから参照させる場合、AとBのどちらが寿命が長いか分からないと詰むし、 これらが複雑怪奇に相互参照してる場合、基本的に ・誰が最長寿命なのか(＝誰が所有権を持つべきか) が静的に確定してないと詰む、という事(だと思う) http://mevius.5ch.net/test/read.cgi/tech/1747750228/26
27: デフォルトの名無しさん [sage] 2025/06/14(土) 22:56:41.09 ID:/OxuSDvW ただ、この辺、単純にAとBの両方より確実に寿命の長いCを定義し、 C->Response として、Cの廃棄でResponseも廃棄させればいいだけで。 (この書き方では意味不明だが、単純には、ただの入れ子で func C(Response){ // C:関数ローカルのスコープ // A->Response としての処理 // B->Response としての処理 } // func 終了タイミングでResponseを破棄してもA->ResponseとB->Responseの処理は終わってるので問題なし と、要するに、寿命を強制的に入れ子にするだけ) 俺的に、 ・回覧方式で、回覧終了後に破棄する前提なので、必要なら各自コピー取れ ・寿命は入れ子で、最長寿命の親が一人居るから、それ以外の連中は寿命を気にする必要ない のどちらかで対応できないケースはなく、どちらかにすることも大して難しくないので、Cで十分という結論になってる この辺は原理的にも当たり前で、 変数自体の寿命が「どこかのローカルで入れ子」で、最外(=最長)が「グローバルでアプリと同じ寿命」なので、 変数に代入してる限り、代入されるオブジェクトもそれ以上の寿命になりようがない だから代入してる時点で、「これまで代入(参照)された最長変数(オブジェクト)よりも寿命が長いか」が確定してれば ・長い場合→所有権を渡す ・短い場合→所有権を渡さない と明示的にやるのがRustで、黙ってプログラマが勝手に管理しろ、というのがCであるだけ だから代入(参照)時点で寿命が確定出来ない場合、Rustは詰むのだが、 原理的に、代入先(=変数/参照元)の寿命は確定してるから、これはない 結果、GCがないと現実的に無理なことは「存在しない」というのが俺の見方 ただtscはやりまくってるのだから、何かcyclicを使えば大幅に手抜きが出来るケースがあるのか？という事 http://mevius.5ch.net/test/read.cgi/tech/1747750228/27
28: デフォルトの名無しさん [sage] 2025/06/14(土) 23:10:53.20 ID:0RGMG9ga >>27 回避可能か不可能かの問題ではない 移植にあたっては、絶対に既存の挙動を変えないために、一行一行単位の逐次翻訳を行なっている Rustでそれができると思うならアンダース氏に凸撃してきたらいい http://mevius.5ch.net/test/read.cgi/tech/1747750228/28
29: デフォルトの名無しさん [sage] 2025/06/14(土) 23:21:32.37 ID:/OxuSDvW >>23 ああ確かにRustで駄目な理由を述べてるだけで、Rustにするとは言ってないな 不用意に信者を召喚してしまう発言は申し訳なかった (が、まあ、そこは本筋ではない) >>25 そこはそう言ってるが、ASTなんてただの木構造だし、相互に複雑に参照されたところで、寿命は同一だろ (＝その中のオブジェクトの全てはソースコードの寿命と同じ) だから全く問題にならない 全部のオブジェクトをルート点の寿命で管理すればいいだけだし、何ならこれはただのグローバルだろ C++的に参照カウンタで管理した場合は無駄にクソ遅くなるが、これはGCなGoでも同じ Rust的に代入/参照する際にいちいち寿命管理しろと言われたら、手間が全く無駄なだけだが、グローバルにも出来たはず まあ最初からグローバルと分かりきってるなら、Cが一番楽ということになるが ソースコード(当然静的)を解析してASTを作りました、なら、 当たり前だが各オブジェクトはソースコードの寿命以上にはならないので、苦労することはないよ func somefunc(){ // ソースコード読み込み // AST木生成 // いろいろ処理 // AST木破棄 } にしかならんだろ 複雑な循環参照はそりゃあるのだろうが、問題になるのは、 『寿命の異なるオブジェクト間の』複雑な循環参照であってね、26のとおり http://mevius.5ch.net/test/read.cgi/tech/1747750228/29
30: デフォルトの名無しさん [sage] 2025/06/14(土) 23:35:56.94 ID:/OxuSDvW >>28 > 移植にあたっては、絶対に既存の挙動を変えないために、一行一行単位の逐次翻訳を行なっている これなら納得だが、なら最初からそう言えよヘルズバーグ、とは思う ただまあ、「TSの方が型が多くて、enumのないGoでは‥」と似たようなことは言ってたが (多分そもそもこの動画がTSer向けで、界隈の状況をある程度知ってる前提で、 俺みたいな門外漢が見る用には出来てないのだろう) 逐次変換するなら、機能的にスーパーセットでないと厳しいので、Rustは論外、Cもまあ無理、 C++は多分行けるはず、C#もおそらく可能、でもGoが一番マシ、というのは分かるかも (しかし厳密に逐次変換を目指すなら《無駄に全部入りの》C++が常道だとも思うが) http://mevius.5ch.net/test/read.cgi/tech/1747750228/30
31: デフォルトの名無しさん [sage] 2025/06/14(土) 23:43:33.04 ID:v07AL1EI >>7 それは特殊なケースだから一般的にGoを採用する理由にはならない 今回は正確には移植による言語移行ではない 約5万行のchecker.tsで実装されていてそのままTSのCompiler API として公開されていてこれも維持を継続しなければならない それに加えて並行して別言語によるスピードアップを叶えることが目的 つまりTSと別言語のソースコード二重管理となる負荷を最も下げられることが最重要という特殊な条件がある C#ではクラスベースとなるためTSから大きく書き換える必要性から条件に合わない CやRustはその点では問題ないがGCに任せている部分を新たに対応することになるため条件に合わない そこで今回の条件ではたまたまGoが合致して採用に至っている もし単なる移植ならば設定から見直し効率よくRustで書けばもっとスピードアップできたであろう http://mevius.5ch.net/test/read.cgi/tech/1747750228/31
32: デフォルトの名無しさん [sage] 2025/06/14(土) 23:54:18.51 ID:/OxuSDvW >>31 > つまりTSと別言語のソースコード二重管理となる負荷を最も下げられることが最重要という特殊な条件がある 無いぞ ブログの方見れば分かるが、 https://devblogs.microsoft.com/typescript/typescript-native-port/ JSはTS6.xで止め、TS7.0はGo、の予定だ (JSベースのTS7.x系が出る予定はない) そしてRust信者は死ね http://mevius.5ch.net/test/read.cgi/tech/1747750228/32
33: デフォルトの名無しさん [sage] 2025/06/14(土) 23:57:18.48 ID:tHMbF/HF 元のTSコードと合わせる必要がないならC#でも問題ないよ だからGoにする必要がない http://mevius.5ch.net/test/read.cgi/tech/1747750228/33
34: デフォルトの名無しさん [sage] 2025/06/14(土) 23:59:27.91 ID:V6t1FI0l >>26 Rustでもアリーナ管理すればよいため循環があろうと大丈夫だよ http://mevius.5ch.net/test/read.cgi/tech/1747750228/34
35: デフォルトの名無しさん [sage] 2025/06/15(日) 00:24:06.66 ID:lIZk6VUi >>26 >単なる循環参照(親→子→親で、まとめて廃棄可能＝寿命が同一のオブジェクト間の相互参照…Rustでも楽勝) 親→子→親の構造を表現するためにはRc/RefCell/WeakRefの組み合わせみたいなのが必須 何も気にせず全自動でやってくれる言語と比べれば相当面倒くさいよ 要は前者でも後者でも基本同じ >A->Response >B->Response これがAがResponseを参照している、BがResponseを参照しているの意味なら AやBより先に他の誰かがResponseを生成して所有しているはずで その誰かはAやBより長生きするんだから何の問題もないよ Rustだからといって面倒くさくなるパターンでもない http://mevius.5ch.net/test/read.cgi/tech/1747750228/35
36: デフォルトの名無しさん [sage] 2025/06/15(日) 00:53:43.71 ID:PrFSErxS TSで循環定義が書けるからコンパイラも同じ構造のまま扱いたいだけでは http://mevius.5ch.net/test/read.cgi/tech/1747750228/36
37: デフォルトの名無しさん [sage] 2025/06/15(日) 01:14:15.92 ID:757F+le4 >>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の方法でメモリ管理するのは無理だと思ってる) http://mevius.5ch.net/test/read.cgi/tech/1747750228/37
38: デフォルトの名無しさん [sage] 2025/06/15(日) 01:41:02.18 ID:757F+le4 >>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なわけだが http://mevius.5ch.net/test/read.cgi/tech/1747750228/38
39: デフォルトの名無しさん [sage] 2025/06/15(日) 03:34:28.75 ID:r3H8nvWy コンパイラというのは数少ないGC有りのほうが有利な分野 全力で駆け抜けて終了するまでに一度もコンパクションが発生しなければメモリ管理のコストを丸ごと踏み倒せてGC無し言語よりも速くなる http://mevius.5ch.net/test/read.cgi/tech/1747750228/39
40: デフォルトの名無しさん [sage] 2025/06/15(日) 03:49:42.94 ID:7JDJ5spc >>39 それは初心者がよくする勘違い GC言語は常に不利で遅くなる http://mevius.5ch.net/test/read.cgi/tech/1747750228/40
41: デフォルトの名無しさん [sage] 2025/06/15(日) 03:57:51.31 ID:r3H8nvWy >>40 そんなことはない。ヒープの構造はGCのほうがコンパクションを前提にできるのでシンプルで割り当ても速いし 手動で解放があることを前提とした前処理も不要になる C言語でも同タイプの用途には特化したプールを用意して一切解放を行わない最適化戦略は行われる http://mevius.5ch.net/test/read.cgi/tech/1747750228/41
42: デフォルトの名無しさん [sage] 2025/06/15(日) 04:03:23.77 ID:sHWxg8n8 GCしなくてもGC言語が遅い だから速いコンパイラはGC言語で書かれていない http://mevius.5ch.net/test/read.cgi/tech/1747750228/42
43: デフォルトの名無しさん [sage] 2025/06/15(日) 04:08:44.02 ID:r3H8nvWy >>42 既存のGC有り言語は大抵他の凝った機能を備えていてそのペナルティが大きい JITは勿論、Goならゴルーチン、Haskellなら辞書によるディスパッチ、OCamlなら値の1ビットをタグにしてる D言語は保守的GCなのでGC特有の最適化が充分にできない等 純粋にGC有りC言語として評価できる言語は実はあんまりない http://mevius.5ch.net/test/read.cgi/tech/1747750228/43
44: デフォルトの名無しさん [sage] 2025/06/15(日) 04:22:57.87 ID:r3H8nvWy だから大抵の場合GC部分のみの評価になってない (もちろんこれらの言語はそうした機能のお陰で保守性良く改良ペースが上がり結果速度向上になる場合もあるので悪いことばかりではない) あとgoやdmdはC言語で書かれたコンパイラと比べても充分速いと思うけどね http://mevius.5ch.net/test/read.cgi/tech/1747750228/44
45: デフォルトの名無しさん [sage] 2025/06/15(日) 04:38:29.84 ID:sHWxg8n8 Goが必ず遅い http://mevius.5ch.net/test/read.cgi/tech/1747750228/45
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.010s