Monday, March 8, 2010

(WCPI): Windows 7 = Moore’s Law In Action

Want to know what separates Windows 7 users from their XP-loving contemporaries? Try 342 additional execution threads chewing-up an extra 711MB of RAM while spending over 2/3 more time running in Windows’ privileged “kernel mode.”

At least that’s what the latest Windows telemetry data uploaded to the exo.repository seems to indicate. By analyzing the approximately 1 to 1.7 million process metrics records, per system, collected each week from our community of over 24,000 registered users, we were able to create a profile of each user type and the composition of their typical application workloads.

For example, the average total process private bytes for systems in our pool of over 13,000 Windows XP users comes in at just over 564MB. Meanwhile, this same metric measure across systems from our nearly 5,000 Windows 7 users shows an average of just under 1.28GB (Vista comes in at just under 1.30GB).

A similar trend emerges when you look at the number of concurrent execution threads running on each system type. Windows XP users typically have anywhere from 40-60 concurrent, running processes spawning an average of 653 execution threads in total. By contrast, Windows 7 users typically have from 50-80 concurrent processes, and these, in turn, spawn an average of 995 execution threads. Vista systems report a similar process count, but with a higher total thread count (1013)across these processes.

Win XP

Vista

Win 7
Private Bytes 564MB 1295MB 1275MB
% Privileged Time 8.4 15.2 14.3
Thread Count 653 1013 995

Another interesting metric, % Privileged Time, shows that process threads under Windows 7 spend, on average, 70% more time running in kernel mode than threads running under Windows XP (for Vista, this delta is 81%). This shift towards privileged execution could have several causes:

  1. Newer applications, like Office 2007/2010 or Internet Explorer 8.0, spending more time executing in kernel model.
  2. New Windows services not present in XP interacting with the kernel and other low-level code, like device drivers.
  3. A more complex kernel, which itself spins an additional 40-50 execution threads in a default installation, taking more time to process kernel-mode requests.

Regardless of the cause, the fact that threads under Windows 7 are spending more time executing in kernel mode can have a direct impact on system performance. On the positive side, code that is executing in kernel mode tends to run faster since it doesn’t need to repeatedly transition into kernel mode to accomplish portions of its work (it’s already there).

However, code running in kernel mode is also inherently more difficult to multitask – it is essentially in control of the system and, in the case of a device driver’s Interrupt Service Routing (ISR), cannot be interrupted. Thus, more time spent in kernel mode often translates into reduced overall system performance, a scenario which typically can only be mitigated through the introduction of a more powerful CPU.

Bottom Line: Windows 7 users place significantly higher demands on PC hardware than users of its popular predecessor, Windows XP. Their workloads are typically larger (Private Bytes), more complex (Thread Count) and spend a greater amount of time running in kernel mode (% Privileged Time).

Fortunately, this additional computational overhead is mitigated by the fact that most Windows 7 users are running the OS on the latest generation of PCs, and this additional computing “horsepower” allows the OS to deliver new functionality and services while remaining responsive to user requests.

In other words, Windows 7 = Moore’s Law in action.

Note: The above statistics were generated from the over 14 billion process metrics records collected from the over 24,000 registered, active xpnet.com users. If you’d like more information about the exo.performance.network, including how to reproduce the above chart object (for free) on your own site or weblog, please visit our web site: www.xpnet.com.


Figure 1 – Get This and Similar Charts at www.xpnet.com

No comments: