次世代言語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/08/29(月) 13:57:56.66

>>1 乙

>>980 次スレ立ててね

**デフォルトの名無しさん** · 2022/08/29(月) 17:39:40.63

文字列の変数sが与えられた時に
変数a (符号付き32bit整数)、
変数b (符号なし64bit整数)、
変数c (64bit浮動小数点数)へそれぞれ変換するコード

【Rust】
let s: &str = "12345";
let a: i32 = s.parse()?;
let b: u64 = s.parse()?;
let c: f64 = s.parse()?;

【Kotlin】
val s: String = "12345"
val a: Int = s.toInt()
val b: ULong = s.toULong()
val c: Double = s.toDouble()

【Swift】
let s: String = "12345"
let a: Int32 = Int32(s)!
let b: Uint64 = Uint64(s)!
let c: Double = Double(s)!

【Go】
var s string = "12345"
var err error
var a int32
a, err = strconv.ParseInt(s, 10, 32)
var b uint64
b, err = strconv.ParseUint(s, 10, 64)
var c float64
c, err = strconv.ParseFloat(s, 64)

**デフォルトの名無しさん** · 2022/08/29(月) 18:02:10.99

KotlinやSwiftは型推論できるやろ
それにパースとキャストは違うぞ

**デフォルトの名無しさん** · 2022/08/29(月) 18:41:59.28

全然書き込みが無いけど

ypeScript Swift Go Kotlin Rust Nimって、需要も人気も無いの？

**デフォルトの名無しさん** · 2022/08/29(月) 18:50:03.71

>>4
今どきのプログラミング言語はいずれも型推論が賢いね
昔は型推論が無いか弱くて
変数の型宣言が不要というだけで動的型付け言語のメリットされていた時代もあった

**デフォルトの名無しさん** · 2022/08/29(月) 19:09:28.15

次世代言語と言われる

TypeScript も Swift も Go も Kotlin も Rust も Nim ←これらの言語を全然知らない、

昭和の時代から IT関連業で働き、稼いでいた者には、居場所が無いから別の職種に転業すべきかなぁ

**デフォルトの名無しさん** · 2022/08/29(月) 19:33:16.23

>>7
TS、Go、Kotlinはいたるところで使われてるから、すでに現行言語では？

**デフォルトの名無しさん** · 2022/08/29(月) 19:46:28.38

AWSがプログラミング言語「Rust」を使っている理由
https://japan.zdnet.com/article/35183866/

Amazon Web Services（AWS）は、同社のエンジニアたちがプログラミング言語「Rust」を
使っている大きな理由として、エネルギー効率の高さを挙げる。
AWSは早くからRustを採用し、GoogleやMicrosoftとともにRust Foundationの創設にも携わった。
現在もRustの普及に熱心に取り組んでいる。

AWSのソフトウェアエンジニアで、Rustの普及に取り組む、
Shane Miller氏と主任エンジニアのCarl Lerche氏の投稿によれば、
Rustはメモリー安全性を高め、セキュリティ関連の不具合を減らす役に立つだけでなく、
PythonやJavaよりもはるかに「エネルギー効率に優れている」という。
Amazonは、2025年までにデータセンターの100％を再生エネルギーでまかなうという目標を掲げ、
データセンターの環境負荷の軽減に取り組んでいる。
Rustの採用はその一翼を担うという。

Rustで構築されたAWSサービスの例としては、
コンテナーアプリ用のサーバーレスプラットフォーム「Lamba」を支える「Firecracker」、
「Amazon Simple Storage Service（S3）」「Amazon Elastic Compute Cloud（EC2）」、
コンテンツ配信ネットワーク「Amazon CloudFront」、
LinuxベースのコンテナーOS「Bottlerocket」がある。

「CやRustが他の言語よりもエネルギー効率に優れていることに驚きはない。
衝撃的なのは、その違いの大きさだ。CとRustを広範に採用すれば、
控えめに見積もってもコンピュートに使用されるエネルギーの量を50％削減できる可能性がある」と
Miller氏は述べ、その根拠として、C、GoogleのGo、Lua、Python、Ruby、Fortranなどをはじめとする
複数の言語のエネルギー効率を相対的に示した研究結果を紹介している。

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

>>8

そういった系統の言語は、
業務で使用した事が無いから知りませんね。

