How fast is QEMU compared to a “Quad” Power Macintosh G5?

[mePy2]

If it is duplicated tell me. I tried searching “powerpc” and “mac g5” but their are too common words. So...

Please, if you have any test made (benchmark), upload it here, let me know.
For “QEMU” I’m referring to a QEMU version for Intel architecture, on linux OS.

Edit:
If you have tests made on other Power Mac G5 machines is fine too.

[24bit]

Could XBench 1.3 be an option for comparison?
The app had a Power Mac 7,3, PowerPC G5x2 @ 2.00 GHz as baseline of 100.
I´ll have a look at my Qemu setups, has been a while…
Much will depend on the hosts raw computing power obviously.

[mePy2]

Yes, exactly.

The data I would like to receive are the one from the computer you are using for virtualizing Mac OS X. I mean, if QEMU performs better than original G5, which is your configuration? Which processor are you using, RAM, HDD/SSD, (QEMU conf) etc.

Thanks

My problem is, I’m currently running Mac OS X on QEMU for Mac which is not as good as Linux virtualization. So it’s useless my benchmark since it’s obvious the Power Macintosh G5 runs Mac OS X better than my pc. But maybe, with a good hardware configuration and Linux OS, it will run as good as the G5 or even better.
I would prefer buying a new pc instead of buying a Power Mac G5. Not for the price, neither for the dimensions. But for energy consumption.

(Yes, I need a Power Macintosh G5; I’m asking if I could solve the problem virtualizing the OS. Since modern Intel processors are by far more powerful than the PowerPC G5 ones I’m wondering if I could obtain the same power of a Quad G5 with a recent Intel proc + QEMU virt.)

[Cat_7]

Hi,

I guess that kind of performance is still a looong way off. Current performance (related to 100% for a 1.0 Ghz G4) with the Skidmarks test:
Integer calculations 130 %
Floating point calculations 9%
Altivec calculations 11 %

Other performance indicators are indeed available with Xbench 1.3. Beware, those test take a long time to complete. And on my last try not all ran.

That is on a 3.5Ghz i7 processor.

Best,
Cat_7

[adespoton]

To add to this, qemu still has poor multi-core support (providing multiple host cores as multiple cores to the guest) AND still has sub-par multithreading (using multiple host cores to speed up emulation of the guest). So there's a lot of potential for improvement, but it's not there yet.

[mePy2]

Thank you Cat_7

Are you on Linux?

Don’t know precisely the model of your processor but 3.5GHz i7 should be really performant.
I assume you are using the last QEMU version too.

I expected much more performance to be honest. And your data is compared with a 1.0GHz G4 processor. So I assume the situation is even worse comparing the results with a G5 Quad 2.5GHz Macintosh...

[adespoton]

Over the last year we've seen some marked performance increases as various bugs have been worked out and features added (yay AltiVec!) but there's still a lot to do, especially with floating point emulation. The good news is that while it's slower in many areas, it's functional instead of crashy. PearPC and SheepShaver take a lot of shortcuts, meaning they can be faster in general, but when faced with an edge case, they'll fail instead of running slowly.

Personally, I've switched over from PearPC to QEMU-PPC completely now, as I find that for the stuff I do, performance is about on-par and stability is much better.

The QEMU architecture also means that in the future, if someone wants to write a G5 multi-core emulator, this can be dropped in and inherit the existing hardware emulation.

Also, the OpenEFI work that's been going on in tandem has been showing performance and capability improvements that have been picked up by the entire QEMU and VirtualBox projects, including QEMU-PPC.

[mePy2]

Thank you

On my macbook pro 13” mid-2012 2.5GHz i5 (base model, upgraded RAM and SSD, macOS Mojave 10.14) the emulation is fine. Tiger is ok (although slow, naturally). But as I said, since my mac is running macOS and it’s a 2012 macbook, I though on Linux with recent hardware the situation was much more better.

Anyway I need to run a ppc linux distro on something :P either a G5 or a QEMU machine would be fine both have pros and cons.

If you are wondering why, or you are just curious or, better: I just want to share it with you...
https://www.powerpc-notebook.org/en
Have fun!

[adespoton]

Interesting... why PPC instead of ARM? PPC's problem was always that of power management, which seems an odd choice for a notebook. But for dev work, qemu-ppc-kvm running on x86 Linux will avoid some of the issues we've been discussing. Not the FPU issues though.

[Cat_7]

@ mePy2: Yes, that is on Linux. Builds for Windows seem some 5 to 10 % slower.

You can run Qemu with KVM acceleration when your host is the same architecture, so if you run Linux on a PPC machine, you can run Qemu with OSX (Old Mac OS is not supported yet).
But it does not yet fully work without issues on a G4, and not at all with qemu-system-ppc64 on a G5.

