結局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/07/08(土) 19:03:14.40

このスレは各言語の特徴的なキーワードだけを参考にしている。
どっちが優れているとかどっちがゴミだとかという話は全く参考にならない。

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

>>332
論文レベルじゃないと理解できないのは困りものですね

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

>>332
lifetime elisionは別に推論じゃないぞ
borrowckとしてはライフタイムは必ず事前に注釈されなくてはならない
一部のよくあるパターンで省略を許可する、人間のためのルールがelision rules

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

Rustについて安全であるということだけを切り取って議論しているのは、現場も現実も知らない阿呆

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

>>332
考え方が逆
ライフタイム注釈はコンパイラにとって常に必要
だからライフタイム注釈するのが基本しかしそれを省略することができる状況が多々あって
その省略された時にコンパイラが省略を補う規則が定められている
https://doc.rust-lang.org/book/ch10-03-lifetime-syntax.html#lifetime-elision
lifetime elision rules
The first rule is that
The second rule is that
The third rule is that

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

>>337
それ。

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

>>332
推論せんよ
だから自分で書く必要がある

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

ここで説明しても無駄だよ
彼は論文レベルじゃないと理解できないんだから

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

みなさまありがとうございます
ちょっと私まだ疑問が解決してないです
私の認識書いてみます
私の認識だとrustの“ライフタイム”はコンパイラが確保したメモリを解放するタイミングを決定するために必須のものだと考えています
何故なら効率のためにrustは複数の参照が同じオブジェクトを参照する事を許す“参照の貸与”のシステムを導入してるからです
なので所有権を持ちその参照が切れる前に全ての“貸与”していた全ての参照の“ライフタイム”が切れていなければなりません
コンパイラは貸し出された参照のライフタイムが所有権を持つ参照のライフタイムより長いものが有ればそれを検出し、貸借規定違反としてコンパイル時にそれを検出する事でダングリング参照の発生を防ぐシステムだと認識してます
その“参照のライフタイム”はユーザーが宣言するものではなくて本来ならコンパイラが自動的に拾うべきものだと思ってます
何故ならばrustの参照のライフタイムが「プログラマが好き勝手に自由に設定していい」ものなら結局それは“コンパイラがダングリング参照の発生を未然に検出する”システムになど到底ならないからです
少なくともユーザーが“この関数の返り値のライフタイムは引数のこのライフタイム以前に切れる”と宣言してもその宣言の妥当性をコンパイラが検証しないなら意味がありません、もちろん検証すると思います、具体的には返り値として用意された値のライフタイムがその値を作成した右辺値に現れる参照のライフタイムより長ければその時点で不当なライフタイムの宣言を検出できてそれでコンパイラは不適切なライフタイム注釈を検出できると思います
分からないのはそれなら結局コンパイラはライフタイムをやろうと思えば自分で推論できるのではないかという事です、実際rustの初期のコンパイラでは必須だったライフタイム注釈はいくつかの推論可能なケースでは省略可能になっているようです
じゃあいつダメなのか？いつどんな時なら推論がうまくいかないのかの基本的な理論がよく分からないんです

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

>>342
>私の認識だとrustの“ライフタイム”はコンパイラが確保したメモリを解放するタイミングを決定するために必須のものだと考えています

ちゃうよ

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

長文しか掛けんのかこいつは

全部関数など使わないで書けばライフタイム自体は一目瞭然
だが不注意な人はブロックから抜けて死んでる物を参照して使おうとする

それをコンパイラが阻止する
ライフタイムは基本的はこれだけ

これが前段階

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

多分GC言語しか使ったことがないのだろう
参照がある限り値が生き続けるというぬるま湯に浸かってるから理解できない

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

すいません、私が知りたい事説明するのにこれ以上短くできませんでした

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

それが途中で関数が使われてると戻り値のライフタイムがわからなくなる
入力した引数と戻り値のライフタイムが関連付けられるならその様にしなければならない

