Re: Cross-platform development

In article <466b11d4$0$8715$ed2619ec@xxxxxxxxxxxxxxxxxxxxxxxxxx>,
Jon Harrop <jon@xxxxxxxxxxxxxxxxx> wrote:

Timberwoof wrote:
Parallels runs in a few modes, the most exciting of which is that
Windows applications run in the full Windows environment, but their
windows and UI appear entirely within the OS X desktop. The CPU to run
the Windows processes is not emulated; the software runs directly on the
Mac's own CPU. However, it uses main RAM to run, not video RAM. That's
generally reserved for things like video (and, in Windows, some printing
functions).

Yes, fast-tracking a virtualized CPU is the easy part. Nowadays you can do
it in hardware using Intel VT.

Virtualizing the GPU is much harder and all other attempts that I am aware
of have failed (except an alpha-release of Chromium for Xen).

I have heard that Parallels does a great job on CPU virtualization, and I
can well believe that because it is now a tried and tested technique.
However, GPU virtualization is very new and very difficult. I believe
Parallels are doing pioneering work here and I'd like to know how well
their latest implementation works.

You are correct that I did make several assumptions about their
implementation. I assumed that it is not possible to do any virtualization
on the GPU, so the task of virtualizing is moved either into the driver or
into an abstraction layer behind the driver.

"The driver"? Ah. Windows does everything with drivers.

Depending how this is done,
the cost of that abstraction could be crippling, e.g. emulating PCI-E
transfers.

OS X on PPC does an interesting thing: It runs the Classic Mac operating
system as a thread so that classic apps can run under OS X. And since
the 68k emulator is part of Classic Mac OS, this setup can also run
those old applications. One of my favorites was SuperPaint, which ran
faster in emulation under a virtual OS on my G4 than it ever did on
native 68k hardware.

There is also the cost of sharing video memory between virtual
hosts.

I still think you're making possibly wrong assumptions here. The 68k
emulator environment supplies QuickDraw calls to the applications, and
these are sent to OS X. There's no performance penalty for other
applications. (Except when running Word. Whether it's an old 68k
version, a PPC Classic version, or an OS X version, that seems to
swallow up CPU cycles whether it's doing anything or not.)

Finally, high-performance video drivers are a hugely difficult
software engineering challenge and require great sophistication. If
Parallels somehow licensed nVidia's drivers and butchered them to get the
best performance then they will almost certainly have introduced bugs.

Unless the Windows video system calls are tramslated into OpenGL calls.
Then none of that hacking about is needed.

Macintosh has a long history of providing everything an application
needs, as well as a long history of saying "this hack may work, but
don't do it for it may not be supported." It also has a long history of
applications that broke the rules and broke with new releases of the OS
.... and applications that followed the rules and ran on several
generations of succeeding operating systems.

I would not speculate as to how this is actually implemented or even what
the performance trade-offs would be. However, I would like to see any hard
numbers on how fast Parallels current implementation runs, particularly
under high video memory usage (e.g. Doom 3 in Ultra quality on a 512Mb
card).

There are various articles out there but nothing I would believe:

"Parallels doesn't officially support DirectX yet, but that didn't stop us
from trying to run Quake 4 on it anyway. Alas, it was an exercise in
futility--it did not work--and in fact, at one point, even forced a
spontaneous system reboot!" -
http://reviews.cnet.com/4531-10921_7-6546370.html

This article doesn't seem to be very accurate but I can well believe that a
virtualized GPU undermines the stability of all virtual hosts running on
that physical host.

It does not seem reasonable to me to guess about the video performance
of native OS X applications based on the performance of a *game* under
emulation. If you want an indication of video performance, try this: I
upgraded my old G3/300 (ATI Rade 128 with 64MB of VRAM) with a DVD
player. Under OS X, that can play DVDs at 1024x768 without any dropped
frames.

If you have to run CPU- and video-intensive applications, then
fergoshsakes, don't run them in emulation under some other system. If
you want to develop OS X applications, then fergoshsakes, don't judge OS
X on the basis of its performance emulating Windows for games!

--
Timberwoof <me at timberwoof dot com> http://www.timberwoof.com
.

Relevant Pages

  • Re: The whole Apple can Run Windows thing...
    ... the new hardware can boot directly), the set of applications that runs ... If you're counting soft emulation, Windows can run OS/X in emulation too, ... mandates that for whatever reason cause a lot of pain to support. ...
    (rec.photo.digital.slr-systems)
  • Re: [Semi-off topic] Next PowerPC To Support Multiple OSs?
    ... Windows, they want it because of specific applications that happen to ... it doesn't take virtualization to port or run another operating ... If you take the whole API conversion idea and combine it with CPU ...
    (microsoft.public.mac.virtualpc)
  • Re: Will wine|win4lin|VMWare save my XP bacon?
    ... Not sure about your original problem, but as for emulation, it goes like ... it does not need Windows at ... Many applications run, but some do not. ... VMWare and Win4Lin run entire operating system in a virtual computer. ...
    (Debian-User)
  • Re: Recoverd mahine from SP2 nightmare
    ... It contains advice ... using Windows XP "prettifications". ... applications you do not use. ... You should at least turn on the built in firewall. ...
    (microsoft.public.windowsupdate)
  • Re: Slow startup and shutdown
    ... > applications that have always been present, ... The problem began before loading SP2 and hasn't changed. ... using Windows XP "prettifications". ... You should at least turn on the built in firewall. ...
    (microsoft.public.windowsxp.perform_maintain)