[表示 : 全て 最新50 1-99 101- 201- 2ch.scのread.cgiへ]
Update time : 07/21 19:31 / Filesize : 64 KB / Number-of Response : 204
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

Rustアンチスレ



1 名前:デフォルトの名無しさん [2017/10/26(木) 23:37:04.08 ID:9syp6YaG.net]
Hello World以上の事をやるとコンパイルが通らない()Rustのアンチスレです

136 名前:デフォルトの名無しさん mailto:sage [2022/05/23(月) 01:27:08.69 ID:aUQlcplw.net]
>>135
領域使い回せるってことは生成・解放するオブジェクトのサイズはだいたい一定なんだと思うけど
そうだとしたら最近の普通のmalloc実装ならそうそうフラグメント起こすことはない気がするけどどうなんだろ
ベンチマークとかあるの?

137 名前:デフォルトの名無しさん mailto:sage [2022/05/23(月) 01:35:14.45 ID:Fl/zPM6P.net]
>>136
行列クラス考えてみろ
while(1)
E = A*B+C/D
C++なら一行でかけるが

138 名前:デフォルトの名無しさん mailto:sage [2022/05/23(月) 01:45:51.46 ID:Fl/zPM6P.net]
誤送信
>>136
行列クラス考えてみろ
while(1)
E = A*B+C/D;
C++なら一行でかけるがテンポラリ領域を演算子の多重定義の中で確保開放繰り返さざるをえない
ETでなんとかなる部分もinverseがあるとそれもお手上げ
一時領域をwhileの外で確保してそれを使い回す方法と比べて早くしようがない。

139 名前:デフォルトの名無しさん mailto:sage [2022/05/23(月) 01:48:39.79 ID:Fl/zPM6P.net]
>>136
>普通のmalloc実装ならそうそうフラグメント起こすことはない

ヒープの動的確保でフラグメント興さないなら
RTOSでメモリプール確保する必要なんてないよなww

140 名前:デフォルトの名無しさん mailto:sage [2022/05/23(月) 02:08:18.18 ID:aUQlcplw.net]
>>138
速度に関してはC++の方が不利なことに対しては異論ないよ
ただフラグメントについては本当にそうなのか気になってた

今時のmallocなら直近にfreeされた領域再利用するから>>138みたいな例なら毎回同じ領域が割り当てられると思うよ
寿命が異なる複数のオブジェクトの確保・解放を繰り返すようなケースでも、オブジェクトが同サイズであればmalloc自体のフラグメントを防ぐ機構がうまく働いてくれるはず

まあ確かにRTOSのmalloc実装では問題起こるかもしれないけどね
ただ、そういうのは "最近の普通のmalloc" ではないと思う

141 名前:デフォルトの名無しさん mailto:sage [2022/05/23(月) 02:25:01.02 ID:Fl/zPM6P.net]
>>140
なんで同じ領域が確保されると保証されるのさ。今時のOSでww
そのエリアが外のタスクで割り当てられなかったことがなんで保証できるんだ?
とにかく動的確保、削除してフラグメント起こさないと思ってる方がどうかしてる。
そういう思い込みが通用するなら、所有権なんてもんは必要ないだろ。
あれはデフラグの対象にするかどうかが細大の目的

あと、普通のとか今時のとか、お前のあたのなかこっちは見られないんだから使うのやめろ

142 名前:デフォルトの名無しさん mailto:sage [2022/05/23(月) 02:44:22 ID:Fl/zPM6P.net]
>>138
>速度に関してはC++の方が不利

これもちょっと違うだろ
上で>>132が言ってるようにBetter cに留めて。
過度な見やすさや書きやすさを追求しなければ
C++はC機能包含してるんでC++で不利になることなんてない。
機能を使わなければいいんで不利になりようがない。
Pure C流ででもかけるわけだし

143 名前:デフォルトの名無しさん mailto:sage [2022/05/23(月) 08:16:07.89 ID:aUQlcplw.net]
>>141
とりあえずglibcのmallocでいいや
>>138のような解放直後に同じサイズで領域を確保する場合は領域再利用されるよね

144 名前:デフォルトの名無しさん mailto:sage [2022/05/23(月) 09:11:41 ID:n2ZPTBPD.net]
// ヒープを使う型Testを作って実証実験
#[derive(Debug)]
struct Test(Box<isize>);

// Test型が作成される時に使われるnew()を実装
impl Test {
fn new(n: isize) -> Self {
let new = Test(Box::new(n));
// その時にヒープで確保されたアドレスを表示
println!("{:p} = Test::new({n})", new.0);
new
}
}

// Test型の足し算を実装
impl std::ops::Add for Test {
type Output = Self;
fn add(self, rhs: Self) -> Self::Output {
Test::new(*self.0 + *rhs.0)
}
}

// 足し算の途中で使われる一時領域のアドレスはどうなるか?
fn main() {
let a = Test::new(1);
let b = Test::new(10);
let c = Test::new(100);
let d = Test::new(1000);
let e = Test::new(10000);
println!("{:?}", a + b + c + d + e);
}



145 名前:デフォルトの名無しさん mailto:sage [2022/05/23(月) 09:17:13.61 ID:n2ZPTBPD.net]
実行結果
0x55790623d9d0 = Test::new(1)
0x55790623d9f0 = Test::new(10)
0x55790623da10 = Test::new(100)
0x55790623da30 = Test::new(1000)
0x55790623da50 = Test::new(10000)
0x55790623da70 = Test::new(11)
0x55790623d9d0 = Test::new(111)
0x55790623da70 = Test::new(1111)
0x55790623d9d0 = Test::new(11111)
Test(11111)

つまり足し算で中間生成される一時的な領域は再利用されて使い回されていることが確認された
したがって>>141の主張がおかしい

146 名前:デフォルトの名無しさん mailto:sage [2022/05/23(月) 09:54:21.07 ID:n2ZPTBPD.net]
一般的に、今回のような多段の計算の場合は、中間領域が少なくとも2つ必要となる
なぜなら、一般的には「中間値2=中間値1+次の項目」と順に計算していくためである
つまり一般的な場合は、5つの変数の足し算ならば、中間値2つを加えて、計7つの領域を必要とする

しかし>>145の結果のアドレスを見ると、確かに中間値は交互にアドレスが異なり2種類だが、全体で6つの領域で済んでいるところに注目
5つの変数の領域は避けられないから、余分に確保されたのは1つのみで済んでいる
これがRust

今回用意したTest型はCopyを実装しなかったため、最初の「中間値1=a+b」を計算した時点てaとbは消費されてそれらの領域は解放される
そのため次の「中間値2=中間値1+c」の時に、中間値2の領域として既に解放されたaの領域が使われた
実際に中間値2のアドレスがaと同じになっていることで確認できる
同様に中間値3は中間値1と同じアドレスとなっている

結論
Rustでは消費し終えた変数や中間値が使用していたヒープ領域もすぐに再利用されて使い回されるため、
>>138のようなケースでも最小限のメモリしか必要とせずに済む

147 名前:デフォルトの名無しさん mailto:sage [2022/05/23(月) 11:54:34.12 ID:n+tkR/ue.net]
glibc mallocの仕様なのでCやC++でも同じです

148 名前:デフォルトの名無しさん mailto:sage [2022/05/23(月) 14:37:05.11 ID:GiQn/B1E.net]
Rubyを長期間動かすとGCがメモリを
細分化してしまうという話かなんかと
混同してんのかな

149 名前:デフォルトの名無しさん mailto:sage [2022/05/23(月) 15:10:34.13 ID:K4XvBL00.net]
>>146
> しかし>>145の結果のアドレスを見ると、確かに中間値は交互にアドレスが異なり2種類だが、全体で6つの領域で済んでいるところに注目
7つ使ってるように見えるんだけど、何を見て6つで済んでるって言えるの?

150 名前:デフォルトの名無しさん mailto:sage [2022/05/23(月) 15:44:46 ID:dNJCbMGg.net]
たぶん1行目も0x55790623d9d0なのを見落としてる

151 名前:デフォルトの名無しさん mailto:sage [2022/05/23(月) 15:46:07 ID:wWZ2mUik.net]
>>149
よく見ると2番目の中間値であるTest::new(111)のアドレスが変数aつまりTest::new(1)のアドレスと同じ
これはRust特有でその時点では変数a(や変数b)を使い終えて解放されているために再利用されたと推測できる
そのため6つメモリ領域で済んでいるのだろう

>>147
CやC++では使い終わった変数の領域が暗黙的には解放されないから7つのメモリ領域を使うと予想

152 名前:デフォルトの名無しさん mailto:sage [2022/05/23(月) 15:51:35 ID:K4XvBL00.net]
>>150-151 あ、ほんとだありがとう。

153 名前:デフォルトの名無しさん mailto:sage [2022/05/23(月) 16:28:21.49 ID:wuIMUAe9.net]
試しに>>144で中間値をもう一つ必要とする例でやってみた
println!("{:?}", (a + b) + (c + d) + e);
メモリ1 = Test::new(1)
メモリ2 = Test::new(10)
メモリ3 = Test::new(100)
メモリ4 = Test::new(1000)
メモリ5 = Test::new(10000)
メモリ6 = Test::new(11) // (a + b)
メモリ1 = Test::new(1100) // (c + d)
メモリ3 = Test::new(1111) // (a + b) + (c + d)
メモリ6 = Test::new(11111) // (a + b) + (c + d) + e
即座に解放された変数領域を2つ使う点で異なるが結果的に計6つ使用に収まっているな

154 名前:デフォルトの名無しさん mailto:sage [2022/05/24(火) 10:09:58.38 ID:PPYrRT7r.net]
https://wandbox.org/permlink/tYewWGlffMON9jxK

ところでこの結果とフラグメンテーションって特に関係あるんですかね



155 名前:デフォルトの名無しさん mailto:sage [2022/05/30(月) 14:58:44.37 ID:MKPVbFKD.net]
>>145
>>146
なーにを馬鹿な考察してんの?
おまえの実行するタスクの途中で他のタスクが実行され、そいつが解放したヒープを確保しないことを
なんで今時のマルチタスク、マルチユーザOSで保証できるのかと言ってる。

156 名前:デフォルトの名無しさん mailto:sage [2022/05/30(月) 15:12:27.13 ID:MKPVbFKD.net]
>>146
>Rustでは消費し終えた変数や中間値が使用していたヒープ領域もすぐに再利用されて使い回されるため

変数が確保されるのは関数コールの度に毎回上書きされるスタックであてtヒープではない
そもそもヒープ領域の確保廃棄で何も問題なければメモリフラグメントなど発生するはずがない。
したがって長期間リブートを想定しないRTOSで、
予めメモリプールを確保してその中で固定的にメモリ割り当てなど行うこと自体全くの無意味ってことだが、
現実はそーじゃない。こんなもんエンベ試験あたりのイロハだろw

157 名前:デフォルトの名無しさん mailto:sage [2022/05/30(月) 15:42:14 ID:9QWL5Xmb.net]
>>155
マルチタスク、マルチユーザーOSというキーワードが出てくるのがよくわからないけど、
物理アドレスの話してるとしたらスタックだろうがヒープだろうがOSの都合で変わりうるんだからヒープのフラグメントの話とはなんら関係ないよね

仮想アドレスの話をしているなら、自プロセスの他スレッドの挙動によってフラグメントしうると言うのは正しいけど
だいたいのmalloc実装ではarenaはスレッドローカルになるからフラグメントは置きにくいと思うよ

というか、どういうシチュエーションで何を実験したときにどのような問題が起きたのか、前提を明確にしてよ
組み込みのRTOSとかいう特殊環境が当たり前のように語られると意見のすりあわせができぬ

158 名前:デフォルトの名無しさん mailto:sage [2022/05/30(月) 15:55:38.95 ID:MKPVbFKD.net]
>>143
> >>138のような解放直後に同じサイズで領域を確保する場合は領

なんで、マルチタスクのOSが、おまえの都合のいいタイミングで解法直後に確保できるのかと言ってる。
例えば、解法直後に割込タスクがおまえのプログラムを一時実行停止し、
そこで開放したばかりのメモリエリアを確保しないとなんで言い切れるんだと聞いてる。

そして、ページングの発生もなんでおこらないと決めてかかってるんだ? 今時のOSでww
おまえが書き出したメモリエリアはあくまでプログラム側から見た論理アドレスだろ?
そこが実はページング対象になってなかったとなぜ断言できるんだ。

159 名前:デフォルトの名無しさん mailto:sage [2022/05/30(月) 15:57:12.40 ID:MKPVbFKD.net]
>>157
>物理アドレスの話してるとしたらスタックだろうがヒープだろうがOSの都

プログラムからは論理アドレスしか見えない
同じ領域を確保してるかどうかはプログラムからはわからない

160 名前:デフォルトの名無しさん mailto:sage [2022/05/30(月) 16:07:33.52 ID:MKPVbFKD.net]
>>157
>マルチタスク、マルチユーザーOSというキーワードが出てくるのがよくわからないけど

汎用OSで自分の起動したタスクしか動いてないと思ってるわけ?
RTOSを持ち出したのは自分のタスクしか実行していなくても、フラグメントを起こす具体例として持ち出した。
そのRTOSでも細心の実装心掛けてるのに汎用OSなんでいわずもがなって話。
今時は、HWのメモリが大きくなってせいぜいページング時のプチフリーズ程度で気付いてない奴もいるだろうが、
やっぱりフラグメントは常時発生してる。
てか、メモリデフラグとか動かしたことないのか?

161 名前:デフォルトの名無しさん mailto:sage [2022/05/30(月) 16:23:56.84 ID:S6YD6bxt.net]
それなんかRustと関係あるんすか?

162 名前:デフォルトの名無しさん mailto:sage [2022/05/30(月) 16:55:49 ID:ccLFuKy8.net]
>>155
まずは基礎知識を勉強しよう
Rustにおいてタスクとは非同期にスケジューリングされるスタックレスなコルーチンのこと
そうでない意味のタスクならばプログラミング言語Rustとは関係ない話

>>156
そのRustプログラム例はBoxを使っているのでスタック上てはなくちゃんとヒープを用いた実験となっている
そんな基本的なことも理解できないならば勉強して出直してきなさい

>>160
それはRustとは全く無関係ない話
基礎的なことを会得していないとそういった無関係な話を持ち出してしまう

163 名前:デフォルトの名無しさん mailto:sage [2022/05/30(月) 18:21:04.97 ID:9QWL5Xmb.net]
>>158
ページサイズより大きい領域の獲得解放を繰り返す想定で良いのかな?
malloc/freeがmmap/munmap呼び出しと一対一対応するような
で、どのOSの実装で問題が起きたの?

164 名前:デフォルトの名無しさん mailto:sage [2022/05/30(月) 22:33:20 ID:SMH6yVl4.net]
ページ単位で割り当てるのにどうやってフラグメンテーション起こすんだろう



165 名前:デフォルトの名無しさん mailto:sage [2022/05/31(火) 14:19:31.88 ID:X/NoC31E.net]
じゃあなんでLinuxやBSD、Windowsはメモリコンパクション機能を実装してるの?

166 名前:デフォルトの名無しさん mailto:sage [2022/05/31(火) 14:23:20.93 ID:5HfxTPdy.net]
>>165 LinuxやBSD、Windowsはメモリコンパクション機能を実装してるの?

167 名前:デフォルトの名無しさん mailto:sage [2022/05/31(火) 16:38:22.49 ID:COFqsPBY.net]
なんで、mallocの話がOSの話とすり替わってたの?

168 名前:デフォルトの名無しさん mailto:sage [2022/05/31(火) 19:29:31.55 ID:6cb4XAup.net]
>>141あたりでもう一緒くたにされてるからしょうがない
たぶん誰も問題意識を共有できてない

