次世代言語28 TypeScript Swift Go Kotlin Rust Nim

**デフォルトの名無しさん** · 2022/08/29(月) 11:22:16.48

スレタイ以外の言語もok

前スレ
次世代言語27 TypeScript Swift Go Kotlin Rust Nim
https://mevius.5ch.net/test/read.cgi/tech/1659655598/

**デフォルトの名無しさん** · 2022/09/02(金) 08:36:58.81

>>77
その割にはforの安全チェックとか持ち出しているやついるけど。
それに配列ならコンパイル時にサイズが決定する／しないで全然違うけど、そこをごっちゃにしているアホがいない？

**デフォルトの名無しさん** · 2022/09/02(金) 09:00:49.10

ほんとダメだねえ、どうやっても遅いんだが？顔真っ赤にして人を罵倒する前にさ
https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=f46924c1a775bf93703ca7aead58b36c
real 0m0.111s
https://wandbox.org/permlink/iP4fPQ7bODKrg7mC
real 0m0.006s

「C言語でもループ1回に付き必ず1回のインデックス値の境界比較が必ず入る」
まず根本的に勘違いしてるのがあなたの言ってるのは境界チェックじゃなく、終了条件のチェックであり、これも、gccなどの処理系では
最適化で固定値だったりしてループ展開したら必ず入るとは限らないんですよ・・・同様のことがRustの勝手にループ展開でも言えますが
いずれもループ終了チェックであり、そんなのは比較していませんし、またあとから出てきたイテレータの話は全く違う話ですね

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

>>78
批判するにはちょっと知識不足すぎじゃない？
みんなが書いているRustのスライスはコンパイル時に長さが確定しないから、確定する配列だけでなく、どちらの場合でも大丈夫ってこと

**デフォルトの名無しさん** · 2022/09/02(金) 09:13:12.31

前スレでも出てたけどrustがphpより遅いってマジっぽいね

**デフォルトの名無しさん** · 2022/09/02(金) 09:17:24.54

>>79
あまりにキチガイでワロタ
その約20倍差の数値で比較しちゃってるのかよ
本気で20倍速いと思い込んでる？

**デフォルトの名無しさん** · 2022/09/02(金) 09:24:36.61

>>74
レス番つけ忘れたけど、頑にCと（速度が）同じだ。遅くないというカルト信者みたいな態度はほんと反省してほしいわ・・・
根拠を示したのにキチガイと反論するばかりで、こんな簡単なプログラムにさえどこが悪いのか言えないし

**デフォルトの名無しさん** · 2022/09/02(金) 09:32:20.12

誰も20倍速いなんて一言もいってませんが？timeごときでこの程度の差が出るのであれば、「同じ」なんて言えないと思いますが？
むしろ境界チェックが機能してる結果であり、一方でCはそのような境界チェックは通常の処理系ではありえない＝チェックがないので
安全性はlintなどやプログラマーの能力に依存する
提言：”内容に反証を提示できず、人をキチガイ呼ばわりする人がキチガイ”

**デフォルトの名無しさん** · 2022/09/02(金) 10:07:22.38

> C言語でも他でもfor文で境界チェックが必ず入る

std::vectorだと両方あるから説明しやすいけど

reference at(size_type n);
　n >= size()の場合、out_of_range例外を送出する。

reference operator[](size_type n);
　vector型のオブジェクトvに対して、v[n] と *(v.begin()+ n) は同じ結果になる
　n >= size()の場合、未定義動作となる
　この関数は、at()メンバ関数とちがって境界チェックを行うことが規定されない。

境界チェックってこれの話じゃないの？
index側のどうこうはさておき、要素アクセスのときにケアできてるかどうかの話じゃないの？

**デフォルトの名無しさん** · 2022/09/02(金) 10:13:15.80

ちなみにJavaのjava.util.Listは

https://docs.oracle.com/javase/jp/8/docs/api/java/util/List.html#get-int-
E get(int index)
　例外: IndexOutOfBoundsException - インデックスが範囲外の場合(index < 0||index>= size())

となってる。

**デフォルトの名無しさん** · 2022/09/02(金) 10:33:22.77

現代のCPUなら投機的実行で境界チェックみたいな処理は時間コストかからんけどなあ
それとRustのprintln!は非バッファでロックもするから配列性能計測に混ぜたらいかんでしょ
性能計測の初歩だと思うんだけど

**デフォルトの名無しさん** · 2022/09/02(金) 10:41:36.52

ここが応仁の乱か

**デフォルトの名無しさん** · 2022/09/02(金) 11:14:19.45

Rustのスライスsでfor i in 0..s.len()でループ回して見たら
生成コードはforの終端チェックだけになってs[i]の境界チェックは消えるんだな
確かに論理的に正しい最適化だが賢いな
結局Cでfor (i = 0; i < len; i++) とした時と同じ

**デフォルトの名無しさん** · 2022/09/02(金) 12:00:55.17

println!取り除いてもCより遅いけど？
勝手にコードを変更してs.lenとか悦にはいってるし、この人たちって絶対objdumpした結果を上げないね
同じ（＝100%一致）なんて絶対あり得ない、gccじゃなくclang/llvmにしたら分らんけど、それでも
”Ｃ言語は”なんてあんたさえも知らない処理系があるのに恥ずかし気もなくビックマウス披露出来るわけない
投機実行の境界チェックのバイパスは有名なスペクターとして脆弱性だから機能してないんちゃうか？知らんけどさ

**デフォルトの名無しさん** · 2022/09/02(金) 12:40:37.54

>>80
固定長なら範囲チェック自体消えるだろ。

Rustの話をするなら、「ひとつの読み書き参照 xor 複数の読み取り参照のきっつい制約を課すことで範囲チェックの回数を減らしている」くらいの説明はできんのかね？オレも詳しくはないが。

**デフォルトの名無しさん** · 2022/09/02(金) 18:35:42.02

引数で与えられた配列の中の最大要素をインデックスアクセスで探す関数をC (clang 14) と Rust (rustc 1.63.0) で書いた
使ってるレジスタこそ違うけど同じコンパイル結果になった

https://godbolt.org/z/TvdGf3dYq

Rust は他の書き方も試してみたけど生成されたコードは同じっぽい

forでsliceをイテレートした場合:
https://godbolt.org/z/38s1819hr
イテレータアダプターだけで書いた場合:
https://godbolt.org/z/cjqqYjKfE

**デフォルトの名無しさん** · 2022/09/02(金) 19:48:54.34

っつーか今さらcでの開発なんて小規模じゃないとやりたくないわ。

**デフォルトの名無しさん** · 2022/09/02(金) 20:22:00.68

遅いくせにCと同等とか言い出したのが発端じゃね？

**デフォルトの名無しさん** · 2022/09/02(金) 20:51:46.96

>>92
凄いな
CとRustは同じ生成コードになるんだな
どちらも64バイトでループ展開か

**デフォルトの名無しさん** · 2022/09/02(金) 20:58:00.60

>>94
生成コードが同じだからCとRustは速さも同等っぽい

**デフォルトの名無しさん** · 2022/09/02(金) 21:28:46.71

>>96
マジか、rustすご過ぎ

**デフォルトの名無しさん** · 2022/09/02(金) 21:41:46.84

わざわざ境界値チェックが不要になるケースで比べたらそりゃそうだろって感じ
最初のサンプルコードが酷すぎた

**デフォルトの名無しさん** · 2022/09/02(金) 21:45:38.80

>>98
境界値チェックが必要なケースをよろ

**デフォルトの名無しさん** · 2022/09/02(金) 22:15:29.02

結論が出たな
Rustを攻撃してた人が以下のようなウソをついてた

> 「結果としてCでもRustでも同じ生成コードとなる」絶対ならないからｗ
> つーかアセンブラして貼り付けろよ？

> そもそも配列ループの遅さをカバーするために
> Rustは速度を稼ぐために一部分ループ展開を勝手にするはず

生成アセンブラコード>92を見ると
CでもRustでも同じ生成コード
CもRustもループ内のインデックス境界チェックは無く同じコードとなっている
そしてCもRustも一部分ループ展開を同様にしてる
当然どちらも同じ速度となる

**デフォルトの名無しさん** · 2022/09/02(金) 22:58:49.99

>>98
早くc言語で境界値チェックするコード出してよ。

**デフォルトの名無しさん** · 2022/09/02(金) 23:27:03.89

全然読まない、勝手にコードを変更してs.lenとか悦にはいってる

**デフォルトの名無しさん** · 2022/09/02(金) 23:59:11.14

