ああ、QueryPerformanceCounterが失敗しないと記載されたドキュメントへの反例を見つけた
Andrej Karpathyが紹介した記事は、Windows APIのQueryPerformanceCounterが「決して失敗しない」とする公式ドキュメントに反する事例を発見したという内容で、技術的な例外ケースを示している。
キーポイント
ドキュメントの反例発見
QueryPerformanceCounterが「決して失敗しない」とするMicrosoftの公式ドキュメントに反する具体的な事例が発見された。
技術的例外ケースの存在
特定の条件下では、高精度タイマーAPIでさえ予期せぬ動作を示す可能性があることを示している。
ルール違反時の限界
記事は「ルールを破れば何でも起こり得る」と指摘し、システムの想定外の使用が問題を引き起こす可能性を強調している。
影響分析・編集コメントを表示
影響分析
この記事は特定の技術的例外ケースを指摘するもので、AI業界全体への直接的な影響は限定的である。しかし、システムレベルの信頼性に関する議論や、ドキュメントの正確性に対する注意喚起として、開発者コミュニティ内では参考になる情報と言える。
編集コメント
AI業界の核心的な話題ではなく、システムプログラミングの技術的詳細に特化した内容です。開発者向けの実用的な知見として参考になりますが、広範なAIトレンドには直接関連しません。
もちろん、ルールを破れば何でも起こり得ます。
この投稿「QueryPerformanceCounterが『決して失敗しない』というドキュメントへの反例を見つけた」は、The Old New Thingに最初に掲載されました。
原文を表示
In the documentation that describes the high-resolution timestamps, there is a question-and-answer section.
Under what circumstances does QueryPerformanceFrequency return FALSE, or QueryPerformanceCounter return zero?
This won’t occur on any system that runs Windows XP or later.
People on Stack Overflow have noted, “Nuh-uh! I can get it to fail even on Windows XP and later!”
The function can fail with error code ERROR_NOACCESS (Invalid access to memory location) if the variable is not double-word (8-byte) aligned.
So who’s right?
The documentation assumes that you are passing valid parameters. Specifically, the pointer parameter is a valid pointer to a writable LARGE_INTEGER structure. And that means that it’s not a null pointer, it’s not a pointer to unallocated memory, it’s not a pointer to read-only memory, it’s not a pointer to memory that is freed while the function is executing, you don’t write to the memory while QueryPerformanceCounter is running, and it’s a pointer to properly aligned LARGE_INTEGER structure. (There are probably other ways the parameter can be invalid; those are just the ones I could think of off the top of my head.)
The LARGE_INTEGER structure as LONGLONG alignment, which on Windows means 8-byte alignment, because the default structure packing is /Zp8. Therefore, your output LARGE_INTEGER was not valid. (Indeed, in the example given, it’s not even a LARGE_INTEGER!)
If you pass invalid parameters, then you have broken the basic ground rules for programming, and the results will be unpredictable. The function might return failure, it might return success but produce garbage results, it might crash your process, it might merely corrupt your process in a way that causes it to crash 10 minutes later. Everything is on the table (as long as it doesn’t cross a security boundary).
The way they got it to fail was by passing invalid parameters. Clearly the function can’t succeed if you don’t give a valid place to put the answer.
But just to forestall the “Nuh uh”-ers, I made an update to the documentation for QueryPerformanceCounter:
On systems that run Windows XP or later, the function will always succeed when given valid parameters and will thus never return zero.
CategoryTopics
Author
Raymond has been involved in the evolution of Windows for more than 30 years. In 2003, he began a Web site known as The Old New Thing which has grown in popularity far beyond his wildest imagination, a development which still gives him the heebie-jeebies. The Web site spawned a book, coincidentally also titled The Old New Thing (Addison Wesley 2007). He occasionally appears on the Windows Dev Docs Twitter account to tell stories which convey no useful information.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み