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/10/06(木) 22:43:37.18

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

Rust CLI (Command Line Interface) apps Book
https://rust-cli.github.io/book/
Rust macro Book
https://danielkeep.github.io/tlborm/book/
Rust Future Book
https://cfsamson.github.io/books-futures-explained/
Rust async-std Book
https://book.async.rs/
Rust tokio Book
https://tokio.rs/tokio/tutorial
Rust rustc Book
https://doc.rust-lang.org/rustc/
Rust rustdoc Book
https://doc.rust-lang.org/rustdoc/
Rust rustup Book
https://rust-lang.github.io/rustup/
Rust Cargo Book
https://doc.rust-lang.org/cargo/
Rust unstable Book
https://doc.rust-lang.org/nightly/unstable-book/
Rust Reference
https://doc.rust-lang.org/reference/
Rust Standard Library
https://doc.rust-lang.org/std/

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

☆WebAssembly（WASM） https://webassembly.org/ https://ja.m.wikipedia.org/wiki/WebAssembly
・Wasmer - The Universal WebAssembly Runtime https://wasmer.io/
-> WASI（WebAssembly System Interface）とEmscriptenに準拠したWASMを実行できるランタイム
・WAPM - WebAssembly Package Manager https://wapm.io/
-> WebAssembly製ツール/ライブラリのパッケージマネージャー
☆Rust
・wasm-pack - your favorite rust -> wasm workflow tool!
https://github.com/rustwasm/wasm-pack
-> WebAssemblyのrustcコンパイルサポート
・Yew - Rust / Wasm framework for building client web apps https://yew.rs/ja/
-> WebAssembly によってマルチスレッドな Web アプリのフロントエンドを作ることができる、モダンな Rust のフレームワーク
☆最近のWebAssemblyのニュース
・Publickey － Enterprise IT × Cloud Computing × Web Technology / Blog より https://www.publickey1.jp/programming-lang/webassembly/
・WebAssembly活用プロジェクト https://madewithwebassembly.com/
・WebAssemblyが気になるので調べてみた - Qiita https://qiita.com/t_katsumura/items/ff379aaaba6931aad1c4
・WASMとRustはVue.js/React.jsを打倒するのか？ - JSへの侵略の歴史 https://zenn.dev/koduki/articles/c07db4179bb7b86086a1
・Typescriptの次はRustかもしれない https://zenn.dev/akfm/articles/81713d4c1275ac64a75c
・WebAssemblyはJVMやeBPFのリバイバルではない　WasmがWeb以外でもアツい理由 - ログミーTech https://logmi.jp/tech/articles/324956
・Rust GUI の決定版！ Tauri を使ってクロスプラットフォームなデスクトップアプリを作ろう https://zenn.dev/kumassy/books/6e518fe09a86b2
類似スレ
【wasm】ブラウザでC++。Emscriptenを語ろう https://mevius.5ch.net/test/read.cgi/tech/1547549448/

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

>>1
前スレのurlはれてなったよぉ…
Rust part16
http://mevius.5ch.net/test/read.cgi/tech/1656285423/

**デフォルトの名無しさん** · 2022/10/07(金) 01:27:41.85

>>1
おつ

**デフォルトの名無しさん** · 2022/10/07(金) 11:28:42.39

>>1
O2

Nim に浮気中

**デフォルトの名無しさん** · 2022/10/07(金) 12:26:19.13

Null安全でないGC言語のNimに浮気する人

**デフォルトの名無しさん** · 2022/10/07(金) 12:31:49.01

Null安全性が入れば雑なスクリプト用としては使えるんだけどな

**デフォルトの名無しさん** · 2022/10/07(金) 13:04:35.78

雑なスクリプト用途ならもっとシェアあって長続きしそうな競合が色々あるからなあ

**デフォルトの名無しさん** · 2022/10/07(金) 13:36:57.50

Rustも意外に雑に手軽に書けるケースが多いと分かってきた
数値以外は先にスタック上に変数を用意（＝メモリ確保）してしまえば
後はその参照を使ってアクセスするだけで所有権もライフタイムも気にせず気楽にコーディングできるんだな

**デフォルトの名無しさん** · 2022/10/07(金) 15:04:20.94

lifetimeや所有権よりshared xor mutableの方が煩わしいと感じる人は多そうに思う

**デフォルトの名無しさん** · 2022/10/07(金) 15:24:21.69

僕はヌルヌルおまんこは好きですね

**デフォルトの名無しさん** · 2022/10/07(金) 15:25:06.27

>>12
Cだと可変ポインタだらけだからその感覚では書けないからねぇ
考え方から矯正しなきゃならんし面倒ではある

**デフォルトの名無しさん** · 2022/10/07(金) 15:53:22.67

スレッド内ならばCellが使えるから可変性も自由自在だよ

**デフォルトの名無しさん** · 2022/10/07(金) 15:57:51.33

Cellを使ったら負け

**デフォルトの名無しさん** · 2022/10/07(金) 16:08:39.72

Cellは安全性・高速性・利便性を両立するRustの最重要パーツの一つ

**デフォルトの名無しさん** · 2022/10/07(金) 16:27:35.67

だんだんトンデモスレになってきてるね

**デフォルトの名無しさん** · 2022/10/07(金) 16:33:32.37

Rust2っていつぐらいになりますか？今のままだと使いづらいです。。。

**デフォルトの名無しさん** · 2022/10/07(金) 16:36:51.77

Cellを使わずにshared xor mutableに囚われて不自由なプログラミングしている初心者は意外と多いね

**デフォルトの名無しさん** · 2022/10/07(金) 16:38:47.86

>>18
真に受けて複オジ2世が生まれないことを願ってる

**デフォルトの名無しさん** · 2022/10/07(金) 16:49:17.62

Cellの利便性を知らない初心者がいるのは直感に反するからだろう
Cellは可変参照なくても非可変参照だけで書き換えられるからな

**デフォルトの名無しさん** · 2022/10/07(金) 16:51:07.23

Cellを使うデメリットはないの？
ないならデフォルトがCell相当になっててもよさそう

**デフォルトの名無しさん** · 2022/10/07(金) 16:56:27.41

>>23
Cellのデメリットは唯一!Syncだけ
つまりスレッド内部でしか使えない

**デフォルトの名無しさん** · 2022/10/07(金) 17:20:16.20

誤解のないように言えば
スレッドを使わずにシングルスレッドの状況でももちろんCellを使える

**デフォルトの名無しさん** · 2022/10/07(金) 17:44:54.27