>>102
配列やベクタやスライスなどを一般的に
C言語で扱う関数ならば先頭ポインタと長さを受け取る
Rustならばその二つがペアとなったスライスsを受け取りその長さ部分がs.len()
だから常識的なプログラマーならば誰が書いても>>92のソースコードとなる
そして生成アセンブラコードがCとRustで同等と判明した

**デフォルトの名無しさん** · 2022/09/03(土) 01:19:34.52

おじさん普通にC勉強した方が良いよ
Rust書ける人でC書けない人なんていないからズレまくった指摘してるんだよ
Rustであえてパフォーマンス出ないようなコードを書いてるとしか思えない

**デフォルトの名無しさん** · 2022/09/03(土) 01:46:36.01

>>92のシンプルなコードをこれ以上に速くするのは無理じゃね
そしてRustもCも同等のアセンブリコードを吐いてるから実行速度も同じで勝負ついた感じだな

**デフォルトの名無しさん** · 2022/09/03(土) 03:19:04.56

バカ野郎！
Rustのおっちゃんは、日本を代表するトライアングル（楽器）奏者なんだぞ！

**デフォルトの名無しさん** · 2022/09/03(土) 04:44:36.86

少なくとも配列範囲外アクセスするようなコードで比べなければ意味がない。
誰も勝負なんてしてないだろ
こんな事やってるからRustを嫌う人が割と増えていく、言い逃れそのものだろｗ

そもそもforの終了条件チェックと配列境界チェックの違いすら分かってないやつだ
カルトRust信者「C言語でもループ1回に付き必ず1回のインデックス値の境界比較が必ず入る」

固定長のループがclang/llvmで同じになったとして、壺カルトRust信者曰く、「C言語は」という
デカすぎる主語と、Rustでのすべての配列境界チェックが無くなるわけではなし何が勝ちなんだか...

**デフォルトの名無しさん** · 2022/09/03(土) 05:27:05.78

>>107
コードを読めない人なの？
固定長のループではなく長さは関数の引数として与えられている
したがってC言語でもループ1回に付き必ずインデックス値の境界比較(＝インデックス値が長さを超えないこと)がfor文の条件部で行われている

**デフォルトの名無しさん** · 2022/09/03(土) 06:17:52.84

>>92
例えばinline化とかで二つの配列/スライスがエイリアスされていることがコンパイラー(とプログラマー)に見えている場合があると思うんだけれど
Rustの方は自動ベクトル化してくれないのね。Cの方は自動ベクトル化されている。

極端に書くとこんな感じ。
ttps://godbolt.org/z/sbenoGEEa

inline
ttps://godbolt.org/z/M6qz3s3f7

max_value_slice_vwをどう書いたら自動ベクトル化されるの?

**デフォルトの名無しさん** · 2022/09/03(土) 06:38:25.68

何の争いかよくわからんけどつまりRustでサイズ10の配列を作ってその11番目の要素にアクセスしたらどうなるん？
Cだと境界チェックしないから未定義になるしセグフォ出たり他の変数を書き換えたり暴走したりすることもある

**デフォルトの名無しさん** · 2022/09/03(土) 06:40:51.52

11というのをリテラルで与えるともしかしたらコンパイルエラーになるかもしれんけどたとえばそれを乱数で生成した場合はどうなんの？

**デフォルトの名無しさん** · 2022/09/03(土) 06:53:51.31

Cが境界チェックしないと言うのは境界チェックがプログラマの責任だということだよね
Rust以外のモダンな言語では大抵範囲外の要素にアクセスしようとすると実行時例外を吐く
Cはそれをせず黙って暴走したりこっそり他の変数の値を書き換えたりして気づきにくいバグになる
Rustはどっち？

**デフォルトの名無しさん** · 2022/09/03(土) 06:56:12.20

>>109
わざわざw = v; とか
架空コードすぎて気持ち悪い

**デフォルトの名無しさん** · 2022/09/03(土) 07:06:18.00

>>112
Rustは基本的には他の大多数の言語と同じで、アクセスする前に自動的にインデックスの境界チェックをする。

ただし、>>92などのように多くのプログラム利用例では、インデックスはforで指定範囲を動くため、アクセスする際のインデックス境界チェックは最適化により必要とせず行われなくなり、結果としてC言語と同じアセンブラコードが生成される。

**デフォルトの名無しさん** · 2022/09/03(土) 07:13:36.64

つまり、Rustは安全性を常に保ちつつ、不要な境界チェックは最適化で無くすことで、安全かつ高速を実現。

**デフォルトの名無しさん** · 2022/09/03(土) 07:29:39.97

>>114
普通じゃね？

**デフォルトの名無しさん** · 2022/09/03(土) 07:34:10.00

CとRustは同じアセンブリコードを生成すると>>92で示されているから
あとは他の言語でもそうなるならそれを示せばよい

**デフォルトの名無しさん** · 2022/09/03(土) 07:37:07.45

どうでもいい内容で盛り上がってるな
for文の仕様がボトルネックになることなんかないんだからどうでもいい

**デフォルトの名無しさん** · 2022/09/03(土) 07:46:39.87

例えばfor (i=0;i<len;i++) arr[i*2]=0;
Rustはこの時もCと同じコードになるんだよね？

**デフォルトの名無しさん** · 2022/09/03(土) 07:56:47.99

gccのコミッターのものだけどそんな単純な話じゃないよ
Rustのスティーブとはよく話をするけどね

**デフォルトの名無しさん** · 2022/09/03(土) 08:03:29.06

最後の一行で胡散臭さ出てくるの何なん

**デフォルトの名無しさん** · 2022/09/03(土) 08:04:34.15

まあこんなマイクロコードの比較だのベンチだのに意味は無いわな
コンパイラも局所だけ見て処理するわけでもなし

**デフォルトの名無しさん** · 2022/09/03(土) 08:23:27.57

>>119
Rustのfor文はそういう構文ではない
あとRustではその処理関数は引数をスライスxで受けることになり
lenはx.len()となる

そしてfor i in 0..lenのループの時
x[i] = 0ならばそのアクセスには境界チェックは最適化により生じない　(C言語と同じ)
x[i*2] = 0ならばそのアクセスには境界チェックが入りindex out of boundsとなる　(C言語と異なる)

**デフォルトの名無しさん** · 2022/09/03(土) 08:27:29.75

>>123
境界チェックがあるって言われてるのはその場合のことだよ
最適化で無くなる時の話をしてるのは君だけじゃないかな多分

**デフォルトの名無しさん** · 2022/09/03(土) 08:47:00.60

rust書けるやつはたいていcも書ける。
cは書けるがrust書けないなつはいる(俺とか)。
両方書けるほうがいいに決まってる。

**デフォルトの名無しさん** · 2022/09/03(土) 08:47:14.13

>>123
後者はC言語だと範囲外をアクセスしてしまい破綻だな
境界チェックをするRustが正しい

**デフォルトの名無しさん** · 2022/09/03(土) 09:09:01.93

>>124
正しい使用ならば最適化されて境界チェックが消える点も重要やで
それによりRustのコードがCとほぼ同じ速度で動いている

一方で間違った範囲外のアクセスが起きうる場合には境界チェックがなされる点も重要やで
それによりRustはCとは異なり安全となっている

**デフォルトの名無しさん** · 2022/09/03(土) 09:12:44.80

>>123,126
> あとRustではその処理関数は引数をスライスxで受けることになり
> lenはx.len()となる
配列の一部だけを処理したいとか普通にあるだろ

**デフォルトの名無しさん** · 2022/09/03(土) 09:21:53.95

>>128
配列の一部分はスライス　(配列全体も可)
Vecの一部分もスライス　(Vec全体も可)
スライスの一部分もスライス
なのでRustで関数を書くときはスライスを対象にして記述する
そしてスライスとして扱った時点で既に境界チェック済み(＝元の範囲内)なので最適化が可能となる

**デフォルトの名無しさん** · 2022/09/03(土) 09:24:37.68

さすが複オジ隔離スレやで
今日もいい仕事しとるww

**デフォルトの名無しさん** · 2022/09/03(土) 09:27:25.47

Rustの実行速度がCと同等だと何か困ることでもあるの？

**デフォルトの名無しさん** · 2022/09/03(土) 09:30:24.03

>>129
関数内でlenが決まる場合でもいちいちスライス作るのか？

**デフォルトの名無しさん** · 2022/09/03(土) 09:32:15.16

C/C++ で BITMAPINFOHEADER なんか扱うときは
意図的に範囲オーバーさせて bmp データにアクセスするよねω株 PI.3.14

