23/05/05 06:12:56.25 EdqaEPwW.net
マイクロソフトがわざわざC++を捨ててまでRustを採用するとはよっぽどのことだよな
Linuxの方は元からC++さえ排除してC言語だけの純血主義だったのにRustを採用し始めてる
51:デフォルトの名無しさん
23/05/05 06:30:56.10 EdqaEPwW.net
>>49
記事を読んだがブートローダーなんて書かれてなかった
Rustを使った場合のWindows OSのパフォーマンス比較でOffice apps使用の場合が出てくるからブートローダーの話ではないね
52:デフォルトの名無しさん
23/05/05 06:37:43.26 yAiikMv0.net
昔、マイクロソフトはわざわざJAVAを捨ててJ++を開発したんだよなあ
53:デフォルトの名無しさん
23/05/05 06:58:16.61 4d5P5zld.net
これまで多数の言語が登場したけど求められてる条件はたった二つだけ
「C/C++と同等のパフォーマンスが出ること」
「C/C++の各種安全性の問題が解決されていること」
Rustが最初で唯一の言語
54:デフォルトの名無しさん
23/05/05 08:25:55.79 tbrjl4OG.net
>>53
どこの異世界にすんでるんだ？
55:デフォルトの名無しさん
23/05/05 08:50:30.82 hIDnL8bT.net
>>53
安全にするにはGC言語にするしかないと思われていたからね
Rustだけが勝者となった
56:デフォルトの名無しさん
23/05/05 09:46:15.52 whzNuXwL.net
Rust以外でGC採用せずにメモリやリソースの後始末をちゃんとしてくれるよう設計された言語って何があるの？
57:デフォルトの名無しさん
23/05/05 10:06:18.39 kHrmJumu.net
お! GC君だ（この人が複製おじさん?）
GC君は他人のことを初心者呼ばわりするけど
技術的な話が全くできないんだよなぁ...
58:デフォルトの名無しさん
23/05/05 10:21:16.98 kHrmJumu.net
>>50
$ tar xJf linux-6.3.1.tar.xz
$ find linux-6.3.1 -name *.c -o -name *.h | wc -l
55806
$ find linux-6.3.1 -name *.rs | wc -l
38
0.07%未満! 前回v6.2.1のとき37だったから1ファイルは増えてるね
何が増えたかは
$ diff -uNr <(cd linux-6.2.1; find . -name *.rs) <(cd linux-6.3.1; find . -name *.rs)
59:デフォルトの名無しさん
23/05/05 10:43:09.36 5yMxjojq.net
>>52
JavaScriptをわざわざパクッてJscriptってのも作ったな
今やIEブラウザごと滅んだが
アップルとかソニーとか独自規格を作りたがる連中はいつの時代も迷惑
60:デフォルトの名無しさん
23/05/05 10:47:34.91 /B4W1iLS.net
Rustはメモリリークには割と寛容なんだよね
野生の参照（ダングリングポインタ）は目の敵にするけど
61:デフォルトの名無しさん
23/05/05 10:52:02.55 rN2P+U1s.net
>>56
Rustしか現存しない
他に出てきそうにないため今後Rustの時代が続くのだろう
62:デフォルトの名無しさん
23/05/05 11:08:39.58 nhdCkkeF.net
>>45
>デコンストラクトによるパターンマッチ
聞かない用語ですねぇ～
デコンストラクト
63:デフォルトの名無しさん
23/05/05 11:27:48.85 i1pozoob.net
>>56
Nim
64:デフォルトの名無しさん
23/05/05 11:29:46.84 i1pozoob.net
>>60
ヒモさえ付いてれば無駄遣いしてもOKみたいな
65:デフォルトの名無しさん
23/05/05 11:58:16.34 kHrmJumu.net
RustってNimに対して何か優位なところはあるの?
66:デフォルトの名無しさん
23/05/05 12:01:00.00 1hHdixRp.net
>>63
NimはGC言語
GCに頼らず済ませられる部分のみ使わないで済むというだけ
67:デフォルトの名無しさん
23/05/05 12:15:37.38 t/UudqdO.net
>>56
間違い：メモリやリソースの後始末をちゃんとしてくれる
正解：メモリやリソースの後始末をちゃんとしてくれる(リーク除く)
68:デフォルトの名無しさん
23/05/05 12:17:42.38 0uwn+ADY.net
Nimはnilが存在していてヌル安全ですらない
69:デフォルトの名無しさん
23/05/05 12:18:25.68 O7pFd4FM.net
基本GCでも充分な性能が出れば別にいいよ
最適化が必要なところだけ手動でやるのはRustも同じだから
手動ライフタイム管理とのトレードオフ
70:デフォルトの名無しさん
23/05/05 12:22:56.73 kk7gdR4M.net
>>69
RustはNimのような逃げをしていない点で全く異なるよね
NimはGC言語という点でも誰も異論はなく
71:デフォルトの名無しさん
23/05/05 12:28:44.39 t/UudqdO.net
>>56
Factorかね。
72:デフォルトの名無しさん
23/05/05 12:37:44.37 A/rFKldr.net
FactorはForthとLispの子みたいな動的型付け言語
ガベージコレクションあり
73:デフォルトの名無しさん
23/05/05 16:12:43.08 UEq66Q3K.net
GCの有無は指標になるけど、現状のC++の、なんでもかんでもヒープに置く習慣は、
GCとそんなかわらないんじゃ…と思わなくもなかったり
74:デフォルトの名無しさん
23/05/05 16:21:47.02 ugKRRbai.net
C++はコンパクションが行えないので、GC付きのJavaのほうが速いのです
って言ってなかった？
75:デフォルトの名無しさん
23/05/05 17:13:23.83 /B4W1iLS.net
感覚的にはプリミティブでない単純なデータ（xyz座標とか）の配列を直接作れるかどうかがボーダーな気がする
ポインタの配列を作ってるようだとGCしなくてもGC言語
C#は微妙なライン
変なタイミングで大掃除始める問題もあるけどこっちを気にする機会は少ないような
76:デフォルトの名無しさん
23/05/05 18:05:31.65 ugKRRbai.net
結局、RustはC++より速くても、Javaよりは遅いってことですね
77:デフォルトの名無しさん
23/05/05 19:01:02.92 yAiikMv0.net
もう少し待てはマイクロソフトがR++を出すと思うから
それまで待って
78:デフォルトの名無しさん
23/05/05 23:04:16.37 Vdiv+WAP.net
JAVAが速い！？
79:デフォルトの名無しさん
23/05/05 23:05:51.16 A/rFKldr.net
>>76
Rustはスタックを多用する言語なのでJavaより速い
80:デフォルトの名無しさん
23/05/05 23:35:38.70 ugKRRbai.net
>>79
証拠は？
81:デフォルトの名無しさん
23/05/05 23:47:38.29 A/rFKldr.net
>>80
スタック上のメモリ領域はCPUレジスタであるスタックポインタを足し算引き算するだけでメモリ確保と解放できるため最も速い
82:デフォルトの名無しさん
23/05/05 23:50:40.76 tbrjl4OG.net
>>81
CPUの仕組みを知っててそういう認識の人はいないと思いますよ
83:デフォルトの名無しさん
23/05/05 23:56:37.63 Ena393we.net
もうみた～
84:デフォルトの名無しさん
23/05/06 00:11:48.42 GtwTEHkL.net
>>81のスタックメモリ利用が一番速いで合ってるけど
スタックメモリは関数から戻ると自動的に開放されその部分は無効になっちゃう
そのため従来の言語ではスタックメモリの利用を抑え気味にすることでその問題を過剰に回避してた
Rustはライフタイムの導入でスタックメモリを安全な範囲内の限界まで使えるようになったことが違いかな
85:デフォルトの名無しさん
23/05/06 00:20:07.63 SIOBPdzx.net
CPUのレジスタ利用が一番速いがレジスタ割り付けの最適化が非常に難しいので
スタックを使ってお茶を濁してる
86:デフォルトの名無しさん
23/05/06 00:36:19.82 cJf94Ar1.net
スタックメモリが主記憶と別の場所にあると思ってない？
87:デフォルトの名無しさん
23/05/06 00:39:27.80 cJf94Ar1.net
もしかしてヒープは主記憶、スタックはプロセッサの中にあるとか思ってない？
いま検索中？
88:デフォルトの名無しさん
23/05/06 00:43:00.80 GtwTEHkL.net
メモリの確保の仕方の違いでの速さの比較の話でレジスタの話を持ち出すのは違うでしょ
そしてレジスタの数は限界がありその退避先もスタックメモリですよ
スタックメモリに割り当てられた変数は最適化によりレジスタ割り当てが可能であればレジスタのみ利用になりますね
>>86
スタックメモリは単なるメインメインの一部にすぎません
しかしメモリ確保と解放が最も速いだけでなくメモリキャッシュに載る点でアクセスも速いです
89:デフォルトの名無しさん
23/05/06 00:43:06.74 ky4tntbz.net
キャッシュメモリは主記憶に含めておいた方がいい？
90:デフォルトの名無しさん
23/05/06 00:43:19.23 SIOBPdzx.net
頭のおかしい人間がずっと一般的な事実に基づかない頓珍漢な独自妄想理論を展開してる
91:デフォルトの名無しさん
23/05/06 00:46:32.42 SIOBPdzx.net
スタックを積極的に利用しているからrustがjavaより速いと言われて
納得する馬鹿はいないだろ
もっと根本的な理由があるだろと
javaはVMでスタックマシンをエミュレートしてるから遅い
92:デフォルトの名無しさん
23/05/06 00:48:39.47 SIOBPdzx.net
通常はレジスタ一発で出来ることもわざわざスタックマシンでエミュレートしてるので遅い
93:デフォルトの名無しさん
23/05/06 00:49:43.41 cJf94Ar1.net
Rustもたいがい遅いだろ
94:デフォルトの名無しさん
23/05/06 00:50:53.23 SIOBPdzx.net
頭のおかしい人間がもう一人増えてた…
95:デフォルトの名無しさん
23/05/06 00:53:21.90 +ei0akhP.net
スタックメモリが確保の点でもキャッシュされてる点でも非常に速いのは常識
そのためGC言語であってもGoのようにまずはスタックメモリ利用を優先する
(他へ渡すときだけGC対象になるヒープを利用)
96:デフォルトの名無しさん
23/05/06 00:58:44.72 cJf94Ar1.net
でもJavaのほうが速いんでしょ？
97:デフォルトの名無しさん
23/05/06 01:02:01.90 GtwTEHkL.net
>>95
Rustはそこからさらに一歩進めて他へ渡すときもスタックメモリを使えるように改善してますね
Rustはライフタイムの導入でスタックメモリを安全な範囲内の限界まで使えるようになりました
98:デフォルトの名無しさん
23/05/06 01:13:46.56 SIOBPdzx.net
変な人大集合だね
それがrustよりjavaが速い理由だと思い込んで疑わない変な人たち
99:デフォルトの名無しさん
23/05/06 01:14:41.38 SIOBPdzx.net
おっと逆だ
それがjavaよりrustが速い理由だと思い込んで疑わない変な人たち
100:デフォルトの名無しさん
23/05/06 01:27:18.47 cJf94Ar1.net
RustはJavaより遅いだろ
101:デフォルトの名無しさん
23/05/06 02:12:11.55 8+gQNNXm.net
そなの?
102:デフォルトの名無しさん
23/05/06 03:12:15.76 eTXbn+fa.net
>>101
それはない。
103:デフォルトの名無しさん
23/05/06 06:31:50.59 BGrqS5mo.net
C++とRustに比べればJavaは当然遅いしどうでもいい
104:デフォルトの名無しさん
23/05/06 06:50:56.78 IDnb553v.net
スタックってそんなでかくない、っていう世界もCの領域なんだよね
そんときの感覚を今でも引きずってる気はする
アプリケーションの起動時に、がつんとデカく確保しちゃえばいいんだろうけどね
なんとなく、ね
105:デフォルトの名無しさん
23/05/06 07:22:20.41 cJf94Ar1.net
>>103
Javaが一番速くて、少し遅れてRust、かなり離されてC++だろ
106:デフォルトの名無しさん
23/05/06 07:46:12.61 a72ZoZZa.net
>>95
いわゆるエスケープ解析と呼ばれているテクニックだな
スタックメモリ利用が断トツに速いのでできる限り使うようにする
GoだけでなくJava含めていくつかの言語で行われてるが適用に限界がある
単純には各ポインタのライフタイムが関数内に閉じてればスタックメモリを利用
他の関数に渡した時は確実に追い切れないので難しい
それを可能とするには言語自体がライフタイムをサポートする必要がある
それを実現したのがRustでありライフタイムを完全に追うことができて現在最強
107:デフォルトの名無しさん
23/05/06 09:19:50.79 xQ/L7Xyj.net
RustよりJavaのほうが速くなることも多々あるけど
unsafeやarena使ったりして最適化すればJavaより遅い状況はなくなる
でもJavaもネイティブコンパイルできるようになってるから起動速度含めてシェルスクリプトの代わりに使えるくらいには十分速いよ
108:デフォルトの名無しさん
23/05/06 09:27:14.82 6sJMiJUH.net
ほとんどのベンチマークでRustが圧倒的に速い
自分でunsafeする必要なんかない
109:デフォルトの名無しさん
23/05/06 09:28:26.41 mjWAg2hj.net
JavaやGoより明らかに高い性能を得ようと思ったら面倒臭いRust特有の最適化が必要になるから
自分用のツールに速度目的でRustを使うのは生産性的におすすめしない
製品開発やそれに準ずるライブラリ開発であればRustも有り
110:デフォルトの名無しさん
23/05/06 09:34:58.48 zYAo+dX9.net
>>109
根拠なくそういうデマはよくないと思うよ
「面倒臭いRust特有の最適化が必要になる」なんて聞いたことも体験したこともない
111:デフォルトの名無しさん
23/05/06 09:46:59.89 IDnb553v.net
Javaはないわー
なんだかんだいって、Oracleのドル箱なんでしょ、あそこの法務はなめちゃだめだ＞＜
112:デフォルトの名無しさん
23/05/06 11:45:09.13 SIOBPdzx.net
chatGTPのいい加減なときの答えみたいなレスが増えたな
しょうもない細部にこだわって全体を一切見ない
事実を使って嘘を作るようなレス
113:デフォルトの名無しさん
23/05/06 14:05:33.18 49fczBUH.net
複オジの一人妄想エコーチェンバースレだからね
114:デフォルトの名無しさん
23/05/06 14:07:36.12 O4KUwdol.net
新しい燃料の投下だよ～
Mojo🔥
URLﾘﾝｸ(zenn.dev)
115:デフォルトの名無しさん
23/05/06 15:11:59.44 Vkc9/sC/.net
>>114
> すべてを1つの言語Mojoで書く。
> Pythonを書くか、metalまでスケールダウンします。
> 多数の低レベルのAIハードウェアをプログラムします。
> C++ や CUDA は必要ありません。
挑発的だな
Pythonがベースの拡張で書きにくいことが確定だからどうでもいい
116:デフォルトの名無しさん
23/05/06 15:24:45.43 IfxSkTCE.net
Pythonが手になじんでる人には吉報かも
こりゃC++に流れ込んでくる日も近いね
117:デフォルトの名無しさん
23/05/06 15:27:19.19 Vkc9/sC/.net
C++を不要にする目標なんだろ
無理だと思うが
118:デフォルトの名無しさん
23/05/06 15:39:53.37 u7GkjfSc.net
逆になるべくC++でやって行きたいと思う人も大勢いるということを
分かってない。
119:デフォルトの名無しさん
23/05/06 15:53:28.09 fVZUtdKL.net
名前からして ジョークじゃねえの
オースティンパワーズ デラックスで見たぞ これ
120:デフォルトの名無しさん
23/05/06 16:59:42.98 QDUY2JyG.net
喪女？
121:デフォルトの名無しさん
23/05/06 17:17:38.48 IfxSkTCE.net
Python使いだけど、全部自力で書きたい…みたいな
GC系言語にどんどん拡がっていくんじゃね
122:デフォルトの名無しさん
23/05/06 18:15:47.48 52PGn/Mb.net
>>106のエスケープ解析やライフタイムを本格的にやるのかな
C++を一気に超えてしまいそう
123:デフォルトの名無しさん
23/05/06 18:26:46.92 SIOBPdzx.net
少しrustの仕組みを勉強してきた
いろいろと勉強になった
面白いからしったかさんを泳がしておこうｗ
124:デフォルトの名無しさん
23/05/06 18:43:25.55 0gq0Gmfh.net
Pythonはインスタンスをヒープに置くことしかしていないが
スタックに置いて高速化するかもしれないのか
125:デフォルトの名無しさん
23/05/06 20:28:37.67 IfxSkTCE.net
LLVMとかあのへんに任せるんだろうから、できるようになりだしたらあっという間
126:デフォルトの名無しさん
23/05/06 23:34:35.68 9Mu3Cg1D.net
GCの分だけRustの方がJavaよりも早いんじゃないの
一般論だけど
127:デフォルトの名無しさん
23/05/06 23:43:00.84 8+gQNNXm.net
GCって予測不能なだけで速いか速くないかとは関係ないのでは?
それよりJavaはプロセッサとの間に入るJavaマシンが律速段階なのでは?
128:デフォルトの名無しさん
23/05/07 00:20:35.09 zx4D7i6q.net
一度実行したら コンパイルすりゃいいんじゃね
129:デフォルトの名無しさん
23/05/07 03:11:23.01 +pQ1lZnP.net
RustよりJavaのほうがだいぶ速い
130:デフォルトの名無しさん
23/05/07 06:16:47.38 7BVdtRv5.net
ネイティブコンパイルができるとからしいから、だいぶ速くなったんかしらんが
Java派のサイトでいいから資料示してくれ
>>111 のとおりで、触る気にはならん それこそJavaやるんならRustやる
131:デフォルトの名無しさん
23/05/07 07:39:12.44 UNWBnCPP.net
多くの人たちが一つの問題を色んな言語を用いて実装することで各言語の実行速度比較例
URLﾘﾝｸ(pbs.twimg.com)
AtCoderのABC182-E問題で提出された各プログラミング言語別の実行時間分布
132:デフォルトの名無しさん
23/05/07 07:45:16.15 ga+9ADYk.net
c++の実装数の多さよ。
Rustの「実装しようとしてできなかった数」がどれくらいになるのか知りたいところ。
133:デフォルトの名無しさん
23/05/07 08:07:01.05 IAlaDasW.net
>>131
Rustは書きやすいから
世間での普及と比較して多数使われてるな
速度もRustとC++は並んで最高速
一般での普及指標も毎年ぐんぐん上昇しているからあとは時間の問題のみか
134:デフォルトの名無しさん
23/05/07 10:50:21.49 xEkqTcpa.net
C、C++、Rust の速度に関しては、fact checkが必要。
少なくとも、C や C++ は、高級アセンブラなのだから、最速のはず。
Rustに負ける可能性はゼロ。
135:デフォルトの名無しさん
23/05/07 10:52:23.10 xEkqTcpa.net
「C++はRustより遅い」などと言っている人は、C++の標準ライブラリ(STL)
だけを使った場合に限定してしまっている。
C++は、アセンブラで書けることはほぼ何でも書けるし、Rustはそれを越える
ことは不可能なわけで、C++がRustより遅くなると言うのは論理的におかしい。
136:デフォルトの名無しさん
23/05/07 10:58:59.25 xEkqTcpa.net
もし、「RustがC++よりどうしても速くなる例」があるとするならば、
Rustのコンパイラは、C言語ではかけない特殊なマシン語を出力できる
ようになっているということである。
しかし、RustのバックエンドはLLVMであり、C/C++ のコンパイラ clang の
バックエンドも LLVM であることから、なぜそのような現象が起きるかは
大いに疑問となる。LLVMはLLVMレベルで最適化を行なうことができるような
コンパイラが存在しているので、C++が吐いたコードを最適化しても、
なぜか、Rustが吐いたコードを最適化したものより遅くなってしまうと言う
ことが起きなければならないことになる。
しかし、C++は、高級アセンブラであり、アセンブラで書けることは特殊命令
以外は基本的に全て書ける。ということは、Rustは、そのような特殊命令を
出力しない限りは、C++に勝つことは不可能と言っても過言ではない。
137:デフォルトの名無しさん
23/05/07 11:00:30.38 +pQ1lZnP.net
いや、>>131 を見る限り、平均するとC++はPythonにすら負けてる
138:デフォルトの名無しさん
23/05/07 11:01:52.13 ms6+oRxa.net
誰かがスタックメモリを使ってるからrustが早いと言ってるけどllvmレベルでは差がない
吐き出した中間コードみてもそんな特徴は特になかった
139:デフォルトの名無しさん
23/05/07 11:04:44.26 +pQ1lZnP.net
いや、>>131 を見る限り、平均するとRustは最速
140:デフォルトの名無しさん
23/05/07 11:06:24.77 xEkqTcpa.net
>>136
アセンブラに詳しくない人のために捕捉しておくと、特殊なマシン語の
例外(仲間はずれ)を除けば
「C言語の演算子は、アセンブラ(マシン語)の 1命令に一対一対応している」
とほぼ言える。なので、基本的に、マシン語を1命令ずつ書いていくのと
同じレベルでC言語はプログラム可能である。それに当てはまらないのは
CPUに依存したような「独特なマシン語」が存在している場合に限られる。
そして、コンピュータは、最終的には全てマシン語に置き換えられて実行され、
マシン語しか理解できない。
そして、C++は、C言語の演算子や機能は全て包含している。
ということは、C++は、特殊命令以外のマシン語を全て1命令ずつ記述できる、
ということである。
マシン語しか理解できないCPUに対して、C++は、あらゆる順序のマシン語を
ほぼ人間が思った通りの順序で書こうと思えば書けるのであるから、どうして、
C++が最速に成らないのだとしたら、非常に特殊な事態が起きていることになる。
その特殊な自体は、人間の手作業による最適化であると考えられている。
141:デフォルトの名無しさん
23/05/07 11:07:48.80 xEkqTcpa.net
>>139
平均と言うが、C++は、Rustのsafeモードを越えられる。
逆に、Rustはsafeモードだけを使っていると、C++に絶対に勝てない状況が
存在すると何度も指摘されている。
142:デフォルトの名無しさん
23/05/07 11:09:29.23 ms6+oRxa.net
>>139
それを見てもptyhon最速の人とC#最速の人が何をしたのかが気になるだけ
143:デフォルトの名無しさん
23/05/07 11:12:16.15 xEkqTcpa.net
>>140
「ほぼ」の意味を書いておく。
int x, y;
x = y;
と書くと、x,y をレジスタにとっていない場合は、
マシン語では、
mov eax,dword ptr [&y]
mov dword ptr [&x],eax
の2命令になり、基本的に1命令では書けない。
x,y がレジスタ、ebx, ecx にとられている場合は、
mov ebx,ecx
という1命令で書ける。
だから、x=y は、2命令になるときと1命令になるときが有る。
これが、「ほぼ」の意味である。
144:デフォルトの名無しさん
23/05/07 11:14:47.99 ms6+oRxa.net
llvmは仮想レジスタマシーンである
145:デフォルトの名無しさん
23/05/07 11:15:59.86 xEkqTcpa.net
>>143
同様に、x += y; は、
x,y をレジスタにとっていない場合は、
マシン語では、
mov eax,dword ptr [&y]
add dword ptr [&x],eax
となり、
x,y がレジスタ、ebx, ecx にとられている場合は、
add ebx,ecx
という1命令で書ける。
だから、x += y は、やはり、2命令になるときと1命令になるときが有る。
「ほぼ 一対一対応」の意味は、このような意味で言っている。
C言語はどうしてもマシン語よりも粒度が大きいので、1命令に置き換える
事が出来ずに、2命令か3命令程度になってしまうことはある。
146:デフォルトの名無しさん
23/05/07 11:17:50.86 xEkqTcpa.net
>>145
なお、Rustは、C言語よりさらに少し粒度が大きいことが多い。
C++は、C言語を包含するので、書こうと思えば、C言語と同じ粒度で書ける。
147:デフォルトの名無しさん
23/05/07 11:19:00.29 ms6+oRxa.net
ながながとつまらないことを書いてるな
最適化でsimdを自動で使ってくれるベースがあればそっちが勝つわ
148:デフォルトの名無しさん
23/05/07 11:20:09.23 xEkqTcpa.net
>>146
[補足]
誤解なきように行っておくと、Rustも、= や、+= のような演算子の粒度は、
C言語と基本的に同じことが多いので、その部分に関しての両者に優劣の
差は無い。だから、RustはC/C++と同じ程度の速度が出ることがある。
149:デフォルトの名無しさん
23/05/07 11:21:33.84 xEkqTcpa.net
>>147
基本を知らない人が誤解する可能性があるので書く必要があった。
C/C++がアセンブラ以外に負ける可能性はほぼ無いと言うことの
根拠を示した。
150:デフォルトの名無しさん
23/05/07 11:23:54.31 ms6+oRxa.net
コンパイラは高速化では中間言語化が有効なケースが多い
llvmの最適化はそれで行われてる
rustは二種類の中間言語に変換されてバイトコードを出す
でも中間言語に寄らないヒューリスティックな最適化も存在してる
そちらは泥臭く研究が進められてそちらは今llvmより速いコードを吐き出している
151:デフォルトの名無しさん
23/05/07 11:25:01.81 xEkqTcpa.net
「ほぼ」の意味が、よく誤解されているから、混乱が起きているようなのだ。
「ほぼ」というのは、>>143 や >>145 の意味においてである。
決して、曖昧な意味で言っているわけではない。
152:デフォルトの名無しさん
23/05/07 11:27:12.27 xEkqTcpa.net
>>150
それでも、C/C++は、そのRust独自の最適化後のコードを手作業で書くことが
できるから、Rustに負ける可能性が「ほぼ」ない。
ここで、「ほぼ」の意味は、>>143 や >>145 の意味である。
153:デフォルトの名無しさん
23/05/07 11:28:14.31 ms6+oRxa.net
エスケープ解析はjava一時期重点的に研究されて実装に取り込まれている
誰か天才的な人間が開発に来たんだろう
golangも後追いでエスケープ解析入れてるけどエスケープ解析をオンにすると速度が落ちるケースが多いらしい
開発者が愚鈍なのか想定ケースを外れてるのか不明
154:デフォルトの名無しさん
23/05/07 11:29:33.02 xEkqTcpa.net
マシン語とは、mov,add,sub,mul,imul,div,idiv,cmp,jnz,jb, jbe, ja, jae,call,ret
の組み合わせでプログラムする方式である。
それは、C/C++ 言語で「ほぼ」一対一対応でかけてしまう。
なので、Rustがそれを越えることは「ほぼ」不可能。
「ほぼ」の意味は、>>143 や >>145 の意味。
155:デフォルトの名無しさん
23/05/07 11:34:06.34 xEkqTcpa.net
>>154
マシン語プログラミングとは、
mov,add,sub,mul,imul,div,idiv,cmp,jnz,jb, jbe, ja, jae,call,ret
のような20個ほどの命令を組み合わせて書く書き方。
ところが、C言語では、少し粒度が大きくなってしまうが、それらの20個の
命令に対応する命令が存在している。つまり、C言語では、マシン語の
1～3命令の単位で命令を書くことが出来る。マシン語の1命令にならない
ケースは、レジスタが足りなくて本質的に1命令で書けない場合。
156:デフォルトの名無しさん
23/05/07 11:35:48.42 ms6+oRxa.net
エスケープ解析が有効なシーンにあっても速度向上はわずか1%～2%ぐらいのレベルなので
誤差と言えば誤差
157:デフォルトの名無しさん
23/05/07 11:37:17.94 zo7jDOyY.net
>>154
時代に取り残されてるな
まず大昔にレジスタ最大限活用最適化により1対1は崩れてる
さらにパイプライン最適化によって手書きアセンブリが敗北するようになってのがだいぶ昔の話
並行してキャッシュ最大限活用最適化によりスタック利用有利がさらに強まったり
158:デフォルトの名無しさん
23/05/07 11:38:19.17 xEkqTcpa.net
>>157
そんなことない。
159:デフォルトの名無しさん
23/05/07 11:40:38.01 ms6+oRxa.net
お互いに自分の強いと思う必殺技を叫んで殴り合ってる状態だな
映画館に行かずにこんなところで聖闘士星矢が見られるとは…
160:デフォルトの名無しさん
23/05/07 11:46:33.50 g30pVgXT.net
今は究極のパイプライン最適化により
生成された機械語と元のプログラミング言語は実行順序すら異なる
だから連投してるアホ>>155の書き込みは読む必要なし
memory orderingとかすら知らない低レベル
161:デフォルトの名無しさん
23/05/07 11:46:55.96 xEkqTcpa.net
いくらRustが独自の最適化しても、その最適化と同じことを
C++では書こうと思えば書けてしまうのだから、C++が負ける可能性
はない可能性がとても高いと言うこと。
162:デフォルトの名無しさん
23/05/07 11:48:22.26 xEkqTcpa.net
>>160
そのレベルの最適化は、コンパイラの最後の段階であるところのLLVMレベル
で行なわれるから、Rustとclangで差が出ることは無い。
出るとしたら、LLVM最適化がたまたまその時には上手く最適化できなかっただけ。
163:デフォルトの名無しさん
23/05/07 11:49:35.05 xEkqTcpa.net
>>162
厳密に言うと、「LLVMレベル」ではなく、それより
さらにマシン語に近いところのレベルの最適化。
164:デフォルトの名無しさん
23/05/07 11:54:20.57 0dpKtdVy.net
まあ一番差が出るのは浮動小数ユニットの扱いだけどね。
165:デフォルトの名無しさん
23/05/07 11:57:59.97 sE0vXw4X.net
>>162
同じLLVMを用いていても
C++よりRustが速くなった例はいくつか知られていて
それはRustの参照排他ルールによりLLVMに渡すことができる制御情報オプションが増えることで
LLVMによる最適化がRustの場合のみ生じることが原因のようです
つまりRustの言語仕様がC++より速くなるケースを生み出しています
166:デフォルトの名無しさん
23/05/07 12:20:49.96 ms6+oRxa.net
どんどん互いにいい技術をパクリあって向上したらいいだけだろ
今後AIによるコード研究が進むだろうし技術的境目はどんどんあいまいになってく
過疎板でお互いにペガサス流星拳を打ち合う必要もなくなる
167:デフォルトの名無しさん
23/05/07 12:44:26.77 IEKfrntf.net
>>131
そもそもこのグラフが、何を測定したかの説明も無い。
事実である根拠も無い。
Rustだけ優秀な人がプログラムし、C++では、スクリプト言語上がりの
CPUやマシン語の基礎が分かってない人がプログラムしたのかもしれない。
それに、Rustは、必ず世界最強クラスの最適化バックエンドLLVMを使っている
のに対し、C++用のコンパイラは最適化がほとんど行なわれないような簡易
コンパイラも含まれる。
168:デフォルトの名無しさん
23/05/07 12:45:57.83 7BVdtRv5.net
ていうか、シンプルにしか書けない(のが利点の)Rustに負けるC++の書きようが悪いって話
きれいに書こうなｗ
169:デフォルトの名無しさん
23/05/07 12:47:17.14 IEKfrntf.net
>>131
「実行時間」というが、PICやAKI-H8、ラズパイPICO、安物Androidデバイス
と、Core i9 とでは全然違ってくる。
Rustは、32BIT 以上専用なのに対し、C++ は、8MHz(?) の 16BIT の
PIC マイコンでも使えるのだから、比較にならない。
C++は、安い低速CPUでも動くが、Rustは高級で豪華な CPU でしか動かない
ということだ。それがグラフに現れているだけだろう。
170:デフォルトの名無しさん
23/05/07 12:49:59.71 IEKfrntf.net
>>165
>それはRustの参照排他ルールによりLLVMに渡すことができる制御情報オプションが増えることで
>LLVMによる最適化がRustの場合のみ生じることが原因のようです
>つまりRustの言語仕様がC++より速くなるケースを生み出しています
その場合、C++でも、同じ「参照排他ルール」に従ってプログラムすれば、
LLVMは同じように最適化できるだろう。
171:デフォルトの名無しさん
23/05/07 12:52:04.21 ms6+oRxa.net
>>167
>>169
atcoderは競技プログラムのプラットフォームで参加者がコード書いて提出
コンパイルも向こうでされてるので統一した環境ではあるかなとｗ
172:デフォルトの名無しさん
23/05/07 12:56:54.33 IEKfrntf.net
>>171
だったら、外国では、C++には、レベルの低い人も参加したのに対して、
Rustはレベルの高い人だけが参加した可能性が高い。
173:デフォルトの名無しさん
23/05/07 13:02:09.04 ms6+oRxa.net
atcoderは日本のサイトだよ
出題は英語で去れ店の？
rustは答えを出せる人間が少なく
低レベルコーダーが足切りされてる可能性が高い
174:デフォルトの名無しさん
23/05/07 13:03:09.17 IEKfrntf.net
>>172
もう一つの可能性は、C++は歴史が長いから、古いCPUで測定された時の
実行時間が記録に残っているのに対し、Rustは、新しいCPUで測定された
記録しか存在して無いという不公平があるのかもしれない。
175:デフォルトの名無しさん
23/05/07 13:04:40.62 IEKfrntf.net
>>173
つまり、
「Rustは初心者向けではない」
「Rustは優秀な人が試している段階」
ということを示しているのかもしれない。
176:デフォルトの名無しさん
23/05/07 13:05:35.59 ms6+oRxa.net
おじいさんは自分の見たいものしか見ず考えもしない
177:デフォルトの名無しさん
23/05/07 13:10:50.09 IEKfrntf.net
Rust信者は木を見て森を見ず。
178:デフォルトの名無しさん
23/05/07 13:11:54.80 tSA2wRyk.net
>>170
参照排他ルールに従うプログラミングをするだけでは最適化されません
言語コンパイラがLLVMへその指示を出さないとLLVMは最適化しないし出来ません
例えばLLVMのnoalias最適化指示の場合
Rustではプログラマーは何も指定しなくても言語仕様によりRustコンパイラが自動的にLLVMへ自動的に指示を出します
C言語の場合はrestrict修飾子が導入されているためプログラマーが自己責任で修飾すればCコンパイラがその指示を出すことが可能です
C++は言語仕様にないためプログラマーは指示できません (言語仕様を独自拡張しているコンパイラのみ可能)
以上のようにプログラマーが何も指示せずともLLVMで最適化が行われるRustが有利な現状です
179:デフォルトの名無しさん
23/05/07 13:13:52.93 IEKfrntf.net
>>178
それは初めて知りました。
このスレで初めてまともな意見です。
180:デフォルトの名無しさん
23/05/07 13:15:46.72 TRA1GHWk.net
C++の方が自由度が高いのだから遅く書くことを妨げない
一方でRustの自由度は低い
書いた人のレベルが如実に現れたってだけでは?
実際に最速は変わらない
Cの最速が遅いのはサンプルが少なかったから?
181:デフォルトの名無しさん
23/05/07 13:16:13.51 ms6+oRxa.net
でたらめを書く前によく見ろよ
グラフにatcode abc 182 e と書かれてるからその問題見て見たらいいだろ
abc = AtCoder Beginner Contest
2020-11-08(日) 21:00 ~ 2020-11-08(日) 22:40 (100分)
問題はAからFまであり後ろに行くほど難易度が高い
E問題を見ると再帰も使わないただのループ問題だからrustの有利なシーンはないと思う
制限時間があるからそこまでの問題で事実上足切りされた人が多いんだろ
182:デフォルトの名無しさん
23/05/07 13:20:05.33 IEKfrntf.net
そもそも、atcoder なんて知りませんから。
183:デフォルトの名無しさん
23/05/07 13:21:58.46 ms6+oRxa.net
通常通り書くとやはりpythonとかは遅くなると思う
速い回答出せた人もいると言うことは技術的に枝狩りできるシーンがあるんだろうな
atcoder知らない＝おじいちゃん
184:デフォルトの名無しさん
23/05/07 13:22:50.40 IEKfrntf.net
C++でやった人は、単に個人の遊びとしてやっていただけなのに対し、
Rustでやった人は、Rustの力をこのスレで自慢するために最高の品質
のコードを書いた「バイアス」があった可能性を除外できない。
185:デフォルトの名無しさん
23/05/07 13:23:13.45 TuWfUTcM.net
atcoderで性能比較www
186:デフォルトの名無しさん
23/05/07 13:23:38.22 IEKfrntf.net
atcoderなんてやってるほど暇人じゃないから。
187:デフォルトの名無しさん
23/05/07 13:24:50.84 vTHLWOBH.net
なんで1問だけで比べるのか
データ公開されてるよね？
188:デフォルトの名無しさん
23/05/07 13:24:56.80 ms6+oRxa.net
それでこのスレでペガサス流星拳を撃ってるとｗ
その前におじいちゃんはe問題解けるのかなあ？
189:デフォルトの名無しさん
23/05/07 13:28:05.72 IEKfrntf.net
なにがペガサス流星拳なんだか、幼稚な。
190:デフォルトの名無しさん
23/05/07 13:30:01.06 ms6+oRxa.net
pythonでギリギリ問題解けるようなレベルの人間がc++やrustに移行できるとは思えない
c++やrustという言語で足切りされてる
でも今後はプログラマー不足が顕著になるのでpythonの利用が促進されると思うわ
191:デフォルトの名無しさん
23/05/07 13:33:41.26 IEKfrntf.net
そもそも、「実験しなければ分からない」というのは物理や数学、コンピュータの
世界ではウソ。理論があるし、人間には想像力があるんだから、思考実験で
済む場合が多い。但し、アホな人は除く必要がある。
192:デフォルトの名無しさん
23/05/07 13:34:36.79 ms6+oRxa.net
プログラムの最適化に詳しくてもプログラム自体出来ないなら本当に存在意義が不明なんだよな
○○が早いと言う人より目的時間内にコードを完成させる人が求められている
アセンブラが捨てられて高級言語が使われてる
生産性の向上が一番の問題
○○速くてスゲーと言うのは意味がない
知識があれば小学生にでも言える
193:デフォルトの名無しさん
23/05/07 13:39:28.20 mYeAuY/K.net
>>190
そこで不足している簡単なレベルかつPythonでできるようなことならば
類似サンプルも多数ネット上に転がっているせいでChatGPTが答えられる
だから従来は人員不足とされたその分野の人材は不要となった
C++/Rustで書かれる分野は少なくとも現状のAIは対応できない
特にインフラをAIが吐くコードに依存するのはリスクが高すぎるため人間の最後の砦として需要が残るだろう
194:デフォルトの名無しさん
23/05/07 13:42:06.90 ms6+oRxa.net
小学生に○○流星拳と言う言葉を教える
何かあればそれを叫ばせるこれがこのスレで起こってる全てです
195:デフォルトの名無しさん
23/05/07 14:20:21.84 7BVdtRv5.net
AtCoderの良問は良問だぞ 俺は全然だけど
あんなもん要らねえｗｗｗとうそぶきつつ、こそっとやっとくと賢くなる
196:デフォルトの名無しさん
23/05/07 14:44:33.78 DlXJa/i8.net
>>172みたいに自分に都合の良い想定を平気で行う人間は
どういう大学出てるんだろうな
「可能性が高い」なんて学部生のレポートレベルでも書かないわ
そのへんのリテラシーなくクソレス書き散らしてるの恥ずかしくないのか
197:デフォルトの名無しさん
23/05/07 15:02:41.71 gnxG91Nb.net
大見得切ってる割に単発で書いてる時点でな
198:デフォルトの名無しさん
23/05/07 15:11:30.83 zx4D7i6q.net
競技プログラミングってC++でやるもんでしょ
集まってくるやつのレベルもピンキリだよ
199:デフォルトの名無しさん
23/05/07 15:16:11.45 nivMpMsP.net
>>131の各プログラミング言語の実行速度比較は実行環境が統一されてる点で信頼度が非常に高いと思う
さらに多数の人たちがコードを書いているためコードのせいで遅くなったりする要因も排除できてる
たまにあるベンチマーク比較でコードが下手なせいで言語によって左右されてるのも見かけるため
200:デフォルトの名無しさん
23/05/07 15:29:50.80 ms6+oRxa.net
自分は触れたくないがpythonって存在は面白い
c++やrustには移れないのにpythonならできるって人が多い
今後c++やrustの研究が進んで実行速度が1%上がるとかそんなレベル
乾いたぞうきんを絞ってる
それだったらpythonをjava並みに引き上げるほうが社会的意義があると思う
pythonの有名ライブラリはc++で書かれてチューンされて実行速度は速い
個人が各部分のコードが遅くてもライブラリが速いならこれで十分
でもそれがc++ユーザーに反映されて利用が進んでいるとは言えない
一般の研究で利用はpythonに軸足が移ってる
今後も進むだろうし
201:デフォルトの名無しさん
23/05/07 15:33:01.77 zx4D7i6q.net
いや、どうみてもPython（PyPy3）書いてるやつらはヘタだな
C++のやつらと同じ程度の頭脳なら言語そのものの早さはともかく分布の形状が同じにならないとおかしい
Pythonだとベストのアルゴリズムを選べないんだろうか？
2500msまで行ってるのはC++しか無いがおそらくはタイムオーバーで失敗したやつもいる
この課題をクリアできたやつの統計だな
クリアできなかった人数もやっぱりC++とPythonが多いと思われる
単に利用者が多いからな
202:デフォルトの名無しさん
23/05/07 15:36:56.31 zx4D7i6q.net
頭脳程度が同じだとすればPythonだと10000ms程度で解けるような尾の方が足きりされてるから分布がそう見えるだけなのか？
すると分布の形状はC++とは相似で、pythonではそれが拡大されただけになる
203:デフォルトの名無しさん
23/05/07 15:39:50.70 ms6+oRxa.net
だから知能レベルが低くてコーディングが下手な人間が書いても成果が残せるんならそっちの言語に注視したほうがいい
ある意味優秀だからさ
たまにライブラリレベルで回答できる問題もあるし正規表現で解決できる問題もある
優劣と言うより実現できるかどうかの世界
204:デフォルトの名無しさん
23/05/07 15:41:53.17 zx4D7i6q.net
とするとC++とPythonの下位は全く同じアルゴリズムを使っているが、
C++の言語性能のおかげで2500msに収まっている
考えてることが同じ人間でそう変わるわけもない
205:デフォルトの名無しさん
23/05/07 15:43:48.79 /r7DBuOd.net
まともにプログラミングができる人ならばC++かRustもやるだろうしな
高速さと省メモリで他の言語とはまるで違う
このスレになぜかJavaのほうが速いと主張してる一匹いるが
206:デフォルトの名無しさん
23/05/07 15:46:07.10 /r7DBuOd.net
効率の良いプログラムを書けない人はAI代替でいいから不要となるんじゃないか
C++とRustだけが残りそうだ
207:デフォルトの名無しさん
23/05/07 15:47:17.20 ms6+oRxa.net
e問題を見れば分かるけどおそらく出題内容をベタにそのままプログラムすると遅くなる
c++の人たちはそんなことはしてないと思う
208:デフォルトの名無しさん
23/05/07 15:48:14.10 ms6+oRxa.net
いいすぎかな
実際自分は解いてないで雰囲気で言ってるだけだから的外れかもしれない
209:デフォルトの名無しさん
23/05/07 15:57:11.39 zx4D7i6q.net
後は手元でのコンパイル時間だろうか
gccとrustcでせいぜい100行200行のコード、コンパイル時間に差が出るとも思えないが
100倍も違ったらさすがに競技プログラミングでは忌避されるがそうじゃあないでしょう
そして書いてすぐ試せるとなるとpythonとかになる
にも関わらずRuby利用者がいないのは悲惨としか言いようがない
210:デフォルトの名無しさん
23/05/07 16:01:14.86 0+o01IGu.net
競プロに限らず無駄な効率悪いプログラムを書くプログラマーが溢れてる
そいつらで十分な分野はAIで置き換わるのたろう
ちゃんと考えて効率良いプログラムを書けるプログラマーならC++でもRustでも会得すぐだしな
211:デフォルトの名無しさん
23/05/07 16:03:17.49 ms6+oRxa.net
pythonは有名ライブラリ内でavx512使ってたりする
コードが寄贈されたりしてる
212:デフォルトの名無しさん
23/05/07 16:20:26.96 zx4D7i6q.net
あとはCargoと競技プログラミングの相性だろうか
213:デフォルトの名無しさん
23/05/07 17:00:28.41 ZuSoPChd.net
連休最終日だというのにお前らは
214:デフォルトの名無しさん
23/05/07 17:27:29.15 IEgposGn.net
>>206
効率の良いプログラムもAIが書いてくれるようになる
215:デフォルトの名無しさん
23/05/07 17:44:09.69 eOzMHQ5G.net
>>214
現在のAIの方式だとそれは無理だな
論理の理解がなく例えば素数すら列挙する以外に理解できない
足し算ですら桁が大きくなると間違える
抜本的な大発明が将来起きない限り見込みがないだろう
216:デフォルトの名無しさん
23/05/07 18:06:36.61 +pQ1lZnP.net
>>131 みれば、平均したらRustのほうがC++より速いだろ
それどころか、平均したらC++はPythonにも負けてそうだぞ
217:デフォルトの名無しさん
23/05/07 18:07:20.74 +pQ1lZnP.net
Pythonクソ速いな
C++より速いな
218:デフォルトの名無しさん
23/05/07 18:10:02.13 TRA1GHWk.net
boxプロットも読めない奴がいるなw
219:デフォルトの名無しさん
23/05/07 18:11:19.92 +pQ1lZnP.net
んなもん読まんでええのや
220:デフォルトの名無しさん
23/05/07 18:31:40.13 N703An5k.net
>>215
AtCoderの問題を解くような処理がプログラミングにおいて最もAIを活用できる分野だよ
広く知られたアルゴリズムの最適化なんてお手のもの
221:デフォルトの名無しさん
23/05/07 18:36:12.26 eOzMHQ5G.net
>>220
競プロに興味はない
そんな話はしていない
222:デフォルトの名無しさん
23/05/07 18:42:35.09 +pQ1lZnP.net
C++がウェブ界に進軍したら、お前らみんな無職だぞ
C++のパワーをまざまざと見せつけられ、しょんベンチビルと思うわ
223:デフォルトの名無しさん
23/05/07 18:43:59.40 +pQ1lZnP.net
それにしてもPython速いな
中にRust入ってるのと違うやろな
224:デフォルトの名無しさん
23/05/07 20:06:09.85 IEgposGn.net
>>215
AIが理解できなくてもパターンみたいに学習するからできちゃうんじゃん
突飛な想像力が必要なのは無理だろうけど
225:デフォルトの名無しさん
23/05/07 20:18:49.70 mxXhCe04.net
工夫すれば１行分（＋電球とブロックの位置）の記憶だけで解けるのか
H,Wが1500以下でメモリ制限1024MBだとH×Wの確保も許容範囲だからそこで差がつきそう
解答者全体のレベルがよく分からないけどPythonにもガチ勢がいただけでしょ
226:デフォルトの名無しさん
23/05/07 20:20:12.61 eOzMHQ5G.net
>>224
パターンはその通りで得意
しかしそこからの帰納法が無理
例えば素数を多数知っているがそこから素数の性質特徴を理解するのは無理
ただし学習として素数の性質特徴はわかるしプログラムも多数転がってるのでわかるだろう
でもそれじゃダメだ
未知のもの(初めてのもの)に対して出来ないといけない
227:デフォルトの名無しさん
23/05/07 20:42:06.12 IEgposGn.net
>>226
そういうことができるプログラマ以外いらなくなりそうだよね
228:◆QZaw55cn4c
23/05/07 21:21:38.60 MxFKzH70.net
>>226
素数に関して突っ込んでいえば、素数の定義と素数の性質＝すべての自然数は素数の積で一意に表現できる、との間には大きなギャップがあるのに、それがあまり意識されていないのが問題
229:デフォルトの名無しさん
23/05/07 21:25:03.91 /qC6ccnK.net
>>227
全く逆だよ
そういうことを差別化要素と捉えてるようなプログラマがいらなくなる
コモディティ化しやすい知識とそうでない知識の違い
230:デフォルトの名無しさん
23/05/07 21:34:18.83 IEgposGn.net
>>229
難しくてわかんない
もう少し優しく
231:デフォルトの名無しさん
23/05/07 22:10:30.80 HMVW7dad.net
バイアスがあった可能性を否定できない っていうんなら逆方向も否定できないだろうに、なんでこのおじいちゃんは片方にだけ肩入れするん？
不自然ですよ
232:デフォルトの名無しさん
23/05/08 00:59:11.95 abS4z/F4.net
最大の問題は rustの利用者が何でこんなに少ないかだな
ただ これには複案があって おそらくは C ++から 移ってきたやつらがrustをやってると思われる
すると rustの標榜する モットーにも合致すると思われる
233:デフォルトの名無しさん
23/05/08 01:13:16.38 abS4z/F4.net
もう出ている通りに この問題を最速で解く 機械語 は存在するので
あと疑うべきは 入出力のオーバーヘッドだけになる
メインのアルゴリズム やら ロジック やらが同じなら
遅くしている要因は 入出力だ
234:デフォルトの名無しさん
23/05/08 01:15:13.32 ddy6A8qL.net
>>232
しかし、SNSを見てると、好きな言語にRustを書いている人は、他の好きな言語と
して、JSやGo、Kotlinなどを挙げる傾向が強く、C++は全く書かれてない
ことが多い。
235:デフォルトの名無しさん
23/05/08 02:06:52.10 A57Tkf07.net
C++のほうが機能が多いので、使える人はC++を使うからだろ
236:デフォルトの名無しさん
23/05/08 02:33:43.51 ocGLFPvg.net
機能の差の比較は難しいが
言語自体で様々な安全保証をするRustの機能が本質的に大きいかな
237:デフォルトの名無しさん
23/05/08 02:37:25.24 A57Tkf07.net
C/C++の90%のコードが危険というような話は
9割が20年以上前に書かれているだけで
最近のマナーで書けば済む話では
238:デフォルトの名無しさん
23/05/08 03:00:18.94 ocGLFPvg.net
IT大手各社が揃って同じ判断をした
C++では無理なので新たなシステムからRustを採用
そしてRust Foundationを共同で立ち上げた
さらに既存のWindows、Linux、AndroidなどもRustの採用を開始
239:デフォルトの名無しさん
23/05/08 03:33:40.76 A57Tkf07.net
そんなこと言ったらJavaの採用も開始してるしC/C++なんか大昔から採用を開始してるだろ
240:デフォルトの名無しさん
23/05/08 03:48:41.01 42N5+bFw.net
非GC言語として絶対的な王道を確立したC++が存在するにも関わらず、
新たな部分からC++ではなくRustを採用し始めたことに重い意味があるのでしょう。
しかも競合ライバル同士が同じ判断をした点も非常に重い意味があるのでしょう。
そのため正しい判断をした可能性が極めて高いでしょう。
241:デフォルトの名無しさん
23/05/08 04:02:39.80 yn6KTAlC.net
C++は死ぬべきだけど、後釜がRustでいいかはわからんわ
コストかけて置き換えるなら最高の言語がいいしな
242:デフォルトの名無しさん
23/05/08 04:21:48.93 c35xMa4f.net
Rustの書きやすさは気に入ったね
次の言語はコンパイラが様々な保証をする点を押さえた上で、Rustが取り込めないような別の新たな画期的な機能を持たないといけない
他に芽が現状ないからこのままRustで進みそう
243:デフォルトの名無しさん
23/05/08 04:29:17.13 PP0yxCHU.net
この流れなら言える
cpp2を知らなかったなんて言えない
244:デフォルトの名無しさん
23/05/08 08:23:06.69 eWwLSdkD.net
実際のところ、将来的に最適化はAIがやるようになって、要件定義と検証だけ人間がやるようになるんだろ。
設計自動化の流れだわな。
そうなってくると実装を人間がやる状況は限定されて、言語もIDLみたいになってくるかと。土方コーダーは全滅だな。
まぁ、c++はCOBOLみたいに過去資産メンテに、Rustはpostscriptみたいにバックエンドで生き残る可能性はあるけど。
245:デフォルトの名無しさん
23/05/08 09:34:04.39 mYRj0CUt.net
>>244
AIにとっても機械語を直接吐くのは保守性が悪すぎる
一方で少なくとも当面は人間が検証できる既存のプログラミング言語になりそう
万が一の時の対応や問題把握のためにも既存の言語が良さそう
インフラは人間がある程度把握し続けないとAIに主導権を奪われかねない点でも同じ
使われる言語は自動的に色々と保証されるRustになるのかな
246:デフォルトの名無しさん
23/05/08 10:33:58.34 faKRd8TS.net
人命や経済損失に大きく関わるシステムは責任や論理的な信頼性の観点からAIに頼るのは無理そうだね。
247:デフォルトの名無しさん
23/05/08 10:45:11.11 iczXOFhv.net
AIはTDD（人間がテストコード書いてAIが実装コード書く）と相性いいかなって思ったけど
絶妙にテストケースだけパスするようなコード吐いてきそうで怖い
人間的な一般化パターンを学習すれば使えそうだけど現状だとコピペミキサーでしょ
248:デフォルトの名無しさん
23/05/08 11:29:16.24 Kh0HUP9F.net
AIがどうとか関係無いはずなんだが
Rustのここがダメ！みたいなことを書くと必死でレスしてくれる人がいるから無限に話を脱線させることができるんだね
249:デフォルトの名無しさん
23/05/08 11:46:17.60 PotcPEgC.net
.gitignore に Cargo.lock を入れてるのに
cargo publish すると Cargo.lock もうｐされる
github の方にはもちろんうｐされていない
cargo publish --allow-dirty は本気で要らないものまでうｐされるからこれはやってないのだが
250:デフォルトの名無しさん
23/05/08 12:11:03.58 Re0hEQKj.net
AIに書いてもらうプログラミング言語はC++かRustになるんだろうが、
C++でプログラムの本質でない部分の隙を残すよりも、
コンパイルが通れば静的にその部分が自動検証されるRustになるんだろうな
251:デフォルトの名無しさん
23/05/08 12:16:11.80 PotcPEgC.net
>>174
すばらC洞察
252:デフォルトの名無しさん
23/05/08 12:31:11.67 B7yn02Wa.net
>>251
バカだな
>>131の実行環境のマシンはプログラミング言語に依らず同一に決まってるだろ
253:デフォルトの名無しさん
23/05/08 12:43:44.96 PotcPEgC.net
>>201
これは良いサンプル
URLﾘﾝｸ(www.youtube.com)
254:デフォルトの名無しさん
23/05/08 12:43:46.40 iczXOFhv.net
>>249
内部で呼ばれるcargo packageの仕様っぽいね
URLﾘﾝｸ(doc.rust-lang.org)
の2.でCargo.lockを含める条件が書かれてる
excludeで強引に外せるのかな
255:デフォルトの名無しさん
23/05/08 12:48:52.30 PotcPEgC.net
>>228
全ての素数の積でπを造る公式あるな
256:デフォルトの名無しさん
23/05/08 12:50:45.02 PotcPEgC.net
>>234
C++使ってるけどC++が一番好きではない
どっちかというとCの方が好き
257:デフォルトの名無しさん
23/05/08 12:56:17.27 yn6KTAlC.net
Rustの検証や推論ってAIの役に立つか？というか役に立つようなAIを作るべきか？
それらもコンパイラではなくAIが判断するようにしたほうがよくないか？
258:デフォルトの名無しさん
23/05/08 12:57:11.50 PotcPEgC.net
thx!
259:デフォルトの名無しさん
23/05/08 13:48:29.03 imilCHLn.net
今話題になってるAIは緻密な整合性検証できるというよりも、人間の雑な問いに「らしい」答えを返してくれる感じだから、コンパイラ側の緻密な推論とかは引き続きやっていく必要あんじゃねえの。
260:デフォルトの名無しさん
23/05/08 14:22:47.81 yn6KTAlC.net
>>259
それならAIが内部でRust的なツールを使ってチェックするだけでよくて、
Rustのコードを出力する必要はないんじゃね
261:デフォルトの名無しさん
23/05/08 15:04:56.15 eTYn8zaL.net
>>245
AIにRustのコード吐かせる理由なんて無いよね
262:デフォルトの名無しさん
23/05/08 15:39:48.45 pZhRtbOb.net
Rust急進派によると、rustcをパスするコードは自動的に与信できるらしいので
263:デフォルトの名無しさん
23/05/08 15:42:47.04 QcAzVd3l.net
速度は、1%位の差になってくると、コンパイラの最適化能力に依存するが、
Rustはrustcの強力なLLVMを使っているのに、C++は、LLVMのclangを
使えばいいのになぜかgccを使っていたりするのもおかしい。
264:デフォルトの名無しさん
23/05/08 16:19:16.98 SySGd/wN.net
>>259 >>262
そうするとコードの安全性は人間かコンパイラが保証するしかないわけか
そうなるとAIに書いてもらうコードはRustしかないな
265:デフォルトの名無しさん
23/05/08 16:35:56.27 x8c+D5IZ.net
>>263
llvmの方がgccより性能良くなった?
266:デフォルトの名無しさん
23/05/08 16:41:27.47 NDGne9Ur.net
>>265
12年前から既にclangの方が速いです:
URLﾘﾝｸ(stackoverflow.com)
267:デフォルトの名無しさん
23/05/08 17:24:13.85 dxF1xGv4.net
>>264
仕様を自分で書く
仕様を満たしてるかどうかを確認するテストを機械に書かせる
テストが正しいがどうか人間がレビューする
テストをパスするコードを機械に書かせる
この繰り返し
機械にやらせてるところは今はベンダーに外注してる作業
抽象度が低くパターン化しやすい仕事ほど高い信頼度で機械化しやすい
268:デフォルトの名無しさん
23/05/08 18:43:10.50 A57Tkf07.net
>>266
その手の話は信用ならねえな
269:デフォルトの名無しさん
23/05/08 20:09:42.31 tptm3XCm.net
>>267
コーディングできない上流と設計できない下流の非効率なウォーターホール方式を続けるの？
テストさせられるほどの細かな設計まで自分でやるならコーディングもしてしまった方が早くない？
270:デフォルトの名無しさん
23/05/08 22:23:28.00 Sk4xBlmq.net
>>269
テストの粒度は上流から下流まで様々あるんだよ
テストさせられる==細かな設計とは限らない
ちなウォーターフォールね
271:デフォルトの名無しさん
23/05/08 22:48:34.95 23L22zMg.net
そんな上位の仕様を渡すだけで内部設計も何でも自動でやってくれるAIは当分来ない
学習して曖昧パターンで答えてくれる方のAIは論理的思考がまるでダメ
論理的な方のAIは厳密に指定し尽くさないと適当に補完してやってくれない
根本的に180度違うから融合の見通しもない
272:デフォルトの名無しさん
23/05/09 02:35:37.18 roDNqhiB.net
公開したcrateの要らなくなった古いバージョンとか消したくても消せないのか
githubよりタチが悪いな
他から参照してると仕方ないのが判るが
管理システムとして破綻してないかこれ
273:デフォルトの名無しさん
23/05/09 02:55:17.89 oJhOeTc4.net
yank
274:デフォルトの名無しさん
23/05/09 03:40:24.06 LWOtm1Dy.net
>>268
gccとclangのどちらの最適化が優れているかは誰にも分からないので、
その影響をなくすためにも、rustc と 比較すべきは gcc ではなく、clang
ということになるわけです。なので、今後ベンチマークを取る際には、
rustc vs clang で行かないと意味が有りません。
275:デフォルトの名無しさん
23/05/09 06:12:08.21 CM93Ewnl.net
そのように同じくLLVMを使ってコンパイルしても
>>178のように言語仕様が原因でC++が遅くなりRustが速くなる事例があるんだよな
276:デフォルトの名無しさん
23/05/09 07:51:20.97 roDNqhiB.net
yankしても消えないやん？
277:デフォルトの名無しさん
23/05/09 08:28:08.83 cNhnBb7C.net
いくらC++が速いといっても、ちゃんと書かないと速度は出ない
当たり前の事実と向き合うべき時期が来ているようだなｗ
278:デフォルトの名無しさん
23/05/09 09:22:12.89 E9TE6Urv.net
プログラミングは能力差が激しいからな
C++を使おうが遅いプログラムが出来上がってしまう人たちも多いが本人自身はなかなか気付けない
Rustだとそれが顕著に出るのでわかりやすい
入門初期は仕方ないがその後もRustを難しいとか面倒とか言ってる人たちは能力の低いプログラマーだけ
279:デフォルトの名無しさん
23/05/09 10:03:50.18 MyUREp4F.net
vec!とか使い捲ってると便利過ぎて
コピーされてるのか所有者移動してるのか意識してない人は遅くなりがち
280:デフォルトの名無しさん
23/05/09 10:17:59.79 DWbeMcsH.net
とフィボナッチイテレータより高度なプログラムが書けない人が申しております
281:デフォルトの名無しさん
23/05/09 10:29:01.80 VcsuRebp.net
>>279
vec!はベクタ初期化時のみに用いられるマクロにすぎずそんな問題はない
値一つ指定でN個を初期化するにはClone以外に方法はない
まあClone回避パターンもありRustは完璧だ
282:デフォルトの名無しさん
23/05/09 11:12:55.99 MyUREp4F.net
>vec!はベクタ初期化時のみに用いられるマクロにすぎずそんな問題はない
doubt
>値一つ指定でN個を初期化するにはClone以外に方法はない
doubt
>まあClone回避パターンもありRustは完璧だ
doubt
よくこんな短文で嘘ばかりかけるな
283:デフォルトの名無しさん
23/05/09 11:27:29.07 5GLz9i7j.net
複オジにいちいち突っ込んでたらキリがないぞ
騙されそうな奴がいなければほっとけばいい
284:デフォルトの名無しさん
23/05/09 11:41:48.76 aPAF6NA5.net
オジ使いの人は否定はしても理由も正解も書かないからどっちが正しいのかいつもわからん
285:デフォルトの名無しさん
23/05/09 12:08:20.62 By46q85D.net
オジオジ言ってる人は間違いも多いけど偶然あってるときもあるぞ
適当に聞き流しとけ
286:デフォルトの名無しさん
23/05/09 12:19:41.76 DWbeMcsH.net
な、単発だろ
287:デフォルトの名無しさん
23/05/09 12:27:45.30 DWbeMcsH.net
プログラミング言語に使われる人になってはいけない
プログラミング言語を使える人になりなさい
288:デフォルトの名無しさん
23/05/09 13:50:33.38 TWnpopnf.net
>>275
ですが、LLVMの最適化層は、メモリー領域が重なっているかどうかを解析する
機能も持っていますから、noaliasを明示的に付けなくても、最適化層が
自動的にnoalias相当の属性を付けてくれる場合も有り、そうなれば、
同じ程度に最適化されます。
C 言語の register 属性を付けなくても今のコンパイラは変数を自動的にレジスタ
に割り当てるのと似たようなことです。
飽くまでも補助情報です。
289:デフォルトの名無しさん
23/05/09 14:18:30.40 qRADqwfY.net
>>288
残念ながら一般的な場合にはその解析が不可能
そのためC言語はrestrictキーワードの指定の有無がそのまま最適化の有無に繋がる
このnoaliasによる最適化はベクトル化にも繋がるため実効果も大きい
Rustの可変参照は常にnoaliasとなりLLVMへその情報が伝わるため有利
290:デフォルトの名無しさん
23/05/09 14:27:49.18 TWnpopnf.net
>>289
>残念ながら一般的な場合にはその解析が不可能
一般的には難しいとされていますが、できる場合も有り、実際 LLVM
の最適化層は、解析を「しています」。
291:デフォルトの名無しさん
23/05/09 14:49:54.81 qRADqwfY.net
>>290
もちろんLLVMが解析で見つけ出すケースもゼロではないだろう
実際にはC言語でrestrict指定のコードを書くか否かで最適化の有無となっている現実が多々ある
つまり各言語はnoalias情報をLLVMへ渡したほうが確実に有利だ
C++は言語仕様にないが各コンパイラの独自拡張を使えば指定可能
もちろん無闇に指定してよいわけではなく確実にnoaliasと判断できる場合でないと動作不良を引き起こす
Rustは言語仕様によりデータ競合を起こさないよう可変参照が排他的になるため確実にnoaliasがLLVMに渡る
292:デフォルトの名無しさん
23/05/09 15:08:56.17 oJhOeTc4.net
URLﾘﾝｸ(stackoverflow.com)
だいたいそんな感じなんだけど実際にはバグったせいで付けたり外したりしてしてます
293:デフォルトの名無しさん
23/05/09 15:10:24.05 TWnpopnf.net
>>291
C++でも、noalias をつけたLLVMを出力するコンパイラも有るかも知れません。
コンパイラの進化の問題です。
294:デフォルトの名無しさん
23/05/09 15:21:42.16 GHMOM/oZ.net
>>292
バグが見つかったのはLLVM側ね
Rustが常にnoaliasをLLVMへ指定してくるようになって
適用事例が増えてLLVMのバグが発覚できた感じ
そしてLLVM側がバグ改修中にRust側は一時的にnoaliasの指定をオフした話だね
295:デフォルトの名無しさん
23/05/09 16:23:47.59 oJhOeTc4.net
重要なのは犯人捜しではなく
「可変参照は常にnoaliasとなり」は嘘だということです
296:デフォルトの名無しさん
23/05/09 16:57:31.86 qRADqwfY.net
>>293
Cではプログラマーがrestrict指定した箇所だけコンパイラがLLVMへnoalias指定する
C++ではプログラマーがコンパイラ独自拡張__restrict指定した箇所だけLLVMへnoalias指定される
言語仕様によりC/C++コンパイラがnoaliasを自動付与することはできない
C/C++プログラマーが安全に適用できると判断した時だけ自己責任でrestrict指定することになる
Rustは言語仕様により常に安全に自動的にコンパイラがLLVMへnoalias指定する
そのためRustプログラマーは何もしなくてもnoaliasによる最適化の恩恵を受けることができる
これが根本的な違い
297:デフォルトの名無しさん
23/05/09 17:04:50.38 9RO9lVT1.net
コンパイラに撃墜されてるRustプログラマもいるから「何もしなくても」は言い過ぎだな
298:デフォルトの名無しさん
23/05/09 17:08:17.41 qRADqwfY.net
>>295
現在はLLVMがバグ対応したため常にnoalias指定となる
もちろん意図的にバグ未対応の古いバージョンのLLVMを指定したときを除く
その場合にRustコンパイラはnoaliasを指定しないという安全な動作をする
299:デフォルトの名無しさん
23/05/09 17:09:31.38 oJhOeTc4.net
そんでいったい何nsec早くなるんですか？ってな
些細すぎる点です
300:デフォルトの名無しさん
23/05/09 17:30:52.58 JrSVS9vw.net
Rustならテキトー書いても速くなる…はさすがに夢見すぎだろう (やってないので)しらんけど
301:デフォルトの名無しさん
23/05/09 17:33:18.67 d0WXtuj5.net
おそらくだけど最適化が利いたとしてもベンチとかでは0.01%も速度は速くならないと思うけどな
302:デフォルトの名無しさん
23/05/09 17:35:11.58 d0WXtuj5.net
普通にコードを書く限り一般的な速度は
c<c++<rust何だろ
でもそんなのにこだわって言語選ぶ意味はないよ
303:デフォルトの名無しさん
23/05/09 17:49:39.63 d0WXtuj5.net
速度じゃないわな
実行時間だ
速度だと
c > c++ > rust
304:デフォルトの名無しさん
23/05/09 21:13:21.70 jpsGavbj.net
>>300
Rustは適当に書いたらコンパイル通らない。
305:デフォルトの名無しさん
23/05/09 21:36:53.43 Pc0KyjBY.net
いうて、C++でinline、constexprやらテンプレートメタとかで実行時の処理効率を上げまくったらRustじゃ敵わないと思うんだけど、、
Rustでも似たようなこと出来るんだっけ？
306:デフォルトの名無しさん
23/05/09 21:55:51.60 m/PdBmgz.net
>>305
できるよw
307:デフォルトの名無しさん
23/05/09 22:07:22.50 GHMOM/oZ.net
>>305
Rustもできるよ
そもそもRustのconstはコンパイル時定数でC++のconstexprのこと
Rustの手続きマクロはRustコードの構文解析を入出力としてコンパイル時に実行生成するためC++より強力だね
308:デフォルトの名無しさん
23/05/09 22:10:15.60 Pc0KyjBY.net
なるほどね
俺の全力のC++コードじゃRustには敵わないようだ
309:デフォルトの名無しさん
23/05/09 23:53:36.96 qRADqwfY.net
>>299
>>301
noalias指定で劇的に速くなる例はC言語でrestrict修飾の有無の解説ページが多数あって詳しい
restrict指定がないとnoalias最適化ができずにベクタ化されずに遅くなる例なども出ている
310:デフォルトの名無しさん
23/05/10 07:24:49.96 gVulLBUf.net
テキトーに書いてもコンパイルが通る言語に憧れるなあ
311:デフォルトの名無しさん
23/05/10 08:38:28.50 uLiToFDO.net
体感ではこうかな
c > rust > c++
312:デフォルトの名無しさん
23/05/10 08:59:49.54 yd4Msfz1.net
複雑なことを好き勝手に書けるのがC++だったけど、簡潔に書くことも求められるようになりそうだねえ
当初は複雑だったけど、やることが大体固まったものをrewriteするなら、
いまなら確かにrustがアツい 成果も目に見えると思う たぶんCでは力不足だしね
313:デフォルトの名無しさん
23/05/10 10:30:02.81 gGgNP0IP.net
>>308
全力のrustコードを書けばいい
314:デフォルトの名無しさん
23/05/10 12:47:47.75 of34847N.net
C++相談室part161、ﾜｯﾁｮｲ導入直前のスレ
ｽﾚﾘﾝｸ(tech板:343番)-381
ｽﾚﾘﾝｸ(tech板:481番)-650
C++相談室part162、ﾜｯﾁｮｲ導入直後
ｽﾚﾘﾝｸ(tech板)
"Rust" の検索結果: 1件
は～
315:デフォルトの名無しさん
23/05/10 12:48:26.46 usV3D88W.net
lintだけでもいいから、smart c++とか名前を付けてRustもどきの強制フォーマットを作って欲しいわ。
Rustそのものは要らん。
316:デフォルトの名無しさん
23/05/10 12:49:05.61 of34847N.net
Rust本スレもﾜｯﾁｮｲ無しのほうやめちまえばいいのにな
C++相談室はすんなり移行できてて羨ましい
317:デフォルトの名無しさん
23/05/10 13:11:50.30 dsu8fQGS.net
>>310
それならば静的型付けではない言語を選ぼう
ここは静的型付けのC++とRustのスレだからコンパイル時に可能な限りエラーを出す言語
>>315
その方向を求めるならばRustの方が優れているからC++にこだわる必要ないんじゃないかな
生産性の高いRustを使った方がメリット享受もたくさん
318:デフォルトの名無しさん
23/05/10 13:15:44.86 uLiToFDO.net
crates.io にうｐして docs.rs の comment cover が
中々 100% に到達しないんだが
どこの comment が足りないって簡単に教えてくれるツールは？
local で docker 使えば判るもんなの？
あと「未 comment」数を減らした(=100%に近付けた)はずなのに
逆に%下がるケースもあるみたいで良く判らん
319:デフォルトの名無しさん
23/05/10 14:03:23.86 jzBK8DOC.net
lintにmissing_docs
URLﾘﾝｸ(doc.rust-lang.org)
があるけどデフォルトでallowになってるらしい
lib.rs（main.rs）に
#![warn(missing_docs)]
を足すかコマンドで↓を実行
cargo rustc -- -W missing-docs
320:デフォルトの名無しさん
23/05/10 14:21:07.26 HatbRJDw.net
>>316
注意喚起テンプレとこの隔離スレが効いてるから本スレも平和
321:デフォルトの名無しさん
23/05/10 16:48:54.33 uLiToFDO.net
>>319
?クス
しかし足りない数(あと5ヶ所のはず)よりはるかに多い warning が出て来たでござる
322:デフォルトの名無しさん
23/05/10 17:11:01.06 uLiToFDO.net
>>319
5ヶ所治して残りの warning 放置で 100% 達成出来ました！
ほんとうにありがとうございました！！！
323:デフォルトの名無しさん
23/05/10 17:13:13.74 dsu8fQGS.net
コメントカバー率の計算対象は限定されてるよ
URLﾘﾝｸ(doc.rust-lang.org)
324:デフォルトの名無しさん
23/05/11 03:47:03.48 1mbxr1bo.net
C++だとdoxygenなど使うところが
Rustだと公式サポートされて色々と進んでいるのね
325:デフォルトの名無しさん
23/05/11 08:01:31.45 UvaUTinw.net
URLﾘﾝｸ(twitter.com)
If you're on the Win11 Insider ring, you're getting the first taste of Rust in the Windows kernel!
URLﾘﾝｸ(pbs.twimg.com)
(deleted an unsolicited ad)
326:デフォルトの名無しさん
23/05/11 11:43:59.84 Ue/TF0sJ.net
win32kbase_rs.sys
win32kfull_rs.sys
って何?
ついでに名前が似た以下のファイルも
win32kbase.sys
win32kfull.sys
327:デフォルトの名無しさん
23/05/11 12:35:35.38 hMF5bhvG.net
URLﾘﾝｸ(japan.zdnet.com)
328:デフォルトの名無しさん
23/05/11 12:57:22.38 h0Ssdxno.net
>>327
C++は何故か年々人気が上がってるね
329:デフォルトの名無しさん
23/05/11 13:16:26.32 a3sWIGIB.net
C++0xの暗黒時代を知らない世代が増えたんだろう
330:デフォルトの名無しさん
23/05/11 14:21:03.16 kyUN9mFL.net
>>317
上澄みだけ使うならライブラリも豊富だし悪くない。
本来なら、c++標準化団体がAccelerated C++みたいなのを用意してメンテナンスすべきだと思うけどなぁ。
331:デフォルトの名無しさん
23/05/11 14:44:20.03 Ue/TF0sJ.net
いらね
332:デフォルトの名無しさん
23/05/11 15:04:29.85 OsVl9AaP.net
デザパタ流行した時ほにゃららパターンのほとんどが理解できなかったけどそのうち理解しなくても何の問題もない事が判った
うんこうんこうんこー
333:デフォルトの名無しさん
23/05/11 15:26:04.23 IKYAIOBH.net
>>332
実務で今使ってるのは、state, proxy, singleton, factoryくらいかな。
あとは使ってないね。
334:デフォルトの名無しさん
23/05/11 16:10:38.63 o+lB6Dgi.net
近年の C + 人気は上の画像でも見ただろ
競技プログラミングだよ
335:デフォルトの名無しさん
23/05/11 16:14:51.13 a3sWIGIB.net
GoFのパターンはiteratorとかadapterも含めてるから多分無意識で使ってるよ
昔のforループはi++で回すのが普通だったし
JavaにIterator（foreach構文）が追加されたのが1.5くらいのはず
336:デフォルトの名無しさん
23/05/11 18:30:22.74 mNkrg+hY.net
懐かしの 何とかの呼吸 ○の型 ほにゃらら！が沢山あるけど
使わないときは使わないと言うだけです
337:デフォルトの名無しさん
23/05/11 18:41:36.44 mNkrg+hY.net
Rustの呼吸 一の型 mut代入！
Rustの呼吸 二の型 シャドーイング！
338:デフォルトの名無しさん
23/05/11 18:56:15.63 gsH464oC.net
それ現行コンテンツちゃうの? (初クール初回から録画だけして観てない
339:デフォルトの名無しさん
23/05/11 19:34:36.36 KOkRWEaK.net
C++コアガイドラインに従い、IDE組み込みのチェッカーを使う
これが一般的なスタイル
これだけであなたの悩みはすべて解決する
340:デフォルトの名無しさん
23/05/11 19:37:24.28 KOkRWEaK.net
CCG！CCG！
341:デフォルトの名無しさん
23/05/12 14:15:57.41 qPE7RwmZ.net
終戦のお知らせ
Rust言語で開発されたカーネルがプレビュー版「Windows 11」に - やじうまの杜 - 窓の杜
URLﾘﾝｸ(forest.watch.impress.co.jp)
342:デフォルトの名無しさん
23/05/12 14:19:03.50 jNwvrlvi.net
解散
343:デフォルトの名無しさん
23/05/12 14:25:26.74 uf2dKGIg.net
カーネルのどのへんで使われてるんだろう
Linuxみたいに周辺部分からかな
344:デフォルトの名無しさん
23/05/12 14:32:56.45 yiIZVwAo.net
>>341
Rustの成果をC/C++に還流させるフェーズ どんどんやってくれ
345:デフォルトの名無しさん
23/05/12 14:44:13.86 GoY4o9UG.net
Microsoft Azure security evolution: Embrace secure multitenancy, Confidential Compute, and Rust
URLﾘﾝｸ(azure.microsoft.com)
Rust as the path forward over C/C++
Decades of vulnerabilities have proven how difficult it is to prevent memory-corrupting bugs when using C/C++. While garbage-collected languages like C# or Java have proven more resilient to these issues, there are scenarios where they cannot be used. For such cases, we’re betting on Rust as the alternative to C/C++. Rust is a modern language designed to compete with the performance C/C++, but with memory safety and thread safety guarantees built into the language. While we are not able to rewrite everything in Rust overnight, we’ve already adopted Rust in some of the most critical components of Azure’s infrastructure. We expect our adoption of Rust to expand substantially over time.
346:デフォルトの名無しさん
23/05/12 14:45:57.07 QUxSeMfx.net
マイクロソフト、Rust言語による開発を含む初めてのWindowsカーネルをInsiderプログラム参加者向けに提供開始
URLﾘﾝｸ(www.publickey1.jp)
デバドラからか
347:デフォルトの名無しさん
23/05/12 15:41:33.52 66ak38wv.net
これを見ると、言語の移り変わり時期が来ると
一気に使われなくなって廃れていくんやな、、
URLﾘﾝｸ(m.youtube.com)
348:デフォルトの名無しさん
23/05/12 16:02:52.10 TaYVXf5t.net
むかしもこんな感じでJ++に騙されたんだよ
349:デフォルトの名無しさん
23/05/12 16:05:02.84 vtQb4m8q.net
コンパイラは何使っているんだろうね?
MSがllvmなんかつかうのかな?
350:デフォルトの名無しさん
23/05/12 16:11:29.41 GsK+e8JY.net
Visual Rust++登場も近いな
351:デフォルトの名無しさん
23/05/12 16:19:18.80 MfrxynDP.net
新しいGC言語がどれだけ出て来ても
C++の天下は揺らがない
もしC++が転落するときが来るとすれば
C++の欠点を解決しつつ同等の性能を出せる新たな非GC言語が登場した時だけだ
352:デフォルトの名無しさん
23/05/12 17:14:53.42 0Z+hsanL.net
trait 内の fn は pub 付けていなくても
trait 自体が pub で定義されていたら
他の trait (というか上の trait を引き継いでいる) からでも参照出来るんだね
353:デフォルトの名無しさん
23/05/12 17:16:09.03 0Z+hsanL.net
Visual R++
Visual R#
しっくりこない
354:デフォルトの名無しさん
23/05/12 17:47:30.22 UYEx77Kz.net
R言語はもう別であるからRustがR++になる心配はない
355:デフォルトの名無しさん
23/05/12 17:50:51.87 BjQIXqEx.net
Visual &mut Rust
356:デフォルトの名無しさん
23/05/12 17:54:33.84 qfqUshnI.net
トリビア: トレイトメソッドに付くVisibilityは構文定義上だけは許されている
357:デフォルトの名無しさん
23/05/12 18:18:31.38 0Z+hsanL.net
トレイト完全に理解した！
ヒャッハーっ！！！
358:デフォルトの名無しさん
23/05/12 18:29:46.57 LzgSZzp6.net
URLﾘﾝｸ(doc.rust-lang.org)
Trait items syntactically allow a Visibility annotation,
but this is rejected when the trait is validated.
359:デフォルトの名無しさん
23/05/12 20:36:17.87 qfqUshnI.net
またひどい知ったかぶりしてる……
ｽﾚﾘﾝｸ(prog板:575番)
575 仕様書無しさん 2023/05/12(金) 15:53:45.02
C++のスマートポインタはRustで吸収され
・RustのCopy実装型 (使われる時は自動コピー)
・RustのCopy非実装型 (使われる時はムーブ) ← C++のunique_ptr
・RustのArc型 (atomic増減でスレッド間も利用可) ← C++のshared_ptr
・RustのRc型 (高速にスレッド内で利用可)
つまりunique_ptrの機能がRustでは標準で備わっている
さらにshared_ptrはArcでその軽量版Rcが追加
C++と異なり使い間違えるとコンパイルエラーで知らせてくれる
さらにRustは参照と可変参照の規則によりデータ競合をコンパイル時に防ぐ
360:デフォルトの名無しさん
23/05/12 22:56:44.22 LzgSZzp6.net
問題なし
361:デフォルトの名無しさん
23/05/12 23:46:30.09 qfqUshnI.net
unique_ptrに対応するのはBoxやろがい
362:デフォルトの名無しさん
23/05/13 02:08:25.96 IwTcnmrR.net
>>361
C++のunique_ptrとRustのBoxは対応しない
Boxはヒープ確保であり例えば以下でのnew int(123)部分にあたる
std::unique_ptr<int> foo(new int(123));
そしてunique_ptr自体にヒープ確保の機能はない
363:デフォルトの名無しさん
23/05/13 04:06:17.18 rghdYpRz.net
>>351
それがrustだろ
364:デフォルトの名無しさん
23/05/13 07:59:34.64 Mq7eAK7K.net
天下ねえ
天下って思われてると、むだに煽られるよねえ
C++サイコーｗｗｗ(大好き)とは思ってるけど
365:デフォルトの名無しさん
23/05/13 10:20:28.21 rDLT/gzF.net
何故プログラミング言語が変わるのか
まずハードが変わる、当然命令セットも変わる、さりとてハードが変わるたんびに新しい言語を覚える、既存のソフト移植する、など不可能なのでここで一個
ソフトサイドで新しい考え方が出てくる、既存の考え方ではバグ出やすい、効率悪い、こう考える方がいいという新しいプログラミングに関する知見が出れば言語そのものの刷新に向かう圧力が出る
ここで一個
大別すればこの2段やろな
①高級言語
━━━
②繋ぎレイヤ
━━━
③アセンブラ
①、③は必然的な刷新圧力に応じてどんどん変わっていく、③は必然的に新しいハードが出るたびに、①は絶対ではないけどBasic, Perl, Java, Ruby, Python などなど概ね5～10年周期で変わってきた
しかし②のレイヤはほぼ半世紀近くC,C++の独壇場, MachとかObjectice Cとかあったけど結局消えていった
さてさてどうなるのか？
Windows, Linuxでは一部Rubyに置き換える試みがなされてるけどコレは本流の大きなにがれになるのか、あるいはやはりごく一時的なものでやはりC,C++の牙城は崩れないのか
366:デフォルトの名無しさん
23/05/13 10:27:54.96 R1hDb7+8.net
>>365
Rustは③だよね？
367:デフォルトの名無しさん
23/05/13 11:14:30.77 qbLWQV0Y.net
たった今あるソリューションがRustだから、切迫した更新需要にはRustが入ると思う
もうちょっとゆとりのあるものは、improved C/C++ でいいかなって感じじゃないかな
自分もその位置
368:デフォルトの名無しさん
23/05/13 12:46:24.99 TFo/sDKR.net
C++は倒れたままなのか？
死亡フラグ
369:デフォルトの名無しさん
23/05/13 12:48:52.48 OKlDpUB8.net
倒れたと言いますと?
370:デフォルトの名無しさん
23/05/13 13:37:03.03 0/cn7SoC.net
>>365
頭悪過ぎ
371:デフォルトの名無しさん
23/05/13 13:52:20.03 IGToM9iL.net
>>362
make_unique知らないの？ 知ってて黙ってる？
それとも知ってたけどunique_ptrに属さないから駄目だって言いたいの？
というかその差異を認めたとしても、スコープを抜けるとき/ムーブされるときに内容の後始末とヒープの解放を行うという重要な共通点が依然としてあるし、
その点を無視してunique_ptr<T>を任意の非Copy型と対応付けようとするほうがよっぽど無理があると思うけどね
372:371
23/05/13 13:54:01.76 IGToM9iL.net
あ、ムーブされるときは違うなすまん
373:デフォルトの名無しさん
23/05/13 18:07:44.55 1P8OgH65.net
lifetime の &'static と
global の static で
同じ名前になってるのはセンス無いな
Rust 界にも static おじさんは息衝いている
374:デフォルトの名無しさん
23/05/13 18:08:15.66 Zeyov0xO.net
なんかメチャクチャ書いたな
NeXT Stepとかはあくまで周辺プログラミング環境がobjective CだっただけでOS本体はMach kernelでそれはCとかでかかれてるから②のレイヤでC,C++に変わるものは四半世紀でてきていない
果たして本当にここにRustが食い込めるのかね、あるいは置き換わるなどということが本当に起こりうるものなのか
375:デフォルトの名無しさん
23/05/13 19:38:25.85 rkpDrS5+.net
>>373
そこはむしろRustの美学というか方針
Rustは予約キーワード類を最小とするために巧妙な使い回しと組み合わせを意図的にしている
376:デフォルトの名無しさん
23/05/13 21:15:21.97 C/HTc2pJ.net
>>371
make_uniqueは複合の合わせ技だから、
unique_ptrのコンストラクタを見た方がよいね
引き数はnewで確保したポインタなどだから、
unique_ptrの構築前に別途ヒープ領域を確保済
一方でBoxの構築時はまだヒープ領域を確保しておらず、Boxがヒープ領域を確保
だから両者は決定的に違うんじゃないかな
さらにunique_ptrは空っぽの状態、つまりヒープ領域を伴わない状態が許されるのに対して、
Boxは必ずヒープ領域を伴っていて、そこに値を必ず持っている、という重要な違いもあるね
スコープを抜けたときの処理や内部で持っているヒープ領域の解放については、
unique_ptrやBox以外でも行われる話だから、両者の共通点というよりもっと大きな範囲の共通点だね
377:デフォルトの名無しさん
23/05/13 21:18:10.27 qbLWQV0Y.net
>>375
騙されないぞ
それじゃC++とおんなじじゃないかｗ
378:デフォルトの名無しさん
23/05/13 21:55:24.10 ps1U4+yC.net
>>373,375
staticはglobalスコープとは関係ない
lifetimeがstaticなだけなのでどっちも同じ意味
美学てｗ
379:デフォルトの名無しさん
23/05/13 22:14:54.43 ps1U4+yC.net
Copy非実装型とBoxとどちらがunique_ptrに近いかと言えば大多数の人はBoxだと言うだろうな
まあ言語が変われば1対1で対応しない機能があるのが普通なので
無理に対応づけようとするよりもそれぞれの違いを学んだほうがいいよ
380:デフォルトの名無しさん
23/05/13 22:22:25.59 IGToM9iL.net
>>376
> さらにunique_ptrは空っぽの状態、つまりヒープ領域を伴わない状態が許されるのに対して、
> Boxは必ずヒープ領域を伴っていて、そこに値を必ず持っている、という重要な違いもあるね
だからBoxとunique_ptrは対応しないってんなら、Arcとshared_ptrを対応させるのはもっと間違ってるぞ
381:デフォルトの名無しさん
23/05/13 22:50:11.88 awcNL8zc.net
Boxはボックス化つまりヒープに置くこと
C++で対応するのはnew
382:デフォルトの名無しさん
23/05/13 22:51:59.52 ps1U4+yC.net
BoxもZero Sized Type(ZST)だとheapを伴わないよね
383:デフォルトの名無しさん
23/05/14 02:32:01.76 WzlwealS.net
>>377
Rustは凄いと言ってる奴は、自分はRust使ってないからな
384:デフォルトの名無しさん
23/05/14 09:24:48.35 20ql+77K.net
Javaが出てきたとき
Javaすげぇぇ他の言語は駆逐される
PHPが出てきたとき
PHPすげぇぇ他の言語は駆逐される
何か出るたびそれを信仰し同じコトを繰り返すんだな
385:デフォルトの名無しさん
23/05/14 09:25:10.34 hi4Bq2pn.net
>>383
使いどころがないからなｗ
386:デフォルトの名無しさん
23/05/14 09:27:43.22 20ql+77K.net
自分で作るじゃなく他所で作られたものを自慢をするというね
こういう言語そうだそれ以外の物でもそうだし
387:デフォルトの名無しさん
23/05/14 09:34:52.10 1jFVCpuN.net
>>384
結局どうなったかっていうと、PHPはサーバサイドのDSLとして落ち着いた
JavaはOracleが接収? した
立ち位置が減少したのは多分Perlだが、いまPerl使ってるって言っても殴る人はいない
(以上、すべて個人の感想)
今回は、LLVMの成熟により、様々な言語が2.0化しようとしてるみたい
わりと何ででも、安全に、高効率なプログラミングができる時代になるのかもしれない
Rustは、新しいbetter C のような気がしてきた
…けど、記述法がどうしても見慣れない(ｗ
388:デフォルトの名無しさん
23/05/14 10:27:30.61 pb1Dbmn7.net
javaはIT企業ではある意味他言語をを駆逐したと思うわ
特殊なケースだけc++、ｖｂ使う
webのDSLでtypescript
地元（田舎）の求人見ると
java,C++が使える人かjs使える人の求人が99%だから…
389:デフォルトの名無しさん
23/05/14 14:29:21.51 ePHWuoFt.net
WindowsのカーネルもRustに移行するのか
390:デフォルトの名無しさん
23/05/14 15:10:39.12 +xFqdUJk.net
これでWindows、Linux、AndroidがRust採用かー
391:デフォルトの名無しさん
23/05/14 19:44:19.16 JeiAQ+ra.net
rubyは使ってると殴られる言語だが
pythonはまだ大丈夫だな
phpやvbは死んでいい
392:デフォルトの名無しさん
23/05/14 19:45:39.76 JeiAQ+ra.net
>>387
記述法が見慣れないのは
キミが関数型をやってないからじゃね
393:デフォルトの名無しさん
23/05/14 20:14:19.79 pJuPP/LG.net
色んな言語やっている中で見比べて
Rustの記述法のほとんどの部分は
複数言語に見られるものかその平均に近い記述
>>387の見慣れない記述法とは何を指すのだろう
394:デフォルトの名無しさん
23/05/14 20:36:25.87 QmAlZPFj.net
🐟::🐟::🐟::
395:デフォルトの名無しさん
23/05/14 20:47:29.76 aUfiFIOV.net
::も<type>もC++と同じだから連続してもそれほど違和感ない
396:デフォルトの名無しさん
23/05/14 20:57:09.57 pb1Dbmn7.net
goの配列の指定はいまだに慣れないと言うかなんじゃこれだけど
rustは&mutとかライフタイムの指定をもっと独自のものにして欲しかった
397:デフォルトの名無しさん
23/05/14 20:59:37.48 oUsSKvxr.net
C++構文定義上の最大の罪である山括弧ジェネリクスを引き継いでしまい
構文の曖昧性を無くすために苦肉の策で生まれたのがあの悲しきお魚ちゃんなのですよ
398:デフォルトの名無しさん
23/05/14 21:00:38.00 QE+keqW6.net
>>392
関数型はマイナーだからな
399:デフォルトの名無しさん
23/05/14 21:02:12.13 QE+keqW6.net
>>397
>C++構文定義上の最大の罪である山括弧ジェネリクスを引き継いでしまい
何が問題なのかな?
400:デフォルトの名無しさん
23/05/14 21:06:28.92 pb1Dbmn7.net
< >は解釈の時若干邪魔なのかとは思うけど
ヒマだからANTLRで構文解析器でも作ってみようか
401:デフォルトの名無しさん
23/05/14 21:08:03.75 pb1Dbmn7.net
ｃはtypedefとかの仕組みがクソ
402:デフォルトの名無しさん
23/05/14 21:30:13.88 QE+keqW6.net
>>401
typedefかっけーやん
#include <iostream>
using namespace std;
struct Hoge {
void hage () const {cout << "hage" << '\n';}
};
int main () {
typedef void (Hoge::*Mage) () const;
Hoge hoge;
Mage mage {&Hoge::hage};
(hoge.*mage) ();
return 0;
}
403:デフォルトの名無しさん
23/05/14 22:05:58.43 RldwXebz.net
何かの言語でvector<vector<int>>の">>"の間にスペースが必要だった記憶があるけど
昔のC++だったかJavaだったか思い出せない
シフト演算子と相性悪いんだよね
どうやって解決したんだろ
404:デフォルトの名無しさん
23/05/14 22:07:54.16 QE+keqW6.net
>>403
昔のC++はそうだったよ
405:デフォルトの名無しさん
23/05/14 22:57:53.83 bfYFgiq9.net
次スレのスレタイはC++ Considered Harmfulにしよう
406:デフォルトの名無しさん
23/05/14 23:23:04.77 pb1Dbmn7.net
>>402
頭が痛くなるからやめて
407:デフォルトの名無しさん
23/05/14 23:23:32.31 QE+keqW6.net
>>402をtypedefなしで書くと逝っとるよな
- Mage mage {&Hoge::hage};
+ void (Hoge::*mage) () const {&Hoge::hage};
何でこんな記法にしたんだろ?
408:デフォルトの名無しさん
23/05/14 23:26:10.97 pb1Dbmn7.net
作った人たちも失敗したと言ってるからな
409:デフォルトの名無しさん
23/05/14 23:29:27.12 bfYFgiq9.net
変数宣言と構文を共有することでパーサの実装量節約に一役買っているのです
410:デフォルトの名無しさん
23/05/14 23:34:59.36 QE+keqW6.net
俺は使える程には理解してるが人にはちょっと説明できん
411:デフォルトの名無しさん
23/05/14 23:35:38.40 QE+keqW6.net
>>408
誰?
412:デフォルトの名無しさん
23/05/15 00:00:45.30 wsaXJZjZ.net
>>411
しばらく検索してみたけどソースが見当たらないので取り消します
413:デフォルトの名無しさん
23/05/15 00:06:48.33 I+wFjT19.net
>>412
お時間使わせてスミマセン
414:デフォルトの名無しさん
23/05/15 09:27:18.72 wFuQ/qib.net
C/C++ は(関数ポインタのときを除いて)
hoge と &hoge と &&hoge と &&...&hoge は明確に区別されるけど
Rust だと区別されずにコンパイル通ってしまうケースもあるんだな
むしろ警告でも良いので出してくれればいいのに
415:デフォルトの名無しさん
23/05/15 09:33:17.96 wFuQ/qib.net
>>399
C++ の <Hoge> 入れ子で
<Hoge<Hoge>> とは書けなくて
<Hoge<Hoge> > と書くとちゃんと動く
だっさーと思った
416:デフォルトの名無しさん
23/05/15 09:37:02.63 wFuQ/qib.net
>>411
ハゲ麦紐じゃなかった？
417:デフォルトの名無しさん
23/05/15 09:38:10.71 DhZrO8d7.net
>>414
型で厳格に区別できるから使い間違えることや問題がおきることはなく
さらにfoo.barとfoo->barを一本化してfoo.barだけにしたRustが便利で合理的かな
418:デフォルトの名無しさん
23/05/15 11:36:55.02 ujHFmMNa.net
>>414
Rustでも区別されてるけど場所によってはDeref Coercionが働くから
区別されてないように見えるというだけ
URLﾘﾝｸ(doc.rust-lang.org)
419:デフォルトの名無しさん
23/05/15 12:27:59.24 GXc9JAaS.net
>>415
いつの話だよ。
C++11以降を知らんのか。
420:デフォルトの名無しさん
23/05/15 12:36:46.16 HovYgrQ4.net
じゃあジェネリクスの記号を何にすればよかったのかの話は無いよね。
代替案が無いなら貶さない方がいいよ
421:デフォルトの名無しさん
23/05/15 12:58:13.92 s5edYhaR.net
Box[T]
Box t
't box
(box t)
422:デフォルトの名無しさん
23/05/15 13:30:47.16 s5edYhaR.net
今さら代替案を出したってもう広まってるから無理だし、本気でこれを変えて「改善」になるなんて思ってる人はいないだろうが
C++の山かっこがC++11で改善されるまで長いことクソクソ言われてたのになぜRustは……ってだけのただの冗談だよ
本気にさせちゃったようですまないね
423:デフォルトの名無しさん
23/05/15 13:45:50.28 I+wFjT19.net
Rustのジェネリックスの記法はこうこうこうだから美しい！マンセー！
って言わなきゃ話が続かないよ
424:デフォルトの名無しさん
23/05/15 13:49:25.75 s5edYhaR.net
URLﾘﾝｸ(www.kmonos.net)
クソクソ言われていた時代にRustと似た動機で作られたD言語はBox!(T)だったんだね
みんないろいろ考えるんだね～
425:デフォルトの名無しさん
23/05/15 14:23:03.39 1m/NLizK.net
> C++構文定義上の最大の罪である山括弧ジェネリクス
> C++の山かっこがC++11で改善されるまで長いことクソクソ言われてた
完全にコイツはエアプ
当時そんなとこに文句言ってるやつ見たこと無い
みんな真顔で「> >」隙間開けてたわ
指がオートマチックでスペース叩いてるはず
仕事やってりゃ色々クソなことはあるが
それを言語に転嫁するようなザコはここにはいないよね？
426:デフォルトの名無しさん
23/05/15 14:37:29.92 8jCFowEK.net
C++11までそんなので頑張ってたんだねw
427:デフォルトの名無しさん
23/05/15 14:44:13.08 HovYgrQ4.net
「もう広まってる」とは言うがRustがわざわざ山かっこ<>をジェネリクス用に選んだ経緯とかはあるのか？
本当に惰性と流れで<>にしたの？
Dみたくa!(b,c)にしなかったのはなんでだ？
やっぱりDのa!(b,c)なる記法は純粋に見映えがダサくて、C++的なa<b,c>なやつはなぜかイケてる、ていうだけのことだろ
428:デフォルトの名無しさん
23/05/15 15:00:31.60 5sS8eRrw.net
()が増えるのは良くない
429:デフォルトの名無しさん
23/05/15 15:09:20.65 s5edYhaR.net
URLﾘﾝｸ(github.com)
URLﾘﾝｸ(github.com)
0.1すら出る前の超初期は角括弧だったんすねえ
430:デフォルトの名無しさん
23/05/15 15:11:35.81 ujHFmMNa.net
URLﾘﾝｸ(soc.me)
ここに書いてあることも一理あるけど
Goのようにsquare bracketでのインデックスアクセスを残したままFoo[T]にするのも微妙
unlimited look-aheadが必要だとしても実際にそんな長く先まで読む必要性なんてないので
読みやすさが勝るのならそれでいいと思う
ターボフィッシュはイケてないけど