Rust part37

公式
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 part36
https://mevius.5ch.io/test/read.cgi/tech/1779974768/

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

>>876
> 基本はスタック領域を活用
この時点で嘘なんだよな
Rustはプリミティブ値以外ほとんどヒープに置く
配列よりもVecを使う言語だぞ

>>875
スタックに大きなデータを置いても構わない
推奨なんてものはない
例えば全てのデータをスタックに置いてL2キャッシュの恩恵により高速に動かすことなど普通に行われている

>>878
ダウト
スタックに置くこととL2キャッシュに載ることに関連性はない

>>877
初心者なのかもしれんがRustではスタック上で配列を使うクレートも盛んに使われているぞ
適材適所で使い分けが肝心

言い争ってる内容のレベルが日々下がってくね

>>880
そりゃ機能があるのに全く使われてないと仮定するのは無理があるし、そんなことは言ってないでしょ
「よりも」はゼロヒャクじゃないよ

>>881
Rustろくに書いたことないのにゼロヒャクで断言したがる奴が多すぎるんだよな

>>879の補足
CPUのキャッシュはヒープ領域のデータでも使用頻度が高ければキャッシュするので、スタック領域かヒープ領域かは関係がない
そのためにキャッシュラインに合わせてアラインメントしてヒープ領域を使うということも行われる
また、スタック領域に置かれていてもアラインメントがされていなければキャッシュ効率が悪くなることも普通にある

メモリ空間をOSが管理してると、ヒープ領域を使うのにいちいちシステムコールが必要になるから、欠点が目立つんだよな
でもスタック領域に欠点がないかと言えば、別にそんなこともないから使い分けが必要

>>879
スタック上で処理したほうが圧倒的に有利になっている理由は、他のローカル変数はスタック上にあり、関数呼び出し時もスタックを用いるため
メモリの使用範囲がスタック上のみに限定され、メモリキャッシュ効果が最大限に発揮されます

>>886
そもそもスタック領域を大きくしたらスタック全体がキャッシュに乗らなくなるし、ヒープでも確保を工夫すればキャッシュに乗せられるので、ほとんど関係がない

>>887
大きさ問題はその両者で中立。
ヒープだけを使うことは不可能だがスタックだけを使うことは可能だから必ずスタックが有利になる。

仮に (あくまでも仮に) スタックの多用が全面的にメリットばかりだとしてもたとえば Linux のデフォルトだとスタックの上限はたった 8MB だぞ。
上限を引き上げる設定をやったことなんてほとんどないだろ。みんなスタック 8MB でやりくりしてるんだよ。

> スタックの多用が全面的にメリットばかり
正にこれが間違い

ヒープ領域に確保する方が関係データを含めてアクセスローカリティを考慮したデータレイアウト設計が出来る

組み込みだとスタックが浅いからって
関数呼び出しはするな
引数も使うな
全部グローバルでやりとりしろ
みたいな流儀があったらしいと聞くが
なんでそういう絶対的な制約があるわけでもないのに似たような縛りプレイやろうとしてるんだろう

>>889
8MBはデフォルト値にすぎないから
起動プロセスのための環境変数を設定するタイミングと同じように
起動直前で例えばulimit -s 65536すれば子プロセスのみスタック領域を64MBに変えることができるよ

>>892
デフォルトなのは知ってるからデフォルトって書いてるだろ。
変更できるのは知ってるから、でも変更したことないだろ (それが普通) って話をしてる。

スタック領域サイズだけに限らず諸々のリソースのパラメータは各用途に応じて設定して運用が行われている

Rustってすごい言語なんですね

>各用途に応じて設定して運用が行われている
(つまり、各用途に応じた設定をして運用を行ったことはない)

>>895
リソースパラメタ変更して運用はRust登場以前から普通に行われている

>>890
そもそもスタックが全てキャッシュに乗るわけでも、データが全てキャッシュに乗るわけでもなく、使ったものがキャッシュに乗る
なのでスタックにあるかどうかは関係ないし、そこに固執してるのは知識がないから

ごめん、>>888だった

複おじの妄想は相手しなくていいよ