169 名前:デフォルトの名無しさん mailto:sage [2022/05/31(火) 20:07:12.82 ID:qkI00F5r.net]
たぶんmallocとOSが密に関連するようなRTOS?が前提なんだと思うよ
>>141は業務で触ってるとかで特性をよく知っているがそのコンテキストが他の人と共有できていないのだろう

170 名前:デフォルトの名無しさん mailto:sage [2022/05/31(火) 20:16:37.40 ID:/PJVfDdU.net]
ずっと暴れている>>141だけが『所有権』と『OS』を同時に登場させていて二つの別レイヤのメモリ管理の話を区別できていない
ここはRustアンチスレなのにプログラミング言語Rustとは無関係な話で暴れていている

171 名前:デフォルトの名無しさん mailto:sage [2022/05/31(火) 21:05:52.27 ID:ycu/V5YM.net]
便乗すんな複おじ

172 名前:デフォルトの名無しさん mailto:sage [2022/05/31(火) 22:22:41.63 ID:qkI00F5r.net]
まあ所有権の話は唐突でよく分かんないけど彼の中では理屈的に繋がりがあるのではないのかな
もうちょっと丁寧に書いてくれれば分かりそうな気もするんだけど

173 名前:デフォルトの名無しさん mailto:sage [2022/07/07(木) 09:23:29 ID:kCv7I/gK.net]
あーうぜー
1.61.0ビルドしてるけどなんだかいろいろとボコボコDLしてくる()
1.61.0なのに 1.60.0-xxx をDLしてくるし()

あーうぜー

174 名前:デフォルトの名無しさん mailto:sage [2022/07/09(土) 14:07:59.53 ID:52J5yu6r.net]
いつのまにかpython module のビルドに入り込んでるのな

悪質



175 名前:デフォルトの名無しさん mailto:sage [[ここ壊れてます] .net]
腐れ言語

早く外せよ

176 名前:デフォルトの名無しさん [2022/09/04(日) 20:06:08.29 ID:9yOWYxc4.net]
なんか第二Javaという感じの臭いがする
非人間的な設計で人間を不幸にしていく悪しき文明というか

177 名前:デフォルトの名無しさん mailto:sage [2022/09/07(水) 04:11:07.00 ID:h5FYCJvl.net]
確かに奴隷言語っぽいね

178 名前:デフォルトの名無しさん mailto:sage [2022/10/08(土) 07:50:08.22 ID:fwLI4Y/X.net]
linus はこれがいいみたいだけどな()

git も Rust もゴミ

179 名前:デフォルトの名無しさん [2022/10/10(月) 15:43:56.96 ID:OkLu+Ovr.net]
meson のビルドで、

× Preparing metadata (pyproject.toml) did not run successfully.
│ exit code: 1
╰─> [64 lines of output]

こんなエラーが出た

すげーイラっとくる


> .toml

クズ言語

180 名前:デフォルトの名無しさん mailto:sage [2022/10/12(水) 21:08:34.50 ID:BNoDz+WR.net]
>>178
重要な部分はRustで作らないと思うよ

181 名前:デフォルトの名無しさん mailto:age [2022/10/20(木) 18:29:22.69 ID:uCae9JR1.net]
なんでこれ、こんなにコンパイル遅いの?

182 名前:デフォルトの名無しさん mailto:sage [2022/10/20(木) 18:33:14.88 ID:sgmqUmRA.net]
>>178
俺もgitもgithubも使いにくいと思っていた。

183 名前:デフォルトの名無しさん mailto:sage [2022/10/20(木) 18:58:12.23 ID:1LIQj8JQ.net]
git自体は悪いと思わんが、なんかgit奉行が色々言い出すのがうざいわ。
rustもそういう匂いがぷんぷんする。

184 名前:デフォルトの名無しさん mailto:sage [2022/10/20(木) 19:21:40.91 ID:LtHEChVu.net]
どのバージョン管理ソフトが良いの?



