結局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/16(日) 14:35:13.61

>>613
45人はいる

**デフォルトの名無しさん** · 2023/07/16(日) 14:36:25.41

>>618
それだ

**デフォルトの名無しさん** · 2023/07/16(日) 14:38:34.26

>>627
的確な判断力が無いまたは物差しが自分基準の人
つまり低学歴低IQにありがちってことと理解したが

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

そもそも「メモリの解放をシステムが自動でやってくれる」事を「解放し忘れ防止」のためだけだと思ってる時点でズレてるやろ
もう他から参照されないと確定した領域は残しとく意味がないんだから解放する、それもシステムが自動で解放してくれるならコードにその事書く必要がなくなる、するとプログラムはコンパイラに“自動的にやってはくれない本質的な処理”だけを書く事が可能になり可読性が向上する
“オレは天才、全てのプログラムはオレが組む”というなら好きにすればいいとは思うがね
仕事にならんわ

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

ダングリングポインタは設計の問題であって、言語の問題ではないのだが
ここがわかっていないといろいろ難しいだろな
生きていくのとか

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

>>631
如何にも正しそうなことを書くので、実際に使うまで
は若い人は騙されるんだろうな。実際に使ってみると
そういうことだけではないことが分かるはず。

**デフォルトの名無しさん** · 2023/07/16(日) 15:48:53.70

C++には長年の経験が詰め込まれているので、C++の流儀、経験則に従っていれば問題なくトップグループに存在できる

**デフォルトの名無しさん** · 2023/07/16(日) 15:50:34.37

>>633
素人の考えは素人にとって受け入れやすい
そして極めた人はほんの一握りしか存在せず、素人は圧倒的に多い
それが問題

**デフォルトの名無しさん** · 2023/07/16(日) 15:51:47.46

>>633
> そういうことだけでは
ここにすべてが集約されてるな

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

lifetimeは面倒だからいちいち描かなくても良きに計らって欲しい

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

Rust lang demerit
でググるだけでも問題点が色々出てくる。
実際はこんなもんだけじゃなく、技術的に根深い問題を
沢山抱えている。

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

おっと、くれぐれも英語モードで検索するんだぞ。
日本語モードではダメだぞ。

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

てかソフトウェア工学なんか1ミリも勉強した事ないんやろ？
なんでそんな自信満々なん？
自分は神に選ばれた天才とか思ってるん？

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

人格攻撃が来たぞ。

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

イヤ、人格攻撃とひとつ非難する前にまず自分の発言見直そうよ
自分が今自信満々に述べてるその主張はもちろん自分の知見に基づいてるんだよね？
その知見はその発言内容に見合うほどのソフトウェア工学に対する勉学に基づいていると自分に対してじしんを持って言えるん？

**デフォルトの名無しさん** · 2023/07/16(日) 17:12:24.84

>>642
コンピュータ言語の良し悪しについてのソフトウェア工学の
具体的な名称をあげてみよ。

**デフォルトの名無しさん** · 2023/07/16(日) 17:38:12.30

>>638
>Rust lang demerit
英語を勉強したほうがいいぞ

**デフォルトの名無しさん** · 2023/07/16(日) 17:44:50.01

自分が無能でソフトウェア工学も知らない
知識が15年前でとまってる無職アスペおじさんなのに
偉そうにソフトウェアやRustについて語る
虫唾が走る

**デフォルトの名無しさん** · 2023/07/16(日) 17:48:04.71

こうは言える
Rustはまだまだ進化の余地を残しており、飛びつくには時期が悪いｗ

例によって、自分用言語ね仕事で指定されたら>>1 のとおり
少なくとも、このスレで見聞きした知見で、自分用のC++コードは見直してるよ

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

コンピュータサイエンスと違ってソフトウェア工学ってのは実践知だから
それほど体系だってもないし理論的でもなくて座学で頑張って学ぶような類のものじゃないぞ
どういうイメージを持ってるのか知らんが

**デフォルトの名無しさん** · 2023/07/16(日) 18:10:52.59

学ぶべきものだぞ
どういうイメージ持ってるのか知らんが

**デフォルトの名無しさん** · 2023/07/16(日) 18:45:02.36

C++はオワコン
はっきりわかんだね

**デフォルトの名無しさん** · 2023/07/16(日) 18:48:37.90

RustについていけないC++erの阿鼻叫喚を見ればいかにRustが脅威かわかるね
仕事奪われるもんね
もうC++erはいらなーいって首切られるよね
残念だね
悲しいね

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

