Rust part20

**デフォルトの名無しさん** · 2023/03/03(金) 00:45:28.73

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

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

**デフォルトの名無しさん** · 2023/04/09(日) 01:36:27.91

もしかしてこういうこと？
let mut v = Vec::new();
v.push("first".to_string());
let first: &str = &v[0];
v.push("second".to_string());
let second: &str = &v[1];
println!("{first} and {second}");
コンパイルエラーだな

**デフォルトの名無しさん** · 2023/04/09(日) 01:42:07.16

文字列専用じゃないけどarena系の実装でいいのかな
typed_arena（https://docs.rs/typed-arena/latest/typed_arena/index.html）がよく使われてるみたい

use typed_arena::Arena;

fn main() {
let arena = Arena::new();
let a: &mut str = arena.alloc_str("abc");
let b: &mut str = arena.alloc_str("def");
let c: &str = arena.alloc_str("ghi");
println!("{a}, {b}, {c}"); // abc, def, ghi

a.make_ascii_uppercase();
b.make_ascii_uppercase();
let d: &str = arena.alloc_str("jkl");
println!("{a}, {b}, {c}, {d}"); // ABC, DEF, ghi, jkl
}

**デフォルトの名無しさん** · 2023/04/09(日) 01:56:50.49

だとしたらinterior mutabilityでやる話だね

**デフォルトの名無しさん** · 2023/04/09(日) 02:19:43.49

use string_cache::DefaultAtom;

fn main() {
let s1 = DefaultAtom::from("example");
let s2 = DefaultAtom::from("example");

assert_eq!(s1, s2);

let s1_ref: &str = &*s1;
let s2_ref: &str = &*s2;

assert_eq!(s1_ref, s2_ref);
}

**デフォルトの名無しさん** · 2023/04/09(日) 02:43:31.70

シンボルテーブルか

**デフォルトの名無しさん** · 2023/04/09(日) 16:31:56.46

>>323,325
質問者はコレクションを求めてるんだろ

**デフォルトの名無しさん** · 2023/04/10(月) 08:37:09.69

Rustのwebフレームワークって2023年現在どれがおすすめですか?

**デフォルトの名無しさん** · 2023/04/10(月) 10:35:11.69

そんなに数多くないと思うから10～20個くらい試して何が良かったか教えてよ

オススメ聞くってことはここで挙げられるようなやつ全部試して感想聞かせてくれるってことでしょ
決めるのに好みも入ってていいんだから
なんなら「名前が気にくわない」「アイコンがダサい」くらいの理由でもいい

**デフォルトの名無しさん** · 2023/04/10(月) 10:45:58.73

規模とか構成とかでも良い選択は違うのでなんとも言いにくいな。
比較的に万能で定番なものは actix, axum, rocket あたりだと思うが。

**デフォルトの名無しさん** · 2023/04/10(月) 12:38:17.63

Tide 使っとけば間違いない

**デフォルトの名無しさん** · 2023/04/10(月) 15:48:33.90

パフォーマンスより、単純明快なwebフレームワークが知りたいな
PythonならFlask的な
どうせDBがボトルネックになるし

**デフォルトの名無しさん** · 2023/04/10(月) 18:28:14.17

そういうの自分で調べられない人はもう少しエコシステムが成熟してからRustを検討した方がいいよ

**デフォルトの名無しさん** · 2023/04/10(月) 19:05:09.35

どうせ○○がボトルネックになるし
↑
こういう発想は大事
細かいところにだけ着目してvtableのコストがどうのとか
クロック数でいくらどうのとか
そういう連中よりは遥かにセンスがある

**デフォルトの名無しさん** · 2023/04/10(月) 19:20:23.61

>>334
クラウドだとCPU時間やメモリに課金されるから
「ユーザの体感速度にほんど影響がないからいいや」とはならない。
スループットだけ見てればよい時代は終わった。

ローカルでちょっとした GUI がわりにする程度ならどうでもいいけど……。

**デフォルトの名無しさん** · 2023/04/11(火) 23:57:13.30

ディスパッチの話で負けた負け犬が遠吠えこいてんのか

**デフォルトの名無しさん** · 2023/04/26(水) 20:19:48.59

