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/07/24(月) 15:07:41.98

シャコタンは文化だから理解しない人もいるかもね

**デフォルトの名無しさん** · 2023/07/24(月) 15:39:05.61

ま、ユーザーがロードカーの車高を下げても良いことは何もないんだけどね
カッコいいと感じる感性の持ち主の部族のことは知らん

**デフォルトの名無しさん** · 2023/07/24(月) 21:51:54.02

2つの封筒問題（封筒のパラドックス）
https://qiita.com/SaitoTsutomu/items/3079a88163153abf2ac2

数学っぽいこと書いてる雰囲気なデタラメ記事。

> ※ 本記事へのコメントはしないでください。コメントがあった場合、すべて削除依頼します。

書いた本人にも自覚はあるんだろうな。

**デフォルトの名無しさん** · 2023/07/25(火) 05:43:25.14

>>223
2つの封筒問題（金額仮定版）の答えが「分からない」が真だとして、
なんで2つの封筒問題（未開封版）の答えが「変わらない」なのかが分からない。

金額仮定版は2つの事象が1/2で発生するか分からないから、という説明なのに対し
未開封版は2つの事象が1/2で発生することを前提にしているの？

**デフォルトの名無しさん** · 2023/07/25(火) 06:41:00.76

数学っぽいとかなんで2つの封筒問題（未開封版）の答えが「変わらない」なのかが分からないとか
記事を開く気がしない

**デフォルトの名無しさん** · 2023/07/25(火) 06:42:02.53

なんで人はわからないものや数学っぽいものに惹かれるのか

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

わからないものはわからない

**デフォルトの名無しさん** · 2023/07/26(水) 21:41:05.02

【検証してみた】株式会社ゆめみは、Organization対抗戦で不正をしているのか？
https://qiita.com/Yametaro/items/3988455d103d2408ea77

組織票は現状ルール違反ではないことを前提として書いてるんだろうけど
トレンドが全く役に立たなくなったし迷惑行為であることは認識して欲しいもんだわ。

**デフォルトの名無しさん** · 2023/07/26(水) 21:47:14.30

いやいやそもそも御本尊のキー太がね
検索結果のど真ん中に野糞置く教えだから

**デフォルトの名無しさん** · 2023/07/26(水) 21:47:30.02

詳しく読んでないけど、ベイズ推定にそんな説明あったね

**デフォルトの名無しさん** · 2023/07/27(木) 09:48:07.83

>>223
無茶苦茶だな
これ本気で書いてんのか？

**デフォルトの名無しさん** · 2023/07/27(木) 09:51:23.51

>>228
オーガニゼーション組織票問題はユーザーからは前から言われてることだけど運営は全く問題にしてないしむしろ推奨してるからな
トレンドが糞記事ばかりになるのは当然

**デフォルトの名無しさん** · 2023/07/27(木) 11:58:29.93

QiitaはSEOに強かったからネットユーザーに認知されて参加するも
いいねが付かないことに悩み
オーガニゼーション（組織票）の存在に気づくのは１年以上後だろう
気づいたら参加モチベーションが下がる
不公平だからな
ほとんどのネットユーザーに認知され新規参加者がいなくなり組織に属さない人のモチベーションが下がったままで
全く上げようとしないのは問題かな
今後も組織参加者を増やすのかな

**デフォルトの名無しさん** · 2023/07/27(木) 12:25:26.22

スクール系組織票も野放し？

**デフォルトの名無しさん** · 2023/07/27(木) 17:43:34.41

ゆめみでゴミ記事書くやつは、片っ端からミュートしてるわ

**デフォルトの名無しさん** · 2023/07/28(金) 10:49:42.57

>>233
advent calendar ってなんなん？

**デフォルトの名無しさん** · 2023/07/28(金) 12:20:44.76

>>205
今読んだけどこれほんま草

**デフォルトの名無しさん** · 2023/08/03(木) 08:01:34.37

な

**デフォルトの名無しさん** · 2023/08/03(木) 19:59:51.90

CとC++って低水準言語なの？
https://qiita.com/takeyoshinitta/items/a646a80f170e31a8c075

