Windows 7 On Multicore — How Much Faster?

snydeq writes "InfoWorld's Andrew Binstock tests whether Windows 7's threading advances fulfill the promise of improved performance and energy reduction. He runs Windows XP Professional, Vista Ultimate, and Windows 7 Ultimate against Viewperf and Cinebench benchmarks using a Dell Precision T3500 workstation, the price-performance winner of an earlier roundup of Nehalem-based workstations. 'What might be surprising is that Windows 7's multithreading changes did not deliver more of a performance punch,' Binstock writes of the benchmarks, adding that the principal changes to Windows 7 multithreading consist of increased processor affinity, 'a wholly new mechanism that gets rid of the global locking concept and pushes the management of lock access down to the locked resources,' permitting Windows 7 to scale up to 256 processors without performance penalty, but delivering little performance gains for systems with only a few processors. 'Windows 7 performs several tricks to keep threads running on the same execution pipelines so that the underlying Nehalem processor can turn off transistors on lesser-used or inactive pipelines,' Binstock writes. 'The primary benefit of this feature is reduced energy consumption,' with Windows 7 requiring 17 percent less power to run than Windows XP or Vista."

Comments

Windows 7 is better than Linux

[Anonymous Coward]

Suck it, nerds.

Re:Windows 7 is better than Linux

[ozmanjusri]

But how does it compare to XP X64?

It's slower.

Win7 is basically just a refurbished Vista under the hood.

Re:Windows 7 is better than Linux

[petermgreen]

XP X64 sucks
Do you have a source for that claim, i've only run it briefly but the only real issue I found was driver availibility.

and it is most assuredly not the same thing on any level as Win2K3 server.
The server specific functionality has of course been stripped out and the crippling adjusted but afaict the version of the major components is the same and it even uses the same hotfixes and service packs as the x64 version of server 2003.

Re:Windows 7 is better than Linux

[cHiphead]

I bet you even threw a Windows 7 launch party.

Re:Windows 7 is better than Linux

[jim_v2000]

I always find the Linux vs Windows debate so comical. Windows is a desktop OS trying to be a server, and Linux is a server OS trying to be a desktop.

Re:Windows 7 is better than Linux

[CarpetShark]

Agreed. I particularly like the feature where you rename a folder, and it shows up as renamed, but on the filesystem, it's still called "New Folder". Gotta love the strict testing that Microsoft put in.

Less power?

[Canazza]

Nooo! I was hoping that power consumption would continue to increase! Sooner or later our PCs would require 1.21GW!

Re:Less power?

[Thanshin]

Indeed. So much work with my lightning catcher for nothing.

Well, time to go back to the human reanimation experiment.

Not Really

[Mikkeles]

'What might be surprising is that Windows 7's multithreading changes did not deliver more of a performance punch,'

No, it's not surprising.

Re:Not Really

[timeOday]

It's not surprising because the OS really can't do that much to improve (or mess up) the performance of user-mode code that isn't making many OS calls anyways.

What is surprising is that power consumption could be so significantly reduced. This story could have come out with an entirely different spin if the headline were simply, "Windows 7 Reduces Power Consumption by 17%."

Re:Not Really

[setagllib]

I disagree - user-mode code, whether it's separated into threads or processes, still relies very heavily on kernel scheduling decisions. It may sound simple enough, but if you study the decisions the kernel has to make (such as which thread to wake first, from a set of 8 all waiting on the same semaphore), you can find lots of ways to get it wrong. We now take it for granted because thousands of man-years have been spent on solutions.

Re:Not Really

[SpryGuy]

While actual performance may not be faster, perceived performance almost certianly is. It "feels" snappier, seems to respond better, due to some optimizations in locking and in the graphics subsystem that allows visual feedback in one app to not be blocked or held up by work going on in another app.

Re:Not Really

[bravecanadian]

Agreed. A 17% reduction in power consumption doing the same tasks is nothing to scoff at...

Re:Not Really

[RicktheBrick]

I do volunteer work for world community grid. I use to run 7 computers. I now run 4 quad computers. A quad will beat 4 computers in work done and will use less electricity than 4 computers running at comparable speeds. My electricity bill went down when running the 4 quads than it was with the 7 computers and daily contribution has more than doubled.

Re:Not Really

[Jah-Wren Ryel]

not surprising because the OS really can't do that much to improve (or mess up) the performance of user-mode code that isn't making many OS calls anyways.

Others have already mentioned scheduling and cache thrashing, I'd like to add memory management. There are lots of ways memory management choices can degrade performance, sometimes drastically.

One example is page sizes and the TLB - each cpu has a hardware TLB which is like a cache of virtual page to physical page address maps. Hardware TLB look-ups are fast, but the TLB is only of limited size and when a virtual address is not in the hardware TLB, the OS has to take a fault and walk its own software-maintained TLB that holds the complete list of virt2phys translations. That's a couple of orders magnitude slower than getting it from the hardware TLB.

