Rust part26

**デフォルトの名無しさん** · 2024/09/20(金) 22:18:38.38

公式
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 part25
https://mevius.5ch.net/test/read.cgi/tech/1722354386/

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

**デフォルトの名無しさん** · 2024/11/14(木) 04:49:13.06

Claude ai 無料でも有能で笑った

**デフォルトの名無しさん** · 2024/11/14(木) 09:48:02.77

>>817
それはバージョン o1 だった？

**デフォルトの名無しさん** · 2024/11/14(木) 17:17:13.60

>>819
ChatGPTではなく、OpenAI o1 のことかいな?

**デフォルトの名無しさん** · 2024/11/14(木) 20:42:25.26

すまん、違うものだったか
孫さんの動画でGPTの次のバージョンのような扱いしてたので同じかと思ってた

**デフォルトの名無しさん** · 2024/11/16(土) 05:20:14.39

アメリカ政府が「安全な言語を強制する」姿勢は、
「規制」だね。それによりC/C++だけが排除される。
ずる賢い連中だ。日本の半導体もそれで駄目になった。

**デフォルトの名無しさん** · 2024/11/16(土) 06:03:12.01

>>822
C/C++のようなクズ言語は早く消えたほうがいい
今はZigやRustなど代替できる良い言語が色々ある

**デフォルトの名無しさん** · 2024/11/16(土) 06:40:57.58

時間ライブラリ、chrono使いにくいなーと思ってtimeに乗り換えたけど
メンテ状態がいまいちだし、変な仕様がいくつもあるなーと悩んでた

今日 jiff を見つけて試してみたら、とても使いやすい
設計のベースがjsのTemporalということもあり、変な独自仕様が少なそう
作者が有名人だし、今後も期待できる
ただちょっとバイナリサイズが大きめかな

**デフォルトの名無しさん** · 2024/11/16(土) 09:37:53.01

>>822
規制と言うより新陳代謝。
c/c++にいくら新機能入れても無理が来てる。
ライブラリの都合上まだ仕方なく使ってるけど。徐々に置き換わって行くよ。

**デフォルトの名無しさん** · 2024/11/16(土) 14:25:13.85

プロが一番使っている言語であるところのC/C++だけが、
アメリカ当局の鶴の一声で潰されようとしている。

**デフォルトの名無しさん** · 2024/11/16(土) 14:55:20.01

欠陥言語C/C++が一掃されるのは良いこと
無知と怠惰が欠陥言語にしがみつく

**デフォルトの名無しさん** · 2024/11/16(土) 15:50:00.42

市場やソフトウェア業界のプログラマや個々の経営者が決める
べきであり、政府が強制すべきではない。

**デフォルトの名無しさん** · 2024/11/16(土) 16:25:18.89

サイコパスは「痛みを伴う失敗」から学習できない！
2024.11.15
nazology.kusuguru.co.jp/archives/165730
「パワハラ上司が生き残る条件」みんな●●だった！
2024.07.12
nazology.net/archives/156599

**デフォルトの名無しさん** · 2024/11/16(土) 16:50:05.47

>>828
アメリカ政府は顧客のひとつとして Rust の積極的導入を要望しているのであって市場に対する規制なんてしてないよ。
結果的に影響力が大きくはあるけどな。

**デフォルトの名無しさん** · 2024/11/16(土) 16:59:51.39

>>830
「メモリー安全で無い言語は使うべきではない」
などと言ったそうだが。

**デフォルトの名無しさん** · 2024/11/16(土) 18:31:49.86

欠陥言語使わないといけない世界は改善したほうが良い

**デフォルトの名無しさん** · 2024/11/16(土) 18:48:21.70

>>828
別に法律で何時までにどうしろと決めたわけでもないので好きにすればいいけど、技術力が無い会社は置いてかれる、それだけの事よ。

**デフォルトの名無しさん** · 2024/11/16(土) 20:55:43.27

