結局C++とRustってどっちが良いの? 2traits
■ このスレッドは過去ログ倉庫に格納されています
「C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」 「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」 っていうスレ。 前スレ: 結局C++とRustってどっちが良いの? https://mevius.5ch.net/test/read.cgi/tech/1677286186/ 最悪計算量がO(1)の両端キューがどうしても欲しい場合にでも使えばいいんじゃないでしょうか まあ、linked list でいっかあ、ってとき。簡単なのはメリット。 おいおい、ちゃんとしたコンテナに替えてもよし。 両端キュー(deque)はリストではなくベクタ系による実装の方が好まれて使われる std::dequeue、JavaのArrayDequeue、RustのVecDequeなど chatgptにlinked listがいい例を挙げてもらった テキストエディタ、ジョブスケジューラ、メモリ管理、ハッシュテーブル >>756 >リンクを毎回たどるって何のことを言ってんの?>>739 のように現在指している要素の隣の要素を参照するだけだよ。 LinkedListでリンクをたどらずどうやって隣の要素を参照するのか教えてくれるかな? >>755 ベクタ/リストをソートするのに計算量的な差は特にない。 ソート済みのものに要素を挿入するのは一長一短あるが一般にはリストが有利な場合が多いな。 挿入自体のパフォーマンスに特化するなら場合はヒープのような木構造を使うのがベストだろうが。 >>764 リンクで隣の要素をたどるだけならなんも不利なことないじゃん。 >>763 ハッシュテーブルでもリンクリストを使うチェーン法はリンクをたどるコストが無駄なので避けられる 現実的に効率の良いオープンアドレス法が好まれておりベクターが使われている なんか偶然ソートの話になってるけど 流れを読んでからこれ書いたんじゃなくて 「ところでインサーションソートなんてベクタじゃ苦しいだろうけど リストならすごく効率がいいんではないか? を確かめようとしたら list::sortがおそらくすでに十分に効率的に書かれてることが分かって インサーションソートを自分で実装する気が萎えた (いちおう拾ったコードは乗せてあるけどクッソ遅い)」という別の話 https://ideone.com/D9ljA7 function asc desc shuf std::sort(v) 16 13 72 list::sort 43 60 332 ←十分早い std::qsort(v) 47 45 144 ←参考 >>766 リンクをたどらず隣の要素を参照することはできないのね チューリング賞ものの新アルゴリズムでもあるのかと思って期待しちゃったよ 数学的に >>769 >>765 はそのリンクをたどることがどう不利になるのかを聞いたんだが? Microsoft's adoration of Rust does have limits. "Rewriting Windows in Rust probably isn't going to happen anytime soon," said Weston, "so while we love Rust, we need a strategy that also includes securing more of our native code." コンパイラはどうすんのかな? 社内に自社製のがあるのかな? >>769 LinkedListにおいて、キャッシュに載っていれば隣の要素は、1クロックで 辿れるから何の問題もない。アセンブリコードは、 mov rbx,[rbx + pNext] みたいになり、キャッシュに載っていれば1クロック。 多くの場合、キャッシュに載っていることが多い。 乗っていない場合は、prefetch 命令で載せることができる。 Stroustrup氏は、キャッシュミス時のハードウェアによる自動 prefetch が 数百クロックかかると書いていたが、それは過去の話で、 現在の DDR4-SDRAM だと、15クロックだと聞いた。 だから、キャッシュに載ってなくても15クロックのペナルティーで済む。 また、pNext を読む前に prefetch 命令で pNext の部分をキャッシュに読み込ます ようにしておけば、ペナルティーは 1 クロック以下に近くなる。 「以下」と書いたのは、いまの CPU は複数命令の同時命令実行機能が有るので prefetch命令自体は0クロックで実行できることがあるから。 なお、LinkedListでも多くの場合は、次のノードは、アドレスがほぼ隣接しているので キャッシュに載っている確率が高い。ほぼ連続的なアドレスを次々に辿っていくので ほとんどの場合、LinkedListのノードは読み込み時にキャッシュに載り続けている。 10万個の要素があった時、その内、2つの要素を10回交換したとしても、 キャッシュの乱れは、40回程度。10万要素の内の40回程度、キャッシュ ナルティーが生じるだけ。 それぞれが15クロックほど遅くなるだけだから、10万個の要素を辿っても、 全体として、600クロックほど、キャッシュ読み込みの時間が追加されるだけ のはず。ただし、キャッシュミス時の自動prefetchの時間が15クロック かどうかは不明。 なお、ソフトウェア的にprefetch命令をマシン語で書いておけば、他の命令を 実行中にprefetch動作が入るので、キャッシュペナルティーを実質0クロック にできる。 >>777 俺の方があんたより数学的才能に恵まれてると思うぞ。 ここの人は何か勘違いしてるようだが、LinkedListで隣のノードに辿るのは、 C で書くと pNode = pNode->pNext; という1行で書けるが、アセンブリだと、 mov rbx,[rbx + (pNextのオフセットアドレス)] という 1命令になって、1クロックに過ぎない。 一方、配列の場合の、++ptr は、 add rbx,(1要素のバイト数) という1命令で書けて、これも1クロック。 なので、キャッシュミスがない限り、LinkedListも配列と同じ速度で ノードを辿っていける。 >>754 QuickSortは、LinkedListではとても不利。 ただし、QuickSortと同じ速度のソートを俺は発見している。 なお、俺は数学的な天才だから、あなた達には無理なんだろう。 LinkedList指向アーキテクチャを使ってるんだろ >>778 >キャッシュの乱れは、40回程度。10万要素の内の40回程度、キャッシュ >ナルティーが生じるだけ。 >それぞれが15クロックほど遅くなるだけだから、10万個の要素を辿っても、 >全体として、600クロックほど、キャッシュ読み込みの時間が追加されるだけ >のはず。 訂正します。 実際には、AAAABAAACAAADAAA・・・ のようになるので、「行き」はキャッシュミスが生じますが、「帰り」は キャッシュに載っているものを再度使うだけなので、キャッシュの乱れは 20回程度となり、キャッシュロードに掛かる追加時間は、全体で300クロックで 済むと考えられます。 >>784 LinkedListでも効率の良い新しいソートアルゴリズムを独自に発見してます。 >>786 高速なソートアルゴリズムを新たに発見するとは 天才すぎる これでLinkedListの逆転勝ちかあ >>780 1クロックで読み込みできるとは ハードウェアでも天才すぎる LinkedListの時代が到来だあ >>772 貼るんなら極力元ネタにしようぜ 字幕でおk https://youtu.be/8T6ClX-y2AE?t=3100 ブートローダはプログラムであって、ライブラリじゃないんだよな はやくAPIをRust化してほしい そうすれば、C++も恩恵を受ける AIにコードを書いてもらえないかってのが研究されだして久しいけど、 Rustは(書いてもらうのに)向いてるかもね Rustは人の仕事を奪うかもよ?w クリックベイトかな?と思ったら速攻で出ていた >>772-773 >>788 > Microsoft's adoration of Rust does have limits. > "Rewriting Windows in Rust probably isn't going to happen anytime soon," said Weston, > "so while we love Rust, we need a strategy that also includes securing more of our native code." 隣へたどる方法比較 https://ideone.com/sVvoxX p++ 28 v ++it 29 v next(it) 30 l next(it) 151 最初の三つに数字の上では差が付いてるが本質的ではない 書いてる最中にここの数字入れ替わったりしてるので誤差 リストは遅いっちゃあ遅いけど致命的に遅いわけでもない リストにとっては有利なメモリ配置にはなってると思うけど 中立ぶってリストを擁護する人も、中立やめてリスト推しになるかといえば ならないだろう 結局、誰も推してないのに誰かが推しているように偽装することを 中立という綺麗事で正当化しているだけだ >>792 ideoneはコンパイラバージョンが古いしマシンも古いと思う ただしWS級だからメモリ帯域は大きそう(オンザフライ数が大きい) vectorならDT級マシンでもHWプリフェッチがうまくやってくれる p++ 6 v ++it 6 v next(it) 6 l next(it) 241 <- 致命的に遅い、よね? >>768 偶然ソートの話になってるんじゃなくて誰かが書いたコードが linkedlistに不利なソートを取り上げてたから荒れてるだけなんだ 原因はその誰かなんだ 上に書かれてるように挿入ソートは実質ランダムアクセスよりlinkedlistに不利になるんだから そういうのをテーマに選んだ時点でちょっとセンスがないと思う 原因はどうでもいい 因果関係に縛られた機械では人間に勝てない 人間も因果に縛られてるんだから、巨視的にはどっこいどっこいかもよw >>792 ,794 もう面白くないからやらないけど補足すると、一昨日のlistのscanがイイ感じだったのは Arena使っているからchunk毎にリニアアクセスだったからなんだ >>792 ,794はdefault allocatorで、Cacheから出たらnext(it)ですら遅いよ bindgenでC/C++のheader変換させると warning: type `ho_ge` should have an upper camel case name help: convert the identifier to upper camel case: `HoGe` みたいな余計な御世話なメッセージが出捲るんだが これを抑制する方法って無い? >>794 (´・∀・`)ヘー これは致命的に遅いね >>798 勉強になります .to_string() とか .to_str() とか .to_str().expect("やりなおせ") とか .to_str()? とか .as_str() とか 一貫性がないな >>799 抑制する方法もエラーメッセージに出てなかったっけ? #![allow(non_snake_case)] #![allow(non_camel_case_types)] #![allow(non_upper_case_globals)] で出来たけど #[allow(non_snake_case)] #[allow(non_camel_case_types)] #[allow(non_upper_case_globals)] にしろって書いてあるサイトもある どっちなんだろ 2つ以上のC/C++のprojectから bindings1.rs bindings2.rs みたいに造って同時にinclude!()すると 定義の衝突とか出るけど header1.hとheader2.hのどっちにも #include <iostream> みたいなの書いてあるとそうなるんかな 面倒だな DDR4-SDRAMのCASレイテンシーは、15クロックではなく、15(ns)程度だった。 3GHzのCPUだと、45クロックという事になる。 >>805 いろいろ間違ってるで SDRAMのCASレイテンシってのはナノ秒じゃなくクロックサイクル数 それもCPUクロックじゃなくRAMクロックのサイクル数 >>805 これネタ? プログラム組めないならAIDA64で測ってみなさい Trialでもmemory latency出るから >>801 Rustは一貫性があるようにガイドラインで命名ルールも定められている as_xxxとto_xxxの違いは基本的に as_xxxはコストなく別の型とみなす to_xxxはコストかけて別の型を作るかみなす その例ではもちろんstrとStringは別の型 基本的にas_strとto_stringが使われる as_strは内部でstrとみなせるデータを持っている時にそこを指すだけなのでコストがかからない場合 to_stringは任意の型からStringを作り出すのでコストがかかる to_stringはtrait ToStringのメソッドだがtrait Displayを実装することで自動的に実装される 唯一の例外がto_str これは外部からのデータに対して存在する strは必ずvalidなUTF8であると保証されている 一方でOsStrやそれを使っているPathは必ずしもvalidなUTF8であると保証されない そこでUTF8チェックのコストが生じるのでto_strとなる FFIであるCStrからも同様にto_strとなる >>752 =805 ? moveもレイテンシーも分かってないRust使いがいるけどホームグラウンドはPythonかよ! 1クロック君も分かってないんだから あんまり人のことは言わんほうがええで Python界隈のCodonを以前評価したけど速度面でC/C++と同等なのは単純なケースに限られるようだった しかも多分皆が最初にみたAckermannの例はgccがclangを凌駕するパターン(再帰Fibonacciなんかもそう) 良いとこだけ記事にした方がいいねもらえるという情報ジレンマ.. どうせCPUじゃなく、GPUだのFPGAだのにオフロードするんだしw >>811 1クロック君 = ID:bU1qZ3nv のことか? 流し読みだと805は1クロック君で、>>752 =move君(C++,Rust,Python)とコムソートの話をしてるのね Rustユーザ-> >>563 みたいな数独パズル状態でどん詰まり傾向、途中LinkedListは遅い発言を受けるも >>581 でやっと動くが何もしない 1クロック君->呼ばれて登場、いつもの虚言連射 自分の思い込みと異なる現実を見たくないから意地でもコード書かない move君->(いろいろ分かってないので、1クロック君の虚言でも)何かしら動くコードにしてideoneに置く、慣れないC++で C++側->面白がってコード弄る、ベンチ晒す、けど全員離脱 move君はそれでも勉強になったとお礼 move君、いい奴なんじゃね? あらゆるところに関所がある まるで江戸時代だ 裏山に抜け道を見付けて分け入っても 突然藪から棒に番人が現れる ところがそんな番人も unsafe印籠を魅せれば一撃で退散だ unsafe万歳!!! こんなことなら最初から 表通りでunsafe印籠を出しておけば良かったんだ きっと番人たちも思っているはず さっさと最初からunsafe印籠魅せやがれ 無駄な手間取らせやがって こんなのがエコシステムとか失笑もの C++のバイブルeffective C++でやってることを何も考えなくても できるのがRustだよな C++のconstを更にウザくした感じをデフォルトにした? まぁ安全なんだろうけども >>817 間違い:何も考えなくてもできる 正解:考えないとエラーが出る これが先週のLinkedListチャレンジの結末である Rust → どん詰まり傾向、1になればゴール 慣れないC++で → 慣れてなくとも独力で0を1にして動くコード提出、その先は先輩たちがサクッと引きあげ ちょっとした車輪ならぱぱっと組めて当然なのがC++ (俺はまだまだだけどw だからこそ、メモリ関係のバグ・デバグに気を取られたくない unsafeの取り込みは急務 よろしくゴサシュー ×Rust → どん詰まり傾向、1になればゴール 〇Rust → どん詰まり、1に出来ずに、ポエムにいいね C++でもnew/deleteなんてだいぶ前から使ってないけどな C++03時代の話を未だにしてるけど、20年も前の環境だし、Boostも1.84からC++03のサポート終了が本格化する この際、C++20まで一気にジャンプしたら良い C++17と20の間にも互換性の壁があるので、過去の資産があるならC++17でも良いかもしれない C++20は便利なので、資産が無いなら一気に飛べ 顧客には「リスク歓迎型」と「リスク重視型」いるが、Rustはいまのところ 前者が使ってる段階。 let temp = Client::RiskFriendly; >>824 C++20になったらこれに対応できるようになるって話はどうなったんだっけ? [Ruby] a.sort().reverse().map{|x| x.to_s}.join("-") [JavaScript] a.sort().reverse().map(x => x.toString()).join("-") [Rust] a.iter().sorted().rev().map(|x| x.to_string()).join("-") よく表れる偉そうな人は プロジェクトでは活躍できているの? >>828 既存のイテレータの問題を改善するためにC++20でstd::rangesが導入された しかし限界というか期待外れというか無理があって使いやすいものにならなかった >>826 リスクを恐れずに新しいものを好む人、失敗しても特になんとも思わない人が 試している状態だということ。 >>831 それは5年以上前の話 現在は様々なインフラがRust製に置き換わりつつある段階 例えばRustで書かれたAWSが安全に問題なく高速に作動し、その上に世界中の各社のサービスが動いていて、世界中の人々が恩恵を受けている >>832 ただ、プログラミング業界において、まだ、使用者数が1%未満くらいしかない。 イノベーター理論によれば、2.5%位までが「イノベーター層」、次の20% 位が、アーリーアダプター層で、それらを合わせた23%位が、「リスク歓迎層」 いわゆる「人柱層」であり、その後に「キャズム」と呼ばれる溝が有ると言われている。 だからRustが普及するためにはまだまだずっと先が有る。 >>833 大勢に影響ないが、数値はちょっとずれていて、ちゃんと調べてみたら、 イノベーター層: 2.5% アーリーアダプター層: 13.5% ----キャズム---- アーリーマジョリティー層 34.0% だったわ。 ソースコードはAWSの0.001%も使われとらんと思うぞw 有料商品だとリスクを恐れて買わない人が多いけど、Rustは無料だから 試すのはタダだから、金銭的には損はしないが時間とストレージ容量は損する。 ジュースみたいに飲んで美味しいわけでもない。 Rustを試す場合、ストレージが結構食うのと、「パス汚染」の問題や、いつのまにか 大事にしていた開発の複雑なツールチェイン環境が 「おかしくなるかも知れない問題」が有る。 経験法則として、ツールチェインが壊れることは辛すぎる。 Rustは、確かにニーズは有ることはあるが、緊急レベルが低いのかもね。 それとターゲット層が狭いかも。 Rustを使いたがってる層って、なぜかサーバーサイドで使おうと思ってる人が多いが、 複雑で遅くなるような処理はMySQLやSQLiteみたいなDBMSがやってしまう。 だから自分でやる部分は余り速度が必要なかったりする。 Rustは安全性と速度の両方重視だが、この場合、速度は不要であり、安全面だけ しか残らないがだとすると、JavaやRubyなどでも互角と言えてしまう。 しかも分かり易さは後者の方が勝ってる。 SNSを見ても、なぜかRustをフロントやデスクトップアプリで使おうとしている人は少ない。 そもそもデスクトップアプリが絶滅危惧種になりつつあるが。 多分、GAFAMが全部需要を吸い取っているからかも知れんが。 そもそも、サーバーサイドやフロントは、CもC++も余り使われてこなかったが、 SNSでは、なぜか、そっち側でRustを使いたがってる人が目立つ。 そもそも、デスクトップやゲームでCやC++が強い。だから、C++の優位性や 慣れ親しみが有る人と層が被ってない。 なのに、彼らは「C/C++をRustが置き換える」と主張している。 彼らにはそもそも自分がCやC++を愛した時期があったのかと問うてみたい。 C++を使いこなした上で、さらにそれより便利だからRustを使おうとしている ならまだしも、C++とは縁遠い人達がRustを礼賛している様に思えてならない。 もともとC++が大嫌いな状態で、C++が消えてなくなればいい、と思っている 層がRustを嬉々として使いたがっている様に見えるのだ。 そして彼らはC/C++を一切話題にしない。もし今ままでC/C++を使い倒してきた ならば、少しは触れてもいいはずなのに、彼らが好きな言語としてあげるリスト の中には、決まって、C/C++が全く触れられておらず、 JS、Go、Kotlin、Java、Pythonなどが上がってくる。 C#ですら上がって来ない事が多い。 よく見ると、彼らがリストアップする言語は、無料の環境ばかりだ。 昔から言われてきたことだが、Windowsのデスクトップアプリを作るのは、 ほぼ Visual Studio 一択 だということである、 そして、その場合、通常、C/C++(MFC、Win32)、C#(WinForms、WPF)、VB のどれかとなる。 プロは、有料のVSを購入して、C++でMFCで組むのが標準とされてきた。 BoostはURLやJSON、そしてついにMySQLが入ったぞ RegexはC++のパワーが発揮される好例だが、あまり使われてないね 文字を返すイテレータさえ用意できれば、どんなデータ構造にも正規表現が使えるんだから凄いけどね >>848 RegExの基礎の部分で、日本語周りがちょっと独特の仕様だった気がする。 UTF8やSJISには状態がない(Stateless)符合なのに、状態があるかのような 独特のC関数(?)を基礎にしている。 それは、もはやほとんど使われて無い、「Shiftじゃない方のJIS」の ShiftIn(SI), ShiftOut(SO)方式ならそうかも知れないが。 >>846 だとするとC#しか選択肢が無い事になる。 >>843 補足すると、C++が好きで、または、どこかに問題点を感じながらも使ってきたが、 さらに良いものを見つけたからRustに移行したい、というなら、C++も好きな 言語リストに入れたり、話題に触れたりするものだが、彼らは一切、 C++に触れようとしない傾向がある。 どんな言語にも欠点があるから、長年使ってきた言語であるならば、 愛着があっても、欠点も知っている。だから、もしC++を使ってきたならば、 C++の欠点を沢山気付いても、一方で、愛着も持っているはずだ。 ところが、彼らは、C++について一切触れずに、初心者用の簡易言語で あるところの、JS、Java、Kotlin、Go、C#、Pythonなどには沢山触れるが、 C++には一切触れようとしない。 >>851 キミもあまりC++を使っていないのでは? 世の中の流れが様々な方向からRustへ向かっているところをみると残るは時間だけの問題かな ロジックに弱い一部のプログラマーはRustでスマートに組めない傾向があるからその点での差別化も進むのかもしれない >>854 もしかしたらそうなのかも知れないな、と思う自分もいるが、 数値を見れば、ランキングは19位くらいで、使用者数は1%未満の状態。 それと個人的には、言語としてメンドクサイ。 >>855 Rustをメンドクサイと感じるならロジックが苦手な人なのかもしれないね 一般的にどの言語でもプログラミングする時はロジックをパズルのように解いて組み立てていくんだけど 複雑な対象かどうかでそのパズルの難易度は様々でロジックが苦手な人は難しいパズルのケースではお手上げ Rustではその解かなきゃいけないパズルが問題によって難易度が増す場合もある それと引き換えに様々な多大な恩恵が生じるわけだけどロジックが苦手な人には難しかったり面倒だったり無理だったりしてしまう でも元々のパズル自体の難度に対してそれほど難しくなるわけではないためプログラマーのほとんどはクリアできるけどね 結果的に極一部のロジックが苦手なプログラマーを切り捨てることで可読性や開発効率や安全性などを上昇させるのがRustというものの本質かもね >>856 ロジックは大好き。 ロジックではなく、Rustの字面が合わない。 ぶったぎるようでいて、多分関連ある 素直に聞かせて 上のほうでも少し出たけど、RustのOOPってどうなん 慣れればわりとなんでも書ける? 所有権関係を見習いたくて、そればっかり今まで調べてて、OOPの書き心地に目を向けてなかった >>850 たまにはATL/WTLも思い出してあげてください あれ使いこなせるようになりたいな そんなことを思いながらC++を趣味でやってる(異業種です >>858 RustやGoなど最近の言語ではOOPの癌であるクラス継承を完全に廃止してくれている点が朗報 代わりにRustでは強力なトレイトがあって非常に分かりやすく可読性もよいコードに誘導されて書き心地もよいよ ただしクラス継承という癌におかされ中毒症状というか依存症の人の一部はリハビリ期間が必要なこともあるみたい ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる