結局C++とRustってどっちが良いの？ 3traits

■ このスレッドは過去ログ倉庫に格納されています
2023/05/04(木) 07:49:56.33ID:z+qB+AKQ
「C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」
「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」

っていう雑談スレ。

前スレ: 結局C++とRustってどっちが良いの？ 2traits
https://mevius.5ch.net/test/read.cgi/tech/1680363777/

関連スレ(マ板): Google&MS「バグの70%はC/C++。Rustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/
2023/05/06(土) 03:12:15.76ID:eTXbn+fa
>>101
それはない。
2023/05/06(土) 06:31:50.59ID:BGrqS5mo
C++とRustに比べればJavaは当然遅いしどうでもいい
2023/05/06(土) 06:50:56.78ID:IDnb553v
スタックってそんなでかくない、っていう世界もCの領域なんだよね
そんときの感覚を今でも引きずってる気はする

アプリケーションの起動時に、がつんとデカく確保しちゃえばいいんだろうけどね
なんとなく、ね
105デフォルトの名無しさん
垢版 |
2023/05/06(土) 07:22:20.41ID:cJf94Ar1
>>103
Javaが一番速くて、少し遅れてRust、かなり離されてC++だろ
2023/05/06(土) 07:46:12.61ID:a72ZoZZa
>>95
いわゆるエスケープ解析と呼ばれているテクニックだな
スタックメモリ利用が断トツに速いのでできる限り使うようにする
GoだけでなくJava含めていくつかの言語で行われてるが適用に限界がある
単純には各ポインタのライフタイムが関数内に閉じてればスタックメモリを利用
他の関数に渡した時は確実に追い切れないので難しい
それを可能とするには言語自体がライフタイムをサポートする必要がある
それを実現したのがRustでありライフタイムを完全に追うことができて現在最強
107デフォルトの名無しさん
垢版 |
2023/05/06(土) 09:19:50.79ID:xQ/L7Xyj
RustよりJavaのほうが速くなることも多々あるけど
unsafeやarena使ったりして最適化すればJavaより遅い状況はなくなる

でもJavaもネイティブコンパイルできるようになってるから起動速度含めてシェルスクリプトの代わりに使えるくらいには十分速いよ
2023/05/06(土) 09:27:14.82ID:6sJMiJUH
ほとんどのベンチマークでRustが圧倒的に速い
自分でunsafeする必要なんかない
109デフォルトの名無しさん
垢版 |
2023/05/06(土) 09:28:26.41ID:mjWAg2hj
JavaやGoより明らかに高い性能を得ようと思ったら面倒臭いRust特有の最適化が必要になるから
自分用のツールに速度目的でRustを使うのは生産性的におすすめしない

製品開発やそれに準ずるライブラリ開発であればRustも有り
2023/05/06(土) 09:34:58.48ID:zYAo+dX9
>>109
根拠なくそういうデマはよくないと思うよ
「面倒臭いRust特有の最適化が必要になる」なんて聞いたことも体験したこともない
2023/05/06(土) 09:46:59.89ID:IDnb553v
Javaはないわー
なんだかんだいって、Oracleのドル箱なんでしょ、あそこの法務はなめちゃだめだ＞＜
2023/05/06(土) 11:45:09.13ID:SIOBPdzx
chatGTPのいい加減なときの答えみたいなレスが増えたな

しょうもない細部にこだわって全体を一切見ない
事実を使って嘘を作るようなレス
113デフォルトの名無しさん
垢版 |
2023/05/06(土) 14:05:33.18ID:49fczBUH
複オジの一人妄想エコーチェンバースレだからね
2023/05/06(土) 14:07:36.12ID:O4KUwdol
新しい燃料の投下だよ～

Mojo🔥
https://zenn.dev/helloyuki/scraps/70e4bcdef0bc6f
2023/05/06(土) 15:11:59.44ID:Vkc9/sC/
>>114
> すべてを1つの言語Mojoで書く。
> Pythonを書くか、metalまでスケールダウンします。
> 多数の低レベルのAIハードウェアをプログラムします。
> C++ や CUDA は必要ありません。

挑発的だな
Pythonがベースの拡張で書きにくいことが確定だからどうでもいい
2023/05/06(土) 15:24:45.43ID:IfxSkTCE
Pythonが手になじんでる人には吉報かも
こりゃC++に流れ込んでくる日も近いね
2023/05/06(土) 15:27:19.19ID:Vkc9/sC/
C++を不要にする目標なんだろ
無理だと思うが
2023/05/06(土) 15:39:53.37ID:u7GkjfSc
逆になるべくC++でやって行きたいと思う人も大勢いるということを
分かってない。
2023/05/06(土) 15:53:28.09ID:fVZUtdKL
名前からして ジョークじゃねえの
オースティンパワーズ デラックスで見たぞ これ
120デフォルトの名無しさん
垢版 |
2023/05/06(土) 16:59:42.98ID:QDUY2JyG
喪女？
2023/05/06(土) 17:17:38.48ID:IfxSkTCE
Python使いだけど、全部自力で書きたい…みたいな
GC系言語にどんどん拡がっていくんじゃね
2023/05/06(土) 18:15:47.48ID:52PGn/Mb
>>106のエスケープ解析やライフタイムを本格的にやるのかな
C++を一気に超えてしまいそう
2023/05/06(土) 18:26:46.92ID:SIOBPdzx
少しrustの仕組みを勉強してきた
いろいろと勉強になった

面白いからしったかさんを泳がしておこうｗ
2023/05/06(土) 18:43:25.55ID:0gq0Gmfh
Pythonはインスタンスをヒープに置くことしかしていないが
スタックに置いて高速化するかもしれないのか
2023/05/06(土) 20:28:37.67ID:IfxSkTCE
LLVMとかあのへんに任せるんだろうから、できるようになりだしたらあっという間
2023/05/06(土) 23:34:35.68ID:9Mu3Cg1D
GCの分だけRustの方がJavaよりも早いんじゃないの
一般論だけど
2023/05/06(土) 23:43:00.84ID:8+gQNNXm
GCって予測不能なだけで速いか速くないかとは関係ないのでは?
それよりJavaはプロセッサとの間に入るJavaマシンが律速段階なのでは?
2023/05/07(日) 00:20:35.09ID:zx4D7i6q
一度実行したら コンパイルすりゃいいんじゃね
129デフォルトの名無しさん
垢版 |
2023/05/07(日) 03:11:23.01ID:+pQ1lZnP
RustよりJavaのほうがだいぶ速い
2023/05/07(日) 06:16:47.38ID:7BVdtRv5
ネイティブコンパイルができるとからしいから、だいぶ速くなったんかしらんが
Java派のサイトでいいから資料示してくれ
>>111 のとおりで、触る気にはならん それこそJavaやるんならRustやる
2023/05/07(日) 07:39:12.44ID:UNWBnCPP
多くの人たちが一つの問題を色んな言語を用いて実装することで各言語の実行速度比較例
https://pbs.twimg.com/media/EmYvG8aVkAMdfFG.jpg
AtCoderのABC182-E問題で提出された各プログラミング言語別の実行時間分布
2023/05/07(日) 07:45:16.15ID:ga+9ADYk
c++の実装数の多さよ。

