結局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/04(木) 14:12:15.32

板のルールが理解できない、プログラムがロクに書けない人たちのスレ
>>1死んどけ荒らしのクズ

**デフォルトの名無しさん** · 2023/05/04(木) 14:13:35.45

あらゆるところに関所がある
まるで江戸時代だ
裏山に抜け道を見付けて分け入っても
突然藪から棒に番人が現れる
ところがそんな番人も
unsafe印籠を魅せれば一撃で退散だ
unsafe万歳!!!
こんなことなら最初から
表通りでunsafe印籠を出しておけば良かったんだ
きっと番人たちも思っているはず
さっさと最初からunsafe印籠魅せやがれ
無駄な手間取らせやがって
こんなのがエコシステムとか失笑もの

**デフォルトの名無しさん** · 2023/05/04(木) 14:18:13.51

ここの説明だと
https://keens.github.io/blog/2018/12/08/rustnomoju_runotsukaikata_2018_editionhan/
lib.rs も main.rs も共存出来る様な描きっぷりだなぁ
今の Rust だと許さないゎょ

まあ2018だし

**デフォルトの名無しさん** · 2023/05/04(木) 14:39:58.15

=== 複製おじさん（通称複おじ）について ===
Rustスレを中心に活動し、2023年4月現在で1年以上ム板に住み着くRustacean。無自覚な荒らし。

Rustスレでは、基本的に他住民の意見を聞いて糧とすることなく、自らのコードが最善であると、ID変更自演を交えいつまでも主張し続ける。
同スレで「所有権が複製される」という違和感のある表現を、「違和感がある」とする他住民の意見をすべて否定してしつこく擁護し続けたことから、「複製おじさん」というあだ名が付けられた。
それ以外のム板スレでは、基本的に他住民の意見を聞いて糧とすることなく、Rustこそが最善であると、ID変更自演を交えいつまでも主張し続ける。
その基本戦術は、「GC言語は遅い」の一声でC/C++/Rust以外の言語を否定し、残ったC/C++は安全ではないので、Rustが最善であるとするもの。

しかしながら、Rust以外の言語に関しては、正当な批判を展開するのに十分な知識を持っているとは言いがたい。
本スレPart1では、C++の問題点を指摘しようとして多数の誤り・知識不足を露呈することとなった。特にしつこく食い下がったのが「動的ディスパッチ」に関する誤解である。
https://mevius.5ch.net/test/read.cgi/tech/1677286186/786-799（ID:Evbafc70とID:RiLc+pIfが複製おじさんであると考えられている）
要約すると、通常「条件分岐」と呼ばれるものを「動的ディスパッチ」と呼ぶのが正しいと主張し続けたのである。
常識的にはあり得ない誤解だが、提示されたC++のコードが自らの主張（C++にはパターンマッチが無い）に不都合であると感じたためか、C++のコードを正しく読み解くことができないにもかかわらず脊髄反射的に否定してしまい、その根拠として誤った論理をこじつけてしまったものと思われる。

ちなみにこの後、同種の誤解を持って書き込むID:wHEiYRW7（これはID使用歴的に複製おじさんとは考えにくい）に対して、正しい理解に基づく指摘を行う単発IDが複数出現するが、この中にも複製おじさんが多数含まれていると考えられている。
このように自分の誤りを認識した場合、それを認める書き込みは決して行わず、別人の振りをして最初から正しく理解していた体を装うのも複製おじさんの特徴である。

**デフォルトの名無しさん** · 2023/05/04(木) 14:42:23.03

Fooという型だけを別ファイルfoo.rsへ移してファイルを分けたくなったとする
もちろんそれは可能だが二つの方針に分かれる

その1
pub mod foo;
とする
つまり単にmod foo;とするのではなくpubを付けることで利用者がfooにアクセスできるようになる
さらにfoo.rsでFooにもpubが付いていれば
利用者はfoo::Fooまたはクレート名::foo::Fooという形で利用できる

その2
mod foo;
pub use foo::Foo;
とする
つまりfooは公開しない
しかしFooは公開したいのでfooの下ではなくトップでFooを公開する
この場もfoo.rsでFooにpubは必要
利用者はfoo::を付けずにFooまたはクレート名::Fooという形で利用できる

ようするにファイルを分けたときに
分けた形で公開するならその1
分けたことを隠蔽して公開するならその2

**デフォルトの名無しさん** · 2023/05/04(木) 14:50:46.28

>>5
>自分の誤りを認識した場合、それを認める書き込みは決して行わず、別人の振りをして最初から正しく理解していた体を装う

図らずも昨晩今日のC言語スレでその現象が観測されました

**デフォルトの名無しさん** · 2023/05/04(木) 14:53:45.65

さらに型Fooのイテレータだけ別ファイルiter.rsに分けたくなったとする
その時はfoo/iter.rsというファイルにする
そしてfoo.rsの中でmod iter;とすればよい
分けたことを隠蔽するか公開するか>>6と同じ方針で望む
もし公開するならfoo::iter::Iterのようにパスが長くなる
それをメリットかデメリットかで決めればよい

**デフォルトの名無しさん** · 2023/05/04(木) 15:08:27.50

>>4
今も同じように共存できるよ

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

次に>>6とは全く逆
ファイルを分けたくないけど
foo::Fooという形で公開したい時
その場合は
pub mod foo {
　ここにFooの定義など
}
とすればよい
ファイルfoo.rsに分けたときと同じにできる

つまり
ファイルを分けるか分けないか
公開パスを分けるか分けないか
任意の組み合わせで自由に可能

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

>>5
動的ディスパッチは俺だよw
間違うな

**デフォルトの名無しさん** · 2023/05/04(木) 15:35:48.42

かの御仁、ディスパッチのことになるとずいぶん熱くなってたよなあ
継承を廃止するのに必要だったからってわけだったみたいね

**デフォルトの名無しさん** · 2023/05/04(木) 15:59:17.58

さらに5つ目の方法
ファイルは分けなくて
mod foo{...}という形でfooは分けるけど
そのfooは見せない！
と一見すると矛盾した方針がある

その場合は>>6と>>10からのご推測の通り
mod foo {
　ここにFooの定義など
}
pub use foo::Foo;
とすればよい
利用者は直接Fooまたはクレート名::Fooとして使える

しかしそれならば
mod foo{...}を使わずにそのまま直接Fooの定義を書いたのと同じじゃないか！
との疑問が湧く

ほぼその通りだが
この方法によりmod foo{...}の中は名前空間が分離されているため
他とのコードの分離もしっかりできる
もし外部との結合があれば
mod foo{...}の中で改めてその使用宣言が必要になる
逆に外部から使われるものはpub宣言が必要となる
mod foo{...}の中に敢えて入れることでそれら他との関係が明示させられる

つまりまとめると3つの自由度がある
・mod fooとして分けるかどうか
・それをfoo.rsとしてファイルに分けるかどうか
・そのfooを外部に見せるか隠蔽するか
それらを多段foo::bar::bazそれぞれ含めて自由に決めればよい

**デフォルトの名無しさん** · 2023/05/04(木) 16:03:32.18

Rustの用語に「名前空間」なんてあるの？

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

あるよ

**デフォルトの名無しさん** · 2023/05/04(木) 16:09:29.50

>>12
Rustは継承を使わずに合成だが
動的ディスパッチ自体はほぼ変わらない
vtable部分が合成した各メソッドを含む一覧になる程度

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

この話興味ない人は今のうちにCpp2見とくと良いよ(思ってたより動きが早い)
https://herbsutter.com/2023/04/30/cppfront-spring-update/

Carbonと違ってこっちは動かせるしC++へのバックポートを視野に入れているから
結果的にRustの立ち位置に影響する

細かいところだと、この辺、Zigに通じるものがある
https://github.com/hsutter/cppfront/wiki/Design-note:-Postfix-operators
https://i.imgur.com/bkjsYG4.png

unsafe印籠(monolithic hammer)は否定してる
https://github.com/hsutter/cppfront/wiki/Design-note:-Unsafe-code

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

