インプットラグの秒数ごとの分布でさらに分析
平均値だけではわかりにくいので、インプットラグの秒数ごとの度数分布を調べてみよう。つまり、100回小パンチを放った時のインプットラグで、どの値(単位ms)が最も出やすかった、あるいは出にくかったかを調べるのだ。最も背の高い山が左に寄っていれば、インプットラグが短く優秀な設定、ということになる。
デフォルト時に最も頻度の高かった(バーが長かった)のは95.83msだったが、V-SyncオンやNULL“Ultra”にすることで明らかに最頻値の山が左側にずれこんでいる。デフォルト時は85.42~89.57msもコンスタントに出ているので、デフォルト時でもそれほど悪い結果が出ているとは言えないが、V-SyncオンやNULL“Ultra”にすることで、より“短いインプットラグが出やすくなる”という傾向が「あるように見える」。
だが「あるように見える」レベルの結論では不十分だ。そこで「t検定」を用いてデフォルト時に比べて、「統計的に有意な差であるかどうか」を検証する。ここから先は小難しい理屈が出まくるがご容赦頂きたい。
今回有意水準pは5%(0.05)とした。つまり、帰無仮説を“デフォルト時とのインプットラグの差は存在しない”、対立仮説は“デフォルト時とのインプットラグの差(大小の方向は問わない)が有意に存在する”とした。下表の「p(T<=t)両側」の値が2.5%(0.025)より小さければ対立仮説が成立する。この辺は統計の教科書などを参照して頂きたい。
これによると有意水準5%の両側検定、即ち2.5%(0.025)より小さいp値を出せたのは、G-SYNCオン時とNULL“On”時のみ。つまり統計的に“違いが認められる”と認められたということだ。だがこれは“インプットラグ短縮効果あり”を意味するものではない。ここでもう一度インプットラグの平均値を見てみよう。
デフォルト時とV-Sync有効時とを比較すると、平均91.19ms 対 92.19msとなるようなデータは出たが、統計的に有意な差ではない。しかし、デフォルト時 対 G-SYNCやデフォルト時 対 NULL“On”で比較すると、その結果には統計的に“ほぼ間違いのない”差が出たと認められる。
つまり、インプットラグ平均値が91.19msから92.77msや93.38msへ長くなったのは偶然ではない。もっと言えば、V-SyncオンやG-SYNCオンでは「わずかだがデフォルト時に比べインプットラグが増えてしまった」ということだ。
ちなみにNULL“Ultra”は統計的にデフォルト時と差のある結果ではない、と判定はされたが、ヒストグラムを見る限りデフォルト時よりも頻度の偏りが強いように見える。これについて実際に箱ひげ図を起こして再考してみよう。
これを見るとNULL“Ultra”設定では、箱の縦の長さ(データの散らばり)がどの条件よりも短い。どの条件においても箱の中に全体の50%の値が入り、さらに言えば、仕切り線で2分割された箱の下の領域はどの条件よりも小さい。このことから、NULL“Ultra”ではより安定したインプットラグになる傾向がありそうだが、残念ながら統計的に満点のお墨付きは出せない感じ、といったところだろうか。
ただし、G-SYNCはインプットラグ的に逆効果であるという事実は新たな疑問を提示する。実はSFVはG-SYNCがドライバーレベルで無効化されており、グローバル設定でいくらオンにしようとも、アプリケーションのプロファイルで無効化されているのだ。
G-SYNCをグローバル設定で有効化し、SFVのプロファイルで無効にするとネガティブな結果を生んだのか、今回のサンプリング数でも足りないかのどちらかが考えられるが、今回はここまでとしたい。
週刊アスキーの最新情報を購読しよう