Rust part17

**デフォルトの名無しさん** · 2022/10/06(木) 22:43:13.96

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

Web上の実行環境
https://play.rust-lang.org

日本語の情報
https://rust-jp.rs/

※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 part16

**デフォルトの名無しさん** · 2022/12/07(水) 17:44:20.91

>>884
GutHubでどこにあるのかは分からないがAndroid Code Searchでは以下が出てきたのでpre-built binary使ってるのかなと判断した

https://cs.android.com/android/platform/superproject/+/master:prebuilts/rust/linux-musl-x86/1.63.0/bin/rustc;l=1?q=rustc&sq=

C++もrustも外部ライブラリはexternal配下にまとめられているようなので、それぞれで集計の仕方を変えるなんて事をしてない限りは、同一条件での比較になるんじゃないかな

あと150万行ってのはAndroid13の話じゃなくて累積のコード量がって話しだよ

**デフォルトの名無しさん** · 2022/12/07(水) 17:44:50.45

>>884 追記
なんかRust批判みたいな印象になっているけど、881が多少調べたっぽいので詳しく知りたいだけ

**デフォルトの名無しさん** · 2022/12/07(水) 17:47:35.12

>>886
次世代隔離スレがなくなると暇してるオジサン達が溢れてくるのよ

**デフォルトの名無しさん** · 2022/12/07(水) 17:55:32.50

>>887 ありがと
ただし、ここ見るだれでもrustコンパイラを構成するソースファイルが山ほどある
https://cs.android.com/android/platform/superproject/+/master:prebuilts/rust/linux-musl-x86/1.63.0/src/

さすがにgccの方はsoになってる
https://cs.android.com/android/platform/superproject/+/master:prebuilts/gcc/linux-x86/

>C++もrustも外部ライブラリはexternal配下にまとめられている
こうした統計ではソースとしておいてあるかどうかで結構差がある

**はちみつ餃子** ◆8X2XSCHEME · 2022/12/07(水) 17:59:46.34

割合で言えば大したことは無くてもある程度は積極的に使おうとする雰囲気は感じなくもないってところかな。

**デフォルトの名無しさん** · 2022/12/07(水) 18:00:13.04

>>887
>あと150万行ってのはAndroid13の話じゃなくて累積のコード量がって話しだよ

累積のコード量で、Android向け書き起こしRustソースが150万行、という主張であれば水増しの疑いを持ってる

**デフォルトの名無しさん** · 2022/12/07(水) 18:01:45.15

>>891
>ある程度は積極的に使おうとする雰囲気
それは同感

**デフォルトの名無しさん** · 2022/12/07(水) 18:01:53.83

>>890
コンパイラじゃなくて標準ライブラリのことね
確かにlibcとは扱いに差があるかもね

詳細な数値が気になるならソースダウンロードして測定してみたら良いのでは
https://source.android.com/docs/setup/download/downloading

**デフォルトの名無しさん** · 2022/12/07(水) 18:04:39.07

>>894
そんな手間かけたくないから聞いたんだけど、皆そうなんだろうな

>累積のコード量で、Android向け書き起こしRustソースが150万行、という主張であれば水増しの疑いを持ってる
これで継続だな

**デフォルトの名無しさん** · 2022/12/07(水) 18:06:43.25

>>895
> Android向け書き起こしRustソースが150万行、という主張
原文ではそんな主張はしていないよ

**デフォルトの名無しさん** · 2022/12/07(水) 18:11:19.10

>>896
そう。原文は意図的かどうかは分からないが、あやふやな表現なので範囲を問うてみた
ここだけ読んでそう捉えて誤解をした人がいたら、まず範囲を疑うのが普通、と思った

**デフォルトの名無しさん** · 2022/12/07(水) 18:13:51.76

ちなみにPhoronixで読んだが、LinuxのRust対応は賞味2万行

**デフォルトの名無しさん** · 2022/12/07(水) 18:20:26.12

>>867
じゃあ一から訳したら？
誰かがそうやったから存在するんだが…

>>870
情けないよね。マージされたらそれなりに嬉しいのに。

**デフォルトの名無しさん** · 2022/12/07(水) 18:24:03.55

例えば、ここだけど、150万行はおろか、2万行すら程遠いかな
https://github.com/aosp-mirror/kernel_common/tree/android-mainline/rust

**デフォルトの名無しさん** · 2022/12/07(水) 18:36:53.47

もっと有意義な話しようぜ
fn<T>foo(x: &T); のTにSized制約付くの邪魔くせーとかさ

**デフォルトの名無しさん** · 2022/12/07(水) 18:39:18.13

>>878
そうするとまたはじめの疑問が...
> まだRustでは書きにくい所があるんだろうか？

**デフォルトの名無しさん** · 2022/12/07(水) 18:41:18.29

>>901
x: TのときはSizedついて欲しいけど、&Tのときはついて欲しくないということ？
Box<T>やRc<T>やユーザー定義のスマートポインタの扱い考えるとめんどくさいから一律Sizedがデフォルトでよくない？

**デフォルトの名無しさん** · 2022/12/07(水) 18:48:05.32

>>902
今出てきている情報だけではなんとも言えないかと
Android開発者の内Rustを使える人の割合が少ないだけの可能性もある

**デフォルトの名無しさん** · 2022/12/07(水) 18:51:46.12

>>902,904
その21%が水増しかどうかは重要なわけではなく

>ある程度は積極的に使おうとする雰囲気
これに意義がある

**デフォルトの名無しさん** · 2022/12/07(水) 18:53:03.86

そりゃC++とのInteropが絶対に必要だしRustはそこが弱い
そういう用途としてはCarbonがあるけどセキュアではない
(C++よりはマシだろうが)

**デフォルトの名無しさん** · 2022/12/07(水) 18:58:45.38

>>906
は20%(水増し？)で浮き足立ったり、Carbonの話に拘ってるけど
当分の間はCarbonの話をすると鬼が笑うと思う

**デフォルトの名無しさん** · 2022/12/07(水) 19:02:37.66

Androidの中のRustはGabeldorsche, keystore2, DoH, UWBくらいだっけ
もう3年くらいかかってるからそれなりの行数になってる気もするけどどうなんだろ
aospのrepo sync全部やるの時間かかるんだよな…

**デフォルトの名無しさん** · 2022/12/07(水) 19:05:40.97

>>908
>aospのrepo sync全部やるの時間かかるんだよな…
そこを何とかお願いします
どの範囲を集計したら150万行に到達するのか皆気になってます

**デフォルトの名無しさん** · 2022/12/07(水) 19:09:14.99

repo sync 終わらんよな
今3時間経過

**デフォルトの名無しさん** · 2022/12/07(水) 19:14:14.71

期待大

原文では
>There are approximately 1.5 million total lines of Rust code in AOSP across new functionality and components such as Keystore2, the new Ultra-wideband (UWB) stack, DNS-over-HTTP3, Android’s Virtualization framework (AVF), and various other components and their open source dependencies.
となってますので、

Keystore2
Ultra-wideband (UWB) stack
DNS-over-HTTP3
Android’s Virtualization framework (AVF)
and various other components and their open source dependencies.
これで150万行の大半を占めているかのような書き方です

まさかこれが大半を占めていたり
>open source dependencies
rustコンパイラのソースツリーが入っているとは言えませんよね

**デフォルトの名無しさん** · 2022/12/07(水) 19:30:47.68

期待すんな
gitとpython入ってるwsl環境とかあれば簡単にとってこれるぞ
https://source.android.com/docs/setup/download/downloading
ただ時間がかかるだけ
この程度出来ない奴がrustについて云々言うとか片腹痛い

**デフォルトの名無しさん** · 2022/12/07(水) 19:35:42.75

>この程度出来ない奴がrustについて云々言うとか片腹痛い
そうだね（笑）

こっちでもやってみるかな

**デフォルトの名無しさん** · 2022/12/07(水) 19:35:54.12

半年ほど前のやつがあったのでそれでtokeiかけてみた
とりあえずexternal内が180万行でprebuiltsが500万行くらい
なので1.5mの根拠はexternalの方かな
prebuiltsの方に上で挙がってたmuslとか入っている
external内はrustディレクトリ内の依存クレートが150万くらい
依存クレートでないので最大はcrosvmが30万行くらい

というわけでAndroidのために150万行書き下ろしたというのは言い過ぎ
ただ150万行のソースコード使ってるという原文の主張は正しそう（コンパイラのコードとかは入ってない）
まぁ依存クレートにも明らかにAndroid用っぽいのもあるし
これ以上の切り分けは難しいな

**デフォルトの名無しさん** · 2022/12/07(水) 19:50:48.43

>>904
それなりに優秀な人たちだと思うんたけどそれでもハードル高いのかな...

