Rust part17

**デフォルトの名無しさん** · 2022/10/06(木) 22:43:13.96

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

Web上の実行環境
https://play.rust-lang.org

日本語の情報
https://rust-jp.rs/

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※次スレは原則>>980が立てること

前スレ
Rust part16

**デフォルトの名無しさん** · 2022/11/16(水) 18:02:22.96

一部のアスペ以外はそれぐらいの推論はできるからあまり気にしなくていいよ

**デフォルトの名無しさん** · 2022/11/16(水) 18:02:43.41

そういうのは吊るを使う

**デフォルトの名無しさん** · 2022/11/16(水) 18:29:22.77

>>343
お前は誰だよw
俺を語ってんじゃねー

**デフォルトの名無しさん** · 2022/11/16(水) 20:20:41.18

.netでrustが使えれば無敵なのに

**デフォルトの名無しさん** · 2022/11/16(水) 21:13:44.67

GCのランタイム環境でRUSTは意味ないんじゃ？

**デフォルトの名無しさん** · 2022/11/16(水) 21:37:10.96

ML 系言語が Rust を高水準にした感じじゃない？
(というか ML の研究からリージョン推論が生まれて Rust に繋がっていったのだが……。)
.NET 用だと F# があるから使ってみても面白いかもね。

**デフォルトの名無しさん** · 2022/11/16(水) 21:59:45.42

.NETのライブラリが使いたいとかでは

**デフォルトの名無しさん** · 2022/11/17(木) 00:08:08.45

rust難しすぎません？
僕はまだまだ、たぶん無理だけど、そこそこできるようになったとしても、全体の底上げがなければ普及が難しいのではという自己弁護

**デフォルトの名無しさん** · 2022/11/17(木) 00:34:44.66

既存のC/C++のコードをRustに書き直すのは
頑張らなくても良いですと言われていても
世界に一人ぐらい頑張る人がいて
再実装しましたみたいなのが時々出てくるな

**デフォルトの名無しさん** · 2022/11/17(木) 00:48:28.80

C++ 何となく使っているけど、Rust って難しいの？
C++ より難しいなら、先に勉強しようかな

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

>>353 とりあえず動かすのはRustのが難しい
正しく動かすのはC++のが難しい

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

C++ は未定義を踏むのがさすがに簡単すぎるのがいけない。

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

>>340
これを徹底すればC++も問題ないよ

**デフォルトの名無しさん** · 2022/11/17(木) 03:15:48.27

>>354
Rustは安全性と処理効率を保ったままさらに高みに登ろうとすると、C++では
可能だったことが不可能なことがある。

**デフォルトの名無しさん** · 2022/11/17(木) 05:38:42.23

>>356
徹底するのが難しい、って話だろ

**デフォルトの名無しさん** · 2022/11/17(木) 05:39:00.42

>>356
「〇〇を徹底します」みたいな精神論が再発防止にならないのは業界の常識

**デフォルトの名無しさん** · 2022/11/17(木) 05:39:30.88

>>357
具体的にはどういうケース？

**デフォルトの名無しさん** · 2022/11/17(木) 07:38:31.41

>>360
大規模なマルチスレッドとかじゃない？
それこそ「共有メモリは排他制御を徹底すべし」ってだけの話だけど
数百万行のコードベース全体に対して常時気をつけ続けるというのは人間には無理だろう

**デフォルトの名無しさん** · 2022/11/17(木) 07:44:38.30

>>361 マルチスレッドこそRustの得意分野だと思うんだけど

**デフォルトの名無しさん** · 2022/11/17(木) 07:48:15.39

rustは所有権とかライフタイムとかなければ簡単で使いやすそうって印象

**デフォルトの名無しさん** · 2022/11/17(木) 07:53:43.04

所有権やライフタイムがいらないならrustである必要ないのでは

**デフォルトの名無しさん** · 2022/11/17(木) 08:37:34.35

>>362
あ、逆の話か
C++だと不可能なことがRustだと可能になるって読んでた
357のは思いつかんね

**デフォルトの名無しさん** · 2022/11/17(木) 08:42:54.13

複雑なマルチスレッドのアプリで俺にしか直せないバグを故意に仕込むことならC++でしかできないかな

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

>>364
プログラマが全知全能でメモリ関係のバグを踏まないって仮定したら所有権やライフタイムがなくてもrustはc++以上の優れた型システムを持ってる

**デフォルトの名無しさん** · 2022/11/17(木) 10:21:30.69

>>367
Haskellの方が優れてるよ

**デフォルトの名無しさん** · 2022/11/18(金) 17:50:50.73

米GitHubは11月18日までに、2022年にGitHub上で多く使用されたプログラミング言語ランキングを発表した。

その結果、1位は「JavaScript」だった。以降、2位「Python」、3位「Java」、4位「Typescript」、5位「C#」、
6位「C++」、7位「PHP」、8位「Shell」、9位「C」、10位「Ruby」と続いた。

Rubyに負けたらいけないだろｗ

**デフォルトの名無しさん** · 2022/11/18(金) 17:57:22.15

企業の人ってGitHub使えるのかな?
企業が使い始めたら増えると思うけど。

**デフォルトの名無しさん** · 2022/11/18(金) 18:25:40.22

真の意味でホビーユーザーに支持されなきゃだめだよ

**デフォルトの名無しさん** · 2022/11/18(金) 18:31:52.75

ゆきひろにより開発されたオブジェクト指向スクリプト言語か

**デフォルトの名無しさん** · 2022/11/18(金) 18:55:51.18

このグラフ、Typescriptの躍進とRubyの凋落が対照的で興味深かった。

**デフォルトの名無しさん** · 2022/11/18(金) 19:00:57.54

これか
https://i.imgur.com/QE0WMb7.jpg

**デフォルトの名無しさん** · 2022/11/18(金) 21:08:51.27

C/C++の減少分がRustじゃね

**デフォルトの名無しさん** · 2022/11/18(金) 21:48:16.28

その説が正しい使い方気がした

**デフォルトの名無しさん** · 2022/11/19(土) 00:42:59.64

>>360
効率よくリンクリストやグラフ構造を使うこと。
この(前?)スレで散々議論されていた。

**デフォルトの名無しさん** · 2022/11/19(土) 00:49:11.67

いい加減スレ違いはやめろって

**デフォルトの名無しさん** · 2022/11/19(土) 04:53:18.01

>>377
全然具体的でなくて草
そりゃ散々議論（のつもりw）になるわ
コードで示すとか出来ないの？

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

tscがRustだと書き直すのが難しいとか聞いたが

**デフォルトの名無しさん** · 2022/11/19(土) 10:48:30.65

>>380
tscをRustに一部移植
元のコードがGC前提だから全体の移植は大変なのでGoに変更
GoはGoで無駄な作業が多くて大変。やっぱりRustのほうが良かったのでRustに戻す

というのが今の状況
来年あたりまたGoに戻ってる可能性はあるが

**デフォルトの名無しさん** · 2022/11/19(土) 14:18:44.14

>>381
移植とか考えずに仕様だけ洗い出してからRustで実装するのがベストでしょうね
仕様解析チーム(tscを読み込んでドキュメント化する)
とRust実装チーム(Rustのエキスパートたち)
この2チームがいれば十分だし

**デフォルトの名無しさん** · 2022/11/19(土) 20:51:33.06

Rustで実装が難しいようなアルゴリズムは不安全で時代遅れだ説

**デフォルトの名無しさん** · 2022/11/19(土) 20:55:58.15

解析してる間にどんどんtscの仕様は変わっていくよ

**デフォルトの名無しさん** · 2022/11/19(土) 21:07:54.54

Rustってお互いに参照し合うようなグラフ構造を表現しにくいイメージある

**デフォルトの名無しさん** · 2022/11/19(土) 22:17:39.01

し難いのか不可能なのかどっちよ

**デフォルトの名無しさん** · 2022/11/19(土) 22:23:36.77

rustcでグラフ構造扱ってるよ
ポインタではなくインデックスでアクセする実装

**デフォルトの名無しさん** · 2022/11/19(土) 22:41:12.16

>>387
なるほどなあ

**デフォルトの名無しさん** · 2022/11/19(土) 23:28:51.73

>>387
前スレ読んでもわかるが、それでやれば出来るのは分かってるんだけど、
効率が落ちるから「ゼロコスト安全性」ではない。

**デフォルトの名無しさん** · 2022/11/19(土) 23:29:54.28

>>383
リンク構造を持つデータ構造は今も発展途上中で今後も開発されていくが、
Rustでは取り扱いにくく、むしろRustこそ時代遅れ。

**デフォルトの名無しさん** · 2022/11/19(土) 23:31:24.06

ポインタが理解できない人は、ポインタが中心に居るところのリンク構造を全て
無視するから、Rustの欠点が理解できないだけ。

**デフォルトの名無しさん** · 2022/11/19(土) 23:32:17.52

>>386
しにくいだけ
>>1のHow to not learn RustとかオライリーのProgramming Rustでも指摘されてたはず

**デフォルトの名無しさん** · 2022/11/19(土) 23:44:21.19

>>386
不可能ではないが、C言語のように参照やポインタでダイレクトに取り扱うのが
不可能なので、インデックスを介してアクセスした、非常に複雑な仕組みで
アクセスしたりする必要があり、効率が落ちる。
マシン語レベルで見ると、アクセスすすために必要なコードが増えるから。

**デフォルトの名無しさん** · 2022/11/19(土) 23:44:57.71

誤：インデックスを介してアクセスした、非常に複雑な仕組みで
正：インデックスを介してアクセスしたり、あるいは、非常に複雑な仕組みで

**デフォルトの名無しさん** · 2022/11/20(日) 00:54:20.94

窮屈だからとか言って車に乗るときにシートベルトを付けないタイプの人かな

**デフォルトの名無しさん** · 2022/11/20(日) 01:12:16.21

見かけ上はインデックスアクセスでも最適化がかかると途中のアドレス計算はほとんど消滅してポインタでやるのとそんなに差はなくなるよ。
ポインタを露骨に使うのはコンパイラ技術の未熟さをプログラマに補わせてただけ。
十分に高い能力のコンパイラにとってはプログラマが細々とした効率のための指示をするのはむしろ最適化の邪魔になる。

全体の構成やアルゴリズムの話ならともかく、細々とした部分はコンパイラのほうが人間よりよっぽど賢いんやぞ。

**デフォルトの名無しさん** · 2022/11/20(日) 01:28:00.24

ahoの「アルゴリズムの設計と解析」という古い本で木構造をインデックスアクセスで実装していたけど
rustにふさわしい実装だったんだな
この本はポインタがない言語を想定していたのだろうけど

**デフォルトの名無しさん** · 2022/11/20(日) 01:29:41.16

ポインタで書いた方が速いじゃんて事は現にあったし
昔だと、それでも遅いからってアセンブリ言語で関数書いて呼んだりしたが
今なら、そこまでやらなくてもいいだろう
これは、コンパイラの進化もあるだろうが、CPUの進化の恩恵が大きい

**デフォルトの名無しさん** · 2022/11/20(日) 01:32:00.55

脱ポインタの流れは変わらないと思うけどね
安全性とは程遠いからこれを無くさない限り絶対にメモリ安全性は守られない

**デフォルトの名無しさん** · 2022/11/20(日) 09:27:21.62

unsafeつかえばいいじゃん

**デフォルトの名無しさん** · 2022/11/20(日) 13:59:12.71

>>396
インデックスを使おうとすると、1つのオブジェクトを作成する際にヒープから確保できず、
同じ集約(コンテナ)に属する全オブジェクトが入っている配列をreallocするような
動作が必要となり、スプリアス的に「停止時間」が入る。
また、その際キャッシュが大規模クリアされてしまう。

**デフォルトの名無しさん** · 2022/11/20(日) 14:00:19.95

>>400
前スレ(?)で、それでは済まないことが指摘済み。

**デフォルトの名無しさん** · 2022/11/20(日) 14:05:25.97

>>399
自分が理解できないことは「ダメ」なこととしたり、排除しようとしてしまう。
典型例としては：
・数学が苦手な人 --> 数学不要論に走り、学校で教えることすら禁止させようとする。
・オブジェクト指向のメリットが理解できない人 -->オブジェクト不要論に走る。
・ポインタが苦手な人 --> ポインタを排除しようとする。
Rustはポインタを使うデータ構造を上手く使えなくなるようになっているので、
ポインタが理解できない人は、他の人も使えなくなって安堵の境地に浸れる。
オブジェクト指向で最も大事なclassの概念も使えなくなっているので、
オブジェクト指向が使えこなせなかった人は、他の人も使えなくなって、
競走上の劣等性を感じなくてすむ様になって得した気分になる。
しかし、現実は、そう甘くは無い。

**デフォルトの名無しさん** · 2022/11/20(日) 14:06:00.71

>>401
> 必要となり

ならない。

**デフォルトの名無しさん** · 2022/11/20(日) 14:09:39.17

>>404
インデックスは「連番」なので、その集約に属する全てのノードが、
1つの配列に入ってなければならない。
だから、ノードを追加した時に配列の容量が足りなくなると、
全ノードを入れるための配列の再確保が必要となる。
(全ノードが十分入る容量の配列を一気に確保して、move 動作が必要となる。
この際にキャッシュがほぼ全クリア状態になる。)