>>898
スタックは必ず使われるからキャッシュに必ず乗り必ず有利になることは常識

>>901
キャッシュはキャッシュラインの単位ごとにしか乗らないので、巨大データをスタックに置いたところで他の変数と一緒にキャッシュに乗ることは保証されない
一方でヒープに置いた場合でも、一度使えばキャッシュに乗るため繰り返し使う時に高速で扱える

> 必ず乗り
そんなわけない

キャッシュが無限に容量があって無限に高速なメモリだとでも仮定しないと、必ず乗るなんて主張は成立させられないはずなのだが
それにヒープ領域はキャッシュに乗らないと頑なに信じているらしいが、CPU設計者をそこまでバカにする理由もよくわからない
わざわざ大量の計算をしてスタック領域だけを見分けてキャッシュに乗せる、そんな無意味なことをするとなぜ信じられるのだろうか

レジスタ退避でいつもL1に乗るからスタック上にあるローカル変数は速いよね

>>905
いつでもL1に乗るなんてありえない妄想
そもそもL1は8MiBもねえじゃん

>>905
レジスタ退避について勘違いしてるよ

>>905
シンプルに教えてほしいんだけど、レジスタやL1が8MiBもあるCPUってどこにあるんだい？

topcoatてこれwasmじゃなくてjsに変換するらしいけど普通にjs書いたほうがよくね？

人類はいつまでJavaScriptに苦しめられるのでしょうか？
WASMを作った連中に覚悟があれば、今頃はC++でWebアプリを作れたでしょうに

Rustってハードパワーのゴリ押しみたいな側面もあるんで
そういうこと

来年WASMでDOM操作とfetchできるようになるから待ってて

フロントエンドはJavaScript側のエコシステムで対応しないと
思ってる以上に早く負債になって失敗、後悔するというのは
これまでもRubyのほうのRailsが散々証明してくれてるからな

てか10日間で設計されたうんこスクリプトをWEBのデファクトにするて人類ガイジすぎやろ

さすがにここまで来たら10日間で作った部分は消え去ってるんじゃねーの

>>907
レジスタは明示的にpushしなくてもripなどの命令ポインタはcallすると自動的にスタックに退避されるよ

>>911
そんなわけなくて草
それでCと同じ速度が出るわけねえだろ

>>916
関数を呼び出す時にスタックにレジスタの値を退避するというのは、スタックで現在処理中の値やプログラムの実行位置を管理してるからで、呼び出した関数から戻ってくるまでそれらの値をスタックに置いておくということでしかない
呼び出した関数から戻ってきた時にこれらの値をレジスタに戻すことで、同じ位置から処理を再開するというのがこの機能の目的であって、キャッシュとは何も関係がない

また、スタック領域に置かれた変数が全てレジスタに書きこまれているわけではない（それどころか、レジスタは全部合わせても大した数がなく、データ置き場としては使えない）し、スタック領域に置かれた変数が全てキャッシュに乗るといった事実もない（当然ながら、あまり使われなければキャッシュには置かない）

>>918
キャッシュとは何も関係がない？ってアホやな
スタックに退避されるとスタックのその前後はキャッシュに載る
その前後にはローカル変数がいる
だから速さの恩恵を受ける

キャッシュに載ってなかったら、キャッシュレス？

>>919
> スタックに退避されるとスタックのその前後はキャッシュに載る
> その前後にはローカル変数がいる
> だから速さの恩恵を受ける

複数の誤謬が含まれている

まず第一に、レジスタがスタックに退避される時のキャッシュへの読み込みはキャッシュライン単位でしか行われないので、64バイトを超えた分はキャッシュに読み込まれない
そのため、巨大データをスタックに置くことでキャッシュ上有利に扱えるということは、この時点でなくなっている

次に、実際にはローカル変数だけでなく、戻りアドレスや呼び出し元のフレームポインタ、レジスタが不足した時の退避先などもスタックに置かれるため、実際には64バイトから8バイトのレジスタ分を引いて残りが全てローカル変数、ということにもならない
そのため、そこまで大きくないデータであってもスタックへのレジスタ退避でキャッシュに乗るとは限らない

更に、キャッシュはスタックへのレジスタ退避の時しか行われないわけではない
既に散々書かれているようにしか見えないのだが、スタックだろうがヒープだろうが読み書きすればキャッシュに乗り、使われ続ければ保持されるためスタックへのレジスタ退避とは無関係に、キャッシュの挙動に合わせたデータが有利に速さの恩恵を受ける
そして、スタックとローカル変数はこれに最適化されていない

説明もなく64バイトと書いてしまったが、これは一般的なCPUのL1キャッシュで比較的多く採用されている、キャッシュラインの大きさである

> キャッシュはスタックへのレジスタ退避の時しか行われないわけではない
結局これよな
ずっと変なこと言ってる奴いるけど、レジスタ退避もスタック/ヒープも関係なく使っていればキャッシュはされる

スタックじゃないとキャッシュに乗らないとか、レジスタ退避の時にしかキャッシュに乗らないとか、とにかくCPUの設計者をバカだと思いすぎだよな
そんなバカな設計になってるわけないのに、頭を使ってない奴はこれだから

自演連投と論点ずらしの傾向がだんだんわかってきた
>>924はついに「スタックじゃないとキャッシュに乗らないとか、レジスタ退避の時にしかキャッシュに乗らないとか、」など
誰の書き込みにも存在していない方向へ話をずらしている

ディープコピー: 大きなサイズのメモリをコピーすること
スタック巻き戻し: ベースポインタの値をスタックからpopすること
レジスタ退避: リターンアドレスをスタックにpushすること

こりゃ大変だ

もういちいち追ってないけどなんか新情報出てたら教えてくれ

相変わらずUIはGUIよりratatuiが圧倒的

>>926
おじいちゃん、大昔はスタックフレームの管理にベースポインタ(bp/ebp/rbpなど)を使ったけれど
現在はどこのABIでもベースポインタなんて使わないんだよ
無駄だからね

>>925-926
都合が悪くなると攻撃的なことを言ったりバカにしたりして話をそらしてるのはいつもお前だよｗ
複おじらしい嘘つきっぷり

>>926
たしかにお前の頭が大変だな、何一つ読めていないせいで全部間違ってるｗ

>>925
ずっと言ってる奴いただろ
いくら勝てなくなったからって嘘はよくない

少なくともヒープだとキャッシュには乗らない、レジスタ退避がキャッシュ性能に大きな影響を与えるとは確実に言ってたな

> スタックじゃないとキャッシュに乗らないとか、レジスタ退避の時にしかキャッシュに乗らないとか

も曲解ではなく言い換えでしかない

>>929
そりゃそうよな

>>925-926
相変わらず書いてあることは読めないし、妄想力は豊かだよね
まあどうせ否定するだろうけど、https://mevius.5ch.io/test/read.cgi/tech/1774264073/679-683 でも散々言われてたように国語ができてなさすぎるよ君
すぐに自演バレするのは、毎回同じ誤読の仕方をするからなんだよ

>>要するに、文脈や構造を見ず文中の単語だけをつまみ食いして、「〜って言ってる！」と脳内変換してしまう、いわゆる**機能的文脈文盲**（単語は読めても構造が理解できない状態）ですね。

これAIの回答っぽいだけに辛辣すぎて笑った

決定的な認知のゆがみがある奴おるよな
某スレだと「〇おじ」とか
この板に限らずだと古くは「〇の壁」とか
思い込みの世界から一歩も外に出てこないのと
意固地になってるのか
もともと粘着質なのか知らんけど
いつでもどこでもいつまでも聖戦を繰り広げてる

バカはまともに文章を読めないくせに、そこに書いてる単語から自分にとって都合のいい物語を作ることには熱心だからな

また複オジ4連投キタ

>>938
お前やｗ

複おじはやたら何連投って言いたがるけど、自分はID変えるからバレないと思ってるんだろうな

どうぜ図星だったんだろｗ

どっちが複おじでどっちが複オジかしらんがまた真夜中ずっと争ってたのか

自演じゃないよ〜ん

