Rust part38

公式
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/
（コミュニティによる日本語翻訳版もあります: https://doc.rust-jp.rs/book-ja/）

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

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

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

前スレ
Rust part37
https://mevius.5ch.io/test/read.cgi/tech/1784283151/

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

>>892
それだと非同期機構が関与してない

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=c97f4c4b1a3a952e5ac727c78bf8ffa3

なんかStreamってあったよなってヒントを与えつつローカルのQwen3.8に書かせてみたけどこんな感じでよか？

C++のそのco_yieldもそれだけでは非同期スケジューリングされる非同期タスクは生成されないぞ

>>894
これいい感じ

>>895
894も882と同じだし
言語毎に非同期機構のデフォルトがeagerがlazyか違うのでそこは関係ないかと

>>882
そのC++のコードのどこに非同期性があるんだよ
全て同期だ

>>897
>>896

非同期機構を使って書いたコードが実際にawaitなどで非同期タスクスイッチが起こるかどうかはこのベンチマークの主眼じゃないかと

>>893でRustのコードに対して非同期機構が関与してないと指摘してるようだが
C++のそのコードも同期のみで同じ

>>899
もう面倒なので自分で勉強してね

C++は非同期ランタイムの標準化に失敗して先送りになったままだったと思う
std::executionが決まらないとC++では無理かと

>>901
どうぞ
https://github.com/nvidia/stdexec

>>902
その非同期スケジューラーを使って非同期に書くといいんじゃね

コルーチンの比較ベンチで非同期かどうかは関係ないような
グリーンスレッドが標準化されてない環境だと重たくなるのはしかたない
RustはTokioがデファクトだからまああり

ID:nl5zGx1zの書き込みを見てると非同期に書いたつもりになってるようだけど非同期になってないですよね

>>905
だから勉強しなさいって

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=9a70f86f7c3c8f25cf743142489b882f

yieldで書きたければ今のnightlyだとこれくらいまではできるみたいね
gen {}はなんかCoroutine実装してないとか言われてだめだった…

単なるコルーチンだな
構成要素の一部にはなり得るけど非同期とは別

>>907
いいね
この人と>>904が話が通じる

coro-prime-sieveって名前のベンチにコルーチンで実装するなとか言うバカ

そうだよ
課題はコルーチン
ID:nl5zGx1z氏が非同期とコルーチンの区別をできなくて何度も非同期がー！と喚いているから話がややこしくなってる

>>911
非同期機構(C++ではcoroutineとpromise_type, awaiter)と
非同期実行を混同してるやつ>>905に説明したけど無理そうだった

コルーチンは非同期機構ではない
非同期機構の実装の一つとしてコルーチンが使われることもある
という程度の関係しかない
同様の関係として
イテレータの実装の一つとしてコルーチンが使われることもあるが
イテレータとコルーチンは別ものである
そして互いに相手を必須とするものではない
非同期機構とコルーチンも別ものである
そして互いに相手を必須とするものではない

コルーチンで作られたジェネレータも同様だよね
どちらも非同期機構とは違う
>>882のC++プログラムはコルーチンで作らたジェネレータではあるけど非同期機構は出て来ていないね

Rustのジェネレータが安定化されていたらもう少しくらい話が通じたのかもしれない

>>915
Rustでyieldを使うジェネレータfeatureは状況が変わって再構築と名前が変更されてコルーチンfeatureになったよ
いずれにせよ非同期は直接関係なくてRustでもコルーチンはasyncではない普通の関数

RustよりもC++よりテクニカルライティングよりも会話を勉強したほうがいい

>>869>>870
草ｗ草ｗおじ草ｗ

Rustでグローバル変数と言えばstatic変数のこと
現代の言語はCのようにグローバルスコープの変数を直接定義できないから
Rustに限らず多くの言語でモジュール/ファイル/パッケージレベルでグローバルな変数を
単にグローバル変数と呼ぶようになってきてる

C言語時代の古臭い脳にそろそろパッチあてたほうがいいんじゃないかな

>>918
いやRustでもグローバルな可視性を持つ変数とプログラム全体にわたるライフタイムを持つ変数は区別するよ
最近の言語でグローバル変数というとそのどちらも十分条件ではなくて、
pub staticやシングルトンのように実質的にグローバル変数のように使用できるもの全般を指すケースが多いと思う
特定の概念を指すというよりユースケースを指す言葉だね

>>919
In Rust, global variables are called static variables.
https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html

static: Global variable or lifetime lasting the entire program execution.
https://doc.rust-lang.org/book/appendix-01-keywords.html

2つ目の説明の前者はstatic変数(=グローバル変数)のこと
後者は'staticライフタイムのこと

ほな「static変数はグローバル変数ではありません」やないやないか

> Rust considers mutable static variables to be unsafe.
> Where possible, it’s preferable to use the concurrency techniques and thread-safe smart pointers

世間的なグローバル変数はつかうなとあるのに話するのも無駄
記憶から消してほかのことに頭をつかおう

>>920
英語が読めないの？
グローバル変数はRustではstatic変数と呼ばれるだけだよ
static変数全てがグローバル変数というわけではない
明確にするために集合で表すと「static変数⊃グローバル変数」
例えば関数内のstatic変数をグローバル変数と呼びません
static変数 ≠ グローバル変数 です

bookの作者の人そこまで考えてないと思うよ

static変数のうちpubが付いてるものはパスさえ分かればアクセスできるからグローバル変数と呼んでもいいけど
static変数の多くは関数内やモジュール内に閉じてる用法
static変数とグローバル変数は別物ですね

そもそもの話が、>>831のコードのように関数ローカルやモジュールローカルのstatic変数に入れることで&'static参照を得て、スレッド内やスレッド共有で使う話でしょ。
そこにはグローバル変数と呼べるstatic変数は出て来ない。
それに対して、突如グローバル変数と言い出した>>868の理解不足だと思うよ。

お爺ちゃんたち必死過ぎて草ｗ
現実を直視する脳細胞が死んでるｗｗ

同じ構造体の自己参照で'static偽装したことはあるな

struct Foo {
full: String,
part: &'static str // -> &self.full[range]
}

外に見せる時に&'a selfの'aで抑えれば問題ないけど
誰か（AI）が間違って&'staticで公開するリスクがあるから
今だとアンチパターンか

>>907
そのresume()周りのごちゃごちゃしてる部分
既存のメソッド二つnext(), into_iter()定義したらシンプルになったよ
既存の関数名変数名などはそのまま

type Gen<T> = Pin<Box<dyn Coroutine<(), Yield = T, Return = ()>>>;

fn prime_generator() -> Gen<usize> {
Box::pin(#[coroutine] || {
let mut g = generate();
while let Some(prime) = g.next() {
yield prime;
g = filter(g, prime);
}
})
}

fn generate() -> Gen<usize> {
Box::pin(#[coroutine] || {
for i in 2.. {
yield i;
}
})
}

fn filter(g: Gen<usize>, prime: usize) -> Gen<usize> {
Box::pin(#[coroutine] move || {
for i in g.into_iter() {
if i % prime != 0 { yield i; }
}
})
}

>>928
うっかりムーブしちゃうと壊れるというのもあるのでpinを使うのじゃ
https://doc.rust-lang.org/std/pin/index.html
https://tech-blog.optim.co.jp/entry/2020/03/05/160000

>>929 メソッド定義と残り
#![feature(coroutines, coroutine_trait, yield_expr)]

use std::ops::{Coroutine, CoroutineState};
use std::pin::Pin;

// due to orphan rule
trait CoroutineExt: Coroutine<(), Return = ()> + Unpin + Sized {
fn into_iter(mut self) -> impl Iterator<Item = Self::Yield> {
std::iter::from_fn(move || self.next())
}
fn next(&mut self) -> Option<Self::Yield> {
match Pin::new(self).resume(()) {
CoroutineState::Yielded(n) => Some(n),
_ => None,
}
}
}
impl<C: Coroutine<(), Return = ()> + Unpin + Sized> CoroutineExt for C {}

fn main() {
let n = std::env::args_os()
.nth(1)
.and_then(|s| s.into_string().ok())
.and_then(|s| s.parse().ok())
.unwrap_or(100);

for prime in prime_generator().into_iter().take(n) {
print!("{prime} ");
}
println!();
}

このアルゴリズムだとn個の素数を求めるためにそれ以前のn-1個の素数で割っていくコルーチンが同期的に次々と並行に走るから
そのためのBoxもn-1個確保されてそのメモリ上で各コルーチンが動くことになるね

Rustってクソめんどくさいんだね

どこが面倒くさい？

このアルゴリズムは2で割るコルーチン、3で割るコルーチン、5で割るコルーチン、…とマトリョーシカのように入れ子状にコルーチンが増えていく
どの言語でも陽に暗に次々と各コルーチンのためのメモリを確保していきながら動作する点は同じではないかと思われる

Rustはスタック以外にメモリを確保するなら明示的に書くことでコードを明瞭化させる方針の言語
プログラム>>929でRust固有な部分はBox::pinでメモリを確保するところ
その内側のコルーチン記述は他の言語と同じ

素数10000個求めたいなら9999個のコルーチンが入れ子になって動くんだろ
遊びや実験ならともかく現実問題としては悪手なコード

話の流れとしてはこうだよな
元コードは>>887にあるPythonコード
そのアルゴリズムのままC++に移植したコードが>>882
そのアルゴリズムのままRustに移植されて整理されたコードが>>929

Rustで書き直されてやっと理解できたからって1日遅れで急に仕切り出したぞ

トイプログラム好きだな

面倒ってBoxでくるむだけだろ

Boxが必要になるのは入れ子になる時や異なる型を同じ扱いにするためdynを使う時のみだよ
そうでない普通のコルーチン返すならこれだけ

fn count_up() -> impl Coroutine<Yield = usize> {
let mut counter = 0;
#[coroutine] move || {
loop {
yield counter;
counter += 1;
}
}
}

中身はコルーチンそのままでコルーチンであることを露出させずにイテレータとして見せる時はこう書けば動くね

#![feature(gen_blocks)]

fn count_up() -> impl Iterator<Item = usize> {
let mut counter = 0;
gen move {
loop {
yield counter;
counter += 1;
}
}
}

中でローカル変数の参照が保持されるならアドレス固定（pin）必須では
実行時のスタック位置が不定になるのは非同期と一緒でしょ

>>944
コルーチンを定義する側ではpin不要
コルーチンを利用する側ではresumeがpin必須
コルーチンをイテレータのインターフェースで利用するなら>>931のようにpinとresumeは内部に隠蔽されるためpinは出て来ない
したがってコルーチンをgenブロックの形で使えば定義する側でも利用する側でもpinとresumeは隠蔽されて出て来ないことになりそれがgenブロックの目的なのかと

んわけあるかｗ

coroutineをstaticにすることで解決できる
困ったときはstatic

&'static str なんて定数なんだからグローバル変数などと呼ぶな

定数ではなく実行時に決まる値をstatic変数に格納すると&'static参照を得られるというRustの基本の話だろ

staticおじさんとバカにされるから &'static は使わない方がいい

プログラム終了まで変化しない値はstatic変数に入れるのが最善策
ファイルから読み出すデータであっても通信で得られる値であっても計算で算出される値であっても同じ

>>938
コード3つとも読んだがコルーチンの同期呼び出しとイールドしかないな
非同期ではない

>>928
struct Foo<'a> {
full: &'a String,
part: &'a str // &self.full[..]
}
これでも面倒じゃないし大して違わんと思う
なぜ敢えて &'static str 使いたがるのか

そもそもasyncやコルーチンってまだ必要なのかねえ
今はまだAIのRLHFの過程で人間にとって分かりやすいコードを書くように教育されてるけど、その重要性は人間がコードを見なくなるにつれて確実に下がっていくわけで、
いずれそういう頭悪い人間のための補助器具的な機能は全く使われなくなりそうだ

分かり易さというのは主に複雑さを抑えることだ。
それは AI にとっても有利な条件になりうる。
(変数名の付け方なんかは人間固有の性質かもしれんが。)
複雑さを抑える方法論を全く無視したら必要な計算量が一気に爆発して手に負えないよ。
計算量の爆発ってのは百倍とか万倍とかいうレベルじゃなくて無量大数倍とかそれよりもっとのレベルで差が出たりする。
(だから巨大なシステムを AI ならたとえばアセンブラで余裕で作れるってわけではない。)

もちろん人間向けが AI 向けに常に有用なわけじゃないだろうけど分かり易くするという指針は AI 向けにも意味がある。

>>954
直バイナリ論者ですか？

railsの偉い人が、もうAIにRust書かせればええやんと発言したらしいな

Rustで修行した結果一周回って安全にCもC++もunsafe Rustも書けるようになった
そう言える境地を目指したい

割と好き、遠回りする人
近くに環境設定職人とかがいると助かるし

人はわかってても間違うものなので理解できたら安全に書けるというものではない。
もちろん目指す自由はあるし目指す過程で身に付くことは無駄ではないだろうけどさ。

>>954
asyncが何かもわかっていなさそうだな

>>961
同等な状態マシンと周辺コードを書けば不要ってことでしょ
実際は>>955のとおりそうでないけど

下のcoro_fibが実行時にシングルスレッド非同期スケーリングやマルチスレッドスケーリングが発動するかは
Task<T>の実装しだいなのであって、コルーチンと言う機構を用いて「非同期」を抽象化しているのよ

Task<size_t> coro_fib(size_t n) {
if (n < 2) co_return 1;
co_return co_await coro_fib(n - 2) + co_await coro_fib(n - 1);
}

こう書いたら実行も再帰コールになるけど
size_t fib(size_t n) {
if (n < 2) return 1;
return fib(n - 2) + fib(n - 1);
}

coro_fibの方はTaskの実装次第でシングルループ化させることが出来るわけよ

>>962
非同期の極一部のawaitを実現する方法の一つとして状態マシンを使うという程度の関係しかなくない？
pollの状態は各外部に左右されるものであるし

>>963
非同期の実装の方法としてコルーチンを使う場合もあるというだけにすぎない
コルーチン自体には昔から非同期の機能はありません

コルーチンはサブルーチンと対になる位置づけ
サブルーチンが毎回最初から実行するのに対して
コルーチンは前回戻った地点から実行するそれだけの違い
どちらも普通のものは同期的に実行される

昔話をされても困るな
少なくともC++20以降の視点が無いとね

co_await resume_background();
(ここはスレッドプールで実行)
co_await resume_foreground(..);
(ここはメインスレッドで実行)

それはC++という変わった変な言語の混乱
一般的なコルーチンの話がなされている場で邪道なものを持ち出すのは愚かとしか言いようがない

言語毎の違い包括して元素還元したのがC++20

>>967
おまえバカだろ
コルーチンにawaitなんて機能はない
awaitが登場するのはどの言語でも非同期の機能
両者の区別もできないのか？

こう言う>>966 表素的な把握だとyieldとawaitが不可分だとは想像できないかも

>>971
それはレイヤーが全く異なる
Rustでは非同期関数の内部実装としてスタックレス・コルーチンが使われているが
階層が異なるため内部実装にすぎないコルーチンが直接露出することはない
きちんと区別されている

どの言語でも、とは...

少なくとも現状の主要言語で
suspend可能ポイントでsuspendするかしないか
suspendしたらなにをするか
resumeしたらなにをするか
yieldで戻り値を受け取る仕組み( new_input_from_caller = co_yield value )
これらを制御出来るのはC++しかないわけで良い学習になると思うよ

>>929とかのコードは途中でsuspendする必要全然ないから同じアルゴリズムでもコルーチン使わないイテレータ版で十分

>>975
それはみなが承知してるが
コルーチンを使って書けという課題らしい

>>975
イテレータとの折衷案はいかが
一応coro-prime-sieveと書かれているから
yieldを使うコルーチンを使って
篩法で実装されていればいいと解釈すると
これがシンプルでよいかと

fn prime_generator() -> impl Iterator<Item = usize> {
gen {
let mut primes = Vec::new();
for i in 2.. {
if primes.iter().all(|&prime| i % prime != 0) {
primes.push(i);
yield i;
}
}
}
}

>>977
それは綺麗だけど
原型のGoが各素数に付き一つのチャンネルを割り当てているから却下かと

>>978
Goってこれかい？
https://github.com/hanabi1224/Programming-Language-Benchmarks/blob/main/bench/algorithm/coro-prime-sieve/1.go

チャネル通信を使っていて本来のコルーチンから大きく逸脱しているような

チャネル使わないと却下だったら最初の書き味がどうとかいう問題提起は何だったんだんだよｗ

書き味って検索するとこの件の一番最初の>>882の書き込みのことか
Rust版はGo版に倣ってチャネルで実装してるから合格？
C++版はチャネルを使ってないから却下？

書き方間違えた
原型のGoが各素数に付き一つのゴールーチンを割り当てているから却下かと

それならまあはい

性能面が悪化しても読みやすくなるとかアルゴリズムがシンプルになるとか何かメリットがあるならまだいいがデメリットしかないやり方をあーだこーだいっても時間の無駄じゃね？

何がそんなにうれしいの？

引くに引けなくなっちゃったんでしょ

このベンチはコルーチンを使う事での性能劣化やそれを緩和する最適化を見る為かと
劣化がゼロなんてことは無いよ
.net10のruntime asyncもその辺の最適化かと

このスレ、こんなのばっかだな

>>947
それマジでコンパイル通らないコルーチンにstatic指定したらコンパイル通るようになった
参照&aがyieldまたぎして使われてるこれ
static指定なしだとコンパイルエラー
static指定ありだとコンパイル通る

fn foo() -> impl Coroutine<Yield = ()> {
#[coroutine] static || {
let a = 123;
let pa = &a;
yield ();
if *pa == 123 {
yield ();
}
}
}

Rust part39
https://mevius.5ch.io/test/read.cgi/tech/1790267803/

何勝手に立ててんの？ なんでID全部違うの？

>>988
全ての正解はstaticに通じる

>>1
>（コミュニティによる日本語翻訳版もあります: https://doc.rust-jp.rs/book-ja/）

（コミュニティによる日本語翻訳版もありますがもう更新されていませんので日本語が必要なら公式版をAI翻訳して読むことをお勧めします: https://doc.rust-jp.rs/book-ja/）

次スレから↑これな