**デフォルトの名無しさん** · 2022/08/29(月) 20:37:11.19

>>9

Lambdaといえば、Common Lisp だな。

LISP - Lambda Functions

**デフォルトの名無しさん** · 2022/08/30(火) 08:16:39.53

>>9
AWSていつのまに会社になったの？

**デフォルトの名無しさん** · 2022/08/30(火) 09:39:41.83

文末がセミコロンで終わらない言語は流行らない

**デフォルトの名無しさん** · 2022/08/30(火) 09:45:30.28

>>13
それなー

**デフォルトの名無しさん** · 2022/08/30(火) 09:52:15.23

Pythonはセミコロン非推奨だが。

**デフォルトの名無しさん** · 2022/08/30(火) 12:29:02.78

matzは構文に人間が寄り添うのではなく構文解析を言語が頑張るべき的なことを言ってたけど、現実は構文は厳格にしてformatterやlnterが曖昧さのないコードに導いてやるのが正解になってきたね。

人間なんてどこまでも適当な事をやらかせるんだから、それを実行時にうまく解釈してやるのは無理筋。

**デフォルトの名無しさん** · 2022/08/30(火) 12:39:56.18

>>16
構文の厳格さもformatterもlinterも関係ないじゃんw
頭悪過ぎる

**デフォルトの名無しさん** · 2022/08/31(水) 00:25:17.21

Pythonは当初の頓珍漢な理想を捨ててpython2を見捨てなかったのがえらいんだよ

**デフォルトの名無しさん** · 2022/08/31(水) 16:57:16.44

Rustを自分には向いてないと言った（恐らく本人は批判したつもりはない）一生懸命にmatzを叩くRust新興カルトが気持ちわる杉る....
CやC++でバリバリ書いてる人に所有権チェックなんて邪魔すぎるし、配列境界チェックだって速度が出ない足を引っ張る機能にしか見えないだろ
今は固定範囲の配列アクセスのチェックなんかは省略してるかもしれんが、恐らくそんな事はない（全てに係るから安全だと大口する）

**デフォルトの名無しさん** · 2022/08/31(水) 18:05:12.54

matzは静的型付け言語は
変数に型定義を書きまくるのが面倒くさい
というようなとこを言ってて
型推論とか知ってるくせにそれは
無いんじゃねと思ったな

**デフォルトの名無しさん** · 2022/08/31(水) 18:25:03.72

CやC++で困ってない人に無理にrustを勧めてくる人は相手しなくて良いよ

**デフォルトの名無しさん** · 2022/08/31(水) 18:30:28.99

matzのおかげでプログラミング文化が進化したのはのは間違いない
RustもRuby文化のいい面をかなり受け継いでいる

**デフォルトの名無しさん** · 2022/08/31(水) 18:32:18.02

>>19
所有権チェックって何？
そんな用語も概念も存在しない

配列境界チェックは
例えばインデックス値をforでループに回したとしても
最適化によりforでのチェックだけになり
インデックスを使った配列やスライスへのアクセス時に再びチェックすることはない
つまりC言語と同じになる

>>21
困ってる困っていないの問題ではない
回避策が確立されたのに欠陥言語を使い続けるか否かの問題
人間は必ずミスを起こしうる、との結論が出ていて
大手IT企業も挙ってRustを採用している

**デフォルトの名無しさん** · 2022/08/31(水) 18:35:01.88

>>23
Rustこそが銀の弾丸って主張かな？

**デフォルトの名無しさん** · 2022/08/31(水) 18:36:59.70

みんな所有権所有権言うけど、初学者がひっかかりがちなのって借用の方では
所有権というとRAIIの方を連想してしまうけど
C++でmove使いこなしてた人ならRustの所有権ではひっかからないだろうし、他の言語でもtry-with-resourcesとか類似の概念あるよね

**デフォルトの名無しさん** · 2022/08/31(水) 18:55:37.66

うちの会社にもPHPで困ってないからと言いながらゴミを作り続けるおっさんいるわ

**デフォルトの名無しさん** · 2022/08/31(水) 19:25:46.59

>>26
そういうおっさんが業務の阻害要因になってるならなんとかした方が良いけど
掲示板上でどういう問題抱えてるかすら分からない相手に闇雲に勧めるのとは全然違うよね