伝えたいことはもともとびっくりするくらいシンプルなんだけど（大きいデータをコピーするとコストがかかるから気をつけよう！とか）
よく知らない専門用語を雑に当てはめてしまうから、本人以外はその専門用語が正確な意味で使われていると思って誤読してしまう、ということが発生しているんだろうなあと推測しました

>>929
これは単純に知らなかったからありがとうね

IDコロコロの誰かさんも自演を訴え始めた今こそ満場一致でワッチョイに移行する好機なのでは？

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

sp を bp (ebp, rbp) に退避するのは元から ABI の要求に含まれてない。
ABI はインターフェイスの規定なので呼び出し側にとって sp のつじつまが合っていればどんなやり方で実現してもどうでもいいから退避のやり方までは規定する必要がない。
bp を使っていたのは単なる慣例。

スタックトレースのやりやすさとかの都合で今でもデバッグモードではごく普通に bp を使うし、無用になったというわけでもない。

>>947
RustでもC++でもDWARF情報でデバッグできるから今はbp不要

>>943
> よく知らない専門用語を雑に当てはめてしまうから、本人以外はその専門用語が正確な意味で使われていると思って誤読してしまう
逆では
毎回「そんな定義はない、こうだ！」って主張してる側が定義を間違えてる

>>要するに、文脈や構造を見ず文中の単語だけをつまみ食いして、「〜って言ってる！」と脳内変換してしまう、いわゆる**機能的文脈文盲**（単語は読めても構造が理解できない状態）ですね。

ローカル変数のムーブをディープコピーだと言い張ったりな

参照を含むデータならば
moveやcopyはシャローコピー
参照先も処理するcloneならばディープコピー

参照を含まないデータならば
moveやcopyは単なるコピー
区別する2種類がないためシャローやディープは使われない

いずれにせよmoveをディープコピーと呼ぶことはない

>>951-952
また複おじが妄想を垂れ流し始めたな
散々言われてたことは全部無視して仕切りなおせると思っているらしい

>>952
コピーは発生しないって自信満々に言ってたのに……ｗ

>>952
それ>>827あたりではっきり否定されてた話を書き直しただけな

そもそも複オジはまともなプログラミング知識がないから、言われたことを覚えておけないのも仕方ない
こいつ間違ったことしか言わないし、誤読しかしない

複おじの行動原理はAIに「自分の理解不足を相手の説明能力・理解力のせいにする方が楽だから」と言われてたよなｗ

>>827は間違ってる
まずスタックやヒープなんて無関係でどこにあってもいい
そのデータをアドレス/ポインタ/参照などで指すデータがある時に、指す先のデータもコピーすればディープコピー
指す先がなければディープは存在しないためディープコピーと言わない

>>952
「複製する」というアクションを区別する話と
「複製物」という複製した結果として生じるオブジェクトを区別する話を混同してる

moveやcopyは対象が参照を含もうが含むまいが分岐はなくやることは同じ
つまり「複製する」というアクションの区別で言えばシャローコピー

複製された結果の「複製物」の区別で言えば
参照を含まないのであれば複製物がシャローかディープかを論じる意味はない
(これはMDNの定義に書いてある通り)

>>958
それも>>733-734で否定されたことをもう一回言ってるだけね
普通にわかってないんだからROMってた方がいいよ君

元々はこれだろ

>>671
>>スタック領域に大きなデータを置くと関数の壁を跨ぐ度にディープコピーになる

671がディープコピーを誤用したから荒れた

>>959
最後の段落はMDNの定義に書いてないし、むしろ矛盾してる
MDNではプリミティブ値についてはシャローコピーとディープコピーは同時に成立するため、通常この区別を論じる必要はないとしている
参照を含むかどうかといった話はされておらず、配列や構造体などプリミティブでないオブジェクトにおいて、この区別が論じられるものということになる

また、中段についてはcopyとmoveに対する誤解がある
copyの場合は値、つまり実体が複製されることになるためMDNの定義によるとディープコピー
一方でmoveは通常（ここは重要）管理構造体しかコピーしないのでシャローコピーとなる

moveにおいて「通常」と強調したのは、スタック領域に実体が置かれている場合、戻り値に指定するとmoveでも実体のコピーが発生する（仕様上の話。最適化の話はまた別）ため、ディープコピーの条件を満たすため

>>961
それも>>733-734で否定されたことをもう一回言ってるだけだね、それは誤用じゃなくて正しい用法だよ
普通にわかってないんだからROMってた方がいいよ君

ディープコピー（深いコピー）とは - IT用語辞典 e-Words
https://e-words.jp/w/%E3%83%87%E3%82%A3%E3%83%BC%E3%83%97%E3%82%B3%E3%83%94%E3%83%BC.html

> ディープコピーとは、配列やオブジェクトなどのデータ構造を複製する際、同じ構造の実体を新たに作成して対応するデータを写し取る方式。


Deep copy (ディープコピー) - 用語集 | MDN
https://developer.mozilla.org/ja/docs/Glossary/Deep_copy

> オブジェクトの ディープコピー とは、コピー先のオブジェクトのプロパティがコピー元のオブジェクトのプロパティと同一の参照（同じ値を指す）で共有しないコピー方法のことです。結果として、コピー元かコピー先のどちらかを変更しても、もう一方オブジェクトにも変更を及ぼしていないことを保証できます。すなわち、コピー元かコピー先に意図せずに予期しない変更が加えられるこはありません。この振る舞いはシャローコピーとは対照的です。シャローコピーでは、コピー元かコピー先のどちらかを変更するともう一方のオブジェクトも変更される可能性があります。

> プロパティがすべてプリミティブ値であるオブジェクトのコピーは、ディープコピーとシャローコピーの両方の定義に当てはまります。しかし、このようなコピーの深さについて話すのはやや無意味です。というのも、このコピーには入れ子プロパティがなく、ディープコピーについては通常、入れ子プロパティを変更するコンテキストで話すからです。

>>961
>>671じゃなくてお前が誤用してるだけな

>>962
関数が構造体を返すのは単なるコピー
参照先を持つならシャローコピーと呼んでもよいがディープコピーではない

>>966
お前の独自定義ではそうなんだな
でも俺は今そんな話はしてないんだ

Rustなら話は非常に簡単だよね
関数がVecなど構造体を返すのはシャローコピー
clone()して返すとディープコピー

>>968
構造体にもいろいろあるからややこしい
データの実体をどう考えるかという話で、Vecはスタックに置かれる管理構造体は実体ではなくて、データの実体はヒープに置かれた可変長の配列データなので、シャローコピーになる
でも構造体自体がデータの実体なら、そのコピーはディープコピーとなる

>>968
Rustはディープコピーが必ずcloneになるから分かりやすいよな

.clone() は管理構造体だけでなくヒープに置かれた可変長の配列データという実体をコピーするので、当然ディープコピー
ただ、.clone() 以外の方法で実体をコピーすることもできて、それがCopyトレイトと呼ばれるもの
Rustの場合はこのCopyトレイトがあれば、.clone() でなく代入によってディープコピーを行うことができる

Rustではあくまで標準状態がmoveなだけで、copyが利用できないわけではないので、プリミティブ値にはこのCopyトレイトが用意されている
この場合必ずディープコピーが発生する（MDNの記述通り、プリミティブ値についてはシャローコピーとディープコピーは同時に成立するため、通常この区別を論じる必要はない）

ただし、Copyトレイトはプログラマが定義した型に用意することもできるため、プリミティブ値でない値が必ずmoveすることは保証されない
この場合はシャローコピー（一部除くmove）とディープコピー（.clone() または Copyトレイト）が区別される必要がある

あれだよね、複オジが「そんなことするのはバカ」って言ってたけど実際はよくされている、moveで受け取ったデータを戻り値で返すを繰り返すパターンは、これがシャローコピーだから成り立っていると

せやな

一部、『構造体』と言った時にヒープの管理構造体しか思い浮かばない人が（複おじ以外にも）いるっぽいけど、Rustでは構造体は非常によく使われるので、データの実体を持っていることも普通にある
なので構造体がコピーされる = シャローコピーとは決まっていない