185 名前:デフォルトの名無しさん mailto:sage [2022/10/21(金) 01:23:53.55 ID:sdgXBR6P.net]
>>184
名前は変わったと思うが、MS製のVisual Source Safeなんかは直感的で便利
だったな。特に何も学ばなくても普通に使えた。

186 名前:デフォルトの名無しさん [2023/08/11(金) 13:18:17.34 ID:98F5eoJ/.net]
cargo check error: failed to run custom build command for `glib-sys v0.17.10`

いい加減にしろよカス言語

187 名前:デフォルトの名無しさん [2023/08/11(金) 13:34:35.94 ID:v1edpQDw.net]
cargo publish して初めて出るエラー (cargo のあっち側の環境でコンパイルしてる) ってうざいよね

188 名前:デフォルトの名無しさん mailto:sage [2023/08/12(土) 00:05:38.13 ID:qDONLKM9.net]
>>186
Cコンパイラかリンカが入ってないんじゃね
そのメッセージの前に何か出ていると思うが

>>187
あっち側ってcrates.ioのこと?
リモート側でビルドなんか走るんだっけ

189 名前:デフォルトの名無しさん mailto:sage [2023/08/15(火) 08:53:12.04 ID:ca01mENm.net]
firefox のビルドもrust が邪魔しまくりだよね()

190 名前:デフォルトの名無しさん [2023/10/02(月) 13:43:22.96 ID:sFvf9xp1.net]
RustとC++の相性は最悪だが
RustとCはまあまあイケる
いいじゃんいいじゃん

191 名前:デフォルトの名無しさん [2023/10/03(火) 16:57:54.88 ID:rr8MlNTB.net]
カス言語ではない

192 名前:デフォルトの名無しさん [2023/10/05(木) 17:14:00.69 ID:WXXGTjkD.net]
C美しい
C++カス
Rustもうちょっとがんがれ

193 名前:デフォルトの名無しさん [2024/04/21(日) 15:50:07.23 ID:aDRU4sod.net]
Rust リファクタリングしてるときに
trait 境界が変わって
あれ?ってなることが多いな

194 名前:デフォルトの名無しさん mailto:sage [2024/04/21(日) 18:44:44.75 ID:GAd5jyBU.net]
>>193
trait境界を満たせなくなるとコンパイラが教えてくれるので安全にリファクタリングできて良いよね



195 名前:デフォルトの名無しさん [2024/04/23(火) 10:33:27.89 ID:9zVe0TBb.net]
>>0185
お前はディストリ自分で組まないの?
情弱だな(プ

196 名前:デフォルトの名無しさん mailto:sage [2024/04/23(火) 10:47:04.81 ID:bJrnaJAq.net]
創価

197 名前:デフォルトの名無しさん [2024/04/27(土) 21:26:16.94 ID:+PotGQRe.net]
crates.io が死ぬと詰むな・・・

198 名前:デフォルトの名無しさん mailto:sage [2024/04/28(日) 14:02:08.42 ID:e+80DOh2.net]
なんなの vendoring とか stable channel とか

意識高そうですね()

199 名前:デフォルトの名無しさん mailto:sage [2024/06/08(土) 09:22:59.84 ID:Kcr3cAzI.net]
Ruby批判だけど
https://qiita.com/scivola/items/17470c52641d3ffa1650
Rustにも同じことが言える

200 名前:デフォルトの名無しさん mailto:sage [2024/06/08(土) 10:03:29.15 ID:9nPXIyFb.net]
>>199
Rustに該当する話が一つもないのにRustを批判?

201 名前:デフォルトの名無しさん mailto:sage [2024/06/09(日) 16:29:53.15 ID:IIKkP3Jm.net]
信者は信者スレに帰れ

202 名前:デフォルトの名無しさん [2024/09/21(土) 15:07:34.01 ID:v+xBeerr.net]
おまいらホントRuby好きだな

203 名前:デフォルトの名無しさん mailto:sage [2024/09/21(土) 15:35:51.56 ID:oJtK/qJ9.net]
遅いのがなあ






[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧](*・∀・)<64KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef