1ナノ秒単位で処理速度を計測するプログラムを作ったのでこれを使ってプチコン3号の様々な処理速度をまとめてみました。

使用方法 10行目に行いたい処理を記述してください。 ループにかかる時間を除外して処理にかかる時間のみを表示しているのですが、そのためにはループにかかる時間が分からなくてはなりません。 5行目のR=953というのがNew3DSでver.3.1.0を動作させたときにループの時間です。 これ以外の環境では正しく補正を行うため計測部分に何も記述してない状態でLボタンもしくはRボタンを押しながら実行すると空ループの時間が計測できます。 そのかかった時間を5行目のRに入れてください。 例えば空ループが3500ナノ秒ならばR=3500とします。

あとは好きな処理を計測しても良いのですが、TIMER関数の仕様上連続で8秒以上の時間は計測できないため重めの処理で1回の計測が8秒を越えてしまう場合にはループ回数をデフォの100万から減らしてください。（8秒を越えた場合にはエラー表示を行っています） その場合は補正値も変更する必要があります。 ループ回数を増やせば計測結果が安定し減らせば不安定になるため可能な限りは100万回より減らさない方が望ましいです。 ループ回数は4行目のK#の値、計測回数はNの値を変えると変更できます。 先日書いた処理時間はループ回数100万回、（計算を暗算で済ませるため）計測回数3回で行いましたが誤差が大きかったのでループ回数500万、計測回数10回で改めて計測して再検証してみました。 最後に表示される平均値を記述しましたがこの試行回数でも1～2ナノ秒は誤差の範囲として考えてください。

1　整数型と実数型の速度の違い A=A・・・302ナノ秒 A=A+1・・・345ナノ秒 「+1」の部分が43ナノ秒 A%=A%・・・305ナノ秒 A%=A%+1・・・330ナノ秒 「+1」の部分が25ナノ秒 結果：整数型の方が1.7倍くらい速いけど代入処理が遅いので実質5％しか速くなっていない。

2　インクリメント専用命令INCの速度 INC A・・・578ナノ秒 INC A%・・・582ナノ秒 INC A・・・581ナノ秒（OPTION DEFINT時） 結果：INC Aは速そうだけどver.3.1.0においてはINC AはA=A+1より遅い（ver.3.0.0ではINC AとA=A+1は同じ速度）

4　四則演算の速度 A=B+5・・・345ナノ秒 A=B-5・・・343ナノ秒 A=B*5・・・559ナノ秒 A=B/5・・・402ナノ秒 結果：なぜか乗算だけ極端に遅い（ver.3.0.0では乗算は除算よりも速い）

5　定数と変数の演算速度の違い A=B+C・・・349ナノ秒 A=B-C・・・354ナノ秒 A=B*C・・・482ナノ秒 A=B/C・・・421ナノ秒 結果：変数の方がわずかに遅いけど乗算のみ定数より変数の方が速くなっている　 それでも乗算は逆数を除算で計算した方が速い。

6　変数の文字数による速度の違い A=A+1・・・345ナノ秒 AB=AB+1・・・345ナノ秒 ABC=ABC+1・・・345ナノ秒 ABCD=ABCD+1・・・345ナノ秒 ABCDE=ABCDE+1・・・345ナノ秒 結果：変数名の文字数による処理速度の違いはない これは仮想マシンコードへとあらかじめ変換されている影響と思われる。（注釈や改行による処理速度の影響もない）

7　配列変数の速度 A=A+1・・・345ナノ秒（16387ナノ秒） A[0]=A[0]+1・・・2451ナノ秒（29321ナノ秒） A=A+B（19070ナノ秒） A[B]=A[B]+A[C]（40394ナノ秒） カッコ内はプチコンmkIIの速度 結果：配列変数を使った処理は通常変数より7～10倍も遅い（比率でいえばプチコンmkIIより4倍くらい遅い）

7（続き） A=B[0]・・・1182ナノ秒 A=SIN(X)　595ナノ秒 A=SIN(RAD(X))　898ナノ秒 配列変数が超遅いため三角関数はあらかじめ計算した結果を配列変数から読み出すより普通に計算した方が速い 三角関数の演算は四則演算と比べるとかなり遅いため配列変数にあらかじめ計算した結果を入れておいてそのテーブルから読み出すという使用方法は昔のBASICではよく使われた。 しかし、三角関数の演算そのものは配列の読み出しより速くRADを使って度に変換しても配列変数の読み出しよりも速い。

8　複数の演算子が使われている場合の速度 A=1+2・・・339ナノ秒 A=1+2+3・・・627ナノ秒 A=1+2+3+4・・・878ナノ秒 A=1+2+3+4+5・・・1128ナノ秒 結果：定数の加算でも1つ追加するごとに250ナノ秒くらい増になるため代入を減らすため式が複雑化するとかえって遅くなる場合がある。

9　グローバル変数とローカル変数の速度 DEF内グローバル変数 A=1・・・274ナノ秒 A=A+1・・・374ナノ秒 ローカル変数 A=1・・・310ナノ秒 A=A+1・・・366ナノ秒 結果：DEF内は代入処理が遅いので結果としてDEF内では処理速度が遅くなる。 ただし、実際に自作関数が遅くなる要因はDEFそのものが3161ナノ秒かかっていることの方が大きい。

10　文字列変数の速度 A$=""・・・419ナノ秒 A$=B$・・・426ナノ秒 （B$="1"*100000の場合） A$="1"*2・・・1390ナノ秒 A$="1"*10・・・1694ナノ秒 結果：演算速度は文字数に大きく左右される。ただし、代入処理は文字数の影響はほとんどない。

長々と書きましたが私のサイトではこれより格段に詳細な計測結果の発表を行っています。 この結果を元にしてより速いプログラムを作れば大幅に高速化されるかというと実際は多重ループの内側でない限りは目立った高速化は難しいかもしれません。 しかも、乗算の速度やINC Aなどはこのバージョンに依存していると思うのでver.3.1.0に最適化するメリットはあまりないと思います。 やはり、高速化はアルゴリズムの改善などで行うべきでしょう。

3点。 8秒までしか測れないのなら「一定秒数の間に実行できた回数」を計った方がいいのでは？ 命令によってループ回数かえるのめんどくさい。 「平均」ではなく「最速」を求めるべきでは？ 命令の実行速度が変わる理由はいろいろあるだろうけど、内部で特別にショートサーキット等組まれていなければ、割り込みなどで遅くなるだけ。 なら、最速の値のほうが命令の実行速度の真の値に近いはず。 MICPOS命令はDSPとCPUのキューの都合で、 まとめて進んだりしばらく増えなかったりするけどそれの対策は？

追記。 MICPOSみたいなキューの遅延は冪分布になる場合が多いので、平均をとる意味がないかと。 ヒストグラム描いて分布関数を見せたほうがかっこいいし正しいんじゃないかね

れいさんへ BASIC上で動作している限り様々な要因が絡んだ上での実行速度なので真の値なんてそもそも測定は不可能です。マシン語のような正確なサイクル数は求められないので遅いときと速いときの平均値がベターだと私は判断します。 平均である以上はある程度の回数をこなせばMICPOS命令の問題は緩和されます。 そもそもMAINCNTLでさえ安定していないため厳密な時間は測定は不可能です。 命令によってループ回数をわざわざ変えなくてもいいですよ。 New3DSならばほぼ500万回ループで実行可能でしたし。 れいさんが理想とする測定プログラムを自分で作ってその結果を報告してください。

冪分布だと平均とっても緩和されないっていう話をしているんだが、まぁいいか。 マシン語も近代的な設計だと正確なサイクル数が求まらなくてイラッとするよね

例えば50回や100回に1度しか出ないかもしれない真の値（っぽい値）よりも普通に実行時に出る値の方がよほど現実的ですね。

ぐるぐる回してとった実行時間が「普通に実行時にでる値」かどうかは微妙じゃないかね？ PCでもスパコンでもなんでも、ベンチマークの類を考えるときにいつもある問題で。 様々な要素が入って実行時間が決まる。 不確定な要素はたくさんあって、どう計ったらいいのかわからない。 そういうときに、何を持って「実行時間」と言うか、どういう方針にするかっていうだけ。 「現実的な値」を目指すならプチコンにおいてより現実的な、ゲームかなにかの実行速度を計るのがより現実的だし。 「単命令の速度」を計りたいのであれば最速の条件を見るのが理想的。

