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/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

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

**デフォルトの名無しさん** · 2022/11/21(月) 17:12:12.72

unsafeは甘え

**デフォルトの名無しさん** · 2022/11/21(月) 17:26:26.15

超エキスパートの皆さんが unsafe で
システムプログラミングしてくださるんだろうが

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

https://qiita.com/ohakutsu/items/5d29001f79d42d63e886
本筋と関係ない部分での強めの態度での批判(というかいちゃもん)、いかにも日本的な陰湿なマウント文化が凝縮されていて笑えない

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

テスト

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

お、書けたか

今日から勉強始めて Tour of Rust やってるんだけどなんか分かりづらいような...？
The Book からやったほうがいいのかな

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

Haskellからやった方がいいかも

**デフォルトの名無しさん** · 2022/11/21(月) 22:00:50.98

Haskell... モナド... うっ、頭が

**デフォルトの名無しさん** · 2022/11/21(月) 23:01:50.99

>>446
本当にこれ
ワイもその記事のコメント欄読んでいたけど
@Akira-T-Hatakeyamaが的外れの癖に高圧的に書いていて見ていて気分が悪くなったわ
サンプルコードもそんなおかしいものではないし事実Cではするメモリリークも防げている
まったく害のない記事を上げたがために揚げ足取りを取られていて不憫や

**デフォルトの名無しさん** · 2022/11/21(月) 23:15:45.42

> Cをきちんと理解していない人が RUST が安全ですと言っても、説得力皆無ですね。

ここに完全同意できてしまうから
この話はもうそこで終わってしまう

批判された側は改善するか記事消すかして
態度で反省を示してほしいわ
ゴミ記事量産すなって話

**デフォルトの名無しさん** · 2022/11/21(月) 23:45:49.72

callocの代わりにalloca使えとか揚げ足取りがすぎる
普通のOSならメモリリーク起きないというのも意味不明

**デフォルトの名無しさん** · 2022/11/21(月) 23:50:01.01

とはいえ元記事も微妙でメモリ安全の話をするならuse-after-free等の話をして欲しかった

**デフォルトの名無しさん** · 2022/11/22(火) 06:46:59.40

ありがちな不具合を示すサンプルにこうすりゃいいとか言われてもねぇ...
そもそもstr_new()でalloca()使ったらstr_new()から抜けた時に解放されちゃうからもっと酷いことになるのわかってないだろw

**デフォルトの名無しさん** · 2022/11/22(火) 09:08:14.28

>>451
コメントしてるやつほどではないにしても
記事もそれなりに害のある記事やろ

**デフォルトの名無しさん** · 2022/11/22(火) 10:53:06.52

コンパイル時評価の欠点
https://c3.handmade.network/blog/p/8590-the_downsides_of_compile_time_evaluation

Rustが攻撃されてる！許せねぇ！

**デフォルトの名無しさん** · 2022/11/22(火) 11:53:04.77

const fnと思ったらmacroの話か
書かれてることはもっともだと思うしrust-analyzerの作者も似たようなことを言っていたような

**デフォルトの名無しさん** · 2022/11/22(火) 12:05:47.11

コンパイル時評価の欠点と言うかマクロは混乱しやすいって話だろ
まあ良薬も使いすぎると毒になるしほどほどに使うのは難しいし、処理系のサポートが難しくてエラーメッセージがイミフになるとかあるから半分ぐらいは同意する

**デフォルトの名無しさん** · 2022/11/22(火) 13:20:21.25

>>457
この文脈でdownsidesを欠点と訳すのは微妙
「コンパイル時評価のマイナス面」みたいにプラス面の存在が当然の前提となる日本語にしないと与える意味が変わる

**デフォルトの名無しさん** · 2022/11/22(火) 16:03:09.05

0..10 で生成されるオブジェクトってイテレータですか？

**デフォルトの名無しさん** · 2022/11/22(火) 16:12:53.87

>>461
はい

0..10はRange<i32>
impl<A> Iterator for Range<A> where A: Step
impl Step for i32

**デフォルトの名無しさん** · 2022/11/22(火) 17:02:18.19

>>462
ありがとうございました

**デフォルトの名無しさん** · 2022/11/23(水) 08:39:00.67

>>463
どういたしまして

**デフォルトの名無しさん** · 2022/11/23(水) 22:54:55.70

The Bookの日本語版がRust 1.58で英語版がRust 1.62っぽいんですけど、この差が問題になることありますか？

**デフォルトの名無しさん** · 2022/11/23(水) 23:36:05.63

>>465 ほぼない
強いて言えば新しい書き方が載ってないぐらい
古い書き方でも問題なく動く

**デフォルトの名無しさん** · 2022/11/24(木) 01:19:12.75

>>465
バージョンの差は問題にならないが日本語版と原文の差は大きい

英語が苦手で原文だと読むのに3倍時間かかるような人でも原文読む方がRustを理解するには圧倒的な近道

**デフォルトの名無しさん** · 2022/11/24(木) 02:03:20.81

英語が駄目って人は百倍かけても読めない。

**デフォルトの名無しさん** · 2022/11/24(木) 02:06:19.42

The Book自体がそんな一生懸命読むべきもんじゃない
別のそのへんの本屋で売ってるRust本でもいい

**デフォルトの名無しさん** · 2022/11/24(木) 02:06:45.58

機械翻訳も良くなったとは言え普通に間違えるし英語読めない人なら日本語版の方がいいでしょ

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

あの日本語版はないわな
Rust習得の弊害でしかない

**465** · 2022/11/24(木) 09:13:21.63

様々な意見、ありがとうございます！
両方を見比べて大きな差がありそうなところは英語版を翻訳して読んでみようと思います

**デフォルトの名無しさん** · 2022/11/24(木) 09:14:00.12

日本語版の一番の欠点は、基礎や概念を説明している項目が所々抜けてることだろうな
なんもわからないまま結論を覚えるだけになってしまう

**デフォルトの名無しさん** · 2022/11/24(木) 10:04:24.95

Rustって難しくね？
できればライフタイムあたり意識しないでプログラミングしたいんだけど

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

そういう難しいところに直に向かい合うための言語なので...

**デフォルトの名無しさん** · 2022/11/24(木) 12:37:17.60

Typeshareが1.0になったけどどない？
https://github.com/1Password/typeshare