ほとんどのmoduleは
自分の今のprojectから分離して別のcrateに移動しても
module内のpub関数はuse cratename;すればそのまま変更無しで参照出来るが
module内のmacroはuse cratename;するだけでは参照出来ない
#[macro_export] だけでは不十分でmoduleに
pub use macroname;
を書き足す必要がある

**デフォルトの名無しさん** · 2023/05/04(木) 16:22:57.02

>>9
ごめん
proc_macro が共存出来なかったって事だった
ていうか proc_macro が共存出来ないのは昔からだな

**デフォルトの名無しさん** · 2023/05/04(木) 17:29:00.42

ITの世界は短期決戦の世界。知名度がこんなに上がってるのに使用者数が1%未満
のRustには一般言語にまで普及する可能性はほぼ無い。

**デフォルトの名無しさん** · 2023/05/04(木) 17:31:09.86

今までの蓄積ではなく、新しく書かれているコードの量ですら1%未満であることの
意味は、絶対に普及しない路線に入っていると言うことだ。

**デフォルトの名無しさん** · 2023/05/04(木) 17:38:32.86

商品が売れない原因の9割は知名度不足だと言われているが、Rustは既に最高レベル
の知名度になった。なのに「売れてない」。それは商品自体に問題があると考え
なければならない。俺はRustが嫌いなので、それでいいと思っているが。

**デフォルトの名無しさん** · 2023/05/04(木) 17:48:43.01

結論としてはRustはC++に比べるとファイル分轄が非常にめんどくさいと言うことだな
ルールが複雑でめんどくさい

言語仕様なのかcargoの仕様なのかしらないけどフォルダ構造が縛られるし…

**デフォルトの名無しさん** · 2023/05/04(木) 17:52:33.78

よくわからんけど自分でstruct沢山作ってcore/modelフォルダ作ってそこに全部突っ込んでフラットに使おうとすると障害があると
implをcore/implに突っ込もうとしても問題があると
それかそれを参照する何かを別に作らないといけないと
自由度が低い

**デフォルトの名無しさん** · 2023/05/04(木) 17:56:09.35

いやーさすがにC++に比べたらRustのが超シンプルなのでわかりやすい
C++のモジュール知っててRustのモジュールを理解出来ない人はいないと思う

**デフォルトの名無しさん** · 2023/05/04(木) 17:58:28.21

>>24
障害？

**デフォルトの名無しさん** · 2023/05/04(木) 18:03:56.15

/struct、/impl、/traitみたいな分け方をしたかったのかぁ
できなくはないけどやめといたほうがいいんじゃないか

**デフォルトの名無しさん** · 2023/05/04(木) 18:06:55.48

したいんじゃなくてそれは仮に書いただけ
自由度が低いと言うことを示したかっただけ

ファイル名やフォルダ名が縛られたり

なんで自由度が低いのに顔を真っ赤にして自由度が高いと書くのか不明なんだけど

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

>>25
C++は至ってシンプルやろ?

**ななし** · 2023/05/04(木) 18:16:37.43

Javaしかやったことない
C++っていいの？

**デフォルトの名無しさん** · 2023/05/04(木) 18:16:44.50

既存のC++のプロジェクトに書き足していくかたちでCargoとかが使われてるんだろ？
C/C++の作法に併せたRustのフォルダ構成の裏ルールがあるとしか思えない

**デフォルトの名無しさん** · 2023/05/04(木) 18:21:23.60

モジュール名とファイル名（パス）は↓みたいな書き方で一応切り離せるよ
ややこしくなるから基本使わないけど

#[path="platform/foo_windows.rs"]
mod foo;

自由度が高いってのはたぶん外面を維持したまま内装を変更しやすいって意味で使ってたと思う
（長文だったからちゃんと読んでない）

モジュールの構成は可視性に関わるからそこまで自由ではないと思う
全部にpubつければ自由になるけどそんな自由はいらない

**デフォルトの名無しさん** · 2023/05/04(木) 18:34:14.75

自分が使ってる中ではC#が一番自由度が高い気がする
classの分割自由
名前空間の分割自由
プロジェクト内ではフォルダ空間自由
ファイル名自由

**デフォルトの名無しさん** · 2023/05/04(木) 18:38:46.37