**デフォルトの名無しさん** · 2022/11/20(日) 14:14:51.22

>>401
[追加]
さらに、それに加えて、インデックスからオブジェクトにアクセスする際には、
オブジェクトのアドレス計算が必要となる。
それに、次のような掛け算が必要となる:
size = sizeof(OBJECT);
address = base + index * size;　// 掛け算。
掛け算は計算科学上遅い処理であり、避けるべき処理である事が知られている。

**デフォルトの名無しさん** · 2022/11/20(日) 14:16:00.87

Rustで複雑なことをさせなければいい

**デフォルトの名無しさん** · 2022/11/20(日) 14:19:02.05

>>406
> 遅い処理

遅くない。

**デフォルトの名無しさん** · 2022/11/20(日) 14:19:28.58

>>406
[補足]
ただし、index * size の値を、「offset 値」として予め計算しておいて、
index値ではなく、offset値をindex値の代わりにすると、この掛け算は
除去できる。
このoffset値は、「相対アドレス」や「相対ポインタ」に相当する。

**デフォルトの名無しさん** · 2022/11/20(日) 14:20:12.92

>>408
ポインタよりは遅い。
32BIT値の掛け算は、16クロックほど掛かる。

**デフォルトの名無しさん** · 2022/11/20(日) 14:20:23.64

>>405
Vec使えばそんな不効率なことはせんよ

**デフォルトの名無しさん** · 2022/11/20(日) 14:23:27.03

>>410
かからない。
原理的には掛け算が高コストなのはわかるが現代の CPU は
その差を埋めるために高度なアドレシングモードを用意した。

**デフォルトの名無しさん** · 2022/11/20(日) 14:26:55.83

>>411
不可能。

**デフォルトの名無しさん** · 2022/11/20(日) 14:27:54.72

>>412
>その差を埋めるために高度なアドレシングモードを用意した。
全く関係無い。
imul命令のlatencyはどんどん速くなって、いて、いまや 3 クロックほどに
なっているらしいが、アドレッシングモードは関係無い。

**デフォルトの名無しさん** · 2022/11/20(日) 14:31:49.56

>>414
imul は使われない。
関係ないものを持ち出しているのはそっち。

**デフォルトの名無しさん** · 2022/11/20(日) 14:34:23.52

この人大丈夫か？
なんか支離滅裂になってきてるが

**デフォルトの名無しさん** · 2022/11/20(日) 14:43:00.42

速度求めるならsizeは2のべき乗にするだろうしそれならバレルシフタで相当昔から1クロックで済むだろ
それほど大きくないサイズならアドレッシングモードでサポートしてるプロセッサーもあるし
ID:9/YCbfcZ はもう少しちゃんと勉強した方がいいと思うよ

**デフォルトの名無しさん** · 2022/11/20(日) 14:48:48.34

Rustで作ったdenoはなぜか遅いんだよな

https://dev.to/codesphere/bun-the-new-javascript-runtime-competing-with-deno-and-node-115d

**デフォルトの名無しさん** · 2022/11/20(日) 14:49:57.69

>>417
メモリの無駄になるので、一般にはObjectのサイズは2のべき乗には出来ない。

**デフォルトの名無しさん** · 2022/11/20(日) 14:53:40.99

>>418
元が根本的にダメだったら単に作り直すだけでも速くなったりするが、
大きなプロジェクトの成果物の性能が良いのは細々としたチューニングを続けてきたという蓄積の賜物。
すぐには越えられないのはごく普通のこと。

**デフォルトの名無しさん** · 2022/11/20(日) 15:06:31.98

>>415
配列
T a[N];
に対して、
a[index]
のアドレスを計算する時、
address = ((BYTE *)&a) + sizeof(T) * index;
の計算が行なわれ、マシン語レベルでは :
mov rax,(Tのサイズ)
imul rax,(index)
add rax,(aのアドレス)
と計算される。
Tのサイズが、1,2,4,8 の場合に限っては、
lea rax,[(aのアドレス) + (Tのサイズ) * index]
と書けるが、一般の場合には無理。

**デフォルトの名無しさん** · 2022/11/20(日) 15:15:31.54

>>418
bunが速いのは、denoやnodejsではJSで書かれている部分がbunではzigで書かれていることや
JSエンジンのJITの段数の違いによるもので
rust関係ないという理解なんだけど

**デフォルトの名無しさん** · 2022/11/20(日) 15:17:09.91

>>422
Bunはおいておいて、node(C++製JSエンジン?)とdeno(Rust製JSエンジン?)
では、denoの方がnodeより遅いと読み取れる。

**デフォルトの名無しさん** · 2022/11/20(日) 15:17:10.42

>>402
どのレス？もっかい書いてよ

**デフォルトの名無しさん** · 2022/11/20(日) 15:17:44.33

>>424
レスではなくスレ。
何度も書かない。

**デフォルトの名無しさん** · 2022/11/20(日) 15:24:09.33

>>423
Rust製JSエンジンとか書いてる時点でよくわかってないのが読み取れる

**デフォルトの名無しさん** · 2022/11/20(日) 15:26:15.43

>>425
スレのどのレスか教えてよ

**デフォルトの名無しさん** · 2022/11/20(日) 15:26:41.67

>>420
そっか、チューニング大事なんだな

**デフォルトの名無しさん** · 2022/11/20(日) 15:30:49.96

>>427
検索してくれ。

**デフォルトの名無しさん** · 2022/11/20(日) 15:34:04.94

>>426
nodeやdenoは余り知らないから。

**デフォルトの名無しさん** · 2022/11/20(日) 15:39:36.41

>>429
これのこと？
https://mevius.5ch.net/test/read.cgi/tech/1656285423/151

**デフォルトの名無しさん** · 2022/11/20(日) 15:43:51.99

>>431
まあ、そうだ。ただし、それは議論の一部。
ただ、反論する前に、頭がいいことが資格だぞ。
この板は頭の良さに対して全くフィルターが掛かってないから議論が混沌とする。
文字だけで理解するのではなく、イマジネーションと脳内のワーキングメモリー
を働かせて図形的に考えないとダメだぞ。

**デフォルトの名無しさん** · 2022/11/20(日) 15:45:48.15

>>431のレスはすべてをunsafeにすれば可能と暗に言ってるから、
>>402の言うunsafeを使っても済まない場合には該当しないか

**デフォルトの名無しさん** · 2022/11/20(日) 15:47:47.99

>>432
そうだね、文章だけではあなたの脳内の意図をちゃんと読み取れないから想像力が重要だね

**デフォルトの名無しさん** · 2022/11/20(日) 15:56:42.10

>>433
しかし、「すべてをunsafe」にするなら、Rustの意味が全く無いから、
「それでは済まない」。

**デフォルトの名無しさん** · 2022/11/20(日) 15:57:37.84

>>434
ちゃんと書くには長く書く必要があるが、理解できない人が多いから書けない。
そもそも、5chでは文章が途切れて書ききれない。

**デフォルトの名無しさん** · 2022/11/20(日) 16:13:12.85

>>428
チューニングの蓄積は大事だが、チューニングは実行環境 (など) の特性に合わせるということだから
前提となる特性が変われば今までの蓄積が今度は足を引っ張ることもある。
だからたまにはリセット (別プロジェクトとして始動) をするのも必要なことなんだよ。
少しづつ違う方針のものが併存しているのが健全な状態で、
真似したり反発したりしながら新陳代謝をしていくもんだ。

**デフォルトの名無しさん** · 2022/11/20(日) 19:14:36.78

グラフとかリンクトリストとかにはarena使えないの？
bumpaloとかtyped-arenaとかid_arenaとかgenerational-arenaとか色々出てるけど

**デフォルトの名無しさん** · 2022/11/20(日) 19:36:54.78

>>436
じゃあなんでこのスレに書いてるの？

**デフォルトの名無しさん** · 2022/11/20(日) 19:37:03.39

>>438
普通に使えるよ

**デフォルトの名無しさん** · 2022/11/20(日) 19:39:01.04

>>435
そもそもすべてをunsafeにする必要があるという前提が偽だよね
特定のデータ構造の操作がプラグラムのすべてなの？

**デフォルトの名無しさん** · 2022/11/20(日) 20:33:05.68

単純なLinkedListのdropでstackoverflow
https://matklad.github.io/2022/11/18/if-a-tree-falls-in-a-forest-does-it-overflow-the-stack.html

dropが再帰的に呼ばれそうなところでwarning出してくれたら嬉しいんだけどな
あ

**デフォルトの名無しさん** · 2022/11/21(月) 16:56:19.41

試しにいろいろやってみたけど
引数を含めて参照渡しなのか値渡しなのか完全に区別されてるのがいいね