**デフォルトの名無しさん** · 2022/08/31(水) 19:48:33.02

>>26
PHPは>>9の記事の観点からはエネルギー効率の悪い劣った言語かもしれないが
C/C++が現実に大量のセキュリティの穴も含むメモリ管理バグを引き起こし続けている危険な欠陥言語である点とは大きな開きがある

**デフォルトの名無しさん** · 2022/08/31(水) 19:56:05.14

>>27
おっさん自身は問題を理解できてないってことを言ってるんだよ

**デフォルトの名無しさん** · 2022/08/31(水) 19:56:39.74

どんなに優れたプログラマーでもミスをするしバグも作るって考え方は大事だと思うけどな

**デフォルトの名無しさん** · 2022/08/31(水) 19:58:59.48

#define new old
で、全て解決では？

**デフォルトの名無しさん** · 2022/08/31(水) 20:04:50.79

でもウェブサイトの9割はPHPで出来てると言うからなあ。

**デフォルトの名無しさん** · 2022/08/31(水) 20:33:48.91

PHPを馬鹿にするやつにその資格はない
PHPの作者を馬鹿にするやつにその資格はない
PHPよりも作者よりも糞なやつが鏡すら見ずに薄ら笑ってる

**デフォルトの名無しさん** · 2022/08/31(水) 20:38:28.28

>>26
ゴミって言ってもそれでお金稼いでいる訳じゃなくて？

**デフォルトの名無しさん** · 2022/08/31(水) 20:55:36.71

>>24
んなこと言ってねーだろ。
ミスリードすんな。

**デフォルトの名無しさん** · 2022/08/31(水) 21:00:04.57

Haskellが見向きもされなくなったら、Rustの宣伝が増えたな。

**デフォルトの名無しさん** · 2022/08/31(水) 21:11:47.88

>>36
宣伝？
例えば>>9の記事はクラウドのシェアトップであるAWSがそのサービス提供にRustを使って構築しているという現実の話
着実に様々なインフラがRustベースへと置き換わっていく現実の一つ

**デフォルトの名無しさん** · 2022/08/31(水) 21:22:47.94

Rust(笑)　時代はJavaだから

求人倍率はなんと21.8倍　「Java」を求める企業が絶えない理由とは
https://atmarkit.itmedia.co.jp/ait/articles/2208/31/news049.html

**デフォルトの名無しさん** · 2022/08/31(水) 21:28:47.20

限られた情報から善と悪を判断できない人達が
まだ公開されていないクソどうでもいいデータを欲しがる

**デフォルトの名無しさん** · 2022/08/31(水) 22:11:23.35

オラクルに丸め込まれた会社本当にかわいそう

**デフォルトの名無しさん** · 2022/08/31(水) 22:21:51.07

今日Helidonなるものを初めて知ったわ
オラクル足掻いてるよねー

**デフォルトの名無しさん** · 2022/08/31(水) 23:06:38.28

rustは死産だったんだよ
このスレで頑張ってるのは水子供養みたいなもん

**デフォルトの名無しさん** · 2022/08/31(水) 23:15:56.00

Facebook、開発言語に「Rust」採用　Javaからも移行
https://www.itmedia.co.jp/news/articles/2107/28/news152.html

Rustを用いることで、どのような利点があるのか。
Facebookは記事の中で次の4つの項目を挙げています。

①Rustのasync/awaitシンタックスは、非同期のコードをとてもスムーズに記述できますし、
Rustは複雑な並行処理の詳細を正しく理解するのに役立ちます。
BuckのJavaの計算を一つ一つ並行処理に移行するのは数カ月に及ぶ困難な作業でしたし、
シングルスレッドの大きなボトルネックがまだ存在しています。

②Rustには、開発をより簡単で楽しいものにしてくれる多くの高レベルな言語機能があります。
それらはenum、パターンマッチング、trait、手続き型マクロなどで、
Rustの開発者の多くに愛されています。

③Rust はメモリの割り当てをより細かく制御することができます。
ガベージコレクションのある言語では、たとえジェネレーショナルコレクションであっても、
Buckが行うようなインクリメンタルな演算に対応するのは困難です。

④Rustは高性能です。
Rustに移植することで劇的な性能向上を私たちは見てきました。

**デフォルトの名無しさん** · 2022/08/31(水) 23:21:00.54

>>35
いやいやC++で書かれたプログラムは無条件にRustで置き換えられるって主張は銀の弾丸って言ってるのと同じでしょ

**デフォルトの名無しさん** · 2022/09/01(木) 00:44:24.52

善行を勧めることと、善行が必勝法であると主張することを区別する必要がある

**デフォルトの名無しさん** · 2022/09/01(木) 07:30:51.13

>>23
「最適化によりforでのチェックだけになり・・・つまりC言語と同じになる」
はい、明確すぎる嘘、Cは普通処理系によりけりだが通常は配列境界のチェックなんてしません。あほかｗなにが、つまりだｗ
必死すぎるのがほんと痛々しい

**デフォルトの名無しさん** · 2022/09/01(木) 07:32:21.78

所有権を邪魔だと思ってる奴のC++コードは読みたくねえな
一緒に仕事したくねえ……

**デフォルトの名無しさん** · 2022/09/01(木) 07:51:48.00

>>46
インデックス値でforループを回すとあるから
C言語でもループ1回に付き必ず1回のインデックス値の境界比較が必ず入るよ
境界チェック無しでforを回したら無限ループになる

**デフォルトの名無しさん** · 2022/09/01(木) 07:57:15.00

>>48
Cって、配列のインデックスアクセスに境界チェックとか無くて、プログラマに委ねられているのかと思ってた。Cも意外に安全性を気にしているんだね。

**デフォルトの名無しさん** · 2022/09/01(木) 08:33:34.02

>>38
javaのフレームワークって何使ってるの？

**デフォルトの名無しさん** · 2022/09/01(木) 09:37:58.04

>>44
その通り
条件を絞って
予めRustに移植することを意識して描かれたC++のソースのみ自動変換出来る
なら正しいかも知れない

**デフォルトの名無しさん** · 2022/09/01(木) 09:39:23.27

>>44 追加
ちなみに漏れは
「Rustに移植することを意識して描かれたC++のソース」
ならC++のままでええやん？的な立場

**デフォルトの名無しさん** · 2022/09/01(木) 09:41:17.41

>>48 はCを知らない素人以下

**デフォルトの名無しさん** · 2022/09/01(木) 09:48:59.81

>>49
たぶん間違って読解してる。
良くも悪くも日本語って主語省略しちゃうからね。

**デフォルトの名無しさん** · 2022/09/01(木) 09:50:52.96

>>53
え？
>>48で合ってるだろ
インデックスforループは境界比較しないと止まらん

**デフォルトの名無しさん** · 2022/09/01(木) 09:57:04.30

>>55
配列のインデックスチェックってここではモダンな言語は配列外にアクセスすると実行時エラーになるということを言ってるんだよ
Cはエラーじゃなく未定義だから何が起こるかわからん

**デフォルトの名無しさん** · 2022/09/01(木) 09:57:34.15

実行時じゃないわ
コンパイルエラーね

**デフォルトの名無しさん** · 2022/09/01(木) 09:59:00.80

いや動的配列ならやっぱ実行時か
どっちにしてもCみたいに変更しちゃいけないところを変更して暴走しないってこと

**デフォルトの名無しさん** · 2022/09/01(木) 10:09:23.03

>>56
元の話は>>23だからインデックス値のforループ
C言語でも他でもfor文で境界チェックが必ず入る

配列アクセス時はまた別の問題
Cならばチェックしないがfor文でチェック済なので安全上の問題なし
Rustならばチェックするがfor文でチェック済なので最適化によりここでのチェックは消えて問題なし

結果としてCでもRustでも同じ生成コードとなる

**デフォルトの名無しさん** · 2022/09/01(木) 10:23:52.21

>>59
動的配列のランダムアクセス時にC言語では入らない境界チェックが入るな

**デフォルトの名無しさん** · 2022/09/01(木) 10:30:39.30

>>59
日本語で説明するよりコードと生成されるアセンブリ見せた方がわかりやすいのでは

**デフォルトの名無しさん** · 2022/09/01(木) 10:31:44.69

forループの例では同じ生成コードとなるが
範囲内かどうか不明なインデックス値がやってきてそれで配列をアクセスする場合は違いが出る

C/C++
プログラマーの自己責任で境界チェックを手動でしなければならない
忘れたときは未定義動作となりうるため危険