Rustの「実装しようとしてできなかった数」がどれくらいになるのか知りたいところ。
2023/05/07(日) 08:07:01.05ID:IAlaDasW
>>131
Rustは書きやすいから
世間での普及と比較して多数使われてるな
速度もRustとC++は並んで最高速
一般での普及指標も毎年ぐんぐん上昇しているからあとは時間の問題のみか
2023/05/07(日) 10:50:21.49ID:xEkqTcpa
C、C++、Rust の速度に関しては、fact checkが必要。
少なくとも、C や C++ は、高級アセンブラなのだから、最速のはず。
Rustに負ける可能性はゼロ。
2023/05/07(日) 10:52:23.10ID:xEkqTcpa
「C++はRustより遅い」などと言っている人は、C++の標準ライブラリ(STL)
だけを使った場合に限定してしまっている。
C++は、アセンブラで書けることはほぼ何でも書けるし、Rustはそれを越える
ことは不可能なわけで、C++がRustより遅くなると言うのは論理的におかしい。
2023/05/07(日) 10:58:59.25ID:xEkqTcpa
もし、「RustがC++よりどうしても速くなる例」があるとするならば、
Rustのコンパイラは、C言語ではかけない特殊なマシン語を出力できる
ようになっているということである。
しかし、RustのバックエンドはLLVMであり、C/C++ のコンパイラ clang の
バックエンドも LLVM であることから、なぜそのような現象が起きるかは
大いに疑問となる。LLVMはLLVMレベルで最適化を行なうことができるような
コンパイラが存在しているので、C++が吐いたコードを最適化しても、
なぜか、Rustが吐いたコードを最適化したものより遅くなってしまうと言う
ことが起きなければならないことになる。
しかし、C++は、高級アセンブラであり、アセンブラで書けることは特殊命令
以外は基本的に全て書ける。ということは、Rustは、そのような特殊命令を
出力しない限りは、C++に勝つことは不可能と言っても過言ではない。
137デフォルトの名無しさん
垢版 |
2023/05/07(日) 11:00:30.38ID:+pQ1lZnP
いや、>>131 を見る限り、平均するとC++はPythonにすら負けてる
2023/05/07(日) 11:01:52.13ID:ms6+oRxa
誰かがスタックメモリを使ってるからrustが早いと言ってるけどllvmレベルでは差がない
吐き出した中間コードみてもそんな特徴は特になかった
139デフォルトの名無しさん
垢版 |
2023/05/07(日) 11:04:44.26ID:+pQ1lZnP
いや、>>131 を見る限り、平均するとRustは最速
2023/05/07(日) 11:06:24.77ID:xEkqTcpa
>>136
アセンブラに詳しくない人のために捕捉しておくと、特殊なマシン語の
例外(仲間はずれ)を除けば
「C言語の演算子は、アセンブラ(マシン語)の 1命令に一対一対応している」
とほぼ言える。なので、基本的に、マシン語を1命令ずつ書いていくのと
同じレベルでC言語はプログラム可能である。それに当てはまらないのは
CPUに依存したような「独特なマシン語」が存在している場合に限られる。
そして、コンピュータは、最終的には全てマシン語に置き換えられて実行され、
マシン語しか理解できない。
そして、C++は、C言語の演算子や機能は全て包含している。
ということは、C++は、特殊命令以外のマシン語を全て1命令ずつ記述できる、
ということである。
マシン語しか理解できないCPUに対して、C++は、あらゆる順序のマシン語を
ほぼ人間が思った通りの順序で書こうと思えば書けるのであるから、どうして、
C++が最速に成らないのだとしたら、非常に特殊な事態が起きていることになる。
その特殊な自体は、人間の手作業による最適化であると考えられている。
2023/05/07(日) 11:07:48.80ID:xEkqTcpa
>>139
平均と言うが、C++は、Rustのsafeモードを越えられる。
逆に、Rustはsafeモードだけを使っていると、C++に絶対に勝てない状況が
存在すると何度も指摘されている。
2023/05/07(日) 11:09:29.23ID:ms6+oRxa
>>139
それを見てもptyhon最速の人とC#最速の人が何をしたのかが気になるだけ
2023/05/07(日) 11:12:16.15ID:xEkqTcpa
>>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命令になるときが有る。
これが、「ほぼ」の意味である。
2023/05/07(日) 11:14:47.99ID:ms6+oRxa
llvmは仮想レジスタマシーンである
2023/05/07(日) 11:15:59.86ID:xEkqTcpa
>>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命令程度になってしまうことはある。
2023/05/07(日) 11:17:50.86ID:xEkqTcpa
>>145
なお、Rustは、C言語よりさらに少し粒度が大きいことが多い。
C++は、C言語を包含するので、書こうと思えば、C言語と同じ粒度で書ける。
2023/05/07(日) 11:19:00.29ID:ms6+oRxa
ながながとつまらないことを書いてるな

