これは何？

先日。Windows の禁断のAPI だった timeBeginPeriod の仕様が変わったことに気がついた。

普通に使って良さそうなので使ってみてどうなるか試してみた。

timeBeginPeriod - 禁断のAPI からの仕様変更

先程のリンクにある通り、昔は

Windows 10バージョン 2004 より前のバージョンでは、この関数はグローバル Windows 設定に影響します。

という邪悪な API だった。どこかのプロセスが timeBeginPeriod を呼ぶと、そのプロセスを動かしている OS 全体の動きが変わり、何も知らない Excel とかも巻き込まれる。

組み込み機器上で動いている Windows 以外で呼ぶのは禁忌とされていた。と思う。

それが

Windows 10 バージョン 2004 以降では、この関数はグローバルタイマー解決に影響しなくなりました。【略】この関数を呼び出していないプロセスの場合、Windows は既定のシステム解像度よりも高い解像度を保証しません。

となり、安心して呼んでいい感じになった。

ちなみに「Windows 10 バージョン 2004」の 2004 ってのは '20年4月のことなので、約三年前。2004年じゃない。

試してみたこと

go の time.Ticker で 1ms 間隔でなんかする、という処理を試みたらどうなるのかを試してみた。

go

func test(msg string) {
	const size = 5000
	ticks := make([]uint64, 0, size)
	ticker := time.NewTicker(time.Millisecond)
	defer ticker.Stop()
	for range ticker.C {
		ticks = append(ticks, queryPerformanceCounter())
		if size < len(ticks) {
			break
		}
	}
	show(msg, ticks)
}

こんな感じ。queryPerformanceCounter は syscall.LoadDLL で呼べるようにしてある。

timeBeginPeriod にわたす値を 1, 15, 16, 256 と変えてみて、処理が来る時間を記録。
ついでに macOS でも記録。
前回時刻との差がどう分布するのかをグラフにしたのが下図。

「before」は、timeBeginPeriod を呼ぶ前。「tbp:N」は、 timeBeginPeriod(N) を呼んだあと。
「macOS」は macOS上なので timeBeginPeriod は無関係。

縦軸はミリ秒。横軸は頻度。

ターゲット環境は、macOS 以外は、いわゆる Windows 11 2022。CPU は Ryzen 3 PRO 4350G。
macOS は、MacBook Pro (Apple M1 Pro 非MAX)。

負荷は特にかけてないけど、負荷がかからないような努力もしていない。全然厳密じゃない感じ。

グラフを見ると

1と15 は同じ。
呼ぶ前と 16・256 は同じ。

という事になっているように見える。

1 と 15 は、1ms 付近と 2ms 付近の二箇所に山がある。最長でも 3ms ぐらいの間隔になる。

呼ぶ前・16・256 は、16ms 付近に山があり、1ms 間隔になることはない模様。

まとめ

Windows で timeBeginPeriod(1) の効果は絶大。
今までは time.Ticker で 1ms と指定しても 16ms にしかならなかったのが、CPU が暇なら、半分以上は 1ms 間隔になるっぽい。

しかし、macOS なんかとくらべると精度が低く、2ms になっちゃうことも多い。残念。

蛇足

1ms より短くできないのも残念。

禁断の関数 timeBeginPeriod の闇の力を利用していた人は、この仕様変更で困ることになった思う。

そういう意味では、別の API を用意してくれたほうがハッピーだったと思うけど、そうできなかった理由はなんだろうね。