結局C++とRustってどっちが良いの？ 3traits

**デフォルトの名無しさん** · 2023/05/04(木) 07:49:56.33

「C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」
「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」

っていう雑談スレ。

前スレ: 結局C++とRustってどっちが良いの？ 2traits
https://mevius.5ch.net/test/read.cgi/tech/1680363777/

関連スレ(マ板): Google&MS「バグの70%はC/C++。Rustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/

**デフォルトの名無しさん** · 2023/05/05(金) 01:56:43.74

全く違うんだが現状は C からの置換を目指さなきゃいけない
その辺りがフォルダ構成にも反映されてしまっている

当然だがマッチの箇所はプロログなどの方が近い

**デフォルトの名無しさん** · 2023/05/05(金) 02:10:01.68

現にデコンストラクトによるパターンマッチはlispかhaskelくらいでしか見かけない

**デフォルトの名無しさん** · 2023/05/05(金) 02:29:13.44

似てたら置き換えやすいけど、置き換える意味も薄まりそうだけどな

**デフォルトの名無しさん** · 2023/05/05(金) 04:24:21.70

「みんなが使ってないものが使いたい」という心理を持っている人が一定数いて、
Rustはそういう人に受けてる可能性もある。

**デフォルトの名無しさん** · 2023/05/05(金) 05:02:21.75

Microsoft「Windows 11がまもなくカーネル内でRustを用いて起動」
https://www.neowin.net/news/senior-microsoft-exec-says-windows-11-kernel-will-soon-be-booting-with-rust-inside/

BlueHat IL 2023 カンファレンスにおいて、マイクロソフトのエンタープライズおよび OS セキュリティ担当バイスプレジデントである David Weston が登壇し、
Windows セキュリティの進化について話し合い、最新の進歩と今後の道のりについての洞察を講演しました。

プレゼンテーションの中でWeston氏は、MicrosoftがWindowsカーネルの一部としてRustを使用して行ってきた進歩について説明しました。
いくつかの理由でこの言語に興味を持っており、そのうちの11つはRustが提供するメモリの安全性とセキュリティを中心にしています。

Weston氏は次のように述べています。
「おそらく今後数週間または数か月以内に、カーネルでRustを使用してWindowsが実際に起動することになりますが、これは本当にクールです。
ここでの基本的な目標は、これらの内部C ++データ型のいくつかをRustの同等のデータ型に変換することでした。」

**デフォルトの名無しさん** · 2023/05/05(金) 05:36:12.75

前スレにも書いたけど、ブートローダってDOSアプリみたいなもんで、劇的に画期的じゃないんだよ

APIが早くRust化してほしいそうすれば、C++も恩恵を受ける

**デフォルトの名無しさん** · 2023/05/05(金) 06:12:56.25

マイクロソフトがわざわざC++を捨ててまでRustを採用するとはよっぽどのことだよな
Linuxの方は元からC++さえ排除してC言語だけの純血主義だったのにRustを採用し始めてる

**デフォルトの名無しさん** · 2023/05/05(金) 06:30:56.10

>>49
記事を読んだがブートローダーなんて書かれてなかった
Rustを使った場合のWindows OSのパフォーマンス比較でOffice apps使用の場合が出てくるからブートローダーの話ではないね

**デフォルトの名無しさん** · 2023/05/05(金) 06:37:43.26

昔、マイクロソフトはわざわざJAVAを捨ててJ++を開発したんだよなあ

**デフォルトの名無しさん** · 2023/05/05(金) 06:58:16.61

これまで多数の言語が登場したけど求められてる条件はたった二つだけ
「C/C++と同等のパフォーマンスが出ること」
「C/C++の各種安全性の問題が解決されていること」
Rustが最初で唯一の言語

**デフォルトの名無しさん** · 2023/05/05(金) 08:25:55.79

>>53
どこの異世界にすんでるんだ？

**デフォルトの名無しさん** · 2023/05/05(金) 08:50:30.82

>>53
安全にするにはGC言語にするしかないと思われていたからね
Rustだけが勝者となった

**デフォルトの名無しさん** · 2023/05/05(金) 09:46:15.52

Rust以外でGC採用せずにメモリやリソースの後始末をちゃんとしてくれるよう設計された言語って何があるの？

**デフォルトの名無しさん** · 2023/05/05(金) 10:06:18.39

お! GC君だ（この人が複製おじさん?）
GC君は他人のことを初心者呼ばわりするけど
技術的な話が全くできないんだよなぁ...

**デフォルトの名無しさん** · 2023/05/05(金) 10:21:16.98

>>50
$ tar xJf linux-6.3.1.tar.xz
$ find linux-6.3.1 -name *.c -o -name *.h | wc -l
55806
$ find linux-6.3.1 -name *.rs | wc -l
38
0.07%未満! 前回v6.2.1のとき37だったから1ファイルは増えてるね
何が増えたかは
$ diff -uNr <(cd linux-6.2.1; find . -name *.rs) <(cd linux-6.3.1; find . -name *.rs)

**デフォルトの名無しさん** · 2023/05/05(金) 10:43:09.36

>>52
JavaScriptをわざわざパクッてJscriptってのも作ったな
今やIEブラウザごと滅んだが
アップルとかソニーとか独自規格を作りたがる連中はいつの時代も迷惑

**デフォルトの名無しさん** · 2023/05/05(金) 10:47:34.91

Rustはメモリリークには割と寛容なんだよね
野生の参照（ダングリングポインタ）は目の敵にするけど

**デフォルトの名無しさん** · 2023/05/05(金) 10:52:02.55

>>56
Rustしか現存しない
他に出てきそうにないため今後Rustの時代が続くのだろう

**デフォルトの名無しさん** · 2023/05/05(金) 11:08:39.58

>>45
>デコンストラクトによるパターンマッチ
聞かない用語ですねぇ～
デコンストラクト

**デフォルトの名無しさん** · 2023/05/05(金) 11:27:48.85

>>56
Nim

**デフォルトの名無しさん** · 2023/05/05(金) 11:29:46.84

>>60
ヒモさえ付いてれば無駄遣いしてもOKみたいな

**デフォルトの名無しさん** · 2023/05/05(金) 11:58:16.34

RustってNimに対して何か優位なところはあるの?

**デフォルトの名無しさん** · 2023/05/05(金) 12:01:00.00

>>63
NimはGC言語
GCに頼らず済ませられる部分のみ使わないで済むというだけ

**デフォルトの名無しさん** · 2023/05/05(金) 12:15:37.38

>>56

間違い：メモリやリソースの後始末をちゃんとしてくれる
正解：メモリやリソースの後始末をちゃんとしてくれる(リーク除く)

**デフォルトの名無しさん** · 2023/05/05(金) 12:17:42.38

Nimはnilが存在していてヌル安全ですらない

**デフォルトの名無しさん** · 2023/05/05(金) 12:18:25.68

基本GCでも充分な性能が出れば別にいいよ
最適化が必要なところだけ手動でやるのはRustも同じだから

手動ライフタイム管理とのトレードオフ

**デフォルトの名無しさん** · 2023/05/05(金) 12:22:56.73

>>69
RustはNimのような逃げをしていない点で全く異なるよね
NimはGC言語という点でも誰も異論はなく

**デフォルトの名無しさん** · 2023/05/05(金) 12:28:44.39

>>56
Factorかね。

**デフォルトの名無しさん** · 2023/05/05(金) 12:37:44.37

FactorはForthとLispの子みたいな動的型付け言語
ガベージコレクションあり

**デフォルトの名無しさん** · 2023/05/05(金) 16:12:43.08

GCの有無は指標になるけど、現状のC++の、なんでもかんでもヒープに置く習慣は、
GCとそんなかわらないんじゃ…と思わなくもなかったり

**デフォルトの名無しさん** · 2023/05/05(金) 16:21:47.02

C++はコンパクションが行えないので、GC付きのJavaのほうが速いのです

って言ってなかった？

**デフォルトの名無しさん** · 2023/05/05(金) 17:13:23.83

感覚的にはプリミティブでない単純なデータ（xyz座標とか）の配列を直接作れるかどうかがボーダーな気がする
ポインタの配列を作ってるようだとGCしなくてもGC言語
C#は微妙なライン

変なタイミングで大掃除始める問題もあるけどこっちを気にする機会は少ないような

**デフォルトの名無しさん** · 2023/05/05(金) 18:05:31.65

結局、RustはC++より速くても、Javaよりは遅いってことですね

**デフォルトの名無しさん** · 2023/05/05(金) 19:01:02.92

もう少し待てはマイクロソフトがR++を出すと思うから
それまで待って

**デフォルトの名無しさん** · 2023/05/05(金) 23:04:16.37

JAVAが速い！？

**デフォルトの名無しさん** · 2023/05/05(金) 23:05:51.16

>>76
Rustはスタックを多用する言語なのでJavaより速い

**デフォルトの名無しさん** · 2023/05/05(金) 23:35:38.70

>>79
証拠は？

**デフォルトの名無しさん** · 2023/05/05(金) 23:47:38.29

>>80
スタック上のメモリ領域はCPUレジスタであるスタックポインタを足し算引き算するだけでメモリ確保と解放できるため最も速い

**デフォルトの名無しさん** · 2023/05/05(金) 23:50:40.76

>>81
CPUの仕組みを知っててそういう認識の人はいないと思いますよ

**デフォルトの名無しさん** · 2023/05/05(金) 23:56:37.63

もうみた～

**デフォルトの名無しさん** · 2023/05/06(土) 00:11:48.42

>>81のスタックメモリ利用が一番速いで合ってるけど
スタックメモリは関数から戻ると自動的に開放されその部分は無効になっちゃう
そのため従来の言語ではスタックメモリの利用を抑え気味にすることでその問題を過剰に回避してた
Rustはライフタイムの導入でスタックメモリを安全な範囲内の限界まで使えるようになったことが違いかな

**デフォルトの名無しさん** · 2023/05/06(土) 00:20:07.63

CPUのレジスタ利用が一番速いがレジスタ割り付けの最適化が非常に難しいので
スタックを使ってお茶を濁してる

**デフォルトの名無しさん** · 2023/05/06(土) 00:36:19.82

スタックメモリが主記憶と別の場所にあると思ってない？

**デフォルトの名無しさん** · 2023/05/06(土) 00:39:27.80

もしかしてヒープは主記憶、スタックはプロセッサの中にあるとか思ってない？
いま検索中？

**デフォルトの名無しさん** · 2023/05/06(土) 00:43:00.80

メモリの確保の仕方の違いでの速さの比較の話でレジスタの話を持ち出すのは違うでしょ
そしてレジスタの数は限界がありその退避先もスタックメモリですよ
スタックメモリに割り当てられた変数は最適化によりレジスタ割り当てが可能であればレジスタのみ利用になりますね

>>86
スタックメモリは単なるメインメインの一部にすぎません
しかしメモリ確保と解放が最も速いだけでなくメモリキャッシュに載る点でアクセスも速いです

**デフォルトの名無しさん** · 2023/05/06(土) 00:43:06.74

キャッシュメモリは主記憶に含めておいた方がいい？

**デフォルトの名無しさん** · 2023/05/06(土) 00:43:19.23

頭のおかしい人間がずっと一般的な事実に基づかない頓珍漢な独自妄想理論を展開してる

**デフォルトの名無しさん** · 2023/05/06(土) 00:46:32.42

スタックを積極的に利用しているからrustがjavaより速いと言われて
納得する馬鹿はいないだろ

もっと根本的な理由があるだろと
javaはVMでスタックマシンをエミュレートしてるから遅い

**デフォルトの名無しさん** · 2023/05/06(土) 00:48:39.47

通常はレジスタ一発で出来ることもわざわざスタックマシンでエミュレートしてるので遅い

**デフォルトの名無しさん** · 2023/05/06(土) 00:49:43.41

Rustもたいがい遅いだろ

**デフォルトの名無しさん** · 2023/05/06(土) 00:50:53.23

頭のおかしい人間がもう一人増えてた…

**デフォルトの名無しさん** · 2023/05/06(土) 00:53:21.90

スタックメモリが確保の点でもキャッシュされてる点でも非常に速いのは常識
そのためGC言語であってもGoのようにまずはスタックメモリ利用を優先する
(他へ渡すときだけGC対象になるヒープを利用)

**デフォルトの名無しさん** · 2023/05/06(土) 00:58:44.72

でもJavaのほうが速いんでしょ？

**デフォルトの名無しさん** · 2023/05/06(土) 01:02:01.90

>>95
Rustはそこからさらに一歩進めて他へ渡すときもスタックメモリを使えるように改善してますね
Rustはライフタイムの導入でスタックメモリを安全な範囲内の限界まで使えるようになりました

**デフォルトの名無しさん** · 2023/05/06(土) 01:13:46.56

変な人大集合だね
それがrustよりjavaが速い理由だと思い込んで疑わない変な人たち

**デフォルトの名無しさん** · 2023/05/06(土) 01:14:41.38

おっと逆だ
それがjavaよりrustが速い理由だと思い込んで疑わない変な人たち

**デフォルトの名無しさん** · 2023/05/06(土) 01:27:18.47

RustはJavaより遅いだろ

**デフォルトの名無しさん** · 2023/05/06(土) 02:12:11.55

そなの?

**デフォルトの名無しさん** · 2023/05/06(土) 03:12:15.76

>>101
それはない。

**デフォルトの名無しさん** · 2023/05/06(土) 06:31:50.59

C++とRustに比べればJavaは当然遅いしどうでもいい

**デフォルトの名無しさん** · 2023/05/06(土) 06:50:56.78

スタックってそんなでかくない、っていう世界もCの領域なんだよね
そんときの感覚を今でも引きずってる気はする

アプリケーションの起動時に、がつんとデカく確保しちゃえばいいんだろうけどね
なんとなく、ね

**デフォルトの名無しさん** · 2023/05/06(土) 07:22:20.41

>>103
Javaが一番速くて、少し遅れてRust、かなり離されてC++だろ

**デフォルトの名無しさん** · 2023/05/06(土) 07:46:12.61

>>95
いわゆるエスケープ解析と呼ばれているテクニックだな
スタックメモリ利用が断トツに速いのでできる限り使うようにする
GoだけでなくJava含めていくつかの言語で行われてるが適用に限界がある
単純には各ポインタのライフタイムが関数内に閉じてればスタックメモリを利用
他の関数に渡した時は確実に追い切れないので難しい
それを可能とするには言語自体がライフタイムをサポートする必要がある
それを実現したのがRustでありライフタイムを完全に追うことができて現在最強

**デフォルトの名無しさん** · 2023/05/06(土) 09:19:50.79

RustよりJavaのほうが速くなることも多々あるけど
unsafeやarena使ったりして最適化すればJavaより遅い状況はなくなる

でもJavaもネイティブコンパイルできるようになってるから起動速度含めてシェルスクリプトの代わりに使えるくらいには十分速いよ

**デフォルトの名無しさん** · 2023/05/06(土) 09:27:14.82

ほとんどのベンチマークでRustが圧倒的に速い
自分でunsafeする必要なんかない

**デフォルトの名無しさん** · 2023/05/06(土) 09:28:26.41

JavaやGoより明らかに高い性能を得ようと思ったら面倒臭いRust特有の最適化が必要になるから
自分用のツールに速度目的でRustを使うのは生産性的におすすめしない

製品開発やそれに準ずるライブラリ開発であればRustも有り

**デフォルトの名無しさん** · 2023/05/06(土) 09:34:58.48

>>109
根拠なくそういうデマはよくないと思うよ
「面倒臭いRust特有の最適化が必要になる」なんて聞いたことも体験したこともない

**デフォルトの名無しさん** · 2023/05/06(土) 09:46:59.89

Javaはないわー
なんだかんだいって、Oracleのドル箱なんでしょ、あそこの法務はなめちゃだめだ＞＜

**デフォルトの名無しさん** · 2023/05/06(土) 11:45:09.13

chatGTPのいい加減なときの答えみたいなレスが増えたな

しょうもない細部にこだわって全体を一切見ない
事実を使って嘘を作るようなレス

**デフォルトの名無しさん** · 2023/05/06(土) 14:05:33.18

複オジの一人妄想エコーチェンバースレだからね

**デフォルトの名無しさん** · 2023/05/06(土) 14:07:36.12

新しい燃料の投下だよ～

Mojo🔥
https://zenn.dev/helloyuki/scraps/70e4bcdef0bc6f

