Rust part21

**デフォルトの名無しさん** · 2023/08/15(火) 22:24:39.45

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

公式ドキュメント
https://www.rust-lang.org/learn

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

※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 part20
https://mevius.2ch.net/test/read.cgi/tech/1677771928/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.2ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2023/10/20(金) 06:13:09.90

Cで安全に書いたときと同じ生成コードにはなるけどRustでは抽象度の高い表現をするからなあ
例えばメモリのある範囲の領域を順に読み取る(書き込む)というC言語だとポインタをインクリメントしていくだけの場合でも
Rustだとまずメモリの領域をスライスという安全な抽象表現で扱い可変性もライフタイムも付随してスライスが指す元の安全に確保されている領域(配列やベクタなど)も必須というところからスタート
そのうえでスライスのイテレータにより必ずその範囲内のみを順に安全に指し示す参照(または可変参照)が次々と得られて順に読み取る(書き込む)ことが達成される
さらにRustではこれをfor文ではなく抽象度の高いイテレータメソッドチェーンで書くことも多いからCコードとの対応はますます難しくなるね

**デフォルトの名無しさん** · 2023/10/20(金) 06:56:18.50

unsafe {
Rust で C ポインタやりたいなら
let p = *mut hoge;
p+=1;
std::slice::from_raw_part(p. 1)[0] = hage;
}

**デフォルトの名無しさん** · 2023/10/20(金) 09:04:11.56

>>513
同じように書けないからこそ対比したものが欲しいと言う話だろうに

**デフォルトの名無しさん** · 2023/10/20(金) 09:27:32.12

>>516
クソでたらめだが真面目に実装するとマジ面倒
>>515 方式だと
#[derive(Debug)]
struct Hoge {a: u8, b: u8, c: u8}
impl Hoge {
pub fn new(a: u8, b: u8, c: u8) -> Self {Hoge{a, b, c}}
}

fn main() {
let hoge: Vec<Hoge> = vec![Hoge::new(1, 2, 3), Hoge::new(4, 5, 6), Hoge::new(7, 8, 9)];
println!("{:?}", hoge);
let mut p = &hoge[0] as *const Hoge as usize;
p += 2 * std::mem::size_of::<Hoge>();
unsafe { std::slice::from_raw_parts_mut(p as *mut Hoge, 1)[0] = Hoge::new(8, 3, 1); }
println!("{:?}", hoge);
}
>>514 方式だと
let p = &hoge[0] as *const Hoge as *mut Hoge;
unsafe { std::slice::from_raw_parts_mut(p, 3)[2] = Hoge::new(8, 3, 1); }
でちょっとマシになるくらい

**デフォルトの名無しさん** · 2023/10/20(金) 09:40:03.83

マクロでウヒヒ

**デフォルトの名無しさん** · 2023/10/20(金) 11:03:08.72

近代的な言語の仕組みってのは大規模なプログラムをどうやってまとめるかという方向で進歩してるから
小さなサンプルで比較しても設計理念は身につかんのだ。

**デフォルトの名無しさん** · 2023/10/20(金) 13:13:02.21

設計理念を身につける話なんて誰もしとらんだろw

**デフォルトの名無しさん** · 2023/10/20(金) 15:12:25.73

してないから問題だと述べてるんだが。
俺が学生のときに英語の長文の全ての単語の横に(単語ごとに！)日本語の単語を書いてたやつがいたことを思い出したわ。
本に載る程度の規模(ひとつあたり数ページくらい？)のプログラムを対比するってのはそういうことだよ。
言語の設計理念に基づいた構造こそが重要で、構造を論じるほどの規模にならないならたいした違いは見えてこない。

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

CでもPythonでもRustでも全部の行にあほみたいなコメント描く香具師はうざいけど
Rustのcrateでdocsにcomment100%達成するためにはアホなコメント描かされてダサい設計思想だと思う

**デフォルトの名無しさん** · 2023/10/20(金) 16:34:14.75

>>521
日本語の設計理念wが身についてないみたいだなw

**デフォルトの名無しさん** · 2023/10/20(金) 17:24:55.57

unsafe使うならCでいいんだよなw

**デフォルトの名無しさん** · 2023/10/20(金) 19:40:13.76

