実行速度の差
解決ＶＢでネイティブコンパイルをした場合、ＶＢの演算関数をランタイムから
呼び出して実行しますが、ＶＣ＋＋のように演算関数を使ってもインライン展開して実行される方式と比べるとネイティブであるＥＸＥからＶＢのランタイム呼び出すのはどのくらい遅くなるのでしょうか。
（特に演算関数において）
また、最適化をなしにしたとき、速度はかなり落ちますか？
>ＶＢでネイティブコンパイルをした場合、ＶＢの演算関数をランタイムから
>呼び出して実行しますが
ランタイムから呼び出すのはP-CODEの場合です。
(ランタイムというよりP-CODEインタプリタですが)
ネイティブの場合はアセンブリ言語で言えばJMPニーモニックに
相当するマシン語(ネイティブ ランゲージ)で呼び出します。
>ＶＣ＋＋のように演算関数を使ってもインライン展開して実行される方式と比べると
>ネイティブであるＥＸＥからＶＢのランタイム呼び出すのはどのくらい遅くなるのでしょうか。
ネイティブに落ちたあとの関数にはいる直前のマシン語命令から
関数内の最初のマシン語命令を実行するまでの時間差という意味なら、
Long型引数1個の場合、レジスタにイミディエイト値をMOVして
関数エントリに間接JMPするだけですから、違いは十数クロックというところでしょう。
このぐらいなら人に聞くまでもなく、逆アセンブルリストをみれば一目瞭然です。
しかし関数呼び出しのコストなんてたかが知れてますから、
この比較そのものにあまり意味がありません。
しかし気になるなら実測してみたらどうでしょう？
関数プロシージャのトップアドレスに飛んだら呼び出した関数が直接処理をしていくのか、ネストされてCALL命令などが実行されているのでしょうか。
最適化では、必要な箇所でLODSB,STOSBがLODSW,STOSW,MOV AL,0がXOR AL,AL,のようにせずサイクルを短くできていないと思うのですが、もしそうなら、その差は大きいのでしょうか。それともCALL命令を使用せずサブルーチンが
メインルーチンに展開せれるのが高速効果の大きいところなのですか？
何をされたいのでしょうか？
VBでの命令単位でのクロック削減は高速化にほとんど寄与しません。
一般のVBアプリにおいて、消費時間の90％以上が
コンポーネント関連の処理によるものです。
科学技術計算でもない限り算術演算関数の消費時間なんて、
残り10％のさらに何％かでしょう。
(もし時間にシビアな科学技術計算をしようと思っているのなら、
VBを使うこと自体、間違ってます。)
そのせいぜい数％の部分を高速化したところでたかがしれています。
たとえば、P-CODEはネイティブに比べ、数倍から数十倍遅いはずですが、
VBの場合、前述の理由でコンパイルコード部分の全体に占める割合が小さいため、
結果的にどちらでコンパイルしても目立つほど速度差は発生しません。
このへんはヘルプに書いてありますから、一読されることをお勧めします。
>MOV AL,0がXOR AL,AL,のようにせずサイクルを短くできていないと思うのですが、
VBの最適化を信じてはいけません。
せいぜい「全然やってないわけじゃないよ」程度です。
たとえば、
a = 3
a = a + 1
は
MOV EAX,00000004h
とコンパイルしますが、
a = a + 1
は
INC EAX
ではなく
ADD EAX,00000001h
とコンパイルします。
(条件にもよりますから、常にこうなるとは限りませんが・・・。)
速度にシビアな案件ならVBを使うべきでありません。
というよりコンポーネントシステムに乗っかった言語を
使うべきではありません。
さらにいうなら低速なOSを使うべきではありません。
アセンブリコードをみたら最適化されていても、以外と一式で統一してあるのがけっこうありました。計算部分はCを使おうと思います。
Sayさん、どうもありがとうございました。
簡単なアセンブラでのご説明もどうもありがとうございました。
| ツイート |  |