ははその前に彼らは定年（あと数年）迎えるから大丈夫さ

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

できれば、pythonとC, C++の関係みたいにRustコンパイラで動く有力なスクリプト言語が欲しい。

**デフォルトの名無しさん** · 2023/07/16(日) 21:48:38.53

自分用言語だから、(世間評価が)どうなろうとかまわんぞ
廃れすぎてコンパイラがなくなるとかまでいくと困るが…そこまではないだろ…haha

**デフォルトの名無しさん** · 2023/07/17(月) 04:32:46.63

しかし実際は、日本語プログラミング言語なでしこ
の作者みたいな恐らく高齢者がRust信者で
あったりするのだよなぁ。

**デフォルトの名無しさん** · 2023/07/17(月) 09:43:25.24

Rustは難しいと文句言う人はwebでスクリプトしか書いてこなかったひと
https://zenn.dev/helloyuki/scraps/94c1dd0822c54f
https://zenn.dev/mabe/articles/936b788cd2b4d4
フーン
https://zenn.dev/khale/articles/rust-beginners-catchup

**デフォルトの名無しさん** · 2023/07/17(月) 09:45:14.52

>>643
コンピュータサイエンス：科学的＆理系
ソフトウェア工学：言語比較分類学＆文系＆ドカタ
>>647
ほんそれ

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

>>650
そんな心配は unsafe {} で全て解決

**デフォルトの名無しさん** · 2023/07/17(月) 09:47:54.55

>>652
そんなにスクリプトが好きなら
Python + Rust で充分強力

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

マスク氏がAI規制しようとしたのも有名人が匿名性を規制しようとするのも
自分が持ってない力を他人が持つことを最優先で規制したいんだろうと思う
だからリスクの大きさと優先順位は比例しない
自信の大きさにも比例しない

しかし誰でもコピーできるオープンソースについては
自分が持ってないと感じた物は一体何なんだろう

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

>>654
それはただの偏見では？自分は学生だけど、Rustは大好きですよ。と言っても必要に応じて別の言語も普通に使うけど。絶対的に嫌いなのがJavaですかね。なぜか全く好きになれなかった。C, C++はまあ、嫌いではないですよ。

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

>>654
あの人の本だいたい中身薄いよな…
クイープ訳と同じくらい著者で敬遠するわ

**デフォルトの名無しさん** · 2023/07/17(月) 11:20:26.14

浅く広くさくっと読みたい初心者向けの本の方が売れるんだよ
一般書店に並ぶから

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

普通は公式ドキュメントか、ソースからだよな
クリエイティブツールだと、ようつべで操作してんのみたりもせんではないけど

**デフォルトの名無しさん** · 2023/07/17(月) 14:41:33.79

日本語プログラミング言語なでしこ作者、クジラ飛行机:
「手軽に音データを扱えるのもRustの魅力です。
Rustで自作シンセ開発ブーム到来目前?!」
と書いてるけど、いわゆるブーム捏造なんじゃないの。

**デフォルトの名無しさん** · 2023/07/17(月) 14:49:29.12

あいつのはどれも30分立ち読みで十分な内容だからタイパがいい
まとめサイトみたいなもの

買わないけどね

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

苦心して漸く多次元配列構造体のイテレータやインデックスとか大体の演算が実装できた。ただし、今の所、全くマルチスレッド対応ではにいし、GPUの抽象化もできてない。
requires_gradも実装できてない。まだ、大分、長い道のりって感じだわ。

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

オープンソースは、暴力と同じ。
暴力を振るうことは人間の能力の一つではあるが、
それだと社会が成り立たなくなるので近代社会では禁止
されているのと同様、オープンソースは禁止すべきだ。

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

>>667
発展途上国で低賃金でミシン労働者を使うのは搾取なので
禁止すべきと言われているが、それとオープンソースは同じ。
逆に、ミシンの方だけ禁止してオープンソースは許容
するのは差別。
LGBTやジェンダーだけ問題視するのもおかしい。
オープンソースは人権侵害だ。

**デフォルトの名無しさん** · 2023/07/18(火) 08:55:35.36

情報工学系ニキに聞いてみたい
volatileと書いたら、ついついatomicも付いてくると考えがちなのは、何の誤謬なのかな

**デフォルトの名無しさん** · 2023/07/18(火) 10:13:13.27

イメージとしては両者は逆だな
volatileはIOメモリなどアクセスのためメモリ直接演算の最適化せずに律儀に値の読み込み→値の演算→値の書き込み
atomicはマルチスレッドなど競合に対処するためアトミック指定のメモリ直接演算

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