Cは低水準言語であるという与太話を広めたい人の記事。
自分はそうは思わないと断りを入れつつ自説に都合の良い記事探してきて
主張するモチベーションはどこから来るのだろう？

**デフォルトの名無しさん** · 2023/08/03(木) 20:28:59.91

インラインアセンブラが可能なC/C++/Rustは低水準記述が可能な言語

**デフォルトの名無しさん** · 2023/08/03(木) 21:01:12.75

>>239
「犬が人を噛んでもニュースにならないが、人が犬を噛んだらニュースになる」が基本
Cは低水準言語でないという論文なら論文にならないが、Cは低水準言語であるという論文なら論文になる
Cは低水準言語でないというだけなら主張するモチベーションが起きないが、Cは低水準言語であるというなら主張するモチベーションが起きる

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

んちゃ

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

そもそも低水準は誤訳
低レイヤと考える方がしっくりくる

**デフォルトの名無しさん** · 2023/08/04(金) 21:08:44.67

>>239
消えてるが

**デフォルトの名無しさん** · 2023/08/04(金) 22:33:31.82

https://megalodon.jp/2023-0804-1704-11/https://qiita.com:443/takeyoshinitta/items/a646a80f170e31a8c075
> 私としてはこのムーブメントが拡大されCが段々と当たり前のように低水準として
> 扱われていることついて例をいくつか紹介し将来的にどうなるのかを含め議論を
> したいと思って投稿したつもりでCが低水準か高水準についてしっかりと議論
> したかったわけではないのですが、このような投稿は初めてでしたので、うまく
> 伝えることができなかったのだと反省しております。
> 私の投稿に対しての誤解を閲覧者が生んでしまうのは申し訳ないのですが、急に
> 投稿を削除してしまうのもこれまでコメントされた方に失礼だと思いますので、
> しばらく時間をおいてから本日中に投稿は削除させていただきます。

うまく伝わらなかったのなら議論重ねりゃいいだけだし削除する言い訳にもなってない罠。
要は旗色悪いから逃げたんだろう。

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

消えてるからなんだよ
webアーカイブでも探せばいいだろ

**デフォルトの名無しさん** · 2023/08/04(金) 22:38:44.38

しっかしコメントしてきた相手に対して長いコメント返してるなあ、例外なく。
負けん気の強さは人一倍だが本人の知識や能力が追い付いてない感じｗ

**デフォルトの名無しさん** · 2023/08/05(土) 07:04:06.19

このスレに貼り付けた人もそうだが削除させる意図があるように見える
削除させなくてもいいんじゃない？
もしかしたら削除させる意図がないと言うかもしれないが
もしそうなら言い方を気をつけるべきだね
削除させる意図があるように見えるから

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

>>248
「削除させる意図があるように見える」のはどの書き込みで
「削除させる意図があるように見える」ことがなくなるようにするには
その書き込みをどのように変えればいいと言うんだろ

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

>>246
Zuishinいいこと言うなー

**デフォルトの名無しさん** · 2023/08/05(土) 10:09:31.04

削除は本人の判断だけど

> それにしてもCが低水準言語であると思っている人の数が圧倒的に多くそのような記事が当たり前のようにあるので驚いたところです。

とまで書いてた本人が記事を削除する意図が分からんのよね。

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

低水準の意味を間違って捉えてるんだろ
ハッカーと同じ

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

C言語における「bool型へのキャスト」が無限の（悪用）可能性を秘めている理由
https://webcache.googleusercontent.com/search?q=cache:ED5C8TAFrNYJ:https://qiita.com/wantun/items/4574049283e1cd7d50cf

程度低い記事だなあ、これはツッコまれるの不可避だわと思っていたら消えていた。

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

「いいね」も付いてたし指摘された誤りは修正すれば消さんでも良かったんじゃないのとは思う。

己に対して完璧以外許さない性格かな。

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

誤り以前にboolに変換して掛け算するのはどうなのよ

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