When emulating a guest architecture, Qemu-system-pcc currently uses the single threaded tcg, mttcg (multi-threaded tcg) does not yet work for qemu-system-ppc.

Best,
Cat_7

[mePy2]

Thank you cat.

If I have a G5 I would make a disk partition with Linux on it.
The problem with QEMU is only if it can be compared in performance to a G5 emulating a ppc machine on an Intel host. And at the moment the answer seems to be no.

Best,
mePy2

[McHargue]

When emulating a guest architecture, Qemu-system-pcc currently uses the single threaded tcg, mttcg (multi-threaded tcg) does not yet work for qemu-system-ppc.

Just a cheer from the peanut gallery: Thank you and all those who have contributed to QEMU to bring it to life. Put me down for desiring multi-threading if it can speed things up, but it is such a big step to go from no emulation to any emulation that I cannot complain.

I'm running a Mac OS X 10.4.11 installation (under Mojave) with FileMaker, Adobe InDesign, and my own legacy REALbasic program that acts as an automated "compositing" engine taking AppleScript commands and directing graphic creation into PDF to print. I can't tell you how happy I am to have Qemu-system-ppc as an enabler.

I plan to add a second instance of QEMU and run a companion image processing setup with Mac OS 9.2, Photoshop (from the old days ), and another REALbasic program that automates it. Since each Qemu-system-ppc instance, I assume, utilizes its own core/thread, this should not impact the other instances as long as the host machine is beefy enough--right?

Both of the above Mac emulation instances will mount a shared folder on the host so they can access common content.

I know there are likely few people out there that are doing these things outside of recreational use, but this is a real help for me to eke out a few more years (decades?) with these old workflows.

So, again - thank you!

Bill.

[adespoton]

Since each Qemu-system-ppc instance, I assume, utilizes its own core/thread, this should not impact the other instances as long as the host machine is beefy enough--right?

Correct -- give each qemu a core and enough memory, and you're good to go.

The tricky bit will be with the shared folders, because qemu is limited to NTFS shared folders, which don't support resource forks or MacRoman text. To support those fully, you need to do virtual network filesharing instead of using the shared folder feature.

But if your workflows ensure to limit themselves to flat data files of 31 ASCII characters and files under 2GB, you should be able to use the folder sharing feature.

[McHargue]

The tricky bit will be with the shared folders, because qemu is limited to NTFS shared folders, which don't support resource forks or MacRoman text. To support those fully, you need to do virtual network filesharing instead of using the shared folder feature.

I must admit I had not looked into any integrated folder sharing feature of QEMU and was assuming I would just use the native Mac OS 9/X AFP (network) file sharing, which I've already setup on my first emulated machine that mounts a shared folder on the host.

I further must admit I'm not even versed in the QEMU networking options--I'm just using Qemu-system-ppc "out of the box" and can get to the LAN with a IP address (e.g., I connect to server with <afp://10.0.1.97>). I do believe I'll have to use "tap" networking to get more than the one QEMU on the network since it looks like all instances take the same IP address in the default configuration. One step at a time though...

Cheers,
Bill.

[adespoton]

You should be able to use a bridge on the host to virtually network two instances without resorting to a full tun/tap configuration. QEMU networking has this built in by default, so you can just tag your networks appropriately and have the data shared via the host bridge appropriately.

I've had success using bridges already set up for VirtualBox, as well as using an existing ThunderBolt bridge on my Macs to pass the network traffic among guest OSes.

[McHargue]

Since each Qemu-system-ppc instance, I assume, utilizes its own core/thread, this should not impact the other instances as long as the host machine is beefy enough--right?

Correct -- give each qemu a core and enough memory, and you're good to go.

Do you know if the Qemu instance (process?) runs as a "thread" or uses a whole physical core? My understanding is that with Intel i7 or i9 cores they actually spawn 2 threads or "virtual cores" (hyper-threads?) that are independent in that the processor doesn't require swapping registers or state information when switching context between them.

So, if I have a 4 core i7, will Qemu use up 1 or 2 of the potential 8 virtual cores? (Running macOS 10.14 Mojave in my case.) This makes a big difference in my deployment.

Thank you for any information on this...

Bill.

[darthnvader]

Qemu-system-ppc can only take advantage of one core/thread, to complicate matters, modern OS's like the macOS and Linux load level even a single core process to all available cores/threads.

So it's unclear if we can even take full advantage of single core turbo boost on systems where it is available.

[adespoton]

While modern OSes can load level across threads, you can set your ceiling in QEMU to something other than 100% to prevent thread saturation, and conversely, you can use nice to change the priority level of the process.

Since QEMU is single threaded, renicing it to -20 should get it to saturate its thread; setting emulation to 99% should ensure there's a tiny bit of headroom left for external operations on that CPU when needed.