Qiita 3 - キータぞ、来たぞ、キータだぞー

**デフォルトの名無しさん** · 2023/05/28(日) 09:56:01.47

Hello hackers !
Qiitaは、エンジニアリングに関する知識を記録・共有するためのサービスです。
コードを書いていて気づいたことや、自分がハマったあの仕様について、
他のエンジニアと知見を共有しましょう ;)

https://qiita.com/

Qiita（キータ）は、Incrementsが運営するプログラミング情報のナレッジコミュニティ。
2016年現在で日本最大のプログラマーコミュニティとされている[1]。

https://internet.watch.impress.co.jp/docs/news/1025972.html

前スレ Qiita
https://mevius.5ch.net/test/read.cgi/tech/1542357242/
Qiita 2 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1658762410/

**デフォルトの名無しさん** · 2023/08/11(金) 08:34:14.26

>>277
暗号解読の趣味はない
そもそも１レス内で完結してるの？
暗号みたいなレスだから他のレスは全く読まない

**デフォルトの名無しさん** · 2023/08/11(金) 08:59:40.37

発狂してる俺様のレスを追いかけて全部読めとかいう頭のバグったやつ

**デフォルトの名無しさん** · 2023/08/11(金) 09:03:31.51

本人が気づいてない可能性があるからボランティアで教えてあげている
君の文章では他の人間は全く理解できないと
そもそも自分と他人を区別できてるのかなｗ

**デフォルトの名無しさん** · 2023/08/11(金) 09:09:23.31

Cの人のレスは複数に分かれて訂正もあって二つの比較がわかりにくいけど
Rustの人のレス>>272はdiff形式で一つのレスに書かれているから何と何を比較しているか一目瞭然でしょ

**デフォルトの名無しさん** · 2023/08/11(金) 09:26:13.77

RustとRubyとMAUIをNGしてるやつは多いと思う

**デフォルトの名無しさん** · 2023/08/11(金) 09:34:13.85

単語NG設定してるやつがそいつだけ重要なレスを読めていないことが原因で勘違いな書き込みを繰り返すパターンはよくあるよな
しかし今回のアホな>>276はNGしていないからレスしてるわけで単なるアホなパターンかと

**デフォルトの名無しさん** · 2023/08/11(金) 15:23:23.45

void hoge(int n, int num[n], int deleteNum)
{
　　for (int i = 0; i < n; i++) {
　　　　if (num[i] == deleteNum) {　// deleteNumで指定した要素を0にする
　　　　　　num[i] = 0;
　　　　}
　　}
}

void piyo(int n, int num[n], int deleteNum)
{
　　for (int i = 0; i < n; i++) {
　　　　num[i] -= deleteNum * (deleteNum == num[i]);　　// deleteNumで指定した要素を消す
　　}
}

void hogera(int n, int num[n], int deleteNum)
{
　　for (int i = 0; i < n; i++) {
　　　　num[i] *= deleteNum != num[i];　// deleteNumで指定した要素を消す
　　}
}

↑を

**デフォルトの名無しさん** · 2023/08/11(金) 15:24:31.74

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

void __attribute__((noinline)) bench(const char* name, void (*func)(int, int[], int))
{
　　const int n = 100000000;
　　int* a = calloc(n, sizeof(int));
　　if (a) {
　　　　for (int i = 0; i < n; i++) {
　　　　　　a[i] = rand() % 2;
　　　　}
　　　　clock_t s = clock();
　　　　func(n, a, 0);
　　　　double t = (double)(clock() - s) / CLOCKS_PER_SEC;
　　　　printf("%s:\t%f\n", name, t);
　　　　free(a);
　　}
}

int main(void)
{
　　bench("hoge", hoge);
　　bench("piyo", piyo);
　　bench("hogera", hogera);
}

↑で測定した。

**デフォルトの名無しさん** · 2023/08/11(金) 15:29:01.99

gcc 12.2.0に-O2を指定
hoge: 0.279982
piyo: 0.059988
hogera: 0.051996
https://wandbox.org/permlink/cLGAj1OcfqmjdJeZ

clang 15.0.7に-O2を指定
hoge: 0.283996
piyo: 0.036019
hogera: 0.028001
https://wandbox.org/permlink/jEA3G3XMSKeCUKbZ

clang 15.0.7に-O2 -march=nativeを指定
hoge: 0.028001
piyo: 0.028001
hogera: 0.027980
https://wandbox.org/permlink/cMJSCT2nnvyhpSpD

**デフォルトの名無しさん** · 2023/08/11(金) 15:40:51.42

gccとclangの両方で最適化指示に-O2だけを指定した場合にhogeの結果が極端に悪いのは
・条件分岐命令が生成されている
・配列の内容をrand()で生成しているため分岐予測が外れまくる
ことが原因と思われる。