Rustに限った話じゃないけど非線形(条件分岐を少なからず含む)な関数のテスト条件って普通どうやって作るの？
例えばRGB888フォーマットの色1と色2を飽和加算合成する関数を作ったのでテストしたいとする
すべてのパターンをテストすれば確実だが2の24乗もあってあまり現実的ではない
最小値と最大値と線形から非線形に移行する付近のみテストするとか？

**デフォルトの名無しさん** · 2023/04/26(水) 20:42:58.19

境界付近をテストするので良いと思う。
網羅的にテストしたつもりでも実際の問題ってのはどうせ
想定してないところから出てくるもんだから事前に何もかも盛り込むのは無理。
問題が出たときにテストを追加して同じ問題をもう出さない (後退はしない) ようにして
徐々に良くしていくしかない。

**337** · 2023/04/29(土) 21:52:25.06

>>338
あと追加するなら加算のテストくらいかな
0+1=1、1+1=0+C、1+0=1・・・ビット単位ならパターンはそこまで多くないし
ググっても具体的に何をテストすべきかみたいな解説はあまり出てこない気がする

**デフォルトの名無しさん** · 2023/05/02(火) 10:56:16.58

スレに人が来なくなったのはGWなのとchatGPTでPG需要減ってきたからか

**デフォルトの名無しさん** · 2023/05/02(火) 12:05:52.42

sudoとsuがRustで書き直される。メモリ安全性向上へ
https://news.yahoo.co.jp/articles/296d15d7c1f7190ff1646f4d52f8df8c56c0e132

**デフォルトの名無しさん** · 2023/05/02(火) 12:09:31.43

このままLinuxの公式言語になってしまうのだろうか？
それはそれでちょっと寂しい

**デフォルトの名無しさん** · 2023/05/02(火) 12:15:20.08

へぇ、Rustって知らないところで着実に市民権獲得し始めてるんやな
まぁ確かに“安全性”、“堅牢性”ってのは売りになるわな

**デフォルトの名無しさん** · 2023/05/02(火) 12:21:25.01

とは言ってもパラダイムが違うものを組み合わせるのは
それはそれで色々としんどいから
新規プロジェクトからということにはなるわな。
あるいはモジュール単位で徐々に……といったところか。

**デフォルトの名無しさん** · 2023/05/02(火) 13:10:44.65

純粋に質問なのですが、Windowsだとユーザ権限プログラムから感知できない全画面確認画面(コード署名表示付き)を
手動クリックすることによって権限昇格するAPIやファイル実行オプションを用いるのですが、
Linuxのsudo、suはそういうOS提供APIの単純ラッパ以外の処理が必要なのですか？

**デフォルトの名無しさん** · 2023/05/02(火) 14:14:52.25

>>345さんの祖末なチソチソもっとよーく見たぃナ☆
>>345さん、またみんなの前でチソチソ出してくださいね☆

**デフォルトの名無しさん** · 2023/05/02(火) 15:20:08.53

Qiitaで調べものをしていたらRustを広めたいというユーザーを
見かけたのですが実のあるRustの記事がありません

ここにいらっしゃるのですか？

**デフォルトの名無しさん** · 2023/05/02(火) 16:34:54.41

Rustはアマチュアがいじいじするだけの言語だから

**デフォルトの名無しさん** · 2023/05/02(火) 17:29:28.03

Rustや情報科学みたいなものは、完全に自分の教養のためと思って勉強してるけど・・・・・
いつまで経っても実用の域に届かない

**デフォルトの名無しさん** · 2023/05/02(火) 17:34:42.24

R&D関係者と交流があるだけの人ってアマチュア？

**デフォルトの名無しさん** · 2023/05/02(火) 17:49:30.32

アマチュアがあーでもないこーでもないと
持て余したヒマでいじくり回した結果
しょうもないポエムを生み出すだけ

この言語そのものというより
この言語を取り巻く状況はずっとこう

**デフォルトの名無しさん** · 2023/05/02(火) 19:13:07.37

Linux 6.3.1のtokeiしました

https://i.imgur.com/1xgblDP.png

**デフォルトの名無しさん** · 2023/05/02(火) 19:48:58.54

YouTube で有名な雑食系エンジニア・KENTA が、
初心者に推奨するキャリアパスは、Ruby on Rails → Go のみ

Rust, Elixir は普及のキャズムを超えなかった。
オワコン認定した言語は、Scala, PHP

米国年収でも、Rails, AWS Solution Architect が13万ドル

Ruby, Elixir : 9.3 万ドル
Go : 8.9
Rust : 8.7

多くの言語 : 6.5～7

PHP : 5
Dart : 4.4

日本では、バックエンドの求人倍率が数倍で、
フロントが0.5倍と、10倍の開きがある。
フロントは供給過剰で、低価格競争になっている

欲しい人材は、Rails, Linux, Docker, AWS が出来る香具師。
つまり、ウェブサービスを作れる香具師

Railsは、作者のDHH が言うように、バックエンド技術者がフロントも兼ねるから、
バック/フロントの打ち合わせコストが掛からないのが強み

その代わり、あまりCSS を知らないので、デザイン性に欠ける。
Bootstrap, Tailwind などが多い

つまり、これが文系の低学歴でも、簡単に高収入を得られる方法。チート職業。
だから皆、月千円のKENTAの初心者向けRailsサロンへ入る。稼げるから

**デフォルトの名無しさん** · 2023/05/02(火) 20:03:17.56

>>341,345
sudu-rsとsudo(original)のtokeiしました
LOCが違い過ぎて機能的に同等とは思えませんが誰か確認してください
https://i.imgur.com/wqUfNLQ.png

**デフォルトの名無しさん** · 2023/05/02(火) 22:59:03.14

>>354
機能的に同等そうかどうかは
テストを比較すればいいよ

**デフォルトの名無しさん** · 2023/05/03(水) 00:18:13.49

>>355
なるほどテストを比較よろ

**デフォルトの名無しさん** · 2023/05/03(水) 00:24:35.35

現時点のCurlからRustの跡形なくなってる

3年前のアナウンス
Memory Safe ‘curl’ for a More Secure Internet - Oct 9, 2020
https://www.memorysafety.org/blog/memory-safe-curl/

言及されてるhyper(-rs)がなくて、C実装になったc-hyper
https://github.com/curl/curl/blob/master/lib/c-hyper.c
Rustlsはそれらしきものが全くない

**デフォルトの名無しさん** · 2023/05/03(水) 00:49:48.46

>>341
これ別にsudo(sudo.ws)やsu(GNU)がRustに移行しますって発表じゃなくて
GNU grepに対するripgrep的なプロジェクトってことで合ってます？

**デフォルトの名無しさん** · 2023/05/03(水) 08:45:46.83

>>357
HTTPバックエンドとして使えるって話だから元々本体にRustコードは入ってないと思うけど
この辺見ればわかるけど、hyperやrustlsは別途ビルドしてるよ
https://github.com/curl/curl/blob/master/.github/workflows/linux.yml

**デフォルトの名無しさん** · 2023/05/03(水) 11:25:57.48

もうChatGPTあるしRustの存在意義がほとんど無くなっちゃったね

**デフォルトの名無しさん** · 2023/05/03(水) 12:08:28.90

>>360
どういう関係が？

**デフォルトの名無しさん** · 2023/05/03(水) 15:58:21.31

>>358
移行を目指して開発するということです

**デフォルトの名無しさん** · 2023/05/03(水) 17:41:36.60

>>360
Linuxをrustで書き直して
↓
はい、できました

**デフォルトの名無しさん** · 2023/05/03(水) 20:37:19.00

数千トークンの単位でしかやり取りできないって知らないんだろうな

**デフォルトの名無しさん** · 2023/05/05(金) 20:25:46.02

この手のシステムプログラミング？できる言語って何から始めたら良いんですかね
いきなりRustから入ってもいいのかそれともC言語から始めるべきなのか

シェルスクリプトで作った自作ツールをバイナリ化して動作を早くしたいとかそれくらいしか今は用途ないんですけど
いやでも、既存のツールのソースが読めるようになるから難しくてもまずCをやるべきか…

**デフォルトの名無しさん** · 2023/05/05(金) 20:44:06.81

>>365
隔離スレに帰れゴミ

**デフォルトの名無しさん** · 2023/05/05(金) 21:21:06.18

>>366
ええ…単にRustで検索してたどり着いて書き込んだだけなんだけど

**デフォルトの名無しさん** · 2023/05/05(金) 21:21:49.38

>>365
そういう用途ならとりあえずはGoからはじめるといいよ
目的を実現するまでにかかる時間が5倍くらいは違うと思うから

シェルスクリプトも外部ツールをうまく利用してたら実質Cに近い速度で動いてる場合もあるからCやRustで自作したからといって速くなるとは限らないよ

**デフォルトの名無しさん** · 2023/05/05(金) 21:25:04.73

Rustを学ぶために事前にCを学んだほうがいいかと言えば全くそんなことはない

**デフォルトの名無しさん** · 2023/05/05(金) 21:46:33.98

>>368,369
ありがとうございます

事前にCの知識が不要であれば、既存のツールのソースを読むのに便利くらいな感じなんですかね、Cは
自作スクリプトは最初からOSに入ってるコマンドを組み合わせる形で動いていて
なのでまあ多少早くなればいいなくらいで、後は趣味兼勉強で覚えたいと思ってます

GoについてはRustと双璧で名前が出てきますね
Rustの方が使われてる印象があったんでそっちを検討してたんですけど
GoについてもRustと違いを把握できる程度で調べて、どっちかで検討してみようと思います

**デフォルトの名無しさん** · 2023/05/05(金) 23:01:41.02

>>370
システムプログラミングというのはシステム (OS やそれに近い層) のプログラミングを
想定したもので、システムのドキュメントでの説明やツールキットに C が使われていることはそれなりにある。
アプリケーション層でも C や C++ で書かれたライブラリと結合したいこともたまにはある。
(人気のあるライブラリなら Rust 用のラッパーライブラリが提供されていると思うが。)
そういうことをしたいのなら C を多少は読み書きできないとしんどいこともあるかもね。
そうでないなら C を扱える必要はない。

大きなコンポーネントを組み合わせる程度の使い方の場合は
シェルスクリプトを他の言語に置き換えても性能はほとんど変わらない。
実行時間のほとんどがそのコンポーネント内のコードの実行に費やされることが多いので
自分が書く部分の性能が少しばかり高性能でも全体の実行時間にはそれほど大きくは影響しない。

**デフォルトの名無しさん** · 2023/05/05(金) 23:23:10.17

>>365
何らかの言語経験があるならいきなりRustで大丈夫だけど
C言語の基礎レベルの知識(ポインタ、スタックとヒープ、ヒープメモリ確保と解放)の有無の差を埋めておくのはよいかもね

>>370
GoはGC(ガベージコレクション)がある言語なのでどうしてもC/C++/Rustとは決定的な違いがあるね
例えばスクリプト言語の高速なライブラリを作るといったような速さや省メモリを追及するならC/C++/Rust

**デフォルトの名無しさん** · 2023/05/06(土) 04:59:19.62

C++もGC使えるけどな

**デフォルトの名無しさん** · 2023/05/06(土) 05:26:55.29

言語システムとしてGCを必須とする言語との区別がつかないアホか

**デフォルトの名無しさん** · 2023/05/06(土) 06:16:27.47

C++マネージ拡張
プログラミング言語

**デフォルトの名無しさん** · 2023/05/06(土) 06:21:14.86

文字列は動的なアロケーションが必要な場合があるだろ？
じゃあ、文字列を動的配列に入れる場合どうなる？
コピーなどは動的配列のメンバで行われるだろ？
C++は、コンテナが使用するメモリーはGC、文字列のメモリー確保はマイアロケータ、なんてことが出来る
動的配列のメンバが文字列のメンバにマイアロケータを使わせるようになるってことだぞ

**デフォルトの名無しさん** · 2023/05/06(土) 06:22:08.86

>>375
標準C++で使えるぞ

**デフォルトの名無しさん** · 2023/05/06(土) 06:47:02.36

GCが不可欠な言語とライブラリでGCする話は全く異なり関係ない

**デフォルトの名無しさん** · 2023/05/08(月) 01:15:08.03

パーサジェネレータっていろいろあるけど今だと何が良いんだ？
パースターゲットはgas風のアセンブラリスト。取り扱いは今風な方が嬉しい

**デフォルトの名無しさん** · 2023/05/08(月) 02:27:34.26

文法にも種類があって文法と解析アルゴリズムの組み合わせ次第では定義不可能なこともある。
具体的な文法を検証しないとどれを使うのが妥当かは言えない。

**デフォルトの名無しさん** · 2023/05/08(月) 06:50:07.08

>>380
gas系のIA-32/AMD64アセンブラリスト
gccやclang等が吐くものを想定している