最適化でsimdを自動で使ってくれるベースがあればそっちが勝つわ
2023/05/07(日) 11:20:09.23ID:xEkqTcpa
>>146
[補足]
誤解なきように行っておくと、Rustも、= や、+= のような演算子の粒度は、
C言語と基本的に同じことが多いので、その部分に関しての両者に優劣の
差は無い。だから、RustはC/C++と同じ程度の速度が出ることがある。
2023/05/07(日) 11:21:33.84ID:xEkqTcpa
>>147
基本を知らない人が誤解する可能性があるので書く必要があった。
C/C++がアセンブラ以外に負ける可能性はほぼ無いと言うことの
根拠を示した。
2023/05/07(日) 11:23:54.31ID:ms6+oRxa
コンパイラは高速化では中間言語化が有効なケースが多い
llvmの最適化はそれで行われてる
rustは二種類の中間言語に変換されてバイトコードを出す

でも中間言語に寄らないヒューリスティックな最適化も存在してる
そちらは泥臭く研究が進められてそちらは今llvmより速いコードを吐き出している
2023/05/07(日) 11:25:01.81ID:xEkqTcpa
「ほぼ」の意味が、よく誤解されているから、混乱が起きているようなのだ。
「ほぼ」というのは、>>143 や >>145 の意味においてである。
決して、曖昧な意味で言っているわけではない。
2023/05/07(日) 11:27:12.27ID:xEkqTcpa
>>150
それでも、C/C++は、そのRust独自の最適化後のコードを手作業で書くことが
できるから、Rustに負ける可能性が「ほぼ」ない。
ここで、「ほぼ」の意味は、>>143 や >>145 の意味である。
2023/05/07(日) 11:28:14.31ID:ms6+oRxa
エスケープ解析はjava一時期重点的に研究されて実装に取り込まれている
誰か天才的な人間が開発に来たんだろう

golangも後追いでエスケープ解析入れてるけどエスケープ解析をオンにすると速度が落ちるケースが多いらしい
開発者が愚鈍なのか想定ケースを外れてるのか不明
2023/05/07(日) 11:29:33.02ID:xEkqTcpa
マシン語とは、mov,add,sub,mul,imul,div,idiv,cmp,jnz,jb, jbe, ja, jae,call,ret
の組み合わせでプログラムする方式である。
それは、C/C++ 言語で「ほぼ」一対一対応でかけてしまう。
なので、Rustがそれを越えることは「ほぼ」不可能。
「ほぼ」の意味は、>>143 や >>145 の意味。
2023/05/07(日) 11:34:06.34ID:xEkqTcpa
>>154
マシン語プログラミングとは、
mov,add,sub,mul,imul,div,idiv,cmp,jnz,jb, jbe, ja, jae,call,ret
のような20個ほどの命令を組み合わせて書く書き方。
ところが、C言語では、少し粒度が大きくなってしまうが、それらの20個の
命令に対応する命令が存在している。つまり、C言語では、マシン語の
1〜3命令の単位で命令を書くことが出来る。マシン語の1命令にならない
ケースは、レジスタが足りなくて本質的に1命令で書けない場合。
2023/05/07(日) 11:35:48.42ID:ms6+oRxa
エスケープ解析が有効なシーンにあっても速度向上はわずか1%～2%ぐらいのレベルなので
誤差と言えば誤差
2023/05/07(日) 11:37:17.94ID:zo7jDOyY
>>154
時代に取り残されてるな
まず大昔にレジスタ最大限活用最適化により1対1は崩れてる
さらにパイプライン最適化によって手書きアセンブリが敗北するようになってのがだいぶ昔の話
並行してキャッシュ最大限活用最適化によりスタック利用有利がさらに強まったり
2023/05/07(日) 11:38:19.17ID:xEkqTcpa
>>157
そんなことない。
2023/05/07(日) 11:40:38.01ID:ms6+oRxa
お互いに自分の強いと思う必殺技を叫んで殴り合ってる状態だな
映画館に行かずにこんなところで聖闘士星矢が見られるとは…
2023/05/07(日) 11:46:33.50ID:g30pVgXT
今は究極のパイプライン最適化により
生成された機械語と元のプログラミング言語は実行順序すら異なる
だから連投してるアホ>>155の書き込みは読む必要なし
memory orderingとかすら知らない低レベル
2023/05/07(日) 11:46:55.96ID:xEkqTcpa
いくらRustが独自の最適化しても、その最適化と同じことを
C++では書こうと思えば書けてしまうのだから、C++が負ける可能性
はない可能性がとても高いと言うこと。
2023/05/07(日) 11:48:22.26ID:xEkqTcpa
>>160
そのレベルの最適化は、コンパイラの最後の段階であるところのLLVMレベル
で行なわれるから、Rustとclangで差が出ることは無い。
出るとしたら、LLVM最適化がたまたまその時には上手く最適化できなかっただけ。
2023/05/07(日) 11:49:35.05ID:xEkqTcpa
>>162
厳密に言うと、「LLVMレベル」ではなく、それより
さらにマシン語に近いところのレベルの最適化。
164デフォルトの名無しさん
垢版 |
2023/05/07(日) 11:54:20.57ID:0dpKtdVy
まあ一番差が出るのは浮動小数ユニットの扱いだけどね。
2023/05/07(日) 11:57:59.97ID:sE0vXw4X
>>162
同じLLVMを用いていても
C++よりRustが速くなった例はいくつか知られていて
それはRustの参照排他ルールによりLLVMに渡すことができる制御情報オプションが増えることで
LLVMによる最適化がRustの場合のみ生じることが原因のようです
つまりRustの言語仕様がC++より速くなるケースを生み出しています
2023/05/07(日) 12:20:49.96ID:ms6+oRxa
どんどん互いにいい技術をパクリあって向上したらいいだけだろ
今後AIによるコード研究が進むだろうし技術的境目はどんどんあいまいになってく

過疎板でお互いにペガサス流星拳を打ち合う必要もなくなる
2023/05/07(日) 12:44:26.77ID:IEKfrntf
>>131
そもそもこのグラフが、何を測定したかの説明も無い。
事実である根拠も無い。
Rustだけ優秀な人がプログラムし、C++では、スクリプト言語上がりの
CPUやマシン語の基礎が分かってない人がプログラムしたのかもしれない。
それに、Rustは、必ず世界最強クラスの最適化バックエンドLLVMを使っている
のに対し、C++用のコンパイラは最適化がほとんど行なわれないような簡易
コンパイラも含まれる。
2023/05/07(日) 12:45:57.83ID:7BVdtRv5
ていうか、シンプルにしか書けない(のが利点の)Rustに負けるC++の書きようが悪いって話
きれいに書こうなｗ
2023/05/07(日) 12:47:17.14ID:IEKfrntf
>>131
「実行時間」というが、PICやAKI-H8、ラズパイPICO、安物Androidデバイス
と、Core i9 とでは全然違ってくる。
Rustは、32BIT 以上専用なのに対し、C++ は、8MHz(?) の 16BIT の
PIC マイコンでも使えるのだから、比較にならない。
C++は、安い低速CPUでも動くが、Rustは高級で豪華な CPU でしか動かない
ということだ。それがグラフに現れているだけだろう。
2023/05/07(日) 12:49:59.71ID:IEKfrntf
>>165
>それはRustの参照排他ルールによりLLVMに渡すことができる制御情報オプションが増えることで
>LLVMによる最適化がRustの場合のみ生じることが原因のようです
>つまりRustの言語仕様がC++より速くなるケースを生み出しています
その場合、C++でも、同じ「参照排他ルール」に従ってプログラムすれば、
LLVMは同じように最適化できるだろう。
2023/05/07(日) 12:52:04.21ID:ms6+oRxa
>>167
>>169
atcoderは競技プログラムのプラットフォームで参加者がコード書いて提出
コンパイルも向こうでされてるので統一した環境ではあるかなとｗ
2023/05/07(日) 12:56:54.33ID:IEKfrntf
>>171
だったら、外国では、C++には、レベルの低い人も参加したのに対して、
Rustはレベルの高い人だけが参加した可能性が高い。
2023/05/07(日) 13:02:09.04ID:ms6+oRxa
atcoderは日本のサイトだよ
出題は英語で去れ店の？