>>905
水増しとかどうでもいいのでいちいち絡んで来ないでね

**デフォルトの名無しさん** · 2022/12/07(水) 20:03:05.60

一応依存クレートも一通り見てみたけど大きいのはメジャーなやつだね
というわけでAndroidのために書かれたコードは全体で40万行以内ってとこかな

まぁtokioやらcrossbeamがちゃんと使われているのは水増しと批判するようなことではなく
むしろいいことなんじゃないか？

**デフォルトの名無しさん** · 2022/12/07(水) 22:19:15.93

それにしても無駄の多いコーディングだな。
そもそもAndroidで使われたというだけであって、Rustが広まったという訳ではない。

**デフォルトの名無しさん** · 2022/12/07(水) 22:24:52.03

かつてCが流行したのは、LatticeC、SmallC、TurboC、MS-C、WatcomC など
色んな企業がコンパイラ作りを競い合った結果だったかも知れん。
TurboCが流行ったが、それ以前からCは雑誌I/Oなどでも取り上げられて、
さまざまな人が話をし、良い言語であるという噂が立っていた。
当時を知っている俺が言わせて貰えば、なぜか、Rustはビビっとこない。
Cはビビっと来た。
C++は、初期の頃にびびっときたが、C++11では、こりゃもう駄目だ、
と思った。

**デフォルトの名無しさん** · 2022/12/07(水) 22:39:14.39

>>918 蓋を開けてみれば様々なバグ(特にメモリ関連)の元凶だったから､その感覚の逆が正解かな

**デフォルトの名無しさん** · 2022/12/07(水) 22:42:23.65

アセンブラとBASICしか無かった所に
Cが登場したから、そりゃ喜んで使うわ

**デフォルトの名無しさん** · 2022/12/07(水) 22:59:32.88

>>918
今は何にビビっと来るの？

**デフォルトの名無しさん** · 2022/12/07(水) 23:01:58.13

>>918
LSI C-86も入れといてね

**デフォルトの名無しさん** · 2022/12/07(水) 23:23:48.68

スタックかグローバル変数しか無い文化でCを流行らせてもヒープのバグは少ない

ヒープを使わないなら変数の寿命は固定長、という伏線が回収されたことに
まだ気付いてない人もいる

**デフォルトの名無しさん** · 2022/12/07(水) 23:25:35.88

>>918
ロートルは去れ

**デフォルトの名無しさん** · 2022/12/07(水) 23:26:15.82

>>921
そうだな、まだ決め手となるものは無いが、(個人的には好きではないが)JSに
人気が有るのはブラウザがそれしか使えなかったから「では無い」と思ってる。
Rubyと比較すればJSの方が優れているように感じる。
また、C#はJavaよりは改良されていると感じる。但し、これも好きではない。
Pythonも好きではない。人気が有る理由は恐らくAIのライブラリと使用例が
多いからではないかと思ってる。
ということで、今はびびっとくるものが無い。

**デフォルトの名無しさん** · 2022/12/07(水) 23:31:51.79

結局RUSTに限った話じゃなかったかw

**デフォルトの名無しさん** · 2022/12/07(水) 23:34:48.20

Rustは大々的には流行らないんじゃないと思うぞ。
理由は色々有るが、
・流行ってる言語は、JS、Python、Java、PHP、C#、Ruby、VB など、初心者向けの
　簡易言語が多い。
・Rustは中途半端。伝統を無視。習慣を無視。直感的でない。
・そもそもRustは低レベル向け言語、上記に書いた簡易言語のターゲット層には
　被らない。
なお、Googleは色んな言語に手を出す企業。
使ってる言語も幅広く、(同列に入れるべきでないものも混ざるが)
C++、NaCL(*)、Java、Kotlin(*)、Go(*)、Dart(*)、Carbon(*)、Rust、Wasm、
などなど。[(*)は自社製言語や自社製仮想言語(?)]
自社製言語だけでも4つ、仮想言語が1つ。

**デフォルトの名無しさん** · 2022/12/07(水) 23:36:08.15

MS-DOS 向けで最初に入ってきたのは
optimizing C86 だったと思う

**デフォルトの名無しさん** · 2022/12/07(水) 23:40:24.00

そもそも低レベル言語でもココまでメモリ管理に気をとられる言語はなく、
直感的に書けた。
Rustはメモリ管理ばかりに気をとられる言語。論理に集中しにくい。
また、JavaやC#、C、C++では直感的に書けることがRustでは書けない。
なお、「それはおまえがバグのコードを書いているから」と反論されるが、
はっきり言って、そのコードでも全くバグは無いから。

**デフォルトの名無しさん** · 2022/12/07(水) 23:49:55.59

隔離スレがないからとにかく昔話をしたいお爺ちゃん達のたまり場になっちゃったね

**デフォルトの名無しさん** · 2022/12/07(水) 23:56:19.06

Cが流行ったのはリンクリストが作れたからだ。
Strousutup氏はリンクリストを全否定に近い形で否定しまくっているが、
彼は机上の空論であり、彼が自分で実験してvectorの方が速いとしたものも
実際に合わない机上の空論的なベンチマークテストだったろう。
そしてそれを信じてしまったRustの作者はRustではリンクリストを
まともには使えない状態にしてしまった。

**デフォルトの名無しさん** · 2022/12/07(水) 23:59:45.09

なんだお前だったのか

**デフォルトの名無しさん** · 2022/12/08(木) 00:03:22.42

スレ立てろよ
手持ちの回線だと全部無理なんだ

**デフォルトの名無しさん** · 2022/12/08(木) 00:08:02.18

ID:Lb4jZ7zfのプライドだけ高い老害感すごいな狙ってできるもんじゃない

**デフォルトの名無しさん** · 2022/12/08(木) 00:20:06.52

一般人は馬鹿だから偉い学者さんが言った間違った言説を信じるしかない。
実験したことが現実的な状況と合ってなければ実験結果は無意味。
だから、他の経験者はリンクリストが速くてメモリー効率もいいことを知っている
のに机上の空論者であるところのStroustrup氏は、自分がやった机上の空論的な
実験結果を縦に徹底抗戦を仕掛けている。
しかし、実際と有って無いから反感を買っている。
それも、C++から人が離れていっている原因の一つ。
C++もRustもどちらも机上の空論になってる。

**デフォルトの名無しさん** · 2022/12/08(木) 00:22:10.33

>>934
老害はStroustrup氏とRustの信者の方。
Rust信者には本の謳い文句に騙された哀れな宗教信者も多いが。

**デフォルトの名無しさん** · 2022/12/08(木) 00:29:07.90

即NG㌧

**デフォルトの名無しさん** · 2022/12/08(木) 00:32:17.18

LinkedListがキャッシュ効率が悪いというのも机上の空論。
なぜなら、机上の空論者は、LinkedListのノードのアドレスが「ランダム」で
あると間違った仮定するから。
実際には基本的に連続しており、多くの場合は連続して無いとしても
軽微な数バイトの隙間がところどころ空いているだけ。
大きく変化することもあるが、それは全体の数箇所だけ。
なぜなら、挿入箇所は、一箇所から始まってその周辺を押し広げてノードを挿入している
だけで、それが少数あるだけだから、アドレスが大きく変わる箇所はわずかで、
「バースト的」になっているから。
机上の空論者は、ノードアドレスをランダムだと考えるから、キャッシュ・ミスが常に
起きると考えてしまう。ところが、そんな状況はまず有りえない。

**デフォルトの名無しさん** · 2022/12/08(木) 00:35:48.02

>>938
さらに、LinkedListのメモリー効率が悪いというのもウソで、むしろ、
std::vectorの方が悪いことが多い。
なぜなら、後者は、濃度ーを末尾追加していくと、スプリアス的に
今までの配列の入ったテーブルの1.5倍のサイズのテーブルをヒープ領域から
確保してしまう。
これが物凄く致命的で、std::vectorは、要素 T のサイズが大きい場合、
物凄くメモリー効率が悪くなる。
一方、std::list は、要素 T のサイズが大きい場合、std::vectorより遥かにメモリー効率が良い。

**デフォルトの名無しさん** · 2022/12/08(木) 00:39:53.26

>>939
[補足]
std::vectorは、sizeがcapacityを越えそうになると、今までのcapacityの
1.5倍のテーブルを新たに確保するので、今までのテーブルと合わせると、
一時的に 1 + 1.5 = 2.5 倍のメモリー領域を確保してしまう。
std::list ならこんなことは起きない。
なおさらに悪いことに、std::vectorはことの時、全要素を move するので
キャッシュが大規模に汚染されてしまう。
キャッシュ汚染という点では、std::vectorは、先頭や途中への要素追加
の際もキャッシュが大規模に汚染されてしまう。