組み込みとかだとヒープの利用が難しいので自然とスタックメインになる

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/07(金) 17:45:11.12

>>23
コンパイル時の検査を緩めるかわりに実行時に検査が入る。
借用規則に逆らえるわけではない。

**デフォルトの名無しさん** · 2022/10/07(金) 17:53:21.56

>>27
それはRefCellでは

**デフォルトの名無しさん** · 2022/10/07(金) 17:55:50.86

>>27
Cellは実行時検査も無くコストゼロです
スレッド内なので借用規則に逆らえます

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/07(金) 18:21:14.63

そっかー。

**デフォルトの名無しさん** · 2022/10/07(金) 19:26:54.49

CellはCopy traitが必要なので場合によってはとんでなくパフォーマンスが劣化する場合がある

単なる数値なら問題はないが

**デフォルトの名無しさん** · 2022/10/07(金) 19:45:02.34

>>31
そんなことはない
Cell<T>のTは完全に自由でありCopy要件はない
Cellで数値だけでなくVecやString等も自由に使える
例外的に一部のメソッドはCopy要件を持つがそれはOption<T>等でも同じでありそのメソッド特定のみの話

**デフォルトの名無しさん** · 2022/10/07(金) 19:48:12.01

>>31
Cell::takeやCell::replaceなど追加されたのでCopyを実装してない型でも使えるよ
StringやVecなどCopyできない型を扱う場合でも
元の値をtakeして更新後replaceするなどうまく書けばそれほど非効率にもならない

**デフォルトの名無しさん** · 2022/10/07(金) 19:52:07.74

CellやRefCellはshared xor mutableを知った上で適切に使った方が良いと思うので
初学者へ勧めるべきかというと微妙な気はするなあ

**デフォルトの名無しさん** · 2022/10/07(金) 19:58:58.94

>>34
Cellは安全性が完全に保証される型
他の型と同様に万が一に間違った使い方をしたらコンパイルエラーとなり常に安全が保証される
初心者かどうかといった区別や考慮はそこに必要ない

**デフォルトの名無しさん** · 2022/10/07(金) 20:08:27.14

何がしたいの？

**デフォルトの名無しさん** · 2022/10/07(金) 20:16:39.71

>>33
takeってデフォルト値に置き換えて所有権をもらうやつでしょ？
うーん、なんか気持ち悪さはあるんだよな

**デフォルトの名無しさん** · 2022/10/07(金) 20:49:01.57

>>33
Cellの更新はset()で十分だね
もちろんreplace()してoldを捨てるのと同じ

>>37
take()はdefault値とのreplace()と同じ
これは気持ち悪いことでも何でもなくて
例えばmutableなOption<T>を維持しながら扱う時と同じ操作
その場合もSome(T)からTを取り出す時にdefault値と入れ替えるtake()を使うよね
何かが入っていないと未定義になるからその身代わり
もちろんすぐに更新する場合は概念上だけの扱いとみなせるし
実際の生成コードでもdefault値が入るコードは最適化で消えちゃう
未定義状態を避けるための自然な操作と捉えてよいかと

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

>>38
うーむ確かにそう言われるとむしろRust Wayな気がしてきた

**デフォルトの名無しさん** · 2022/10/07(金) 21:12:11.57

不必要にCellを使ってみたくなるのはRust厨二病によくみられる症状
悪影響は少ないから温かく見守っておけばそのうち治るよ

**デフォルトの名無しさん** · 2022/10/07(金) 21:18:22.03

まとめると実行時に値を書き換えたいオブジェクトにはCellを使う
書き込む場合はset
読み込む場合はtakeを使う

RefCellはオワコン

**デフォルトの名無しさん** · 2022/10/07(金) 21:30:00.49

>>40
内部可変性を知らないのかな？
Cellは内部可変性を与えるものであり
& mutに縛られずにコーディングの自由度を上げるだけでなく
この内部可変性を使わないと記述できない場合もあるほど重要なもの

**デフォルトの名無しさん** · 2022/10/07(金) 22:49:11.13

> inherited mutability is preferred, and interior mutability is something of a last resort.
内部可変性は必要な時だけつかうべき
https://doc.rust-lang.org/std/cell/

**デフォルトの名無しさん** · 2022/10/07(金) 23:05:27.46

スレッド間での共有ができないからその場合は内部可変性を避けないとコンパイルエラーとなっちゃう
しかし共有しないものならばいつでも安全に使うことが出来ます
不自由なプログラミングをしてまで内部可変性の利用を避ける必要はありません
そのような場合にはむしろ使うべき時ですよ

**デフォルトの名無しさん** · 2022/10/07(金) 23:15:28.30

The Bookの内容も理解してないようだから厨二病というより厨一病だねぇ

**デフォルトの名無しさん** · 2022/10/07(金) 23:27:40.94

>>45
The Bookでは
CellはSyncを実装していないからマルチスレッド間では使えないことしか書かれていない

**デフォルトの名無しさん** · 2022/10/07(金) 23:41:21.31

>>46
!Syncが許容される場面では常にCellを使うべきだと考えていますか？

**デフォルトの名無しさん** · 2022/10/07(金) 23:44:26.62

>>47
常に？
そんな極端な主張を一度もしていない
他のものと同じで有用な時に使えばよい
そして有用な時が多い
それだけだ

**デフォルトの名無しさん** · 2022/10/07(金) 23:59:28.46

Cellは安全なだけでなく
実行コストもかからないし
データ設計の幅も広がるし
メリットだらけだよね

**デフォルトの名無しさん** · 2022/10/08(土) 00:00:53.53

後で読むからブログにでもまとめといて

**デフォルトの名無しさん** · 2022/10/08(土) 00:05:55.63

Cellを嫌ってる人って何かの病気なの？
数ある型の一つに過ぎないのに

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

Rustレスバトル会場
https://mevius.5ch.net/test/read.cgi/tech/1657382429/

**デフォルトの名無しさん** · 2022/10/08(土) 00:21:36.43

Cell使わずにshared xor mutableの制限で苦しんでいる人は単なるバカ

**デフォルトの名無しさん** · 2022/10/08(土) 00:35:12.49

CellとかRefCellってRustの本にも殆ど解説がないよな
ちょろっとおまけ程度にしかない
これなしでは現実的なプログラム書けないと思うのだが本の著者らはRustを理解してないんだろうか

**デフォルトの名無しさん** · 2022/10/08(土) 00:52:04.60

