![]() ![]() Now Apple is moving away from Macs even being able to run intel Windows software at all. Sadly, there hasn’t been a suitable desktop Mac in almost a decade (GPU, heat, etc). The setup didn’t need to be 100% equal to a Windows PC in performance, just be comparable. It used to be that we could have a Mac for both Mac OS and Windows. Unfortunately, gaming on Macs is nowhere near the level of gaming on Windows. Sounds simple to you, doesn’t it? Thing is, I don’t want to have TWO computers to maintain. ![]() I don't know much about the software situation, I was more interested in the CPU-architecture details.If you need to run Windows then buy a Windows PC. ![]() They're both x86 emulators.Īnd as you say, the main issue is Apple providing public APIs for enabling the HW mode so people don't have to install this kernel module manually I'm sure most people wouldn't want to do that. So yes, it's plausible that QEMU's x86 emulation could use the same hardware support that Rosetta-2's x86 emulation does. (If you're not seeing it, the permissions on the extension might be wrong: try a chown -R root:wheel.) In practice this can go wrong in many ways, and I have had luck by "resetting everything" and trying to install after doing the following: A dialog should come up to prompt you to enable the extension in the Security & Privacy preferences pane, you allow it from there and restart, and it will be installed. Supposedly, you should be able to use this if you build and sign the kernel extension (disabling SIP if you aren't using a KEXT signing certificate) and drag it into /Library/Extensions. But it's a kernel extension, and code signing makes it tricky to get MacOS to allow it, and you have to sign it or disable signature verification or something: SeeĪnd yes, is open-source software to toggle that support. M1 has hardware support for a mode like that, as well as a weakly-ordered mode to run native AArch64 code most efficiently. (With real x86 CPUs doing speculative early loads so performance doesn't suffer under normal conditions when a single thread is operating on memory that other threads aren't writing.) for lock-free atomics used for inter-thread synchronization - in x86, every asm load/store is acquire/release respectively. Separately, is this processor mode (flags or instructions) documented and published for 3rd-party use, or is it private to Apple only?Īpple released support for Rosetta 2 Linux VMs using the Virtualization framework, perhaps sometime around June 2022:Īlso, Docker Desktop for Mac released a beta feature for x86 containers using this feature in version 4.16.0 on. Effectively, when Rosetta 2-emulated instructions are being run, a flag is set to let the processor know to use the x86-style addressing scheme.Īssuming this explanation is reasonable (and if anyone has better-sourced reporting than the above Twitter thread I would appreciate it in the comments for inclusion), is it technically plausible that this optimization could be leveraged for full hardware emulation, for example running x86-64 Linux Docker containers, or running a full x86-64 Windows desktop virtual machine a la VMware Fusion/VirtualBox? Or, does the separate operating system layer in those scenarios preclude being able to leverage the memory ordering optimization? The gist of that explanation is that under usual circumstances, arm and x86 have opposite (and incompatible) memory addressing schemes which require significant emulation overhead, but the M1 chip addresses this with a hardware optimization that allows it to access memory using both addressing schemes. I understand why emulation is so slow, but an explanation for why Rosetta 2 is so fast has been detailed in this Twitter thread: emulation, for example what Docker Desktop currently does using QEMU. I am curious about the vastly different performance characteristics of running x86-64 binaries on the Apple M1 platform using Rosetta 2 vs. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |