Vegas+XP on Parallels 4 (and the Two-CPU Mystery)

fausseplanete wrote on 1/18/2009, 3:42 AM
On a Mac Pro, although BootCamp is obviously fastest, Vegas (8.0c) on XP Pro (32 bit) still runs usably fast in a Parallels 4.0 virtual machine with 2 CPUs, about 3 times slower than BootCamp but still comparable to a dual-core.

Following these successful tests, I upgraded my license from Parallels 3.0, which only offers one CPU (hence is of no further interest) to Parallels 4.0, and it seems fine.

THE TWO-CPU MYSTERY:

One might naively expect that increasing the number of CPUs for the virtual machine would speed things up further ... but NO, it is the opposite. I spent a day tweaking all possibilities of Parallels 4 and Vegas I could imagine or discover from forum posts (including virtual machine CPU settings, HyperVisor, memory; even the Vegas internal prefs threads min=4 max=8 trick). The very best is with virtual machine CPUs=2 and, bizzarely, Vegas threads = 3 or 4.

Anyone have insights into why the magic number 2 CPUs and, with this, why more than 2 Vegas threads?

Ref: (my benchmark test results) http://www.sonycreativesoftware.com/forums/ShowMessage.asp?MessageID=526098&Replies=321

Comments

ritsmer wrote on 1/18/2009, 4:17 AM
Just for curiosity: why do you work so hard to improve the speed of Vegas on Parallels on Mac OS on Mac Pro when you could just enjoy the 8 cores working busily using Boot Camp?

The only reason I got an Mac Pro is that it was the cheapest way to get a 2 x quad Xeon machine - and the first thing I did was to scratch all the Mac things from the machine just using the Boot Camp to read the Mac Bios for XP at boot time (and the XP drivers, of course) and else use the machine as true XP machine - i.e. having native NTFS disks etc...

I do not know Parallels - but many years ago I did some machine emulators - and I could very well imagine that your Two-cpu Mystery is a case where more cpu's simply waste their power on overhead and administration.

The 2 cpu's and 3-4 threads thing sounds quite reasonable because the threads often wait for I/O operations and during this time another thread can use the cpu available.
mtntvguy wrote on 1/18/2009, 6:58 AM
And, as you'll find out when you try to preview to an exterior monitor via firewire pass-through, or when you try to print to tape, Parallels doesn't support firewire. I can't get it to work using Bootcamp, either. But at least with Boot Camp I can capture flawlessly... couldn't with Parallels.
fausseplanete wrote on 1/18/2009, 7:04 AM
ritsmer,

Thanks for the "threads > CPUs" explanation: I/O waiting. That makes sense.

Options, I like to have options!

For example I could be occasionally tinkering and rendering a Vegas DV project in the background while I do other work on the Mac. Of course for a full-on session I'd reboot to BootCamp, but flexibility like that is always useful. Also the VM can be used as a play area, e.g. sometimes in the middle of a project I need to install new apps (e.g. iZotope to remove phone rings from a music gig) and from experience of new apps in general, fear the possibility of damage (domage!).

I admit also to the geek-factor: it's a challenge, to know I am using the VM at its most efficient and to know the limits of the latest virtualization solutions, which are rapidly evolving (e.g. multi-core and the appearance of Intel VT-x and its successor coming round the corner, which is reportedly taken advantage of in Parallels 4, giving speed advantage). I will also play with VMWare etc., though my initial experiences of speed (possibly down to my use of it) have not been encouraging.

As well as the Vegas RenderTest benchmark, I also tried CineBench, a free benchmarking app designed to relate to video apps etc., that runs on both PC and Mac. I learnt and read that it is necessary to use a manual stopwatch with this test (as its own scores and timings are weird), but otherwise it seems OK. With that app's multi-CPU test, the 8 cores are visibly in use under Mac, BootCamp and Parallels 4, giving timings within 10% of each other. This certainly illustrates that caution is needed in interpreting benchmark results. From other people's results, the Vegas benchmark includes a large proportion of parallelizable processing (people's multi core results show that) but it doesn't seem to travel well through the virtualizer, at least not this one.

Still, for Vegas, at least two cores are better than one.
fausseplanete wrote on 1/18/2009, 7:47 AM
mtntvguy,

You're right about FireWire, but it's not a show-stopper:

I don't need firewire-fed monitoring to TV etc. since I now have a proper separate monitor.

I don't need the same machine for capturing - I'll most likely use my existing laptop for that task, undisturbed, into a GRAID2, leaving the heavier machine free or switched off (to save the planet). I could network the laptop for onwards transfer if needed, or just plug the GRAID2 via USB into VM/BootCamp/Mac, or simply capture straight into the Mac (via some other utility) either to an NTFS or FAT partition or to a Mac one but read/write -able by XP via one or other app such as MacDrive. More experiments...but no pain, no gain.

Incidentally a Parallels forum thread [http://forum.parallels.com/showthread.php?t=29707&highlight=firewire] gives the impression they are working on FireWire but they're finding it hard to ensure stability, so no timetables are offered just yet. I would hope that they're instead consolidating the main functionality right now.
mtntvguy wrote on 1/18/2009, 11:38 AM
My workaround for the print to tape issue is I move the .veg file and its media to my external hard drive, then open them on my PC. That's a pain in the fanny, however.

The print-to-tape thing didn't work with FC{P on the Mac OS side, either; but FCP has a "refresh camera" option and that fixed it there. Can't find a fix in Windows.
fausseplanete wrote on 1/18/2009, 4:06 PM
OT but interesting, for the same Vegas rendertest on BootCamp, the best speed was with Vegas threads min=4 max=7 (not 8) as described at http://www.sonycreativesoftware.com/forums/ShowMessage.asp?MessageID=526098&Replies=323.

Once again, less is more. It's a lot slower with 8 threads.