>>54
書籍は見たことないから知らなかったけどそうなのか
自分が使っている著名なcratesのソースを見てみるとCellを使っているcrateも多い
だから普通に皆がCellを使っていてそこにタブーは無いようだ
まあ当たり前か

**デフォルトの名無しさん** · 2022/10/08(土) 00:58:18.16

Cellなしでは現実的なプログラム書けないというのは言い過ぎ
ある種のプログラムではCellが必要になるくらいが適当では

**デフォルトの名無しさん** · 2022/10/08(土) 01:04:15.77

Cellが必須となるプログラムと
Cellが必須でないプログラムがあるだけだよな
まあこれも当たり前かｗ

**デフォルトの名無しさん** · 2022/10/08(土) 01:12:26.49

Rustで日本が変わる！世界が変わる！
などとほざいてる人は自分では使っていないと思う。
使ってたら、ウーン、こりゃ使えんなあ・・・って言ってると思う。

**デフォルトの名無しさん** · 2022/10/08(土) 01:34:11.88

Rustは今までに登場したプログラミング言語の中では一番使いやすく効率がいい程度だな
世界や日本がどうなろうとどうでもいいが
理解できない人たちとの不利有利の二極化は起こるだろう

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

>>55
The bookにはRefCellの解説はあるけどCellの解説がないんだよね
だからCellを使ってる人が少ないのかと思う

**デフォルトの名無しさん** · 2022/10/08(土) 05:12:58.83

各crateのソース調べたらtokioもasync-stdもwasm-bindgenもCell使ってるな
別方面でtauriもyewもeguiもCell使ってるな
他にもproc macro用のsynとかCLI用のclapとか様々なcrateがCell使ってるな
この状況を見るとCellは普通に使って当然っぽい

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

>>38
それってCellから取り出した値がdefaultだった時の処理を書かないとならないんじゃないんですか？

**デフォルトの名無しさん** · 2022/10/08(土) 10:55:13.71

>>54
Cellは扱いの小さい本が多いがRefCellはだいたいどの本でもしっかり解説されてるでしょ

オライリー本はCellも解説してる

**デフォルトの名無しさん** · 2022/10/08(土) 10:59:24.30

Cellはスレッドローカルの共有状態を管理する時に使う
カウンタとかフラグとか

shared mutability自体多用するもんじゃないからその辺をよく考えてね

**デフォルトの名無しさん** · 2022/10/08(土) 10:59:37.80

>>54
Cの入門本の8割はmallocの使い方を説明してない

**デフォルトの名無しさん** · 2022/10/08(土) 13:18:33.57

どうせなら不変な部分を取り出せるようにしてすればよかったのにな。
参照カウントみたいなどこでも付いて回るのは厄介だけど。

**デフォルトの名無しさん** · 2022/10/08(土) 13:48:31.81

>>63
ここの議論を見るとCellの解説を最初にやるべきだと思うのになぜRefCellばかりなのだろうという謎が
歴史的経緯みたいなやつか？
日本人の書いた本もRefCellばっかだよ

**デフォルトの名無しさん** · 2022/10/08(土) 14:04:15.39

カジュアルにCellを使って欲しくないからだよ
よく考えて使わないとバグのもとだから
必要な人向けにはリファレンスで詳しく解説してる

**デフォルトの名無しさん** · 2022/10/08(土) 18:26:38.20

>>62
マルチスレッド間共有していないから
空っぽの時に知らぬ間にアクセスされることはないよ
だから大丈夫
そしてすぐに更新することで最適化される
あとはプログラムの組み立て方の話であって言語による管轄の話ではないね

**デフォルトの名無しさん** · 2022/10/08(土) 19:07:57.58

interior mutabilityを持ち所有権を自分が持たないケースは特殊だから説明した方がいいかもしれないが、
interior mutabilityを持ち所有権を自分が持つケースは普通の事だからわざわざ説明するまでもない。

write lockを取るからborrow checkが実行時に遅延されるのも説明しないといけないし。

**デフォルトの名無しさん** · 2022/10/08(土) 19:14:27.64

Cellの使い方教えればRustユーザーも増えると思うな
所有権そのものより副作用を簡単には許さないところにハードルがあるから

**デフォルトの名無しさん** · 2022/10/08(土) 19:30:29.77

>>70
実行時borrow checkされるのはRefCellだけ
Cellはborrow checkもlockも無くてゼロコスト

**デフォルトの名無しさん** · 2022/10/08(土) 20:24:05.46

カジュアルに使うならマルチスレッドでも使えるMutex使っておけばよいのではという気もするが

**デフォルトの名無しさん** · 2022/10/08(土) 21:19:30.79

CellはCにおけるグローバル変数と同じで真に必要な時以外は極力避けるべきもの
ましてやRustの基本的考え方に慣れてないうちから使うべきものじゃない

**デフォルトの名無しさん** · 2022/10/08(土) 22:01:30.85

>>73
そこは真逆
Mutexはlockのコストがかかる
Cellはコストがかからない

>>74
Cellはグローバル変数ではなくローカルにいくつも出現可能
そしてグローバル変数のような極力避けるべきものではない

**デフォルトの名無しさん** · 2022/10/08(土) 22:04:07.45

>>75
ロックのオーバーヘッドを気にする必要があるのはカジュアルに含まれません

**デフォルトの名無しさん** · 2022/10/08(土) 22:06:04.90

immutableなのがいいと言いつつ
mutやinterior mutabilityを結局使わせるダサさなｗ

**デフォルトの名無しさん** · 2022/10/08(土) 22:39:37.88

>>76
Cell<T>ならスレッド内部専用の代わりにロックがなくてTと同じコストで使えるからオススメ

**デフォルトの名無しさん** · 2022/10/08(土) 22:40:45.08

immutableだけで書きたければそうすれば良いのでは
そのアプローチに窮屈さを感じる人が大半だからshared xor mutableという安全に使えるサブセットが生み出されたわけで

**デフォルトの名無しさん** · 2022/10/08(土) 22:42:33.20

>>78
ただしマルチスレッド対応させようとすると書き換えが必要だし性能面に大きなこだわりがないなら最初からMutexにした方が良いのでは
Cell<T>はランタイムコスト面ではTと同じかもしれないけどコード記述は結局

**デフォルトの名無しさん** · 2022/10/08(土) 22:43:05.48

途中で書き込んでしまった

コードの記述の面ではTとは異なるから同じ使い心地にはならないよね

**デフォルトの名無しさん** · 2022/10/08(土) 22:53:58.00

