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/15(土) 13:42:45.20

>>188
> 性能比較を押し付けるな

記事書いた当人が性能比較してるけど何言ってんの??

> ベクトルサイズと実行命令数の相関関係と相関係数は次のようになりました．
> * 提案手法(固定小数点数表記のRVVハンドコーディング実装): 36.932n + 406.53, 0.9611
> * 固定小数点数表記のC実装，GCC 12.2 (`-O2`): 349.35n + 31.996, 1
> * 固定小数点数表記のC実装，Clang 16.3.2 (Auto-vectorization): 175.16n + 52.681, 0.9887

**デフォルトの名無しさん** · 2023/07/15(土) 14:02:39.96

>>189
glibc等で提供される三角関数と性能比較してないの意味わからんｗ
↓
glibc等で提供される三角関数と性能比較するなら意味わかる
↓
glibc等で提供される三角関数と性能比較しろ
↓
性能比較を押し付けてる

と思ったんだが何が違うんだい？

**デフォルトの名無しさん** · 2023/07/15(土) 14:16:46.67

>>190
・CORDICによる三角関数の性能比較は記事書いた当人が行っており性能比較は>>187が言い出したことではない
・CORDICは手段であり目的ではない筈

以上2点ご確認ください。

**デフォルトの名無しさん** · 2023/07/15(土) 14:44:06.82

> タイトルからして意味わからん
> 意味わからん記事を読むべきでない
> 頭が混乱して性能比較を押し付け誹謗中傷もしてしまっている

自他の区別がつかない人かな

**デフォルトの名無しさん** · 2023/07/16(日) 14:44:35.54

https://qiita.com/zacky1972/items/e3ec1e57168e685e2893/likers

全員福岡Elixirコミュだけど記事の内容読んで理解していいねつけてる気がしない

**デフォルトの名無しさん** · 2023/07/16(日) 16:31:39.57

Facebookでも上司の意味わからん投稿にいいねつけるだろ
それと一緒

**デフォルトの名無しさん** · 2023/07/16(日) 18:25:53.17

これだけ短期間に複数の改善提案される程度の記事にいいねつけなきゃならん部下も大変だなｗ＞福岡Elixirコミュ

つか情報処理学会で発表ってマジか。マサカリハンパじゃないと思うが。

**デフォルトの名無しさん** · 2023/07/17(月) 03:08:55.58

>>194
いや、組織でいいねを付けるのはQiitaのどの記事でも一緒

**デフォルトの名無しさん** · 2023/07/17(月) 05:00:22.37

実際は経営企画なのに、ショッピングセンター勤務者という記事
超高速の肉まんbunがnodeの5倍denoの2倍早いらしいんだがマジか

**デフォルトの名無しさん** · 2023/07/17(月) 08:54:04.75

>>197
「ノーコード」だってさ

**デフォルトの名無しさん** · 2023/07/17(月) 21:03:43.84

h ttps://qiita.com/zacky1972/items/eabbcae5af04e24c2cc0#comment-0264e1d4f5877205726a
> なお、当方はRISC-Vの知識は持ち合わせておらず動作環境も手近にないのでこのコメント冒頭で言っているa5が使用されたコードが正しくないかは確認しておりません。
> 同様に、このコメントでの修正内容が正しいかは不明なので参考にされる方はご慎重に願います。

予防線張るのダッセエ

**デフォルトの名無しさん** · 2023/07/17(月) 21:25:24.50

知識ないのに突っかかるって凄いなw
働いたことないんだろうか

**デフォルトの名無しさん** · 2023/07/18(火) 00:14:30.93

准教授

RISC-Vベクタ拡張を用いたCORDICアルゴリズムによる三角関数の実装
https://qiita.com/zacky1972/items/e3ec1e57168e685e2893
> 提案手法の定数項が想定よりかなり大きいのは，最適化オプションを指定していないためです．
> 最適化オプションを指定しなかった理由は，現状の実装では最適化オプションを指定すると
> 不具合を生じるためです．この原因は，アセンブリコードの生成にGCCのインラインアセン
> ブラ機能を使用したのですが，おそらく申告すべき使用レジスタの指定を誤っているためでは
> ないかと考えられます．

に直球のツッコミ入ったわけだけどどうすんのかな？
学生さんに教える立場であれば自分の考えに固執するんじゃなくて何が正しい正しくないで語ってほしいところではあるかな

**デフォルトの名無しさん** · 2023/07/18(火) 01:07:09.70

というかこのレベルで科研費貰えるんだね

**デフォルトの名無しさん** · 2023/07/18(火) 19:51:13.13

> 本研究はJSPS科研費 22K04657の助成を受けたものである．

これかな

MPSoCとSAR衛星によるリアルタイム土砂災害情報提供システムの実現可能性検証
https://kaken.nii.ac.jp/ja/grant/KAKENHI-PROJECT-22K04657/
https://researchmap.jp/zacky1972/research_projects/40967862

**デフォルトの名無しさん** · 2023/07/18(火) 23:22:11.86

https://qiita.com/zacky1972/items/eabbcae5af04e24c2cc0#comment-274dfdc78a0388e2b28b
> 要素数を左2ビットシフトしてアドレスレジスタに加算されてますが3ビットシフトして8倍にするのが適当なのではないかと思うのですが

指摘がその通りだとすると動作確認しないで記事書いてた可能性も出てくるのかな

https://qiita.com/zacky1972/items/eabbcae5af04e24c2cc0
> "vsetvli t0, t1, e64, m8\n\t"

> "slli t0, t0, 2\n\t"
> "add %[v], %[v], t0\n\t"

でも同じことしてるみたいだけど准教授ダンマリになっちゃったけど折角記事読んでいいねつけてくれた福岡Elixirコミュのみんなのためにも責任もって回答して欲しいよね

**デフォルトの名無しさん** · 2023/07/19(水) 23:06:58.07

SAR衛星によるリアルタイム土砂災害情報提供システムの実現に向けた衛星画像の分散並列処理の実現
https://researchmap.jp/zacky1972/misc/40467660

ダウンロードして読んだけどPythonより遅いElixirって意味あんのかよｗ

やっぱこの人手段が目的化してるわ。

**デフォルトの名無しさん** · 2023/07/19(水) 23:34:30.52

>>205
https://elixir-fest.jp/
2019年に任天堂がElixir使ってzacky1972の名前もある
任天堂がつかってるからスポンサーがいる

**デフォルトの名無しさん** · 2023/07/20(木) 00:35:39.00

任天堂が何らかの用途にElixirを使っている(いた)というのと、
准教授が画像処理にElixir選んでクソ遅いPythonより性能出せなかったというのは
実は大して関係がある話ではない。

**デフォルトの名無しさん** · 2023/07/20(木) 22:01:20.27

CORDICアルゴリズムに必要なarctan(2^{-i})のテーブルを整数演算で作成する
https://qiita.com/zacky1972/items/b62baa0d74221ad51fb8

Elixirで？こういうことやる意味がわからんのだけど

https://qiita.com/zacky1972/items/e3ec1e57168e685e2893#comment-a2ae5fca7ed289b8d732

への対抗心かな？ひとっことも触れてはいないけども。

次に平方根の記事投稿したらオモロいのにｗ

**デフォルトの名無しさん** · 2023/07/22(土) 22:44:05.02

今ほぼコードレビュー専になってる私が、リーダブルなコードを書くうえで意識してほしいと考えている順番
https://qiita.com/kawagashira/items/a0d2ef9bc058dacc03d3

沢山いいねついてる記事だけど

>　public function changeHeightByAbsoluteMeter($value) {
>　　$this->height = $value;
>　}

AbsoluteMeterや$valueに誰も疑問持たないのかな。

**デフォルトの名無しさん** · 2023/07/23(日) 04:34:12.13

絶対値で高さを変えるか相対値で高さを変えるかで意味ある
valueは「日本人は何故英語が出来ないのか」に誰も疑問持たないのと同じ

**デフォルトの名無しさん** · 2023/07/23(日) 13:06:54.90

valueになってる理由は記事にもちゃんと書いてるだろうが
> 引数を丁寧に命名するなら $absoluteValue になるが、スコープの短さを考えると省略しても自然

**デフォルトの名無しさん** · 2023/07/23(日) 13:14:12.17

>>211
リーダブルコード「汎用的な名前を避ける」は？
valueやarg、fooなどの空虚な名前はできるだけさけるべきである

**デフォルトの名無しさん** · 2023/07/23(日) 13:48:36.00

>>212
いや、俺に聞くなよ
俺が記事書いてるわけじゃないんだから

記事主としてはリーダブルコードの「無駄な単語は捨てる」を実践してるんだろう
今回のケースが適切かどうか知らんけど

**デフォルトの名無しさん** · 2023/07/23(日) 14:06:16.50

>>213
記事の読み方の違いだが記事の
> 「変に削るより、長くてもいいから正確な命名を」という言説をしばしば見るように感じますし、私も同意
は「無駄な単語は捨てる」の逆だと思った
リーダブルコードは短いほうがいいで記事は長くてもいい
日本人は英語ができないから正確に削れないということだろう

**デフォルトの名無しさん** · 2023/07/23(日) 16:57:38.73

>>210
> 絶対値で高さを変えるか相対値で高さを変えるかで意味ある

change～なんてアホなメソッド名やめて set～や add～とかにすればおｋ

**デフォルトの名無しさん** · 2023/07/23(日) 20:38:42.33

> 今ほぼコードレビュー専になってる私が、リーダブルなコードを書くうえで意識してほしいと考えている順番

ハンパな知識のオッサンが若い人のコードに思いつきでダメ出ししてる光景が目に浮かぶんだけど。

**デフォルトの名無しさん** · 2023/07/23(日) 21:02:45.58

今回のは結論ありきのお題だから突っ込むのは野暮かもしれんが
>>215に完全同意。この場合get/setのほうが百倍マシ。
メソッド名がシンプルで、メソッドの内容がシンプルで、メソッド間の直行性が高い。

$myCar->changeHeightByRelativeMeter(1);　←きがくるっとる
$myCar->changeHeightByRelativeMeter(0.2);　←きがくるっとる

$myCar->setHeight(1);　←きがくるってない
$myCar->setHeight($myCar->getHeight() + 0.2)　←きがくるってない

説明的な変数名、メソッド名をつけなきゃいけないのは
散らかったウンコを片付けずに消臭剤いっぱい振りかけるのと同じ

**デフォルトの名無しさん** · 2023/07/23(日) 21:41:55.47

確かにsetHeight, addHeightのほうがいいな

**デフォルトの名無しさん** · 2023/07/23(日) 22:22:44.58

>>215
絶対値相対値とか言われてもピンとこないよね普通は

**デフォルトの名無しさん** · 2023/07/24(月) 13:45:58.84

そもそも高さって何なん？
車高のこと？
なんで車高を変えんの？

**デフォルトの名無しさん** · 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から削除されて存在しない
１つのテーマを掘り下げる目的がありそうだし
長くなりそう