global usingと言うものが出来て各ファイルでusingもしなくて良くなった
これはいらない機能だと思うけど

**デフォルトの名無しさん** · 2023/05/04(木) 18:42:44.88

C#はまじめに使ったことないけど拡張メソッドとかいうのが自由すぎて若干引いた記憶がある
どこで何を足されるか分からない恐怖を感じた

**デフォルトの名無しさん** · 2023/05/04(木) 18:48:25.91

プロジェクト内のファイル位置も当然自由
一ファイルに複数の名前空間含めるのも自由

**デフォルトの名無しさん** · 2023/05/04(木) 19:14:36.30

Rustがなぜファイル名やフォルダ名でモジュール固定になってるかと言えば
それしかモジュール位置を決定する仕組みがないから
ルートのコードからたどれる物しか名前を解決できないから
それが良くないんじゃないの？

>>35
既存のクラスすべてで必ず拡張されるわけじゃない
本当は拡張などしてなくてただのstaticメソッドだし
どこかそれを他で使われていてもそれをusingしなければ使えないから関係ない
usingしててもpublicじゃなければ見えないので影響はない

**デフォルトの名無しさん** · 2023/05/04(木) 19:37:12.64

proc_macro で黒魔術やりたい放題出来る様になりますた
おまいらのお蔭です本当にありがとうございますた

っていうか proc_macro::TokenStream と proc_macro2::TokenStream と
同時に使うと違うと判ってても混乱するな

**デフォルトの名無しさん** · 2023/05/04(木) 19:41:38.84

>>35
>どこで何を足されるか分からない恐怖を感じた

これは Rust の trait や後付けの impl にも同じ臭いを感じる

**デフォルトの名無しさん** · 2023/05/04(木) 20:43:05.13

一応Rustのimplは型（trait）を定義したクレート内に制限かけてるけどそれでも気になる人はいるか
自由な場所で定義を足せるとどうしても散らかりやすくなる

**デフォルトの名無しさん** · 2023/05/04(木) 21:36:06.92

>>38
---- lib.rs 側 ----
use proc_macro::TokenStream;
use proc_macro2::TokenStream as PM2TS;
(略)
#[proc_macro]
pub fn mk_ts(_item: TokenStream) -> TokenStream {
let mut ts: PM2TS = PM2TS::new();
Ident::new("let", Span::call_site()).to_tokens(&mut ts);
Ident::new("x", Span::call_site()).to_tokens(&mut ts);
Punct::new('=', Spacing::Alone).to_tokens(&mut ts);
Literal::u8_suffixed(255u8).to_tokens(&mut ts);
Punct::new(';', Spacing::Alone).to_tokens(&mut ts);
ts.into()
}

---- main.rs 側 ----
fn main() {
mk_ts();
println!("{}", x);
}

これで実行は出来たけど TokenStream がぶつかってるのが気に入らない

**デフォルトの名無しさん** · 2023/05/04(木) 21:37:41.16

main.rs の方は
mk_ts!(); だった

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

>>30
基本的に、JavaとC++は兄弟言語で、共通点がとても多い。
classの概念もほとんど同じだし、とても良く似ている。
一方、RustとC++は全く違う言語。

**デフォルトの名無しさん** · 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は仮想レジスタマシーンである

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

>>143
同様に、x += y; は、
x,y をレジスタにとっていない場合は、
マシン語では、
mov eax,dword ptr [&y]
add dword ptr [&x],eax
となり、
x,y がレジスタ、ebx, ecx にとられている場合は、
add ebx,ecx
という1命令で書ける。
だから、x += y は、やはり、2命令になるときと1命令になるときが有る。
「ほぼ一対一対応」の意味は、このような意味で言っている。

C言語はどうしてもマシン語よりも粒度が大きいので、1命令に置き換える
事が出来ずに、2命令か3命令程度になってしまうことはある。

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

>>145
なお、Rustは、C言語よりさらに少し粒度が大きいことが多い。
C++は、C言語を包含するので、書こうと思えば、C言語と同じ粒度で書ける。

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

ながながとつまらないことを書いてるな

最適化でsimdを自動で使ってくれるベースがあればそっちが勝つわ

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