**デフォルトの名無しさん** · 2022/09/03(土) 09:37:13.56

>>131
Rustアンチの人にとって「Rustは遅い！」が信仰の砦。
ところが世間で言われてる通り、RustはCとほぼ同じ速さだと>>92で分かり、大変なことになってしまって大騒ぎ。

**デフォルトの名無しさん** · 2022/09/03(土) 09:45:26.31

困るとか困らないとかじゃなくCではやらない境界チェックがあるから現実に遅いよ

**デフォルトの名無しさん** · 2022/09/03(土) 09:47:19.22

Cと同じ速度で動くコード「も」あるというならその通り
他の言語でもある

**デフォルトの名無しさん** · 2022/09/03(土) 09:52:51.38

>>132
Rustのスライスは抽象化された概念で扱われるけど
実体は先頭ポインタと長さのペア
だからスライスを作るって大層なことではなくC言語で処理対象の先頭ポインタと長さを用意するのと同じ

あと、Rustではforインデックス使わずにイテレータチェーンにすることも多いけどその時もスライス起点が多い
そのイテレータチェーン利用時も>>92の下でforインデックス時と同等の生成コードになることが示されてる
つまり境界チェックは起きずC言語と同じ速さで動く

>>136
C言語より遅いコードがあると主張したいならば
具体的に>92のように生成コードの比較を出せばよい

**デフォルトの名無しさん** · 2022/09/03(土) 09:54:03.17

境界チェックが消えたコードじゃなく消えてないコードで比べてみたらすぐわかるんじゃないですかね

**デフォルトの名無しさん** · 2022/09/03(土) 09:54:19.38

>>135
コンパイルオプションでチェック無効に出来ないの？

**デフォルトの名無しさん** · 2022/09/03(土) 09:56:34.91

>>139
C#はできるね

**デフォルトの名無しさん** · 2022/09/03(土) 09:59:58.21

>>137
> だからスライスを作るって大層なことではなくC言語で処理対象の先頭ポインタと長さを用意するのと同じ
いや、実装は想像できるからいちいち説明してもらわなくてもいいんだけどC言語だといちいちそんなもの作らないよ
先頭ポインタも長さ情報も既にあるのに同じ内容を持つスライスを作るのは（C言語脳としては）無駄に思える

**デフォルトの名無しさん** · 2022/09/03(土) 10:03:47.05

>>138
CよりRustが遅いコードを具体的に出してよ
array[i*2]の例は危険な範囲外アクセスとなるコードだから境界チェックをするRustに軍配が上がるね
だから安全な正しいコードなのにCよりRustが遅いコードを具体的に生成コードと共に出しましょう

**デフォルトの名無しさん** · 2022/09/03(土) 10:06:50.84

>>142
プログラマが完璧なら危険ではないので上司のしりぬぐいをしないというのがCのスタンス
Rustはチェックするので正しいが遅い

あのー、わざとやってるのかバカなのかどっちなの？

**デフォルトの名無しさん** · 2022/09/03(土) 10:11:51.77

>>141
Rustではもっと抽象的に捉えてプログラミングするからそこに無駄と考える発想は出てこないし
同じだから無駄だといっても生成コードは最適化で無駄は消えるからCと同じ速さが出るでしょう

**デフォルトの名無しさん** · 2022/09/03(土) 10:14:07.95

実例と計測結果出さないと空論でしか無いわな
まあ速度差が無くて出せないんだろうけど

**デフォルトの名無しさん** · 2022/09/03(土) 10:17:36.98

チェックが入ると遅くなるから最適化でチェック省くことがあるんだろうに何で実測しなきゃわかんないんだよ
特定のスニペットじゃなく境界チェックが入る現実のコードの話をしてるのに実測なんてできるわけないだろ
境界チェックが原因で遅くなるコード作れと言うなら作るが、それ作ったら間違いを認めるんだろうな？

**デフォルトの名無しさん** · 2022/09/03(土) 10:20:44.15

>>144
ホントに常に消えるの？
ダメなケースは存在しないの？

**デフォルトの名無しさん** · 2022/09/03(土) 10:20:52.59

>>143
それは君が誤解してるようにみえるなあ
Rustでは安全に範囲内のアクセスとRustコンパイラが分析できれば境界チェックをしないためCと同じ速さが出る
そうでなく危険な範囲外のアクセスになりうるとRustコンパイラが判断すれば正しく境界チェックを行なう
C言語で書いても危険な範囲外のアクセスになりうる場合は手動で境界チェックをせざるを得ないから速さは同じ

**デフォルトの名無しさん** · 2022/09/03(土) 10:22:44.18

>>148
同じじゃなく遅くなると認めろよ

**デフォルトの名無しさん** · 2022/09/03(土) 10:28:32.67

>>149
遅くなる具体例ありそう？それ知りたい
RustとCのアセンブリ生成コードが同等になり速さが同じとなるケースは>>92で示されてるから
同じようにして遅くなるケースを示せばよいと思う
もちろん範囲外アクセスとならない例でw

**デフォルトの名無しさん** · 2022/09/03(土) 10:32:05.60

いつもの嘘つき複オジに必死に突っかかるアホ
どっちもどっち

**デフォルトの名無しさん** · 2022/09/03(土) 10:49:11.71

>>148
> そうでなく危険な範囲外のアクセスになりうるとRustコンパイラが判断すれば正しく境界チェックを行なう
C言語では外部からもらったデータは仕様で配列範囲に入るのが確実だからチェックをしないとかあるんだけど、Rustコンパイラとやらは仕様書まで読み込んでくれるのかなw

**デフォルトの名無しさん** · 2022/09/03(土) 10:52:15.27

境界チェックによるペナルティが気になる箇所なら境界チェックのないget_unchecked使えば良いのでは
デフォルトは安全側に倒されてるけどプログラマの裁量で速度を優先することもできるので、適材適所でどちらを使うか選べば良い
C++でも境界チェックありのat()があるから、デフォルトが逆なだけでできることは同じだよね

**デフォルトの名無しさん** · 2022/09/03(土) 11:03:40.39

結局プログラマーの手に委ねていると必ずミスが起きうるから
境界チェック省略の件も含めて全てについて
コンパイラが分析して安全かどうか判定できた時にはチェックを省略し
そうでない場合は安全のために自動的にチェックをするのがベスト
という方向へ向かっているんじゃないかな

GoogleやMicrosoftがRust言語でOS開発
https://xtech.nikkei.com/atcl/nxt/column/18/00692/042700054/
【脆弱性の70％がメモリー管理バグに起因】
GoogleによればAndroidに存在した深刻なセキュリティー脆弱性の70％近くがメモリー安全に関するバグに起因するという。
同様にマMicrosoftも、同社製品に存在したセキュリティー脆弱性の70％がメモリー安全に関するバグに起因すると述べている。
C/C++を使う限りセキュリティー脆弱性を根絶するのは不可能と考えて、Rustを採用するに至ったというわけだ。

**デフォルトの名無しさん** · 2022/09/03(土) 11:21:29.31

マジキチだった

**デフォルトの名無しさん** · 2022/09/03(土) 11:53:26.95

>>150
じゃあCよりRustが遅くなるコードを示せばごめんなさいすんのか？しないだろ？
ここまでの説明でわからないバカがいるはずないからレスバしたいだけだよな？

**デフォルトの名無しさん** · 2022/09/03(土) 11:55:04.03

この話題、ここ数年で最もレベル低いんじゃないか？大丈夫か？

**デフォルトの名無しさん** · 2022/09/03(土) 12:31:15.03

Rustは安心安全でC言語と同等の速度ってことでFAだな

**デフォルトの名無しさん** · 2022/09/03(土) 12:34:45.63

体言止めおじさん

**デフォルトの名無しさん** · 2022/09/03(土) 12:53:59.17

最近のレベル低下には目を見張るものがあるな

**デフォルトの名無しさん** · 2022/09/03(土) 12:58:26.77

>>142
>array[i*2]の例は危険な範囲外アクセスとなるコードだから境界チェックをするRustに軍配が上がるね

array[i*2]の例は危険な範囲外アクセスとなるコードだから境界チェックをしないCに軍配が上がる
が正しい

**デフォルトの名無しさん** · 2022/09/03(土) 13:35:09.09

いやはや、時代についていけないCオジが暴れてるようだなw
Cオジもさぁ、自分の世界に引きこもってないでもっと外の世界見ないとねw

**デフォルトの名無しさん** · 2022/09/03(土) 13:37:41.33

Cこそ最強！
1個でもCより遅いケースあったらダメね！

**デフォルトの名無しさん** · 2022/09/03(土) 13:38:08.80

次世代言語スレなんだから変数の境界越えたアクセスは落とす一択だろ。

もうちょっと別の話したいわ。

**デフォルトの名無しさん** · 2022/09/03(土) 13:38:32.50

1個でもCより遅い場合あったら、他にメリットあっても意味ないから！

**デフォルトの名無しさん** · 2022/09/03(土) 13:50:50.43

誰も>>91の突っ込み無いんかよ。
Rustが速いのは非常にキツイxor条件を満たす範囲だけで、そこを超えるのはとても面倒。そこを無視して「Rustは安全で高速」とか言うのは詐欺じゃね？

あと、次世代スレなのに何でRustとcだけの比較なんだよ。rangeの最適化なんてイマドキc++ですらやるんじゃないの？

**デフォルトの名無しさん** · 2022/09/03(土) 14:31:36.61

このスレは何もかもをRustと比較したがる信者とそれに反応してしまうバカに乗っ取られた隔離スレです
次世代言語スレではありません
次世代言語の話がしたいかたはこちらへ↓

次世代言語27 Nim Zig Pony Carbon Gleam
https://mevius.5ch.net/test/read.cgi/tech/1659660050/

**デフォルトの名無しさん** · 2022/09/03(土) 14:36:16.07

ていうかこいつほんとにRust使ってプログラミングできるの？って思ったんだけど
あまりにも頭が残念すぎて論理的思考の必要なプログラミングができるとは思えない

**デフォルトの名無しさん** · 2022/09/03(土) 14:49:28.41

>>165
Cで書いた方が良い箇所はCで書けば良いのでは
アプリケーション全体を単一言語で書かなければならない理由もなかろう

**デフォルトの名無しさん** · 2022/09/03(土) 17:15:49.49

>>167
最終レスが8月18日とか終わってんじゃねえか

**デフォルトの名無しさん** · 2022/09/03(土) 17:17:49.88

TypeScriptは次世代なのか？
そろそろ枯れてきてるし何ならバニラが復権しかけてんだが

**デフォルトの名無しさん** · 2022/09/03(土) 17:37:42.10

>>169
そんなこと言ったらRsutを使う場面が無くなっちゃうだろ

**デフォルトの名無しさん** · 2022/09/03(土) 18:07:45.82

Rustはスライスに対して境界チェックをしないでアクセスする方法もunsafeで用意されている
つまり最適なプログラミング方法はC/C++を絶対に使わずに全てをRustで記述し
「コンパイラによる安全保証で最適化により安全に境界チェックを省略してくれる部分以外」かつ「人間による安全保証で境界チェックを不要としたい部分」のところのみunsafeで人間が安全保証し
その部分以外は全てコンパイラにより自動的にあらゆるメモリ安全保証させるのが最適な方法となる

**デフォルトの名無しさん** · 2022/09/03(土) 18:32:15.93

>>137
>>109は RustがC言語より圧倒的に遅いコードです

>>166 172
＞Rustが速いのは非常にキツイxor条件を満たす範囲だけ
＞「Rustは安全で高速」とか言うのは詐欺
＞そんなこと言ったらRsutを使う場面が無くなっちゃうだろ

完全同意
Rustの最適化度合いは一貫性がなくて信頼できない
「Rustで高速化」が少しでも視野に入っている人は
Cコードも書いて常にasmとBenchmarkで比較確認するしかない

＞173
109はRust版が10倍くらい遅いんだけどunsafe使ったら早くなるの？

**デフォルトの名無しさん** · 2022/09/03(土) 18:40:11.28

え？↓これってデマなんだよね？

https://qiita.com/shadowTanaka/items/5fb99819629dcaab3e05

**デフォルトの名無しさん** · 2022/09/03(土) 19:00:48.70

>>174
わざわざ　w = v; 　してそんな無意味なプログラムを書く人いないよ
>>92のような実際に使われているパターンの意味のあるプログラム例が欲しいな

**デフォルトの名無しさん** · 2022/09/03(土) 19:10:31.55

>>109
これって偶然とか意図に関係なく引数が手に負えなくなると
Rustが全く最適化をしない、というPOCじゃね?

>>92
はhello worldレベル過ぎて逆に意味なくない?