全盛を極めていたプログラミング言語たちが情勢の変化により落ちていった
今回はC++の番

**デフォルトの名無しさん** · 2024/11/16(土) 21:01:25.26

特定の言語使うことを技術力と思うのは勘違いな
たいした価値を生まない

**デフォルトの名無しさん** · 2024/11/16(土) 21:26:15.37

Rustの採用って実のところ、既存の資産を捨ててゼロベースで書く、キャッチアップのためにコストをかける (慣れてる言語よりも時間がかかることを許容する) とかの思い切りの問題だと思う

**デフォルトの名無しさん** · 2024/11/16(土) 21:37:25.08

それはそう。
C++ が良い言語ではないことに C++ の設計者は自覚的で、それでもなお「今」目の前にある問題に対処可能であることを理念にしてる。
まだ不十分だけど良い言語だなんてのは実務者にはなんの救いにもならない。
汚くてもなんとかする方法はあるほうがありがたい。
ただ、無限に汚くなり続けることは許容できないのだから、どこかで新しいものが生まれてリセットする必要はあって今がその時なんだろう。
でもまあ現実に使われるものは汚いものだよ。
だって現実が汚いものだから。
Rust もいずれ汚くなって次のなにかに置き換わる。
それが半世紀くらい後だとよいね。

**デフォルトの名無しさん** · 2024/11/16(土) 22:52:16.06

C/C++しか使えないダメ人間だと他の言語に手を出したり習得したりするハードルも高くそんなスキルもないんだな
普通に色んな種類の言語をやってきていればすぐに対応できるようになる

**デフォルトの名無しさん** · 2024/11/17(日) 00:10:11.34

C/C++ を「ちゃんと」使えているならかなり能力は高いはず。
あの無茶苦茶なのを把握してるわけだからな。
でもちゃんと理解せずに使っているやつもそれなりに多いのもそう。

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

アメリカ政府がRustが欠陥言語であることに気づいて無いだけだ。

**デフォルトの名無しさん** · 2024/11/17(日) 09:50:13.04

>>840
欠陥の無い言語教えれ

**デフォルトの名無しさん** · 2024/11/17(日) 10:45:30.77

RustはCの置き換えには最適だが
C++からRustはノーチャンス

**デフォルトの名無しさん** · 2024/11/17(日) 11:09:03.35

>>842
過去資産を除くと
C++の利点は無いと思う

**デフォルトの名無しさん** · 2024/11/17(日) 12:57:50.30

>>843
まあその過去資産がクソデカだって話なんだけどな。

**デフォルトの名無しさん** · 2024/11/17(日) 13:22:59.92

現実的なことを言うとRustの仕事は多くないからな
世の中的にはC++の方が多いし、それよりもC#やJava、JavascriptやPythonの方が多い
現状Rustを書ける人が少ないから組織としても採用しづらい、みたいなところもある

**デフォルトの名無しさん** · 2024/11/17(日) 14:04:38.06

Rustは欠陥が多すぎる。

**デフォルトの名無しさん** · 2024/11/17(日) 14:14:43.13

>>846
C++と比べても桁違いに欠陥ない

**デフォルトの名無しさん** · 2024/11/17(日) 14:17:04.13

>>342
>RustはCの置き換えには最適だが
そんなことない。むしろ置き換えに適さない。

>>843
そんなことない。

**デフォルトの名無しさん** · 2024/11/17(日) 16:20:28.69

Rust に (まだ) 足りないものはあるという意味では欠陥はあるが、設計が間違ってて改善の余地がないような欠陥は少ないだろ。
C の場当たり過ぎる設計に比べれば Rust はだいぶん綺麗だわ。

**デフォルトの名無しさん** · 2024/11/17(日) 17:47:06.07

C++は多段に増築して要らないものも多く
新しい仕様は良いけど広まっていなくて
標準ライブラリのインターフェイスを新たな仕様にすることもできなくて
初心者にとってC++はRustの何倍も複雑で学習難易度も高いのよ
Rustはシンプルに高機能でプログラミング効率もいいね

**デフォルトの名無しさん** · 2024/11/17(日) 21:11:05.44

C++はBoostあたりまでは良かったけどそれ以降は機能のゴミ箱
上品な言い方をすればキッチンシンク担当になった

**デフォルトの名無しさん** · 2024/11/17(日) 21:56:59.22

>>849
そうでもない。

**デフォルトの名無しさん** · 2024/11/17(日) 22:25:57.84

mordern c+で随分楽になったけど

**デフォルトの名無しさん** · 2024/11/17(日) 22:26:17.33

modern

**デフォルトの名無しさん** · 2024/11/17(日) 22:37:46.32

CをRustで置き換えたら劇遅になるから重要な部分は無理じゃね

**デフォルトの名無しさん** · 2024/11/17(日) 22:55:33.70

>>855
デバイスドライバを両方で実装して速度がほぼ変わらないことが立証されている

**デフォルトの名無しさん** · 2024/11/17(日) 23:02:46.96

>>856
それは、一般にデバイスドライバはシンプルなアルゴリズムしか使ってないからだよ。

**デフォルトの名無しさん** · 2024/11/17(日) 23:11:47.34

同じアルゴリズムでRustが遅い例プリーズ

**デフォルトの名無しさん** · 2024/11/17(日) 23:14:29.54

>>858
unsafeを使わない限り、ほとんどのアルゴリズムがそれに当たる。
なぜなら、ほとんどのアルゴリズムが使えないから。

**デフォルトの名無しさん** · 2024/11/17(日) 23:19:43.73

>>859
ウソつき

**デフォルトの名無しさん** · 2024/11/17(日) 23:25:29.83

安全側に寄せる部分でRustの方が基本的にコストかかるんじゃないの？
グローバルな可変状態はMutexが無いと書けない (アクセスの度にロックが必要) とか、Cellは実行時に借用チェックするとか、配列は基本的に範囲チェックされるとか

コンパイラは利用側を知り得ない (複数スレッドから呼ばれる可能性があると想定せざるを得ない) からMutexが必要だけど実際は無いと想定して良い、みたいなケースはありそう

**デフォルトの名無しさん** · 2024/11/17(日) 23:28:19.03

>>860
あなたも含めたここの連中は理解力が低い。
なお、俺には丁寧に説明する義務は無い。理解できない人はそのままでいい。
俺には関係無い。

**デフォルトの名無しさん** · 2024/11/17(日) 23:34:51.20

>>859
unsafe使えば同等になるなら、どこかの誰かさん以外はRustが遅いとは思わないのでは？
とりま、unsafe使わない遅いコードさらしてみては？

ここの優秀な方々が「unsafeでもこうすればCと同等の速さだ！」ってコードを返してくれるかもしれん。

**デフォルトの名無しさん** · 2024/11/17(日) 23:37:27.94

>>861
そこはどの言語でも同じ
スレッドローカル変数を使う
RustでもMutexの必要はない

**デフォルトの名無しさん** · 2024/11/17(日) 23:41:13.09

他のレスに「あなたは正しくない」とだけ書けば自分が賢いということになるなら、それほど楽なことは無いな
スマホさえ持ってれば小学生でも同じことはできるわけだし

**デフォルトの名無しさん** · 2024/11/17(日) 23:53:16.59

100点オジと複オジはいつまでたっても進歩がないな

**デフォルトの名無しさん** · 2024/11/18(月) 00:24:33.99

基礎的なデータ構造に unsafe が必要になるのは本当だ。
基礎は std で提供されるのでその上では unsafe の仕様が少なくなるように巧妙に設計されている。
std を使えないときに std と同等なものを作らなければならないような状況だと C とあまり差はない。
逆に言えば unsafe を含む下回りをかっちり作りさえすれば Rust のほうが優秀だよ。

**デフォルトの名無しさん** · 2024/11/18(月) 02:14:46.19

あゝこんなときRustにもextern "C"があれば平和が訪れるのに

**デフォルトの名無しさん** · 2024/11/18(月) 04:44:45.38

>>840
「欠陥のない言語は存在しない。だがデバッグの不可能な言語もまた存在しない」

**デフォルトの名無しさん** · 2024/11/18(月) 07:01:58.78

おれの作った言語はデバッグ機能ないけど？

**デフォルトの名無しさん** · 2024/11/18(月) 07:06:12.01

【ナゾロジー】サイコパスは「痛みを伴う失敗」から学習できない！ [すらいむ★]
http://itest.5ch.net/egg/test/read.cgi/scienceplus/1731838156

**デフォルトの名無しさん** · 2024/11/18(月) 08:33:03.50

>>868
あるやる

**デフォルトの名無しさん** · 2024/11/18(月) 09:04:25.28

>>867
>逆に言えば unsafe を含む下回りをかっちり作りさえすれば Rust のほうが優秀だよ。
そんなことない。
unsafeがライブラリ関数の外に染み出てくるから。

**デフォルトの名無しさん** · 2024/11/18(月) 09:13:51.03

>>865
ここに書かないのは、「企業秘密的」な意味も有るんだよ。

**デフォルトの名無しさん** · 2024/11/18(月) 09:30:27.68

>>862
競プロでもやってんの？

**デフォルトの名無しさん** · 2024/11/18(月) 09:41:47.81

>>873
RustがC/C++に勝利した一番大きな要因は
メモリ操作など基本的にunsafeにたどり着く様々な操作を
中身でunsafeを使っていてもそれを外へ染み出さないsafeなインターフェイスを提供して実用的に使えることを示した点にある
これがRustの標準ライブラリの中核であり
同様にしてunsafeが外へ染み出さないsafeなライブラリを作ることもできる

**デフォルトの名無しさん** · 2024/11/18(月) 10:43:14.43

>>876
馬鹿発見。

**デフォルトの名無しさん** · 2024/11/18(月) 12:57:29.84

>>873
unsafeの何が悪い
unsafe{
下回りもunsafe
利用者側もunsafe
皆で使おうunsafe
}

**デフォルトの名無しさん** · 2024/11/18(月) 13:58:30.56

unsafeが染み出すとか言っているの本気？
意図的に出さないと出てこないよ？

// 意図的なunsafe
pub unsafe fn dangerous_operation() {
// 何らかの危険な操作
}

// 利用者側
unsafe {
dangerous_operation(); // ここでunsafeが必要
}

普通はこう書く

// ライブラリ側
pub fn safe_wrapper() {
unsafe {
// 内部で危険な操作を行うが、
// 安全性を保証する条件をすべて満たしている
}
}

// 利用者側
safe_wrapper(); // unsafeは不要

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

>>877
事実を目の当たりにして具体的な反論や反例を出せない気苦労は理解するが
それでも具体的にRustのコードを示すのがよいかと

**デフォルトの名無しさん** · 2024/11/18(月) 21:05:40.46

>>874
説明は求めないけどね？
「自分は知ってるが説明する義理はない」なんて第三者からみれば「俺は分かりません説明できないです」と書くのと変わらないじゃない
分からないならスルーすればいいのに、それをわざわざ書くのはダサくない？

**デフォルトの名無しさん** · 2024/11/18(月) 21:41:56.71

実際にはunsafe使わないRustはCよりもいくらかオーバーヘッドが生じるとは思う
Cでなポインタのコピーで済むけどsafe RustだとArcが必要だからcloneの際にロックのコストがかかるとか、配列へのインデックスでのアクセスで境界チェックされるとか
Rustでは安全側に寄せる分のコストはかかるはず

**デフォルトの名無しさん** · 2024/11/18(月) 21:52:16.61

>>882
本当に各チェックを安全に外せる場合
つまり安全なインターフェイスを提供できる場合
Rustでもそれを安全なライブラリとして提供すればよいですね
実際にそのようにしてRustの標準ライブラリが作られて来ていますから

**デフォルトの名無しさん** · 2024/11/18(月) 22:05:29.90

>>879のコード例だと本当はアウトなのに屁理屈でセーフという俺ルールでねじ曲げてるだけに見える
それunsafeやない、アウトや！

**デフォルトの名無しさん** · 2024/11/18(月) 22:35:51.22

計測して本当にunsafeにする価値がある部分だけ暴走覚悟でunsafeにすればいい
満たさないと危なくなる条件はdebug_assertしておくと気休めになる

**デフォルトの名無しさん** · 2024/11/18(月) 22:46:47.54

＞いくらかオーバーヘッドが生じるとは思う
そんなレベルじゃないだろｗ

**デフォルトの名無しさん** · 2024/11/18(月) 22:49:05.04

>>882
安全のためのオーバーヘッドはどちらの言語も同じです

Rustも&TならばCopy実装型なのでコピー出来ますからC言語と同じです
Arcのcloneはロックフリーです
ロックされるのはその中で用いるMutexなど
C言語でも排他制御が必要なところではMutexが使われます
ヒープを使うデータをポインタで指す人数が変化していくならば最後の人が解放するためにリファレンスカウント管理が必要です
実際にC++ではそれがshared_ptrとしてArcと同様なものが提供されています

**デフォルトの名無しさん** · 2024/11/18(月) 22:53:38.18

よかった、RustとCではオーバーヘッドは同じがRustの方が少ないんだね

**デフォルトの名無しさん** · 2024/11/18(月) 22:59:47.77

前提条件大杉

**デフォルトの名無しさん** · 2024/11/18(月) 23:17:10.99

>>888
複おじ、幼稚すぎｗ

**デフォルトの名無しさん** · 2024/11/18(月) 23:40:55.05

Rc相当がなくArc相当のshared_ptrしかないC++はオーバーヘッドが大きい

**デフォルトの名無しさん** · 2024/11/18(月) 23:52:07.17

C++でポインタいじってる時も特定の前提条件の時まともに動くだけで、そこから外れたらすぐバグるから。安全性のレベルを合わせたら結局どちらも同じようなコードになるよ。条件チェックしてるのとしてないのを比較して速い遅い言われても。
あと、rustの方が型で前提条件弾いて全域関数を作りやすいから。下手なC++よりは最適化される場合もある。何にせよ最初ほ安全に振っておいて、そこからプロファイラかけて遅いところだけ変えて行くほうがいいと思うけどね。

**デフォルトの名無しさん** · 2024/11/19(火) 00:32:35.22

参考までに聞きたいんだけど、画像処理みたいなタスクってunsafe無しでもC/C++と同等の速度を出せるの？
フィルタのように周辺画素の値を使う処理や、処理対象の画素 (もしく行) を複数スレッドに分割するような処理を想定してる

自分の知識だと、可変かつマルチスレッドのような場合はsafe Rustだと難しい気がしてる
unsafeを使うなら、オーバーラップしないように範囲を分割して、そのポインタを渡して処理させることはできるけど、safe Rustだと可変借用のルールが問題になる気がしてる
それこそunsafeを使うべき場面だというなら納得するし、safe Rustでもうまくやれるなら知っておきたい

**デフォルトの名無しさん** · 2024/11/19(火) 00:50:32.75

>>893
rayon crateというデーター並列処理のライブラリを使う。チャンクに分割されたパラレルイテレータを回すだけ。フィルター処理とかは割と簡単。

**デフォルトの名無しさん** · 2024/11/19(火) 01:54:46.13

use image::{ImageBuffer, Rgb, RgbImage};
use rayon::prelude::*;

