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.
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
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.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
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
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
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.
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.)
Come on, look at the feature comparisons, and tell me which actual features of Ultimate make it any faster than Professional, or even Home Premium.
If Ultimate was actually faster than any other version of 7, wouldn't it be in tech news sites everywhere? Ultimate is about more features, not about more speed.
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.
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.