誤差の問題はループ回数である程度カバーできます。 したがって、8秒という時間制限がある以上は旧3DSよりもNew3DSの方がより正確な結果（安定した結果）を求めることが可能になります。 今回の結果よりも正確に測定したいのであれば不安定なMAINCNTLではなく内蔵時計を使い10000秒とか100000秒での実行回数を計測すると良いでしょう。（それでも計測誤差を考えると最低でも3回は試行しなくてはならない）

そもそも、1ナノ秒単位になると回数をカウントする処理でさえ誤差の問題が発生します。 実際このレベルになるとFOR～NEXTのループでさえ回数と時間は比例関係にはありません。（500万回ループは100万回ループのちょうど5倍の時間ではない） プチコンの処理に依存しない正確なカウント方法がない限りは概ね正確な値を求めるのが精一杯です。 というか、今回書いたものは「ver.3.1.0はこういう傾向にある」というだけの話なのでそれを説明するには十分な精度で計測できていると私は思います。 上辺だけの知識よりも実際にどうなのかが重要です。

だからさ。 こうしたほうがより「良い値」がでるんじゃね？って言っているだけで、十分でないなんて言ってないぜ？ 結論を否定しているわけでもないし。 ズレがあるのももう散々話してるし、わかりきったことだし。 世界にはたくさんの人がいて、いろいろなことしてるからね。 その「精一杯」っていうのが、「平均」を前提に考えるからであって、分布を考えれば「より良い値」を出せるっていう話、そういう方法が既出だよっていう話をしているんよ。 まぁそれを「上辺だけの知識」と思うのならそれでもいいけども。

その分布さえも正確に出せず、分布からどのように結論を導くかも人それぞれに分かれてしまうというのが個人的には難点に思います。 今回の結果では「乗算が除算より遅い」とか「INC AがA=A+1より遅い」と言っても「どれくらい遅いのか」というのが気になる部分だと思うのでその目安として提示しているにすぎません。 個人的にはこれが「正解に最も近い」と感じていますが、これが万人にとって正解というわけではなくれいさんにはれいさんの正解があることでしょう。 ならば、ここであれこれ言う間に自分にとって正解を「形」にする方がベターではないでしょうか？

「冪分布だ」って話を聞いても「これが正解に最も近い」と思うんならまぁそれでも。 命令の実行速度は重要だけど必要な時に調べればいいだけなんで貴重な公開キー一つつぶしてまでコード出すほどは興味ないかな 俺の言ってるのは最速を求めるだけなんで平均より簡単だし。

少し勘違いされていますが、例えば10秒間に1000万回実行できたとしてその1000万回のうちの最速を表示することは簡単なことではないですよ？ 10秒間の実行回数を10回測定してその中の最速というのはすでに最速ではなく「平均に近い数字」になっています。それならば、最初から「平均」として提示した方が分かりやすいでしょう。 個人的には「紛い物の最速」なんて要らないです。

んー…。なんというか、ぶっちゃけ、その理解が間違ってるんだよ。 だから必要以上に「平均」にこだわってるんだと思うんだけど。 ここで説明すんの大変だし別に間違ってても悪いわけじゃないでまぁいいかとも思ったが 仕事したくないから説明してみるかね。 ある命令1個実行するのに、最低限必要な時間をA秒とするでしょ。 実際にはその命令の最中に割り込みが入ったり、中でキューイングされたりして遅くなる。 割り込みはいくつもあるし、時間もいろいろだけど、とりあえず独立で確率p、時間はB秒とすると。 A秒で終わる場合（たくさん）、A+B秒で終わる場合（確率p）、A+2B秒で終わる場合(p^2)… となって、頻度分布とったら冪分布になる。 実際には割り込みの最中にも割り込み入るんで、もっと裾野広い分布になる。 続く。

よくあるガウスや正規分布の場合なら、 「10000回実行にかかった時間/10000」のバラツキは 「100回実行にかかった時間/100」のバラツキの1/10になるんよ。 だから、たくさん測れば測るほど、バラツキが減る。 ところが冪分布だと、「たまたまたくさん割り込みはいっちゃった回」の影響が大きくて、たくさん測ってもバラツキが減らない。 （たくさん測ると「たまたま」が入る確率が上がって、その結果バラツキが小さくならない。） 100回実行の結果を3つ比較した時、10000回実行の結果を3つ比較した時で、差があまりなくなってしまうということ。 それでこの手のベンチを平均で処理してるとみんなおちゃめ氏のように「バラツキが大きい」ということになる。

そこで別の手法を使う。いろいろあるけど、たとえば「最速」を選ぶ方法。 最速は割り込み等遅延の影響がなかったとき。 「100回実行」したときに一回も割り込みが起きないのはめったにないかもしれないが、少ないことはある。 たくさん繰り返せば、必ず収束する。 「100回実行」を10000回やって最速を求める、というのも 「100回実行」を100回やって最速を求める、というのを100回やって最速を求めても、大体同じになる。 さらに、そこから、 「n回実行」をm回やって最速を求めた時の結果を予知できる。 これが重要。 n=1にすれば 「1回実行」した時の最速が求まる。

おちゃめ氏の言う、「平均に近い数字」というのから、きちんと「最速の値」が出る。 少なくとも「たくさん測ると一定の値になる」数字が出る。 分布から逆に計算すれば、「最速の値」ですら出せる。 ところが、「平均」を使ってしまうと、たくさん測っても一定の値にならない。 割り込み等の間隔よりも十分に長い間隔で測定すれば冪分布にからずれるので、 平均もある程度収束するようにはなるが、とても長い時間が必要になる。

空気読まず質問しようかとか思ってたので手間が省けて助かりました(`・ω・´)＼ 勉強になりまっす。

えっと、SPVARがクソ重い気がするとゆー質問はここでいいんですか?

「平均は、都合の良いことをを表現するために使うこともあるし、都合の悪いことを覆い隠すために使うこともある。」 平均値に踊らされないためには、度数分布や、母集団とサンプルの関係など他の情報も併せて考慮した方が無難かな、ということかもしれない。（気のせいかもしれない。難しくてついていけていない。）

関係ないかもしれませんが、リアルタイム処理の場合は、最速や平均も大事ですが、最悪がアルゴリズム選定の決め手になることが多いです。

れいさんへ 私が言いたいのはそれが実現可能なのか上辺のみの知識ではなく形にして欲しいということです。 そしてループ回数が少なくなるほど計測誤差が大きくなります。 プチコンの処理に依存しない正確な時間を計るカウンターがない限りは絵に描いた餅の状態です。 実際に美味しく食べている餅を目の前に「こちらの絵に描いている餅の方が美味いぞ」といわれても「それがどうした？」というのが本音です。 今回の結果がそれによって覆るというのならば話は別ですが、そういう趣旨でも無さそうなのでれいさんがここで一体何をしたいのかも分かりません。 ゲームを作ったこともない人が（制作者が十分満足しているのに）「このゲームはこうしたら面白くなる」とその人のトピで延々に語っているのと何ら変わらない気がします。

コータさんへ 正確に数字が出る場合は平均に踊らされないということが重要ですが、ループ回数を減らしてしまえば時間計測の誤差の方が大きくなるため今回の件に関しては無意味なんですよね。 れいさんは時間計測の誤差に関しては全く触れておらず、失礼ですがこの辺の認識が甘すぎると思いました。

気のせいかもしれませんが、れいさんのやり方だと、誤差の特性も推定できるようになると思います。

コータさんへ 結局誤差を含んでいる値には代わりがないのでループ回数を減らせば誤差に左右されるため真の値からはどんどんずれていきます。（数学的には正しくても現実的には正しくない）

ループ回数を増やしたときと、減らしたときとでは、効いてくる誤差の要因と影響する度合いが変わると思われます。 同じバックグラウンドで行われるにしても、定期的に行われる処理もあれば、不定期に行われる処理もあります。しかも、その時々で、処理量が一定かどうかは保証されていません。 １フレームが、私たちが検知できる最小時間単位ではありますが、誤差の特性を全く無視して良い用途ばかりでは無いと思います。 なお、短期的にはともかく、中期的には１フレームは十分信頼できる時間だと思います。

全然理解してない…orz ループが少ないほうが誤差が大きいというのはガウスや正規分布の場合なんだってば。 数学的に正しいなら現実でも正しいし。 まぁ俺の説明能力の限界もあるし、ここはそういう説明するのに適した場所でもないし、仕方ないね。 とりあえず、俺の方法で計った結果はこんな感じ。 A=1 241.6 +- 1.5 nsec A=B 276.1 +- 2.4 nsec A=B/5 367.1 +- 3.0 nsec A=B*5 443.1 +- 4.2nsec 割り算の方が早いのは変わらん。

処理の速度が分かるプログラムか、あまり使わなくない？

いや使いまくりだろ。 プログラムしてるとあれもしたいこれもしたいってなってくるんだよ。 で、そうすると大抵メモリか速度かどっちかが足りなくなる。 おちゃめ氏の言うように根本的にはアルゴリズムなおして対応するんだが、無理な場合もある。 そういうときは限界までチューニングするんだよ。 BadAppleも、旧3DS対応のために限界までいろいろやったぜ？ 最終的にいろいろあきらめたけども。

ムスカさんへ 私は、時間制限が厳しい用途のプログラムには縁が薄いですが、時間制限が厳しい用途のプログラムを作る人にとっては、とても重要なんです。

そーなのか？まぁ、頑張って下さい(逃亡)

ムスカ氏が速度限界まで挑戦するプログラムを作るフラグか……… コータさんのコメントを見て、書こうとして忘れてた事を思い出しました。 ゲームとかツールとかで速度がネックになる状況だと、おちゃめさんのいうように処理時間の平均＝期待値を判断基準にするか、コータさんのいうように最悪の場合を期待値にする場合の2通りがメインですね。 多重ループの中にどんな処理を書くかとかだと平均で考えて、CPUのAIの処理時間だと最悪の場合を基準にアルゴリズムを選んだりします。 それで、処理時間の平均を知りたかったらサンプリング数を増やせば得られると直感的に思っていたのですが、れいさんの説明を読むとそれは正規分布やガウス分布の場合だけなのですね。

最悪ケースでも長くならないようなキューとか割り込みとかの技術はちょっと前まで一大研究分野になってたと思う。 そういうの使うと平均でもある程度はでるんだけど、最悪を気にするならきちんと分布でみたほうがいい。 べき遅延問題は最近だとネットワークや並列コンピューティングで問題になってて。 ネットワークは正常なのに永遠に返事が来ないなんて最悪ケースもある。 プチコンみたいなブラックボックスの場合。 個々の命令の速度の測定は最速のパターンで調べて、それを組み合わせて最速のアルゴリズムにする。 そのアルゴリズムの実際の速度は、実際に組んでみて実行時間の度数分布をみる。 最悪ケースを対処したいなら度数分布から統計的に許せる速度を推計して使う。 ってのが王道かな。

おちゃめさん、沢山の検証お疲れ様です！ これは参考になりますね♪ れいさんの説明も分かりやすかったです。 確率と統計に関することって面白い！ あとあと、れいさんの理論は正しいと思います(^_^) ただ、もし苦労して作ったものを「3点」っていきなり言われちゃったら 私は傷ついちゃうかも(;~;) もっと優～しぃ言い方のが嬉しいかもね？ そう、オブラートのように(笑

アレ？「3点」って「☆３つ頂きました」ってことじゃないんですか？ よくプログラムで多重ループ使ってるんで配列への代入が遅いっていうのはすごい参考になりました。 検証お疲れさまです。

コメントを３つします(=３点)

なるほどっ。 れいさんの事だから協力したいんだけど取りあえず一刀両断にぶった切ってから本題に入っただけかと思ってました。失礼失礼(^ω-) いわゆる今流行りの………ツンドラでしたっけ。

これってfps表示に使えますか？

3点って得点のことじゃなかったのか… 失礼しましたm(_ _)m

れいさんお詳しいですね。知らないことがたくさん書いてある。 べき分布にはパレート分布とかあって、例えば地震のエネルギーと発生頻度の関係がそうみたいですね。ネットに書いてあった。中心極限定理が成り立たない? いや正規分布に収束しない? なんか手ごわそう。 いわれてみればマグニチュードの平均とか意味ないような気がする。けど実行時間がべき分布になるという根拠は?? けいさんそれは冷凍マンモスのふるさと!!

れいさんへ 「数学的に正しくても現実的には正しくない」というのはプチコン3号に処理に依存せず厳密に等間隔で刻めるタイマーがあったられいさんの考えたものを作ることができるけど現実的にはMAINCNTもMICPOSも厳密な意味での等間隔ではないためです。（MICPOSを使っている私の自作TIMER関数も同じ） したがって、そのやり方は最速値としては正しくありません。（最速値よりも速い値に収束する） 単に「バラツキの少ない値が欲しい」というだけであればれいさんの方法がベターですが、れいさんが求めている「最速」というのはそのレベルで考えていたのでしょうか？

けいさんへ 平均と一言でいっても相加平均、相乗平均など様々なものがありますが、今回の場合は実際の実行速度がどれくらいなのかという目安が分かれば良いため相加平均（算術平均）で問題ないと判断しました。 もちろん、判断を下すためには自作のTIMER関数の性質も把握する必要があるし、今回サイト上で結果を正式公開するにあたり「平均をとって問題ないのか」というのを十分な検証をするため3週間に渡り数千回の計測を行いました。 本来ならば平均値ではなく最頻値にすべきですが、（最頻値を採用するならば計測回数が10回では全然足らないのでこれは妥協策とはいえ）検証によって平均値と最頻値とはほとんど差異はないことが分かっているため問題はないです。 そして、れいさんが危惧しているようなとんでもなく大きなバラツキは1度も発生しませんでした。 （↓続く）

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

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

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

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

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

ヤバイ、全然理解できぬ。(関係ないのに乱入)

ムスカさんへ 大丈夫、これを理解しなければならない人はそんなに多くありません、 たぶん、想定している処理速度の利用目的に違いがあり、そのために発生している見解の相違なのかもと思っています。

ふぅ、それなら良かった。(棒)

おちゃめさんの投稿はとても参考になるので、勉強させていただいております。いつもありがとうござます。 質問ですが「最速値よりも速い値に収束する」という一文が理解できません。もうちょっとわかりやすくご解説いただけますでしょうか? それと「平均値と最頻値とはほとんど差異はない」事を検証されたとの事ですが、どうやって最頻値を求められたのでしょうか?

>おちゃめさん メチャメチャ詳しい解説ありがとうございます。 まず知らない単語が多いので、調べて勉強しつつ読ませて頂きます(`・ω・´)＼ >ムスカ氏 「(俺ほどになれば自然と十分な速度が出るからなぜわざわざ計るかが)全然理解できぬ」 と。なるほど、流石です(`・ω・´)

3DSで音関係は内部のDSPが処理してる。 サンプリングされた音のデータはDSPからCPUにバッファをかまして少しずつ送られてきてる。 負荷を減らすために、サンプリングのたびに送るんじゃなくて、16点程度をまとめてからCPUに送るような仕組みになってる。 DSPのサンプリングは32728HzでCPUと全然違うし、バッファで一度蓄えられたりするので、 MICPOSで時間を計る場合、この「まとめて送る」のが精度を決めてて、16/32727=488.9usec程度になる。 タイミングによってはバッファにたまってる分を数えちゃうので、最大488.9usec、平均249usec短く数えてしまう。

おちゃめ氏が「最速より速い値に…」っていうのはこれのことだろうと思うが…問題にならない。 おちゃめ氏もやってるように、「命令の実行時間」を測る時には「空ループの実行時間」を引いて求めることになる。 「空ループ」も「命令を含めたループ」も、同じように「最速」で見れば、 それぞれの計測時間が最大489usec短く出てしまっても引き算するので消える。

あれ。文字と絵と同時に投稿はできないのか。せっかく書いたのに…。 長さの計測とか、電圧の測定みたいに、「大きくなる誤差」も「小さくなる誤差」も同じような確率で起きるような計測だと、↑の右絵みたいに、「ガウス」分布になる。左右対称で正しい値は真ん中。たくさん測定して平均求めると正しい値が出る。 ベンチマークなんかは、「実行に最低限必要な時間」は決まっていて、それに「割り込み等にかかる時間」が加わるので、左絵みたいに、左右非対称の「冪っぽい」グラフになる。 平均は最頻よりも大きい側にあって、たまに遅い値がでちゃうから、収束が悪い。 最速と最頻はすぐ隣にあるので、最速を見ると誤差が少なく収束が速い。

ぐはっ 3点ってたしかに点数っぽく見えるww IMEが「三点」にしてくれないから…って漢数字でも点数にみえるか。 文字数制限きつくてとにかく短く書くことしか考えてなかった すまんorz

誤解をされる方がいるとまずいので、一つだけ補足します。 「本来なら無視すべき値」は、状況によっては無視してはいけない場合もあります。 １）科学実験の場合は、原因が明らかにならないまま無視するとねつ造と非難されます。 ２）リルタイム処理の場合には、バグの存在が疑われる案件なので、原因が明らかにならないまま無視すると世に出してから大事故に繋がることがあります。

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

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

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

はぁ、ハァ、これ読むのに1時間くらいかかった。 でも、色々参考になりました!って言いたかったんですが　何か難しい... でも、参考になったところもあるのでよかったです。 って今かいたら遅いかな。

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

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

MICPOSの16サンプル分、足し算して分布が広がる分、割り込みはランダムではなく定期的に入るというところから来る分、 そういったのが合わさるのでだんだんぼける。 つ中心極限定理 ぼけるだけならいいんだけど、問題は最頻や平均がループ回数に依存してしまう点。 「500万回ループの平均、を1000回計測したときの平均」 「100万回ループの平均、を5000回計測したときの平均」 が変わってしまう。 これは500万回ループのヒストグラムと100万回ループのヒストグラムと形が違うことからわかる。 他の環境、他の言語、他のアルゴリズムなどで比較するときに試行回数で結果が変わるんじゃ比較しづらいでしょ。 「無印3DSは遅いから10万回ループで試しました」っていうのと比較ができなくなってしまう。

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

？ ループ回数が増えたらぼけて安定分布って言う面倒な分布になるだけで、最頻や平均では正確性に問題があるという点では同じだけど。 俺はずっと、「客観的な正確さの定義」と「計測における分布の問題」を話してる。 誰がどう思うか、なんて主観的な話はしてない。

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

だから。 傾向を測定したという結論を否定してるわけではないって上でも言ってるだろ。 何回言ってもそこを否定されてると勘違いしているようだが、そこは初めから問題にしていない。 次。 環境と命令とを分離して考えていないので話がおかしい。 「命令の実行速度」と「特定環境での特定アルゴリズムの実行速度」は全く違うものだ。 プチコンはそれほど実行時環境の影響を受けないが、それでもスプライト数、BG数、拡張機能の有無などで速度が変わる。 「命令の実行速度」の議論をするのであれば、それらの影響を排除しなければならない。 環境Aは、ある命令が200nsecで実行できるが、環境の背景負荷が小さい。 環境Bは、ある命令が150nsecで実行できるが、環境の背景負荷が大きい。 というのであれば、「ある命令」は環境Bの方が速い。 それを含む「実際のプログラムの実行速度」は環境Bの方が遅い。 環境の背景負荷は

切れた。 というのであれば、「ある命令」は環境Bの方が速い。 それを含む「実際のプログラムの実行速度」は環境Bの方が遅い。 環境の背景負荷は場合によって異なる。増えたり減ったり、増やしたり減らしたり。 なので、「命令の実行速度」を議論するのであれば「最速の方が適切」＝客観的に正確な値だ。 やっぱここは議論に向いてないな。 連投できないわ短いわ。 絵が描けるのだけはちょっといいけど。

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

うん。 で、1nsec単位で処理速度を計るプログラムと銘打つなら、より絶対的で正確な値を出せた方がいいよね。 あたりまえだけど。 自分の環境だけで意味のある数字をたくさん並べるより、 全ての環境で共通に意味のある数字をたくさん並べたほうが意味がある。 特に、「～より～の方が速い」といったことを言うのなら。 そこまでわかってくれたら最初から俺のコメントを読んでみてくれ。 より良い測定にするにはどうするかを書いてあるから。

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