fn to_grayscale(img: &RgbImage) -> RgbImage {
let (width, height) = img.dimensions();
let mut output = ImageBuffer::new(width, height);

output.par_chunks_mut(3).zip(img.par_chunks(3)).for_each(|(out, pixel)| {
// RGB to グレースケール変換の重み付け
let gray = (0.299 * pixel[0] as f32 +
0.587 * pixel[1] as f32 +
0.114 * pixel[2] as f32) as u8;

out[0] = gray;
out[1] = gray;
out[2] = gray;
});

output
}

fn main() -> Result<(), image::ImageError> {
let img = image::open("input.jpg")?.to_rgb8();
let gray_img = to_grayscale(&img);
gray_img.save("output.jpg")?;
Ok(())
}

**デフォルトの名無しさん** · 2024/11/19(火) 02:09:20.81

サンプル書いてみた。
RGB画像をグレースケールに変換する。
imgが入力画像、outputが出力画像のバッファ。
イテレータで回してクロージャー呼んでる。

per_chunks_mut、per_chanksでチャンクのサイズ指定。今は1ピクセルrgbで3バイトずつ取り出してクロージャーの引数として渡される。スレッドの並列処理は自動で行われてる。
例えばチャンクサイズをwidth×3とかにすれば1ラインずつデータが渡される。width×3×2とかにすれば2ラインずつ。ある程度のサイズにしたほうが高速になる。
チャンクのサイズを変えたらクロージャーの処理も変えるのを忘れずに。

**デフォルトの名無しさん** · 2024/11/19(火) 02:14:25.94

これをC++で書けと言われたらやりたくない。
rustなら安全で分かりやすく書けるし、イテレータは並列処理の最適化が効く。

**デフォルトの名無しさん** · 2024/11/19(火) 07:54:11.15

rayonが出たついでの質問なんだけど、rayonのイテレーター (par_iterなど) ってグローバルなスレッドプールでなく、ThreadPoolBuilder::build で作ったスレッドプール上で実行できる？
以前調べた際によく分からなかった

**デフォルトの名無しさん** · 2024/11/19(火) 08:24:41.51

ところでこのスレって業務で実際にrust使ってるよーって人います？

**デフォルトの名無しさん** · 2024/11/19(火) 08:27:40.98

スレッド数を自分で設定したいって意味でいいのかな？
rayon::ThreadPoolBuilder::new().num_threads(8).build_global().unwrap();

**デフォルトの名無しさん** · 2024/11/19(火) 08:32:14.22

use rayon::ThreadPoolBuilder;

// カスタムスレッドプール作成
let pool = ThreadPoolBuilder::new()
.num_threads(4) // スレッド数指定
.build()
.unwrap();

// スレッドプールで特定の処理を実行
pool.install(|| {
output.par_chunks_mut(row_size)
.zip(img.par_chunks(row_size))
.for_each(|...| {
// 処理
});
});

**デフォルトの名無しさん** · 2024/11/19(火) 14:47:04.76

>>892
>下手なC++

templateですね判ります

**デフォルトの名無しさん** · 2024/11/19(火) 15:24:29.64

>>897
なんで主語がrustとc++なの？
便利なライブラリがあるってだけでしょ？
c++でも同様のライブラリを作るのは可能だと思うけど

**デフォルトの名無しさん** · 2024/11/19(火) 15:42:39.43

Rustが勝利した原因はrayonやtokioなどのマルチスレッドを便利に安全に活かすライブラリの存在が大きいが
C/C++は数十年の年月を重ねてもそれに匹敵するものが完成しなかった

**デフォルトの名無しさん** · 2024/11/19(火) 16:37:47.00

>>903
発端はrustでc++みたいなフィルター処理書ける？って話。c++でも書けるかもしれんが自分は面倒なんで誰かコード書いてくれ。

**デフォルトの名無しさん** · 2024/11/19(火) 22:42:01.95

>>901
ありがたい
やりたいのは「明示的に指定した場合のみ並列処理をする」プログラムで、データとしては Option::ThreadPool みたいなものを持ってるから、その中で実行したいという話

よく分かってなかったのは install の動作で、これに渡したクロージャーはプール内のスレッドで実行されると思ってたから、例えば4スレッドの場合に「スレッド1がpar_chunksを含むコードを呼びだす、それを受けてスレッド2-4が並列実行する (スレッド1はinstallに渡したクロージャの終わりでブロックされる) 」みたいなことになったりしないか…って思ってた
(公式のリファレンスは Executes op within the threadpool. という説明)

問題なさそうなら使わせてもらいます

**デフォルトの名無しさん** · 2024/11/19(火) 22:46:22.71

C++で並列とかようやらんわ
SendもSyncもないとかもう考えられん

**デフォルトの名無しさん** · 2024/11/19(火) 22:49:56.47

違うかも？
>>906 のスレッド4つの例だと、クロージャー自体はプール内のスレッド(スレッド1とする) で実行されて、スレッド1はpar_iterで並列処理を開始した後すぐ抜けて par_iter の仕事に加わるということ？

**デフォルトの名無しさん** · 2024/11/20(水) 00:33:04.50

例えばスレッドプールを4で設定するとワーカースレッドが4つになります。でそれとは別にメインスレッドがあるわけで、このパラレルの処理をするときはメインスレッドもワーカーとして参加します。なので5個で回る感じ。

**デフォルトの名無しさん** · 2024/11/20(水) 00:36:52.89

pool.installとpool.scopeでメインスレッドがワーカーとして参加するかしないかが変わるみたい。

**デフォルトの名無しさん** · 2024/11/20(水) 00:42:34.33

>>907
C++にasyncがあるぞ。

**デフォルトの名無しさん** · 2024/11/20(水) 00:47:56.81

いずれにせよパラレルイテレータを回しているときは処理が終わるまで待つことになるんで、メインスレッド止めたくないときは別スレッドで立てる感じ。
fn non_blocking_example() {
let (tx, rx) = mpsc::channel();

std::thread::spawn(move || {
let pool = ThreadPoolBuilder::new()
.num_threads(4)
.build()
.unwrap();

pool.install(|| {
// 並列処理
});

tx.send("Done").unwrap();
});

// メインスレッドは他の処理を継続可能
println!("Doing other work");

// 必要なタイミングで結果を受信
match rx.recv() {
Ok(msg) => println!("Processing complete: {}", msg),
Err(e) => println!("Error: {}", e),
}
}

**デフォルトの名無しさん** · 2024/11/20(水) 01:09:41.69

>>911
asyncは全然別の話。
rustでは型に対してsendやsyncといった属性を付けるようなイメージ。sendが付いてなければ別スレッドにデータ渡せないとかsyncが付いてなければ同時に使えないとか、そういうスレッド対応してないものを使うとコンパイラに怒られる仕組みになってる。

**デフォルトの名無しさん** · 2024/11/20(水) 08:50:31.70

>>912
詳しい説明ありがとう
scope と install については自分でもちょっと調べてみます

**デフォルトの名無しさん** · 2024/11/20(水) 09:59:28.14

最近のCPUは速過ぎるから第三者から見れば「速さ」は見えない
バグなら見える

それで無人の機械で速さを計測するから
第三者などという人間は不要だと分かる

**デフォルトの名無しさん** · 2024/11/20(水) 11:26:15.05

Cが早くてRustが劣っていると仮定して
その差が問題なることなんてない
自分では何も生み出せないベンチ回マニアくらいだろ

**デフォルトの名無しさん** · 2024/11/20(水) 12:43:18.25

>>914
フィルター系のプログラムだとCPUのSIMD命令がかなり効くと思うんでそちらも検討するといいかと。
コンパイラが自動でやってくれる可能性もあるけど、明示的に書くと確実。
標準だと std::simd がそのうち実装される予定。
その他クレートもあるんで探してみて。