I'll also toss out a minor caveat in regard to Microsoft's API time functions: none of them are accurate enough for certain kinds of work, because of fundamental problems in the implementations, the vagaries of an event-driven messaging system, and problems in the x86 silicon itself. Because of this, the best you can reasonably expect is an accuracy of about 1/1000 second, with considerable unpredictable drift. While that may seem like a lot, for many purposes it isn't nearly enough. You also have to be aware that there are actually two families of Windows time functions, and the other one will give you no more accuracy than the old
DOS 1/18.2 second timer interrupt, which it was designed to mimic. Top of my head, I don't recall which functions belong to which family, but if you follow the link David gave, it should tell you there. Or install Microsoft's latest
Platform SDK; it's a free download, and is loaded with tons of hard-core programming info. Only problem is, it's roughly 150 MBytes to download, and more than a Gigabyte expanded, so you'll need to have a lot of disk space to spare.
The other possibility that sounds really good turns out not to be. That's using the time-stamp opcodes, which are documented by Intel as maintaining a count of clock cycles since the last system restart. A few years ago I had an interesting chat with the guy who designed that silicon for Intel (and similar silicon for Motorola), and he gave the myriad reasons why it isn't what it seems. Besides the fact that you can't count on finding that function on all x86-compatible chips, since it's not officially supported, it isn't actually a timer at all. In fact, all it guarantees is a monotonically-increasing counter (up to its size-modulus roll-over point), with no guaranteed relationship to real time. It was intended merely to provide a unique timestamp for
Windows NT processes, not an absolute time. This is further complicated by the fact that different parts of the CPU core run at different speeds, and can change speeds depending on certain conditions (for instance, parts of the core can drop to lower bandwidth to conserve power during system hibernation; there are many instances when it can happen even during normal CPU operation). So while you can build a timer more accurate than any of the
Windows API functions using the
RDTSC opcode, it isn't as accurate as you'd think. Still, I used to use that in the timing code for systems of differential equations in physical simulations (i.e., games
), and it was generally adequate for that purpose. Obviously, such an approach will have more problems on some more modern chipsets, particularly those designed for mobile use, as power is a prime concern there.
Anyway, for most practical applications you'll find yourself doing in
CMac, the functions David mentions will be plenty adequate. I mention all this only to keep anyone from trying to write, say, scientific code using those functions, as it would not give the expected results. This is true in general
Windows programming too, BTW.
The sad truth is that if you require that kind of timing accuracy, your machine will have to have external hardware to provide it. I once tried to talk a couple of AMD engineers at a seminar into adding a true counter to their silicon (and a good non-pseudo-random number source, as well), but it ain't there yet, so I guess they were just letting the words bounce off while waiting for the buffet.
The Intel guy I talked to told me he'd argued strongly when designing the TSC silicon for making it a true counter, but they were at their component density limits for a reasonable chip yield at the time, and didn't want to give up silicon elsewhere on the chip. Such is life.
) To use the following macro file, first declare and "Create" a str_array (supplying a unique filename). "Put" strings in the array, then "Get" each string or "Clear" as needed.