仮に　a とｂが与えられて戻り値がどちらかになるのであれば

「寿命が短い方を共通の寿命」と考えることが必要になる
そうしないと死んでる奴を参照しちゃうから

それを元にライフタイムの範囲を判定してはみ出てたらコンパイルエラーにする

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

発想を逆転させな？
「変数が生きている間しか参照は存在できない」

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

>>342
コンパイラはライフタイム注釈の推論をしていない
>>338に公式ソースを示したから読もう！
ライフタイム注釈は原則としてプログラマーが与えるべきもの
ただし例えば1対1に対応しているような、与えなくても自明な場合に省略できる
そして省略されている時にコンパイラが機械的に補うルールが定められている
結果的にプログラムは全てライフタイム注釈されていることになる

つまりコンパイラが推論することはなく
コンパイラがすることは省略を機械的に補うことと
ライフタイム注釈がすべて揃ったプログラムに対してのジャッジ

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

参照というのは実体がないと生きられないの
関数の引数や戻り値が参照だけだと実体がどれだけ生きてるかわからんでしょ？

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

ライフタイム自体はコードが書かれた時点で決まってる
それがおかしくないか判定するときのヒントがライフタイム注釈

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

>>349
はい、rustは型推論をしないのは知ってます
しかしそれが何故なのか分からないんです
例えばHaskellなら一才の型注釈は省略が可能です
全ての型は全てコンパイラによって推論され、型注釈を入れてコンパイルできるプログラムは型注釈を全消ししても(ただし効率のためにmtoplevel monomorphism restrictionというシステムが邪魔してくれますけどそれ外せば)必ずコンパイラが正しく推論してコンパイルしてくれます、その推論メカニズムの理論的根拠は論文として寄稿されネットにいくらでも転がってます
知りたいのはRustのライフタイム注釈は推論して省略可能だけどいつもいつも省略可能なわけではないのは、
・そもそもいつでも推論可能なわけではないので基本宣言させる、コンパイラが推論可能な限られたケースでは可能としている
・いつでも推論可能(私にはそう思える)のだけど効率を考えてそうしない(Haskell の toplevel monomorphic restrictionと同じように)
のどっちなんだろうと
そしてその話をtegulationに求めないのは必ずしもregulationは最新の研究を反映しているわけではないからです
つまり“現在のregulatinでは推論しない”という現状が必ずしも“そもそも推論などできない”を必ずしも意味しないからです
私ちょっとプログラミング言語論齧ってた事がありましてその辺の理論的背景どうなってるのかちょっと知りたいもので

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

お前のお気持ち表明はいらん

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

>>352
Rustは型推論します
非常に便利です

ただし間違った型推論の連鎖を起こす混乱やニワタマ問題などを避けるために
関数の引数値と返値については(ジェネリックを除き)
敢えてプログラマーに明確に型宣言させています
つまり型推論が可能な領域はもっと広いけど
意図的にRustは一定の範囲内に抑えていることになります

ライフタイム注釈についても同様で
推論可能な領域は確かに存在するけれど
意図的にRustは推論をせずに機械的な省略補完ルールの適用のみに抑えていることになります

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

そして明確に型宣言することが基本である関数の引数値と返値についても
ジェネリックな型とそのトレイト境界による制限を用いることで個別の型宣言をさけることができるし
さらに型宣言の位置に「impl トレイト名」という形で静的なopaqueな型指定をしたり
「dyn トレイト名」という形で動的な型指定をすることで
幅広い型を受け付ける関数を書くこともできたり
複雑な型を返す時にそれを明示せずに済むなど
Rustでは型推論とは別のアプローチで利便性と可読性の向上に役立っています

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

ChatGPTみたいなレスだな…

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

