Vista slower in compute-intensive work?

[VirtualLarry]

This is a semi-continuation of a discussion that I was having with bsobel in another thread.

I personally don't know what to say about the CPU scheduler in Vista, since I'm not familiar. But I do have another data-point to add to this discussion.

I've recently started participating in http://www.seventeenorbust.com/ , a distributed-computing project involving searching for prime numbers, something to do with the "Serpinski Conjecture". The client gets downloaded, and contacts their server, and computes work-units locally, and eventually forwards the results to the server. I also got my friend interested in this. (Check the Distributed Compuiting forum on AT for more info.) The client measures work in something called "cems/sec".

On two identical laptops, one running Vista Home Premium, one running XP Pro. Pro was a recent fresh install, Vista has had all of the pre-installed bloatware removed, and the Aero theme disabled. The SoB client was configured for two cores using the service install method. The CPU is a 1.6Ghz C2D Merom chip.

On XP Pro, each core would compute 2.8M cems/sec and 2.9M cems/sec.
On Vista, each core would compute 1.4M cems/sec and 1.8M cems.sec.

Quite a large difference.


Another data point: http://forums.anandtech.com/me...=2064330&enterthread=y

Problems with idle-priority threads in Vista slowing down their foreground tasks.


So the real question is, what is really going on here? Is Vista defective? These numbers aren't due to hardware drivers or anything else of those sorts, since the software apps in question are purely computational apps.

 

[Smilin]

If you were calling in for support on why this app runs slow we would be starting with perfmon counters on the processes in the system. Why don't you collect that and post it somewhere?

Lacking that data you can do nothing but speculate.

BTW there is only on idle priority thread and it belongs to the idle process. Did you mean low or background priority?

Other questions:
What priority does this app run at?
What is the service install method (assuming we run as a noninterractive service)?
If "service" what account is it running under? What happens if you set it to the logged on user?
What other install options are available and does the performance differ?






edit: answered one of my own questions.

 

[mechBgon]

Also, based on my past knowledge of SoB, let me ask if both clients are using the same k and n values. It seems, uh, pretty unlikely

In general, be careful when using DC apps for benchmarking. I speak from experience.

Also, is Vista set for the maximum-performance profile in the power settings, where it'll run the CPU full-throttle 100% of the time?


edit: Since I have an XP/Vista dual-boot on my main system, I did a quick test, rendering the same scene in trueSpace (3D modelling/animation app) using multithreaded raytraced rendering. The rendering times are within a second of eachother, as near as I could time it by hand. This is a 100% CPU-bound situation.

 

[BD2003]

Originally posted by: VirtualLarry
This is a semi-continuation of a discussion that I was having with bsobel in another thread.

I personally don't know what to say about the CPU scheduler in Vista, since I'm not familiar. But I do have another data-point to add to this discussion.

I've recently started participating in http://www.seventeenorbust.com/ , a distributed-computing project involving searching for prime numbers, something to do with the "Serpinski Conjecture". The client gets downloaded, and contacts their server, and computes work-units locally, and eventually forwards the results to the server. I also got my friend interested in this. (Check the Distributed Compuiting forum on AT for more info.) The client measures work in something called "cems/sec".

On two identical laptops, one running Vista Home Premium, one running XP Pro. Pro was a recent fresh install, Vista has had all of the pre-installed bloatware removed, and the Aero theme disabled. The SoB client was configured for two cores using the service install method. The CPU is a 1.6Ghz C2D Merom chip.

On XP Pro, each core would compute 2.8M cems/sec and 2.9M cems/sec.
On Vista, each core would compute 1.4M cems/sec and 1.8M cems.sec.

Quite a large difference.


Another data point: http://forums.anandtech.com/me...=2064330&enterthread=y

Problems with idle-priority threads in Vista slowing down their foreground tasks.


So the real question is, what is really going on here? Is Vista defective? These numbers aren't due to hardware drivers or anything else of those sorts, since the software apps in question are purely computational apps.

Given the fact that the VAST number of computationally based benchmarks have shown little to no performance difference between the Vista and XP core, I'd say its pretty obvious that either the app or PC is not configured identically in both cases, or there is some underlying incompatibility with Vista that is slowing that particular app down - going as far as to say or imply that Vista is intrinsically slower (by near 50% no less) is categorically absurd. You may have indeed uncovered an issue with that app, but no more.

 

[bsobel]

going as far as to say or imply that Vista is intrinsically slower (by near 50% no less) is categorically absurd. You may have indeed uncovered an issue with that app, but no more.

There are plenty of XP vs Vista benchmarks available, Toms Hardware has an ok one. Basically some things are slower, some things are faster. Overall they are basically the same. The one case where there is a legit issue which I can see leading to performance differences (in XPs favor) which is the user address space concern that the Anandtech article talks about. That appears to be a design flaw and needs to be corrected.

p.s. Gave up on the HT thread eh?

 

[fierydemise]

My completely uneducated guess is that Seventeen or Bust is running like most DC clients at a low priority where it is being forced to share CPU cycles with everything Vista does at system idle unlike in XP where it gets basically free reign.

 

[VirtualLarry]

Originally posted by: Smilin
If you were calling in for support on why this app runs slow we would be starting with perfmon counters on the processes in the system. Why don't you collect that and post it somewhere?

Ok, I can fire up perfmon, but what would I be looking for? A graph of CPU time for all the processes in the system? That's probably going to be a crowded graph. Or are you looking to see if everything else but this app is a flatline? Good idea.

Originally posted by: Smilin
BTW there is only on idle priority thread and it belongs to the idle process. Did you mean low or background priority?
Other questions:
What priority does this app run at?