rustは答えを出せる人間が少なく
低レベルコーダーが足切りされてる可能性が高い
2023/05/07(日) 13:03:09.17ID:IEKfrntf
>>172
もう一つの可能性は、C++は歴史が長いから、古いCPUで測定された時の
実行時間が記録に残っているのに対し、Rustは、新しいCPUで測定された
記録しか存在して無いという不公平があるのかもしれない。
2023/05/07(日) 13:04:40.62ID:IEKfrntf
>>173
つまり、
「Rustは初心者向けではない」
「Rustは優秀な人が試している段階」
ということを示しているのかもしれない。
2023/05/07(日) 13:05:35.59ID:ms6+oRxa
おじいさんは自分の見たいものしか見ず考えもしない
2023/05/07(日) 13:10:50.09ID:IEKfrntf
Rust信者は木を見て森を見ず。
2023/05/07(日) 13:11:54.80ID:tSA2wRyk
>>170
参照排他ルールに従うプログラミングをするだけでは最適化されません
言語コンパイラがLLVMへその指示を出さないとLLVMは最適化しないし出来ません

例えばLLVMのnoalias最適化指示の場合
Rustではプログラマーは何も指定しなくても言語仕様によりRustコンパイラが自動的にLLVMへ自動的に指示を出します
C言語の場合はrestrict修飾子が導入されているためプログラマーが自己責任で修飾すればCコンパイラがその指示を出すことが可能です
C++は言語仕様にないためプログラマーは指示できません (言語仕様を独自拡張しているコンパイラのみ可能)

以上のようにプログラマーが何も指示せずともLLVMで最適化が行われるRustが有利な現状です
2023/05/07(日) 13:13:52.93ID:IEKfrntf
>>178
それは初めて知りました。
このスレで初めてまともな意見です。
2023/05/07(日) 13:15:46.72ID:TRA1GHWk
C++の方が自由度が高いのだから遅く書くことを妨げない
一方でRustの自由度は低い
書いた人のレベルが如実に現れたってだけでは?
実際に最速は変わらない
Cの最速が遅いのはサンプルが少なかったから?
2023/05/07(日) 13:16:13.51ID:ms6+oRxa
でたらめを書く前によく見ろよ
グラフにatcode abc 182 e と書かれてるからその問題見て見たらいいだろ

abc = AtCoder Beginner Contest
2020-11-08(日) 21:00 ~ 2020-11-08(日) 22:40 (100分)
問題はAからFまであり後ろに行くほど難易度が高い

E問題を見ると再帰も使わないただのループ問題だからrustの有利なシーンはないと思う
制限時間があるからそこまでの問題で事実上足切りされた人が多いんだろ
2023/05/07(日) 13:20:05.33ID:IEKfrntf
そもそも、atcoder なんて知りませんから。
2023/05/07(日) 13:21:58.46ID:ms6+oRxa
通常通り書くとやはりpythonとかは遅くなると思う

速い回答出せた人もいると言うことは技術的に枝狩りできるシーンがあるんだろうな

atcoder知らない＝おじいちゃん
2023/05/07(日) 13:22:50.40ID:IEKfrntf
C++でやった人は、単に個人の遊びとしてやっていただけなのに対し、
Rustでやった人は、Rustの力をこのスレで自慢するために最高の品質
のコードを書いた「バイアス」があった可能性を除外できない。
185デフォルトの名無しさん
垢版 |
2023/05/07(日) 13:23:13.45ID:TuWfUTcM
atcoderで性能比較www
2023/05/07(日) 13:23:38.22ID:IEKfrntf
atcoderなんてやってるほど暇人じゃないから。
187デフォルトの名無しさん
垢版 |
2023/05/07(日) 13:24:50.84ID:vTHLWOBH
なんで1問だけで比べるのか
データ公開されてるよね？
2023/05/07(日) 13:24:56.80ID:ms6+oRxa
それでこのスレでペガサス流星拳を撃ってるとｗ

その前におじいちゃんはe問題解けるのかなあ？
2023/05/07(日) 13:28:05.72ID:IEKfrntf
なにがペガサス流星拳なんだか、幼稚な。
2023/05/07(日) 13:30:01.06ID:ms6+oRxa
pythonでギリギリ問題解けるようなレベルの人間がc++やrustに移行できるとは思えない
c++やrustという言語で足切りされてる

