番外企画・速度にまつわる小ネタ達の巻

　どんな言語でも、プログラミングをする際に要求されることの一つに「いかに高速なプログラムを組めるか」があります。今回はその当たりに突っ込んでいきたいと思います。でもネタがなくてベンチマーク大会に走ったわけではないぞなもし(^^;。
4/26補足：トップメニューの変更に伴って「番外企画」となりました。でも別に何も変わってないんですけど。

●概要
　一般に「こうすると速くなる」といわれている高速化テクニックについて以下のスクリプトを用いて処理にかかった時間を測定し、その効果を確かめます。間にあいている3行の空行に計測するスクリプトを挿入して使います。なお、このスクリプトをご家庭(笑)で使用するには、MIAさん作の「DSOUNDEX.DLL」が必要になります。

　今回実験に使用したマシン環境は、以下のようなものとなっています。

機種：PC-9821 Xa13
CPU：Pentium 133MHz、K6-2 333MHz
メモリ：80M、128M
OS：Windows98
画面：1024*768 256色
HSP：Ver 2.4g、Ver 2.4h2、Ver 2.5

　いうまでもないですが、計測中はマウスやキーボードには一切手を触れていません。また、計測時はHSPスクリプトエディタ以外のアプリケーションを最小化した状態で計測しています。

●実験開始

実験1.「a=a+1」より、「a++」「a+=1」のほうが速い
　ってプログラミングリファレンスなどに書かれているので、間違いないと思いますが実験。それぞれの計算を100万回行うのにかかった時間を比較します。 

　なんとa++だと普通の倍の速さで計算できるではありませんか!!　またa+=1でも約25%の高速化。
　念のため、引き算でもやってみました。 

　ほぼ同じ結果となりました。

結論：a++、a+=1の方が高速に計算できる。

実験2.割り算をビットシフトで代用すると速くなる
　C言語では2のn乗で割るのならビットシフトを使った方が高速に処理ができるのですが、HSPではどうか試してみようということで実験。1同様計算を100万回行うのにかかった時間を比較します。 

　あらら、あまり変わらないみたい。では掛け算で比較。 

　アラららららららら、逆に遅くなったぞ。ビットシフトって役に立たないってこと？　ガーン(注：使い方によっては十分役に立ちます)。

結論：ビットシフトは高速化としては微妙な効果しかなく、しかも掛け算だと逆に遅くなる(ただし掛け算はオーバーフローするので使い分けが必要)。

実験3.clsで消すよりboxfで消した方が速い
　画面消去をboxfで行うのとclsで行うのとどっちが速いでしょうか。ここではそれぞれ500回画面を消去して比較してみます。ウィンドウサイズは640*480で、redrawは使っていません。 

　うわ〜全然速度違うじゃないか。たぶんこれはclsがパレットやオブジェクトを初期状態に戻していることが原因だと思いますが。

結論：boxfの方が断然速いが、オブジェクトを使っている場合は初期化しないと残っているので注意。

実験4.redrawはどれくらいで遅くなるか？
　redrawは、1フレーム当たりの描画量が少ないときは使わない方が高速に動作するのですが、ではどれくらいまでならredrawを使った方が速いのか実験してみました。ドットを1フレームに1個〜100個描画、これを100フレーム行ってかかった時間を大比較!!　なお、ゲームプログラミングを想定しているため画面はboxfで消去しています。 

　・・・って全然遅くないやん(爆)!!　っつうか、画面消去して一から書き直すくらいならredraw使うに決まってますから実験失敗。気を取り直して今度は画面消去無しで測定してみます。 

　凄い結果が出ちゃいました。画面消去しなかったらredraw使っちゃダメという結論が出ました。ただしこれはドットを打っているだけなので、boxfやgcopyに置き換えてさらに実験を行ってみます。まず、32*32ドットの四角を描いて比較。 

　続いてgcopy。gmodeを2にして、画像を32*32ドットコピーして比較。 

結論：非リアルタイムゲームなどのようにフレームごとに画面の大部分を書き替えないプログラムであればredrawを使わないほうがよい(ビデオカードの性能や見栄えを考慮した場合などによってはその限りではないが)。

実験5.サブルーチンは遅い!?
　MSXを使っていたころに「サブルーチンを多用すると処理速度が低下する」という話を聞いたことがありますが、HSPではどうか大比較。実験1のa++を100万回行うプログラムを、サブルーチンを使った場合とサブルーチンをgoto文で代用した場合とで比較してみます。参考までに、goto文で代用するとどうなるかを下に記しておきます。なお、サブルーチンを使わずに処理した場合の結果は、実験1にありますので割愛させていただきます。

　倍近くの時間がかかっています。あと、サブルーチンをgotoで代用するとさらに遅くなっています。いくら何でもループの中でgotoを使うというような行為はエラーの原因にもなりますし、そもそもこういうプログラムを組むと凄いかっこ悪いのでやめましょう。

結論：遅い。goto文で代用するともっと遅い。

実験6.ループはやっぱりrepeatのほうがよいのか
　repeat〜loopを変数とif文で代用すると、速度はどう変化するのか確かめてみました。プログラムは例によってa++100万回です。repeat〜loopの結果は実験1にあるので以下略。 

　ぐは〜劇的に遅くなりました。repeat〜loopの約3倍半です。repeatがネストし過ぎていない限りやっちゃいけないですな。

結論：むちゃくちゃ遅くなる。

実験7.if文と理論式はどちらが速いのか
　理論式というのは「a=a+(x>200)」のような式のことで、この場合「xが200を越えている場合、aに1が足される」という意味になります。BASICではよくどちらが速いだの遅いだのいわれ続けましたが、HSPでは結局のところどうなのか実験。「a>10のときに、bを1足す」というプログラムを100万回行って速度を比較してみました。 

　というわけでif文に軍配!!　だいたいHSPだと理論式を使ってプログラムをスマートにする意味がほとんどないんだよね。

結論：if文を使おう。

実験8.\と&はどちらが早いか(4/7追加)
　演算子「a\b」はaをbで割ったあまりを出すというもので、「a&b」はandの論理演算です(主に特定のビットを0にするために使われる)。これらの演算子は読んでの通り使い方が異なるわけですが、ある条件ではどちらを使っても同じ動作をします。であれば速いほうを使うべきだろってことで比較です。

　100万回やって0.3秒程度の差ではありますが、速くなることにかわりはありません。条件を書かずに使えっていうのも変ですけど。

結論：&の方が速くなる。

実験9.ループはやっぱりrepeatのほうがよいか・パート2(4/26追加)
　実験6においてループはrepeatにしたほうが3倍半くらい速くなると言う結果がでました。そこで、ゲームなんぞのメインルーチンをrepeatでループさせればどのくらいまで高速化できるのかという、どこまでもセコイ実験です。タイマーのチェックとawait命令だけを延々繰り返し、10秒後の平均フレーム数(fps)を比較します。

　あれっ、gotoの方が速いぞ。どーゆうこっちゃ。

結論：goto文のほうが速いけど、repeatの方が少し速度が安定している感じだ。

実験10.i=cntは遅い?(2001/01/12追加)
　以前ループ中にあった無意味な一時変数へのカウンターの代入を消したところそこそこの高速化が望めたことから変数への代入に結構なオーバーヘッドがあることに気づいたので実験してみることにします。例によって100万回ループの中で「a+=cnt」あるいは「i=cnt:a+=i」を実行してどれくらいの差が出るか、またループの中でカウンターを参照する回数を増やして(「a+=cnt」や「a+=i」の回数を増やして)一時変数の使用は効果があるのかを検証しました。

　こうなりました。5回までは直接参照の方が有利ですが、回数が増えてくると一時変数に代入した方が高速になるようです。

結論：たくさん使うなら代入しておいた方がよい。

実験11.ネストってどうよ(2001/01/12追加)
　例えば64*64の配列を参照するときに普通はループを二重にして処理しますがこれをネストさせないようにするとどのくらい速度は変わるのでしょう。一万*100回のループをネストした場合としなかった場合で比較してみます。一応ネストした場合は一番深いループのカウントを一時変数に代入した場合としなかった場合も調べます。

　除算が遅いせいだと思いますが、全然違いますね。ちなみに一時変数への代入については前の実験を参考にして決定しましょう。

結論：ネストしとけ。

実験12.コメントの通過は時間がかかるか?(2001/01/12追加)
　内部の動作を考えればこの比較が無意味なのは明らかですが、一応はっきりさせておきたいので比較します。

　あ、全く一緒だ。ちなみにこの後コメントや空行を100行くらい入れましたが誤差の範囲内だったことを付け加えておきます。

結論：なワケねぇだろ。

●実験を終えて(ってなんだか論文かレポートみたいだな。笑)

　というわけで今回は処理速度にまつわる実験を行いました。知らなかった人はこれを参考にできる限り高速で動作するプログラムが組めるようになれば幸いだよね。でも無駄のないプログラムを組むことが一番高速化に繋がる気がするけど。今回やったことって基礎知識みたいなところあるし。
3/15補足：MIA's Homepageにて、高速化をテーマにしたページが最近できたようです。ここよりもさらに深くつっこんでいるので、一度目を通しておくとよいでしょう。念のためいっておきますが、やり始めたのはこっちの方が先だから「おまえパクッただろ」とか言わないでね(笑)。
4/26補足：番外企画に移動したこともあって、実験はどんどん増えていきます。ネタがあればね。

戻る