clangに-O2 -march=nativeを指定した場合にhogeの結果が他と変わらなくなったのは恐らくはAVX命令が使用され条件分岐がなくなったため。
試しに-O2 -mavx2を指定しても
hoge: 0.028001
piyo: 0.028002
hogera: 0.028002
https://wandbox.org/permlink/XqiQgGEs1BZJmpmp

変わらない結果となった。

**デフォルトの名無しさん** · 2023/08/11(金) 15:42:39.23

別スレ立ててそこでやって
リンク貼っていいから

Qiitaと関係なくてスレチだし
元の記事はQiitaから削除されて存在しない
１つのテーマを掘り下げる目的がありそうだし
長くなりそう

**デフォルトの名無しさん** · 2023/08/11(金) 22:03:23.82

>>286
if文を使うと10倍遅くなるのが衝撃的だ
今後はif文を無くせる場合は無くそうと思う
if文の中で代入してるだけならコンパイラが頑張ってcmoveを使って分岐を避けてくれればいいのにね

**デフォルトの名無しさん** · 2023/08/12(土) 02:16:01.85

「なんでそんな書き方するの？」
「こっちのが速いから」
「へー、どれくらい？」
「100万回実行して数msかな」
「でもここ数回しか実行されないよ？」

**デフォルトの名無しさん** · 2023/08/12(土) 10:23:43.34

長々と空気読めないこと喋るやつおるよな

**デフォルトの名無しさん** · 2023/08/12(土) 10:28:09.42

>>289
if文を無くせる場合はどんな場合がある？
ifがあるなら無くせないんじゃないの？
その場合を見つけたとしてこのスレで発表する？
それともこのスレを出典にする？
このスレにリンクを貼らないとif文を使うと10倍遅くなることを証明できないから

**デフォルトの名無しさん** · 2023/08/12(土) 12:27:02.41

常にこんな書き方をするべきとかではなくてスループットを上げたい場合に考えられる手段の一つ、くらいの話だと思うんだが顔真っ赤にして否定してる奴なんなの

**デフォルトの名無しさん** · 2023/08/12(土) 13:09:09.17

処理系やプロセッサ依存のソースを書く時代は終わったんだよ顔真っ赤なおじいちゃん
何度も言われてるようにここじゃなくQiitaに記事書きなよw

**デフォルトの名無しさん** · 2023/08/12(土) 13:13:42.09

> 処理系やプロセッサ依存のソースを書く時代は終わったんだよ

組み込みとか念頭にない人は世の中が単純に見えて幸せそうですね。

**デフォルトの名無しさん** · 2023/08/12(土) 14:21:39.40

組み込みの現場も知らない癖に何をイキッてるんだ無職くんはw
いいから記事を書きなよ
そしたらここで話題にしてもいいからさ
スレ違いってわかる？

**デフォルトの名無しさん** · 2023/08/12(土) 16:29:25.06

https://qiita.com/kazukichi/items/281a86a1d53117b2a583
金持ち喧嘩せず

**デフォルトの名無しさん** · 2023/08/12(土) 16:53:18.46

>>292
if文を無くせる場合があるというのが>>253の記事
そしてif文を無くした方が10倍速くなる場合を示してくれたのが>>286の測定

何がトレードオフになっているかというと
if文があるとCPUは条件分岐によるパイプラインの乱れのペナルティを喰らう
if文がないとCPUは条件に関わらず同じ命令群を実行する (＝条件の片方では無意味なことをする可能性がある)

したがってif文を無くせる場合はまず大雑把に言うとif文の(条件部ではなく)実行部がある程度短く実行サイクルも短いこと
例えば軽い数値の演算やその代入などならばif文を無くせる場合に合致することが多いだろう

**デフォルトの名無しさん** · 2023/08/12(土) 16:55:33.58

プロセッサに依存していいならどう最適化されるか決まってないCよりアセンブラ使う方が確実だぞ

**デフォルトの名無しさん** · 2023/08/12(土) 17:42:26.72

終わった記事に関してウダウダと
そんなんだからいつまで経っても独り身なんだぞ

**デフォルトの名無しさん** · 2023/08/12(土) 17:51:13.60

>>299
CMOV命令はintelにもamdにもあるから一般的な環境でプロセッサ依存ではないですよね
もしCMOVがない特殊な環境でも条件フラグをレジスタに入れる命令があればそれが使われて大丈夫ですね

gccとclangどちらでも速くなったようだからコンパイラ処理系依存のテクニックではなさそう
C言語だけでなくRustでも同じ生成コードとなったから言語に依存したテクニックでもなさそう

**デフォルトの名無しさん** · 2023/08/12(土) 18:39:13.58

>>298
> if文を無くせる場合があるというのが253の記事
記事にあるif文を無くせる場合はこれ１つだけ
if (num==1) { num=0 } else { num=1 }
↓
num = !(bool)num
他の読者のために書いてあげる
機会が非常に少なくて残念!!
レスの後半部分は間違ってる

