Slashdot Mirror
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."
Suck it, nerds.
Nooo! I was hoping that power consumption would continue to increase! Sooner or later our PCs would require 1.21GW!
It pays to be obvious, especially if you have a reputation for being subtle.
'What might be surprising is that Windows 7's multithreading changes did not deliver more of a performance punch,'
No, it's not surprising.
Great minds think alike; fools seldom differ.
Suck it, Microsoft drone.
Is this really that surprising? I mean, splitting threads over different cores, having two cores still isn't going to be that much faster than one. I wouldn't expect to see much a gain just from this any more than I would on Linux or BSD. Still, every little bit helps.
Seeing the performance increase and in some cases decrease from Vista to 7, I don't see that as a selling feature either.
What does intrigue me is the ability of the OS to allocate threads to the different cores. That is something I would want to learn more about.
Basically, unless you're on a workstation and running intensive applications, you're not going to benefit from buying Windows 7 for an old machine.
It's NOT me! It's the meds! I'm on 1000mg of Fukitol.
So you've got a Linux fan and not a Windows fan. Not surprising on this site.
My webcomic
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.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
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.
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.
I am TheRaven on Soylent News
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.
I am TheRaven on Soylent News
Do you mean the BKL? It's hurt, but it's still there
IranAir Flight 655 never forget!
I actually have a system using that same motherboard. The BIOS on this board does have a tendency to run the CPU fan at full speed after rebooting. Even when it does work, it does not do a very good job at adjusting fan speeds based on the CPU temperature.
In my experience it is best not to rely on the BIOS control on these boards and instead use a software solution to adjust the fan speeds.
Under Windows you can use the Abit uGuru software to automatically adjust fan speeds based on temperature thresholds you specify which works quite well (at least under XP and Vista, haven't tested it on Windows 7 yet.) You can also use SpeedFan, but I prefer the Abit utility since it appears to react to temperature changes a bit faster.
I haven't run Linux on this board but you may be able to find a Linux application that is also capable of adjusting fan speeds.
Maybe he's a mac user. 10.1-> 10.2 -> 10.3 all sped up my 550 mhz powerbook back in the day. 10.4 was the first OS update to slow down my computer (10.3.9 was screaming fast on my laptop). 10.4.1 fixed some speed issues, and by the time 10.4.5 came out it was nearly as fast as 10.3.5 or so. So it's possible to upgrade your OS and end up with a faster feeling system. There used to be a mac benchmarking site, mac feats that documented that each release was in fact marginally faster in most every aspect.
moox. for a new generation.
Suck it, transitive property.
In the article,t he numbers show that Vista SP2 gives a clear edge over Win XP SP3 in every case. I'm surprised that this wasn't commented on, given the general perception of Vista's sluggishness.
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.
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.
Finally had enough. Come see us over at https://soylentnews.org/
I see you are using Windows 7... :)
Do what thou wilt shall be the whole of the Law
They tested Windows ULTIMATE, the best of the newest against the oldest patched-up version of XP. And it only saved a marginal amount of power. and may be slightly faster in some operations. What about the versions that the average Joe is going to be running? There are Starter, Home, Home Premium, Professional, and Ultimate; each with an increasing price requirement (http://windows.microsoft.com/en-us/windows7/products/compare). How does the "basement" version compare to XP SP3 (or against the various flavors of XP)? Still not apples-to-apples (oh, I hate the puns from that), but might give a better representation of what's going on.
Chaos maximizes locally around me.
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.
What you're probably thinking of is patch for the Big Kernel Lock(BKL) in Linux which basically was the origin of SMP scaling in Linux. This article is talking about the kernel dispatcher lock in NT. Two separate things.
Yeah, it's possible for an OS to slow down your computer by improperly handling tasks, but you can't depend on finding and correcting them. (They may not even be there.) It's understandable to be annoyed if an OS update slows down your system; it's something else to expect a speed-up from out of nowhere.
Also, Windows 7 users are reporting a subjective improvement in response much like you report in OS X's progression.
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.
If we take this as true, it's an example of why for some people, paying a premium for a Macintosh is worth the cost and can make sense. You give up the freedom to do all sorts of things (like get a machine with specs perfectly suited to specialized needs for example), but you gain freedom from a lot of problems of this sort.
(Just trying to plant this in the heads of the countless people who argue there's literally no rational reason to buy a Mac, and only fanboys would even consider it. You won't see me argue that there's no such thing as an Apple fanboy, but I will argue that the fanboy phenomenon is not all there is to Apple's sales.)
Is that really the best you can come up with?
Some of us have actually don't development on large Unix servers. There
really isn't any reason the OS should be getting in the way. The
bottlenecks should be all in your applications. A well built application
should be able to light up your entire server, fully exploit all of it's
hardware and scale well while doing it.
Whether or not you overwhelm your scheduler is also something that should
be an application problem rather than an OS problem.
A Pirate and a Puritan look the same on a balance sheet.
Windows 7 (as well as I think certain versions of Vista) provides support for booting from EFI rather than a BIOS. While, yes, it's still a "BIOS-like" bootstrap loader, Windows 7 is not reliant on any specific BIOS functions.
Any examples?
(Score:-1, Troll)
There' s one ---^ :)
Err... you DO know what first takes control of the computer when you turn it on right?
That would be a firmware interface. BIOS is one example of a firmware interface - and is the defacto standard on a PC - but it isn't the only one. You can indeed run all recent versions of Windows without a BIOS.
Comment removed based on user account deletion
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.
If I'm reading the chart correctly, it appears that Vista rivals Windows 7 in all benchmarks and even beats it in a couple.
Are we talking about the charts at http://www.infoworld.com/d/windows/windows-7-multicore-how-much-faster-325? If so, you are indeed reading them incorrectly. Vista beats 7 in two of the performance benchmarks and loses in two of the others, by fairly close margins all around. The catch, though, is that 7 beats Vista by a significant margin in power efficiency.
Karma: Terrifying (mostly affected by atrocities you've committed)
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.
Only the 64bit versions do. Granted, all UEFI enabled machine (except some Macs) are 64bit capable, but it's still important.
Windows can do CPU microcode updates:
http://support.microsoft.com/kb/936357
I bet a lot of enterprises don't have a Corei5/i7 to actually save from a complete core powe down that nahelems can do. I bet in a few years, this will help desktop comps a lot more as they get upgraded. Also, Win2k8 R2 share a lot of this stuff and a Dual socket i7 Xeon could potentially save a lot of power during low use times
Typically, when you've swapped out a process on the CPU, most of the L1 cache is going to be evicted by the next process which runs. A considerable amount of data will remain in the L2 cache but the L1 cache will be quite polluted by the intermediate processes that run between time slices. Therefore, L2 is the more important consideration.
The system they performed testing on has a CPU with a single shared L2 cache so processes moving between CPU cores are not necessarily slower than processes parked on a single core. Since the L2 is shared, there are no L2 cache misses introduced by swapping cores.
A CPU that would better show performance improvements on Windows 7 by higher thread affinity would be one with a split L2 cache like the Intel Kentsfield Core 2 Quad Q6600. The Q6600 would have a lot of L2 cache misses on Vista and XP that would be eliminated by the optimization in Windows 7.
I also find it odd that if you are currently running Windows XP quite happily on, say, a single core Pentium 4 CPU with 1GB RAM and a 400W PSU, why this would be a power saving when you probably need a dual-core CPU with 4GB RAM running a 500W CPU to get Windows 7 running equally as fast?
Gentoo Linux - another day, another USE flag.