>>524
それは違う
unsafeを使ってsafeなインターフェースを提供する部分だけ人間が安全性を保証すれば
それ以外の部分はすべてRustが安全性を保証してくれる
その方針でRustの標準ライブラリやunsafeを用いる一部クレートが作られている

**デフォルトの名無しさん** · 2023/10/20(金) 20:06:04.22

>>525
もちろん品質が保証されてるライブラリは使うよ
現時点でここまでライブラリが揃ってるから自前でunsafeを書く必要は感じない

**デフォルトの名無しさん** · 2023/10/21(土) 12:29:35.28

関数型最強(キリω
ですねわかります

**デフォルトの名無しさん** · 2023/10/21(土) 21:43:10.75

Linuxでも、結局のところ「C言語でいいじゃん」という結論になりそうよね
リーヌスもなんかやっぱRustはなぁ・・・ってトーンダウンしてきてるし

**デフォルトの名無しさん** · 2023/10/22(日) 00:35:28.61

>>528
カーネルなんて低レイヤーのポインタ操作とかビット演算しかしないからな

**デフォルトの名無しさん** · 2023/10/22(日) 00:50:06.85

Linux カーネルの中にだって Rust が適している場所も
あるといえば有るだろうけど現時点でそれなりに検証が済んで
安定して動いているものを「置き換え」するほどではないだろうな。

適しているからといって各部を別の言語で書いたりすると
接続箇所で面倒になったりもするし。

**デフォルトの名無しさん** · 2023/10/22(日) 11:49:16.17

カーネルで流行らないならもう流行るところないんじゃ…

**デフォルトの名無しさん** · 2023/10/22(日) 19:50:36.55

どの言語からどの言語への場合でも既に動いているものを別の言語に移植するだけだとコストがかかる
それでもスクリプト言語からRustへ置き換えるなら実行速度と省メモリの効果がコストを上回りやすいためよく行われている

一方でC/C++からRustへ換えても実行速度と省メモリの効果はない
だからシステム設計を変えるなど大きな更改タイミングでRust化することが多い
特にマイクロサービス化されているものは個別に更改できるためシステム全体の一部Rust化に向いている

最も向いておらずハードル高いのがモノリシックになっているOSカーネル
その場合でも分離されているデバイスドライバは最近のデバイス複雑化と更新対応の多さからもRust化が向いているため進んでいる

**デフォルトの名無しさん** · 2023/10/22(日) 19:58:13.61

>>531
もうちょっと上位のレイヤーなら良いと思うけどね
Cでバッファオーバーランするようなプログラムって
結局Rustでもunsafe使わざる終えないような処理なので

**デフォルトの名無しさん** · 2023/10/22(日) 21:57:00.47

構造体をキャストするものでも、hoge_storage_t みたいに最大サイズを規定するパターンと
char foo[0]; を積極的に利用するパターンと真っ二つにわかれるしねぇ
後者はRustでどうすんだろ

**デフォルトの名無しさん** · 2023/10/22(日) 22:15:56.13

結局構造体もパケットのバイト列にパックするからね
その時unsafeを使うことになる

**デフォルトの名無しさん** · 2023/10/22(日) 22:45:30.49

構造体はunsafeいらん
タグ無し共用体はunsafe

**デフォルトの名無しさん** · 2023/10/22(日) 23:15:20.26

流行るから価値ある、流行らないから価値なしって評価基準はジャパニーズカルチャーのガラパゴス

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

>>534
後者も普通に表現できるしCとのFFIも可能

**デフォルトの名無しさん** · 2023/10/22(日) 23:28:57.61

Redox（https://www.redox-os.org/）みたいなRust製のUnix系OSプロジェクトならもうあるし
無理してLinuxに食い込む必要はないと思うんだけどLinux開発者でもRust使いたい人はいるんでしょ
Linuxは一部のモジュールがRust製になる程度で中核は最後までCで通すと思う
というかRustで置き換えるなら名前変えてほしい

**デフォルトの名無しさん** · 2023/10/23(月) 00:13:38.68

>>539
まあカーネルで使ってる基本的なデータ構造(赤黒木、ハッシュテーブル、双方向リスト)
kref(リファレンスカウント)などは外せないからね
無理に組み合わせるとかえってキツい気がする

**デフォルトの名無しさん** · 2023/10/23(月) 05:58:05.37

>>533
実際にはCでもバッファオーバーランしないからRustでは、unsafe必要ないでしょ

**デフォルトの名無しさん** · 2023/10/23(月) 06:59:33.53

>>533
>使わざる終えない

昔こんな誤字よく観たな

**453** · 2023/10/24(火) 00:55:17.36

>>500
今度は逆にrustで書いたもの>>453をcで書いてみた
https://ideone.com/j5KR8Y
・参照透過性は考慮していない
・型のパラメータ化？には挑戦してない
・パターンマッチ再現？にも挑戦してない
・クロージャが欲しいところには呼び出し元の文脈を手渡して誤魔化す
・グローバル変数一個使ってノードの再利用を試みてる
・とにかくlist_qsort内部がそれっぽい感じの手順になってたらヨシ
struct node {
int value;
struct node *next;
};
struct node *list_qsort(const struct node *list) {
int pivot;
struct node *sorted = 0, *tail, *smaller, *rest, *a, *b;
if (list) {
pivot = list->value, tail = list->next;
list_partition(&pivot, less_than_context, tail, &smaller, &rest);
sorted = list_append(a = list_qsort(smaller), b = list_cons(pivot, list_qsort(rest)));
list_available_push_all4(smaller, rest, a, b);
}
return sorted;
}

**デフォルトの名無しさん** · 2023/10/24(火) 13:32:38.68

スレチ

**デフォルトの名無しさん** · 2023/10/24(火) 16:02:23.69

cargo 経由で rustc にコンパイルオプションを渡したいとき
RUSTFLAG=hogehoge
で成功はしたのですがパッケージ全体が再コンパイルされて遅いです
特定のファイルだけにコンパイルオプションを適用したいのですが
cargo にはそういうオプションはありませんか？

**デフォルトの名無しさん** · 2023/10/24(火) 18:21:38.30

>>545
ありません

**デフォルトの名無しさん** · 2023/10/24(火) 20:07:58.68

大文字小文字が混在する言語って気持ち悪い

**453** · 2023/10/24(火) 22:19:05.86

>>543 c
https://ideone.com/yYGR7x
・ノード再利用やめた
・若干の整理

**デフォルトの名無しさん** · 2023/10/25(水) 09:06:18.67

>>545
試してないけど
やるとしたら
cmdとかterminal(shell)を2つ以上別ウィンドウで開いておいて
それぞれ別のRUSTFLAG=を設定しておく(環境毎に独立なはず)
片方でbuildしたあと適用したいファイルだけ修正してもう片方でbuildするとうまくいかんかな

**デフォルトの名無しさん** · 2023/10/25(水) 10:10:31.38

特定のファイルにだけ適用したいコンパイルオプションて何なの？

**デフォルトの名無しさん** · 2023/10/25(水) 10:43:36.55

crateで分割したらいけるんじゃね

**デフォルトの名無しさん** · 2023/10/25(水) 11:35:23.44

そらそうやろと言いたいところだが
今はcrate単位の指定はできなくてパッケージ単位のみ

**デフォルトの名無しさん** · 2023/10/25(水) 13:57:15.42

crate で別れてる前提で
その crate を使う2つの bin (まあまあそっくりな main) を造って
それぞれをそれぞれの RUSTFLAGS= で build したら
うまく使い別けられました
とりあえず速度は気にならないからしばらくこれで逝く
アイディア呉れた人thx

**デフォルトの名無しさん** · 2023/10/26(木) 14:45:03.06

しつもんです
cargo publish のときに
warning: package `hoge vN.N.N` in Cargo.lock is yanked in registry `crates-io`, consider updating to a version that is not yanked
って警告が出てて意味は判るんだが
cargo clean してやり直しても package 'hoge vN.N.N' が最新のものに切り替わらない
自分自身の Cargo.toml の dependencies には hoge は描かれていない
どの crate が原因で hoge を要求してるのか知るにはどうすれば良い？
その crate を最新のものにすれば hoge の yank されてないものを取って来てくれるとも限らない訳だが

**デフォルトの名無しさん** · 2023/10/26(木) 15:53:54.89

cargo treeを使うといいよ

**デフォルトの名無しさん** · 2023/10/26(木) 21:41:03.08

Rust で書かれた WebAssembly／Canvas 上の
FlashPlayer のエミュレータ Ruffle の実装が
凄い勢いで進んでるけど
世界の凄腕プログラマも参戦してるみたい。

このスレで貢献してる人ひょっとしている？
エミュレータ実装て武者修行になるのかな。

**デフォルトの名無しさん** · 2023/10/26(木) 23:18:45.93

エミュレーターを作り始めるスタートは完全な仕様の資料を手にいれることで、それがないことも良くあることだから調査がしんどいんだよ。
そんで実装は仕様通りにやるだけのひたすらに地道な作業だからあまり面白味はない。
動くだけじゃなくて性能を出そうと思ったら色々と工夫の余地はあるんだけど……

**デフォルトの名無しさん** · 2023/10/27(金) 10:08:58.42

古いゲーム機のエミュレータを書いたことがあるが結構面白いぞ
昔のソフトはクロックタイミングに依存することも珍しくないから、性能だけでなく再現精度にも気を配らなくちゃいけない
腕試しとしてはちょうどいいと思うよ

**デフォルトの名無しさん** · 2023/10/27(金) 12:30:38.77

もっと良いサイトあったんだけど消滅してる？
http://sunlight.cocolog-nifty.com/sunlight/2005/08/post_1ff6.html
http://www.sm.rim.or.jp/~shishido/tick.html

**デフォルトの名無しさん** · 2023/10/27(金) 22:25:37.09

>>557 >>558

そうですね、面白さと言う点では

当時は無かった WebGPU等の現代的な技術を
積極的に取り入れて
本家 FlashPlayer の単なるエミュレータに留まらず

ブラウザWASM上の本格ゲーム・アニメプレーヤーに
なりそうな所が興味を引きます。

取り敢えずは日本人として
縦書きCJK 2バイト文字列の動的表示等の
検証報告で協力できたらと考えております。
（和風ゲームのイベント表示など）

**デフォルトの名無しさん** · 2023/10/27(金) 22:44:06.00

web上で再発明するの好きなやつ多いよね
でも失敗率高めじゃないか？

**デフォルトの名無しさん** · 2023/10/28(土) 14:23:38.78

自己鍛錬で再発明するのは好きにすればいいがそれでサーチエンジンの上位を占拠するのはマジ迷惑だ

**453** · 2023/10/28(土) 18:50:08.51

>>548 c
https://ideone.com/Rp476I
・ノードへのポインタとしてリストを表現していた(>>548)のを廃止
・共用体でリストを表現したことによりBoxの位置？がRust版(>>453)と同じに
・特に意味もなくループ文を再帰に置き換え

**デフォルトの名無しさん** · 2023/10/29(日) 12:47:29.07

uBlacklist が猿人検出阻止してくれるそうだ
sejuku とか techacademy とか KENTA とか入れると良い

**デフォルトの名無しさん** · 2023/11/03(金) 14:51:57.32

=== 複製おじさん（通称複おじ）について ===
Rustスレを中心に活動し、2023年4月現在で1年以上ム板に住み着くRustacean。無自覚な荒らし。

Rustスレでは、基本的に他住民の意見を聞いて糧とすることなく、自らのコードが最善であると、ID変更自演を交えいつまでも主張し続ける。
同スレで「所有権が複製される」という違和感のある表現を、「違和感がある」とする他住民の意見をすべて否定してしつこく擁護し続けたことから、「複製おじさん」というあだ名が付けられた。
それ以外のム板スレでは、基本的に他住民の意見を聞いて糧とすることなく、Rustこそが最善であると、ID変更自演を交えいつまでも主張し続ける。
その基本戦術は、「GC言語は遅い」の一声でC/C++/Rust以外の言語を否定し、残ったC/C++は安全ではないので、Rustが最善であるとするもの。

しかしながら、Rust以外の言語に関しては、正当な批判を展開するのに十分な知識を持っているとは言いがたい。
本スレPart1では、C++の問題点を指摘しようとして多数の誤り・知識不足を露呈することとなった。特にしつこく食い下がったのが「動的ディスパッチ」に関する誤解である。
https://mevius.5ch.net/test/read.cgi/tech/1677286186/786-799（ID:Evbafc70とID:RiLc+pIfが複製おじさんであると考えられている）
要約すると、通常「条件分岐」と呼ばれるものを「動的ディスパッチ」と呼ぶのが正しいと主張し続けたのである。
常識的にはあり得ない誤解だが、提示されたC++のコードが自らの主張（C++にはパターンマッチが無い）に不都合であると感じたためか、C++のコードを正しく読み解くことができないにもかかわらず脊髄反射的に否定してしまい、その根拠として誤った論理をこじつけてしまったものと思われる。

ちなみにこの後、同種の誤解を持って書き込むID:wHEiYRW7（これはID使用歴的に複製おじさんとは考えにくい）に対して、正しい理解に基づく指摘を行う単発IDが複数出現するが、この中にも複製おじさんが多数含まれていると考えられている。
このように自分の誤りを認識した場合、それを認める書き込みは決して行わず、別人の振りをして最初から正しく理解していた体を装うのも複製おじさんの特徴である。

**デフォルトの名無しさん** · 2023/11/03(金) 20:56:04.34

Generatorはコードがごちゃっとしてたからgen fn/blockはありがたいな

**デフォルトの名無しさん** · 2023/11/03(金) 22:49:04.51

2024 editionから？

**デフォルトの名無しさん** · 2023/11/04(土) 04:29:37.91

Rustの学習を始めたが、所有権面倒くさい。まあでも安全性は高められそうな感じはする。

**デフォルトの名無しさん** · 2023/11/04(土) 12:29:53.92

Better C的なRustが欲しい
C++と張り合って仕様が複雑になってる

**デフォルトの名無しさん** · 2023/11/04(土) 12:45:03.68

>>569
それはZigじゃない？
とはいえ、所有権いい感じに見てくれない言語を今更betterと言えるかというと微妙か。

**デフォルトの名無しさん** · 2023/11/04(土) 13:26:02.22

Rust は別に C++ と張り合ってなんかいないよ。
現実に使うものはどうやったってどこかで汚くなるってだけ。
綺麗なものは使われてないものだ。

**デフォルトの名無しさん** · 2023/11/04(土) 14:22:45.66

>>569
Odinはいかが？
https://odin-lang.org/

**デフォルトの名無しさん** · 2023/11/05(日) 00:55:20.60

>>569
Carbon

**デフォルトの名無しさん** · 2023/11/05(日) 13:27:00.92

>>567
「gen」予約keyword化はそうだね

**デフォルトの名無しさん** · 2023/11/09(木) 15:19:57.39

すまんが、VSCode上から/examples下にあるものをデバッグしたい場合ってどうやんの？
他人の作ったクレートのコードを読む上で、これを楽にできると個人的にはありがたいんだけど・・・・

**デフォルトの名無しさん** · 2023/11/09(木) 22:37:41.41

バージョンと拡張機能によりそうだけど自分の環境（Windows）だと
examples内でもfn main()の上に
|> Run | Debug
みたいなinlayが表示されてとりあえずそこからデバッグ実行できた
設定作ればほかの起動方法もあるはず

たぶんrust-analyserの機能だけどデバッガは環境依存だからわからん

**デフォルトの名無しさん** · 2023/11/12(日) 02:38:23.29

gen はいわゆる協調スレッドなのか。
言語機能として取り込むにはちょっと豪華すぎる気もするな。

**デフォルトの名無しさん** · 2023/11/12(日) 04:55:58.85

genはasyncと同じでコルーチンだよね？
そしてasyncと同じく単純な状態マシンで実装だよね？

**デフォルトの名無しさん** · 2023/11/12(日) 07:45:09.87

>>576
ありがとう！バッチリできたぜ！！！

**あぼーん** · NG

あぼーん

**デフォルトの名無しさん** · 2023/11/12(日) 11:30:27.32

>>580
既にやってるよ

**デフォルトの名無しさん** · 2023/11/14(火) 12:58:29.06

https://crates.io/search?q=arete

0なんだが

**デフォルトの名無しさん** · 2023/11/19(日) 15:31:52.34

rust初心者です。
cだとポインタに対してキャストすることで完全にプログラマ任せのキャストが出来ます。
例えば文字列を参照するポインタを強引に数値として解釈させるなど、好きなように出来ます。
rustでは簡単に調べたところparse().unwrap()などが必要だそうです。
rustはcのようにバイナリフォーマットをプログラマ任せにして自由にキャストさせる習慣はないということでしょうか？

**デフォルトの名無しさん** · 2023/11/19(日) 16:23:14.27

あるよ

**デフォルトの名無しさん** · 2023/11/19(日) 16:29:48.57

#[repr(C)]
as *const T
as *mut T
as usize
bytemuck
slice::from_raw_parts

**デフォルトの名無しさん** · 2023/11/19(日) 16:46:38.60

バイナリや文字列と内部表現・の相互変換(シリアライズとデシリアライズ)ならば
Rustではdeser crateファミリーを使って専業分離することが多いね

**デフォルトの名無しさん** · 2023/11/19(日) 18:17:50.06

シリアライズ関連のクレートを使った方が楽だし、もうちょっと簡易的にやる場合でも from_le_bytes などの組み合わせで安全にやれるから不必要にプログラマの責任で管理するべきではないよ。
C でもいまどきは高レイヤのプログラムならそんなに気軽に未定義の型変換はしない。(もっとも、高レイヤではあまり C を使わないけど)

**デフォルトの名無しさん** · 2023/11/19(日) 18:43:57.48

ごめん、アホなスペルミスしてる
deserでなくてserde
あとserde_bytesやbincodeを併用

**デフォルトの名無しさん** · 2023/11/19(日) 23:58:07.78

少し調べてより明確に言語化出来ました。
Rustはゼロコストのserderができますか？

Cだとしばしばそれができます。構造体の要素次第ですが。
で、調べてみるとrkyvというフレームワークが近いことを可能にしているようです。
ゼロコピーと謳っていますが、何らかの演算コストが生じているのかどうか。
Cなら構造体を注意深く設計すればキャスト一発で実行時コストゼロでserderが完了するのです。

**デフォルトの名無しさん** · 2023/11/20(月) 02:05:15.84

>>589
＞Cなら構造体を注意深く設計すれば

なんでそのコストを無視するんだい？

**デフォルトの名無しさん** · 2023/11/20(月) 02:16:16.40

>>590
実行時コストじゃないからです。
例えばRustのゼロコスト抽象化という概念もあくまで実行時コストがゼロであることを意味しているはずです。

**デフォルトの名無しさん** · 2023/11/20(月) 02:16:45.62

#[repr(C)]付けてstruct/enum/unionをCと同じ使い方すればC互換のレイアウトになるはず

**デフォルトの名無しさん** · 2023/11/20(月) 06:49:29.19

>>589
Cと同じことがしたいだけならrepr(C)で構造体定義して
std::mem::transmuteでキャストすればいい
rkyvみたいなフレームワークはもっと高度なデータ型（ハッシュマップとか）で同じことをやるためのもの

**デフォルトの名無しさん** · 2023/11/20(月) 08:53:23.51

抽象度の高いレイヤを挟んでもかなり最適化で消えるよ。
逆に自由なキャストのコストはゼロではない。
ハードウェアの癖、処理系の癖を理解している人がうまくチューニングすれば性能はあがることも多いけどキャストして直接に読み替えたら実行時コストが低くなるとは限らない。

**デフォルトの名無しさん** · 2023/11/20(月) 13:51:58.80

>抽象度の高いレイヤを挟んでもかなり最適化で消えるよ。

それはもちろん判ってて
その上で厳密にゼロじゃないから問題視してんじゃん

**デフォルトの名無しさん** · 2023/11/20(月) 15:34:39.51

具体的にRustを使うメリットよりデメリットが上回る例があるならそれを出さないと話がわからない
色んなバイナリプロトコルもRustで実装されて問題になっていない

**デフォルトの名無しさん** · 2023/11/20(月) 17:27:20.27

transmuteだとalign合わせるためにコピーする場合がありそうだから
本気でCと同じゼロコストで読み替えするならポインタ（参照じゃない）をとって
as *const T（as *mut T）で目的の型にキャストして参照（&T, &mut T）に戻す感じかな
どうせunsafeだからunion使う方がいいかもしれないけど

**デフォルトの名無しさん** · 2023/11/20(月) 17:54:17.33

Cから移植する場合でtagged unionをうまく移植する方法はないだろうか
unsafe使わずに

struct tagged_value {
enum tag t;
union {
hoge h;
fuga f;
} u;
};

みたいなの

**デフォルトの名無しさん** · 2023/11/20(月) 18:11:32.44

>>598
enumで

**デフォルトの名無しさん** · 2023/11/20(月) 18:17:00.50

>>595
最適化の話は「どちらにしてもゼロとは限らない」という話のための前ふり。
仮にその場所に限ってはゼロになったとしても周囲の最適化の足を引っ張ることもある。
総合的な速さを出すには諸々を加味したチューニングが必要なので単純にキャストしたほうが速いとは考えるなというのが主旨。
もちろん諸々を考慮して検証した上で実際に速くなることが確かめられるならそれを否定したりはしないよ。割に合うことは少ないとも思うけど。

**デフォルトの名無しさん** · 2023/11/20(月) 21:13:04.59

ちゃんと考えるよ。
角度とか

**デフォルトの名無しさん** · 2023/11/20(月) 23:02:22.90

重要なのは、Rustで書くと遅くなる(コストがかかる)パターンを、実際に発見できたのかどうか？

もしそのようなパターンを発見できて、(Cによる)速い方法でも安全性に問題がないのならば、
Rustの歴史ではそれを(必要なら)unsafeで記述してライブラリの中に安全に閉じ込めてきた
そのためRustで一般プログラマーがunsafeを使わずに記述しても、ほとんどのケースでCと同等の速さが出る

**デフォルトの名無しさん** · 2023/11/21(火) 04:05:24.41

個人的な懸念点は処理のゼロコピー化においてCに劣るのか？という点
Rust界隈でゼロコピーフレームワークが色々あるがどういう工夫が行われているのか
調査は時間がかかりすぎるからやらないw

**デフォルトの名無しさん** · 2023/11/21(火) 04:13:54.83

データ転送はCPU上の演算と比較してかなり遅い処理なので
ゼロコピーで劣ると一部の処理でかなり遅くなる
そしてベンチマーク系のプログラムではゼロコピーはあまり問題にならない。

**デフォルトの名無しさん** · 2023/11/21(火) 04:16:28.76

ゼロコピーが問題になるのはserder、通信
あとたぶんOSの実装でも問題になるはず
だから数学的計算というよりはシステム間の垣根を超えるようなところで問題になる
RustがベンチマークでC並といっても、あくまで数値計算系の話

**デフォルトの名無しさん** · 2023/11/21(火) 08:42:33.89

ゼロコピーってのはオリジナルのバッファ以外には追加でヒープアロケーションをせずに処理をするという意味

**デフォルトの名無しさん** · 2023/11/21(火) 10:07:46.27

ウザイからttf_parserのコードでも読んでくれば

**デフォルトの名無しさん** · 2023/11/21(火) 11:00:12.68

unsafe という名前が誤解の元になってる
unsafe に描く内容って結局安全な内容しか描いてはいけない訳だ
そして unsafe は使ってはいけない機能ではなくむしろ積極的に使って良い機能

**デフォルトの名無しさん** · 2023/11/21(火) 11:55:27.06

こういうやつがいるからこそunsafeという名前に価値があるんだよな

**デフォルトの名無しさん** · 2023/11/21(火) 12:57:54.74

>>605
それらRustで書くことで遅くなった事例がない
むしろ例えばCDN世界トップのCloudflareは
Cで書かれたnginxを全面的にRustで作り直すことで
CPUリソースとメモリリソースを1/3に削減することに成功している

**デフォルトの名無しさん** · 2023/11/21(火) 15:25:53.24

Cloudflareのやつはnginxがスレッドベースで処理をブロッキングしてしまう(CPU時間とメモリを占有してしまう)から
マイクロスレッドで作り直した＝基本設計を大きく変更したというだけで、Rustだからパフォーマンスが向上したというわけではない

**デフォルトの名無しさん** · 2023/11/21(火) 16:18:31.31

stdをunsafeで検索するとUnsafeCellしか出てこなくて
unsafeな関数の名前がほとんどuncheckedなのは
let x = unsafe { do_something_unsafe() };
だとアホっぽいからかな

**デフォルトの名無しさん** · 2023/11/21(火) 18:24:54.78

検索方法が間違ってる
そしてuncheckedはunsafeとは意味が違う