>>80
それは君が勘違いをしている
Cellはマルチスレッドであってもスレッド内で使用することができる
Mutexを使うべき時はマルチスレッドのスレッド間で共有メモリとする時
排他制御のためMutexはコストが重い
したがって両者を互いに代用することは有り得ない

**デフォルトの名無しさん** · 2022/10/09(日) 00:09:47.59

よくわかんないんだけどMutex<Cell<T>>は有効なの？

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

>>83
無効ではない
しかしMutex<T>はlockを取れたら& mut Tも得られて書き込みも可能なのでCellは不要
例えば

fn main() {
　let m = Mutex::new(Vec::new());
　sub(&m);
　let v = m.lock().unwrap();
　assert_eq!(*v, [123, 456]);
}

fn sub(m: &Mutex<Vec<i32>>) {
　let mut v = m.lock().unwrap();
　v.push(123);
　v.push(456);
}

つまりMutexの可変参照をもっていなくても内部の可変性を得られる
ようするにCellで内部可変性を得られるのと同じ
だからMutex<Cell<T>>と二段に重ねる必要はない

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

>>84
なるほどー
めちゃくちゃ勉強になる

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

>>82
ランタイムコストが無視できる場合はMutexが使えるけどCellが使えないシチュエーションはないよね
カジュアル用途なら大は小を兼ねる的な意味でCellよりMutexの方が良いのでは？
Cellにすべき理由あるの？

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

>>86
一文目逆だった。MutexがCellを置き換えられない場合はないよね、と言いたかった

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

>>86
話は非常にシンプル
スレッド間でメモリを共有するならばMutex　(ただし排他コストがかかる)
共有しないならばCell　(コストはかからない)
適切な方を選べばよい

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

というかRustマジで良くできてんな
考え尽くされてるわ

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

要するに変数は全部Cellで囲っておけばいいんでしょ

**デフォルトの名無しさん** · 2022/10/09(日) 02:08:28.77

>>88
スレッド間で共有しなくてもstatic変数だったらCell使えないのでMutexは単純にマルチスレッド用とも言えないのでは
よくわからない人向けにはMutexをまずは勧めるのが良いのでは

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

Qt使おうかと考えているけど
バインディングライブラリのritualを勧めている人がいたけど
最後のコミットが去年でサポーターが心配なんだけど
結局Cのライブラリ読み込みや既存ライブラリの利用とかどれを使えばいいの？

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

>>91
それは基本的な理解ができていない
static変数はスレッド間で共有が可能なためその型はSync実装を必要とする
だからCellが使えないのは当たり前

スレッド間で共有する必要がないならば
スレッドローカルに持てばSync実装を必要としないためCellを使える
例えば
thread_local! {
　static FOO: Cell<Vec<i32>> = Cell::new(Vec::new());
}
これでスレッド毎に持つことができる
もちろんスレッドを使わないシングルスレッドな状況でも使える

**デフォルトの名無しさん** · 2022/10/09(日) 04:37:34.70

Cellって基本的に値がムーブされるから構造体分はmemcpyが起きると思うんだけどそこはどうなの
RefCellやMutexなら直接参照取れるからそっちの方が効率的だよね

**デフォルトの名無しさん** · 2022/10/09(日) 04:57:14.58

複オジの嘘に騙される前には少しは頭使え

**デフォルトの名無しさん** · 2022/10/09(日) 05:51:16.25

隔離スレに帰れ

**デフォルトの名無しさん** · 2022/10/09(日) 05:51:33.43

>>94
memcpyは起きない
Cellに関係なく一般的にムーブはあくまでもRustの言語レベルにおける概念的なもの
したがって生成コードでは無駄なメモリ間のムーブ(コピー)は起きずに最適化される

Cellの場合でも同様に最適化される
&Cell<T>に対してtake()してTを更新してset()するコードは
& mut Tに対してTを更新するコードと同じ生成コードとなる

例えばそれらの比較コード
https://godbolt.org/z/1TY9v33YP
完全に同じ生成コードとなっていることが分かる
つまりCell<T>はTと比較して実行時ゼロコストである

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

RustコンパイラとLLVMは凄いなあ
いつでもそうだけど生成コードではがっちり最適化してくれる
抽象的に書いても安全に書いてもCと同じ速さ

**デフォルトの名無しさん** · 2022/10/09(日) 11:45:38.50

おまえも隔離スレに帰れ！ちょっと前にLLVMだから凄い坊があそこで暴れてたけど、ここはgccrsとかやる人の場だ、市ね

**デフォルトの名無しさん** · 2022/10/09(日) 13:36:44.30

gccrsって使えるようになったの？

**デフォルトの名無しさん** · 2022/10/09(日) 20:46:00.69

Linux6.1ってRustで組んだってこと？

**デフォルトの名無しさん** · 2022/10/09(日) 22:32:00.35

ドライバ等をRustでも書けるようになるだけ

**デフォルトの名無しさん** · 2022/10/09(日) 23:29:48.75

Pattern alternativesってなんですか？和訳のパターンORもよくわかりません
https://doc.rust-lang.org/book/appendix-02-operators.html
https://doc.rust-jp.rs/book-ja/appendix-02-operators.html

**デフォルトの名無しさん** · 2022/10/09(日) 23:53:45.87

パターンの代替策
つまり「|」記号が
bit演算のORとしてだけでなく
パターンのORとしても使われるよってこと

**デフォルトの名無しさん** · 2022/10/10(月) 11:32:20.19

>>69
なるほど
マルチスレッドで共有する場合にはどうするのが適切なんでしょうか？

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

>>105
これか

https://qiita.com/muumu/items/f264ad781486d3dd037b

**デフォルトの名無しさん** · 2022/10/10(月) 18:49:06.89

Linux Kernel6.1は、Rustへ移行した最初のバージョンとなります。
Rustへ移行することにより、C言語バージョンの世代から、およそ30%の高速化を果たしました。

**デフォルトの名無しさん** · 2022/10/10(月) 22:52:16.26

気分はCelltic！
「実はshared xor mutableってしっくりこないんです！」

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

>>105
内部可変性を得たい場合
スレッド内ではCell<T>もしくは参照を持ち出したいならRefCell<T>を使う
スレッド内部で普通の共有ならばそれらの＆を使う　(＆mutでなくてもOK)
スレッド内部で所有者が別となる共有ならばそれらのRc<...>を使う

スレッド間では完全排他のMutex<T>もしくはreaders複数可のRwLock<T>を使う
(ただしTがi32やboolならばもっと軽いAtomicI32やAtomicBoolが使える)
スレッド間で共有は所有者が別となるのでそれらのArc<...>を使う