Rust含むその他の言語
プログラマーは気にせずとも自動的に境界チェックされるため安全

**デフォルトの名無しさん** · 2022/09/01(木) 11:17:36.46

>>43
もうRustの覇権確定だなｗ

**デフォルトの名無しさん** · 2022/09/01(木) 12:16:04.06

その技術を作られたのがこれか
https://i.imgur.com/ymYXnQr.jpg

**デフォルトの名無しさん** · 2022/09/01(木) 12:46:30.05

>>62
？？
範囲forは？

**デフォルトの名無しさん** · 2022/09/01(木) 13:36:52.33

>>59
>Cならばチェックしないがfor文でチェック済なので安全上の問題なし

doubt
マジで言ってるなら去ね

**デフォルトの名無しさん** · 2022/09/01(木) 19:55:15.23

>>66
forでインデックスの境界チェック済みとあるから
配列のアクセス時に再び境界チェックしなくても安全でしょ

**デフォルトの名無しさん** · 2022/09/01(木) 20:39:52.39

いや、for文でのループ条件とか書き間違えてバグる筆頭だろ。
人力チェックの限界が見える典型。

**デフォルトの名無しさん** · 2022/09/01(木) 21:06:01.62

Rust方式が速さと安全の両立でベストだろう
基本的には配列(スライス)アクセス時にインデックス境界チェックが行われて必ず安全
その上でインデックスforなどでループ内のアクセスがコンパイラにより安全と保証できる場合は
最適化によりループ内の配列(スライス)アクセス時にインデックス境界チェックが無くなり速さと安全を両立

**デフォルトの名無しさん** · 2022/09/01(木) 21:29:24.74

>>38
単価の中央値は？

**デフォルトの名無しさん** · 2022/09/01(木) 22:04:15.15

もしもポインタが組み込み型ではなく外部のライブラリだったら
ライブラリを変更するだけでCはそこそこ安全になれた

C++はスマートポインタを追加することはできても
元からあるポインタ型を改善することは全然できなかった

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

>>69
slice::Iterは<[] as Index>::index使わないから最適化関係なく境界チェックは一度だけになるが

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

>>59
痛いRustおじさんの代表例だね、境界チェックが必ず入る処理系があったとしてそれを、C言語は！なんて表現しないぞ？
「結果としてCでもRustでも同じ生成コードとなる」絶対ならないからｗつーかアセンブラして貼り付けろよ？
それで常に100%が誰がやってもどのバージョンでもどの環境でも同じならあんたが正しい
そもそも配列ループの遅さをカバーするためにRustは速度を稼ぐために一部分ループ展開を勝手にするはずなので、gccとかなら
O2ではダメでO3でfunroll-loopsでコンパイルしないとならないよ

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

>>72
もちろんRustはイテレータが強力だから
インデックスで回すよりもイテレータ利用が断然に多く
スライス(配列)アクセスに境界チェックを毎回しないのはおっしゃる通りだが
様々な理由でイテレータではなくインデックスでforで回す場合もあり
その時ですらforの終端チェックのみで最適化によりスライス(配列)アクセス時の境界チェックは消えている
という話だから両立する話

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

>>73
配列ループで遅いなんて聞いたこともなく実際に遅くなっていない
何を根拠にそんなデタラメで叩いているのだろうか

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

他言語の範囲forとかイテレーターを無視して「Rustのforが一番」とかいうのは無知を通り越して無能。
「C++のforループは危険」というのはさすがに引っ込めたみたいだけど、cのforループと比較してRustを褒めるのは邪悪すぎるだろ。

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

>>76
みんなが話しているのは配列アクセスの安全と速さ
forはその時に出てくるだけであってfor自体の比較を誰もしていない
そこに優劣もない

**デフォルトの名無しさん** · 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レベル過ぎて逆に意味なくない?

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

>>174
Cのコードを書く必要はない
Rustには一部エリアのみプログラマーに安全性の保証の義務を負わせるunsafeブロックがありCと同じことができる
ベンチも#[bench]等ですぐ比較できるから速さにシビアな場合は本件に限らずアルゴリズムの差異も含めてコストをかけるだろう
その点はどんな言語でも同じ

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