>>146
[補足]
誤解なきように行っておくと、Rustも、= や、+= のような演算子の粒度は、
C言語と基本的に同じことが多いので、その部分に関しての両者に優劣の
差は無い。だから、RustはC/C++と同じ程度の速度が出ることがある。

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

>>147
基本を知らない人が誤解する可能性があるので書く必要があった。
C/C++がアセンブラ以外に負ける可能性はほぼ無いと言うことの
根拠を示した。

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

コンパイラは高速化では中間言語化が有効なケースが多い
llvmの最適化はそれで行われてる
rustは二種類の中間言語に変換されてバイトコードを出す

でも中間言語に寄らないヒューリスティックな最適化も存在してる
そちらは泥臭く研究が進められてそちらは今llvmより速いコードを吐き出している

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

「ほぼ」の意味が、よく誤解されているから、混乱が起きているようなのだ。
「ほぼ」というのは、>>143 や >>145 の意味においてである。
決して、曖昧な意味で言っているわけではない。

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

>>150
それでも、C/C++は、そのRust独自の最適化後のコードを手作業で書くことが
できるから、Rustに負ける可能性が「ほぼ」ない。
ここで、「ほぼ」の意味は、>>143 や >>145 の意味である。

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

エスケープ解析はjava一時期重点的に研究されて実装に取り込まれている
誰か天才的な人間が開発に来たんだろう

golangも後追いでエスケープ解析入れてるけどエスケープ解析をオンにすると速度が落ちるケースが多いらしい
開発者が愚鈍なのか想定ケースを外れてるのか不明

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

マシン語とは、mov,add,sub,mul,imul,div,idiv,cmp,jnz,jb, jbe, ja, jae,call,ret
の組み合わせでプログラムする方式である。
それは、C/C++ 言語で「ほぼ」一対一対応でかけてしまう。
なので、Rustがそれを越えることは「ほぼ」不可能。
「ほぼ」の意味は、>>143 や >>145 の意味。

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

>>154
マシン語プログラミングとは、
mov,add,sub,mul,imul,div,idiv,cmp,jnz,jb, jbe, ja, jae,call,ret
のような20個ほどの命令を組み合わせて書く書き方。
ところが、C言語では、少し粒度が大きくなってしまうが、それらの20個の
命令に対応する命令が存在している。つまり、C言語では、マシン語の
1～3命令の単位で命令を書くことが出来る。マシン語の1命令にならない
ケースは、レジスタが足りなくて本質的に1命令で書けない場合。

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

エスケープ解析が有効なシーンにあっても速度向上はわずか1%～2%ぐらいのレベルなので
誤差と言えば誤差

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

>>154
時代に取り残されてるな
まず大昔にレジスタ最大限活用最適化により1対1は崩れてる
さらにパイプライン最適化によって手書きアセンブリが敗北するようになってのがだいぶ昔の話
並行してキャッシュ最大限活用最適化によりスタック利用有利がさらに強まったり

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

>>157
そんなことない。

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

お互いに自分の強いと思う必殺技を叫んで殴り合ってる状態だな
映画館に行かずにこんなところで聖闘士星矢が見られるとは…

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

今は究極のパイプライン最適化により
生成された機械語と元のプログラミング言語は実行順序すら異なる
だから連投してるアホ>>155の書き込みは読む必要なし
memory orderingとかすら知らない低レベル

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

いくらRustが独自の最適化しても、その最適化と同じことを
C++では書こうと思えば書けてしまうのだから、C++が負ける可能性
はない可能性がとても高いと言うこと。

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

>>160
そのレベルの最適化は、コンパイラの最後の段階であるところのLLVMレベル
で行なわれるから、Rustとclangで差が出ることは無い。
出るとしたら、LLVM最適化がたまたまその時には上手く最適化できなかっただけ。

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

>>162
厳密に言うと、「LLVMレベル」ではなく、それより
さらにマシン語に近いところのレベルの最適化。

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

まあ一番差が出るのは浮動小数ユニットの扱いだけどね。

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

