コグノスケ

手動の最適化 対 コンパイラの最適化

ポッキーの日だそうですが、1（と0）といえば2進数、2進数といえばビット操作ですね（？）。以前 Bit Twiddling Hacks を最新のコンパイラ達に向けて試したときの悲しい結果をメモしておきたいと思います。

試したのはConditionally set or clear bits without branchingという項目で、fがtrueならwとmのビット論理和を、fがfalseならwからmのビットを消去した値を返す処理です。素朴な実装ではif文を使うでしょう。

int cond_set_or_clear1(bool f, int m, int w)
{
    if (f)
        return w | m;
    else
        return w & ~m;
}

さきほどのサイトでは最適化版として、条件分岐をなくす、データ依存性をなくす（スーパースカラプロセッサ用）、2つのバージョンを掲げています。まずは条件分岐をなくした版のコードを紹介します。

int cond_set_or_clear2(bool f, int m, int w)
{
    return w ^ ((-f ^ w) & m);
}

分岐がなくなっています。なんでこれで同じ動作をするのか？は説明が必要でしょう。fがtrueなら -f = -1となり、-f ^ wはwのビット反転（notと同じ）と同じ結果 -1 ^ w = ~wになります。よって右側の括弧内 (-f ^ w) & m = ~w & mです。

あとは~w & mはw = 0, m = 1のビットだけ1になって残り、あとは全部0になります。w ^ (~w & m) はw | mと同じ結果ですが……そう言われてもわかりにくいので表にします。

一方fがfalseの場合、0とみなされるので -f = 0となって、-f ^ w = 0 ^ w = wです。右側の括弧内 (-f ^ w) & m = w & mです。w ^ (w & m) は先ほどとは逆でw = 1, m = 1のビットだけ1になって残り、あとは全部0になります。

最後にwとこの結果をxorすることでwとmがともに1のビットだけ0になりますから、w ^ (w & m) はw & ~mと同じ結果です、が……これも表がわかりやすいでしょう。

次にスーパースカラ版のコードを紹介します。

int cond_set_or_clear3(bool f, int m, int w)
{
    return (w & ~m) | (-f & m);
}

これは先ほどよりシンプルです。左側の括弧はfによらず常にw & ~mで一定で、右側の括弧の値だけが変化します。

まずfがtrueなら -f = -1となり、-f & m = mです。(w & ~m) | mですが、w & ~mはwからmの1となっているビット位置を0にする演算でした。そこにmをorすると消えたビットは再び1になります。すなわちw | mと同じ結果です。

次にfがfalseなら -f = 0となり、-f & m = 0です。よって (w & ~m) | 0 = w & ~mになります。

なぜスーパースカラ向けか書いていませんが、w & ~mと -f & mに依存性がなくて同時に演算できるからだと思われます。じゃあ全部これでいいじゃないか？と思われるかもしれませんが、演算回数を見ると、

2つ目の方式: w ^ ((-f ^ w) & m)

neg, xor, and, xorの4回の演算が必要

3つ目の方式: (w & ~m) | (-f & m)

not, and, neg, and, orの5回の演算が必要

このため同時に演算できないプロセッサの場合は2つ目の方式の方が良いと言えます。

全てを無にするコンパイラの最適化

ここまで長々と紹介しておいてこんなことを言うのは憚られますけど。この手のビット魔術は面白いのでつい手を出したくなりますが、最近のコンパイラに対しC言語レベルでの最適化はあまり意味がないです。

論より証拠でGCC 12.2.0の結果から見てみましょう。

GCC 12.2.0でのコンパイル結果

あれだけグダグダ語った3つ目の方式でしたが、なんと2つ目の方式と全く同じバイナリになりました。

GCCだけでは証拠として不安でしょうか？では次にclang 15.0.0の結果も見ましょう。

clang 15.0.0でのコンパイル結果

なんと3つ目の方式は「これ分岐じゃね？」と解釈されて分岐に戻されてしまいました。これが分岐に見えるclangはスゴイですね。私はこのコードを見ても分岐には見えません……。

1つ目の方式と2つ目の方式が違うバイナリになるところを見る限り、全くの無意味ではないです。しかし見やすさでは大幅に劣ります。基本は素朴なコードにしておき、遅くて困る場合のみビット魔術に手を出すべきでしょう。

皆既月食と惑星食

今日は皆既月食と惑星食（天王星）が同時に観測できる非常に珍しい日だそうです。天王星はさすがに撮影できないでしょうけど、月ならなんとか撮れるだろうと思い、三脚とカメラを持って撮影しました。

肉眼で見ると赤くボンヤリとした月に見えます。先日（2022年9月10日の日記参照）撮った、中秋の名月と比較するとかなり暗いです。

まずコンデジでは暗くて写りません。マニュアルで明るさの限界を狙って設定したものの、私の腕と知識では下記の写真が限界でした……。

コンデジ（CASIO EXILIM EX-ZR1300）で撮影

月の左下に天王星らしき点？が写っています。天王星は青いと聞きましたが、あまりに点が小さすぎて良くわかりません。もしかしたらレンズについたゴミかもしれないです。

奥さんの一眼レフでも撮りました。さすがの高解像度＆性能ですが、残念ながらレンズのズーム倍率が足りず非常に小さくしか写りません。

一眼レフ（Canon EOS Kiss X10, Canon EF-S 18-55mmレンズ）で撮影

引き延ばしたところボンヤリした写真になってしまいました。世の写真家が撮影したきれいな写真がたくさんあるので、それを眺めることにします。

JTSA Limited練習記録2022

目次: 射的

スピードシューティングを始めてから半年ほど経過しました。いよいよ11月末は公式大会（リミティッド - 一般社団法人日本トイガン射撃協会JTSA）です。今までの練習会のタイムをまとめておこうかと思います。

基本的に練習は週1回のみです。たまに練習以外のシューティング系イベントにも行きますが、さほどタイム上達とは関係ないはず。たぶん。

JTSA Limited練習会の記録

トータルタイムが2種類ある理由は、途中でStage 5の追加が正式発表されたためです。そのため7月まではStage 1〜4の合計（赤い線、右軸）、8月からはStage 1〜5の合計（青い線、右軸）が記録となります。ですが8月以降もStage 1〜4の合計タイムを見たら、今までと比べて上達or停滞が分かりやすいかも？と思い、表示しています。

最初こそ順調に早くなっていますが、ここ2〜3か月は伸びが止まっています、記録は正直だな〜。タイムは80秒台前半、脱・初心者レベル（※）くらいです。もうオジサンだし、あんまり根詰めたり無理するとケガするだけなんで、気楽＆気長にやります。

（※）大会の前の公式記録会だと、総合（Hands Up）で84/101位、カテゴリ内（LM）で21/28位でした。