C言語ならまだギリギリ許されることもあるけどセマンティクス的に汚いし他の言語だとNGだから積極的に学ぶ方法でもない
読みにくくなるだけでなくコーディング量もそれほど変わらない上に速度すら落ちてるから

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

あとデータが1と0に限定されるから拡張性にも欠ける
後で2を使いたくなった時に全コード見直す必要が出てくる

**デフォルトの名無しさん** · 2023/08/10(木) 14:12:42.71

キャスト使えばこういう悪事もできるよ(良い子は真似しないでね)という記事なんだから、掛け算以外の指摘に関しては論点ではない

**デフォルトの名無しさん** · 2023/08/10(木) 14:15:03.93

C言語だと別に悪事というほどではない
ひたすら汚いだけ

**デフォルトの名無しさん** · 2023/08/10(木) 16:12:44.88

>>253
考え自体は正しい
条件分岐はパイプラインを乱す
条件分岐とならないコードが生成されることが望ましい

しかし多くのケースではコンパイラのコード生成に任せることができる
今回のケースならばif文のままでも条件ムーブ(CMOVcc)命令などが生成され条件分岐とならないだろう
ソースコードの可読性からもif文のままが好ましい

ただしもっと複雑なケースで複数の条件分岐をなくして演算のみにできる場合もある
そしてコンパイラ任せではそのようなコード生成が無理な場合もある
その場合はベンチ測定比較すれば有意な差が出るためそれは正しい判断となる

**デフォルトの名無しさん** · 2023/08/10(木) 19:42:46.48

> しかし多くのケースではコンパイラのコード生成に任せることができる
> 今回のケースならばif文のままでも条件ムーブ(CMOVcc)命令などが生成され条件分岐とならないだろう
> ソースコードの可読性からもif文のままが好ましい

なにやら知ったようなことを言ってるので検証してみるとするか。

**デフォルトの名無しさん** · 2023/08/10(木) 19:43:13.35

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;
　　}
　}
}

gcc 13.2 最適化オプション-O2でコンパイル
hoge:
　　　　testl　 %edi, %edi
　　　　jle　　 .L1
　　　　movslq　%edi, %rdi
　　　　leaq　　(%rsi,%rdi,4), %rax
.L4:
　　　　cmpl　　%edx, (%rsi)
　　　　jne　　 .L3
　　　　movl　　$0, (%rsi)
.L3:
　　　　addq　　$4, %rsi
　　　　cmpq　　%rax, %rsi
　　　　jne　　 .L4
.L1:
　　　　ret
https://godbolt.org/z/noxvcGbff

条件分岐するじゃんｗ

**デフォルトの名無しさん** · 2023/08/10(木) 19:46:00.32

記事の計算による方法
void hoge(int n, int num[n], int deleteNum)
{
　for (int i = 0; i < n; i++) {
　　for (int i = 0; i < 6; i++) {
　　　num[i] -= deleteNum * (deleteNum == num[i]);　// deleteNumで指定した要素を消す
　　}
　}
}
hoge:　xorl　　%r11d, %r11d
　　　　leaq　　24(%rsi), %r10
　　　　xorl　　%r9d, %r9d
　　　　testl　 %edi, %edi
　　　　jle　　 .L9
.L2:　　movq　　%rsi, %rax
.L4:　　movl　　(%rax), %ecx
　　　　movl　　%r9d, %r8d
　　　　cmpl　　%edx, %ecx
　　　　cmove　 %edx, %r8d
　　　　addq　　$4, %rax
　　　　subl　　%r8d, %ecx
　　　　movl　　%ecx, -4(%rax)
　　　　cmpq　　%r10, %rax
　　　　jne　　 .L4
　　　　addl　　$1, %r11d
　　　　cmpl　　%r11d, %edi
　　　　jne　　 .L2
　　　　ret
.L9:　　ret
https://godbolt.org/z/do55an9P9

cmov命令吐いてる

**デフォルトの名無しさん** · 2023/08/10(木) 19:47:40.53

ちなみに計算による方法でもこう書くと2行短くなった

void hoge(int n, int num[n], int deleteNum)
{
　for (int i = 0; i < n; i++) {
　　for (int i = 0; i < 6; i++) {
　　　num[i] *= deleteNum != num[i];　// deleteNumで指定した要素を消す
　　}
　}
}
hoge:　xorl　　%r10d, %r10d
　　　　leaq　　24(%rsi), %r9
　　　　xorl　　%r8d, %r8d
　　　　testl　 %edi, %edi
　　　　jle　　 .L9
.L2:　　movq　　%rsi, %rax
.L4:　　movl　　(%rax), %ecx
　　　　cmpl　　%edx, %ecx
　　　　cmove　 %r8d, %ecx
　　　　addq　　$4, %rax
　　　　movl　　%ecx, -4(%rax)
　　　　cmpq　　%r9, %rax
　　　　jne　　 .L4
　　　　addl　　$1, %r10d
　　　　cmpl　　%r10d, %edi
　　　　jne　　 .L2
　　　　ret
.L9:　　ret
https://godbolt.org/z/ro1qj98MG

**デフォルトの名無しさん** · 2023/08/10(木) 19:51:41.79

したがって>>253の記事は全面的に正しい
bool値を数値演算として使うことを積極的に推奨する

**デフォルトの名無しさん** · 2023/08/10(木) 19:57:21.15

> したがって>>253の記事は全面的に正しい

boolへのキャストなんてしねーよ馬鹿か

**デフォルトの名無しさん** · 2023/08/10(木) 20:01:44.72

>>256
数学に出てくるクロネッカーのデルタみたいなもので汚くはないし、型に厳しい言語でなければ他の言語でも使えるだろ。

**デフォルトの名無しさん** · 2023/08/10(木) 20:21:25.47

>>263訂正
void hoge(int n, int num[n], int deleteNum)
{
　for (int i = 0; i < 6; i++) {
　　num[i] -= deleteNum * (deleteNum == num[i]);　// deleteNumで指定した要素を消す
　}
}
hoge:
　　　　leaq　　24(%rsi), %r8
　　　　xorl　　%edi, %edi
.L2:
　　　　movl　　(%rsi), %eax
　　　　movl　　%edi, %ecx
　　　　cmpl　　%edx, %eax
　　　　cmove　 %edx, %ecx
　　　　addq　　$4, %rsi
　　　　subl　　%ecx, %eax
　　　　movl　　%eax, -4(%rsi)
　　　　cmpq　　%rsi, %r8
　　　　jne　　 .L2
　　　　ret
https://godbolt.org/z/br4nPfcEa

**デフォルトの名無しさん** · 2023/08/10(木) 20:22:14.91

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

hoge:
　　　　leaq　　24(%rsi), %rdi
　　　　xorl　　%ecx, %ecx
.L2:
　　　　movl　　(%rsi), %eax
　　　　cmpl　　%edx, %eax
　　　　cmove　 %ecx, %eax
　　　　addq　　$4, %rsi
　　　　movl　　%eax, -4(%rsi)
　　　　cmpq　　%rdi, %rsi
　　　　jne　　 .L2
　　　　ret
https://godbolt.org/z/7xhMr6oae

**デフォルトの名無しさん** · 2023/08/10(木) 20:25:05.76

すまん>>263再度訂正
void hoge(int n, int num[n], int deleteNum)
{
　for (int i = 0; i < n; i++) {
　　num[i] -= deleteNum * (deleteNum == num[i]);　// deleteNumで指定した要素を消す
　}
}
hoge:
　　　　testl　 %edi, %edi
　　　　jle　　 .L1
　　　　movslq　%edi, %rdi
　　　　leaq　　(%rsi,%rdi,4), %r8
　　　　xorl　　%edi, %edi
.L3:
　　　　movl　　(%rsi), %eax
　　　　movl　　%edi, %ecx
　　　　cmpl　　%edx, %eax
　　　　cmove　 %edx, %ecx
　　　　addq　　$4, %rsi
　　　　subl　　%ecx, %eax
　　　　movl　　%eax, -4(%rsi)
　　　　cmpq　　%rsi, %r8
　　　　jne　　 .L3
.L1:
　　　　ret
https://godbolt.org/z/9K6dj7Goc