When most people are referring to "idle", I think they mean "Dynamic Idle" (MS term), meaning priority 1. (Priority 0 is true idle, and doesn't run any programs, AFAIK.) I haven't tested whether this app actually runs at priority 1 or not, I'm just assuming, based on my knowledge of what "idle" usually means.

Originally posted by: Smilin
What is the service install method (assuming we run as a noninterractive service)?
If "service" what account is it running under? What happens if you set it to the logged on user?
What other install options are available and does the performance differ?

Service install method is "sobsvc -i", it installs it as a service, but also allows the service to interact with the desktop". It runs under LocalSystem, AFAIK.

The other option is to simply run the client .exe without installing the service, but that only runs on a single core and not dual-core. To run dual-core (one client instance per core), you also have to do "sobsvc -p:2" (before starting the service). There doesn't appear to be any performance difference that I can see, simply running the client .exe versus installing it as a service.

However, there can be a performance difference running single-core, versus dual-core. On my friend's machine with an E6300 @ 2.65Ghz, he gets 4.9M cems/sec running the single client .exe, and 4.9M and 5.0M cems/sec running dual-core. On my rig (E4400 @ 2.81Ghz), I get 4.9M cems/sec running the single client .exe, and 3.6M and 3.7M running dual-core (two clients). So on my rig there is a slowdown running two clients together. I'm running DDR400 memory and 281FSB, he's running DDR2-800 and 375FSB. I'm not sure whether the slowdown is due to cache issues or FSB issues. Both the E4400 and E6300 have 2MB L2 cache, but the E4400 is an Allendale and the E6300 is a Conroe. I'm also running downloads constantly in the background, his machine is mostly idle. (That could likely be the difference, I should test with no downloads going on I suppose.)

One other thing, my friend specifically showed me that the laptop running Vista was running in "High Performance" power mode. Both laptops were on AC power.

Edit: Verified on this box (a 3400+ running at 2.44Ghz) that the SoB client worker thread is running at base priority: 1, dynamic priority:1, using ProcessExplorer.

 

[bsobel]

Originally posted by: fierydemise
My completely uneducated guess is that Seventeen or Bust is running like most DC clients at a low priority where it is being forced to share CPU cycles with everything Vista does at system idle unlike in XP where it gets basically free reign.

That is a great point and would explain the behaviour seen.

 

[BD2003]

Originally posted by: bsobel

going as far as to say or imply that Vista is intrinsically slower (by near 50% no less) is categorically absurd. You may have indeed uncovered an issue with that app, but no more.

There are plenty of XP vs Vista benchmarks available, Toms Hardware has an ok one. Basically some things are slower, some things are faster. Overall they are basically the same. The one case where there is a legit issue which I can see leading to performance differences (in XPs favor) which is the user address space concern that the Anandtech article talks about. That appears to be a design flaw and needs to be corrected.

Yep, but the difference is usually so small that its not even worth mentioning.

p.s. Gave up on the HT thread eh?

What HT thread?

 

[bsobel]

What HT thread?

This one He hadn't answered it in a while, I thought he was finally going to let it die when he posted this thread and didnt' respond there. But nope, he went ahead and responded last night. It's sad really.

 

[BD2003]

Originally posted by: bsobel

What HT thread?

This one He hadn't answered it in a while, I thought he was finally going to let it die when he posted this thread and didnt' respond there. But nope, he went ahead and responded last night. It's sad really.

Well, the lecture was priceless.

FWIW, VL does have the occasional moment of clarity amidst the nonsense, but it really is overshadowed by a complete lack of understanding of his lack of understanding, arguing for argument's sake rather than learning something from his errors or letting minutiae that can be considered technically right take precendence over common sense and rationality.

He's not a troll like quinton mcleod though (wtf ever happened to him anyway?), just a bit misguided.

 

[Nothinman]

My completely uneducated guess is that Seventeen or Bust is running like most DC clients at a low priority where it is being forced to share CPU cycles with everything Vista does at system idle unlike in XP where it gets basically free reign.

Vista does probably do more in the background which would steal cycles from the SoB client but I wouldn't expect a 50% drop. At least not after the initial "settle in" stuff Vista does finishes up.

 

[bsobel]

Originally posted by: Nothinman

My completely uneducated guess is that Seventeen or Bust is running like most DC clients at a low priority where it is being forced to share CPU cycles with everything Vista does at system idle unlike in XP where it gets basically free reign.

Vista does probably do more in the background which would steal cycles from the SoB client but I wouldn't expect a 50% drop. At least not after the initial "settle in" stuff Vista does finishes up.

Yea, but we have no other data, we don't know if the machine got defragged, the indexer was running, etc. So, sans that it's a useless comarison.

 

[bsobel]

FWIW, VL does have the occasional moment of clarity amidst the nonsense, but it really is overshadowed by a complete lack of understanding of his lack of understanding, arguing for argument's sake rather than learning something from his errors or letting minutiae that can be considered technically right take precendence over common sense and rationality.

Agreed, if he actually wanted to enter into a conversation about some of these issues he'd probably learn something. But instead he comes in with off the wall positions and just digs his heals in. Of course he gets so owned in the process he's convinced I have some grand conspiracy against him. I tend to find when one person is disliked/not respected by some people, it might be a personality clash and both sides probably have some merit, but if its by all people I generally blame the person not everyone else.

He's not a troll like quinton mcleod though (wtf ever happened to him anyway?), just a bit misguided.

Well, the HT thread is just like any number of other threads he starts or jumps into. He makes point A, is shown to be wrong, and then tries to claim point B was the point all along (like with the other thread on Vista's scheduler performance. When shown it wasnt slower than XP he claimed well the sound stack was longer, and thats what he meant by slower overall, while prevously JUST talking about the kernel scheduer. It gets old).

He flipped the troll bit with me back on the anti-hibernation crusade he went on. It was more laughable than the HT thread.

His most recent antics where to bash Vista all year (including mentioning how he'd never leave XP) and then on June 29th started a complaint thread about the Vista Home promotion was ending at midnight that night and how he was hoping to get in on it on time. Classic.

Basically he finds and edge case he can, and then tries to make that into the most important issue in the world. As an example OMG home basic 64 is limited to 8gigs of memory. Can you believe that, its a MS conspiracy to keep that from the home basic crowd (you know, the real power user base...)

 

[bsobel]

Vista has had all of the pre-installed bloatware removed, and the Aero theme disabled.

Not that I think it's related to your 'issue', but you do realize on most machines aero is faster than non-aero since the GPU is baiscally free and aero offloads much of the rendeirng to it.

 

[VirtualLarry]

Originally posted by: bsobel
His most recent antics where to bash Vista all year (including mentioning how he'd never leave XP) and then on June 29th started a complaint thread about the Vista Home promotion was ending at midnight that night and how he was hoping to get in on it on time. Classic.

As usual, Bill is suffering from minor delusions. I've never claimed that I'd "never leave XP". Yes I bash Vista, and I'll continue to bash Vista. That doesn't mean that I'll never upgrade - everyone is forced to upgrade, eventually. I don't have to like it though.
(I even went and bought a ReadyBoost drive today, imagine that.)

Originally posted by: bsobel
Basically he finds and edge case he can, and then tries to make that into the most important issue in the world. As an example OMG home basic 64 is limited to 8gigs of memory. Can you believe that, its a MS conspiracy to keep that from the home basic crowd (you know, the real power user base...)

More delusions, I never said it was a conspiracy, only that MS hasn't exactly been forthcoming about those limitations, at least not in a clear way to consumers.

 

[VirtualLarry]

Originally posted by: bsobel

Vista has had all of the pre-installed bloatware removed, and the Aero theme disabled.

Not that I think it's related to your 'issue', but you do realize on most machines aero is faster than non-aero since the GPU is baiscally free and aero offloads much of the rendeirng to it.

Yes, but in this case it was using integrated graphics, and all of the additional horsepower for the graphics would suck up memory bandwidth, and SoB appears to be very bandwidth-heavy. (IOW, GPU is not "free", it has a heavy cost WRT memory bandwidth.)

Therefore if Aero was enabled, that might prove to be the reason behind the low scores. However, it was not enabled, according to my friend.

 

[VirtualLarry]

Originally posted by: bsobel
Agreed, if he actually wanted to enter into a conversation about some of these issues he'd probably learn something. But instead he comes in with off the wall positions and just digs his heals in.

It's "heels", and it's really funny to hear your suggestion that taking the officially-documented Microsoft position in an arguement is "off the wall". Nice.

Originally posted by: bsobel
Of course he gets so owned in the process he's convinced I have some grand conspiracy against him.

You called me a liar without justification, Bill. That's not ownage, that's a personal attack on my credibility.

Originally posted by: bsobel
Well, the HT thread is just like any number of other threads he starts or jumps into. He makes point A, is shown to be wrong, and then tries to claim point B was the point all along

No Bill, that's exactly what YOU did in the HT thread. You apparently lack the reading comprehension necessary to understand Microsoft's documentation. You know, the part where MS says that HyperThreading is supported (officially!) on W2K. You said it wasn't, I said it was. I pulled out the MS docs that say it is, and then you tried to claim that it wasn't supported because the performance on W2K is worse than XP.

You keep making weak claims on why you believe that HT shouldn't be supported on W2K - opinions that I support on a technical basis, if your anecdotal evidence is right - but it doesn't change the facts, of what is officially supported by MS. Those are the facts that I've been arguing all along, and have never changed my stance on them.

You just steadfastly refuse to see the truth as it is, because you've previously been convinced otherwise. Well, the general wisdom (regarding HT on W2K), is wrong. Since you refuse to look beyond the general wisdom, and continue to parrot it, then you are wrong too.

 

[BD2003]

Originally posted by: VirtualLarry

Originally posted by: bsobel
Agreed, if he actually wanted to enter into a conversation about some of these issues he'd probably learn something. But instead he comes in with off the wall positions and just digs his heals in.

It's "heels", and it's really funny to hear your suggestion that taking the officially-documented Microsoft position in an arguement is "off the wall". Nice.

Originally posted by: bsobel
Of course he gets so owned in the process he's convinced I have some grand conspiracy against him.

You called me a liar without justification, Bill. That's not ownage, that's a personal attack on my credibility.

Originally posted by: bsobel
Well, the HT thread is just like any number of other threads he starts or jumps into. He makes point A, is shown to be wrong, and then tries to claim point B was the point all along

No Bill, that's exactly what YOU did in the HT thread. You apparently lack the reading comprehension necessary to understand Microsoft's documentation. You know, the part where MS says that HyperThreading is supported (officially!) on W2K. You said it wasn't, I said it was. I pulled out the MS docs that say it is, and then you tried to claim that it wasn't supported because the performance on W2K is worse than XP.

You keep making weak claims on why you believe that HT shouldn't be supported on W2K - opinions that I support on a technical basis, if your anecdotal evidence is right - but it doesn't change the facts, of what is officially supported by MS. Those are the facts that I've been arguing all along, and have never changed my stance on them.

You just steadfastly refuse to see the truth as it is, because you've previously been convinced otherwise. Well, the general wisdom (regarding HT on W2K), is wrong. Since you refuse to look beyond the general wisdom, and continue to parrot it, then you are wrong too.

Which document is this? I've never seen MS claim "support" for HT, only that its compliant and will run without error on HT systems. Those are two entirely different things.

 

[bsobel]

You called me a liar without justification, Bill. That's not ownage, that's a personal attack on my credibility.

Actually you said I did and I said 'if I did call you a liar then find the thread since that would be the thread you lied in'. I'm still waiting for you to find it. The only case I can find where I did call an OS poster a liar AND you were in the thread was a statement not directed at you. Seriously post the thread in quesiton and I'll explain my position or apologize if I was wrong.

comprehension necessary to understand Microsoft's documentation. You know, the part where MS says that HyperThreading is supported (officially!) on W2K. You said it wasn't, I said it was. I pulled out the MS docs that say it is, and then you tried to claim that it wasn't supported because the performance on W2K is worse than XP.

Funny, everyone else reading the same doc comes to the same conclusion as myself. I even gave you the names of the folks to call at MS or Intel. But you still believe we are *all* wrong.

 

[VirtualLarry]

Originally posted by: BD2003
Which document is this? I've never seen MS claim "support" for HT, only that its compliant and will run without error on HT systems. Those are two entirely different things.

Microsoft's whitepaper on HyperThreading support in Windows' OSes.
http://www.2cpu.com/Hardware/h...sis/hyperthreading.doc
(I would give you the microsoft link, but it seems to have disappeared as MS re-org'ed their site. The above is a mirror copy.)

You can also see Compaq's stance on HT support in Windows 2000, at
http://h18004.www1.hp.com/prod...reading-ossupport.html

 

[VirtualLarry]

Getting back on-topic: I have another data-point for this issue.
My C2D rig at home finished one of the proth tests (WU) in SoB, and got assigned another one. (One core finished, one core still working on the old WU.) With the old WUs, I was getting 3.4 and 3.6 Mcems/sec. With the new WU, I'm only getting 2.57Mcems/sec on that core.
So it appears that the cems/sec rating shown, does depend on the K/N values of the tests.

Shoot, maybe not, I just remembered I'm copying gigabytes off of my software RAID to a USB drive in the background, that could easily be sucking up the CPU time as well. Sorry, I just invalidated my own data-point. Maybe more conclusive evidence after I finish this copy job.

Edit:
Ok, I stopped the USB device, stopped copying, stopped downloading in the background, and stopped the service and then re-started it and let it build up an average.
I get 3.75M cems/sec (old WU), and 3.31M cems/sec (new WU). So it's still in the ballpark of what the two old WUs were, although not quite as high, as my prior numbers were with downloads going on in the background.
Edit:
With the downloads restarted, I'm getting 3.62M and 3.34M cems/sec.

 

[BD2003]

Originally posted by: VirtualLarry

Originally posted by: BD2003
Which document is this? I've never seen MS claim "support" for HT, only that its compliant and will run without error on HT systems. Those are two entirely different things.

Microsoft's whitepaper on HyperThreading support in Windows' OSes.
http://www.2cpu.com/Hardware/h...sis/hyperthreading.doc
(I would give you the microsoft link, but it seems to have disappeared as MS re-org'ed their site. The above is a mirror copy.)

You can also see Compaq's stance on HT support in Windows 2000, at
http://h18004.www1.hp.com/prod...reading-ossupport.html

Which is the same document I've seen.

All versions of the Windows 2000 operating system are fully compliant with HT and should run without error on HT-enabled systems. However, neither Windows 2000 nor any of its service packs support the identification of HT processors. The type of modifications that are required for HT processor identification and support are not typically supported in a service pack. There are no plans to introduce this support in any future Windows 2000 service pack.

Running without error on a HT processor and supporting HT are two entirely different things! Windows 2000 does not support hyperthreading.

 

[VirtualLarry]

Please take all HT discussions to this thread: http://forums.anandtech.com/me...=2073486&enterthread=y

 

[BD2003]

Originally posted by: VirtualLarry
Please take all HT discussions to this thread: http://forums.anandtech.com/me...=2073486&enterthread=y

Its not even worth discussing something you are so clearly wrong about.