結局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/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つではなくグラフの横軸に振って速度に与える影響を
示したんじゃないのかな?

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

ハゲの書いてることは00年代中盤にはCSでは一般常識化してた内容
実測すれば答えすぐ出るから

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

>>720
出禁にされた結果がこのスレや

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

cargo は便利だけど crates.io の複数のモジュール同時使用で衝突するケースがあるよな
それぞれ単独で使うと問題起きないのに組み合わせて使うと死ねる
それぞれの開発者はたぶんお互いを認知してないかあるいは
どうなろうと知ったこっちゃないんだろ

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

>>713-714
そういう問題じゃなくて
リンク先がキャッシュに乗ってなかったら大変コストが増える
って話だろ

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

>>717
だからそれぞれの利点欠点を把握した上で使い分けようという話をしてるんだよな
ハゲは(ほぼ)全部Vectorとか極端だから馬鹿だと言われてるって話だよな

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

>>721
明らかに君が可笑しい

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

バランスを考えるのをやめろ
両極端の宗派はそのままにしておけ
統一するな

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

>>733
サーチが必要な場合、LinkedListはO(1)ではなくO(n)
どういう勘違いをしたのかも含めて教えてもらえるとありがたい

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

横からだけど
>>735

＞　>>717
＞　LinkedListがO(1)なのは先頭に挿入する場合だけだぞw

これじゃね？明らかに間違ってる

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

LinkedListが一直線のリンクで実現してるのか、二分木とか赤黒木とかまで含んでるのかで話が変わる

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

>>736
うーん、じゃあもういいやw

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

同じO(N)でも性能は全く違うって話なのは理解してる？

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

このスレではLinkedListは常にO(1)ってことにしようw
よし使いまくるぞ！w

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

>>740
本当はしまったと思ってるけど開き直って違うことをかいてるんでしょう
みじめですね

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

なおRust標準ライブラリのLinkedListの扱い
（https://doc.rust-lang.org/std/collections/index.html）

Use a `LinkedList` when:
* You want a `Vec` or `VecDeque` of unknown size, and can't tolerate amortization.
* You want to efficiently split and append lists.
* You are *absolutely* certain you *really*, *truly*, want a doubly linked list.

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

>>741
ほんと惨めやね
>>719のような人間は自分だと自ら証明してしまった訳だ
せめてid変えとけよって思うわw

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

1. ソートされた状態でデータを管理したい
2. 走査は激遅でいいけどキーに対応する値1件の取得/挿入/削除は高速に行いたい
3. 取得/挿入/削除時に先頭末尾以外位置はリストにアクセスしなくても分かる
これらを満たしてる場合にのみLinkedListが候補の1つに上がる

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

数学の人とオープンソースの人はひょっとして同じ人？

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

ひょっとしなくても同じやつだろ

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

>>744
>> 3. 取得/挿入/削除時に先頭末尾以外位置はリストにアクセスしなくても分かる

それはLinkedList全ての要素へのポインタ一覧を持っていないと無理だな
それをベクタで持つならその削除問題が発生してLinkedList利用の唯一の利点が消える
別のLinkedListで持つなら再び激遅な走査問題が起きる

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

>>747
一般的にはLinkedListとHashMapを組み合わせる
一部の言語に実装されてるLinkedHashMap/OrderedDictionaryや
基本的なLRUキャッシュの実装でその組み合わせが使われてる

**デフォルトの名無しさん** · 2023/07/21(金) 00:53:33.35

一般的なLinkedListはともかくとしてRustに標準に実装されてる
use std::collections::LinkedList;
は前後のノードへのポインタで実現してるらしい
赤黒木がどうこうとかいうものではとてもなさそう
ランダムアクセスなんか劇遅やろ
そもそもLinkedListのくせに
「リストの中間地点に要素を追加したり、削除する操作が効率的にできるのも連結リストの特徴ですが、Rust1.26の時点では、そのような操作のためのメソッドが用意されていません」
とはどういうつもりなんやと
https://qiita.com/garkimasera/items/a6df4d1cd99bc5010a5e

**デフォルトの名無しさん** · 2023/07/21(金) 02:25:21.34

LinkedList単体で使おうとするとベクタ系での実装に対するアドバンテージがほとんどのケースで存在しない
またソートを維持したいならLinkedListよりもBTreeMapが有利
他にもそれぞれ目的別に有利なデータ構造がある

>>748
Rustにも毎日10万ダウンロードされているLinkedHashMapがある
https://crates.io/crates/linked-hash-map

**デフォルトの名無しさん** · 2023/07/21(金) 02:46:28.99

アルゴリズムやデータ構造の性能を評価する上で、
よく使われてきた計算量という指標の実用性も微妙になっちゃったな

**デフォルトの名無しさん** · 2023/07/21(金) 03:01:04.83

>>724
そのように番号で場所にアクセスするような
事に使用するにはArrayが有利。
単純なLinkedListは、番号でアクセスする用途には向いていない。
LinkedListを効率よく利用するには番号ではなくアドレスでアクセスする。
アドレスとは、ノードに付けられた唯一無二の名前。
この板の人達はその概念が全く理解できず、
いつまでも番号によるアクセスから頭が切り替えられないでいる。

**デフォルトの名無しさん** · 2023/07/21(金) 03:38:53.42

ndarrayクレートはイテレータの高速化のためにZip構造体を使ってるって聞いたんだけど、Zip構造体ってどんなことやってんの？誰か教えて。

**デフォルトの名無しさん** · 2023/07/21(金) 03:40:00.01

>>752
それをしようとするとLinkedListの各要素のアドレスを持つもう一つのデータ構造が必要となる
さらにそのもう一つのデータ構造に対しても挿入や削除の処理が必要となる

**デフォルトの名無しさん** · 2023/07/21(金) 03:49:23.59

>>753
今一瞬しか見ていないがndarray::Zipは単なるタプル化

**デフォルトの名無しさん** · 2023/07/21(金) 08:45:47.57

これがRustの実力だ

FirefoxがついにChromeよりも高速なブラウザに
https://gigazine.net/news/20230720-firefox-surpassed-chrome-speedometer/

**デフォルトの名無しさん** · 2023/07/21(金) 09:30:46.83

そろそろ、(Rust世代の知見を組み入れた新世代の)C++でフルスクラッチが試みられてもいい頃合だな

**デフォルトの名無しさん** · 2023/07/21(金) 09:59:32.61

>>756
記事にはRustのRの字もないのだが本当に早くなった要因なの?

**デフォルトの名無しさん** · 2023/07/21(金) 10:11:38.01

まぁそんな結論出せるわけない
その結論出すにはFireFoxと同じアルゴリズムで別の言語で組み直して実測するしかない
そんな事誰もしない
しかしRustは他の言語に比べて抽象度はやや高め(C++等とでは)だから速度面とかでは不利になるはず
しかしそのディスアドバンテージが跳ね返されるくらいの性能がある事は実証されたとしていいやろ

**デフォルトの名無しさん** · 2023/07/21(金) 10:27:50.89

>>751
指標やハッシュ値や非可逆圧縮や浮動小数点数はある意味現実の劣化コピーだから
現実とお花畑の対立を煽れば煽るほど劣化コピーという身分が固定されてしまう

**デフォルトの名無しさん** · 2023/07/21(金) 11:44:03.63

>>751
絶対的性能を評価するためのものではなくて
要素数の変化に対する性能変化の次数(order of growth)を分かりやすく把握するためのもの
“計算量”という誤った訳語から受ける印象に引きずられてはいけない

**デフォルトの名無しさん** · 2023/07/21(金) 11:51:22.56

トータルの消費時間を決定する要因は複数なんだから
律速段階も見極めずに最適化しても意味はない

**デフォルトの名無しさん** · 2023/07/21(金) 14:00:29.86

>>759
抽象度が高いことによる速度面の不利はコンパイル時間の方で吸収してると思う

**デフォルトの名無しさん** · 2023/07/21(金) 14:39:47.78

FireFoxは糞ブラ
↓
Rustは糞言語
↓
C/C++勝利

**デフォルトの名無しさん** · 2023/07/21(金) 15:20:14.46

>>763
ｗ

**デフォルトの名無しさん** · 2023/07/21(金) 16:03:44.31

>>754
それが必要ない場合もある。
頭の良し悪しが問われる。

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

フィールズ賞を受賞してる日本人で広中さんって人がいるよな
広中さんは「自分は鈍才だが、森君は天才」と言ってるそうな（wikipedia調べ）
このスレで数学の才能がどうのと言ってる人はこれもう
ひょっとしたら森さんなのかもしれんな
森さんって人も、フィールズ賞受賞してる数学の天才

このスレすげーな