ビットマップをごっそりメモリコピーする必要がでたわけです。 単純に memcpy を使うと、byte 単位でしかコピーしてくれないようなので、自分で書いてみることにしたわけです。 ついでに、mmx とか sse とか使える環境下では、これらを使った方が早いと思いますし。
…って今調べたら asm で書かれてる memcpy の DWORD 単位でコピーするコードもあるのね…
crt\src\memcpy.c しか見て無かったよ… orz
…当初書く予定の失敗談を書く前に 予定外の失敗が発生してます が…まぁまぁ。＾＾；
で、何を失敗したというと、計測です。
::timeGetTime() つかってたのはいいのですが、::timeBeginPeriod() するの忘れてました。orz 風呂入ってるときに気づいた……。 …うぅ…やり直し…
…とはいえ…不正確な数値とはいえ、どうも変な結果がでてるような…（不正確なので適当にネタにしてます）
↑16MBのメモリコピーを32回行うプログラムを８回起動し、処理した時間の平均値
- 項目名のサフィックス s, d, sd は、それぞれ Src, Dest, Src&Dest のアライメントがずれている状態を表します。 なお、16byteにそろえられてるバッファに対して２バイトずらします。
- DWORDコピー x 16回 をループさせてます == ループのアンロールをちょこっとしてみた
- 64 と 64asm は、Cコードと 自前asmコードの違い。
- Athlon 1260MHz, PC2100 CL2.5, 1GB (起動時は 512MBぐらいの空)
…計測が間違っていたとはいえ、アライメントが揃ってるコピーが遅いってのはなんなんだろう。つか、ソースのアライメントが狂ってる方が早いってのは一体。 また、PenIII PC133 マシンでも同じバイナリで実行してみたところ、今度は dest が狂っていた方が早いとか言う状態に…
他にも、単純にループだけで済ますコード等で色々テストしてみましたが…どーも違和感を感じる結果しか出てこない…。 …テスト環境 or テストコードがおかしい気がしてなりません。（ぉ（いや、コードは問題あったんですが…）
timeGetTimeのデフォの精度って 10ms ぐらいだった気がするので…誤差が積み重なったと見る事も出来そうな感じもするけれど…うむむむ…
とりあえず、もう一度やり直してみよう。 そして、もっと精度の高い QueryPerformanceCounter で計測しなおしてみよう。
でも、その前に講義の課題やら無いと…
でも、その前に寝よう…＾＾；
