XP Screen update very slow if two processors used

[BobTheDog]

Hi,

On my MacBook pro 17" screen update is painfully slow in fusion running XP if two processors are enabled.

With one processor it is nice and fast.

Anyone else seeing this?

Cheers

Andy

[MandarMS]

can you go through the MS KB http://support.microsoft.com/kb/896256 and try installing the Update for multiple processors

[BobTheDog]

Hi There,

Installed the update, no difference in performance though.

It is quite a difference as well, running Visual Studio 2005, screen redraw with multiple processors is around two seconds, with one processor is nearly instant.

Cheers

Andy

[MandarMS]

can you which HAL is installed in Windows XP Guest OS

[BobTheDog]

Sorry I don't quite understand.

What do you want me to do?

Cheers

Andy

[InflatableMouse]

I think MandarMS was in a hurry and forgot the word "check"

Please Right Click 'My Computer', choose Manage, choose Device Manager from the tree on the left and find 'Computer' in the tree on the right. Click the + or double click it. Tell us the name of what you see below 'Computer'. It should be something like "ACPI xxx PC".

[MandarMS]

Thanks for correcting me..:8}

[BobTheDog]

Hi Guys,

It is listed as "ACPI Multiprocessor PC"

HAL.dll is version 5.1.2600.3023

Cheers

Andy

[MandarMS]

Try switching to Mac OS application performance Under VMware Fusion > Preferences

[BobTheDog]

Hi,

Still slow I am afraid!

Cheers

Andy

[KAMitchell]

Has anybody else come up with other proposed solutions for this problem? I'm having the same trouble, and it's extremely evident with GNU Emacs. Redraws are very slow, almost like watching fluid run down the screen. Almost like the Matrix.

I'm running Leopard on a 15" Santa Rosa MBP.

I tried installing the update from Microsoft, tried setting for improved Mac OS X performance. Tried reverting back to the SVGA driver from Fusion 1.0. Nothing has helped.

If I change back to one virtual processor, everything speeds up tremendously. But it would be nice to be able to use two processors when compiling software.

[KAMitchell]

I've found a workaround, though it would be nice if this was fixed in a future version of VMware, if possible.

The workaround is to turn off font smoothing. Right click the desktop, choose Properties, then Appearance tab, Effects, and turn off the option that says "Use the following method to smooth edges of screen fonts."

[Bob_Zimmerman]

The actual issue is probably that when the host has two processors and the guest has two processors, something's got to give. Keep in mind that the host still needs to emulate the guest's hardware. The host just runs out of processors to run things on. This is why two processors on the guest is actually measurably slower in every way I've seen than one processor when the host only has two.

Using two virtual processors on a host with two processors has a better than even chance of making compilation slower because of all the switching the host has to do. Now, on a 4-way or 8-way Mac Pro, it's a different story.

[pjtcb]

Bob...you're not the only one with this problem. My Win XP/Fusion installation on a MacBook Pro has been excrutiatingly slow for some time and I didn't realize the issue until I read your post...changed my settings from 2 processors to 1 and it became much faster. It's still not not as fast (or reliable) as booting straight into WinXP (Boot Camp Partition), so I will continue booting into WInXP until (hopefully) some future Fusion release cures most of the issues I've been having.

[itsme2003]

KAMitchell is correct. If you check the VMware best practices guide you will see that you should only use a dual processor VM on a dual processor real machine when you need to test the effect of dual core execution, for example race conditions, or other aspects relating to dual core behavior. Don't do it because you think you will get faster execution by having both cores working for you. It is expected to execute slower to have 2 on 2, and will likely never be "fixed." The clear, unambiguous recommendation is to run single processor VMs on dual processor/core machines, otherwise expect slowness.