次世代言語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(月) 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も同等のアセンブリコードを吐いてるから実行速度も同じで勝負ついた感じだな