One way to reduce TLB misses is to use larger pages. So an OS that is smart enough to automagically coalesce 4K pages to 4MB (or larger, depending on the hardware) pages can significantly improve TLB performance. In a pathological case, that could result in a 100x-1000x speed-up, in typical cases where it is going make an difference you'll probably see ~10% performance improvement.

Another related example is how shared memory is handled. Every page of virtual memory has a PTE which, at the most basic level, contains the virt2phys translation. When shared memory is used, a decision must be made - are the PTEs shared, or does each process get a separate copy of the PTEs for the shared memory. Downside of sharing PTEs is that the shared memory must be mapped at exactly the same virtual address in each process that uses it, so if one of those processes already has something else at that address, it won't be able to use the shared memory. The downside of using separate copies of PTEs is that you can really suck up a lot memory for just the PTE list -- imagine 50 processes that all share on chunk of 100MB of memory, if they all get their own PTE copies for that 100MB its the equivalent of 5GB worth of PTEs. If a PTE itself takes up 32 bytes, then that's at least 40MB of PTE entries just to manage that 100MB of memory. A 40% overhead is huge and then there is the issue of hardware TLB misses which, depending on the implementation, may have to search all PTEs in the system, so the more PTEs the worse a TLB miss will hurt performance.

Re:Not Really

[lukas84]

Microsoft's "Engineering 7" blog has several telemetrics examples from Windows 7 vs. Vista.

As a Microsoft Partner, we've been using Vista exclusively on good hardware (2.5+ Ghz Intel Dualcores, 4GB RAM, 32bit Vista Enterprise).

We've completed our Migration to Windows 7 x64 two weeks ago. That's 10 desktops and 20 laptops. Everyone that has moved to Vista to 7 is glad that their computer is now faster.

Personally, i've witnessed that it's quicker to respond, though the tasks take roughly the same time in the end.

Re:Not Really

[lukas84]

There's a multitude of possible migration paths to take, to go from Windows XP to Windows 7 - in fact there is only one migration path that's exclusive to Windows Vista - the inplace upgrade.

The inplace upgrade is a horribly bad idea, and you should never try or consider it.

So, for any reasonable person, the migration paths available from XP to 7 are exactly the same as from Vista to 7. A new, clean install, followed by a migration of application settings.

If you're a home user, use Windows Easy Transfer to save all your settings to an external drive, reinstall, then recover your settings from the external drive. Reinstall all apps.

If you're a business user, there's a wealth of options available to you - check out the documentation for MDT2010, which can provide you with all the tools you need to roll out Windows 7 in your company. USMT and Windows Easy Transfer are the same under the hood - so user settings can be migrated.

A good place to start is the Windows 7 springboard:
http://technet.microsoft.com/en-us/windows/default.aspx

Re:Something is wrong with Win7 power management

[T Murphy]

So you've got a Linux fan and not a Windows fan. Not surprising on this site.

Not all code can be done in parallel

[jellomizer]

What the new languages and OS's are doing, are just making it easier for developers to make code that runs on parallel processors. However most of us are not trained to write parallel code. And there are some algorithms that cannot be parallelized. What the moderns OS are doing is taking code that was designed to run multi-threaded or parallel in the first place and in essence have them run more efficient on multi-processors. As well as giving you some tools to make development easier and stop us from trying to work around all those conflicts that distracts us from software development. Much like how String classes came common for developers so we didn't need to fuss around with allocations just to do some basic string manipulation... (Alocate space, calculate the memory offset insure the last character was a 0x00...) aka making development really easy for buffer overflow errors if you missed a step.

Re:Not all code can be done in parallel

[Nursie]

"What the new languages and OS's are doing, are just making it easier for developers to make code that runs on parallel processors. However most of us are not trained to write parallel code."

Well you bloody well should be, it's basic stuff.

Parallelism has been around for over 20 years now, not to mention the related discipline of distributed computing. It's not new. It's not *that* hard. You don't need to parallelise every last goddamn algorithm if you can split the work up into jobs using thread pools, or into similar tasks.

You think the people that make apache analyse every string comparison they do to see if they could do it more efficiently across a set of vector cores? Well maybe, but most likely they use task parallelism to get multiple threads executing different but comparatively large chunks of code.

This is not a distraction from software development, it's doing it well. And if you're afraid of a little bit of memory allocation then you're doing it wrong...

Re:Something is wrong with Win7 power management

[sunderland56]

Windows 7 (like all modern versions of Windows) does nothing with the BIOS at all - the BIOS ceases running as soon as Windows starts booting. You don't even need to *have* a BIOS to run Win7. And, if a power cycle fixes the issue, it clearly is not a BIOS problem.

If the device drivers for your motherboard have a bug - which sounds more like the cause of your issue - then that isn't a Microsoft problem at all, since they didn't write the drivers. Contact Abit for support.

Ouch

[TheRaven64]

I should know better than to click on InfoWorld links, but I think I just lost about 10 IQ points as a result of reading that article.