>>178
＞Cのコードを書く必要はない
＞ベンチも#[bench]等ですぐ比較できる
いやいやCコードなしにhello sliceどうしでいくら比較しても意味ない。>>174は信頼性の話でしょ

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

>>174
最適化度合いに一貫性のある言語って何？
Cだろうがasm確認しないといけないのは同じだと思うが

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

>>109のコードを見てみたが書き方が酷いな
とりあえずそれと全く同じ関数仕様に合わせるとして
Rustならもっと簡潔にこのように書く

fn max_value_slice_vw(v: &[u32], w: &[u32]) -> u32 {
　std::iter::zip(v, w)
　　.map(|(m, n)| m + n)
　　.max()
　　.unwrap_or_default()
}

C言語バージョンより遥かに分かりやすいし
通常Rustでは返り値をu32でなくOption<u32>とするから最後のunwrap_or_default()も不要となる

これでC言語バージョンと全く同じ結果を得られるし
境界チェックも行われないし
そのC言語バージョンと全く同等のアセンブリコードが生成されることも確認できる
つまり今回の>>109の件もRustとCは同じ速さで動作する

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

>>180
現行C/C++だけがダントツトップレベル
Rustは裏でLLVM使ってるのに何で >>177 で信頼性がないと証明されたんだ...

>>181
あちゃちゃhello sliceと違う書き方をしないといけないなんて、これも無信頼性のPOCだ

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

「最適化度合い」ってあれだな
「クイックソートは最悪のケースの計算量が多過ぎる」みたいな
ヒープソート最強伝説に似ている

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

>>183
ほんとだね。アルゴリズム系は数学的に最悪ケースを予期回避できるのに、Rustの一貫性の無さは最悪
>>181で突然「このように書く」って言われてもPOCの積み増し

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

>>181
RustはわかりやすくシンプルにプログラミングできてCと同じ速度なのが素晴らしいね

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

>>185もはや自虐ネタ。嫌味ですか？

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

Rustをむやみに褒めてるやつがアホすぎてRustのネガティブキャンペーンにしか見えない件

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

こういう争いは同じレベルのやつ同士でしか起きない
お互いに相手がアホだと思ってるけど両方同レベルのアホ

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

for文を使わずにメソッドチェーンで書いたことが気に入らないのならば
>>181はfor文を使って以下のように書ける

fn max_value_slice_vw2(v: &[u32], w: &[u32]) -> u32 {
　let mut max = 0;
　for (m, n) in std::iter::zip(v, w) {
　　if max < n + m {
　　　max = n + m;
　　}
　}
　max
}

これもC言語バージョンと同じ動作をし
同等のアセンブリコードが生成されることも確認できる

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

せめてID変えずにやってくれればいいのにな
何回NGさせるんだか

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

>>189
確認乙
POC(>>177,182)積み増し乙

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

Cだと速いけどRustだと遅くなるケースって存在しないの？
誰かそういう例を作ってほしい
ここまでRustがCと同じ速さで書ける例ばかりだから

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

本人はバレてないと思ってるらしいw

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

>>192
はい。Rustは一貫性がない(>>177,>>182)ので個別にCコードと比べて
書き方を変えることにより同程度にもって行ける
ケースが稀にあることが証明されました
多大な努力の結果です。感謝

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

Rustはfor文自体がイテレータを使うから、
for i in 0..s.len() {
　　println!("{}", s[i]);
}
とインデックスを使う書き方をするのは非常に稀で、
これはインデックスを使わず、
for n in s {
　　println!("{}", n);
}
と書くのがRustでは普通だから、
インデックス議論自体があまり意味のないものに思える。
そしてどちらの書き方をしてもCコードと同速度。

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

Rustがそんなに速いならなんで競プロはC++一択なの

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

>>196
それは単なる人口差・マニュアルやサンプル数差
C++に次いで多いのが言語としてはかなり遅いPythonなのを見ても分かる通り

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

まあ、型を正確に宣言しても速くならないし遅くなるというのがもし本当なら
バニラJSが復権するのもPythonが支持されるのも当然といえば当然

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

>>196
解説本がc++が多いからかな

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

例えば競プロAtCoderでABC182-E問題 i行目j列目のマス(i,j)を扱う問題
提出された各プログラミング言語別の実行時間分布
https://pbs.twimg.com/media/EmYvG8aVkAMdfFG.jpg