C#が新unsafeでメモリ安全に Rust/Swiftへの言及も

>>13
無知すぎる
ガベージコレクションが開始されなくてもガベージコレクション言語が遅い理由をまずは理解すべきだ

メモリが十分にあってGCが発動しなくても、GC言語は各種ベンチマークで、なぜC/C++/Rustに勝てないのか？
その理由は、GC言語はGCできるようにメモリ管理をせざるを得ないためだ。

>>16
あなた無能ってことですやんｗｗｗ

それってあなたの感想ですよね

>>14
手動とはどういう意味でしょう？

例えばそのRustで構造体のオブジェクトを作るとすると
その値を格納する変数はスタック領域に確保されます
そのメモリ割り当て解放コストは他のローカル変数とまとめてスタックポインタを加算減算するだけでコストは最小
これら自動ですので手動ではありません

ではその構造体オブジェクトを作る関数が先ほどの変数>>21へ値を返す時はどうなるでしょうか？
その値が小さければレジスタで返されます
その値が大きければ自動的に先ほどのスタック上の変数のアドレスが関数へ渡されてダイレクトに返す先の変数に値が書き込まれます
このようにオブジェクトの値のやりとりコストも最小
そしてこのオブジェクト作成関数ではオブジェクトのメモリの確保が不要
これらも自動ですので手動はありません

最後に変数>>21に格納された構造体オブジェクトの値を用いる他の関数を呼び出す時はどうなるでしょうか？
不変参照(書き換え不可)か可変参照(書き換え可能)を関数へ渡します
先ほどのスタック上の変数のアドレスがレジスタに格納されて関数へ渡されるだけでコスト最小です

以上ここまでメモリの割り当てと解放のコストは最初のオブジェクト格納変数のためのスタックポインタの加算減算しか生じていないです
だから速いのです

>>9 >>13-14
流石にGCがいくら高速になってもメモリの確保・解放にプラスして管理コストが乗っかる以上、メモリの確保・解放のみより軽くなることは理論上あり得ないことくらいはわかっておくべき

>>21-23
複数の点で間違っている
まず、ランタイムが管理するのではなくソースコードで利用されている場所や解放のタイミングを定めることを「手動管理」と呼ぶのであり、Rustは手動管理を行う言語である
また、メモリ割り当てコストはスタックポインタの加算のみではなく、OSによる処理が介在するしこちらの方がはるかに重い、しかもGCの話と何の関連性もない
メモリがどこから参照されていてどの時点で利用されなくなったか、管理する処理を全てランタイムが実行時に行うのがGCである
参照カウンタによる管理（ARC, ORC）のような中間の機能を備えた言語も存在するが、いずれにせよGCは管理コストが重いことは確かである