Discussion:
How to run Virtual PC faster on a Mac?
(too old to reply)
A***@officeformac.com
2009-09-12 18:11:32 UTC
Permalink
Operating System: Mac OS X 10.5 (Leopard)
Processor: Power PC

How to run Virtual PC faster on a Mac?

My Processor is 1.33 Ghz PowerPC G4 with 1.25 GB Memory.
Mac G
2009-09-12 19:07:49 UTC
Permalink
Post by A***@officeformac.com
Operating System: Mac OS X 10.5 (Leopard)
Processor: Power PC
How to run Virtual PC faster on a Mac?
My Processor is 1.33 Ghz PowerPC G4 with 1.25 GB Memory.
VPC WinXP on my G4/1.25 1.5GB ram Tiger is very slow on CPU intensive
operations. CPU emulation is just slow.

I got an Intel Mini, now use Sun's Virtual Box and WinXP.
It's very fast, another world. May my VPC rest in peace!
Michael Vilain
2009-09-13 06:55:20 UTC
Permalink
Post by Mac G
Post by A***@officeformac.com
Operating System: Mac OS X 10.5 (Leopard)
Processor: Power PC
How to run Virtual PC faster on a Mac?
My Processor is 1.33 Ghz PowerPC G4 with 1.25 GB Memory.
VPC WinXP on my G4/1.25 1.5GB ram Tiger is very slow on CPU intensive
operations. CPU emulation is just slow.
I got an Intel Mini, now use Sun's Virtual Box and WinXP.
It's very fast, another world. May my VPC rest in peace!
There's a help feature in VPC that outlines optimizing XP for running
under VPC. I turned off themes and security from msconfig, all the
specialized display features under the System Advanced control panel,
and disabled restore and remote desktop.

Look around the help pages for VPC. You'll find it.
--
DeeDee, don't press that button! DeeDee! NO! Dee...
[I filter all Goggle Groups posts, so any reply may be automatically by ignored]
unknown
2009-10-10 12:53:49 UTC
Permalink
Post by A***@officeformac.com
Operating System: Mac OS X 10.5 (Leopard)
Processor: Power PC
How to run Virtual PC faster on a Mac?
My Processor is 1.33 Ghz PowerPC G4 with 1.25 GB Memory.
Best advice I can give you is to:

- use hibernation as often as you can

Virtual PC offers a feature that allows a virtual machine to be
suspended rather than
be shut down. Use this as often as you can, as this will help you
get into and out
of your virtual machine without costly startup and shutdown
operations. It also has
the side effect of clearing out the code cache of code that has been
used early on in
the boot process but has never been flushed, giving you more code
cache space for
translated code that Virtual PC actually needs to use.

The more translated code VPC gets to execute, the faster the
emulation. Once VPC
needs to translated more code from x86 to PowerPC, VPC takes costly
performance hits.
And unlike modern virtual machines like Java, Virtual PC doesn't
flush its code cache
very often.

- watch what you run, and how you run it

Virtual PC has a very small code cache size compared to the size of
Windows XP itself,
let alone any applications you care to run on it. When Connectix
developed Virtual PC,
they were implementing a system that could run Windows 95 at the
time, so to me it
appears that the code cache was big enough to accommodate running
Windows 95.

However, on Mac OS 7.5 through to 9.2, Virtual PC (up to version 6)
had a code cache
size which users could configure through the use of the Mac OS's
application partition
size (the amount of memory an application can reserve via the
Finder's Get Info window
for the Virtual PC application icon). On Virtual PC for Mac OS X,
this code cache size
is fixed to approximately 32 MB... insufficient to run anything
larger than Windows 98.
So, for Windows XP and Windows 2000, the code cache is a very
limited resource.

All you can do to better manage this resource is to make sure that
you run the computer
with only one application at a time. Because most Windows 2000/XP
applications have a
memory footprint of larger than 20 MB, running more than one is
bound to cause cache
thrashing -- remember, the code cache is shared between both
operating system code
(Windows itself) and any apps you run. Running multiple
applications concurrently will
reduce the effectiveness of the code cache to near-zero, meaning
your Mac will spend
more time translating instructions from x86 to PowerPC than actually
running your
Windows applications (as PowerPC code).

- keep Virtual PC running, even if you're not using it

this gives Virtual PC time to inspect its code cache, and flush out
code it isn't using.
It appears to me that Virtual PC uses a pretty crude "timeout" mechanism for
invalidating code, using an oldest-code-first algorithm for clearing
the cache. The
longer Virtual PC is kept running, even if Windows is idle, the
better Virtual PC can
manage its code cache.

- keep your video card memory allocation as low as possible

the code cache shares its memory space with the emulated video card
hardware.
Increasing the size of the video card capacity will reduce the size
of the code cache.

The code cache is at the heart of Virtual PC's x86-to-PowerPC
instruction translation
mechanism, however, on Mac OS X, it's also the most severely
restricted. By watching
what you run and how you run your applications within Virtual PC, you
can wring out as
much performance as your G4 or G5 processor can dish out, but thanks to
the small, fixed
size of the code cache in Virtual PC for Mac OS X, you'd have to be
spending a long time
in a relatively small application to get the most performance out of
the virtual machine.
Changing what code you run will cause Virtual PC to translate more
instructions as the
code it needs is not in the code cache, reducing the virtual machine's
performance.

This is all I can offer out of using Virtual PC 7.0.3 on an 867 MHz 12"
PowerBook G4
w/ 640 MB of RAM for over 4 years. While this machine is no speed
daemon by any stretch
of the imagination, it was useful to some degree, even whilst running
applications such
as Visual BASIC 6 and VisualAge Smalltalk. These two applications were
small enough
to run in a cut-down installation of Windows XP for Virtual PC to run
with acceptable
levels of performance.

Hope this proves useful to you.


--tonza
A***@officeformac.com
2009-10-10 16:14:27 UTC
Permalink
Thank you so much for this explanation !

Loading...