64(1): デフォルトの名無しさん [sage] 2023/06/14(水) 23:03:53.15 ID:GFS/QI0w(1) AAS
>>61
C++でint main()は反対する理由がない

348(2): デフォルトの名無しさん [sage] 2023/08/23(水) 21:43:18.69 ID:xWiJzaGi(1) AAS
ナイーブな再帰フィボナッチでマイクロベンチマーク
外部ﾘﾝｸ:qiita.com
> もともと
> 外部ﾘﾝｸ:qiita.com
> という URL で公開されていた記事に
> > int の長さが処理系によって違うので公平じゃないかもしれません。
> > それと
> > > ネイティブコンパイルの優位性
> > とありますが、Go が Java に負けてますね。
> > int の長さの影響かもしれません。
> というコメントを書いたら、その記事は削除されて。
> 同じ方が、全く同じような内容で
> C++ はどれくらい速いのか？：フィボナッチ数列の演算で比較してみる - Qiita
> 外部ﾘﾝｸ:qiita.com
> という記事を公開されて。
> なぜか私はコメントできない（ブロックされてるのかな）ようなので、コメントで書きたかった追加情報に関する記事を書こうと思った。

まとめると、
・コメントしたらブロックされた
・コメントされたことをなかったことにしたいのか元記事は削除、同じ内容で再投稿

で、
> C++ はどれくらい速いのか？：フィボナッチ数列の演算で比較してみる - Qiita
> 外部ﾘﾝｸ:qiita.com
見に行ったらこっちも既に削除済みｗ 誰かコメントしたんだろうなｗ
新記事が↓らしい。

C++ はどれくらい速いのか？：フィボナッチ数列の演算で比較してみる
外部ﾘﾝｸ:qiita.com

どうでもいい内容の記事だったけど、タイトルのC++はg++じゃね? 言語じゃなくて処理系の話してるよね? くらいは誰でも言いそうになると思う罠。

359(1): デフォルトの名無しさん [sage] 2023/08/24(木) 08:41:31.44 ID:jcLl4hPI(3/3) AAS
ちなみに>>358のRustコンパイラが吐いたLLVM IRのコードを
見やすくC言語に翻訳するとこういうコードになっている
(このコードはLLVM自体による最適化をする前であることに注意)

int fibonacci(int n) {
　if (n < 2) {
　　return n;
　}
　int f = 0;
　while (1) {
　　f += fibonacci(n - 2);
　　n = n - 1;
　　if (n < 2) {
　　　return f + 1;
　　}
　}
}

これはgccが吐いたアセンブラコードと同じ構造であり
rustcとgccは同様の最適化をしていることがわかる

したがって実測結果の Rust(rustc)=C(gcc)>>>C(clang) が生成コードによっても裏付けられた
結論「同様の最適化をしているRustとC(gcc)の両者が最も速い」

597(4): デフォルトの名無しさん [sage] 2023/12/04(月) 02:08:38.29 ID:uA82POL4(1/3) AAS
#include <stdio.h>
#include <math.h>

#define PI 3.141592653589793238462643383279

int main(void)
{
　　double r = PI / 6;
　　printf("sin(%.16f) = %.16f\n", r, sin(r));
　　r = asin(0.5);
　　printf("sin(%.16f) = %.16f\n", r, sin(r));
}

外部ﾘﾝｸ:wandbox.org
sin(0.5235987755982988) = 0.4999999999999999
sin(0.5235987755982989) = 0.5000000000000000

ラジアン派はこーゆーの気になんないの？

744(2): デフォルトの名無しさん [sage] 2023/12/14(木) 07:29:56.59 ID:y0v8WBQQ(1/6) AAS
10万のプロセス作ったとしてもCPUが10万無いなら結局同時処理できないわけで意味ないんじゃね
あとプロセス作る負荷と切り替えの負荷は結構重い
PCで使う限り大量のプロセス作っても速くなるどころか逆に遅くなると思うんだがほんとに速さが売りになるのか？