プチコン3号で処理を高速化する方法って、 ↓の他にも何かありませんか？ ・WHEEL⇒REPERT ・A⇒A% ・INC A⇒A=A+1 ・A%=A%+1⇒INC A%

WHEELって何？　は置いといて おちゃめさんの プチコン3号　プログラムの高速化手法　ナノ秒単位で処理時間を計測してみる http://ochameclub.web.fc2.com/petitcom3/lecture/speedup_nano.htm

WHILEよりもREPEATの方が早いんですか？？条件判断のタイミングが違うだけでやってること一緒だと思ってましたー(・д・) 私がよく置き換えるのは、 A*4→A<<2 A DIM 8→A>>3 A MOD 32→A AND&H1F みたいな掛け算割り算の式です。検証はしていませんが、ビット演算の方が早いらしいと聞いたので。。 でも基本的には置き換えよりも、処理の内容を見直した方が高速化効果が高いと思いますー。配列アクセスを減らすとかー。 最悪、FORを展開しちゃうという手も。。。

*4→<<2 は微妙だったような… OPTION DEFINTだと良くなるけど実数型だと微妙だった気がする

A DIM 8って何？　は置いといて 古いバージョンの頃は確かREPEATが速かった。 でも今はどうなんだろ。 古いバージョンでREPEAT中にCONTINUEすると条件判定に行かずREPEATに行ってしまうバグがあって、そのために速かったのかも知れない。

ИEX(読み方ネックスで合ってますか？)さんのツッコミが面白い。 「～って何？　は置いといて」

ИEXって何？　は置いとけない← ZEXでした。すみません。

あ、ИEXさんも居るのか。 髪型と髪色がおんなじだから紛らわしい← 確かWikiにもHanzoさんに似た名前の Handoさんが居るんだよなぁ。

おちゃめさんのサイト見てきました。 ・A%=A%+1⇒INC A% これ間違いでしたね。 INCェ…

処理の高速化の方法は多数ありますが、「これをやったら劇的に速くなる」という特効薬のようなものはありません。 私は昔はベーマガ等の雑誌に掲載のゲームプログラムを3～5倍の高速化を行っていて、それを雑誌に講座として書いたこともありましたが、高速化というのはボトルネックとなっている部分がどこかにあるのを知ることが何より重要です。 プチコン3号でポリゴンやワイヤーフレーム表示を行う場合だと配列変数の処理の遅さがネックだし、多重ループをしている場合はそのループ回数を減らしたりループ内の処理を少し減らしたりするだけで大きな高速化を望めますが冒頭に書いているような置き換えでは体感できるほどの性能向上は困難だと思います。

配列変数の読み込み回数を減らしたら、 20fps⇒40fpsになりました。 「配列の処理を減らす」のが 一番効果があるみたいですね。

アルゴリズムレベルで変えるのが一番効果があって、 二番目は実装方法の工夫 (不変式をループの外に出すなど) 最後にピープホール最適化(ぐぐれ) 配列はホント邪悪 いい加減慣れたけど、こないだ改めてビックリしたのは (1<<n)-1 より mask[n] の方が遅いってこと!! どんだけ・・・ 除算より乗算のが遅いので a 倍する代わりに aの逆数で割った方が速い。 文字列の連結は遅いので使わない push/pop/shift/unshift など配列長を変える命令も遅いから使わない。

MIKIさん» ぐぐってみたがわからなかった(´・ω・`)

VAR関数は、便利だけど配列より遅かった気がします。

ピープホール(のぞき穴)ってことで、局所的な最適化です。4倍を<<2で書き換えるとかはこの類。 うえこうさん、ごめん、減らす命令は大丈夫かもしれません(未確認)。 push の代わりに、一度に 1024 個とか追加して、足りなくなったらまた一気に増やす。 毎回毎回一つずつ増やすのが最悪のパターンです。 var 関数とか、実行時に文字列からシンボルテーブル引くわけだからますます遅くなります(普通の変数はコンパイル時にシンボルテーブルを引く)。goto などのラベルに文字列変数使うのも同様に遅くなるはず。

文字列の連結 s$="" while 1 for i=0 to 999 s$=s$+"." next ? "."; wend これ実行すればどんどん遅くなるのが実感できるでしょう。 prgset も同様です。 文字列は適当な単位(改行までとか)で区切って、文字列配列にどんどんつめて行くのがいいです。その時も push じゃなくて、上の技法使うんですよ。

今確認したけど push は実用的な速度を維持できるみたいですね。 > push/pop/shift/unshift など配列長を変える命令も遅いから使わない。 これ撤回します。申し訳ない。

+（加算）、-（減算）と比べて遅かったINCやDECが配列変数で使用時には参照回数を1回に減らせるため高速化が可能だったのと同じ原理ですね。（プチコン3号の文字列は内部では配列で処理されているみたいだし）

ちなみに、 アルゴリズムごと変えるってのは、 計算方法を変えるってことかな。 別の計算方法…思い付かない。 「配列変数の読み書きを減らす」 　↑これさえ頭に入れとけば、 あとはなんとかなりそうな気がする。

あ、なるほど。 普通に考えただけで大丈夫「そう」ですね。

高速化したプログラムを公開しました。 詳しくはお気に入りの1枚へ。 更なる高速化の意見求む！

アルゴリズム、わかりやすいのはソートですね。 単純比較、バブル、クイックソート、バケツソート、スパゲッティーソート、ボゴソートなどなど。それぞれ長所短所があります。

>incは配列だね。 今気が付いたんですけど、 A[0]=A[0]+1⇒INC A[0] ってことですか？

その通り!! inc は +1 より遅いんだけど、配列は最強の遅さなので v[0]=v[0]+1 vs inc v[0] では 前者が配列を二回評価するため、 一度しか評価しない後者よりも遅くなります。 inc が引数を二回評価してた過去のバージョンでは inc の方がおそくなってたのではないかな?

> 今確認したけど push は実用的な速度を維持できるみたいですね。 更に定量的に確認。 option defint var n=1<<19,v[0],w[n],u,i,t0 t0=millisec: for i=1 to n: push v,i: next: ? (millisec-t0)/1000 t0=millisec: for i=1 to n: w[u]=i: u=u+1: next: ? (millisec-t0)/1000 結果 5.965 3.714 push は後者より 1.6 倍遅い。 後者が激遅キングの配列を使ってることを考えると、push の遅さも大概ですね!!

手元にあるver.3.0.0のプチコン3号（旧3DS）で計測してみました。 A[0]=A[0]+1 平均9069ナノ秒 INC A[0]　平均9104ナノ秒 《参考》 A=A+1 平均1145ナノ秒 INC A　平均1148ナノ秒 両者には0.3％程度の速度差があるのですがこの程度は計測誤差と考えられるためA[0]=A[0]+1もINC A[0]もほぼ同等の速度と言えるでしょう。

おお、検証ありがとうございます。 やはり二度評価すると遅くなりますね。 この修正前のやつってとても不思議な感じがして、 いわば「inc v[e]」を内部的には「v[e]=v[e]+1」として処理してるってことなんですよね。 それって、例えばプリプロセッサを使うなら簡単に実装できるけど、コンパイラレベルでやろうと思うと、わざわざそんな事するより、inc 命令を真っ当に実装した方がよほど簡単だと思うんですよね。 どんな風にコンパイルしてる(してた)のかとても気になります。

皆さんコメントありがとうございました。 このトピックはまだ閉じない方が良いですかね?

新しいトピックを思い付いたんで、 ここ閉じますね。ありがとうございました！ 「プチコン3号に学習させてGAME3をクリアする。」