>>667
口先だけで禁止する自由は既にある
もっと現実的にするために暴力を使って実現する自由はない
現実主義を禁止すれば平和になる

**デフォルトの名無しさん** · 2023/07/18(火) 14:01:35.52

高速に動くプログラムを作るには極力if文を減らす、コピーを減らす等のキャッシュ効率の向上、+=, -=, *=, /=等の演算子でできるだけ四則演算を回していく。ここら辺か。
Rustでこの様な工夫をしたところ、かなりサイズの大きい配列の計算が速くなった。

**デフォルトの名無しさん** · 2023/07/18(火) 15:28:04.66

>>672
本当はどんなマシン語(アセンブリコード)になるかを
知っていないと十分な高速化は難しいことがある。
それと、それ以上にアルゴリズムの
O(1)、O(log N)、O(N)、O(N logN)、
O(N^2)などの違いの方が遥かに重要だったりする。
数学が出来ない人は、後者が理解できない。
B.J.Stroustrup 氏もその辺が全く理解できて無い。

**デフォルトの名無しさん** · 2023/07/18(火) 15:40:09.79

>>673
アルゴリズムの最適化は当然だろ。それはやった上での話だよ。

**デフォルトの名無しさん** · 2023/07/18(火) 15:42:48.20

>>674
ところが、重鎮のStroustrup氏は全く理解できてないので、
権威なため彼を信じた不幸な若い人は集団でデタラメな
理解になってしまっている。

**デフォルトの名無しさん** · 2023/07/18(火) 15:55:20.63

>>675
Stroustrupって誰だよ。自分は全然知らないな。普通はアルゴリズムの最適化を行い、プログラム自体の最適化を行うもんだろ。

**デフォルトの名無しさん** · 2023/07/18(火) 16:06:28.75

遅くなるの判ってても
.clone() しまくりたくなる誘惑

**デフォルトの名無しさん** · 2023/07/18(火) 16:12:19.35

>>677
できる限り参照返しにしてる。

**デフォルトの名無しさん** · 2023/07/18(火) 16:23:03.42

>>673
>O(1)、O(log N)、O(N)、O(N logN)、
O(N^2)などの違いの方が遥かに重要だったりする。
数学が出来ない人は、後者が理解できない。

ほんそれ

**デフォルトの名無しさん** · 2023/07/18(火) 16:26:10.43

>>678
hoge.clone() したくなる場面(というかRustcがシレっとhoge.clone()しろって薦めてくるとき)
&hoge[..] とするだけで済むケースが結構あるけどこれ速くなってるよね？

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

仕事でやってるやつでアルゴリズムの単純なオーダーを理解できないやつなんていないだろ
amortizedを理解できないとかそういう話ならまだわからなくもないが

**デフォルトの名無しさん** · 2023/07/18(火) 17:12:16.37

>>681
アメリカ人は学者ですらちゃんと理解できて無い。

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

>>680
多分速くなってると思う。
気になるなら実際計測してみれば分かるのでは？

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

>>676
StroustrupはC++を作った人で少し前にその人の書いた記事が話題になってた
要約すると↓みたいな流れだったと思う

記事（英語）の内容
ファームウェアみたいにメモリアクセスが高価な環境では多少非効率でも
vectorを使った方がキャッシュ等の関係でパフォーマンスがよくなる
実測データでも数万件程度（うろ覚え）ではvectorが優位だった

記事に対するこのスレでの批判
何にでもvectorを使うように推奨するのはアルゴリズムを理解できてないからだ

**デフォルトの名無しさん** · 2023/07/19(水) 00:22:21.27

算数100点大先生がcache localityを理解できないという話をまたやるのか

**デフォルトの名無しさん** · 2023/07/19(水) 00:38:56.49

>>680
どういうコードでhoge.clone()をお勧めされるんですか？

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

ハッシュテーブルが遅くなる攻撃を思いつくような奴は確率を信じてない
というかこのラインをこえたら信じないというローカルルールがある

そもそもローカルがグローバルより劣っているみたいな考えは数学で扱わないので
そんなものを信じる義理はない

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

>>685
理解できて無いのはこのスレの馬鹿どもとStroustrup氏の法だ。

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

文脈が全くわからないのだがStroustrupの記事ってどれ？

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

>>684
ほとんどの用途でベクターが有利というその主張で合っている
実際の各ユースケースで計算量の償却解析してみればわかる

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

ハゲは>>684記事で実測を示したんでしょ?

**デフォルトの名無しさん** · 2023/07/19(水) 11:34:57.60

>>676
C/C++ スレでハゲと描かれていたらそいつのことだ

**デフォルトの名無しさん** · 2023/07/19(水) 11:37:33.24

>>684
>ファームウェアみたいにメモリアクセスが高価な環境では

それこそ「何にでも」なんて言ってない限定してる

**デフォルトの名無しさん** · 2023/07/19(水) 12:59:18.29

>>690
「ほとんどの」というのが嘘だ。

**デフォルトの名無しさん** · 2023/07/19(水) 13:00:42.03

この板は馬鹿ばっかりで、それで納得してしまうのかも
知れんが、海外のサイトだと、ちゃんと、リンクリストが
有利な場合が沢山あげられている。

**デフォルトの名無しさん** · 2023/07/19(水) 13:04:59.13

>>695
ハゲは>>684の記事で実測を示したんでしょ?

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

>>696
そんなもん、実験条件と解釈がめちゃくちゃなので
証拠にならない。
理論や理屈を理解していなければ実験しても無駄な例。

**デフォルトの名無しさん** · 2023/07/19(水) 13:15:37.13

>>697
実験条件と解釈を読んだのかな?
内容をおせーて

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

価値観を押し付け合うのは実は平和的だよな
相手の価値観に合わせる柔軟なタイプが最も危険で
相手が戦争嫌いではないと知ったら嫌いになるまで戦争をやめない

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

Stroustrup師って、一人でさらさらって書いて出しちゃう御仁なのかな
こーゆうツッコミが入るのはわかるだろうにねやっぱ原著見ないとか

**デフォルトの名無しさん** · 2023/07/19(水) 14:45:35.26

>>699
なるほど折伏ですね判ります

**デフォルトの名無しさん** · 2023/07/19(水) 15:39:26.34

https://www.tiobe.com/tiobe-index/
ruby抜けそう
Goくらいは抜いてほしいものだ

**デフォルトの名無しさん** · 2023/07/19(水) 16:11:16.93

>>702
惜しい
swiftが挟まってなければRRRだったのに

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

やっぱりこうなるね
https://mevius.5ch.net/test/read.cgi/tech/1683600652/509-510

**デフォルトの名無しさん** · 2023/07/19(水) 20:59:38.09

興味ある人のためにStroustrup氏の記事のリンク（Rust本スレのPart18で議論されてた）
https://www.stroustrup.com/Software-for-infrastructure.pdf

URLからも分かるけど記事のタイトルは「Software Development of Infrastracture」で内容は少しハード寄り

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

>>702
スゲーCOBOLに勝ててるんじゃん

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

>>705
ハゲの言うinfrastructure softwareはハードよりかどうかは関係ない

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

俺はハゲに同意かな
LinkedListはもはや古いデータ構造だと思う
現代のアーキテクチャにおいてはキャッシュメモリに乗せることがめちゃくちゃ重要なんだよ
LinkedListは挿入や削除を繰り返すとメモリアドレスがめちゃくちゃになりがちだし
ポインタを辿るという操作もページアウトなどを引き起こす
普通にポインタ配列のvectorが良い
もちろんreallocのコストが無視できない環境だと有効であるのは間違いない

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

キャッシュメモリがゴミカスレベルのサイズ
もしくは存在しないレベル
メモリアロケーションのコストが高い
追加削除が頻繁に起きまくるようなソフトウェア

これらの場合はLinkedListで良いかも

**デフォルトの名無しさん** · 2023/07/19(水) 23:33:20.68

コンパイラとかもろもろ最適化して計測するとndarrayクレートのArrayのイテレータよりも自分の作った多次元構造体のイテレータの方がまだ10倍くらい遅い。nextメソッドで呼び出される自作の外部関数の呼び出しがコストになってるっぽい。

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

馬鹿な人ほど、LinkedListを嫌う傾向がある。

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

ほとんどのケースでLinkedListが使われないのは遅いしメモリも余分に食うためだ
次の位置のアドレスを得るためにメモリアクセスが必要となり遅い
Vectorなら次の位置のアドレスはインクリメントするだけだ
前の位置も辿りたいならLinkedListだと双方向リンクでさらにメモリ使用量も増える

**デフォルトの名無しさん** · 2023/07/20(木) 03:04:02.05

>>712
マシン語レベルで見ると、インクリメントと
次のアドレスを得るのはどちらも mov 命令1つで、
どちらも1クロックで時間に差は無い。

**デフォルトの名無しさん** · 2023/07/20(木) 03:09:08.59

>>713
>次のアドレスを得るのはどちらも mov 命令1つで、
>どちらも1クロックで時間に差は無い。
間違えた。
正しくは、
「インクリメントは、add、次のアドレスを得るのは movだが、
　どちらも1クロックで必要時間に差は無い。」

**デフォルトの名無しさん** · 2023/07/20(木) 03:15:52.51

いやだからメモリアクセスが支配的になるという話なのだが？
キャッシュメモリに乗ってないと致命的な速度低下となる

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

>>713
メモリアクセスに時間がかかることすら知らないならコンピューターの入門レベルからやり直せ

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

>>716
キャッシュメモリに乗っている場合の話だ。
乗っていない場合には、もちろんペナルティーが発生する。
ただ、ArrayListは、途中への挿入や削除がO(N)かかるが、
LinkedListは、O(1)だから、Nが10万の時には10万倍
の時間差となる。
一方、キャッシュのペナルティーは15(ns)くらいだから、
現在のCPUでは、45クロック位。
これだと、最悪のケースでも9倍程度だから、圧倒的に
LinkedListの方が時間的に安定。

**デフォルトの名無しさん** · 2023/07/20(木) 03:25:15.25

はっきりいって、ここの数学的才能の無い連中にも
俺は説得できる説明が出来る自信は有るが、敢えて
やってない。なぜなら、それを論文にしてステップアップ
に利用すると言うずるがしこい連中を多く見てきた
からだ。

**デフォルトの名無しさん** · 2023/07/20(木) 03:29:46.06

この板の人は、数学的才能の無い人ばっかなので
異常に馬鹿丁寧に説明しないと理解できない。
今回の説明でも馬鹿丁寧だが、経験上、この程度の
丁寧さでは理解できないだろう。
もっとアセンブリコードまで徹底して書いて、
キャッシュとメインメモリの関係の図を書いて、
大量の比較コードを提示して、やっと僅かに理解できる人が
一人現れる程度だ。
それなのに、自分は賢いと思い込んでいる。
また、文書が読めない人が多い。
音声で言わないと理解できないらしい。
だから、掲示板では無理。

**デフォルトの名無しさん** · 2023/07/20(木) 05:22:45.38

はよ賢い人たちに説明しにいって、出禁にされてこい

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

>>717
LinkedListがO(1)なのは先頭に挿入する場合だけだぞw
サーチが必要な場合は当然O(n)
数学だけじゃなくCSも正しく理解できていないようだ

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

LinkedListすらまともに作れない言語ってどうなんだろうなｗ

**デフォルトの名無しさん** · 2023/07/20(木) 07:29:26.02

>>717
キャッシュメモリに載っていてもいなくてもメモリアクセスのペナルティが発生する
キャッシュに載っていないメインメモリならレジスタの数百倍
L3キャッシュに載っていればレジスタの数十倍
L2キャッシュに載っていればレジスタの十数倍
L1キャッシュに載っていてもレジスタの数倍かかる
メモリアクセスはこのようにとても遅い

したがってレジスタのインクリメントだけでアドレスを得られるVectorの方が有利になる
さらにVectorなら次の要素はほぼ必ずL1キャッシュに載っている恩恵も加わる
ほとんどのケースでVectorが速いのはこれらメモリアクセスの観点も効いている

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

ランダムアクセスになる場合なんかはlinkedlistなんかメチャクチャ遅くなる
例えばバッファサイズが8のフーリエ変換だと
1-5,2-6,3-7,4-8,
1-3,2-4,5-7-6-8,
1-2,3-4,5-6,7-8
とアクセスする
頭から読んでいくとものすごいコストがかかる

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

そのレベルで速度気にするんならCやC＋＋の方がよくね？

**デフォルトの名無しさん** · 2023/07/20(木) 09:05:41.95

全員がプログラミング言語に全く依存しない話をしてるところで唐突だな

**デフォルトの名無しさん** · 2023/07/20(木) 09:35:16.93

>>719
速度に影響を与え得る全ての要因を把握してれば理論的に予測できる
しかし多くの人は全把握していないことが実測の反例1つで明らかとなる
ハゲは>>684の記事で反例を示したってことなんでしょ? （俺は読んでないよ）
測定条件も恐らく1つではなくグラフの横軸に振って速度に与える影響を
示したんじゃないのかな?