**デフォルトの名無しさん** · 2022/12/08(木) 00:45:56.87

stroustrup氏の言説はデタラメが多くてストレスがたまる。
そして、自分が間違った説を後ろ盾するために、間違った仮定の元に
実験を行なっている。
コンピュータの実験の場合、正しい仮定のもとで行なうことが重要で、
実験して時節を裏付ける結果が出たとしても、仮定がまるっきり
間違っているのだからどうしようもない。
ベンチマークテストでも、もし、実際と合わないような内容をテストしても
意味が無い。そんな状況は滅多に起きないから。
コンピュータの測度は「加重平均値」で決まる。どういう「加重」かが、机上の空論者
には分からないからデタラメになる。
言語仕様の策定においても、実際にはそんなことをやってもほとんど意味が無いことを
優先的に簡単化しようとする一方で、もっとも重要なことがめんどくさくなるような
仕様を追加してしまったりする。
だから、C++は机上の空論といわれる。
ところが、同じことがRustにも言える。

**デフォルトの名無しさん** · 2022/12/08(木) 00:46:30.49

gccのrustフロントエンドがマージされるそうだけど、これってどういう時に便利なの？
gccでビルドしたCとのcross-language LTOとかできるの？

**デフォルトの名無しさん** · 2022/12/08(木) 01:02:47.82

>>914,916
ありがとうございますとても参考になります

こちらはパーティションを小分けにしていたせいで要領不足にあっていました
これ全体だと300GB以上あるのでしょうか？

仕方ないので
repo init -u https://android.googlesource.com/platform/manifest --depth=1 --partial-clone --clone-filter=blob:limit=10M -b android-13.0.0_r18
としたら100GB位に収まって何とか完走したところです

android-12.1.0_r26も取ってきて21%がcrosvm(当初はChromeOS向け)の移行を含んでるのかどうか見たかったのですが
話のネタが変わってしまったので週末かどこかでやり直すことにしました

**デフォルトの名無しさん** · 2022/12/09(金) 01:41:09.99

LinkedList信者まだいるんだ....
リンクリストなんて既にETHやMITでも、コンピューターサイエンスで多くの人が間違いなく否定するものなのに。別にStrousutupだけじゃないぞ？ほぼ全否定で言ってるのは
キャパを越えそうな事を無理やりするのはほぼ設計の問題だし、途中への要素追加が起きるようなコードを書いてて問題ないと思ってるのはプログラマの能力の問題。
バースト的なんて言ってるけど、連続するメモリー領域へのアクセスと比べて明らかにリンクリストが不利になるのは自明だ、さらに逆に途中追加した場合のキャッシュミスを汚染なんて言ってるけど
それこそ現代の多段キャッシュアーキテクチャを甘く見すぎてる。そりゃ容量を超えるような操作を行えばメインメモリに取りに行くけど、言うまでもないがリンクリストの要素の先はメインメモリー散らばってる。
それがキャッシュされるとしてもCPUのキャッシュは1Byteとか8Byteをキャッシュするものじゃなく1キャッシュブロックで連続するメモリーをk単位でキャッシュする。
StrousutupのC++は明らかに欠陥言語だが、それとデーター構造の理解は別の問題。コンピュータの速度は加重平均なんていう単純なもんではない
すべてがキャッシュに乗るなら一番早く動くが、メインメモリを頻繁にアクセスするなら100倍遅くなる。メインメモリにさえ載りきらないデータを扱いHDDならそこからさらに1000倍遅い。
だがキャッシュの容量しかデータを扱えないプログラムは役に立たたないし、Swapしまくりのプログラムは実用に耐えない。
まだLinkedListを擁護する人が多いのは、欧米のように日本のプログラマーは文系や高卒がやり、明らかにまともに計算機科学というものを受けていないからだ
Rustこそ欧州主体で行われている計算機科学にあまり即してない、FORTRANみたいな米国主導のLinkedListのような産物

**デフォルトの名無しさん** · 2022/12/09(金) 02:35:24.01

なんだかRubyガイジみたいな論法だよな
Rubyでできることはすばらしいこと
Rubyでできないことは必要ないこと

いや必要あるか、使うかどうかは検討の上こっちが決めるんで😅

**デフォルトの名無しさん** · 2022/12/09(金) 08:53:27.93

関数型のElixir は、先頭だけに追加できる片方向リストで、
データが変更されない・immutable だから、バグらない

x = a-b の時に、
先頭に、c を追加して、y = c-a-b となった時に、
a-bの部分が変更されないので、x, y 両方で再利用できる

**デフォルトの名無しさん** · 2022/12/09(金) 09:23:54.41

>>944
絶対ネタで書いてるだろｗ

**デフォルトの名無しさん** · 2022/12/09(金) 13:50:41.90

>>944
CPUにおいて、基本的に cache block と cache line は同じ意味だが、
https://stackoverflow.com/questions/14707803/line-size-of-l1-and-l2-caches
のように、Intel CPUにおけるcache lineの大きさは 64バイト。
先読み機能が有るので、少し先まで読むことがあるが、
1KBみたいに大きくは無い。

**デフォルトの名無しさん** · 2022/12/09(金) 13:58:22.82

>>944
コンピュータ科学ではむしろ、LinkedListがArrayListより速いことがあることを学ぶ。

**デフォルトの名無しさん** · 2022/12/09(金) 14:00:08.53

>>944
>言うまでもないがリンクリストの要素の先はメインメモリー散らばってる。
現実的な使用法では、バースト的になっていて、散らばってない。
散らばっていると思っている人が現実を知らない机上の空論家だと言っている。

**デフォルトの名無しさん** · 2022/12/09(金) 14:03:46.44

>>950
[補足]
バース的で無い場合においても、非常に近いアドレスになっていることが多い。
例えば、ノードを削除してから追加すると、最後に削除されたアドレスが再利用されるから、
データ列を加工する場合にはキャッシュがとても強く働く。
また、ソートにおいてもノードの繋ぎ方を変えるだけだから、コピーはおろか、
ムーブすら発生せず、要素Tのバイト数sizeof(T)が十分大きい場合は、
std::vectorより速い。

**デフォルトの名無しさん** · 2022/12/09(金) 14:08:27.79

>>944
>コンピュータの速度は加重平均なんていう単純なもんではない
加重平均である事と、単純である事は同じことでは無い。
単純ではないが、加重平均である。
実行時間 T = Σ_i w_i T_i
w_i = 処理 i に対する重みパラメータ
T_i = 処理 i に掛かる時間

w_i は、経験を積まないとわからなくて、机上の空論家はこれを誤って見積もる。
偉いとされる先生を筆頭とした「象牙の塔」の集団幻覚の様な現象が起きる。

**デフォルトの名無しさん** · 2022/12/09(金) 14:13:39.03

>>951
[さらに補足]
・ノードを削除してから追加する--->malloc や new が、直近に
　削除したノードのアドレスを再利用されるのでキャッシュが良く効く。
・削除したノードのメモリ・ブロックが全部使われた場合、
　malloc や new がHeapやOSから新しくアドレスを確保してくる -->
　OSは後続の連続アドレスを返してくるので、アドレスはほぼ連続
　するので、キャッシュが良く効く。

故に、実際的な使用においては、LinkedListはキャッシュがよく効く。
　
　

**デフォルトの名無しさん** · 2022/12/09(金) 14:18:24.24

たとえば、馬鹿な人は、通信経路においてのエラーは「ランダムに起きる」から、
「本当にランダム」のケースを脳内で勝手に想像して、
「CRC符合は一般には役に立たない」
と結論付けてしまうかも知れないが、それは机上の空論で、
実際のエラーはバースト的に起きるから、CRC符合は非常に強力に働く。
それと同様にLinkedListもキャッシュが良く効く。
なぜならノードのアドレスが「ランダム」ではないから。

**デフォルトの名無しさん** · 2022/12/09(金) 15:08:04.74

どっちもヤバくて草w

**デフォルトの名無しさん** · 2022/12/09(金) 16:41:02.60

自己完結すれば最速で完結するが
机上で完結しないことを望むなら呪術的な対価を要求されるんだよ

**デフォルトの名無しさん** · 2022/12/09(金) 17:13:50.21

>自己完結すれば最速で完結する
アタオカの巣窟になりつつあるな

**デフォルトの名無しさん** · 2022/12/09(金) 18:30:00.75

絶対にベンチマークの数値は出せないリンクリストおじさん
いつまでrustに粘着してんの

**デフォルトの名無しさん** · 2022/12/09(金) 21:16:01.37

馬鹿は想像力が無いから、理論から計算できない上に、仮定も間違っているから
間違った条件で実験して間違った実験結果を出して、それを信じてしまう。
Stroustrup氏もその一部。

**デフォルトの名無しさん** · 2022/12/09(金) 21:33:34.50

>>959
そんな馬鹿でも実際にプログラムしてる人は自分の間違いに気付くが、
彼と彼の取り巻き達はベンチマーク以外のプログラムはしないので
一生気付かない。そして自分達は実験したから正しいんだと主張し
まくって、それを信じた人類は謝った認識を持って文明の発達が遅れる。

**デフォルトの名無しさん** · 2022/12/09(金) 22:18:43.15

真面目に言うならStroustrupの指摘したリンクリストは、愚直で安直な1要素で次を示すようなデータ構造はバカのすることで間違いない。
というかStroustrupはプログラマのために教え諭してるのに対して、自分が攻撃されたと思い込み、稀なケースで「LinkedListがArrayListより速いことがある」なんていい年してイキっててもしょうもないだろう？
「非常に近いアドレス」とか自分で参照効率が悪いことを理解してるのに、何がしたいのかサッパリわからん。ぴろゆきみたいに見えない仮想的にロンパーしたいの？
https://www.youtube.com/watch?v=YQs6IC-vgmo

ま、今ではUnrolled Linked listとか普通の配列やB-Treeなどと区別がつかない参照の局所性が大幅に向上しているものもあるから
そんなことで騒ぐのはもはやジジイの域だなあ、10年前の出来事じゃん・・・・

**デフォルトの名無しさん** · 2022/12/09(金) 22:39:25.91

ジジイと言うかその人は
1) 頭が悪くて
2) 経験もなくて
3) その自覚が無い
というかわいそうな存在だからあんま刺激しちゃダメ
こうなってくるとこの手のひとは
あとは粘着するだけのマシンと化すから要注意だぞみんな

**デフォルトの名無しさん** · 2022/12/10(土) 00:05:08.23

自己完結は悪と思ってるから他者に粘着するんでしょ

**デフォルトの名無しさん** · 2022/12/10(土) 01:32:53.73

コンピュータサイエンスやプログラミング関連の学者は、アホばっかだからな。

**デフォルトの名無しさん** · 2022/12/10(土) 01:33:28.16

Rustではポインタの代わりに要素のインデックスで管理するのが基本であり安全
リストもツリーもグラフもこれで実装可能
これはポインタがない言語では当たり前のように使われていた方式
これまでが間違ってた
ポインタなどというものは数百万行とかあるプログラムで正しく使うのは無理
世界中のエンジニアがそのために苦労している
ポインタとNULLは完全に失敗

**デフォルトの名無しさん** · 2022/12/10(土) 01:36:13.33

ちなみにインデックス管理がゴミだったのはCみたいに配列の要素チェックがなく
生アドレスを直接触れる仕様だったせい
本来この仕様があり得ない
これならポインタの方がマシだし楽だからという理由でポインタが乱用されてきた

**デフォルトの名無しさん** · 2022/12/10(土) 01:42:29.86

>>961
その動画のジジイはまさに馬鹿。
老害。

**デフォルトの名無しさん** · 2022/12/10(土) 01:44:30.98

アメリカのコンピュータ学者は馬鹿。
自ら馬鹿な方法ばかり想定しているから遅いと思い込んでいる。
それを鵜呑みにしてる学生は大ばか者。

**デフォルトの名無しさん** · 2022/12/10(土) 01:46:18.37

だからアメリカ人の作るソフトは遅い上にサイズも大きいんだな。
日本人の作るソフトはコードも小さいし、データも小さいし、速度も速い。
全然違う。
なぜなら、アメリカ人がイマジネーションが足りなくて馬鹿なのに自覚が無いから。
なのに、詐欺的手法によってアメリカ製ソフトを蔓延させた。

**デフォルトの名無しさん** · 2022/12/10(土) 01:47:54.33

ポインタてのは、CPUの汎用レジスタの
アドレッシングモードを考慮して
OSをコーディングしやすくする仕組みだから

**デフォルトの名無しさん** · 2022/12/10(土) 01:51:53.77

>>967
おっと、こいつが、Stroustrup氏だったのか。
どうりでデタラメな事言ってると思った。まさに、彼が自書で言ってる通りの内容。
この人は計算量などを考えるイマジネーションが不足している。

**デフォルトの名無しさん** · 2022/12/10(土) 02:00:02.88

