Qemu 5.0.0 has been released, with a massive laundry list of changes, fixes, and improvements for a lot of Qemu’s emulated platforms. The new version will make it your operating system’s repositories soon enough if you use Linux, but if you use a platform where you have to muddle along with and juggle your applications and updates manually like a peasant, like Windows or macOS, you’ll have to wait until someone packages it for you so you can update your binary manually.
Of course, you can always build it yourself, too.
Interesting passive aggressive commentary in software development, who’d have thunk it!
Virtualisation and emulation are having a bit of a moment right now all due to COVID-19, and that won’t be a surprise to any of us. It would be interesting to see figures but I’m not sure they exist anywhere, somebody must have an idea though!
> Interesting passive aggressive commentary in software development, who’d have thunk it!
Come for the interesting tech news, leave because of the toxic atmosphere.
Hell with emulation, I’ve been cranking out my old computer fixes I’d been putting off for a long time. Mostly pulling out the soldering iron and fixing caps, etc. 😛
Though I do notice there is certainly an acceleration on projects that have been in process for many years.
I wanted to point out a connection with this news and the Sailfish OS 3.3.0 post immediately before it. From the Sailfish blog, regarding the internal tooling upgrade of their Qemu dependency:
> QEMU is an important part of our toolchain, used to compile our ARM and aarch64 binaries with x86 based machines. Over time we have experienced some problems with QEMU and it has become evident that we needed to update it to a newer version. Even though the release includes version 4.2.0 (update from the old 2.x branch), internally we conducted the upgrade in two steps, first to 4.0 and then to 4.2 release.
>
> The change required a notable amount of work and resulted in no visible improvements for Sailfish OS end-users as such. However, developers will now be able to enjoy the new capabilities.
Just in time for Qemu 5.0.0 to drop. I’m sure 4.2.0 makes things much easier than relying on 2.x, but still… ouch.
We’ve got a couple of clients using embedded 32-bit PowerPC big-endian hardware. Have you tried sourcing 32-bit big-endian PowerPC or POWER hardware lately? Basically eBay for ancient Macs is your best hope.
We’ve got one (1) PowerMac G4 or G5. We had two, but we blew a cap in the power supply on one and nobody’s felt inclined to fix it.
Those old chips are single-threaded, and we haven’t come across any nice SMP hardware. So we run a bunch of tests concurrently on x86-64 using qemu, and it winds up being faster overall, despite the overhead of emulation.
qemu is an amazing project.
I guess my question is what x64 CPU are you testing against? I mean I have an old atom NUC that supports x64, but I wouldn’t be shocked to find out was outpaced in single threaded performance by a G5. I need more information to evaluate what you are saying
jockm,
More information is definitely needed, no models were given. Ideally we’d have 3 benchmarks for both physical hosts as well as the benchmark for the emulated one.
While I haven’t done it in a long time thanks to virtualization technology, in my experience QEMU emulation tended to be very slow however I’m having trouble finding benchmarks for it. It’s generally been replaced by KVM.
phoronix.com/scan.php?page=article&item=virtualbox-60-kvm&num=2
(note: I’ve taken out the http links because wordpress has been flagging the links in all my posts lately for moderation, grr)
For a sufficiently old computer though it’s possible that emulation wins. I’d be surprised to see a CPU emulated under QEMU to beat out hardware unless the CPU being replaced was extremely slow to begin.
browser.geekbench.com/geekbench2/2685643
browser.geekbench.com/geekbench2/2685636
It’s not necessarily meaningful without host details, and nothing here is apples to apples, but…
browser.geekbench.com/v5/cpu/1960226
Despite this though, the an emulated system as a whole might be faster because the reduction of IO and RAM bottlenecks might more than make up for emulated CPU performance losses.
@Chrish, I’ve found something similar myself, not just QEMU, I’m always looking for ways around legacy road blocks and something like QEMU can be just that, giving me an up to date base that can still deliver legacy applications. I’ve been able to get around many OS related problems this way, if only I could virtualize or emulate custom hardware in such an easy manner. I realise there are companies that do this now, using modern large scale FPGAs, but it is still an expensive process.
> …but if you use a platform where you have to muddle along with and juggle your applications and updates manually like a peasant, like Windows or macOS…
This is misleading.
Qemu 2020.2.1.20200331
https://chocolatey.org/packages/Qemu#releasenotes
Scoop
https://github.com/ScoopInstaller/Main/blob/master/bucket/qemu.json
Homebrew
https://formulae.brew.sh/formula/qemu#default
In addition, the packaging of Qemu on various Linux distributions and BSDs are (also) done by contributors/ porters. It is unnecessary to blame the system and/ or the OS users because Qemu doesn’t officially providing pre-built package for specific platforms.