>>354
そうですね
一般的には“コンパイラにできないわけではない”場合でもユーザーにあえて“注釈をつけさせる”事が非常に便利な場合があります
多分Rustのライフタイム注釈もそれだと思ってはいるんですけど、ほんとにそれで間違い無いのか文書でまとめられたものがないか確認したいんです
HaskellやRustの型推論システムはもう論文でいくつか読んだ事があるのでそのメカニズムもまぁわかります
Rustのライフタイム注釈の場合も多分同じ事ができそうだとは思ってるんですけど敢えてか何故かやってない、それが“できそう”と思ってる自分の勘違いなのか、やはり“できるけど敢えてやってない”のか、あるいは現時点の最新研究でどこまではできることが確認されているのかとかその辺の情報持ってる人いないかなと

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

いやいや
関数を使う人間側が推論不可だろ

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

NGでスッキリ

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

ググったら理由が出てきた

基本的に関数シグネチャが変わるような事態を避けたいようだ
関数内部を変更したら推論されるライフタイムを含んだシグネチャも変わってしまう事態が起こりうる

変更で呼び出した側であちこちにボコボココンパイルエラーが出るのはプログラマ的にうれしくないので避けてる
呼び出し規約は人間が決めてそれをコードを書く側が守ると言うこと

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

Rustは関数単位で色んなチェックしてるけど
その関数が「どこでどう使われているか」を材料にして検証とか推論はしないし
最初からそんなつもりはないと思う

関数を全部インライン展開して１つのmain関数にできれば理論的には全部推論できそうだけど
関数ポインタとかdyn traitを使った動的な呼び出しが絡むと多分無理
Haskellレベルの推論は動的な呼び出しが存在しない参照透過性？が前提にあるはず

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

推論されたライフタイムを含むシグネチャと人間側が思ってる必要なシグネチャ（ライフタイム）と違うことが起こりうる

例えば他人が作ったライブラリのコードが変わって自分のところに波及してきたら嫌だろ？
従来のはそのままで別のシグネチャの関数を作れと思うだろ？

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

イヤ、ライふタイム注釈の推論に“使われる場所”まで検証する必要はないですよ
関数の返り値を作成してる右辺値を調べればそれで十分だと思います
その単位で返り値のライフタイム注釈が決定されれは、返り値が解放後に参照されるエラーが発生するか否かはその返り値を利用する呼び出し側関数のコンパイル時点で検出できると思います

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

>>332
論文を探す前にチュートリアルを読みましょう

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

せっかくググって答えを見つけてきたのにガン無視されてる…

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

いい感じにゴミ集積所になりつつあるな

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

ゴミクズ荒らすなよ

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

最初は実質ライフタイムの使い方がわからないと言うのが徐々に軌道修正されて変なところまでたどり着いた

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

>>382
コンパイラが推論する型と人間が想定する型が違うなんてもちろん日常茶飯事ですね
Haskell使ってて:tで推論した型表示させたら「うおーなんじゃこりゃ」と思うことなんてしょっちゅうです
コンパイラは右辺値(haskellでは表現)が提供可能な“最大に一般的な型”を与えようとします、そしてその「提供可能な最大の多層型」の中に関数の利用者が要求する利用可能ないずれかの型が含まれるかどうかを確認して可能ならその単相型を導出し、無理ならコンパイルエラーを吐きます
そして同じメカニズムは多分Rustのライフタイム注釈でも可能なはずです
しかしいくつか当たったRustのライフタイム注釈の解説文書のなかにはあたかも「それは不可能なのでプログラマに注釈をつけさせる」という類の説明がついてることが多いんです
それ見てホントかと、しかもその手の文書についてる例では明らかに推論可能でそれくらいコンパイラが自分でできるやろというくだらない作業をプログラマに強いてるだけの例がついてる事が多いんですよ
それがRustの“仕様”であるならそれはそれでいいんですけど、それを強いる理由が「推論することが不可能だから」と説明してるのがおかしいなと、何か自分の気付いてない勘違いしてるのかなと

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

>>369
コンパイラから外されて実装してないから不可能だろ
それも事実を表してる

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

わかったから消えろ

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

完全に推論可能かは知らないが実害があるのでそもそも実装されていない

