プチコン3号 プログラムの高速化手法

ナノ秒単位で処理速度を計測してみる

 プチコン3号はプチコンmkIIと比べると20〜30倍程度(New3DSで動作時)速くなっていて速度面で不満に感じることは少ないですが、それでも「少しでも速くしたい」という場合もあることでしょう。プログラミングにおいて処理速度の向上はアルゴリズムの改善などによって大幅な高速化も可能になりますが、全く同じアルゴリズムでも例えば整数しか使わない場合は整数演算によって高速化が可能になったりします。
 しかし、プチコン3号では「整数演算は思ったほど速くない」という意見も結構見られるためその辺を検証してみることにしました。検証するためには一定の回数ループさせてそれにかかった時間を計測する必要があります。通常は1フレーム単位でインクリメントするシステム変数MAINCNTを使って計測するのですが、それだと1フレーム(1/60秒)秒単位でしか計測できません。
 そこで私が作った1ミリ秒(1000分の1秒)単位でインクリメントするTIMER()関数を使うことにしました。これを使って100万回ループによる時間を計測すれば1回当たりの処理にかかる時間を1ナノ秒単位(10億分の1秒単位)で計測可能になります。「ナノ秒」という単位を使うことで「ループ○○回行った時に××フレーム」という表記をせずに済むしその場合にはループそのものにかかった時間を含むか否かの注釈、FOR〜NEXT以外のループを使用した場合もその注釈を入れたりする必要もなくなります。TIMER()関数についてはこちら(Miiverseの私のコメントへのリンク)をご覧になってください。
 もちろん、実行時間をループ回数で割るだけの単純な計測プログラムなのでMAINCNTを使っても1ナノ秒単位での計測は可能です。その代わりTIMER()関数よりも多くのループ回数(1671万回くらい)が必要になります。(1秒単位の3DS内蔵時計を使っても10億回ループをデフォにすれば1ナノ秒単位で計測は可能)

※正しくは「1ナノ秒単位で時間を計測する」プログラムではなく「(計算によって)1ナノ秒単位で計測結果を表示する」プログラムです。仕組みは単純ですが、1ナノ秒単位で発生する微妙な計測誤差も可能な限り削減しています。 → 詳しくはこちらを参照


ナノ秒単位で処理時間を計測するプログラム



 そのナノ秒単位での処理時間計測を実現するのがこの「処理時間計測プログラム」です。


 公開コード【 43351483 】 公開コードは随時変更しています

 まず、このプログラムの使い方を説明します。10行目の注釈文の所に計測したい処理(例えばA=A+1など)を記述して実行するだけでデフォ設定の場合は10回の計測を行いそれにかかった時間の平均を表示します。
 このプログラムではループにかかった時間を除外して処理そのものにかかる時間を表示します。そのため「ループにかかる時間」というのがどれくらいかを計測する必要があります。このプログラムでは2行目の末尾にあるR=953がその時間になります。ループ回数をデフォの100万回でNew3DSでプチコン3号 ver.3.1.0起動させた直後に動作させた場合の時間であるためそれと合致すれば再計測の必要はないのですが、それ以外の環境で動作させるためには再計測の必要があります。(プチコン3号は実行するたびに変数が自動的に初期化されますが、その処理が完全ではないため起動してからの時間が経ち多くのプログラムを実行していると変数の代入や読み出しの速度が変わってくるので時々空ループを実行してその補正値で誤差がほぼ0になっているのかを確かめるのがベター)
 ループにかかる時間の再計測はループ内に何も処理を書いてない状態でLボタン、または、Rボタンを押しながらこのプログラムを実行するだけです。その結果、例えばループのみに平均3500ナノ秒かかったとしたらR=3500と書き直すことでループにかかる時間を除外してくれます。自動的にループにかかる時間を取得させることも可能ですが、毎回実行時に何10秒も待つのは面倒だし、補正値とのずれが大きくなったときに自動的にループを再計測というのも可能ですが、そのためには毎回セーブ、ロードの必要性があるため現状の方式がベストだと判断しました。(ちなみに3500という補正値はver.3.0.0が入った旧3DSでの値です)

 このプログラムで注意すべき点はTIMER()関数の仕様上(8秒に1回はTIME()関数を呼び出さないと正常にカウントできないため)連続8秒以上の時間は計測できません。そのため1計測あたり8秒以下に抑える必要があります。8秒を超えた場合にはエラー表示を行うためそれを参考にしてみてください。
 しかし、デフォの100万回のループでは8秒を超えてしまうという場合にはループ回数を減らす必要があります。ループ回数の変更は4行目のK#の値を変えてください。ただし、ループ回数を減らすと計測精度が落ちてしまいます。逆にいえば速度に余裕がある場合は8秒の限界までループ回数を増やせば精度がアップします。(ループの補正値と処理にかかる時間を8000ナノ秒までに抑える必要があるためNew3DSでも200〜300万回へとループ回数を減らした配列変数などは旧3DSだと100万回では厳しい)
 TIMER()関数の仕様上どうしても計測結果にはバラツキが出てしまう(バラツキを小さくするためにはループ回数を増やすしかない)ので複数回の平均を求めることでそれを改善しています。デフォでは10回の計測となっています。より多くの計測をした方が精度がアップしますが、ループ回数が少ない状態で計測回数を増やすのは安定した値を得ることができないため計測回数10回より増やすならばまずはループ回数を増やすことを優先してみてください。
 OPTION DEFINTを実行時の速度を計測する場合は1行目の注釈を取ってください。OPTION DEFINTでの実行を考慮してループでは意図的に実数型を表す#を付けています。OPTION DEFINTは置いた場所以降のものが有効になるためすべての変数を整数型にするためには1行目に置く必要がある)

 以下の検証には計測回数(N)10回、ループ回数(K#)500万回、補正値(R)4767でNew3DSにてプチコン3号 ver.3.1.0を動作させた場合の値を示しています。(処理時間がかかり500万回のループでは8秒を超えてしまうものは300万回へとループ回数を減らし、300万回でも8秒を超えてしまうものは200万回へとループ回数を減らした)
 なお、この回数でもわずかな誤差は発生するため1〜2ナノ秒程度は誤差の範囲として考えてください。また、MAINCNTが正確な1/60秒単位ではないのと同じくTIMER()関数も正確な1/1000秒単位ではないためこの計測結果が絶対的に正しいものではなく相対比較のための目安として考えてください。

 ちなみにこのプログラムを使ってA=A+1の500万回ループを1000回計測した結果をヒストグラム表示したのがこちらです。



 こんな感じでループ回数を増やせば平均値付近の値が出やすくなるため結果が安定します。(※上記プログラムにはヒストグラム表示機能はありません)


(1) 整数型と実数型の速度の違い



最も基本的な実数型であるA=A+1(デフォでは#を付けなくても実数型となっている)と整数型であるA%=A%+1の比較をしてみます。(以下の処理の時間は特別に明記していない限りはすべてNew3DSでプチコン3号 ver.3.1.0を動作させた場合の数字です)

実数型
整数型
速度向上率
A=A
302ナノ秒
A%=A%
305ナノ秒
-1
A=A+1
345ナノ秒
A%=A%+1
330ナノ秒
+5
「+1」の部分
43ナノ秒
「+1」の部分
25ナノ秒
+72
※比較対象より速くなっている場合は青文字、遅くなっている場合は赤文字で表記しています。

 これを見ての通り、単純なインクリメントの場合では整数型は実数型と比べて5%くらいしか速くなっていません。その理由は代入処理が遅いためです。A=AA%=A%という代入処理にかかる時間を除外して純粋に加算処理のみにかかる時間を見てみると実数型は43ナノ秒、整数型は25ナノ秒で約1.7倍速くなっているのです。
 つまり、「整数型があまり速くない」というのは正しくなくて代入処理(がボトルネックとなって結果として整数型はあまり速くならないだけです。


(2) インクリメント専用命令INCとA=A+1の速度の違い



 プチコン3号ではmkIIまで無かったINCでインクリメントを行うことが可能です。これを使えばA=A+1INC Aと表記できます。専用命令であるため処理速度の向上が期待できそうですが、果たしてどうなのでしょうか?

通常表記
INC命令
速度向上率
A=A+1
345ナノ秒
INC A
578ナノ秒
-40
A%=A%+1
330ナノ秒
INC A%
582ナノ秒
-43
A=A+1
OPTION DEFINT使用時
330ナノ秒
INC A
OPTION DEFINT使用時
582ナノ秒
-43

これを見ての通り、1を単純加算するインクリメントの場合では「A=A+1よりINC Aの方が速そう」という予想とは真逆の結果になっています。ただし、これはver.3.1.0において言えることで初期バージョンver.3.0.0が入った旧3DSではA=A+1INC Aも約1135ナノ秒で速度面の違いはほぼなかったためINCは遅いというのは今後変わるかもしれません。


(3) 整数値と実数値の演算速度の違い



プチコン3号では整数値同士の演算では自動的に整数演算が行われています。例えばDIRCTモードでPRINT 65536*65536を計算すると0になることからそれが分かると思いますver.3.2.0以降は整数型の範囲を超えた場合には自動的に実数型で計算するようになった)。定数を整数値で指定する時にそれが実数であるとプチコン3号に分かるようにしてあげるためには「1」を「1.0」のように表記すれば良いです。
 それでは「1」と「1.0」で速度に違いがあるのかを確かめてみます。

整数値
実数値
速度向上率
A=1
270ナノ秒
A=1.0
301ナノ秒
-11
A=A+1
345ナノ秒
A=A+1.0
381ナノ秒
-9
A%=1
260ナノ秒
A%=1.0
355ナノ秒
-37
A%=A%+1
330ナノ秒
A%=A%+1.0
413ナノ秒
-25
A=1
OPTION DEFINT使用時
259ナノ秒
A=1.0
OPTION DEFINT使用時
353ナノ秒
-36
A=A+1
OPTION DEFINT使用時
330ナノ秒
A=A+1.0
OPTION DEFINT使用時
415ナノ秒
-26

 整数値を加算するA=A+1A%=A%+1を比較した場合には整数型の変数を使った方が高速でした。しかし、実数値を加算するA=A+1.0A%=A%+1.0を比較した場合には逆に実数型の変数を使った方が高速になっています。  なぜこのようなことになるのかというと整数型変数に実数の値を入れた場合には型変換が行われるためその処理に時間がかかっているためだと推測されます。それは代入処理にかかる時間を見てみると明らかです。A=1A%=1では後者の方が10ナノ秒速いですが、A=1.0A%=1.0では前者の方が54ナノ秒も速くなっています。つまり、型変換の時間だけで60ナノ秒程度かかっていると考えられます。
 ちなみに整数型であるA%=A%+1OPTION DEFINTを実行してサフィックス記号(%)を省略したA=A+1では明確な速度差はありませんでした。(これは後述のように事前に仮想マシンコードに変換されているためだと思われる)


(4) 四則演算の演算速度の違い



普通に考えれば加算、減算と比べて乗算、除算は遅いことが予想されます。では、どの程度遅いかを確かめてみることにしましょう。
整数値
速度低下
実数値
速度低下
A=B+5
345ナノ秒
A=B+5.0
382ナノ秒
「+5」の部分
43ナノ秒
基準値
「+5.0」の部分
54ナノ秒
基準値
A=B-5
343ナノ秒
A=B-5.0
356ナノ秒
「-5」の部分
41ナノ秒
-5
「-5.0」の部分
42ナノ秒
-22
A=B*5
559ナノ秒
A=B*5.0
523ナノ秒
「*5」の部分
257ナノ秒
+498
「*5.0」の部分
275ナノ秒
+409
A=B/5
402ナノ秒
A=B/5.0
417ナノ秒
「/5」の部分
100ナノ秒
+132
「/5.0」の部分
115ナノ秒
+113
Bの値が5の場合の計測値

 これを見ると減算は加算と比べてわずかに速く乗算は極端に遅いことが分かります。乗算は除算と比べても大幅に遅いため「実数型が整数型よりも遅い」というのを加味してもA=B*5A=B/0.2とした方が高速になります。(ちなみにA=B/0.2415ナノ秒)  ここまで乗算が遅いのはINC AA=A+1と比べて大幅に遅いのと同じく不可解な部分ですが、これもver.3.0.0が入った旧3DSで計測してみたら乗算が1305ナノ秒、除算が1755ナノ秒で乗算の方が速かったため今後のプチコン3号のアップデートによって変わる可能性は十分に考えられます。


(5) 定数と変数の演算速度の違い



 普通に考えれば定数で済む部分を変数で記述すると遅くなりそうです。では、どの程度遅くなるのかを確かめてみることにしましょう。

整数値 Cの値は5
速度低下
定数との比較時
実数値 Cの値は5.5
速度低下
定数との比較時
A=B+C
349ナノ秒
+1
A=B+C
364ナノ秒
-5
A=B-C
354ナノ秒
+3
A=B-C
368ナノ秒
+3
A=B*C
482ナノ秒
-14
A=B*C
495ナノ秒
-5
A=B/C
421ナノ秒
+5
A=B/C
432ナノ秒
+3
Bの値が5の場合の計測値

 これを見ると差異はあるものの変数を使うことで定数と比べて3%前後遅くなっています。ただし、乗算では整数値でも実数値でも逆に速くなっているという点です。特に整数値においては約80ナノ秒も速くなって誤差というにはあまりに大きな差なのですがこれもver.3.1.0でのみ言えることです。これは今後のバージョンアップで変わる可能性がありますが、ver.3.1.0の時点では乗算を除算を使って記述したくないという人は一旦変数に入れると高速化を行うことが可能ということです。(より高速化するためには乗算を使わずすべて除算で記述するのがベター)


(6) 変数名の長さによる演算速度の違い



 変数名が長くなればなるほど遅くなるというイメージがある人もいることでしょう。では変数名が速度に与える影響がどの程度あるのかを調べてみました。

A=A+1
345ナノ秒
AB=AB+1
345ナノ秒
ABC=ABC+1
345ナノ秒
ABCD=ABCD+1
345ナノ秒
ABCE=ABCE+1
345ナノ秒

 1文字から5文字までは変数名の文字数による影響はありませんでした。もしかしたら文字数が増えたら目に見える影響があるかもしれないと思いABCDEFGHIJKLMNOPQRSTUVWXYZ=ABCDEFGHIJKLMNOPQRSTUVWXYZ+1を計算しても345ナノ秒で変化はありませんでした。したがって、変数名の文字数による演算速度の差はないと言えるでしょう。  これはプチコン3号がリアルタイムの構文解析ではなく実行前に仮想マシンコードへと変換しているためだと推測されます。注釈や改行を大量に入れた場合には普通ならばわずかな速度低下が見られるのですが、仮想マシンコードへあらかじめ変換されるためプチコン3号では注釈や改行を入れることによる速度低下もありません。


(7) 通常変数と配列変数の速度



 配列変数は便利ですが、配列変数ではない通常の変数と比べて遅いです。どの程度遅いのかを調べてみました。

通常変数
配列変数
速度低下倍率
A=1
270ナノ秒
A[0]=1
1038ナノ秒
3.84
A[B]=1
1136ナノ秒
A=A+1
345ナノ秒
A[0]=A[0]+1
2451ナノ秒
7.10
A[99]=A[99]+1
2451ナノ秒
A[B]=A[B]+1
2508ナノ秒
A=B
302ナノ秒
A[0]=A[1]
2109ナノ秒
6.98
A=A+B
349ナノ秒
A[B]=A[B]+A[C]
3541ナノ秒
10.15
B=A[0]
1182ナノ秒
A[0]=B
1182ナノ秒

 これを見ると配列変数は通常変数と比べて概ね7〜10倍遅くなっています。一般的に配列変数は遅くなりがちなのでこの数字がどうなのかはプチコン3号単体データを見ても分からないため前作のプチコンmkIIでの計測データを書いておきます。
 プチコンmkII(最終バージョンであるver.2.3においては、A=B12388ナノ秒、A=A+116387ナノ秒、A=A+B19079ナノ秒、A[0]=A[0]+129321ナノ秒、A[B]=A[B]+139382ナノ秒、A[B]=A[B]+A[C]40394ナノ秒となりました。MAINCNTLで1ナノ秒単位の数字を出すため1670万回ループで計測)
 プチコン3号はmkIIに対してA=A+1は、47.5倍速いのですが、A[0]=A[0]+112.0倍しか速くありません。確かに速いのですが、その比率が1/4になっていますね。(全くの余談ですが、最速クラスのポケコン(PC-E650)でさえA=A+1は約3.1ミリ秒(=約3100000ナノ秒)かかるためNew3DSで実行時のプチコン3号はその約9000倍の演算速度となっています)
 配列変数の通常変数に対する速度低下倍率を見るとA[0]=A[0]+1はプチコン3号が7.10倍、プチコンmkIIは1.79倍、A[B]=A[B]+A[C]はプチコン3号が10.15倍、プチコンmkIIは2.46倍でこの数字を見るとプチコン3号の配列変数の遅さは異常と言えるでしょう。これは読み出し速度が遅いのが原因なのですがPUSHPOPで要素数を自由に変更できたりとかの高性能化の代償かもしれませんね。(プチコン以外の環境だとポケコン(PC-E650)の場合で2〜3倍くらい配列変数の方が遅くなっている)
 これは逆に言えば配列変数をいかに減らせるかが高速化においては非常に有用になると言えるでしょう。

 旧来のBASICでは三角関数が遅くて配列変数にあらかじめ演算結果を入れておくといういわゆるテーブル処理はポピュラーな高速化テクニックだったのですが、プチコン3号ではA=SIN(X)595ナノ秒で配列変数からの読み出しよりも三角関数を普通に計算した方が速いという逆転現象が起きています。テーブル化の場合にはラジアンへの変換もあらかじめやっておくことが可能なのですが、A=SIN(RAD(X))としても898ナノ秒でラジアンへの変換を行ったとしても配列変数からの読み出しよりも速いです。


(8) 使われている演算子の数の違いにおける演算速度の違い



 加算となる演算子「+」の処理が
上記(4)では1回43ナノ秒と推測されているのですが、複数の演算子が含まれた式を記述したらどうなるのかを調べてみました。

A=1
270ナノ秒
A=1+2
339ナノ秒
A=1+2+3
627ナノ秒
A=1+2+3+4
878ナノ秒
A=1+2+3+4+5
1128ナノ秒

 これを見ると演算子が1つ増えるごとに演算子そのものの処理時間よりも多くの時間がかかっています。演算子「+」が1つ増えるごとに概ね250ナノ秒程度の処理時間増になっています。これは加算に限らず複数の演算子を使った場合には一度に計算というのは無理なので順番に処理していき1つ演算子の処理を行うごとにスタック用のメモリにその結果を書き込んでいるためだと思われます。
 したがって、代入処理が遅いからといって高速化を行うために式が複雑化してしまうと逆効果になってしまうということです。同じ演算を複数回行っているならばあらかじめ別の変数に同じ部分の処理をしたものを代入しておき式を単純化する方が高速化される場合があるわけです。


(9) グローバル変数とローカル変数の速度の違い



プチコン3号ではDEFEND内でグローバル変数をローカル変数を使い分けることができます。(変数を宣言、もしくは最初に使われた場所でローカル変数かグローバル変数かが決まる)

DEF外
グローバル変数
DEF内
グローバル変数
ローカル変数
A=1
270ナノ秒
274ナノ秒
310ナノ秒
A=B+5
345ナノ秒
370ナノ秒
365ナノ秒
A=B-5
343ナノ秒
366ナノ秒
372ナノ秒
A=B*5
559ナノ秒
556ナノ秒
552ナノ秒
A=B/5
402ナノ秒
442ナノ秒
440ナノ秒

 DEFで自作関数にしたら普通に処理するよりも遅くなるのですが、これを見る限りでは確かに同じグローバル変数であってもDEF内はDEF外と比べてわずかな速度低下が見られます。加減算はそれほど変わりませんが除算に関しては誤差というには大きな差があります。
 グローバル変数とローカル変数で見るとどうなのかというと微妙な差こそあれこれで傾向を見るのは難しいです。そこで演算速度ではなく変数の読み出しや書き込み速度に差異があるのではないかと思いDEF内における代入速度の比較をしてみました。

グローバル変数 ← グローバル変数
345ナノ秒
グローバル変数 ← ローカル変数
346ナノ秒
ローカル変数 ← グローバル変数
360ナノ秒
ローカル変数 ← ローカル変数
373ナノ秒

 これを見ると同じA=Bというただの代入であっても変数A、変数Bがグローバル変数かローカル変数かで1割程度の速度差が発生していることが分かるでしょう。これを見る限りではローカル変数の方がグローバル変数よりも若干遅いと言えます。

 DEFが遅いというのはローカル変数が遅いというだけではなくもっと根本的な部分にあります。それはDEF命令そのものの処理時間が大きいためです。
 引数無しで中身が空白のDEF Z ENDというZ命令を定義してみたところその命令の実行には3161ナノ秒かかりました。つまり、DEF内の処理が仮に3000ナノ秒だったとしてもそれをDEFで定義して自作命令として使えば2倍くらい遅くなるわけです。DEF内での処理が少なければ2倍どころではなく遅くなるし、多ければ数割遅くなる程度に止まる)
 DEFで遅くなる要因としては引数があります。これは概ね引数が1つ増えるごとに260〜270ナノ秒程度(最初の1つ目は460ナノ秒程度)遅くなります。これは引数が増えるということは定義されているローカル変数への代入処理が加わるためやむを得ないでしょう。
 限界まで高速化するならばDEFは使用しないということになるのですが、利便性を考えるとなかなか難しいところです。


(10) 文字列変数の処理速度の違い



 今までずっと数値変数の処理時間を測定してきましたが、最後に文字列変数の速度を書いておきます。

A$=""
419ナノ秒
A$="1"
426ナノ秒
A$=B$
(B$="1"の場合)
426ナノ秒
A$=B$
(B$="1"*100000の場合)
427ナノ秒
A$=B$+"1"
1146ナノ秒
A$="1"*2
1390ナノ秒
A$="1"*10
1694ナノ秒
A$="12345"*10
3095ナノ秒
A$=B$[0]
(B$[0]は通常変数の場合)
1578ナノ秒
A$=B$[0]
(B$[0]は配列変数の場合)
1826ナノ秒
A$=B$[0][0]
(B$[0]は配列変数の場合)
2992ナノ秒
A$=B$[0,0]
2194ナノ秒

 文字列変数は全体的に数値変数よりも重めですが、代入に関しては文字数はほとんど影響がありません。文字列の演算はかなり重く掛け算に関しては演算結果の文字数が多くなればなるほど処理に時間がかかります。
 文字列変数では添え字を付けることで通常変数であっても配列変数のような使用が可能ですが、配列変数よりは若干処理が軽いので1文字ずつ取り出すならば積極的に使っても良いかもしれません。(変数そのものの読み出し速度向上よりもMID$などが不要でありリスト短縮や速度向上に繋がることの方が大きい)
 ただし、添え字を2つ付けるくらいならば2次元配列の方が速くなります。


あとがき



 今回は四則演算や変数に注目してその処理速度を計測したわけですが、予想外のものが結構ありました。ただし、この処理速度はあくまでver.3.1.0においてのみ言えるもので今後のバージョンアップで変わる可能性があります。(乗算に関してはver.3.1.0でやたら遅くなったので今後変更の可能性は十分にある)
 現状のバージョンで可能な限り速くしたいという人にとっては有用になるかもしれないですが、それでもナノ秒単位で高速化しても体感レベルの速度向上を得るのは非常に厳しいです。というのも1フレームは概ね1671万ナノ秒だからです。つまり、30fpsのゲームを60fpsで動作するようにしたい場合には1600万ナノ秒以上高速化する必要があります。
 とはいえ、これが深い階層のループでメインループ1回あたり数千、数万回繰り返している処理ならば1000ナノ秒の高速化は数100万、数1000万ナノ秒の高速化に繋がります。したがって、多重ループの内側においては今回書いたことを元にすれば体感できるレベルの速度向上が可能になるかもしれません。しかし、それ以外だとベンチで数値化しないと分からないレベルの速度向上に止まると思います。やはり、高速化を行うならばアルゴリズムの改良など処理そのものを見直すということの方が重要になると思います。
 今回の結果は「○○の処理が××ナノ秒である」ということが言いたいのではなくver.3.1.0は概ねこういう傾向にあるというのが分かれば良いのではないかと思います。(絶対的な数値よりも相対的な数値の方が重要)

《追記》
 プチコン3号 ver.3.2.0では上記の表の数字と比べてかなり変わっています。実数演算においては全体的に大幅な向上(演算内容によって差異はあるものの概ね2割前後の速度向上)が見られますが、整数演算においてはあまり向上は見られません(数%の速度向上)。したがって、場合によっては同じ演算を行っても実数演算より整数演算の方が遅いという逆転現象も起きています。(上記の「処理時間計測プログラム」ではA=A+1よりもA%=A%+1の方が遅いという結果になっている。私の「処理時間計測プログラム」が信用できないという人はFOR I=1 TO 10000000:A=A+1:NEXTFOR I=1 TO 10000000:A%=A%+1:NEXTの処理時間を比較してみてもいい。)
 実際にどの程度変わったのかはここでは書きませんので自分の目で確かめて見てください。


RETURN (プチコン3号講座のページにもどる) RETURN *MAIN (トップページにもどる)

inserted by FC2 system