でも今後はプログラマー不足が顕著になるのでpythonの利用が促進されると思うわ
2023/05/07(日) 13:33:41.26ID:IEKfrntf
そもそも、「実験しなければ分からない」というのは物理や数学、コンピュータの
世界ではウソ。理論があるし、人間には想像力があるんだから、思考実験で
済む場合が多い。但し、アホな人は除く必要がある。
2023/05/07(日) 13:34:36.79ID:ms6+oRxa
プログラムの最適化に詳しくてもプログラム自体出来ないなら本当に存在意義が不明なんだよな
○○が早いと言う人より目的時間内にコードを完成させる人が求められている
アセンブラが捨てられて高級言語が使われてる
生産性の向上が一番の問題

○○速くてスゲーと言うのは意味がない
知識があれば小学生にでも言える
2023/05/07(日) 13:39:28.20ID:mYeAuY/K
>>190
そこで不足している簡単なレベルかつPythonでできるようなことならば
類似サンプルも多数ネット上に転がっているせいでChatGPTが答えられる
だから従来は人員不足とされたその分野の人材は不要となった
C++/Rustで書かれる分野は少なくとも現状のAIは対応できない
特にインフラをAIが吐くコードに依存するのはリスクが高すぎるため人間の最後の砦として需要が残るだろう
2023/05/07(日) 13:42:06.90ID:ms6+oRxa
小学生に○○流星拳と言う言葉を教える

何かあればそれを叫ばせるこれがこのスレで起こってる全てです
2023/05/07(日) 14:20:21.84ID:7BVdtRv5
AtCoderの良問は良問だぞ 俺は全然だけど
あんなもん要らねえｗｗｗとうそぶきつつ、こそっとやっとくと賢くなる
2023/05/07(日) 14:44:33.78ID:DlXJa/i8
>>172みたいに自分に都合の良い想定を平気で行う人間は
どういう大学出てるんだろうな
「可能性が高い」なんて学部生のレポートレベルでも書かないわ
そのへんのリテラシーなくクソレス書き散らしてるの恥ずかしくないのか
2023/05/07(日) 15:02:41.71ID:gnxG91Nb
大見得切ってる割に単発で書いてる時点でな
2023/05/07(日) 15:11:30.83ID:zx4D7i6q
競技プログラミングってC++でやるもんでしょ
集まってくるやつのレベルもピンキリだよ
2023/05/07(日) 15:16:11.45ID:nivMpMsP
>>131の各プログラミング言語の実行速度比較は実行環境が統一されてる点で信頼度が非常に高いと思う
さらに多数の人たちがコードを書いているためコードのせいで遅くなったりする要因も排除できてる
たまにあるベンチマーク比較でコードが下手なせいで言語によって左右されてるのも見かけるため
2023/05/07(日) 15:29:50.80ID:ms6+oRxa
自分は触れたくないがpythonって存在は面白い
c++やrustには移れないのにpythonならできるって人が多い

今後c++やrustの研究が進んで実行速度が1%上がるとかそんなレベル
乾いたぞうきんを絞ってる
それだったらpythonをjava並みに引き上げるほうが社会的意義があると思う

pythonの有名ライブラリはc++で書かれてチューンされて実行速度は速い
個人が各部分のコードが遅くてもライブラリが速いならこれで十分
でもそれがc++ユーザーに反映されて利用が進んでいるとは言えない
一般の研究で利用はpythonに軸足が移ってる
今後も進むだろうし
2023/05/07(日) 15:33:01.77ID:zx4D7i6q
いや、どうみてもPython（PyPy3）書いてるやつらはヘタだな
C++のやつらと同じ程度の頭脳なら言語そのものの早さはともかく分布の形状が同じにならないとおかしい
Pythonだとベストのアルゴリズムを選べないんだろうか？

2500msまで行ってるのはC++しか無いがおそらくはタイムオーバーで失敗したやつもいる
この課題をクリアできたやつの統計だな
クリアできなかった人数もやっぱりC++とPythonが多いと思われる
単に利用者が多いからな
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況