>>162
同じLLVMを用いていても
C++よりRustが速くなった例はいくつか知られていて
それはRustの参照排他ルールによりLLVMに渡すことができる制御情報オプションが増えることで
LLVMによる最適化がRustの場合のみ生じることが原因のようです
つまりRustの言語仕様がC++より速くなるケースを生み出しています

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

どんどん互いにいい技術をパクリあって向上したらいいだけだろ
今後AIによるコード研究が進むだろうし技術的境目はどんどんあいまいになってく

過疎板でお互いにペガサス流星拳を打ち合う必要もなくなる

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

>>131
そもそもこのグラフが、何を測定したかの説明も無い。
事実である根拠も無い。
Rustだけ優秀な人がプログラムし、C++では、スクリプト言語上がりの
CPUやマシン語の基礎が分かってない人がプログラムしたのかもしれない。
それに、Rustは、必ず世界最強クラスの最適化バックエンドLLVMを使っている
のに対し、C++用のコンパイラは最適化がほとんど行なわれないような簡易
コンパイラも含まれる。

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

ていうか、シンプルにしか書けない(のが利点の)Rustに負けるC++の書きようが悪いって話
きれいに書こうなｗ

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

>>131
「実行時間」というが、PICやAKI-H8、ラズパイPICO、安物Androidデバイス
と、Core i9 とでは全然違ってくる。
Rustは、32BIT 以上専用なのに対し、C++ は、8MHz(?) の 16BIT の
PIC マイコンでも使えるのだから、比較にならない。
C++は、安い低速CPUでも動くが、Rustは高級で豪華な CPU でしか動かない
ということだ。それがグラフに現れているだけだろう。

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

>>165
>それはRustの参照排他ルールによりLLVMに渡すことができる制御情報オプションが増えることで
>LLVMによる最適化がRustの場合のみ生じることが原因のようです
>つまりRustの言語仕様がC++より速くなるケースを生み出しています
その場合、C++でも、同じ「参照排他ルール」に従ってプログラムすれば、
LLVMは同じように最適化できるだろう。

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

>>167
>>169
atcoderは競技プログラムのプラットフォームで参加者がコード書いて提出
コンパイルも向こうでされてるので統一した環境ではあるかなとｗ

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

>>171
だったら、外国では、C++には、レベルの低い人も参加したのに対して、
Rustはレベルの高い人だけが参加した可能性が高い。

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

atcoderは日本のサイトだよ
出題は英語で去れ店の？

rustは答えを出せる人間が少なく
低レベルコーダーが足切りされてる可能性が高い

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

>>172
もう一つの可能性は、C++は歴史が長いから、古いCPUで測定された時の
実行時間が記録に残っているのに対し、Rustは、新しいCPUで測定された
記録しか存在して無いという不公平があるのかもしれない。

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

>>173
つまり、
「Rustは初心者向けではない」
「Rustは優秀な人が試している段階」
ということを示しているのかもしれない。

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

おじいさんは自分の見たいものしか見ず考えもしない

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

Rust信者は木を見て森を見ず。

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

>>170
参照排他ルールに従うプログラミングをするだけでは最適化されません
言語コンパイラがLLVMへその指示を出さないとLLVMは最適化しないし出来ません

例えばLLVMのnoalias最適化指示の場合
Rustではプログラマーは何も指定しなくても言語仕様によりRustコンパイラが自動的にLLVMへ自動的に指示を出します
C言語の場合はrestrict修飾子が導入されているためプログラマーが自己責任で修飾すればCコンパイラがその指示を出すことが可能です
C++は言語仕様にないためプログラマーは指示できません (言語仕様を独自拡張しているコンパイラのみ可能)

以上のようにプログラマーが何も指示せずともLLVMで最適化が行われるRustが有利な現状です

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

>>178
それは初めて知りました。
このスレで初めてまともな意見です。

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

C++の方が自由度が高いのだから遅く書くことを妨げない
一方でRustの自由度は低い
書いた人のレベルが如実に現れたってだけでは?
実際に最速は変わらない
Cの最速が遅いのはサンプルが少なかったから?

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

でたらめを書く前によく見ろよ
グラフにatcode abc 182 e と書かれてるからその問題見て見たらいいだろ

abc = AtCoder Beginner Contest
2020-11-08(日) 21:00 ~ 2020-11-08(日) 22:40 (100分)
問題はAからFまであり後ろに行くほど難易度が高い

E問題を見ると再帰も使わないただのループ問題だからrustの有利なシーンはないと思う
制限時間があるからそこまでの問題で事実上足切りされた人が多いんだろ

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

そもそも、atcoder なんて知りませんから。

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

通常通り書くとやはりpythonとかは遅くなると思う

速い回答出せた人もいると言うことは技術的に枝狩りできるシーンがあるんだろうな

atcoder知らない＝おじいちゃん

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

C++でやった人は、単に個人の遊びとしてやっていただけなのに対し、
Rustでやった人は、Rustの力をこのスレで自慢するために最高の品質
のコードを書いた「バイアス」があった可能性を除外できない。

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

atcoderで性能比較www

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

atcoderなんてやってるほど暇人じゃないから。

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

なんで1問だけで比べるのか
データ公開されてるよね？

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

それでこのスレでペガサス流星拳を撃ってるとｗ

その前におじいちゃんはe問題解けるのかなあ？

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

なにがペガサス流星拳なんだか、幼稚な。

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

pythonでギリギリ問題解けるようなレベルの人間がc++やrustに移行できるとは思えない
c++やrustという言語で足切りされてる

でも今後はプログラマー不足が顕著になるのでpythonの利用が促進されると思うわ

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

そもそも、「実験しなければ分からない」というのは物理や数学、コンピュータの
世界ではウソ。理論があるし、人間には想像力があるんだから、思考実験で
済む場合が多い。但し、アホな人は除く必要がある。

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

プログラムの最適化に詳しくてもプログラム自体出来ないなら本当に存在意義が不明なんだよな
○○が早いと言う人より目的時間内にコードを完成させる人が求められている
アセンブラが捨てられて高級言語が使われてる
生産性の向上が一番の問題

○○速くてスゲーと言うのは意味がない
知識があれば小学生にでも言える

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

>>190
そこで不足している簡単なレベルかつPythonでできるようなことならば
類似サンプルも多数ネット上に転がっているせいでChatGPTが答えられる
だから従来は人員不足とされたその分野の人材は不要となった
C++/Rustで書かれる分野は少なくとも現状のAIは対応できない
特にインフラをAIが吐くコードに依存するのはリスクが高すぎるため人間の最後の砦として需要が残るだろう

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

小学生に○○流星拳と言う言葉を教える

何かあればそれを叫ばせるこれがこのスレで起こってる全てです

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

AtCoderの良問は良問だぞ俺は全然だけど
あんなもん要らねえｗｗｗとうそぶきつつ、こそっとやっとくと賢くなる

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

>>172みたいに自分に都合の良い想定を平気で行う人間は
どういう大学出てるんだろうな
「可能性が高い」なんて学部生のレポートレベルでも書かないわ
そのへんのリテラシーなくクソレス書き散らしてるの恥ずかしくないのか

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

大見得切ってる割に単発で書いてる時点でな

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

競技プログラミングってC++でやるもんでしょ
集まってくるやつのレベルもピンキリだよ

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

>>131の各プログラミング言語の実行速度比較は実行環境が統一されてる点で信頼度が非常に高いと思う
さらに多数の人たちがコードを書いているためコードのせいで遅くなったりする要因も排除できてる
たまにあるベンチマーク比較でコードが下手なせいで言語によって左右されてるのも見かけるため

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

自分は触れたくないがpythonって存在は面白い
c++やrustには移れないのにpythonならできるって人が多い

今後c++やrustの研究が進んで実行速度が1%上がるとかそんなレベル
乾いたぞうきんを絞ってる
それだったらpythonをjava並みに引き上げるほうが社会的意義があると思う

pythonの有名ライブラリはc++で書かれてチューンされて実行速度は速い
個人が各部分のコードが遅くてもライブラリが速いならこれで十分
でもそれがc++ユーザーに反映されて利用が進んでいるとは言えない
一般の研究で利用はpythonに軸足が移ってる
今後も進むだろうし