The ApplicationLaunch native time of 0.493 s extended to 0.967 s in the VM, but KextdVolumeAppeared was almost identical, at 6.97 µs native and 6.85 µs in the VM. Non-graphics performance in the VM can be very impressive. These confirm that to achieve good graphics performance in the VM, you will need a relatively powerful graphics card in the first place, and to run the VM in Mojave or Catalina. However, a native render_quad taking just 0.195 ms took 77.5 ms in the VM.
Other calls, to CompositeLoops for instance, weren’t slowed as badly as that. One matching call to render_tile, for instance, took 12.1 ms when running native, and 77.5 ms in the VM. Graphics Signpost performance was invariably slower in the VM than when running macOS natively, but this varies greatly between different procedures. However, you can’t run the Geekbench graphics benchmark in a VM. Running standard CPU-based benchmarks like Geekbench demonstrates that raw CPU performance is only slightly below that attained when running in native macOS, which is impressive. Performance also varies considerably according to the operation being undertaken. Parallels claims that version 15 works directly with Metal in Mojave and Catalina, and the evidence from these Signposts confirms that. When the VM was running, the host log consisted of a great many CompositeLoops with interspersed CoreAnimation Commit events. The VM required a longer sequence of more basic rendering operations, which appear to be short-circuited when running in native macOS. When running in the native macOS, direct use of the GPU was seen in gpu_compute calls, which didn’t appear in the VM logs, nor in the host log when the VM was being used. There are some obvious differences between the three logs. when opening SilentKnight in the VM, analysing the Signposts in the VM’s log and the log of the host macOS too, over the same time period.when opening SilentKnight in the host macOS, without the VM running.I then examined the Signposts written by macOS during that period of less than twenty seconds, e.g. Once it had downloaded the information it required, I moved its window on the screen. I then opened my app SilentKnight at one second past the minute (e.g. I quit all open apps apart from the Finder.
PARALLELS FOR MAC RUN PROGRAM IN HOST OS SOFTWARE
The software tool which I’m using to obtain performance measurements from macOS is my own RouteMap, which analyses the many Signposts written to the unified log by macOS sub-systems. Parallels does run very nicely in Catalina too, but because that’s still in beta, I felt it best not to try measuring performance there just yet. I’m looking at Parallels Desktop 15 hosted on macOS Mojave 10.14.6, and running the same macOS in its VM.
PARALLELS FOR MAC RUN PROGRAM IN HOST OS PRO
To investigate this, I’ve been using my normal desktop Mac, a base model iMac Pro with an 8-core Intel Xeon W running at 3.2 GHz, 32 GB of memory, and a Radeon Pro Vega 56 graphics card and its 8 GB of memory. Will your VM run like an old Intel Core Duo iMac, and be almost unusable? This article looks at some answers to that question, using performance measurements built into macOS rather than artificial benchmarks. One major concern with any form of software virtualisation is how it will perform. If you need to retain access to key 32-bit apps, or anything else which won’t run in Catalina, a VM running Mojave or earlier is a highly practical solution, and very straightforward to set up using the latest Parallels Desktop 15. It’s a standard tool for security researchers, and for many developers, but of little advantage to others – until Catalina drops support for 32-bit software, that is.
Before the arrival of Catalina, relatively few Mac users needed to run an older version of macOS in a Virtual Machine (VM).
0 kommentar(er)