**デフォルトの名無しさん** · 2023/05/08(月) 08:35:46.67

nomでいいんじゃないかな

**デフォルトの名無しさん** · 2023/05/08(月) 10:53:50.62

gas の文法なら最も素朴な文法カテゴリである LL 文法の範疇に収まるはずなので
PEG 系のパーサコンビネータライブラリが適していると思う。

でも LL 文法は再帰下降で書いてもたいした手間ではないので
凝ったツール (またはライブラリ) を導入しても劇的に楽になるってほどでもない。
コードの見通しが良くはなるかなぁ……。

**デフォルトの名無しさん** · 2023/05/08(月) 20:28:58.82

>>383
ググるとpegってクレートが引っかかるけどこれでいいのだろうか
というかgas系の文でもISAによって使えないパーサジェネレータとかあるのかな

**デフォルトの名無しさん** · 2023/05/12(金) 21:22:48.00

わび、さび
が分かる日本人↓

**デフォルトの名無しさん** · 2023/05/13(土) 06:51:26.85

滑ってるぞ

**デフォルトの名無しさん** · 2023/05/20(土) 16:33:08.50

--emit asmをつけるとアセンブラリストを出力できるけどstaticlibやrlibをつけても一部の関数が
出力されないように見える。例えばpanic!を呼ぶとうちの環境(1.69 x64 MSVC)では
callq _ZN4core9panicking5panic17h3445eebb4065373cE
が生成されるけどリスト中にこのラベルはない。マングリングされているけど実体はおそらく
ttps://doc.rust-lang.org/core/panicking/fn.panic.html
と思われるけどこのあたりのアセンブラリストを得るにはどうしたらいいんだろ？

**デフォルトの名無しさん** · 2023/05/20(土) 18:33:58.33

インライン化されてるだけでは？
panicだと分岐とpanicハンドラが出てくるから分からないってことはないと思うんだが
最小再現コードをgodboltにても上げてみては？

**デフォルトの名無しさん** · 2023/05/20(土) 19:27:31.19

Compiler Explorerの使い方がよくわかっていないので変だったらスマン
ttps://godbolt.org/z/nxz95xejr
こんな感じ。明示的にrip相対になっているのでコンパイラはLinux版と思われる
core::panicking::panicを呼び出していることはわかるがその中身は出てこない

**デフォルトの名無しさん** · 2023/05/20(土) 23:56:16.81

>>389
no_stdなライブラリだと基本的に使う側がpanic_handlerを定義するので実体なくてもしょうがないような
no_stdをコメントアウトして表示される結果と比べてみれば？

**デフォルトの名無しさん** · 2023/05/21(日) 00:24:43.05

>>390
[no_std]を外すと
callq *std::panicking::begin_panic::{{closure}}@GOTPCREL(%rip)
とかになるみたい。ただしその中で呼んでいるラベルすべてが含まれるわけではない模様

例えば
#[panic_handler]
fn panic(_panic: &PanicInfo<'_>) -> ! {
loop {};
}
などとパニックハンドラを足してもcall先のラベルがrust_begin_unwind(上記panic関数の実体)になったりはせず
core::panicking::panicが呼ばれるっぽい。そこからユーザー定義のハンドラを呼び出す隠れたコードがあるはず
ついでにabort=unwindの場合はpanic発生時にrust_begin_unwindが呼ばれるはずだけどその辺も隠れているように見える

**デフォルトの名無しさん** · 2023/05/23(火) 16:03:35.67

初心者の相談ここでいい？
RustやってみようとWin ＋VisualStudioCodeに　
RustAnalyzer と　CodeLLDBを入れ
PythonもPath付きで入れた　
cargo newも走った

なのにデバッガが使えない　
Hello Worldにブレイクポイント一つ置いただけなのに
F5押したら帰ってこない　もう一回押したら

Debugは既に開始しています　別のインスタンスを開始しますか？

なんかワクチンが悪さしてるかと思ってESETも30分止めてみたけれど同じ
誰もこんなところで躓いてないのになんでかな，，，

**デフォルトの名無しさん** · 2023/05/23(火) 17:27:20.12

デバッグなしの実行だと　Hello, world!　が普通にターミナルに出力されるのに
なんで　デバッガ動かないんだか，，，

**デフォルトの名無しさん** · 2023/05/23(火) 17:30:06.95

