コツコツと更新してここまで来ました。
最新:GitHub - mattsan/BitOperation: operating bits classes
(2010/03/14時点:GitHub - mattsan/BitOperation at cbd369981a0ec5fd251e57f99877f45401be3c46)
ここでちょっとパフォーマンス測定。
使ったコードは、今日リポジトリに追加したsample/color_conv/。カラーコードを変換するサンプルです。
各々の関数と、測定時の実行回数は次のとおり。
関数 | 内容 | 実行回数 |
---|---|---|
make_rgb555 | 3つの値から15bitカラーをつくる | 32,768,000回 |
make_rgb565 | 3つの値から16bitカラーをつくる | 65,536,000回 |
make_rgb888 | 3つの値から24bitカラーをつくる | 167,772,160回 |
rgb555to565 | 15bitカラーから16bitカラーへの変換 | 32,768,000回 |
rgb555to888 | 15bitカラーから24bitカラーへの変換 | 32,768,000回 |
rgb565to555 | 16bitカラーから15bitカラーへの変換 | 65,536,000回 |
rgb565to888 | 16bitカラーから24bitカラーへの変換 | 65,536,000回 |
rgb888to555 | 24bitカラーから15bitカラーへの変換 | 167,772,160回 |
rgb888to565 | 24bitカラーから16bitカラーへの変換 | 167,772,160回 |
これらを今回作成した変態クラステンプレートで実装した場合と、愚直に実装した場合とで比較してみました。実行時間の計測にはBoost. progress_timerを使っています。また計測量の単位は秒です。
結果。
関数 | emattsan::bits | naive | 比率 |
---|---|---|---|
make_rgb555 | 18.49 | 1.39 | 1,330.22% |
make_rgb565 | 37.13 | 2.92 | 1,271.58% |
make_rgb888 | 95.24 | 8.56 | 1,112.62% |
rgb555to565 | 35.25 | 2.06 | 1,711.17% |
rgb555to888 | 42.21 | 4.85 | 870.31% |
rgb565to555 | 70.2 | 4.05 | 1,733.33% |
rgb565to888 | 84.58 | 9.97 | 848.35% |
rgb888to555 | 205.58 | 10.13 | 2,029.42% |
rgb888to565 | 205.56 | 10.15 | 2,025.22% |
見事に惨憺たるものです。10倍から20倍の時間がかかってる。やはり式を複雑に重ねた影響は如実に出るようです。
とはいえ。これは最適化していない時の結果。
コンパイラに最適化を指定した場合はどうなるか。
結果。
関数 | emattsan::bits | naive | 比率 |
---|---|---|---|
make_rgb555 | 0.230 | 0.230 | 100.00% |
make_rgb565 | 0.462 | 0.462 | 100.00% |
make_rgb888 | 1.560 | 1.388 | 112.39% |
rgb555to565 | 0.254 | 0.230 | 110.43% |
rgb555to888 | 3.806 | 3.854 | 98.75% |
rgb565to555 | 0.554 | 0.494 | 112.15% |
rgb565to888 | 7.632 | 7.746 | 98.53% |
rgb888to555 | 2.990 | 2.822 | 105.95% |
rgb888to565 | 2.994 | 2.838 | 105.50% |
遜色ないぐらいの結果が出ました。成績が愚直なコードよりよくなっているものもあります。愚直なコードがもっとも効率の良いコードとは限らないのでこのような結果がでてもおかしくはありませんが、結果として速くなっているというのは興味深いです。
なお測定は次の条件でおこないました。
マシン | iBook G4 |
CPU | PowerPC G4 1.33 GHz |
OS | Mac OS X 10.5 |
コンパイラ | GCC 4.0.1 |
最適化オプション | -O3 |