結局C++とRustってどっちが良いの？ 5traits

**デフォルトの名無しさん** · 2023/06/30(金) 21:56:35.52

「C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」
「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」

っていう雑談スレ。

結局C++とRustってどっちが良いの？ 4traits
https://mevius.5ch.net/test/read.cgi/tech/1686046386/

関連スレ(マ板): Google&MS「バグの70%はC/C++。Rustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/

**デフォルトの名無しさん** · 2023/06/30(金) 22:00:04.42

クラウド世界トップシェアのAWSもRustで構築されているようだ

https://japan.zdnet.com/article/35183866/
AWS (Amazon Web Services)は、「Rust」を使っている大きな理由として、エネルギー効率の高さを挙げる。
AWSは早くからRustを採用し、Rust Foundationの創設にも携わった。
現在もRustの普及に熱心に取り組んでいる。

AWSのソフトウェアエンジニアで、Rustの普及に取り組む
Shane Miller氏と主任エンジニアのCarl Lerche氏の投稿によれば、
Rustはメモリー安全性を高め、セキュリティ関連の不具合を減らす役に立つだけでなく「エネルギー効率に優れている」。
Amazonは、2025年までにデータセンターの100％を再生エネルギーでまかなうという目標を掲げ、
データセンターの環境負荷の軽減に取り組んでいる。
Rustの採用はその一翼を担うという。

Rustで構築されたAWSサービスの例としては、
コンテナーアプリ用のサーバーレスプラットフォーム「Lamba」を支える「Firecracker」、
「Amazon Simple Storage Service（S3）」、
「Amazon Elastic Compute Cloud（EC2）」、
コンテンツ配信ネットワーク「Amazon CloudFront」、
LinuxベースのコンテナーOS「Bottlerocket」などがある。

**デフォルトの名無しさん** · 2023/06/30(金) 22:03:50.69

布教でも反論でも、質問(C/C++ﾁｮｯﾄﾃﾞｷﾙけどRust始めました、あるいはその逆とか)でも、
関係ないようなこと(避難スレ的運用)でも、ご自由に。

>>2
記法もちょっと近かったりして、webとは相性いいみたいね

**デフォルトの名無しさん** · 2023/06/30(金) 22:48:29.45

乗るしかないこの大波

**デフォルトの名無しさん** · 2023/06/30(金) 23:28:17.68

非∞！！！！
頓∞！！！！！
典∞！！！！！！
項∞！！！！！！！
判∞！！！！！！！！
病∞！！！！！！！！！

**デフォルトの名無しさん** · 2023/07/01(土) 01:50:39.23

俺はc言語がいいんだ
nimは試そうかと思ったけどmingw入れるのがだるくて入れなかった
エコシステムに関してはrustは素晴らしい
cargoが良く出来てる

**デフォルトの名無しさん** · 2023/07/01(土) 02:16:26.66

俺は見つけてしまった!!!
gccrs

**デフォルトの名無しさん** · 2023/07/01(土) 02:18:19.44

LinuxがRustのソースコードを受け付けるようになったって話は
コンパイラはgccrsで良いのかな?

**デフォルトの名無しさん** · 2023/07/01(土) 03:46:54.61

gccは誰も使わないコンパイラ。

**デフォルトの名無しさん** · 2023/07/01(土) 04:02:08.70

めっちゃ使ってる
clangもいいけど

**デフォルトの名無しさん** · 2023/07/01(土) 04:41:49.04

今、Rustでnumpyライクなライブラリを目指してるけど、行列の演算はrayonを内部にぶっこむべきだろうか。
ちなみにRustのndarrayベースで作るのはやめて一から実装している。

**デフォルトの名無しさん** · 2023/07/01(土) 04:46:21.39

ユーザが好きに選べるようにするべき

**デフォルトの名無しさん** · 2023/07/01(土) 05:18:27.37

gccを使っていると言う変な人が、自分がスタンダード化の様に
偉そうに振舞えるのが匿名インターネットの世界。

**デフォルトの名無しさん** · 2023/07/01(土) 07:08:07.40

>>6
Zigがあるじゃない

**デフォルトの名無しさん** · 2023/07/01(土) 08:15:56.69

ユーザ数も指標の一つ
利用者が多ければライブラリも大量に出る

**デフォルトの名無しさん** · 2023/07/01(土) 08:24:36.90

>>13
それも、この世界の下積みの一種かなって思ったり

**デフォルトの名無しさん** · 2023/07/01(土) 08:34:29.73

Rustはrust analyzerが優秀なので、何も考えずに言われた通りに修正したら何かコンパイルも通って大体挙動も正しいということが経験できる。これはC, C++では絶対ない。

**デフォルトの名無しさん** · 2023/07/01(土) 08:59:45.18

C++にもチェッカはあるけど、あんまり利用が普及しないんだよね
利用が普及しないから成長も遅いそれがC++の現状の弱さ

**デフォルトの名無しさん** · 2023/07/01(土) 09:26:47.55

これすごいな
https://www.youtube.com/watch?v=0O_kqQ4RQI8

**デフォルトの名無しさん** · 2023/07/01(土) 09:31:25.82

Unreal Engine の Rust化なんて永久に来ないわ

**デフォルトの名無しさん** · 2023/07/01(土) 09:34:27.40

>>7
ggrks と似てるね

**デフォルトの名無しさん** · 2023/07/01(土) 10:28:15.98

>>13
Rustコンパイラに選択肢が出来ることは良いことではないか!
恐らく史上最も稼働しているカーネルをビルドしてるのがgccだよ

**デフォルトの名無しさん** · 2023/07/01(土) 10:29:07.14

Rustはゲーム製作周りのクレートとかが不足気味な気はする。でも、機械学習系の有用なRust純正クレートはかなり増えてきてるとは思う。

**デフォルトの名無しさん** · 2023/07/01(土) 10:34:43.25

こんなにモダンで優れた言語があるのに今からそびえ立つ💩のシープラやる人いるのかね

**デフォルトの名無しさん** · 2023/07/01(土) 10:38:27.78

>>24
後方互換性なめすぎ
MSは賢かった

**デフォルトの名無しさん** · 2023/07/01(土) 11:47:08.23

>>24
>>1 にもあるとおり、仕事では、やれと言われたものをやる
SwiftでもDartでもおなじ

問題は、自分用の推し言語
俺はもうちょっとC++でいく Rustの知見をC++に持ち帰るんだ

**デフォルトの名無しさん** · 2023/07/01(土) 14:19:14.54

同じく仕事で必要なものを使う。
今はC、C#、C++/CLI、Python。
Rustをまずは趣味で始めたいが時間が取れないのと、C++/CLIで作りたいものがある。

**デフォルトの名無しさん** · 2023/07/01(土) 14:28:25.90

えっ
C++/CLIはもう……

**デフォルトの名無しさん** · 2023/07/01(土) 14:37:04.32