**デフォルトの名無しさん** · 2022/10/11(火) 18:04:30.49

>>97
最適化頑張ってるだけでムーブは概念的なものじゃないぞ。RBMMなんだから。

**デフォルトの名無しさん** · 2022/10/11(火) 19:16:08.16

moveがmemcpy呼び出しになるかどうかはあくまでも実装の話で
move自体のセマンティクスはデータのコピーを要求しないということが言いたいのでは

最適化offにして構造体サイズ大きくするとmemcpy呼び出されるから、memcpy起きないというのは嘘だけど

**デフォルトの名無しさん** · 2022/10/11(火) 19:23:40.64

>>110
あくまでもRustの言語レベルでの抽象的なレベルではムーブはムーブであってビットコピーの保証はそこには一切ない
そして我々は抽象的な概念に基づいてプログラミングすればよい
生成コードはムーブという抽象的な概念だけを保証して最適化される
だからこそ生成コードではムーブでビットコピーが消え得る

**デフォルトの名無しさん** · 2022/10/11(火) 19:29:43.10

>>111
memcpyはたまたまムーブの最適化なしのデフォルト状態で行われる可能性のあるコードにすぎないね
Rustの言語としてはmemcpyが必ず行われることなんて全く保証しない
ムーブはもっと上位の概念であってRustが保証するのはその上位の概念のみだね

**デフォルトの名無しさん** · 2022/10/11(火) 19:51:08.13

>>113
はいはい、>>111は誤読されかねない表現でしたね
(常に)memcpy起きないというのは嘘
と読み替えておいてください

元々の>>94のRefCellやMutexの方が効率的かという質問については、そういう場合もある、というのが答えで良いですよね

生成されるコードがどうなるかは最適化レベルや周囲のコードに依存するわけで、必ずどちらかが効率が高いと言えるようなものではない
感覚的には格納するデータサイズが大きい方がRefCell/Mutexが有利に、小さければCellが有利になりそうだけど、
ちゃんと測定したわけではないので実際のところは分からない

**デフォルトの名無しさん** · 2022/10/11(火) 20:23:10.29

>>114
実はRefCell構造体のメンバーにCellが使われている(現状)

使用されるメモリサイズ
Cell<T> ← Tと同じサイズ
RefCell<T> ← Tのサイズに加えてborrow管理のために内部で使用するCellサイズ分加算

動作コスト
Cell<T> ← (利用後すぐset()すれば)Tと同じコスト
RefCell<T> ← Tのコストに加えてborrow管理のために内部で使用するCellの読み書き操作コスト分加算

**デフォルトの名無しさん** · 2022/10/11(火) 21:44:42.19

ホント笑っちゃうくらい嘘を散りばめてくるよねw

**デフォルトの名無しさん** · 2022/10/11(火) 21:58:52.19

>>114
RefCellやMutexの方が効率的かという質問については
代用として使うならばそれらの方が遅いでしょう
RefCellはボローチェック処理が必ず入ります
Mutexは排他的ロック処理が入るのでさらに遅いです

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

>>115
動作コストはT全体を置き換える場合だよね
TがVecで、一要素追加する場合のコストも計算してみてよ

>>117
ボローチェック処理が最適化で消えないことは保証されてるの？
ボローチェックや排他処理のコストはCellで発生するデータコピーより必ず高コストになるの？

**デフォルトの名無しさん** · 2022/10/12(水) 14:10:22.75

ムーブ元の変数が使われないことがわかってるんだから
その変数の領域を使い回せばよいだけでしょ？
普通に考えてコピーとか起きないと思うんだが

**デフォルトの名無しさん** · 2022/10/12(水) 18:26:20.15

自称分かってる人同士のケンカ

**デフォルトの名無しさん** · 2022/10/12(水) 21:47:16.08

RefCell使うのはアロケーションを避けたいからでしょ

**デフォルトの名無しさん** · 2022/10/12(水) 23:29:45.96

Cell<T>もTもメモリ領域は同じサイズで性質が異なるだけなのね

Cell<T>の更新はこうなるから
(1) メモリ→value読み出し　// take()その1
(2) メモリ←default-value書き込み　// take()その2
(3) valueを更新してnew-value
(4) メモリ←new-value書き込み　// set()
コンパイラがまともなら(2)の部分はムダと判断して無くせそうね

さらにvalueの更新内容によっては (例えば足し算など算術の場合など)
その後にLLVMが最適化でメモリに対して直接実行する命令コードにするだろうから読み出し書き込みも消えるわけね

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

CopyじゃないStringやVecで&mut selfとるメソッドを試せば違いが分かるよ

**デフォルトの名無しさん** · 2022/10/13(木) 02:00:58.56

Copyを実装しない適当な構造体
#[derive(Default)]
struct Foo {
　inner: i32,
}
の &Cell<Foo> と &mut i32 の両方のケースで
>>122の最適化により同じ生成コードとなるから
Copyを実装してるか否かは関係ないみたい

**デフォルトの名無しさん** · 2022/10/13(木) 03:36:21.71

>>124
それだと簡単にインライン化出来るからね
アロケーションが必要な型という意味でCopyじゃないStringやVecと言ったんだけど
Dropと言ったほうがよかったのかな

**デフォルトの名無しさん** · 2022/10/13(木) 04:02:18.88

アロケーション発生しなくても(i32, i32)とかにするだけでもう生成アセンブリ同じじゃなくなるね

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

コンパイラが>>122の
(2) メモリ←default-value書き込み
を削除する最適化をすれば
Copy実装なかろうがヒープを使おうが
生成コードは同じになるんじゃね？

**デフォルトの名無しさん** · 2022/10/13(木) 15:12:31.34

>>126
Copyにしてget/setにすれば同じになるかも

**デフォルトの名無しさん** · 2022/10/13(木) 15:31:24.77

macOSにおけるFirefoxのパフォーマンスを劇的に改善した方法とは？
メモリアロケーター「jemalloc」を独自にカスタマイズしたアロケーターを用いてメモリ管理を行っています。Firefoxのアロケーターでは並列処理時のロックを効率的に行うためにOSごとにネイティブなAPIを使用しているとのこと。このロックAPIとして、macOSではOSSpinLockが用いられていました。
https://gigazine.net/news/20221011-firefox-macos/

これって、Rustのメモリアロケーターがjemallocを基にしたRust実装になってるってことだよね？大昔はjemallocだったという話で

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/13(木) 16:10:29.83

>>129
現在の Rust はデフォルトではシステム標準のアロケータを使うはず。
一時期は Jemalloc (のバインディング) を使っていたけどだいぶん前にやめてる。
やりたければアロケータの差し替えは簡単に出来るので
大きなプロジェクトだと (必要な性質にあわせて) 専用のアロケータを持っていることはあるかも。

**デフォルトの名無しさん** · 2022/10/13(木) 16:44:36.94

>>129
この記事はrustまったく関係ないよ
Firefoxはすべてがrustで書かれているわけではない

**デフォルトの名無しさん** · 2022/10/13(木) 17:51:45.20

>>129
Rustでは1.32.0(2019/01/17)から jemalloc がデフォルトでなくなりましたが、理由はjemallocのほうがマルチスレッドでは
微妙に低負荷で速いですが、コンパイルバイナリで300kB追加されるのとjemalloc自体のバグなどで問題が出ていたから。

Firefoxは恐らく、Cargo.tomlでアロケターをjemalloc系（多分tikv-jemallocator）に変えていて速度を稼いでるのでは？
（完全に想像だけど・・・）

Rust で jemalloc を使ったら並列処理が速くなった
https://zenn.dev/hankei6km/articles/using-jemalloc-in-rust-speeds-up-parallelism

**デフォルトの名無しさん** · 2022/10/13(木) 20:45:15.45

>>132
C++とのinteropあるからrust側はC++のallocator呼び出しているだけで
独自に(オリジナルの)jemallocをリンクすることはしてないと思うよ

**デフォルトの名無しさん** · 2022/10/13(木) 23:11:21.07

>>133
元記事見ると、jemallocそのものを一部、リプレースして書き換えてるみたいね。firefoxのレタリングエンジン自体はservoで
tikv-jemallocatorを使ってるみたいだけど、リンクしてるのはその通りオリジナルではなく書き換えたjemallocになってるみたい
https://github.com/servo/servo/blob/master/components/allocator/Cargo.toml
https://searchfox.org/mozilla-central/source/memory/replace/logalloc/README

**デフォルトの名無しさん** · 2022/10/13(木) 23:14:01.26

いや動的リンクはしてないのかな？jemallocソースをリプレースして実行ファイルに組み込んでる

**デフォルトの名無しさん** · 2022/10/13(木) 23:25:53.83

Firefoxはservo使ってない定期

**デフォルトの名無しさん** · 2022/10/14(金) 01:05:31.38

>>127
コンパイラはそんなに賢くないってことじゃね？

**デフォルトの名無しさん** · 2022/10/14(金) 10:36:15.19

複オジの嘘をまともに相手してたらキリが無いよ

**デフォルトの名無しさん** · 2022/10/14(金) 11:07:41.50

おじさんなんで最近こっちにいるの？
隔離スレが機能しなくなったのとリンクしてるのが面白い

**デフォルトの名無しさん** · 2022/10/14(金) 21:09:01.17

>>136
シッタカも出来ないかまってちゃん不定期
https://searchfox.org/mozilla-central/search?q=servo%2F&path=&case=false®exp=false

**デフォルトの名無しさん** · 2022/10/15(土) 00:38:51.20

>>140
servoを構成するコンポーネントのうちfirefoxに取り込まれたstyloしか登場してないように見えるが

**デフォルトの名無しさん** · 2022/10/15(土) 10:12:30.40

複オジにマジレスしても意味ないよ

**デフォルトの名無しさん** · 2022/10/15(土) 21:19:13.19

お前の主張は「Firefoxはservo使ってない」であって「styloしか登場してない」では無い、そもそもstyloだけじゃない
途方もなく低い技術力でマウント取りたいことが生きがいの薄汚いオッサン

**デフォルトの名無しさん** · 2022/10/16(日) 01:52:37.08

servoは独立したレンダリングエンジンだからservoを使うと言えるのはgeckoを丸々置き換えた場合では
というかallocatorの話はどうなったんだ

**デフォルトの名無しさん** · 2022/10/16(日) 13:06:47.08

「Firefoxはservo使ってない」定期、顔真っ赤の話しそらしオジサン、geckoを丸々置き換えた場合とか言い出したｗ
「styloしか登場してない」も消えたwww
あんたはアロケーターなんて興味ないだろwww
したけりゃしろ。自分からは詳しい技術的な話何もできない、マウントしたいだけ、業界にいる寄生虫

**デフォルトの名無しさん** · 2022/10/16(日) 16:22:20.12

>>134
firefoxのレンダリングエンジンはservoじゃなくてgeckoのままだよ
servoは次世代ブラウザ向けのレンダリングエンジンの実装を模索するための実験プロジェクトで、geckoを置き換えることを意図したものではないよ
servoの一部のコンポーネントは完成度が高くgeckoに取り込まれてはいたので、
servoが発展していったらgecko全体がservoで置き換えられる未来もありえたけど、
mozillaがservoの開発者レイオフしちゃったのでその可能性もなくなっちゃったかと

動的ライブラリや静的ライブラリとして他のアプリケーションにリンクするcrateの場合、リンク先のアプリケーションバイナリに含まれる(または、動的リンクされる)allocatorを利用するのが普通なので、
geckoのservo由来のrustコードもそうなっていて独自にallocatorを定義することはしていないんじゃないかな

**デフォルトの名無しさん** · 2022/10/16(日) 18:59:51.30

rust関係ないけどjemallocを日本語で読む時
ジェ-マロック派？それともジェム-アロック派？

**デフォルトの名無しさん** · 2022/10/16(日) 20:24:24.45

Json Evans mallocだからジェーイーマロックって呼んでる

**はちみつ餃子** ◆8X2XSCHEME · 2022/10/16(日) 22:45:33.29

それを言うなら malloc が (たぶん) memory allocate の略なんだから
ジェーイーエムアロックと呼ぶのが筋というものでは……。

俺はそもそも口頭で読み上げる機会がないから考えたこともなかった。

**デフォルトの名無しさん** · 2022/10/16(日) 23:11:22.79

開発者本人の動画見るとジェイ・マロックに聞こえるが
ジェイ・イー・マロックが短くなってるだけかなこれ
https://youtu.be/RcWp5vwGlYU?t=79

**デフォルトの名無しさん** · 2022/10/17(月) 18:50:40.32

>>146
servoじゃなくてgeckoのままは言い過ぎです、現にベクター系の2Dや、Canvasなどに使用するレンダラーはservo由来の
レンダラーが使用されます。その他はその通りでしょう