**デフォルトの名無しさん** · 2023/08/12(土) 18:45:47.87

if文の高速化が検索したら
ifとswitchで迷ったらswitchを使う
IF K=6 THEN X=X+1→X=X-(K=6)
が出てきてif文の高速化は有名な話だったようだ
補足訂正

**デフォルトの名無しさん** · 2023/08/12(土) 19:08:27.81

>>302
プログラムも読めないのか
そんなバカが必死に否定してたのか
記事以外にもこのスレで他のコード例やコンパイラによるその生成アセンブラも出ている
さらにベンチマーク比較で大きく速度向上まで結果が出ている
この状況で必死に否定し続けるのはみっともないぜ

**デフォルトの名無しさん** · 2023/08/12(土) 22:28:25.82

>>301
組み込みの意味がわからない人？w

**デフォルトの名無しさん** · 2023/08/12(土) 23:03:51.71

記事読んでも組み込みなんて限定はないな
必死に否定してるバカが勝手に組み込みの話と思い込んでいるのか

**デフォルトの名無しさん** · 2023/08/13(日) 00:15:07.75

なんでそんなに必死なのか知らんけどここまで言われても記事を書こうとしないのは自分が間違ってることを薄々でもわかってるんだろ？w
無理すんな無職

**デフォルトの名無しさん** · 2023/08/13(日) 01:15:32.46

>>307
if文を無くす高速化の話は昔から有名かつ実用なので記事なんていくらでもあるよ
自分で検索してごらん

**デフォルトの名無しさん** · 2023/08/13(日) 10:23:41.63

> 記事を書こうとしないのは

日本の技術力の底上げのために
検索結果の健全化のために

クソ記事書くのはもうやめてクレメンス
お願いですから書くのやめてクレメンス
書かないことでみんなが助かる
書かないことでみんなが嬉しい

わかってクレメンス

クソ記事書いてはいけないと
正常な人間ははじめから知っているんです

**デフォルトの名無しさん** · 2023/08/13(日) 10:23:43.05

逃げたw

**デフォルトの名無しさん** · 2023/08/13(日) 12:06:02.55

クソ記事は批判して良いと思うが
クソ記事に対する批判がみんなのためになるのなら賛成
ただ暇でやってるだけならもうちょっと時間を有効に使えと言いたい

**デフォルトの名無しさん** · 2023/08/13(日) 13:52:34.26

if文をなくすのが高速化に繋がってると解釈してる人がいるようなので補足。

>>286の投稿でhogeの結果が極端に悪いのは条件分岐命令が生成されていることが原因だが条件分岐命令が生成されているのはif文を使用しているからではない。条件によってメモリへの書き込みが行われたり行われなかったりするロジックのためである。
試しにhoge()の実装を
void hoge(int n, int num[n], int deleteNum)
{
　　for (int i = 0; i < n; i++) {
　　　　int x = num[i];
　　　　if (x == deleteNum) {　// deleteNumで指定した要素を0にする
　　　　　　x = 0;
　　　　}
　　　　num[i] = x;
　　}
}
内容が変わろうが変わるまいが常にメモリへの書き込みが行われるよう変更したらどうなるか。

**デフォルトの名無しさん** · 2023/08/13(日) 13:57:12.40

gcc 12.2.0に-O2を指定
hoge: 0.044001
piyo: 0.060001
hogera: 0.052001
https://wandbox.org/permlink/Na7RxYGEttdpuCnR

clang 15.0.7に-O2を指定
hoge: 0.032001
piyo: 0.032002
hogera: 0.031992
https://wandbox.org/permlink/1FZCQD2WsnbvifWw

hoge()の実行時間はpiyo()やhogera()と大差なくなる。
if文の使用がhoge()が遅かった原因ではない。

**デフォルトの名無しさん** · 2023/08/13(日) 14:09:26.02

Qiitaアカウント持ってないからここでウダウダコメントするしかない雑魚w

**デフォルトの名無しさん** · 2023/08/13(日) 14:28:13.37

https://qiita.com/f0lst/items/616eb2915fffacc1cefe
自分でもキモいとわかっていながらなぜこんなキャラで発信してしまうのか
いいねは組織票かな？

**デフォルトの名無しさん** · 2023/08/13(日) 14:59:12.83

> Qiitaアカウント持ってない

つまりそれは
正常な思考力を持ってるってこと

**デフォルトの名無しさん** · 2023/08/13(日) 16:34:36.74

Qiitaに日記を書くんじゃない

**デフォルトの名無しさん** · 2023/08/13(日) 16:43:33.83

IT技術と関係ない記事、不愉快
https://qiita.com/rana_kualu/items/55bd3f13cf98d54a4ae0
https://qiita.com/kaizen_nagoya/items/a735e751cf398996590b

**デフォルトの名無しさん** · 2023/08/13(日) 16:56:52.28

> 不愉快

彼らに不愉快という概念はないぞ
クソを食い
クソを出し
周囲をクソまみれにしても
そのとき
むしろ笑顔だから

**デフォルトの名無しさん** · 2023/08/14(月) 05:02:03.98

>>315
以前「キモッ」だけのコメントをQiitaでしたことあるが、運営から「削除しろ。しなければ垢バンまである」というメールがきたw

**デフォルトの名無しさん** · 2023/08/14(月) 10:45:24.67

>>320
草

**デフォルトの名無しさん** · 2023/08/14(月) 10:59:15.20

>>321
草で済まない
ここでも言うべきでない
開示請求して制裁するように日本社会が変化
法律上は不特定多数に言うのがアウト
ここの発言は必然的に不特定多数
どうしても言いたいなら少数の友人だけに言えばいい

**デフォルトの名無しさん** · 2023/08/14(月) 11:55:14.49

>>322
>>297の記事のコメント欄を見てから言ってもらおうか
運営からメールが来るのは運営に不都合なことを書いた人だけだよ
キモッとコメントするような記事を書いたのが関係者だったというだけ

**デフォルトの名無しさん** · 2023/08/14(月) 14:52:20.96

> 運営からメールが来るのは運営に不都合なことを書いた人だけだよ

運営に不都合関係なくユーザーからの報告がある程度以上あると運営からコメントを直せってメールくるよ。
若年者や女性が書いたという体(てい)の記事に絶賛のコメントが多数付いてるところに水差すようなコメント書いて運営からメール貰ったこと何回かあるわ。
運営に自分の投稿したコメントのどこが問題なのか尋ねても「多数の苦情が来てるのだからお前のコメントが悪い」と埒が明かぬ。運営が苦情の数を気にして機械的に対応してることは確かだと思われる。

**デフォルトの名無しさん** · 2023/08/15(火) 16:44:03.65

>>324
苦情の数だと思ってるところが素直というか騙されやすいというか
そんなんお前だから届いたんだぞ
ゆめみ社員のコメントならどんだけ苦情が届こうがガン無視だ

**デフォルトの名無しさん** · 2023/08/15(火) 17:06:16.32

>>325と>>323は同一人物？
騙されやすいことを批判してるが騙されやすいのはおまえだろとつっこみたい
「ゆめみ社員のコメントならどんだけ苦情が届こうがガン無視」も「キモッとコメントするような記事を書いたのが関係者だったというだけ」も陰謀論だから
陰謀論を言うことが騙されてる

**デフォルトの名無しさん** · 2023/08/15(火) 18:05:42.32

「なんで、for文ってforなの？」って、みんな思ったはず。
https://qiita.com/jin237/items/444688df1b6bfad3bd75
> 皆さまのありがたいお声の数々
> 叩かれ放題の記事となっております（笑）
> はてなブックマーク
> https://b.hatena.ne.jp/entry/s/qiita.com/jin237/items/444688df1b6bfad3bd75
> twitterでの記事の検索結果
> https://twitter.com/search?q=https%3A%2F%2Fqiita.com%2Fjin237%2Fitems%2F444688df1b6bfad3bd75

https://twitter.com/jin2372/status/1691061293107859457
> ・釣りタイトルにする。
> ・正解も不正解もある内容にする。
> ・叩き放題でマウント取れるものにする。
> ・文を下手にしてみる。
> ・タグの中で見られやすいものを選ぶ。
> ・別の場所にスレを作る。
> ・見られやすいトレンドにとりあえず載せる。
> 結果：プチ炎上できた。
https://twitter.com/5chan_nel (5ch newer account)

**デフォルトの名無しさん** · 2023/08/15(火) 18:38:37.81

苦情の数の話はその人の体験談で話が具体的で信じられる
創作の可能性もあるがそこまで疑わないぞ
運営にメールで尋ねたなどの体験談はwelcomeで書いてほしい
welcomeなレスに騙されやすいなどとくだらない批判をいれるべきでない
何を言いたいかと言うと話の構造が根本的に違うだろと

**デフォルトの名無しさん** · 2023/08/15(火) 18:46:26.63

>>327
ツイッターに名前とか自己紹介が書いてある
30で起業するらしい
炎上商法
何かでかいことをやりそうで期待しかないｗ

**デフォルトの名無しさん** · 2023/08/15(火) 18:47:04.69

>>326
自分で苦情入れてみりゃすぐわかること
大きなorganizationのクソコメントはどれだけクソでも削除されることはない

**デフォルトの名無しさん** · 2023/08/15(火) 19:07:59.33

>>330
おまえはずれてるんだよ
おまえが正しいと思う内容を世間一般が正しくないと思う

**デフォルトの名無しさん** · 2023/08/15(火) 19:09:41.51

と思いたいんだなw
だからやってみればわかると言ってるのにw