C++/CLIは、C++20くるよ (ぐぐると、使えないっていう記事があがってくる
https://devblogs.microsoft.com/cppblog/cpp20-support-comes-to-cpp-cli/

C++やっててC#もやってたら、十分射程に入る

**デフォルトの名無しさん** · 2023/07/01(土) 14:42:28.74

持ち帰るも何もRustにはできてC++ではできないことなんかないやろ
匙加減の問題でしかない
C++ではスマポ限定の所有権、ライフタイムの設定を全オブジェクトに適用した
文法的に厳しくした
プログラムの制限が増えたせいでコンパイラがプログラマのミスを発見できる範囲が増えただけ
C++で同じ事ができるようになるとすればコンパイラオプションで
“-strict_variable_management”みたいなオプション新しく作ってRustスタイルの厳密な変数管理でコンパイルできるコンパイラが出てこないと無理、そして結局それ使うならrustスタイル(=スマポスタイル)の変数管理法を勉強しないといけない
そもそももうすでにポインタ使うならC++でもc++11以降のスマポの利用推奨で非推奨の方法避けるなら、これからは所有権とライフスタイルの概念勉強するのが不可避になってる

**デフォルトの名無しさん** · 2023/07/01(土) 14:56:45.83

勉強するってほどの御大層なものでもあるまいw

**デフォルトの名無しさん** · 2023/07/01(土) 15:36:05.30

匙加減ww
バカにつける薬は無いとは良く言ったもの

複オジもたいがいバカだと思うが
C++に執着してるやつが輪を掛けてバカだから
このスレはいつ見てもサル山の争い

**デフォルトの名無しさん** · 2023/07/01(土) 15:42:32.57

この文章読んでc++を擁護してると読めるのはどこまで日本語力ないんやろ
プログラミング能力どうこう言う以前の知能しかない

**デフォルトの名無しさん** · 2023/07/01(土) 15:44:12.22

できることが多いイコール優れているってのが間違い
RDBからカラム制約を外してエクセルのように使って幸せになれるか？

**デフォルトの名無しさん** · 2023/07/01(土) 15:48:16.48

まぁこの手の論争スレで人の意見を“敵か味方か”に2値で分類して絡んでくるんやろ
そう言う行為がみっともないと考える知能もない
便所の落書きだからこんなもんなんなも知らんどな

**デフォルトの名無しさん** · 2023/07/01(土) 16:16:02.46

RustよりHaskellのほうが安全で速い

**デフォルトの名無しさん** · 2023/07/01(土) 16:51:31.78

そもそも、STLなんて後から入ったものだから、それを使うことは
強制されて無いのに、STLの欠点がC++の言語としての欠点に
勝手にみなされてっしまってる。
これまでずっと、C++はBetter Cとして使うのが好まれていたのに、
Better Cとして使うのは時代遅れなんていっておきながら、
STLならではの欠点を指摘して、だから、C++を使うのは馬鹿なんだ、
と言ってくる。
Better CとしてSTLではないライブラリを使っている限り、
その欠点は入ってこないにもかかわらず。

**デフォルトの名無しさん** · 2023/07/01(土) 16:58:20.28

そもそも、C++でもsmart pointerを使うのが必須、などと言っているが、
むしろ、そうすることが煩わしさを生む。
そうすることによって、むしろめんどくさくなったり、分かりにくくなったり
することがあるのだ。
勝手に smart pointer を使うのが必須であるとして、それがとても使いにくい
ことがC++の欠点だと昇華され、だから、Rustでないとダメなんだと。
しかし、smart pointer を大々的に使おうとしたことが煩わしさの根本で
あることに気づいてない。
また、速度比較などでも、伝統的な Better C としての C++ ならば、
STL も smart pointer も使ってなかったから、Rustより速いにもかかわらず、
勝手に「最新のC++のやり方」とその人が思っていものを使って、
遅い結果にしてしまって、それをC++の「最高の結果」だと勝手に断定
してしまう。
世の中には「改悪」という現象がある事をその人は知らない。

**デフォルトの名無しさん** · 2023/07/01(土) 17:04:31.83

C#でWindowsフォームアプリで作成中にWin10では別途.net coreを配る面倒な事がわかってショックだわ。
Windowsフォームアプリケーション (.NET Framework)にしたいのだが作り直ししか無い？

**デフォルトの名無しさん** · 2023/07/01(土) 17:07:45.38

>>39
すまん誤爆しました。m(..)m

**デフォルトの名無しさん** · 2023/07/01(土) 17:31:35.89

マイクロソフトのMFCも欠点が指摘されやすいが、しかし、STLより便利なところもある。
MFCにはなかった問題点をSTLは沢山入れてしまった。
MFCはSTLと距離を置いている。
そして、デファクトスタンダードとしては、現代においてC++を使うとは
MFCを使うことに他ならない。ということは、STLはほとんど使われていない。
にも関わらず、教科書に書いて有るようなSTLの非常に煩わしいやり方を持ってして
C++が使いにくい、と言ってくる。
C++が愛されてきたのは、MFCのせいであってSTLのせいではないことを知るべきである。

**デフォルトの名無しさん** · 2023/07/01(土) 18:38:56.14

プログラマなのによくこんな駄文書けるな
ChatGPTで水増しさせた?

**デフォルトの名無しさん** · 2023/07/01(土) 18:41:37.69

偏見を承知で言うと
マイクロソフト依存症の人はそんな人が多い

**デフォルトの名無しさん** · 2023/07/01(土) 19:01:28.94

C#使いなよ

**デフォルトの名無しさん** · 2023/07/01(土) 19:03:32.57

C#は絶対嫌だ。

**デフォルトの名無しさん** · 2023/07/01(土) 19:05:40.48

>>14
Zig使ったこと無いけどエコシステムが整ってるなら使ってみたいな

**デフォルトの名無しさん** · 2023/07/01(土) 19:08:35.56

そもそもSTLがC++のメインライブラリなどと思っている人は、
C++をまともに使ったことが無い人だ。

**デフォルトの名無しさん** · 2023/07/01(土) 19:17:18.65

boostだろメインライブラリは

**デフォルトの名無しさん** · 2023/07/01(土) 19:18:04.10

C++のテンプレートは理想（言語仕様）と現実（コンパイラ実装）が乖離してたからな
module導入で多少はマシになるかもしれないけどnamespace残したままだからカオス度が増してしまった

**デフォルトの名無しさん** · 2023/07/01(土) 19:23:55.22

MFCは問題が有ったが、それは主にWin32のWindow関連の
APIとの連携においての話。
STLはそれ以前の問題で書き方がおかしい。
現実にプログラミング経験が少ない人が勝手に考えた感じだ。

**デフォルトの名無しさん** · 2023/07/01(土) 20:02:19.26

>>36
ライブラリがな

**デフォルトの名無しさん** · 2023/07/01(土) 20:20:46.38

>>36
HaskellがCやRustより速いとマジで言ってるの？

**デフォルトの名無しさん** · 2023/07/01(土) 21:49:33.99

>>39
>昇華
doubt

**デフォルトの名無しさん** · 2023/07/01(土) 22:14:34.22

>>38
全体は同意

**デフォルトの名無しさん** · 2023/07/02(日) 01:00:29.09

C#に慣れるとMFCでGUIは二度と書きたくない

**デフォルトの名無しさん** · 2023/07/02(日) 01:02:51.98

行列のサイズがでかくなるとシングルスレッドよりもrayonによる並列演算の方が速くなってくるな。

**デフォルトの名無しさん** · 2023/07/02(日) 06:54:41.92

そもそもMFCはfull freeにならんから
ちょっと前まではそうだった、今もそうだよな

自分用なら、コンソール+C#(OSに同梱の古い枯れたやつ)でいいし

**デフォルトの名無しさん** · 2023/07/02(日) 09:53:50.16

>>55
開放するの忘れてリークしまくる。

**デフォルトの名無しさん** · 2023/07/02(日) 13:18:42.16

GUIがかんたんになったのはここ10年くらいでしょ
それ以前は何を選んでも面倒で難しかった

**デフォルトの名無しさん** · 2023/07/02(日) 13:20:54.90

IDEの性能や極まったポトペタ感で昔より作りやすくなってる
言語そのものじゃなくその周辺が作りやすさを決めてるだけじゃないか？

**デフォルトの名無しさん** · 2023/07/02(日) 13:53:16.00

RustのGUIってそんなに作りやすいか？

**デフォルトの名無しさん** · 2023/07/02(日) 14:19:07.95

GUI用のDSL（マークアップ）がある言語に比べればまだまだでしょ
Rustもマクロ使えばDSLくらいは組めそうだけど
最近は内部ブラウザみたいな代替技術があるから需要が少なそう

**デフォルトの名無しさん** · 2023/07/02(日) 15:12:58.96

>>59 難しいと思ったことは一度も無いな
>>61 Tauri は糞

**デフォルトの名無しさん** · 2023/07/02(日) 15:49:02.90

TauriやElectronはGUIといっても
・マルチプラットフォームでスマホ対応も進行中
・Webと同じ知識技術で作れる
・Webアプリへとの共有や移行が容易
と大きなメリットがあり
VSCodeなどこの方式で成功しているアプリが多数ある

**デフォルトの名無しさん** · 2023/07/02(日) 15:52:44.86

Rustで全てが非同期かつコンポーネントベースのGUIライブラリを作る機運が生まれてる
描画から全部自前でやる本当のネイティブ版Reactのようなもの

**デフォルトの名無しさん** · 2023/07/02(日) 18:19:31.18

GUIをC++やRustでやる意味とは
UEだけだろ意味あるの

**デフォルトの名無しさん** · 2023/07/02(日) 18:40:53.06

>>61
全てがasyncでコンポーネント化されている
これこそ次世代のGUIライブラリとなる
これを作れるのはrustのみ

**デフォルトの名無しさん** · 2023/07/02(日) 19:45:01.65

すべてasyncとか死ぬほどめんどくさそう

**デフォルトの名無しさん** · 2023/07/02(日) 19:49:14.43

いやGUIだとそれが普通なんだよ
UIスレッドでブロッキングAPI使えないのだからその設計が普通
今までのライブラリの設計がミスってた

**デフォルトの名無しさん** · 2023/07/02(日) 19:55:13.31

このライブラリがかなり理想に近い
https://wishawa.github.io/posts/async-ui-intro/

見てもらえればわかるがほぼReactだ
しかも全てが非同期なので非常に速い

**デフォルトの名無しさん** · 2023/07/02(日) 20:01:17.15

そもそもJavaScriptが非同期に動き並行プログラミングだからね

**デフォルトの名無しさん** · 2023/07/02(日) 21:45:39.87

C#もそんな感じだろ
メッセージポンプスレを止めちゃいけないからとか聞いた、そういやそうだよな
モダンだね

**デフォルトの名無しさん** · 2023/07/02(日) 21:52:34.41

C#は残念ながらブロックする処理を書く場合はスレッドを立てなきゃいけなくて遅い
さらにUIスレッドへの同期コンテキストが必要でその分さらに遅い

**デフォルトの名無しさん** · 2023/07/02(日) 21:59:34.59

結局のところOSの描画API呼び出すから、
最終的にUIスレッドに描画任せないといけないのはどのライブラリでも変わらん

**デフォルトの名無しさん** · 2023/07/02(日) 22:04:50.40

>>74
それは違うんじゃないか
例えばファイル読み書きもOS呼び出すけど
並行プログラミングができていれば
シングルスレッドでもファイル読み書きでブロックされず
待ち時間に他の作業をできるよ
そこにマルチスレッドや描画専用スレッドの必要性はない

**デフォルトの名無しさん** · 2023/07/02(日) 22:08:24.86

OSの仕組み理解してなさそう

**デフォルトの名無しさん** · 2023/07/02(日) 22:27:06.93

>>76
OSの仕組みを理解していないのは君だ
Linuxならepollなど
WindowsならIOCPなどを勉強しなさい

**デフォルトの名無しさん** · 2023/07/02(日) 22:31:37.38

なぜ非同期が良いか？
UIスレッドが呼び出しても何の問題もないことが保証されてるから
これはnode.jsが気が付かせてくれたパラダイムシフトだよ

**デフォルトの名無しさん** · 2023/07/02(日) 22:49:45.19

>>76
並行プログラミングの基本はOSをノンブロッキングで呼び出すところにある
例えばシングルスレッドでもファイルを読み書きしつつ10000個のクライアントと通信するサーバーも作れる
これが並行プログラミング
具体的には>>77のepoll等やあるいはそれらを用いてマルチプラットフォーム対応したlibuvライブラリ等を使う

>>78
Node.js以前から行なわれてきている
Node.jsはそのイベントループ構造部分を内蔵していて
その核心部分をプログラミングできない人でもJavaScriptを書くだけで使える点は大きいね

**デフォルトの名無しさん** · 2023/07/02(日) 22:54:55.66

C++にもco_awaitきてるけど、ああいうのこそ、所有権とか来たらラクに書けるだろうな
コルーチンおもろいぞ、C++erもいっぺん経験してみるべき

**デフォルトの名無しさん** · 2023/07/02(日) 22:59:35.55

フロントエンドならRustが活躍できるんだな

**デフォルトの名無しさん** · 2023/07/02(日) 23:07:43.48

いいGUIライブラリを使いなさい

**デフォルトの名無しさん** · 2023/07/02(日) 23:09:15.57

Rustは昔からmioクレートがマルチプラットフォーム対応していて
| OS | Selector |
|---------------|-----------|
| Android | [epoll] |
| DragonFly BSD | [kqueue] |
| FreeBSD | [kqueue] |
| iOS | [kqueue] |
| illumos | [epoll] |
| Linux | [epoll] |
| NetBSD | [kqueue] |
| OpenBSD | [kqueue] |
| Windows | [IOCP] |
| macOS | [kqueue] |
こんな感じ

現在はmioを直接使わなくても
mioの上に並行並列スケジューラを構築しているtokioを使えばよい

**デフォルトの名無しさん** · 2023/07/02(日) 23:47:03.38

>>79
ファイルの話じゃなく描画の話をしてるんだが

**デフォルトの名無しさん** · 2023/07/02(日) 23:57:38.16

最近ちょっと(GUIまわりから)離れてるけど、GUIのメッセージキューがメインスレッドに付いてるから、
処理をとっととワーカスレッドに移しちゃうってのは、古くて新しいテーマだよな

**デフォルトの名無しさん** · 2023/07/03(月) 00:14:59.36

>>84
ファイルだろうがネット通信だろうが描画だろうが全てソケットに抽象化されているので同じ

**デフォルトの名無しさん** · 2023/07/03(月) 00:21:47.27

C言語が、あるいはそれに連なるC++が業界標準の地位を確立したのって何ともANSI Cの存在が大きい気がします
言語が流行るためには何はともあれ“人が作ったプログラムが自分の環境で試せる”と言うのは大きい。それをちょっと変えてみたらどうなるかとか試してみて学んだりできるのって大きい気がします
今の“業界標準のRust”ってどこが取り仕切っているんですか？
そしてその“業界標準Rust”に収録されてる“標準ライブラリ”の一覧のようなものはどこかで一覧の形で見れますか？、

**デフォルトの名無しさん** · 2023/07/03(月) 00:25:47.65

epollって並列待機処理でそもそもの待機側を開放したい
async/awaitとは別の話題だと思うんだが

**デフォルトの名無しさん** · 2023/07/03(月) 01:22:18.45

>>87
https://www.rust-lang.org/ja/governance

Rustユーザがもっと増えて
gccrsのように他にもコンパイラが出てきたら
規格が必要になってくるかもね

**デフォルトの名無しさん** · 2023/07/03(月) 01:36:25.99

>>88
同じ
(スレッドを使う並列でななく)並行処理を行なうコードを自分で書いてみるとわかる
I/Oを非同期多重化することになる
ためselect/poll/epoll/kqueueを用いたイベントループがスケジューラ相当として核をなす
それを直接使う未分化な原始的な利用から始めて、
次にコールバック方式による単純分離、
さらにpromise/futureによる抽象化、
そしてasync/awaitによる糖衣構文、
と進むことになるが核部分はもちろん同じ

**デフォルトの名無しさん** · 2023/07/03(月) 01:37:43.68

>>89
thx

**デフォルトの名無しさん** · 2023/07/03(月) 02:06:46.42

サイズの大きい配列って結構コピーの部分で時間が取られるのかねえ？GUI周りの話ではないが。Rustでnumpyライクなライブラリを作っているからそこら辺は気になる。

**デフォルトの名無しさん** · 2023/07/03(月) 02:28:24.34

>>88
async/awaitって元はただのブロックしないコールバック付きの関数だよ

**デフォルトの名無しさん** · 2023/07/03(月) 03:05:22.10

と言うかRustの利点はそこにあるんやろ
特に返り値のとき
返り値に大きいサイズのObjectを返すときが問題
その場合Cでは返り値のどデカい構造体を呼び出し側のスタック領域にコピーする手間がどうしてもかかってしまう
それを避けるには
・返り値をヒープに領域確保して返す
・呼び出し側で受け取りようの空の構造体領域を呼び出し側スタックエリアに確保してその参照を渡して返り値をそこに書き込んでもらう
くらいしかない
しかしヒープにわざわざ永続的には存在する必要のないデータの受け渡しのためエリアをとるとフラグメンテーションの原因になるし、呼び出し側が返り値の大きさをあらかじめ計算してから領域確保して呼び出さないといけないのはメチャクチャ手間がかかってしまう
Rustなら返り値の構造体をダイレクトに呼び出し側のスタックエリアに確保できる(と思う、未確認)のでそこでパフォーマンスの優位性が出る(ハズ)
今のC,C++にはこのメカニズムを実現する方法はないと思う

**デフォルトの名無しさん** · 2023/07/03(月) 03:22:41.96

>>94
別にそこに関しては今やRustもC++も大して変わらんぞ
今のC++はreturn時に余計なコピーをしないようになってる

**デフォルトの名無しさん** · 2023/07/03(月) 03:24:05.61

RVO?

**デフォルトの名無しさん** · 2023/07/03(月) 03:37:51.42

>>95
そうなんだ
CとかC++は必ずコピーが発生するからどうやって回避するかでの定石習ったけどな
今はコピー回避できるんだ

**デフォルトの名無しさん** · 2023/07/03(月) 04:29:45.61

>>97
今のC++コンパイラはめちゃくちゃ賢くなってて
最適化できる処理はほぼ全て最適化する
特にreturn時や引数に渡す場合の処理で最適化して問題ないと判断されるとほぼ最適化される

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

>>92
めちゃくちゃ遅くなるよ
現代のアーキテクチャでは無駄なアロケーションやコピーが1番遅くなる要因
1番速いのは当然同じ領域を使い回してそこに書き込むようにすること
キャッシュも効くし無駄なアロケーションが発生しない
ただし副作用と可読性の低下という犠牲を払う
速度と安全性はまさに水と油

**デフォルトの名無しさん** · 2023/07/03(月) 04:46:33.55

>>98
その“コピー回避”の方法は“ヒープを利用して回避”ではなくて“呼び出し側のスタック領域を利用する”で回避してるんですか？
ソースあります？

**デフォルトの名無しさん** · 2023/07/03(月) 04:48:48.70

>>100
https://cpprefjp.github.io/lang/cpp17/guaranteed_copy_elision.html

**デフォルトの名無しさん** · 2023/07/03(月) 04:56:04.09

prvalueとかxvalueとかの値のカテゴリについてはこちらが詳しい
https://cpp.rainy.me/037-rvalue-reference.html#%E6%A6%82%E8%A6%81

**デフォルトの名無しさん** · 2023/07/03(月) 05:46:02.09

>>102
thx
でもコレやっぱりこの機能をスタック領域でやってるのかどうかの明言はないですね
上の方で誰かが言ってたんですけどC++のスマポ絡みは全部ヒープでやってるって話があったのでどうなんだろと
この問題はとても難しくて私勉強してた頃は解決できてなかったんですよ
例えば

object theFunc(){
object a,b;
.......
if comp( a, b) {
return( a );
} else {
return( b );
}
}

のようなコードの場合コンパイラは実際に変数aかbかのどちらが返り値として返されるのか決定する事はできません
もうこのような場合にはほとんど必然的にコピーするしかなくなります
回避する唯一の方法はobject a,bの両方を呼び出し側のスタックに確保して使わなかった方のobjectは呼び出し側スタックの穴として我慢します
もちろん一時的にスタックに穴が開きますがその呼び出し側の処理が終われば全部御破算にされるので目を瞑る作戦です
なんか聞こえは悪いですがスタック領域中に使われる変数でほんの一瞬しか使われない変数なんか山のように出るものなのでそれを一々気にしてたらキリがありません、問題視しないといけないのは永続的に残るヒープ領域のフラグメンテーションです
じゃあいつでも何でもかんでも呼び出し側のスタックに返り値を受け取る領域確保すればいいのかといえばそれもウソでほんの数バイトの情報しかないならいる分だけコピーしていらないデータは綺麗さっぱり消してしまった方がいい時もあって、どちらが良いかコンパイラは判断する方法がCでは中々解決できないみたいな事習った記憶があります
Rustならできるのかはまだ勉強中なのでよく分からないですけど

**デフォルトの名無しさん** · 2023/07/03(月) 06:42:22.66

スタックの穴ってなんのことぞや

関数等の行き返りで、intptr_t以上のものを受け渡ししようっていうのが、そもそもの無理筋感があるんだよな
rvalueを渡すなんていうのは、渡しているのやら、いないのやら

C++時代は、自信のないことはしない、だったんだ

**デフォルトの名無しさん** · 2023/07/03(月) 06:49:45.31

>>102
どうせならこっち https://github.com/EzoeRyou/cpp-intro/blob/master/037-rvalue-reference.md

**デフォルトの名無しさん** · 2023/07/03(月) 08:24:46.39

最適化しすぎるが故に、未定義を踏むとこういう事も起きてしまうという
https://cpplover.blogspot.com/2014/06/old-new-thing.html

**デフォルトの名無しさん** · 2023/07/03(月) 08:42:15.29

何かRustだとreturn時にコピーが行われてるような気がする。

**デフォルトの名無しさん** · 2023/07/03(月) 08:58:28.64

std::move() もそうだが、最低限のコピーはしないといかんぞどうせ
生成コードみてみろよ C++ならそうするので、取るべき行動は同じ

**デフォルトの名無しさん** · 2023/07/03(月) 09:05:18.13

要はAddAssignとAddだと計算結果は同じでもAddAssignの方が圧倒的に速いという現象が起こったりすることがある。これはAddだとコピーをリターンするのに対してAddAssignだとselfの値は同じメモリ上で書きかえられてreturnによるコピーがないから。

**デフォルトの名無しさん** · 2023/07/03(月) 09:32:31.64

確かに WideCharToMultiByte/MultiByteToWideChar は毎回
↓
容量確認で1回目呼び出し
↓
確保して
↓
容量指定して2回目呼び出し
↓
面倒だと思ってた

**デフォルトの名無しさん** · 2023/07/03(月) 09:54:04.75

毎回書くからだろ、ライブラリ(コードスニペット)にしちゃえｗ

**デフォルトの名無しさん** · 2023/07/03(月) 10:05:14.03

コンパイラが吐き出すコードなんて意図通りにならない
疑い深いなら細かくチェックしながらアセンブラで書くしかない
ループ内の重要な変数はレジスタを使っているか
無駄なコピーが無いか
ループ部分に無駄な関数呼びだしが無いか
実際のメモリに読み書きしやすい順序でデータが並んでいるか
最初に必要なメモリを一括でOSから取得しているか
最適な命令を使っているか
キャッシュ汚染が無いか

**デフォルトの名無しさん** · 2023/07/03(月) 10:10:50.88

アセンブラで書いてすら、意図通りにならないくらいに思っとけってばっちゃんが言ってた
(適当に分割して、複数パイプラインに流し込まれたりするから)

**デフォルトの名無しさん** · 2023/07/03(月) 11:59:58.23

>>96
RVOだよなぁ

**デフォルトの名無しさん** · 2023/07/03(月) 16:06:04.98

>>103
その場合はムーブコンストラクタ実装しとけば良い
参照でない値のリターンは自動で右辺値参照となる

**デフォルトの名無しさん** · 2023/07/03(月) 16:10:20.37

このようにC++は色々複雑すぎてもはや普通の人が理解できるものではなくなったので
素直にrust使おうよという振りなんだけどね

**デフォルトの名無しさん** · 2023/07/03(月) 16:16:32.89

Rustだとどうなるの? ソースで例示プリーズ

**デフォルトの名無しさん** · 2023/07/03(月) 16:53:27.10

たとえば64bit二つ分を返すと

#[derive(Default)]
struct Foo { a: u64, b: u64, }
impl Foo {
fn new(a: u64) -> Self {
let mut foo = Foo::default();
foo.a = a;
println!("foo: 0x{:p}", &foo);
foo
}
}

fn main() {
let fff = Foo::new(123);
println!("fff: 0x{:p}", &fff);
}

レジスタ返しができる範囲なので両者のアドレスは異なる
foo: 0x0x7ffc3e73a6d8
fff: 0x0x7ffc3e73a740

一つ増やして64bit三つ分を返すと
struct Foo { a: u64, b: u64, c: u64, }

レジスタ返しではなくなり
いわゆるRVO (Return Value Optimization)
呼び出し元main()のスタックフレームに直接書き込むため両者のアドレスは同じになる
foo: 0x0x7ffc03863d78
fff: 0x0x7ffc03863d78

**デフォルトの名無しさん** · 2023/07/03(月) 17:12:42.36

前者のアドレスが異なる場合というのは
レジスタ上だけで済むところを敢えてアドレス表示させているため
実際にはスタックを使わずレジスタのみの利用に成りうることを意味してることに注意

**デフォルトの名無しさん** · 2023/07/03(月) 18:59:43.08

なるほどrustは呼び出し元スタックに直接値返せるのね
コレはC++でできるんですか？

**デフォルトの名無しさん** · 2023/07/03(月) 20:50:38.98

$ cat test.cpp
#include <iostream>
#include <cstdint>
using namespace std;
struct Foo {
uint64_t a;
uint64_t b;
static Foo new_ (uint64_t a) {
Foo foo; foo.a = a;
cout << "foo: " << &foo << '\n';
return foo;
}
};
int main () {
auto fff {Foo::new_ (123)};
cout << "foo: " << &fff << '\n';
return 0;
}
$ g++ -O0 -std=c++20 -o test test.cpp
$ ./test
foo: 0x7fff0bbf3540
foo: 0x7fff0bbf3560
$ g++ -O3 -std=c++20 -o test test.cpp
$ ./test
foo: 0x7ffed05f53a0
foo: 0x7ffed05f53a0

**デフォルトの名無しさん** · 2023/07/03(月) 21:12:04.60

>>121
それは呼び出し側のスタックですか？

**デフォルトの名無しさん** · 2023/07/03(月) 21:12:23.79

NRVOなのでいつも効くとは限らない?

**デフォルトの名無しさん** · 2023/07/03(月) 21:15:14.72

>>122
0x7fff0bbf3560と0x7ffed05f53a0は呼び出し側のスタックなのでは?

**デフォルトの名無しさん** · 2023/07/03(月) 22:09:08.78

たったそれだけのことを
ヒープから確保してガベージコレクションで解放する重い遅いプログラミング言語がほとんどの中
C++とRustが優秀すぎるハイレベルな戦い

**デフォルトの名無しさん** · 2023/07/03(月) 23:25:23.71

>>724
そうなんですか？
厳密にいえば>>118のコードにしても関数側の変数のアドレスと返されたアドレスが同じである事の確認に過ぎず、つまり値を返す時にコピーがされてない事の確認にすぎません
それがヒープなのか、呼び出し側のスタックなのかは分からない
ただRustの場合は>>118の場合呼び出し側のスタック領域が利用される、その技術をRVOと呼ぶとアナウンスされているのに対してC++の方では今の所そのような情報ないので分からないのでは？
単にヒープに確保してるだけかもしれない

**デフォルトの名無しさん** · 2023/07/03(月) 23:28:41.59

あ、いや、今ググったらC++でもRVO実現してるみたいですね
失礼しました
しかし本当にそのアドレスの数値が一致していることだけでRVOが効いてる事の証明にはならないとは思います

**デフォルトの名無しさん** · 2023/07/03(月) 23:31:27.59

あ、よくよく読んだら「RVOとは戻り値返す時にコピーしない技術のこと」であって「呼び出し側のスタックを利用するかどうか」は別問題のようですね
まぁだからC++もRustも両方ヒープ使ってRVOしてるだけかもしれない

**デフォルトの名無しさん** · 2023/07/03(月) 23:46:31.39

ヒープが勝手に使われることはない
ヒープとスタックは空間を通常分けてありアドレス値も見ればわかるくらい異なる値を使っている
単純なローカル変数のアドレス値との比較からスタックのアドレス値かどうかすぐわかる

**デフォルトの名無しさん** · 2023/07/03(月) 23:47:11.84

>>128
根拠までは示せんが
俺はC/C++とやってきて
関数にnewを直接/間接に呼び出さなずにインスタンスを作れば
スタックに確保されるという認識だな
なのでRVO効いてれば呼び出し側のスタックに作成されるという風に考えている

**デフォルトの名無しさん** · 2023/07/04(火) 00:03:31.80

Rustはリターンの場合は多分コピーしてると思いますよ。なぜならサイズの大きい配列の計算において返り値ありときとポインタから直接いじる返り値なしの場合で返り値なしの方が圧倒的に実行速度が速かったから。

**デフォルトの名無しさん** · 2023/07/04(火) 00:16:23.10

推測するな
逆アセンブリ読め

**デフォルトの名無しさん** · 2023/07/04(火) 00:36:27.02

少なくとも>>118,>>121ともにRVOが効いててコピーはされてないようには見えますね
ヒープかスタックかは今上がってる実験だけからはなんともいえませんね
この“コンパイラの実装問題”はどんな言語の話でも突っ込んだ話すると必ず出てきますね
言語のregulationで「こういう場合はRVOか働いてコピーはされない、ヒープも使われることなく呼び出し側スタックが確保される事が保証される」みたいな文章が言語のregulationの中に有れば話早いんですけど大概書いてなくてコンパイラの実装依存だったりするしなぁ

**デフォルトの名無しさん** · 2023/07/04(火) 00:36:48.56

>>131
コピーしない
>>121のRustコード例のように呼び出し元のスタックフレームへ直接書き込む

もし遅くなっているなら別の要因だろう
たとえば未定義の値を使うことによるバグを一般的に防ぐためにRustは初期化をする
もし初期化をせずとも常に計算値で全て埋めることを保証できれば
unsafeな未初期化を用いてsafeな関数を作り出せる
そして初期化しない分だけ速くなる

もちろん他の要因もありえるためその遅いコードを見ない限り原因はわからない

**デフォルトの名無しさん** · 2023/07/04(火) 01:08:19.71

Rustのコンパイラがどういう方法でRVOを実現してるかは多分実装依存で「可能な限りやるようにしろ、プログラマはRVOが働いてくれると期待していい」くらいまでは書いてあるんかもしれないですね
実装としては予想ですけど

・関数のスコープ内でローカルに作られた変数(左辺値？)は原則スタック領域に確保されて関数の処理終了時点で全て解放される
・しかし関数の戻り値として呼び出し側の変数にバインドされて生存期間が伸びた変数は消去されず呼び出し側スタックに残す
・もちろん>>103のような例でコンパイル時点でobject a, object bのどちらを残すか決定できないなら両方残して返り値として使われなかった方のメモリは穴として諦める、どのみちその“呼び出し側の関数”が終了する時点で解放される穴なので諦める

みたいな実装なんでしようかねぇ？
私アセンブラ読めないので確かめられませんけど

**デフォルトの名無しさん** · 2023/07/04(火) 01:50:19.31

もし怪しい点があるとすれば>>121のC++側
コンパイルを同じコードに対して最適化レベルを変えて-O0と-O3で比較している
これでは例えば-O3の場合にinlIne化による最適化が起きただけかもしれない
したがってC++側はRVOの証明になっていない

一方>>118のRust側は返す値の大きさの違いで比較して挙動が変わっている
Rust側はRVOの証明になっている

**デフォルトの名無しさん** · 2023/07/04(火) 02:24:25.89

関数がインライン展開されたら関数間の変数のコピーは省略される
レジスタ変数は参照を取得出来ない
逆にいうと参照を取得したらレジスタではなくメモリ変数(非レジスタ変数)になる

Rustではよく所有権の借用のための参照取得をするけれどそれが
C++ほど最適化されるのでしょうか

**デフォルトの名無しさん** · 2023/07/04(火) 02:44:11.87

>>118
の追試

https://ideone.com/6g3Ne2

関数内で２つのFoo型を作ってどっちを返すかコンパイル時には分からない(はす)のコードで実現

fn whichFoo ()-> Foo {
let a = Foo::new(456);
let b = Foo::new(789);
if( true ){
a
}else{
b
}
}
この関数を2回呼んで返り値のアドレスと比較
結果びっくりした

a 456 foo: 0x0x7ffff3242cd0 // 1階目の１項目(返す方)
a 789 foo: 0x0x7ffff3242c98 // 1階目の2項目(捨てる方
fff: 0x0x7ffff3242cd0 // 返り値、1個目と一致
a 456 foo: 0x0x7ffff3242cb0 // 2階目の１項目(返す方)
a 789 foo: 0x0x7ffff3242c98 // 2階目の2項目(捨てる方
fff: 0x0x7ffff3242cb0 // 返り値、1個目と一致

で2回呼んで2回とも1個目のアドレスと一致でRVOが効いてる
のみならず1回目で捨てた方のアドレスが2回目のすてる方のアドレスとして再利用されてる
コレはどうやってんの？
全く予想外

**デフォルトの名無しさん** · 2023/07/04(火) 02:53:28.80

そんな気になるなら生成されたコード見たら？

**デフォルトの名無しさん** · 2023/07/04(火) 03:12:41.98

>>137
最適化される
参照はその値自体を必要としなければ最適化で消え得る

>>138
レジスタ割り当て再利用と同じ
それ以降に使われていなければ領域の再利用の最適化ができる

**デフォルトの名無しさん** · 2023/07/04(火) 03:23:48.80

>>140
thxです

**デフォルトの名無しさん** · 2023/07/04(火) 07:50:54.82

>>141
イヤそれをどうやってんのって話
オレが当然こういうimplementだろうと思ってたのはこう

whichFooが呼ばれてstackが割り当てられる(でもおそらくそのプロセスに割り当てられてるスタックのスタックポインタの上端もらってくるだけだと思うけど)
もらったstackに上から詰めてFoo型のaとbができる
普通に考えて上端から順にaのための領域、bのための領域
この２つは返り値として使用される可能性があるからmainのstackの下端のすぐ下に作ってはおくけどどちらが使われるかは不定

①呼び出し前(♪がsp)
[　　未使用域　　]♪|　[mainのstack　]
②1回目呼び出し直後
[未使用域]♪[ b ][ a ]|　[mainのstack　]

実行時に[a]が返される事が確定、bは破棄されて[a]の真下にspを戻してmainの再開から2回目呼び出されて同じく[a],[b]が作られる

③2回目呼び出し直後
[　未使用域　　]♪[ a ]|　mainのstack　]
④2回目の変数領域確保
[未使用域]♪[ b ][a'][ a ]|　[mainのstack　]
⑤2回目の変数領域確保
[　未使用域　]♪[a'][ a ]|　[mainのstack　]

となると予想したら違った

**デフォルトの名無しさん** · 2023/07/04(火) 07:51:01.03

今のは運良く最初に確保したaの方が返り値として使われたので簡単に領域bが再利用できるけど、もちろん一般には分からない、なのでコンパイラのできることといえば返り値になるかもしれないbの領域はスタック上端に確保しておいてなるべくフラグメンテーションが起きても被害最小に止めるくらいかなと思ったら違った
(ちなみに残す方と捨てる方逆にしても結果は同じ)
確保されたアドレス見るにコンパイラは最初からaが返されるのを見越して[a]の領域だけをmain側のstackに割り当ててるように見える、1回目も2回目も、そして1回目終了時に回収されたbのためのエリアが再利用されてる
レジスタの場合と徹底的にに違うのはメモリの場合「空いてたら使う」を実現するには“未使用域を完全に把握して新しく領域を確保する時未使用域をなるべく活用する”がかなり難しい事
普通は使用してる下端と未使用の上端の境界にsp置いとくくらいが限界
「使用してるのは①～②、③～④、....」なんてできるはずない、できるハズないからフラグメンテーション問題が発生する
もちろんこの“できるはずない”事をやってれば実験結果みたいになって不思議ないんだけど流石に無理じゃないかと

**デフォルトの名無しさん** · 2023/07/04(火) 07:56:44.61

でも可能性はあるのかな
プロセス全体で共有されるヒープ全体の使用状況なんか全部管理できないけどローカルの関数に割り当てられたスタックなんてしれてるから使用域、未使用域全部管理してるのかな？

**デフォルトの名無しさん** · 2023/07/04(火) 09:22:16.43

Rustで標準的なチャート生成(グラフ描画)ツールは何ですか？

**デフォルトの名無しさん** · 2023/07/04(火) 10:49:51.72

>>136,137
なるほどー
Rustはinline展開しないの?

**デフォルトの名無しさん** · 2023/07/04(火) 11:02:31.68

>>142
話は単純
>>138のifでtrueで恒真だから最適化で消えた

**デフォルトの名無しさん** · 2023/07/04(火) 11:18:09.81

>>146
Rustもinline展開される
それとは独立にRustの基本動作として常にRVOが起きる

>>118のコードを
debug mode ← cargo run
release mode ← cargo run -r
の2種類で実行すると

➀debug modeでstruct Foo { a: u64, b: u64, }の場合
　→　fooとffiは別アドレス
このdebug modeではinline最適化はされていない
レジスタ返しできる範囲であるため別アドレス

➁release modeでstruct Foo { a: u64, b: u64, }の場合
　→　fooとffiは同じアドレス
これはrelease modeでinline最適化がされたため同じアドレスとなった

➂debug modeでstruct Foo { a: u64, b: u64, c: u64 }と大きいサイズの場合
　→　fooとffiは同じアドレス
これは➀によりinline最適化はされていない
レジスタ返しできる範囲を超えてるためmain()スタックフレームに直接アクセスしている

**デフォルトの名無しさん** · 2023/07/04(火) 11:53:43.89

>>121を-fno-inlineをつけてビルドしてみた
$ g++ -O3 -fno-inline -std=c++20 -o test test.cpp
$ ./test
foo: 0x7fffb2b5ee40
fff: 0x7fffb2b5ee40
-fno-inlineでインライン展開されていないとするならRVOが効いている

**デフォルトの名無しさん** · 2023/07/04(火) 13:35:05.06

global optimizationがかかったら、どっちにしても、いいようになるのかもしれない
いいようになってくれと思って書くのがいいこれはC++もRustも同様

**デフォルトの名無しさん** · 2023/07/04(火) 15:10:09.42

Why you shouldn't learn Rust
https://www.youtube.com/watch?v=kOFWIvNowXo

**デフォルトの名無しさん** · 2023/07/04(火) 15:58:19.26

良いまとめ

Why You Should Learn Rust
https://zerotomastery.io/blog/why-you-should-learn-rust/

**デフォルトの名無しさん** · 2023/07/04(火) 17:54:17.35

>>147
せやね
かなぁとは思ってたんやけど時間なくて試せなかった
whichFoo()の条件式を時間のsystem時間の下一桁が奇数か偶数かで決めるように変項したら当たり前みたいにRVOが聞かなくなった

https://ideone.com/T6QJKv

まぁそりゃそうかもね、aかbかどっちが返されるか分からないのに両方とも呼び出し側stackに領域確保してまでRVO効かす事はしないみたいやね
もちろん「フラグメンテーション上等、ローカルスタックに穴開いてもその処理終わるまでなんやから無視、無駄コピーしない事最優先」って実装もできたんやろうけどそうはなってないみたいやな
多分この辺は実装依存なんやろ

**デフォルトの名無しさん** · 2023/07/04(火) 18:53:05.89

Rustはなんでsimd命令を安定版で使えないんだろうか。

**デフォルトの名無しさん** · 2023/07/04(火) 19:16:47.25

A-simdラベルつきのissues一通り読んでくれば

**デフォルトの名無しさん** · 2023/07/04(火) 21:51:42.30

>>145
いろいろある
"Rustでグラフをplotするライブラリのまとめ"

**デフォルトの名無しさん** · 2023/07/05(水) 01:56:15.57

多次元配列の実装ってブロードキャストのところが結構ムズいな。今かなり苦労してるわ。とりあえずnumpyのメジャーな機能はすべて実装したものをrust純正で作りたいか。

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

足りない次元を前から詰めていくだけでは？
それでうまく揃えられなかったらエラー

**デフォルトの名無しさん** · 2023/07/05(水) 08:04:26.42

rustってマスコットも可愛いし
全てが完璧だよな

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

golang なんてマスコットがきもすぎて皆逃げだしたもんな

**デフォルトの名無しさん** · 2023/07/05(水) 10:16:26.75

あれは何周回っても逆に良いとはならないのがすごい

**デフォルトの名無しさん** · 2023/07/05(水) 15:06:58.72

>>145
https://github.com/plotters-rs/plotters

**デフォルトの名無しさん** · 2023/07/05(水) 19:58:33.55

ʕ◔ϖ◔ʔ < 呼んだ？

**デフォルトの名無しさん** · 2023/07/05(水) 20:49:18.89

とりあえず、Rustで多次元配列の実装自体は大分進んできたけど、配列の値は構造体の中にVec型で持つべきかそれとも他の配列構造体においても同じデータをコピーせずに使い回せるようにするために&Vec型で持たせるべきか悩んでるんだよね。&Vec型だとライフタイムの指定とか複数の可変参照について考えなくちゃいけないからだるいんだけど、一つのデータから複数の配列構造体がコピーなしで作れるんだよな。どうするべきか。

**デフォルトの名無しさん** · 2023/07/05(水) 21:19:29.23

Rustの基礎常識
長さを変えうる場合を除いて&Vecや&mut Vecの受け渡しをしない

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

>>165
配列構造体、ここではNdarray構造体と呼ぶことにする。Ndarray構造体に多次元配列のデータを持たせる。ただし、Ndarray構造体は配列の中身の情報をVec型で保持してるとするこれをdata属性と言うことにする。すると、Ndarray構造体の２つインスタンスに共通のdata属性を持たせることがムズいんですよ。キャッシュの効率的に共通したメモリを占有するdataを持たしたいときがかなりあるのでそこで悩んでいるんですね。

**デフォルトの名無しさん** · 2023/07/05(水) 21:50:12.76

データ構造体をコードで示すべし

**デフォルトの名無しさん** · 2023/07/05(水) 21:59:42.44

なにも考えたくなければRc<[T]>でも使ってれば

**デフォルトの名無しさん** · 2023/07/05(水) 22:02:51.53

一応pytorchの例だと_で終わるメソッドはin-placeで配列を書き換える

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

Ndarray構造体は簡単に書くと以下のような感じになる。
struct Ndarray<T> {
pub data: Vec<T>,
pub shape: Vec<usize>,
pub stride Vec<usize>,
}
実際のコードではTに関する制約条件も入ってるけどここでは本質的ではないので書かないことにする。
Ndarray構造体を多次元配列の要素に関する情報をdataに持っている。shapeには多次元配列の形状に関する情報が入ってる。ここで、2つのNdarrayインスタンスに同じdataを共有しているような感じにしたいんですよ。勿論、dataのコピーはキャッシュの効率的になしということで。

**デフォルトの名無しさん** · 2023/07/05(水) 22:27:08.29

途中で伸び縮みするのか否か
途中で値が書き換わるのか否か

**デフォルトの名無しさん** · 2023/07/05(水) 22:30:04.73

いやいや数値計算のライブラリでデフォルト共有とかまずないからコピーで実装してくれ

**デフォルトの名無しさん** · 2023/07/05(水) 22:39:25.32

>>164で&Vecを渡そうとしていたから何も書き換わらないと判断すると
コピーするのは無駄

**デフォルトの名無しさん** · 2023/07/06(木) 01:08:51.91

当面コピーでよくね？
numpyの値受け渡しもcall by valueで毎回コピーしてるんじゃないの？

**デフォルトの名無しさん** · 2023/07/06(木) 01:17:08.65

コピーするメリットがない
普通に&[T]渡し

**デフォルトの名無しさん** · 2023/07/06(木) 01:38:49.41

お前らエロ画像ぶっこ抜くときもRust使ってんの？

**デフォルトの名無しさん** · 2023/07/06(木) 02:02:58.99

Rustならエロも安全さ

**デフォルトの名無しさん** · 2023/07/06(木) 03:18:32.83

>>172
計算効率の向上のためですね。よく使うような奴はコピーにする様に動くようにしたいですね。
>>171
途中で伸び縮みはしないと思う。
途中で中身が書きかえられたらすごい都合が良い。出来れば途中で中身が書きかえられるようにしたい。

**デフォルトの名無しさん** · 2023/07/06(木) 03:21:51.88

>>175
Rustは構造体の使用的に属性に参照渡しするのが結構ダルいのではと思っています。正直、自分はライフタイムの`aとかいう感じの修飾子に関してあまり理解できてない

**デフォルトの名無しさん** · 2023/07/06(木) 03:30:31.36

>>174
Numpyはデフォルトでは浅いコピー、要は参照で渡してるっぽいです。自分が調べてみた感じでは。

**デフォルトの名無しさん** · 2023/07/06(木) 04:40:27.15

スレチですが、
k0 レジスタを、opmask レジスタとして predicate
としては使用できない、ということで正しいのでしょうか？
つまり、
EVEX.512.0F.W0 5E /r
VDIVPS zmm1 {k1}{z}, zmm2, zmm3/m512/m32bcst{er}
と書いてある場合、{k1} の部分は、{k2}や{k3}
などを指定できて、EVEX.aaa の部分には、2や3など、
1～7 の数値が指定できますが、0 だけは指定できないのでしょう
か？　しかし、それだと、k0 のビットが常に全て 1 である
という便利な性質が利用できない気がします。
もしかして、たとえば、k2 レジスタに k0 レジスタの値を
代入してから、{k1}の部分を{k2}と書け、と言うことなんで
しょうか。
だとすれば、なぜ、そんな回りくどい事を。

**デフォルトの名無しさん** · 2023/07/06(木) 05:15:09.86

>>178
書き換えありの場合
同時共有しないなら単純に&mut [T]渡し
共有するならスレッド内かスレッド間か排他制御の粒度や種類はどうかなどで分かれる
例えばスレッド間で共有しつつ書き込みありで排他制御の粒度はスライス全体で読み込み複数同時可ならばArc<RwLock<&mut [T]>>など

**デフォルトの名無しさん** · 2023/07/06(木) 06:11:31.90

すまん&mutはもちろん不要
Arc<RwLock<[T]>> ね
配列からでなくVecからなら
Arc<RwLock<Vec<T>>> か
長さ変わらないならBox化して
Arc<RwLock<Box<[T]>>>

**デフォルトの名無しさん** · 2023/07/06(木) 08:06:47.31

>>179
それは例えると
「私はC言語を書けますがポインタを使えません」
と言ってるのと同じでマズいな

**デフォルトの名無しさん** · 2023/07/06(木) 12:21:28.35

>>164
lifetime 付けたくないなら
struct Ndarray<T> {
pub data: Option<&Vec<T>>,
pub shape: Option<&Vec<usize>>,
pub stride Option<&Vec<usize>>,
}

**デフォルトの名無しさん** · 2023/07/06(木) 12:24:16.16

>>176
初めてのRustはエロ収集scrapingツールだった

**デフォルトの名無しさん** · 2023/07/06(木) 14:30:31.20

ネタにマジレスですまんが、スクレーピングみたいのってRust得意なんけ

**デフォルトの名無しさん** · 2023/07/06(木) 14:53:35.46

得意かは知らないが非同期io機能が充実しててやりやすい

**デフォルトの名無しさん** · 2023/07/06(木) 17:09:56.98

rustに全てを置いてきた

**デフォルトの名無しさん** · 2023/07/06(木) 21:21:05.78

>>185
ないわw

**デフォルトの名無しさん** · 2023/07/06(木) 21:34:07.17

シャローコピーってスライス代入と普通の代入の時だけでしょ？
ディープコピーは...演算子を使う
さらにin-place演算子(+=など)は変数を書き換える
それ以外は全てコピーを作って返す
これがnumpy

**デフォルトの名無しさん** · 2023/07/06(木) 21:39:43.66

ndarrayはスライスをマクロで定義している
さらにスライスはArrayViewを返す
これは真似た方が良い
あとはslice_mut...assignという書き方を踏襲するかどうか

**デフォルトの名無しさん** · 2023/07/07(金) 02:03:56.84

>>192
自分は初学者でも分かりやすいように気本的に配列に関する全ての操作はNdarray構造体に押し込みたいんだよね。

**デフォルトの名無しさん** · 2023/07/07(金) 03:34:18.30

ダメそう

**デフォルトの名無しさん** · 2023/07/07(金) 04:58:02.59

オプソのするつもりならRustに反対しないが
オプソにするつもりの無いプロジェクトなら
迷わずC/C++ジャマイカ？

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

RustでNumpyライクなクレートを制作中だけど、ある程度形になったら公開するつもりだよ。OSSにするつもりだし。

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

>>193
rust使いに初心者がいるとは思えないのだが
ということはやはりRcで持つということになるんかね
chainerのarrayの実装もshared_ptrで持ってる
https://github.com/chainer/chainer/blob/master/chainerx_cc/chainerx/array_body.h

**デフォルトの名無しさん** · 2023/07/07(金) 13:01:06.40

まぁでも実際には難しいやろな
かつてプログラミングの世界を席巻していたPascalを駆逐してCが覇権を握ったのは多分基本的な関数の呼び出し方式をcall by refference からcall by valueね変更したのが大きい
cpuの性能が上がるにつれ整数型とか浮動小数点型の受け渡し時程度なら毎回値をコピーする実装にしてもそれで落ちるパフォーマンスの低下はやはりcall by valueの持つ“読みやすさ、組みやすさ”の優位性が際立ってきた
でもとはいえ毎回呼び出しのたびに値をコピーするcall by valueに全統一するのは無理なので文字列やベクトル処理についてはcall by refferenceをえらべるようなよくいえば柔軟、悪くいえば場当たり的な実装にしたのがCが覇権を握った最大の要因かもしれない
しかし今日さらにプログラミング言語の研究が進んでRVO技術などを利用して"call by valueの文法なのにコピーしない"という事が可能になってきて話が違ってきたのは事実、この先この技術がさらに発展すれば“call by valueを使わないベクトル処理ライブラリ”なんてものが出てきてもおかしくはない
でもこのRVOはまだまだ使いにくい、Rustの資料色々読んでも「関数の戻り値の受け渡しの際必ずしもコピーが発生するわけではない」程度の話しか出てこない、この辺は今現在開発がどんどん進んで行っててまだまだ“企画”としてまとめられる段階にないんやろ
だとすると現状“ベクトル処理ライブラリ”をまとめるならcall by refferenceを使う他ない
問題はその際発生するlife time注釈をどうするかの問題、しかしコレもRustの版が進むにつれ変化している“開発途上”の立ち位置で“注釈の省略”の機能を了して“一才注釈なしで使える”はちょっと難しいかも

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

>>197
初心者がRustに参入しやすくなるようなライブラリを作ることが目標だから。私自身も初心者に毛が生えたようなレベルだし。
同じ可変参照を持つ構造体のインスタンスが複数作られることを考慮してるからRxとかArcを使うことになる可能性は高い。

**デフォルトの名無しさん** · 2023/07/07(金) 13:17:59.91

いや高いじゃなくてw