**デフォルトの名無しさん** · 2022/10/17(月) 19:52:15.71

>>151
geckoを構成するコンポーネントの入れ替わりはあったけど
firefoxのレンダリングエンジンは生まれたときからずっとgeckoだよ
逆にgeckoじゃなかったら何なんだ

**デフォルトの名無しさん** · 2022/10/17(月) 19:58:16.39

>>151
FirefoxにRustのコンポーネントを多く導入したQuantumプロジェクトの説明でも、ServoのコンポーネントをGeckoに取り込むと言っていて、
Geckoを置き換えるとは言っていない
https://wiki.mozilla.org/Quantum

**デフォルトの名無しさん** · 2022/10/17(月) 21:29:09.32

Rust関係ないからFirefoxスレでどうぞ

**デフォルトの名無しさん** · 2022/10/17(月) 22:43:40.85

もうその話題はいいよ
しつこいな

**デフォルトの名無しさん** · 2022/10/18(火) 10:08:56.84

しつこくやって『Cell<T>はTと同じコスト』(真っ赤な嘘)を流したかったんでしょw

**デフォルトの名無しさん** · 2022/10/18(火) 11:26:14.64

termuxのrustずっとバージョン不整合で動かないな
rustupじゃそもそもインストール出来ない

**デフォルトの名無しさん** · 2022/10/18(火) 12:14:53.29

>>157 俺は普通に動いてる
一応聞きたいんだけど､TermuxはF-Droidから入れたよね?
Play Store版はもうメンテナンスされてないから色々バグると思う

**デフォルトの名無しさん** · 2022/10/18(火) 12:23:43.08

>>153
あー、それ見てワカッタ風吹かしてんのな。「Rustのコンポーネントを多く導入」と言ってる時点で、styloだけじゃないし
2DレタリングのwebrenderもservoからのRust製だわ。”誰も”Geckoを置き換える＝Geckoが無いなんて言ってない
https://github.com/servo/webrender

**デフォルトの名無しさん** · 2022/10/18(火) 14:03:11.76

>>158
F-Droidから入れてる
何故かlibllvm-14.soのリンクが出来ないと怒られてしまう
で入ってるllvmのバージョンが更新で15に上がってしまってる状態
俺環かも知れんね

**デフォルトの名無しさん** · 2022/10/18(火) 14:27:25.95

あんまり自信がある訳じゃないんだけど、カーネルが64bitでユーザーランドが32bitみたいな環境だったりしない？

**デフォルトの名無しさん** · 2022/10/18(火) 14:27:28.03

>>159
Geckoのコンポーネントを置き換える
と
Geckoを置き換える
は全然意味が違うでしょ

まあ日本語の問題で意図してるところは食い違ってないから反応するのはこれで終わりにするわ

**デフォルトの名無しさん** · 2022/10/18(火) 14:32:25.86

グーグル、Rustで書かれたセキュアなOS「KataOS」を発表
https://japan.zdnet.com/article/35194751/

**デフォルトの名無しさん** · 2022/10/18(火) 15:37:54.47

>>158,161
すまぬ色々やってる中で入れたnightlyの影響だった
お騒がせした

**デフォルトの名無しさん** · 2022/10/19(水) 03:30:17.24

fucsia「僕はいらない子なの？」

**デフォルトの名無しさん** · 2022/10/19(水) 07:05:26.07

>>163
昔「おおっ！！！あのグーグルがまた何か新しいことを始めたぞ！すごそうだ！」
今「まぁーーたはじまったよ・・・」

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

Googleが立ち上げては潰してきたサービス一覧｢Killed by Google｣
killedbygoogle.com

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

何も産まないよりは健全よね

**デフォルトの名無しさん** · 2022/10/19(水) 11:35:06.09

役に立つかどうかわからんものに手を出せる余裕が
個別の結果に関わらず
部分的な成果の積み上げで会社をブーストさせるんよ

**デフォルトの名無しさん** · 2022/10/19(水) 11:38:58.17

まあ堅そうな名前ではあるな

**デフォルトの名無しさん** · 2022/10/19(水) 12:24:59.02

IoT向けOSって言ってるし組み込みOSなんて元々百花繚乱だろ。
組み込み機器の脆弱性対応なんて大変だし、そもそもその手の脆弱性が入り込みにくい言語を採用するのは合理的だと思う。

**デフォルトの名無しさん** · 2022/10/19(水) 12:46:33.84

日本ってやらない理由、出来ない理由並べる奴が多いよな
多くの日本企業よりGoogleの方が多く生み出しているし世の役に立っている

**デフォルトの名無しさん** · 2022/10/19(水) 12:48:40.76

南朝鮮ってやらない理由、出来ない理由並べる奴が多いよな多くの南朝鮮企業よりGoogleの方が多く生み出しているし世の役に立っている

**デフォルトの名無しさん** · 2022/10/19(水) 13:00:38.45

Rust Foundationへの参加はNECやFUJITSUよりSamsungの方が早いんじゃないかなぁ
国内大手で積極的にRustを推していこうなんて所はなさそうに見えるし
組み込みのRenesasとかもやる気なさそうだしな

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

出来ない理由を考えるのではなく！

**デフォルトの名無しさん** · 2022/10/19(水) 21:32:43.94

日本が後進国になってきたのは政治の責任が大きいけど
IT分野で遅れてるのは総じて教育水準が低いからだよ

**デフォルトの名無しさん** · 2022/10/19(水) 22:51:58.05

民主主義国は政治の責任＝有権者の責任

**デフォルトの名無しさん** · 2022/10/19(水) 23:03:48.16

>>177
利権差配と中抜きしか考えない国賊を礼讃して
統一創価売国与党に投票し続けたやつの責任だろ

**デフォルトの名無しさん** · 2022/10/20(木) 00:02:58.60

まったく読むに値しないクソ書き込みの羅列の中で
>>170 だけが唯一価値ある輝きをはなっている

**デフォルトの名無しさん** · 2022/10/20(木) 13:00:10.90

在日だらけ。IT分野で遅れてるのは米国（英語圏）・中国の人口差だし、日本の人口減でもある。
世界中で、歴史上、移民以外で人口減を解決した国は１つもない
そういう意味では韓国などはでは優れたソフトウエアは１つもない。馬鹿な半島はAndoridのOSを
握ろうとTizenなどというゴミを掲げたが、食いついたのはNTTドコモぐらい
いま韓国で起こってるのはソフトウエアサービスの””ガラパゴス化””であり、GoogleやAmazon
Apple Payなどに対して参入障壁を作り防御するような、大昔の古臭い日本あった不公正貿易。
民主党政権時代だって３年あったわけだが、利権と中抜きしかしてない。やったことは仕分けだが
１つも役に立たないどころか、地方医療を崩壊させ、気象変動へ対処できるインフラ投資を
一時的止めた害悪しかなかった。その他にも野田政権による執拗な消費税増税もあった。
今彼らは英国が減税を匂わせただけで大混乱していることを見ずに、消費税ゼロを掲げている。

卑劣にも矛先を反らし、リベラルなのに移民反対派で、リベラルなのに「国賊、売国」などという言葉を使い、
まるで戦争前夜か、共産主義や社会主義のような物言いをするアホが出る時点で若い人の人材不足といえる。

**デフォルトの名無しさん** · 2022/10/20(木) 16:07:13.38

英国が減税しただけで、支持率が7% になったw
米国の金利上昇で、韓国の金利も0.5% 上がったw

なのに、借金が1千兆円もある日本の金利が、0%w

狂った世界中の経済学者達が、日本は不正をしている。
日本国債は破綻しなければおかしいと言ってるw

外人が幾ら日本国債を売っても、金利が上がらない。
破綻しないw

いい加減、借金が1千兆円もあるという財務省の嘘に気付け！w

YouTube で勉強しろ。
【TVじゃ絶対言えない話】国の借金は嘘！？中田敦彦が解説

**デフォルトの名無しさん** · 2022/10/21(金) 19:45:15.15

WEB+DB PRESS、何度目のRust入門なんだい？

**デフォルトの名無しさん** · 2022/10/21(金) 20:10:13.59

Rust入門は初めて

**デフォルトの名無しさん** · 2022/10/21(金) 21:22:06.02

pythonとrustを一通り試してみた
for文の入れ子で外側のforをbreakできるとか、数値を1_000_000と表現できるとか、
そんなところでrustのほうが行き届いている感じがした

ただpythonのリスト内包表記、添え字の-1で配列の一番最後を表すとかそんなのは便利だな

**デフォルトの名無しさん** · 2022/10/21(金) 21:26:14.55

Rust入門という感じではないな
Rustを使ったWeb入門という感じ

**デフォルトの名無しさん** · 2022/10/21(金) 22:25:35.46

>>185
Web+DB Press読者は簡単なWebアプリ開発はいろんな言語で経験済みで理解しやすいだろうからチュートリアルの対象に選んだだけでは？

**デフォルトの名無しさん** · 2022/10/22(土) 13:19:56.51

>>186
普段読まないけどRustなので買ってみた
なかなかわかりやすかった
基本文法の解説が明らかに足りないけど
サンプルを理解するだけならこの程度で良いのか
面倒な部分が表に出ないようにうまくサンプルを調整してるし

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

借用がどうGCに関係するのかよくわからない
うまく説明しているサイトはないですか?

**デフォルトの名無しさん** · 2022/10/22(土) 21:38:11.55

まずスタックとヒープを理解せよ
これは口を酸っぱくして言ってる
でないとRustは理解できない

**デフォルトの名無しさん** · 2022/10/22(土) 21:39:04.07

とりあえずThe Bookの4章
https://doc.rust-lang.org/book/ch04-02-references-and-borrowing.html

Rustをそれなりに習得しようと思うなら
The Bookとオライリー本を読むのが一番近道

**デフォルトの名無しさん** · 2022/10/22(土) 23:56:07.88

両方とも初心者には辛いよなあ
わかりやすい入門書が待たれる

**デフォルトの名無しさん** · 2022/10/23(日) 00:22:18.48

借用するときにデータをスタックに積む
スコープを抜けるときに一気にpopするので
GCがいらない、つまり、早い
heapだとGCのときにデータの移動が必要になる
ので遅い
この理解であってる?

**デフォルトの名無しさん** · 2022/10/23(日) 00:29:31.67

ポインタとか参照とか他の言語で扱ったことない？

**デフォルトの名無しさん** · 2022/10/23(日) 00:44:57.32

heapが遅いの要因は、メモリの割り当て解放処理があるから処理量が多いとか、
割り当てた領域がバラバラになることでキャッシュ効率がさがることとかかと

**デフォルトの名無しさん** · 2022/10/23(日) 13:47:22.46

ページング処理みたいなのが、ヒープだと2重に行われるんじゃないの？

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

>>192
Rustでのその辺のメモリの動きはオライリー本に詳しく書いてあった気がするから読むべし

**デフォルトの名無しさん** · 2022/10/23(日) 15:30:09.10

>>192
>>195
お前ら、具体的にどうされてるからスタックだと速いかわかって無いだろ、、、

**デフォルトの名無しさん** · 2022/10/23(日) 18:33:19.09

>>192
そんなに物事が単純なら良かったのに...
”スコープを抜けるときにGCがいらない、つまり、早い”、これは間違いでもある。インライン展開されるような高階関数なら良いが
ループ中でアロケーションしてしまうような記述をすると、その度に確保・解放されるので非効率になりかねないし、借用による
メモリーの管理ではないが、参照カウントを使用するSwiftでは、ループでボトルネックになることはある。
このためRustでは高階関数で書く事が一般的に（分かり易く）良い事とされる。あとスタックでどの言語も大体はスコープ外で
消えるのでヒープとスタックの区別は付けましょう

独立したGCスレッドが動く言語だと、スコープ外れでGCするとは限らないので、速い場合がある。一方で、高負荷な環境では
GCスレッドがありで、回収などインターラプトが入るのでRustが有利になる（＝※こちらのほうがRustが重要視される理由）
いわゆるSTOP THE WORLD（DIO様風）だ。ただ、これが無ければ良いということではなく、循環参照などを作らなければ
問題ないという話で循環参照を作ってしまうのであれば、独立したGCスレッドは便利でもある

”GCのときにデータの移動が必要”になるかどうかは、GCのアルゴリズム次第であり、厳密には”データの移動が必要”になるのは
メモリーのフラグメント解消つまりコンパクション処理によるところが大きい。これは、近代的なOSでは似たような事を行っていて
これ自体が速度に大幅に影響を及ぼすとは言い難い

**デフォルトの名無しさん** · 2022/10/23(日) 19:03:12.25

>>198
> ループ中でアロケーションしてしまうような記述をすると
アホなコードで議論する必要あるの？

**デフォルトの名無しさん** · 2022/10/23(日) 20:51:00.62

一体何と何を比較しているのだ