仮に、彼の間違った仮定であるところの、リンクリストのノードのアドレスが
ランダムに近い状態だったとして(それ自体がウソの仮定なのだが)も、
キャッシュペナルティーは、一回当り20クロックほどだ。
だから、この場合、次のノードに移るのに20クロック掛かることになる。
しかし、それでも、ノード数がNの場合に、20*N クロックほどで済むから
そんなに致命的ではない。Nを100倍しても、100倍の時間がかかるだけで、
大した増加ではない。
一方、std::vectorの場合、挿入や削除一回当り、O(N)の時間が掛かるから、
N回それを繰り返すと、O(N^2)の時間が掛かる。
これは致命的で、Nを100倍すると、1万倍の時間になってしまう。
Stroustrup氏は、オーダーの考え方が経験的に身についてない。

**デフォルトの名無しさん** · 2022/12/10(土) 02:06:32.68

>>972
[補足]
CPUの速度はこの30年間で、1コアあたりに限定しても300倍以上になっている。
良いアルゴリズムを使えば、扱うデータも300倍に増やすことが出来る。
ところが、std::vetcorを使った挿入や削除を行なっていた場合、300*300=9万倍
にクロック数が増えるから、CPUの速度がせっかく300倍になっても、300倍の
時間が掛かることになる。
一方、std::listを使った挿入や削除を行なっていた場合には、クロック数が
300倍で済むから、CPUが300倍になったことにより、時間は昔のままで済む。
つまり、std::listの場合、CPUの速度が300倍になった現在、
データを300倍に増やしても、挿入や削除が昔と同じ時間で済むのに対し、
std::vectorは、同じことをするとなんと昔の300倍の時間が掛かるということだ。

こういう基本をstroustrup氏は理解出来て無い。
探索の時間は関係無い。探索しなければいいのだから。

**デフォルトの名無しさん** · 2022/12/10(土) 02:29:35.43

>>961
>稀なケースで「LinkedListがArrayListより速いことがある」なんていい年してイキっててもしょうもないだろう？
稀ではない。
今はCPUが速くなりすぎて実感がわかないだけ。
だから、遅いCPUでトレーニングした方が良いと言われている。

**デフォルトの名無しさん** · 2022/12/10(土) 03:06:45.22

プロファイルでは粘着というより、論破された時の憂さ晴らし自演が延々と続くパターン
ID:Lb4jZ7zf = ID:pMPEGjtK = ID:3DNXTGzR = ID:ExYz252Q +α
今回は ID:Mw8qZqut だな

**デフォルトの名無しさん** · 2022/12/10(土) 08:26:05.03

CPUが早くなったんだからRustで多少遅くなっても大丈夫

**デフォルトの名無しさん** · 2022/12/10(土) 08:49:37.65

Goも大丈夫

**デフォルトの名無しさん** · 2022/12/10(土) 08:52:02.51

>>975
ID:Mw8qZqut だけどこの人と同一人物判定されるのは不名誉すぎるからやめてくれ

**デフォルトの名無しさん** · 2022/12/10(土) 08:54:11.81

>>978
そうかな？流れ的には水増し論に決着して放り投げてるよ

**962** · 2022/12/10(土) 09:12:41.82

誤解は避けたいからいちおう書いとく

> ジジイと言うかその人は

これはもちろん連投してる哀れなID:ExYz252Qのことね
C++やハゲに文句言うとか身の程知らずもいいとこやわ

**デフォルトの名無しさん** · 2022/12/10(土) 09:19:33.69

>>980
その人C++スレの自称天才でRustに傾倒していてChatGPT並みに尤もらしい適当をこいている人

**デフォルトの名無しさん** · 2022/12/10(土) 09:22:07.09

その人自演が大好きなので ID:Mw8qZqut だとしてもおかしくない

**デフォルトの名無しさん** · 2022/12/10(土) 09:25:57.47

流れ的には水増しの話が再開するはずなので、ID:Mw8qZqut = >>978がどう反応するか楽しみ

**デフォルトの名無しさん** · 2022/12/10(土) 09:30:48.75

>>981
C++スレも荒らされてるのか
自称天才の粘着力すげえな

**デフォルトの名無しさん** · 2022/12/10(土) 11:09:35.00

C++ vs Rust Part4建てとく？

**デフォルトの名無しさん** · 2022/12/10(土) 12:35:14.53

>>983
Androidのソースコード量については、
* コンパイラはカウントされていない
* 外部の依存関係はカウントされているぽい
ということで、事実関係についてはだいたい確定したのでは