In summary, Windows 7 now tries to keep threads on the same processor. It has been known for about 15 years that this gives better cache, and therefore overall, performance. Any scheduling algorithm developed in the last decade or so includes a process migration penalty, so you default to keeping a thread on a given processor and only move it when that processor is overly busy, another one is not, and the difference is greater than the migration penalty (which is different for moving between contexts in a core, between cores, and between physical processors, due to different cache layout). This also helps reduce the need for locking in the scheduler. Each CPU has its own local run queue, and you only need synchronization during process migration.

If Vista, or even Windows Server 2003, didn't already do this, then I would be very surprised. FreeBSD and Linux both have done for several years, and Solaris has for even longer. Fine-grained in-kernel locking is not new either; almost every other kernel that I know of that supports SMP has been implementing this for a long time. One of the big pushes for FreeBSD 5 (released almost a decade ago) was to support fine-grained locking, where individual resources had their own locks, and FreeBSD was a little bit behind Linux and a long way behind Solaris in implementing this support.

Re:Power savings

[VGPowerlord]

From what I've seen, unless you're on a Core i7, you're not getting the power savings.

The 17% power savings mentioned on page 3 of the article is primarily for the Intel Xeon 3500 and 5500 lines (the Nahalem processors), which shut off power to cores that aren't being actively used. The other linked articles go into this more in depth.

Re:I disagree with *you*

[TheRaven64]

Lots of things affect performance. One of the big things is cache usage. A L1 cache miss costs around 10 cycles these days. A L2 cache miss costs 200 or more. If you move a process (or thread) between cores on the same die with a shared L2 cache, then every load or store instruction for a little while will cause a L1 cache miss. If you move them between processors with no shared cache, then every access will cause a L2 cache miss. If, every time you schedule a thread, it is on a different processor then, given that a typical scheduling quantum is only 10ms, your thread will spend most of its time loading data from main memory to cache. This will show up as 100% CPU usage, but will only be getting something like 10% of the maximum theoretical throughput for that CPU. Improve processor affinity, and you can easily see a large speedup relative to this.

Linux is better that Snow Leopard

[Timothy Brownawell]

Suck it, transitive property.

Re:Did we really expect different?

[DrXym]

You might not care about potentially 17% CPU power savings. I expect large enterprises who run 10,000 PCs including data centers would be very interested.

As for Windows 7 being an improved OS, yes it is. It is a substantial improvement over XP and Vista in a variety of ways such as security, virtualization support, performance on multi-core processors, support for 64-bit processors, desktop usability etc. Perhaps none of them matter to you or don't matter enough to switch but that's besides the point.

Re:Something is wrong with Win7 power management

[L4t3r4lu5]

Latest ABIT BIOS resolves a lot of issues with the temperature sensor on IP35 boards. Check the ABIT forums.

And work on your Google-fu.

Re:Not fast enough

[mister_playboy]

I see you are using Windows 7... :)

Re:Something is wrong with Win7 power management

[DoofusOfDeath]

If the device drivers for your motherboard have a bug - which sounds more like the cause of your issue - then that isn't a Microsoft problem at all, since they didn't write the drivers. Contact Abit for support.

I think that's being a little too easy on Microsoft. Getting drivers right is a shared effort of both the hardware vendor and MS. Both parties need to do their jobs right in order for the overall system to work.

Even if it is a bad driver, one might blame MS for not making Windows 7 sufficiently compatible with Vista at the device-driver-interface level. Or for building an ecosystem in which closed-source, maintainable-only-by-the-OEM drivers are the norm, etc.

I think the best we can say here is that the MS-Abit team seems to have produced a bug.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Did we really expect different?

[Gadget_Guy]

Windows 7 is NOT as or Faster than XP. PERIOD, stop the lies already.

Did you even read the article? There's a simple performance table on the first page, followed by the analysis:

These results suggests that when considering Windows 7, performance should be viewed as a reasonable justification for upgrading from Windows XP, but not a driver for migration from Vista.

Re:Something is wrong with Win7 power management

[ettlz]

I believe fan control in a protected-mode operating system operates in one of the following ways.

• ACPI embedded controller, a separate microprocessor in the chipset that runs its own firmware (typically packaged alongside the BIOS) that monitors the temperature and controls fans in manner orthogonal to the goings-on of the rest of the system.
• System-management mode where, upon detecting some thermal condition, the chipset puts the CPU into a special operating mode that executes a particular piece of BIOS code presumably to emulate the above. In this case, SMM BIOS code is executed. This happens without the knowledge or control of the operating system.
• Protected-mode ACPI control whereby the OS kernel runs the ACPI tables (read from the BIOS on boot) on a virtual machine. These tables include some bytecode to activate the fan once a trip-point is reached. x86 binary found in the BIOS is not invoked here.

The first is clearly the most desirable, as SMM is just plain wrong, and hardware protection should not rely upon the stability of the operating system.

What's happening in your case could be a problem with the EC somehow becoming confused, which is likely either a BIOS or EC firmware bug.