Generational Windows Multicore Performance Tests
snydeq writes "Windows XP, Windows Vista, and (soon) Windows 7 all support SMP out of the box, but as InfoWorld's Randall Kennedy notes, 'experience has shown that multiprocessing across discrete CPUs is not the same thing as multiprocessing across integrated cores within the same CPU.' As such, Kennedy set out to stress the multiprocessing capabilities of Windows XP, Windows Vista, and Windows 7 in dual-core and quad-core performance tests. The comprehensive, multiprocess workload tests were undertaken to document scalability, execution efficiency, and raw performance of workloads. 'What I found may surprise you,' Kennedy writes. 'Not only does Microsoft have a firm grasp of multicore tuning, but its scalability story promises to keep getting better with time. In other words, Windows Vista and Windows 7 are poised to reap ever greater performance benefits as Intel and AMD extend the number of cores in future editions of their processors.'"
Not really, wasn't one of the major complaints about Vista that they were changing the OS architecture to tune multicore processors to the detriment of single core processors?
I tried RTFA (sorry, please mod me done for this ;) but, after clicked the "print" version, I couldn't find anything that looked like a benchmark report. No numbers. No tables. No graphs. All I saw was a page of [[weasel words]] or something like that.
Sigh..
Colorless green Cthulhu waits dreaming furiously.
Ok so who is faster XP, or Vista?
The header says Vista and Windows 7, but yet in the article:
It should come as no surprise that Windows 7 performs very much like its predecessor. In fact, during extensive multiprocess benchmark testing, Windows 7 essentially mirrored Vista in almost every scenario. Database tasks? Roughly 118 percent slower than XP on dual-core (Vista was 92 percent slower) and 19 percent slower than XP on quad-core (identical to Vista). Workflow? A respectable 38 percent slower than XP on dual-core (Vista was 98 percent slower) and 59 percent slower on quad-core (Vista was 66 percent slower).
http://www.infoworld.com/article/09/01/22/03TC-windows-multicore_4.html
So therefore Vista and Windows 7 suck in performance to XP?
"You can't make a race horse of a pig"
"No," said Samuel, "but you can make very fast pig"
Oh? That's quite a claim.
"DRM" only kick in the moment you play hi-def media with copy-protection bits enabled only. Vista is in some tests ever-so-slightly slower than XP, but then XP was to 2k, 2k to 98, etc, etc. It's a phenomenon known as "more code".
I'd appreciate it if you could justify any of these claims with say some evidence? Not the Auckland guy though, his claims were debunked rather thoroughly a long time ago.
throw new NoSignatureException();
As a HPC developer, there's a few areas where XP falls down. With the release of the new Core i7 line from Intel, the end of the FSB is in sight. Both Intel and AMD now use a ccNUMA memory architecture, which has tremendous implications on software design. In short, if your software isn't aware of the system's memory topology, you're going to end up with most of your memory traffic going over the processor interconnects and that's a substantial performance hit over going directly to memory (2-4 times slower).
XP's NUMA support is very weak. Sometimes the easiest solution is to write your own allocator (and preallocate huge chunks of ram).
And before somebody comes along and says 'no real HPC is done in Windows!' there are a lot of old, crusty engineering software packages that everybody is scared of porting.
All you MS apologists and shills have the same talking points: (1) DRM is harmless because it isn't invoked unless you're play DRMed content (in which case you *want* it), and (2) Don't quote Peter Gutmann (the "Auckland guy") because he's been debunked.
"The Auckland guy" has most definitely not been debunked. The only serious (using the term loosely) efforts I know of have come from Microsoft itself and from the Microsoft's ad agency, ZDNet. Gutmann showed the ZDNet critics for the idiots that they are (not that it wasn't already pretty obvious on the face of it), and the Inquirer exposed the Vista team's response for the spin that it was.
"The Auckland guy" is a respected academic computer scientist and security and cryptography expert who is talking in his field of expertise. Everything he says is based on Microsoft's own developer docs or device manufacturer docs. He cites his sources. He explains it all in technical detail. And unlike his opponents his fortunes aren't tied to this argument.
The truth scares you shills so much you have to try to discredit and suppress him at every turn. That's why you say thing like "Stop quoting the Auckland guy, he's been thoroughly debunked." I hate to break it to you, but this random debunked guy from Auckland has Bruce Schneier on his side. It's not hard to tell the difference between the experts and the shills in this debate, as long as the experts get the exposure they deserve. That's why people keep posting links to the "Auckland guy" despite your desperate protests. I know who I trust.
Read Peter Gutmann's excellent article here:
http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.html
It's with handling DRM (not specifically Microsoft's implementation). The fact that Microsoft MUST handle DRM is the slowdown.
Take a look at it this way:
Code Execution Path w/out DRM
Run
Function
Function
Function
End
Code Execution Path w/ DRM
Run
DRM Check
Function
DRM Check
Function
DRM Check
Second DRM Check
Function
End
One is obviously taking longer than the other.