>>392
下ペインの出力タブで何かエラーメッセージ出てないか確認しなさい

**デフォルトの名無しさん** · 2023/05/23(火) 18:02:22.62

>>392
launch.jsonを生成してみれば？

**デフォルトの名無しさん** · 2023/05/23(火) 18:04:39.75

へい

コード側に表示されている
Run/DebugのうちのDebugを押しても
ターミナル側にはPS C:\Users\xxx\xxx\hello >　
みたいにpathが見えているままで　何も追加表示されない

launch jsonは自動的に作られている
コールスタック表示には　プロセスについて　run ｘｘと表示が出て
Debug押すたびに　run xx 2とかプロセスが増えていくだけ

**デフォルトの名無しさん** · 2023/05/23(火) 18:11:32.54

"configurations": [
{ "type": "lldb", "request": "launch",
"name": "Debug executable 'hello'",
"cargo": { "args": [ "build", "--bin=hello", "--package=hello" ],
"filter": { "name": "hello", "kind": "bin" } },
"args": [　], "cwd": "${workspaceFolder}" },
{ "type": "lldb", "request": "launch",
"name": "Debug unit tests in executable 'hello'",
"cargo": { "args": [ "test", "--no-run", "--bin=hello", "--package=hello" ],
"filter": { "name": "hello", "kind": "bin" } },
"args": [　], "cwd": "${workspaceFolder}" } ]　}
誘導に乗るままに自動生成されたlaunch json なんかおかしいのかなこれ

**デフォルトの名無しさん** · 2023/05/23(火) 18:14:16.03

>>396
出力タブってそれじゃなくて[表示(V)]→[出力(O)]で出るやつね
右上のセレクタで関係ありそうなやつを片っ端から確認

**デフォルトの名無しさん** · 2023/05/23(火) 18:26:24.50