ただあからさまな場合は省略可能

コンパイラも楽だろ
戻り値のライフタイム覚えておいて型を返す場所でチェックするだけだし

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

>>372
そうですね、多分コンパイラが楽だからがホントの理由な気がします
推論するには最低限その関数の関数定義が終了する時点まで読まなければならないですからね
しかし実際には関数の終わりの時点まで読んだ段階で完全に決定してその1回目の読み、ワンバス目で終わる気はします、少なくともコンパイラの世界の暗黙の了解「線形オーダーで解決しなくてはいけない」はクリアするとは思います、(勘ですけど)
まぁそれでも「必ず宣言するように、異論は認めない」が仕様ならそれはそれで結構なんですけどそれを「できないから宣言するしかないんです」という説明はある程度以上を勉強するつもりの人が読むと多分混乱招くと思うんですよ
初学者が余計な気を回さないように「できない、信じろ、なので宣言しろ」は初学者向けの説明でありかなとは思わないではないんですけどね
そこでちゃんとした論文ないもんかと

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

もしかして、クロージャなら式から推論してるのかな
関数のシグネチャはフルで書かなきゃいけないってだけで

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

クロージャは型推論してくれるからそういう用途に使える
集合としてみてもfnよりFnを満たす集合の方が大きい
逆にクロージャでも型指定を要求されることもある

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

いずれにせよ、Rustは、自由と民主主義をベースとする西側諸国
の価値観には合わず、中国と同じ社会主義的な東側諸国の価値観
に合っている。この言語が成功することはIT産業が壊滅状態になる
ことを意味する。

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

自分達の作った言語を普及させるためには、無料にして、他の業者
がどれだけ迷惑を被っても構わないというスタンスをとる。
このことは、世界の中心でありもっとも進んだ国であるところの
中国の価値観を広めるためには、人民の犠牲もいとわない、
他国がどれだけ苦しんでも構わない、むしろ歓迎する、などという
中国のスタンスと共通する。

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

もっとも優れた政治経済思想であると事の中国流社会主義を
世界に広めるためには、どんな犠牲もいとわず、どんな
人権侵害も環境破壊もいとわず、経済ルールを無視して独自
ルールを徹底し、言論統制し本当の情報を流さない、
という中国のスタンスと、Rust信者達が行っているスタンスは
そっくりである。

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

中国人は洗脳の結果、自分達が世界最高の政治体制を持つ偉大な
国家であり、その思想と政治体制を世界中に教えてあげなければ
ならないと思っている。
そしてアジアの最高の先進国は中国であり、日本より上回っている
と勝手に思い込んでいる。
この状況とRust信者の脳内心理はそっくりである。

**デフォルトの名無しさん** · 2023/07/09(日) 04:44:46.78

>>376
IT産業の壊滅とか最高じゃん。一番損をするのは覇権国のアメリカ、一番得するのは出遅れた日本だからねぇ。
ちなみにOSSとITの民主化は中国などのレッドチームを追い詰めることに繋がると思うぞ。お得意の世論統制が難しくなるからね。

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

>>376
お前誰からも必要とされてないから消えて

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

>>381
可哀想だからそんなこと言ってあげるな
病気なんだから
居場所はどこにもないんだよ

**デフォルトの名無しさん** · 2023/07/09(日) 08:32:03.98

マシな流れからまたクソな流れになってきそうだな

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

RustはDynamicRustみたいな感じのRustコンパイラ上で動くスクリプト言語が有っても面白いかもな。

**デフォルトの名無しさん** · 2023/07/09(日) 11:03:32.10

頭のおかしいネトウヨがアンチrust側で良かった

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

>>385
ネトウヨって何？
ここはRustとC,C++の比較及びその他プログラミング系の話をする板であり君の様な差別主義者は別の板に行きなよ。

**デフォルトの名無しさん** · 2023/07/09(日) 12:20:32.66

>>379
>この状況とRust信者の脳内心理はそっくりである。
お前さんの言動は統合失調症の患者さんとそっくりだよ

**デフォルトの名無しさん** · 2023/07/09(日) 13:41:10.77

効きすぎだろw

**デフォルトの名無しさん** · 2023/07/09(日) 14:20:00.41

Rustなら失敗しなかったと思う割とマジで
https://www.youtube.com/watch?v=XDy0dqZrbN4

**デフォルトの名無しさん** · 2023/07/09(日) 14:21:39.84

だれもRustの使用を強制してないのに強制されてると思い込んでるあたりが危険だな…

どこかの大臣が「Rustの利便性向上のためにC++コンパイラを廃止します」とか言い出したら騒いでもいいけど

**デフォルトの名無しさん** · 2023/07/09(日) 14:30:11.62

>>337
Rustが安全であるという考え方が最も危険である

**デフォルトの名無しさん** · 2023/07/09(日) 15:40:54.31

>>308
それが本当なら水虫言語じゃん

**デフォルトの名無しさん** · 2023/07/09(日) 15:57:49.89

糖質だから仕方ない
誰からも必要とされてないことすら気がつかないのだから

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

RustがC/C++に似ているとか、構文が便利だとか本気で思っている
方が統合失調症だ。病院で見てもらえ。

**デフォルトの名無しさん** · 2023/07/09(日) 18:47:10.60

Rustが爆発的に飛躍するには何が足りないの？

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

学習コスト低減、ライブラリ作成支援
何よりもRustの案件・求人の増加

**デフォルトの名無しさん** · 2023/07/09(日) 19:08:06.34

誰からも必要とされてない人
今日もよく喋るな

**デフォルトの名無しさん** · 2023/07/09(日) 19:43:24.19

せいぜい、人から必要とされまくって楽しい人生を謳歌しろよ。
ww

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

行列積ってマルチスレッドで実装すべき？それとも、キャッシュやコピーを減らすためにシングルスレッドの方が良いのかな？

**デフォルトの名無しさん** · 2023/07/09(日) 20:44:21.03

GPUに投げるべき

**デフォルトの名無しさん** · 2023/07/09(日) 20:46:14.43

真面目な話するとプロファイル取ってサイズで分岐すればいいんじゃないすかね

**デフォルトの名無しさん** · 2023/07/09(日) 21:34:02.14

>>399
parallel=trueみたいなオプションをどこかに書けばスレッド使うようにする

**デフォルトの名無しさん** · 2023/07/09(日) 21:55:27.03

>>400
GPUを使った並列演算処理を提供するRustのクレートで良いのは何？できれば、GPUのデバイスによらずに操作が抽象化されてるものが良いな。

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

四次元ポケットがあるかのような話だな…

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

C++にはあるんじゃね？

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

rust-gpuとかいうクレートはどうなの？これはcudaがないと動作しない感じ？

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

CUDAとかOpenCLとか書かれているから、CUDAでなくても動くんじゃね？

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

GPUは考えなくて良いと思う
まずはCPUのシングルノードで性能を出すことが大事
GPU使えるなら現状は生のCUDAやpytorch使うので

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

どうしてOSSの人って自分が良い事してると思ってるのか。
競合企業には悪魔なのに。

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

慈善でやってると思ってる阿呆

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

>>408
現状ではnumpyではCPUってどれくらい効率的に使用できてるの？

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

>>409
OSSはOSSの仲間に寄与してるんであって、
おそらく適価でソフトを売ってくれないだろう競合企業とはなんら関係を持たないからね

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

>>409
お，無根拠なOSS批判だ

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

>>320
「料理を自由にやられたら料理人が困るだろ！」
「レシピを共有するやつはカルトだ！左翼だ！」
って言ってるようなもの
料理人は家庭では難しい料理をつくるなり
サービスで付加価値をつけるなり
マネタイズ方法はいくらでもある

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

>>356
ChatGPTωには無理ωωω

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

>>395
信者が足りない
逆に多過ぎるのはcrates.io
もっと整理するべき

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

>>400
それ

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

>>403
NdArray
BLAS

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

>>411
君の言う効率的の意味が単純に速度ということなら
全てin-place演算子かつ同じメモリを使い回すような書き方をすればキャッシュヒット率が高くなり
ベクトル演算を使うので生のCで書くより速い
rustでこの速度と同等まで持っていくのはなかなかしんどいが
非同期IOやスレッドを組み合わせることで
大規模な演算では上をいける可能性はなくはない

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

例えばメモリに乗らないようなクソでかい行列の積が上げられる
MMLなどの学習時に使われる多次元配列は普通にやるとメモリに乗らないので
ファイルに吐くことになる
その時非同期IOやスレッドを駆使できるrustの方が速くなるのではないかと思う

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

普通にやるとメモリに乗らないので、モンスターマシンを使う、とかじゃないん。

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

ファイルなら無限大

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

>>421
それをやれるのは一部の企業のみ
LLMは推論だけでGPUメモリが数百G必要だからね

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

Rustで５ちゃんみたいな掲示板作れないの？

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

当然作れるけど言語に関係なく
無数にSNSがある状況で宣伝資本がなければ集客が無理
さらに犯罪予告から怒涛の妨害書き込みへの対処が面倒

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

とりあえずrust純正の多次元配列の実装の以下の感じでやって行こうと思う。

シングルスレッドでの多次元配列の演算の実装
　　　　　　　　　⬇
CPUベースのマルチスレッド(rayonとtokioを主に使用)での演算の最適化の実装
　　　　　　　　　⬇
requires_gradの実装(これもマルチスレッドでの計算最適化を適用。)
　　　　　　　　　⬇
余裕があればGPUベースの並列演算機能も実装。これはできればcudaがなくともGPUの種類によらない計算ができるようにしたい。

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

Numpyは多次元配列の中身を1次元配列に変換して持っているけど、多次元インデックスから内部の配列の対応するインデックスを一々計算してるのかなぁ？

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

行とか列に沿って数値処理する計算ならインデクスを一定間隔でずらせばいいでしょ
ランダムアクセスならどうしようもないけど

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

>>423
そんな状態では、学習に莫大な時間が掛かり、
恐らく結果が10年後とかになる。

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

それと、数100Gバイト位なら、スパコンならRAMにおいて
問題ないだろう。

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

M*Nの巨大なメモリを一気に確保できる範囲内ならばそれが可能だけど無理な場合もありそう
例えばM=N=100万とすると
1要素64bitとして1列分は64MBだけど
行列全体は64TBだね

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

>>414
それとはかなり違う。
料理の場合：
1. 本当に優れた料理人のレシピは公開されて無い。
(もし公開されている、とされていても、本物かどうか分からない。)
2. レシピがあっても、腕が無いと作れない。
3. 仮に作れても、手間がかかるので料金を払ってでも、作ってもらって
　食べたい人が大勢いる。

ソフトウェアの場合、特に 3 の部分が全く違っていて、
簡単にコピーできてしまう特徴がある。

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

>>431
どうやってるんだろうな。
熱力学や統計力学などの物理学や数学を駆使してるんだろう。
恐らく、幾何学的に距離が遠すぎる結合は 0 と仮定しているんじゃなかろうか。
脳もそうだろうし。

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

>>429
複数ノード使えばなんの問題もない
今のスパコンはほぼそれ
俺が普段やってる流体や量子化学計算も
32コア程度のマシンを複数台で1週間計算したりしてる
今のpytorchはasync使ってないから行列計算を並行してできるところも全てブロックしてる
GPUへの転送もブロックする処理をしてる
シングルノードで超高性能のGPUで力技で計算するというのは普通の企業では難しい
クラウド使っても費用が半端ない
CPUでの高速化を実現しコストを下げることができれば次のステージへ行ける

なんか運営でゴタゴタが起きてるらしく
スレの読み込みができなくなったから改善しないと今後は書き込まないかも