「環境によって変化する値」という問題は計測プログラムを公開することでカバーしました。 いくら何でもすべての値を提示するのは不可能ですからね。 とりあえず公開の時点では最善のものを作ったつもりですが、れいさんが言われていることももっともなので今後の参考にさせていただきます。 最初に書くべきでしたが「1ナノ秒単位での計測」は誤差が少ないのをアピールするためのウリ文句で命令の厳密な処理時間を計るプログラムと勘違いされたのならばごめんなさい。 一定秒数での計測だと誤差が多めになってしまうので誤差を少なくするため一定ループ回数にかかった時間を元に計測にしたわけですが、わざわざ自作TIMER関数を使わずともMAINCNTで1671万回ループをデフォにすれば似たようなものは誰でも簡単に作れます。 それを考えればこのプログラムは特殊なものでも何でもないんですよね（笑）

れいさんへ ＞というのであれば、「ある命令」は環境Bの方が速い。 ＞それを含む「実際のプログラムの実行速度」は環境Bの方が遅い。 れいさんからその言葉を聞いて安心しました。 私が提示しているA=A+1の速度というのも私の計測環境（私が作った計測プログラム）におけるA=A+1という「プログラム」の実行速度を示しているからです。 結局、提示してある表の数値を「絶対的な値」として捉えているか「相対比較用の値」として捉えているかの違いしかりません。 絶対的な値（＝客観的に正確な値）として提示するならばれいさんが言われているように環境で変化しない値にすべきですね。 相対比較用ならばその比較に使えるレベルであれば問題ないというのが私の考えです。

MID$を覚えるというのは重要ですが、短くするのが目的ならばMID$("Version1.0",I,1);の部分は"Version1.0"[I];とすることもできますね。

スプライトで作るのもいいですが、BGが4面あるので各BGにリール1列分を割り当てて作るのもありですね。 3x3の一般的に良くあるタイプも簡単にできますし。

私は7とXPの二択ならばXPですね。 歴代Windowsならば95のが一番好きです。

れいさんへ 最頻や平均は些細な環境の変化で変わる絶対的な値ではないことは分かっています。 何度も書いているようにこれはver.3.1.0はこういう傾向があるというのを提示しただけのことでそれが分かるくらいの精度は確保できていると思います。 「これは1ナノ秒単位の限界までの高速化を行うために書いた」というのならば話は別ですが、そんなものを書いても無意味なので書く気もありません。 逆に聞きますが、「客観的な正確さ」って何でしょうか？ 例えば同じ命令を実行時に環境Aでは最速200ナノ秒だけど割り込みなどによって実際は250ナノ秒程度で動作することが多く、環境Bでは最速150ナノ秒だけど割り込み等によって300ナノ秒程度で動作することが多い場合に私は環境Aの方が速いと判断しますが、れいさんはどうでしょうか？

ループ回数が増えれば平均値を求めることでほぼ正確な最頻値が求まるというのがようやく分かってもらえて何よりです。 ループ回数に関しては最低100万回実行すれば最頻と平均にはほとんど開きがないことは確認済みです。 さすがに10万回まで減らせば多少のずれが生じますが、計測そのものが10ナノ秒単位になってしまうため今回の趣旨とは異なりサポート対象外です。 しかし、その場合であっても計測回数を増やせば最頻値は求まるため問題はありません。（当然求まるのは10ナノ秒単位ですが） 結局のところ何を求めたいのか、何に利用するのかという点が異なるためどちらが良いのかという客観的な判断はできないと思います。 「私はこの方法が良いと思った」「れいさんはその方法が良いと思った」というだけではないでしょうか。

ちなみにこれは1計測あたり500万回のループで行いました。 100万回ループだとこれより少しバラつきがあります。

ヨッシーさんへ 私も参考になる部分がたくさんありましたよ。 ヒストグラム表示を付けると良いとのことなのでA=A+1を1000回計測した結果を表示しました。 A=A+1の場合はこんな感じで平均値と最頻値はほぼ一致します。

環境の変化を与えるだけで代入処理は3％くらい高速化可能ですが、扱いが微妙なので実際はベンチにしか活用は難しいですね（笑）

しかし、環境の変化をコントロールすればこのように最初の方のA=1.0の方を速くする高速化テクニックに使えます。

プチコン3号のMAINCNTは不安定だし代入は環境にかなり依存していますね。ちなみにこのプログラムは後の方のA=1.0の方が速くなります。

コータさんへ 補足ありがとうございます。 「最速値は最頻値ではないため除外」という意味で書いたのですが、誤解される人がいるとマズいですね。

れいさんへ 丁寧な解説ありがとうございます。 私はハードに関してはそこまで詳しくないので参考になりました。 それならば私が危惧しているような問題点は無く最速が測れそうですね。 今回の件に関しては最初から最速の計測は眼中になかった」ですが、今後測る機会があれば活用させていただきたいと思います。 「3点」は後から言われてそのような解釈があることに気づきました（笑）

みきさんへ 最頻値に関しては計測回数を増やすだけで簡単に分かります。 1000回くらい計測（8秒弱×1000回）すれば概ね一定の値が求まります。 それ1回だけだとたまたまの可能性があるため条件を変えて同じようなことを数回行う必要があります。 すでに書いているように「最頻値＝平均値」ではないのですが、個人的には問題ないレベルと判断しました。 デフォの10回の計測だとその傾向が分からないですが。

ぺんこさん、ツララさんへ ありがとうございます。 前回（私の過去の活動から4月10日のものを参照）適当に計測した結果が意外に好評だったのでちゃんと参考になるレベルのものをこの度公開しました。 とはいえ、Miiverseでは文字数の関係で計測するための条件設定や計測結果の詳細や考察を端折りまくっているので本当は私のサイトの結果を見せたいくらいです。 端折りまくっているとはいえ結果として大体の雰囲気は伝わると思います。

コータさんへ ただし、プチコン3号では概ね1/60秒（ここではあえて1フレームとは呼ばない）は計測できても1/60秒単位の厳密な時間は計測できないのが難点になります。 したがって、短ければ短いほど1フレームと1/60秒との誤差が大きくなります。

（続き） 今回の結果もver.3.1.0の大体の傾向が分かればそれで問題はなく個々の計測結果の数字そのものに大きな意味はないです。 単純に考えれば同じ比率で高速化できれば同じような効果が得られそうですが、実際には5fpsが10fpsになれば体感で明らかに変わるけど30fpsが60fpsになっても体感ではそれほど大きな違いがないのに加えて元が60fpsならばそれ以上速くしてもほとんど無意味であるためです。

Newあっキーさんへ fps（処理速度）を少しでも上げるには有用ですが、無駄に配列変数を使いまくっているとか多重ループの内側で無駄な処理をしているというので無ければ極端に変わることはありません。 私も昔はポケコンでプチコン3号のナノ秒に相当するレベルまでの処理の高速化を行っていましたが、ポケコンの場合は元が遅いから高速化の効果を体感しやすいことに加えて普遍的なROM BASICであるためその機種に最適化するというのは十分に意味があることでした。 プチコン3号の場合は元が速いから多少速くなっても体感しにくいのに加え今回書いた傾向も次のバージョンアップでは白紙になってしまいかねないため「ver.3.1.0に最適化するのが目的」で無ければあまり意味はないと思います。 （↓続く）

（続き） それはたまたまかもしれませんが、大きなバラツキが出たら計測し直したり複数の測定結果の最頻値付近から大きく外れた値は省いて平均を取れば全く問題はないと判断しました。 計測実験でとんでもなく外れた値には1度もならなかったのでおかしな値は無視するという処理は上記のプログラムには入れていません。 したがって、「れいさんが考える最速の値」は私にとっては最頻値から外れた「本来ならば無視すべき値」でしかないです。