へい
今日はもうPCから離れてしまったので
(お仕事の時間
明日の午後　出力をここに転記してみます
よろしくお願いします

**デフォルトの名無しさん** · 2023/05/24(水) 14:06:06.92

昨日の続きです　出力>Debugdセレクタで
Launching debug configuration:
{
"type": "lldb",
"request": "launch",
"name": "run hello",
"program": "C:\\Users\\ochia\\Downloads\\RustTry\\hello\\target\\debug\\hello.exe",
"args": [],
"cwd": "C:\\Users\\ochia\\Downloads\\RustTry\\hello",
"sourceMap": {},
"sourceLanguages": [
"rust"
],
"env": {
"RUST_BACKTRACE": "short",　以下略

**デフォルトの名無しさん** · 2023/05/24(水) 14:08:03.26

＞LLDBセレクタ
relativePathBase: 'c:\\Users\\xxx\\Downloads\\xxx\\hello',
_adapterSettings: {
displayFormat: 'auto',
showDisassembly: 'auto',
dereferencePointers: true,
suppressMissingSourceFiles: true,
evaluationTimeout: 5,
consoleMode: 'commands',
sourceLanguages: null,
terminalPromptClear: null,
evaluateForHovers: true,
commandCompletions: true,
reproducer: false
}
}

**デフォルトの名無しさん** · 2023/05/24(水) 14:09:28.83

Resolved debug configuration: {
type: 'lldb',
request: 'launch',
name: 'run hello',
program: 'C:\\Users\\xxx\\Downloads\\xxx\\hello\\target\\debug\\hello.exe',
args: [],
cwd: 'C:\\Users\\xxx\\Downloads\\xxx\\hello',
sourceMap: {},
sourceLanguages: [ 'rust' ],
env: {
RUST_BACKTRACE: 'short', 以下略

**デフォルトの名無しさん** · 2023/05/24(水) 14:17:47.42

launch jsonの内容をなぞっているように見えますけれど　どこが問題なんですかね

**デフォルトの名無しさん** · 2023/05/24(水) 19:14:40.08

その後は何もないの？

**デフォルトの名無しさん** · 2023/05/27(土) 20:30:35.69

生行列をallocするベストプラクティスを教えてください
doube **a=malloc(sizeof(double*)*100);
for (i=0; i < 100; i++) {
a[i]=malloc(sizeof(double)*1000);
}

//a[i][j]でアクセス

みたいなやつです

条件としてC/C++より遅くはならないこと
かつある程度安全であることです

普通にやVecで良い」ならそれで行きます

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

何に使うかによります

**デフォルトの名無しさん** · 2023/05/27(土) 22:55:13.87

>>405
とりあえずVecで作るので良いよ
性能は別途検証しましょう

bound checkが必要になる使い方か
auto vectorizationが働く使い方か
などが差が出るポイント

**デフォルトの名無しさん** · 2023/05/27(土) 22:56:24.11

ドキュメントを調べたらRawVecが良さそうなんですが
まだ安定版で早い模様
https://github.com/rust-lang/rust/blob/master/library/alloc/src/raw_vec.rs

うーむ

**デフォルトの名無しさん** · 2023/05/27(土) 23:03:14.16

Vecの中身がRawVecなんだけど
RawVecを直接使ったほうが速くなるような使い方なのかな？

**デフォルトの名無しさん** · 2023/05/27(土) 23:15:57.87

数万要素の行列演算なので極力余計な処理はして欲しくない感じかな

**デフォルトの名無しさん** · 2023/05/27(土) 23:38:53.11

>>405
Cのコード見るにそんな速度にこだわり無さそうだけどｗ

**デフォルトの名無しさん** · 2023/05/28(日) 00:21:22.19

今のご時世に行列計算の速度を気にするならSIMD使えでFAじゃね？

**デフォルトの名無しさん** · 2023/05/28(日) 00:34:27.16

今の時代は普通にGPU使うのがベストだよ
ただしクラウドでやるとなると金がかかる
今こそCPUで限界まで性能を出し切ることが「男の夢」じゃあないか
マルチスレッド、ベクトル命令、メモリのプリフェッチを駆使して
GPUなしでどの程度性能を引き出せるか？という実験をやっているところ
Cなら普通に書けるのだけどRustの方が色々ライブラリも豊富だから
アプリケーション化するとき楽かなあと思った次第

**デフォルトの名無しさん** · 2023/05/28(日) 00:34:40.65

詳しくないけどBLAS/LAPACKっていうの使えばいいんじゃないすか
そもそも行列計算するつもりなのかすら明言されていませんが

**デフォルトの名無しさん** · 2023/05/28(日) 00:42:17.84

GPUは環境依存が激しいからなぁ。自分しか計算しないならそれでもかまわないかもしれないが
不特定の環境で動かすソフト用には使いづらい

**デフォルトの名無しさん** · 2023/05/28(日) 02:13:41.27

とりあえず行列を適当なブロックに区切ってそれをスレッドで計算、ブロックは転置したりしてキャッシュメモリに乗るように調整する
それを最終的にreduceする
こうすればマルチノードでも実行可能

>>414
それも使ってみるよ
numpyは内部でそれを使ってるらしいけどね
ただライブラリ使ってハイ終わりってのは味気ない
そしてやってることは俺が上に書いた技術以上のことは現状ない

**デフォルトの名無しさん** · 2023/05/28(日) 18:01:21.95

「The Rust Programming Language 日本語版」の日本語訳が微妙すぎる。自分は英語が苦手なのでできるだけ日本語で分かりやすくRustの使用について書いてあるドキュメントが読みたい。
だれか日本語的にもう少しちゃんとしたRustのドキュメントを作ってくれないだろうか？

**デフォルトの名無しさん** · 2023/05/28(日) 18:48:08.28

>>417
しっかり学びたいならオライリー本がいいよ

**デフォルトの名無しさん** · 2023/05/29(月) 09:19:07.96

本家に追従できていないのは不備だがそれは単なるリソース不足だから訳者が増えないとどうしようもないし、
文章表現の中に学習に障害になるほどおかしいようなところがあるとは思えないので
分かり難いと感じる箇所は本当に翻訳由来なのか？と思う。

**デフォルトの名無しさん** · 2023/05/29(月) 11:00:00.74

>>417
日本語訳にそのような問題はない

**デフォルトの名無しさん** · 2023/05/29(月) 11:14:03.62

せめて具体的にどの部分かくらいは言ってくれないと
翻訳の問題なのか原文自体が417に合わなかったのかも分からんしなぁ

**デフォルトの名無しさん** · 2023/05/29(月) 11:31:04.88

そんなレベルじゃないだろ
あの日本語訳を普通に読めるやつって普段どんな文章読んでんだよ