From reading the blog to be ready for my interview, I find Dave has an excellent vertical view of Silicon Valley, from the engineer up to the big conglomerate companies.  He focuses a bit on the players in search and databases, as that is his area, but I expect many aspects of his posts are universal in the high-tech business.

-Todd

p.s. I was thinking Dave should have named his blog “KellBlogg” instead of “Kellblog,” but if you look at one of his blog posts, you will see why that is a poor marketing choice.

QueryPerformanceFrequency()

and

QueryPerformanceCounter()

The first is OK, as it will give you an accurate number of cycles per second as returned by the intrinsic __rdtsc, which executes the RDTSC instruction.  That is, if you divide the value returned by __rdtsc by that returned by QueryPerformaceFrequency() you will get a value in seconds.  This value may vary by processor, so QueryPerformanceFrequency() is valuable, but it should be considered “expensive,” and thus only called at the start or end of a performance-critical section of code.

I noticed QueryPerformanceFrequency() returns an incorrect value when running in a 32-bit program executing on 64-bit Windows 7.  The value is 1,000 Hz too small.  This is easy to fix.  I have not experimented to see what is returned by querying the counter directly:

// Get the current ticks per second from the CPU.
unsigned __int64 m_ticksPerSecond;
__asm {
  mov ecx, 0xe8
  rdmsr
  mov m_ticksPerSecond,   eax
  mov m_ticksPerSecond+4, edx
}

QueryPerformanceCounter() is deathly expensive, and can ruin your performance evaluation if you are not aware of it.

QueryPerformanceCounter() does the same thing as __rdtsc, but requires a trap into the operating system.  This would be our burden if __rdtsc were always protected by the OS, but it is usually not (see my previous article.)

If we assume we must use QueryPerformanceCounter() to get a current cycle count, this is what we can expect:

LARGE_INTEGER m_temp;  // LARGE_INTEGER is MS-specific.
unsigned __int64 m_startTick;

QueryPerformanceCounter(&m_temp);
m_startTick = m_temp.QuadPart;

Execution time for QueryPerformanceCounter():

Kernel time: 47 nanoseconds  (110 cycles)
User time:   32 nanoseconds  (75 cycles)
Total Time:  79 nanoseconds  (185 cycles)

The timings are similar for the VS 2005 and Intel compilers.

Using the __rdtsc intrinsic required 3-5 cycles, so it is about 50 times as fast as using QueryPerformanceCounter().

These examples are executed using the Visual Studio 2005 compiler.  Results are given for the Intel compiler only when they differ.  For simple examples like these, the results are usually the same.

Pinning the Process to Core Zero

I will start by pinning the monitored process to core #0 of the four cores on my system.  If I allow the process to simply run on my system, it might be migrated by the operating system (Windows XP) between the four cores on my processor many times per second.  This migration can skew the results of the test.  I “pin” the process to core zero using the statement:

SetProcessAffinityMask(GetCurrentProcess(), 0x01);

The hexadecimal value “0×01″ tells Windows to assign this process to core zero.  (I know this does not make a lot of sense, but the cores are assigned to each binary digit, starting from the right.  Core zero is “x1″, core 3 is “x4″, and core 4 would be  “x10″, if I had more than four cores in my system.)  If I wanted to describe cores 0 and 4, I would use “x11″, which corresponds to the binary number “b10001.”

The Timing

I now will show some timings, with the running process “pinned” to core zero as mentioned above.  The results are likely to be the same without the pinning, but we would not be certain the experiment was sound.

The CpuTimer type uses the __rdtsc values.

CpuTimer timer, timer1, timer2;
timer2.Start();
for (int n = 0; n < 100000000; n++) {
  timer1.Start();
  timer.Start(); timer.Stop();
  timer1.Stop(); timer1.GetTimeSeconds();
}
timer2.Stop();

Results:

• Time to do a Start()/Stop() pair:  between 1.4 and 1.7 nanoseconds (3-5 cycles)

• Time to do GetTimeSeconds(), which is dominated by the time to convert the number of ticks to a 64-bit floating point number: about 5 nanoseconds (12-15 cycles)

The cycle counts for a 64-bit FP divide on my machine are:  latency 6, throughput 5, so the time to convert the number of ticks to a floating-point number is spot-on.

Many contemporary processors provide a mechanism to access a cycle counter accurate to a single cycle.  In recent x86 processors, we are able to access a count of the number of cycles since the processor was last started via the rdtsc, or “read time-stamp counter” instruction.  On my test machine, this counter is accurate to 1/2,330,000,000th of a  second or about 43 nanoseconds!  Compare this to the well-known Unix time() function which returns the time accurate to the nearest second.

Both the Visual Studio and Intel compilers provide and intrinsic to allow easy execution of this instruction in a C/C++ program:  __rdtsc.

In some secure environments (envision the NSA protecting its computers from some evil hacker), the operating system (OS) may not want to allow a normal user program to directly query the value of the time-stamp counter register.  But, in Windows and the Unix OSes with which I am familiar, you can access this directly.  Accessing it indirectly can cause trouble, as will be shown in later posts.

The __rdtsc Intrinsic

The __rdtsc intrinsic returns the number of clock cycles (stored in the time-stamp counter register) since the last system reset.  This is a 64-bit unsigned value, so on my 2.33GHz machine, it takes just over 250 years for this to wrap-around back to zero.  So, we can use it to time almost any event.

We are now faced with a future where the performance of software with only a single thread of execution will not continue to double every 18 months as a result of Moore’s Law as it has in the past.

Side note: Moore’s Law states: “The number of transistors which can be placed inexpensively on an integrated circuit [tends to double] approximately every two years.”  It does not say programs will run faster or clock rates will go up or anything else.  Moore’s Law refers to transistor counts, period.

In the past, having more transistors lead to on-chip floating-point units, superscalar pipelines, out-of-order execution, caching, and prediction mechanisms which used transistors to allow a single thread to execute faster at a given clock rate.  Also, transistors with smaller feature sizes were able to be clocked at higher rates, giving an additional performance increase for a single thread of code.  Today, processor designers have billions of transistors available, and clock rates are constrained by power limitations.

As a result, in order to continue to benefit from Moore’s Law, programmers will have to build multi-threaded applications which scale well to current (4-12) and future multicore counts.

In general, I will talk about the x86 family of processors in this blog.  This includes those made by Intel and AMD.  If a discussion of other implementations of the x86 ISA or other ISAs, e.g., SPARC, PowerPC, ARM, MIPS, etc., is included, the specific ISA or its implementation will be denoted.