https://qiita.com/youwht
こいつが組織票でトレンドに載ってることをバラした記事があったのでこいつを通報したら逆にその記事が消えたのをどう説明するんだよw

**デフォルトの名無しさん** · 2023/08/15(火) 19:27:20.24

>>332
youwhtで前スレ１から３を検索したが１つもレスがない
話すまでもないというのがQiitaスレの共通認識
説明しようにも何を言ってるのかわからん
陰謀論って早く忘れたほうがいい
いつまでも引きずるのが精神衛生上良くない
起きたときにスレに投稿すべきだった

**デフォルトの名無しさん** · 2023/08/16(水) 08:17:39.47

>>333
他の記事やコメント含めてそれだけ徹底的に消されたってことだよw
一時期話題になってたから知ってるやつに聞けよ
こいつの組織票はえげつなかったぞ
なにせqiitaを読みもしないまるで関係ない職場の人間に大量にアカウント作らせて記事をアップすると同時にそいつらに一斉送信していいねさせてたことを自白してたからな
そのいいねの付き方があまりに不自然すぎることに気づいたやつが計測して記事にしたところ数日して削除されて今は痕跡も残ってない
こんな話はその辺にゴロゴロしてるが何せこんなふうに証拠隠滅してるからな

**デフォルトの名無しさん** · 2023/08/16(水) 08:19:13.27

あとスレに関してはこのスレのできる前の出来事だから話題になってないのは当然だ

**デフォルトの名無しさん** · 2023/08/16(水) 08:26:56.16

https://www.google.com/search?q=youwht%20site%3Amegalodon.jp

魚拓にyouwhtが無いのも不思議だろ？
あれだけ人気記事書いて本も書いて人気ソフト作ってテレビにも出演してるのに一切アーカイブされてないんだぜ？
そんなことあり得ると思う？
答えは一つ
消したんだよ

**デフォルトの名無しさん** · 2023/08/16(水) 18:44:29.95

> 魚拓にyouwhtが無いのも不思議だろ？

別に不思議はないなあ。

> あれだけ人気記事書いて本も書いて人気ソフト作ってテレビにも出演してるのに一切アーカイブされてないんだぜ？
> そんなことあり得ると思う？

魚拓取られるのってやらかした奴の証拠保全が目的だからなあ、人気記事たくさん書いてる人気者なら問題行動起こす可能性も低そうだし魚拓取られる機会もそうそうないんじゃないの。つか

> 答えは一つ
> 消したんだよ

妄想乙ｗ

**デフォルトの名無しさん** · 2023/08/16(水) 18:55:47.22

> こいつが組織票でトレンドに載ってることをバラした記事があったのでこいつを通報したら逆にその記事が消えたのをどう説明するんだよw

妄想記事が消された以外の解釈あるかな?
つかどこの誰が書いたか正しいかもわからん記事が「あった」というだけで通報って大分イカれてるぞ

**デフォルトの名無しさん** · 2023/08/16(水) 18:56:47.72

そんなに発狂するなよw
正体がバレるぞw

**デフォルトの名無しさん** · 2023/08/16(水) 19:04:30.78

> 正体がバレるぞw

妄想持ちならではのセリフｗ

**デフォルトの名無しさん** · 2023/08/17(木) 09:06:45.29

妄想ブーメランで火消しに必死になってるのは本人なんだろうなあ

**デフォルトの名無しさん** · 2023/08/17(木) 09:27:37.89

いつでも本人がいると思うのは都合が良すぎる
病気なんだろうなあ
精神病棟で隔離されてそう

**デフォルトの名無しさん** · 2023/08/17(木) 09:30:01.29

このスレ３人しかいない

**デフォルトの名無しさん** · 2023/08/17(木) 13:58:17.84

まあこれだけ発狂してたらそりゃ本人かくらい言われるだろ
みんな知ってる事件なんだし

**デフォルトの名無しさん** · 2023/08/17(木) 13:59:32.09

精神病棟とか3人とか妄想がきっついな
こういうのって大概自分が言われなれてることを言うんだよな

**デフォルトの名無しさん** · 2023/08/18(金) 20:22:10.84