**デフォルトの名無しさん** · 2023/08/10(木) 20:25:56.38

>>264も再度訂正
void hoge(int n, int num[n], int deleteNum)
{
　for (int i = 0; i < n; i++) {
　　num[i] *= deleteNum != num[i];　// deleteNumで指定した要素を消す
　}
}
hoge:
　　　　testl　 %edi, %edi
　　　　jle　　 .L1
　　　　movslq　%edi, %rdi
　　　　xorl　　%ecx, %ecx
　　　　leaq　　(%rsi,%rdi,4), %rdi
.L3:
　　　　movl　　(%rsi), %eax
　　　　cmpl　　%edx, %eax
　　　　cmove　 %ecx, %eax
　　　　addq　　$4, %rsi
　　　　movl　　%eax, -4(%rsi)
　　　　cmpq　　%rsi, %rdi
　　　　jne　　 .L3
.L1:
　　　　ret
https://godbolt.org/z/WTTadjj5a

**デフォルトの名無しさん** · 2023/08/10(木) 22:01:59.49

Rustでも同じ結果となった (diff -u 形式)
fn hoge(num_list: &mut [i32], delete_num: i32) {
　for num in num_list {
-　　if *num == delete_num {
-　　　*num = 0;
-　　}
+　　*num *= (*num != delete_num) as i32;
　}
}

アセンブラ出力の方はラベルと使用レジスタ名のズレだけ揃えてdiff
hoge:
　　test 　rsi, rsi
　　je 　　.LBB1_4
　　shl　　rsi, 2
　　xor　　eax, eax
+　　xor　　ecx, ecx
.LBB1_2:
-　　cmp　　dword ptr [rdi + rax], edx
-　　jne　　.LBB1_3
-　　mov　　dword ptr [rdi + rax], 0
-.LBB1_3:
+　　mov　　r8d, dword ptr [rdi + rax]
+　　cmp　　r8d, edx
+　　cmove　r8d, ecx
+　　mov　　dword ptr [rdi + rax], r8d
　　add　　rax, 4
　　cmp　　rsi, rax
　　jne　　.LBB1_2
.LBB1_4:
　　ret

**デフォルトの名無しさん** · 2023/08/10(木) 22:05:03.94

つまりC言語もRustもどちらも同じく
if文の時は普通に条件分岐する
比較値を自己掛け算させるとcmoveを使う

生成コードで掛け算が消えてしまうのはいいね
代わりにやってることは
(1) レジスタの値にメモリから読み込む
(2) 比較
(3) 一致していた時のみレジスタに値0を入れる【cmove】
(4) レジスタの値をメモリへ書き戻す

条件分岐がない代わりに0にしない時も常に書き込みが発生する
ただし読み込んだ位置への書き込みだから
1サイクルのみでキャッシュページミスのペナルティも無くて済むから問題なしか

一方で元の条件分岐ジャンプするコードと比較して速さはどうなの？
分岐予測ミスやパイプラインの乱れとやらがどれだけ効くのか教えて欲しい

**デフォルトの名無しさん** · 2023/08/10(木) 22:05:48.11

何度訂正されても暑さでやられたやつが発狂してるようにしか見えんからもういいぞ
どうしても主張したいなら記事書けよ

**デフォルトの名無しさん** · 2023/08/10(木) 22:36:14.41

訂正してる人はコピペミスか実験かどちらかで二重ループになってしまったのを訂正してるっぽいけどよくわからん

アドバイスできることは
clangの方で-O2だとベクタ展開して比較わかりにくくなってるのを
-Os指定すれば展開がなくなりgccとほぼ同じコードになるよ

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

>>273
元の条件分岐ジャンプするコードと比較して速さはどうなの？と聞いてるが
元のコードが何か分からないし
比較対象のコードが何か分からない
元のコードと比較対象のコードは何？

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

if文を使ったコードと使わないコードの2種類が示されている状況で
何と何を比較しているのかわからないのは深刻な脳のバグだよw

**デフォルトの名無しさん** · 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
草