**デフォルトの名無しさん** · 2023/05/06(土) 15:11:59.44

>>114
> すべてを1つの言語Mojoで書く。
> Pythonを書くか、metalまでスケールダウンします。
> 多数の低レベルのAIハードウェアをプログラムします。
> C++ や CUDA は必要ありません。

挑発的だな
Pythonがベースの拡張で書きにくいことが確定だからどうでもいい

**デフォルトの名無しさん** · 2023/05/06(土) 15:24:45.43

Pythonが手になじんでる人には吉報かも
こりゃC++に流れ込んでくる日も近いね

**デフォルトの名無しさん** · 2023/05/06(土) 15:27:19.19

C++を不要にする目標なんだろ
無理だと思うが

**デフォルトの名無しさん** · 2023/05/06(土) 15:39:53.37

逆になるべくC++でやって行きたいと思う人も大勢いるということを
分かってない。

**デフォルトの名無しさん** · 2023/05/06(土) 15:53:28.09

名前からしてジョークじゃねえの
オースティンパワーズデラックスで見たぞこれ

**デフォルトの名無しさん** · 2023/05/06(土) 16:59:42.98

喪女？

**デフォルトの名無しさん** · 2023/05/06(土) 17:17:38.48

Python使いだけど、全部自力で書きたい…みたいな
GC系言語にどんどん拡がっていくんじゃね

**デフォルトの名無しさん** · 2023/05/06(土) 18:15:47.48

>>106のエスケープ解析やライフタイムを本格的にやるのかな
C++を一気に超えてしまいそう

**デフォルトの名無しさん** · 2023/05/06(土) 18:26:46.92

少しrustの仕組みを勉強してきた
いろいろと勉強になった

面白いからしったかさんを泳がしておこうｗ

**デフォルトの名無しさん** · 2023/05/06(土) 18:43:25.55

Pythonはインスタンスをヒープに置くことしかしていないが
スタックに置いて高速化するかもしれないのか

**デフォルトの名無しさん** · 2023/05/06(土) 20:28:37.67

LLVMとかあのへんに任せるんだろうから、できるようになりだしたらあっという間

**デフォルトの名無しさん** · 2023/05/06(土) 23:34:35.68

GCの分だけRustの方がJavaよりも早いんじゃないの
一般論だけど

**デフォルトの名無しさん** · 2023/05/06(土) 23:43:00.84

GCって予測不能なだけで速いか速くないかとは関係ないのでは?
それよりJavaはプロセッサとの間に入るJavaマシンが律速段階なのでは?

**デフォルトの名無しさん** · 2023/05/07(日) 00:20:35.09

一度実行したらコンパイルすりゃいいんじゃね

**デフォルトの名無しさん** · 2023/05/07(日) 03:11:23.01

RustよりJavaのほうがだいぶ速い

**デフォルトの名無しさん** · 2023/05/07(日) 06:16:47.38

ネイティブコンパイルができるとからしいから、だいぶ速くなったんかしらんが
Java派のサイトでいいから資料示してくれ
>>111 のとおりで、触る気にはならんそれこそJavaやるんならRustやる

**デフォルトの名無しさん** · 2023/05/07(日) 07:39:12.44

多くの人たちが一つの問題を色んな言語を用いて実装することで各言語の実行速度比較例
https://pbs.twimg.com/media/EmYvG8aVkAMdfFG.jpg
AtCoderのABC182-E問題で提出された各プログラミング言語別の実行時間分布

**デフォルトの名無しさん** · 2023/05/07(日) 07:45:16.15

c++の実装数の多さよ。

Rustの「実装しようとしてできなかった数」がどれくらいになるのか知りたいところ。

**デフォルトの名無しさん** · 2023/05/07(日) 08:07:01.05

>>131
Rustは書きやすいから
世間での普及と比較して多数使われてるな
速度もRustとC++は並んで最高速
一般での普及指標も毎年ぐんぐん上昇しているからあとは時間の問題のみか

**デフォルトの名無しさん** · 2023/05/07(日) 10:50:21.49

C、C++、Rust の速度に関しては、fact checkが必要。
少なくとも、C や C++ は、高級アセンブラなのだから、最速のはず。
Rustに負ける可能性はゼロ。

**デフォルトの名無しさん** · 2023/05/07(日) 10:52:23.10

「C++はRustより遅い」などと言っている人は、C++の標準ライブラリ(STL)
だけを使った場合に限定してしまっている。
C++は、アセンブラで書けることはほぼ何でも書けるし、Rustはそれを越える
ことは不可能なわけで、C++がRustより遅くなると言うのは論理的におかしい。

**デフォルトの名無しさん** · 2023/05/07(日) 10:58:59.25

もし、「RustがC++よりどうしても速くなる例」があるとするならば、
Rustのコンパイラは、C言語ではかけない特殊なマシン語を出力できる
ようになっているということである。
しかし、RustのバックエンドはLLVMであり、C/C++ のコンパイラ clang の
バックエンドも LLVM であることから、なぜそのような現象が起きるかは
大いに疑問となる。LLVMはLLVMレベルで最適化を行なうことができるような
コンパイラが存在しているので、C++が吐いたコードを最適化しても、
なぜか、Rustが吐いたコードを最適化したものより遅くなってしまうと言う
ことが起きなければならないことになる。
しかし、C++は、高級アセンブラであり、アセンブラで書けることは特殊命令
以外は基本的に全て書ける。ということは、Rustは、そのような特殊命令を
出力しない限りは、C++に勝つことは不可能と言っても過言ではない。

**デフォルトの名無しさん** · 2023/05/07(日) 11:00:30.38

いや、>>131 を見る限り、平均するとC++はPythonにすら負けてる

**デフォルトの名無しさん** · 2023/05/07(日) 11:01:52.13

誰かがスタックメモリを使ってるからrustが早いと言ってるけどllvmレベルでは差がない
吐き出した中間コードみてもそんな特徴は特になかった

**デフォルトの名無しさん** · 2023/05/07(日) 11:04:44.26

いや、>>131 を見る限り、平均するとRustは最速

**デフォルトの名無しさん** · 2023/05/07(日) 11:06:24.77

>>136
アセンブラに詳しくない人のために捕捉しておくと、特殊なマシン語の
例外(仲間はずれ)を除けば
「C言語の演算子は、アセンブラ(マシン語)の 1命令に一対一対応している」
とほぼ言える。なので、基本的に、マシン語を1命令ずつ書いていくのと
同じレベルでC言語はプログラム可能である。それに当てはまらないのは
CPUに依存したような「独特なマシン語」が存在している場合に限られる。
そして、コンピュータは、最終的には全てマシン語に置き換えられて実行され、
マシン語しか理解できない。
そして、C++は、C言語の演算子や機能は全て包含している。
ということは、C++は、特殊命令以外のマシン語を全て1命令ずつ記述できる、
ということである。
マシン語しか理解できないCPUに対して、C++は、あらゆる順序のマシン語を
ほぼ人間が思った通りの順序で書こうと思えば書けるのであるから、どうして、
C++が最速に成らないのだとしたら、非常に特殊な事態が起きていることになる。
その特殊な自体は、人間の手作業による最適化であると考えられている。

**デフォルトの名無しさん** · 2023/05/07(日) 11:07:48.80

>>139
平均と言うが、C++は、Rustのsafeモードを越えられる。
逆に、Rustはsafeモードだけを使っていると、C++に絶対に勝てない状況が
存在すると何度も指摘されている。

**デフォルトの名無しさん** · 2023/05/07(日) 11:09:29.23

>>139
それを見てもptyhon最速の人とC#最速の人が何をしたのかが気になるだけ

**デフォルトの名無しさん** · 2023/05/07(日) 11:12:16.15

>>140
「ほぼ」の意味を書いておく。
int x, y;
x = y;
と書くと、x,y をレジスタにとっていない場合は、
マシン語では、
mov eax,dword ptr [&y]
mov dword ptr [&x],eax
の2命令になり、基本的に1命令では書けない。
x,y がレジスタ、ebx, ecx にとられている場合は、
mov ebx,ecx
という1命令で書ける。
だから、x=y は、2命令になるときと1命令になるときが有る。
これが、「ほぼ」の意味である。

**デフォルトの名無しさん** · 2023/05/07(日) 11:14:47.99

llvmは仮想レジスタマシーンである