　　　　　ｶﾀｶﾀ
　　||￣ Λ＿Λ
　　||＿（Д`；　）　「なに？このスレ・・・」
　　＼⊂´　　　）
　　　　（　　┳'

**デフォルトの名無しさん** · 2023/08/19(土) 09:59:43.77

qiitaのスレということがわかってないやつが病棟から常駐してるな
自説の主張を話題にしたいなら記事書けと何度も言われてるのに

**デフォルトの名無しさん** · 2023/08/23(水) 21:43:18.69

ナイーブな再帰フィボナッチでマイクロベンチマーク
https://qiita.com/Nabetani/items/19ea2d3f8c18d862497f
> もともと
> https://qiita.com/fsdg-adachi_h/items/5feeda2ed19f879fdf9a
> という URL で公開されていた記事に
> > int の長さが処理系によって違うので公平じゃないかもしれません。
> > それと
> > > ネイティブコンパイルの優位性
> > とありますが、Go が Java に負けてますね。
> > int の長さの影響かもしれません。
> というコメントを書いたら、その記事は削除されて。
> 同じ方が、全く同じような内容で
> C++ はどれくらい速いのか？：フィボナッチ数列の演算で比較してみる - Qiita
> https://qiita.com/fsdg-adachi_h/items/c54135cf0a562019295c
> という記事を公開されて。
> なぜか私はコメントできない（ブロックされてるのかな）ようなので、コメントで書きたかった追加情報に関する記事を書こうと思った。

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

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

C++ はどれくらい速いのか？：フィボナッチ数列の演算で比較してみる
https://qiita.com/fsdg-adachi_h/items/74764a835be31c1e73c6

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

**デフォルトの名無しさん** · 2023/08/23(水) 23:22:56.21

>>348
その最後の記事
CとRustで速さ約2倍は明らかにおかしいので
手元で実行してみたらCとRustは同じ速さとなった

CとRustのこの種のベンチマークで2倍差となったのを見たことがない
少なくとも今回のような類いのコードならば同じ速さとなっている
今回よほど何か特殊な環境下で実行計測しているのか
あるいは記事が間違っているのか

**デフォルトの名無しさん** · 2023/08/23(水) 23:47:17.93

間違ってない
(非線形)再帰に関してはgcc/g++の最適化が進んでいる

**デフォルトの名無しさん** · 2023/08/23(水) 23:50:22.47

GOに関してもtinygoを使えばLLVMの速度がでると思われる

**デフォルトの名無しさん** · 2023/08/23(水) 23:59:13.29

実名だけでなく会社名も晒してるけど問題ないのか？
誰もレビューしてないのかしら

**デフォルトの名無しさん** · 2023/08/23(水) 23:59:14.64

>>350
やってみた
その指摘は正しいようだ
ただしこちらも正しいという結果になった

速さの結果
Rust ＝ C (gcc) ＞ C (clang)

これによりRustがLLVMに渡す前にその最適化しているっぽいな

**デフォルトの名無しさん** · 2023/08/24(木) 00:23:12.72

>>353
Rust=C(gcc)は再現しない
gcc 13.2.0
rustc 1.71.1

gcc -o fibonacci_c fibonacci.c -O2
time ./fibonacci_c
Result: 701408733
Time: 0.00069 seconds <-- time関数が別物(1/1000)
real 0m0.774s <--コマンド実時間

clang -o fibonacci_clang fibonacci.c -O2
time ./fibonacci_clang
Result: 701408733
Time: 0.00157 seconds
real 0m1.592s

rustc -C opt-level=2 -o fibonacci_rs fibonacci.rs
time ./fibonacci_rs
Result: 701408733
Time: 1.55644 seconds
real 0m1.641s

**デフォルトの名無しさん** · 2023/08/24(木) 00:39:14.97

GOROOT=... tinygo build -opt=2 -o fibonacci_tinygo
time ./fibonacci_tinygo
Result: 701408733
Time: 1.55111 seconds
real 0m1.626s

LLVM(Clang/Rust/tinygo)=1.55s
GCC=0.7s
以上

**デフォルトの名無しさん** · 2023/08/24(木) 04:19:18.96

>>353
(室温超伝導)サンプルの提出をお願いします

>>350,354
スルーか一言で済ませて、余計な知恵を付けさすな

**デフォルトの名無しさん** · 2023/08/24(木) 08:31:12.59

こちらでも Rust(rustc)=C(gcc)>>>C(clang) となった
gccとrustcが同じ最適化をしてると思われる
確認のためLLVM IRを吐くrustcとclangでどのようにコードが異なるか調べてみた

まずclangによるLLVM IR生成
$ clang -S -emit-llvm -O2 -o fibonacci_cl.ll fibonacci.c
そのうちfibonacci()関数部分を抜粋すると以下のコードとなった

; Function Attrs: nounwind readnone uwtable
define dso_local i32 @fibonacci(i32 %0) local_unnamed_addr #0 {
　%2 = icmp ult i32 %0, 2
　br i1 %2, label %9, label %3

3: ; preds = %1
　%4 = add nsw i32 %0, -2
　%5 = tail call i32 @fibonacci(i32 %4)
　%6 = add nsw i32 %0, -1
　%7 = tail call i32 @fibonacci(i32 %6)
　%8 = add nsw i32 %7, %5
　ret i32 %8

9: ; preds = %1
　ret i32 %0
}

元のCコードそのままでnが2未満すなわち0と1の時はそのまま返して
それ以外は fibonacci(n-2) + fibonacci(n-1) を返している
最適化をしていないのでclangがgccよりも遅いのはこれで納得

**デフォルトの名無しさん** · 2023/08/24(木) 08:33:36.30

次にrustcによるLLVM IR生成
$ rustc -C opt-level=2 --emit llvm-ir -o fibonacci_rs.ll fibonacci.rs
そのうちfibonacci()関数部分を抜粋すると以下のコードとなった

; fibonacci::fibonacci
; Function Attrs: nofree nosync nounwind nonlazybind memory(none) uwtable
define internal fastcc noundef i32 @_ZN9fibonacci9fibonacci17h1af4b62ef57b502cE(i32 noundef %n) unnamed_addr #4 {
start:
　%switch1 = icmp ult i32 %n, 2
　br i1 %switch1, label %bb8, label %bb5

bb5: ; preds = %start, %bb5
　%n.tr3 = phi i32 [ %_7, %bb5 ], [ %n, %start ]
　%accumulator.tr2 = phi i32 [ %0, %bb5 ], [ 0, %start ]
　%_5 = add i32 %n.tr3, -2
; call fibonacci::fibonacci
　%_4 = tail call fastcc noundef i32 @_ZN9fibonacci9fibonacci17h1af4b62ef57b502cE(i32 noundef %_5)
　%_7 = add i32 %n.tr3, -1
　%0 = add i32 %_4, %accumulator.tr2
　%switch = icmp ult i32 %_7, 2
　br i1 %switch, label %bb8, label %bb5

bb8: ; preds = %bb5, %start
　%accumulator.tr.lcssa = phi i32 [ 0, %start ], [ %0, %bb5 ]
　%n.tr.lcssa = phi i32 [ %n, %start ], [ 1, %bb5 ]
　%accumulator.ret.tr = add i32 %n.tr.lcssa, %accumulator.tr.lcssa
　ret i32 %accumulator.ret.tr
}

clangの場合>>357とは異なり「call」によるfibonacci()呼び出しが一つとなり最適化されている

**デフォルトの名無しさん** · 2023/08/24(木) 08:41:31.44

ちなみに>>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)の両者が最も速い」

**デフォルトの名無しさん** · 2023/08/24(木) 13:00:39.60

で、それぞれの実行時間は?
うちでは clangもrustcも>>358相当の.llを吐くけど実行したらgccより激遅い

**デフォルトの名無しさん** · 2023/08/24(木) 13:10:33.06

https://godbolt.org/z/96ePGvT76
これがgccより激遅い

**デフォルトの名無しさん** · 2023/08/24(木) 13:17:53.54

あぁ、この人か? スルーしよ
https://mevius.5ch.net/test/read.cgi/tech/1690610746/759

**デフォルトの名無しさん** · 2023/08/24(木) 22:58:58.23

俺のところではこうなった

>>348の記事の再帰呼び出し2つのfibonacci.rsとfibonacci.c
$ rustc -C opt-level=2 -o fibonacci_rs fibonacci.rs ; ./fibonacci_rs
Time: 1.90858 seconds
$ gcc -o fibonacci_gcc fibonacci.c -O2 ; ./fibonacci_gcc
Time: 1.90691 seconds
$ clang -o fibonacci_clang fibonacci.c -O2; ./fibonacci_clang
Time: 3.16011 seconds

>>359の再帰呼び出し1つと片方ループ化のfibonacci_opt.rsとfibonacci_opt.c
$ rustc -C opt-level=2 -o fibonacci_opt_rs fibonacci_opt.rs ; ./fibonacci_opt_rs
Time: 1.94240 seconds
$ gcc -o fibonacci_opt_gcc fibonacci_opt.c -O2 ; ./fibonacci_opt_gcc
Time: 1.92169 seconds
$ clang -o fibonacci_opt_clang fibonacci_opt.c -O2 ; ./fibonacci_opt_clang
Time: 1.94741 seconds

ループ化した最適化コードをLLVMに渡さないclangだけが遅い

**デフォルトの名無しさん** · 2023/08/25(金) 06:29:41.57

>>363
バージョン上げて全部やり直しだ

**デフォルトの名無しさん** · 2023/08/25(金) 18:02:25.77

なんかバブルソートで同じような記事最近見たぞ
node.jsはインタプリタじゃなくてjitだろと突っ込まれてたがこっちでもインタプリタになってんな

**デフォルトの名無しさん** · 2023/08/25(金) 18:06:50.53

https://qiita.com/fsdg-adachi_h/items/9d91e53d6ff4e5753b05
同じやつだった

**デフォルトの名無しさん** · 2023/08/25(金) 20:01:49.79

gcc のバージョン10以前か以降かで生成されるコードが全然違う。
https://godbolt.org/z/93sxnq9xP

gcc 9.3.0 -O2
https://wandbox.org/permlink/PWLc6EFfecavDZ0m
> Time: 1.58398 seconds

gcc 10.2.0 -O2
https://wandbox.org/permlink/9OYZBH14tYooZHF7
> Time: 0.89583 seconds

**デフォルトの名無しさん** · 2023/08/26(土) 12:00:16.58

Nim 2.0.0 速すぎ

https://wandbox.org/permlink/WoYP0STRKxaRBGCY
>Time= 0.240s Result=701408733
>Time= 0.238s Result=701408733
>Time= 0.238s Result=701408733
>Time= 0.238s Result=701408733
>Time= 0.241s Result=701408733

**デフォルトの名無しさん** · 2023/08/26(土) 12:08:31.17

nim.cfgファイルでwanboxのgcc 12.2.0を指定
gcc.path%="/opt/wandbox/gcc-12.2.0/bin"

**デフォルトの名無しさん** · 2023/08/26(土) 12:11:38.14

ローカルマシンではもっと速い
$ ./fibonacci_nim_gcc 44
Time= 0.182s Result=701408733
Time= 0.186s Result=701408733
Time= 0.188s Result=701408733
Time= 0.184s Result=701408733
Time= 0.184s Result=701408733

**デフォルトの名無しさん** · 2023/08/26(土) 12:19:34.15

--cc:clangだとLLVM速度(ローカルマシン)

$ ./fibonacci_nim_clang 44
Time= 1.620s Result=701408733
Time= 1.628s Result=701408733
Time= 1.630s Result=701408733
Time= 1.674s Result=701408733
Time= 1.647s Result=701408733

Nimのトランスパイルとgccの最適化が相性が良いのかな

**デフォルトの名無しさん** · 2023/08/26(土) 18:41:17.51

C(gcc)よりNimが3倍も速いのか
計測方法に問題があるんしゃないか？

**デフォルトの名無しさん** · 2023/08/26(土) 21:58:15.99

室温超伝導サ〇wって言われない様に真っ先にwandboxに提出したんだわ

あとclangでもNimが多少速かった(朝方とはLTOの有無が違う)

Nim 2.0.0 + clang 16.0.5
$ nim c --cc:clang --verbosity:0 -d:release -d:danger -o:fibonacci_nim_clang -u:lto fibonacci.nim
$ time ./fibonacci_nim_clang 44
Time= 1.43200s Result=701408733
Time= 1.42200s Result=701408733
Time= 1.44100s Result=701408733
Time= 1.43800s Result=701408733
Time= 1.43900s Result=701408733
real 0m7.250s

Nim 2.0.0 + clang 15.0.7
https://wandbox.org/permlink/quetpnT592ONdM2x
>Time= 1.48272s Result=701408733

生clang 15.0.7
https://wandbox.org/permlink/U97PecZYrzymnfH4
>Time=1.58712s Result=701408733

生clang 16.0.1はstack frame limitエラー?
https://wandbox.org/permlink/TXPiXPLUJ8WX3kTK

生clang HEAD(18.0.0)
https://wandbox.org/permlink/caGw8uqCS8tW0fnt
>Time=1.57598s Result=701408733

**デフォルトの名無しさん** · 2023/08/26(土) 22:00:21.79

こっちもtimeコマンド付きで

Nim 2.0.0 + gcc 13.2.0
$ nim c --cc:gcc --verbosity:0 -d:release -d:danger -o:fibonacci_nim_gcc -u:lto fibonacci.nim
$ time ./fibonacci_nim_gcc 44
Time= 0.18500s Result=701408733
Time= 0.19200s Result=701408733
Time= 0.18400s Result=701408733
Time= 0.18400s Result=701408733
Time= 0.18600s Result=701408733
real 0m1.005s

これこそQiitaの面々に検証してもらいたい

**デフォルトの名無しさん** · 2023/08/26(土) 22:10:21.63

ループ1回にして試したらスタートアップタイムが多少大きめ(~70ms)なのが見えるけど
fibonacci関数自体は複数ループ版と整合的で、同一引数複数ループ版で何か省略している訳でもなさそう

$ time ./fibonacci_nim_gcc 44
Time= 0.18100s Result=701408733
real 0m0.252s

$ time ./fibonacci_nim_clang 44
Time= 1.43300s Result=701408733
real 0m1.505s

**デフォルトの名無しさん** · 2023/08/26(土) 22:12:34.92

クソ課題にクソ計測方法をまだやっているのか
NimがCより何倍も速くなったのもクソなせいだと気付かないのは愚なことだ

この課題でこの継続方法なら極論すれば0秒にできる
例えばC++ならば

constexpr int TERM = 44;
constexpr int fibonacci(int n) {
　if (n == 0 || n == 1) {
　　return n;
　} else {
　　return fibonacci(n - 2) + fibonacci(n - 1);
　}
}

結果
Result: 701408733
Time: 0.00000 seconds

もちろん言語によって最適化や事前計算の仕様は異なる
C++はconstexpr指定が必要だが指定不要な言語もあるだろう

**デフォルトの名無しさん** · 2023/08/26(土) 22:15:58.64

44は定数にせずにコマンドライン引数にしのよ