[dead]
How fast is a macOS VM, and how small could it be?
21–30 of 111 posts
Re: How fast is a macOS VM, and how small could it be?
#22I was hoping to see the bare macOS with all the applications removed as much as possible, no graphical user interface, just the bare minimum to boot, login as a user, and write hello world dot txt with a text editor. Or maybe some command line apps? Or is it no longer macOS at that point?
"I'd just like to interject for a moment. What you're referring to as macOS, is in fact, macOS/Darwin, or as I've recently taken to calling it, macOS plus Darwin."
"What you're referring to as Darwin, is in fact, Darwin/XNU."
"What you're referring to as XNU, is in fact, BSD/Mach."
I seem to remember it being possible to run macOS-less Darwin several years ago, not sure if that's still possible or if Apple has modified it so much at this point that it's useless without at least some macOS components.
Re: How fast is a macOS VM, and how small could it be?
#23Earlier quoted context omitted.
macOS is generally pretty amazing at efficient memory usage and VM (virtual memory subsystem) handling. So even a 8GB machine can run pretty impressive workloads without having the user think the machine is underpowered.
Not really. Larger page sizes mean more potential for wasted memory and it has had a long standing memory leak in some core component to where even Calculator can cause an OOM event.
GP is pretty accurate in my experience. Up until last year I was still running an Intel MacBook Pro with 8GB of RAM and successfully multitasked with Blender, Illustrator, Unity, VS Code, and Firefox quite often. The math doesn't make sense, but all stayed responsive even with frequent hops between them. The only OOM events I ran into were memory leaks from Firefox, I believe from an extension.
Re: How fast is a macOS VM, and how small could it be?
#24Earlier quoted context omitted.
Not really. Larger page sizes mean more potential for wasted memory and it has had a long standing memory leak in some core component to where even Calculator can cause an OOM event.
GP is pretty accurate in my experience. Up until last year I was still running an Intel MacBook Pro with 8GB of RAM and successfully multitasked with Blender, Illustrator, Unity, VS Code, and Firefox quite often. The math doesn't make sense, but all stayed responsive even with frequent hops between them. The only OOM events I ran into were memory leaks from Firefox, I believe from an extension.
There's nothing particularly interesting about that. Linux distro-of-your-choice can run the equivalents fine, as can Windows.
Browse /r/macos if you dare to wade into the uninformed cesspool; it's full of OOTB apps causing OOMs (among 3rd party apps) with the past at least two major versions of macOS.
Re: How fast is a macOS VM, and how small could it be?
#25Got a M5 air recently - my first dive into MacOS land so trying to figure this out too. Seems essentially impossible to get: * pytorch * GPU acceleration * VM/container like isolation The virtio-gpu layer gets closest but seems to only pass through graphics GPU not compute GPU so no pytorch
I need this too, and looked quite a lot on it a year ago. I haven’t had time to check out the recent developments with Docker Model Runner (vllm-metal) or podman libkrun. Did neither of those work for you?
vllm-metal isn't GPU access but rather a openai compatible end point which I can already do via lm studio endpoint over network
>podman libkrun
Haven't tried it but research suggests its really shaky still. podman libkrun exposes vulkan while torch expects mps on macs. Sounds like one can force vulkan but that's apparently slow and beta-ish?
Re: How fast is a macOS VM, and how small could it be?
#26Got a M5 air recently - my first dive into MacOS land so trying to figure this out too. Seems essentially impossible to get: * pytorch * GPU acceleration * VM/container like isolation The virtio-gpu layer gets closest but seems to only pass through graphics GPU not compute GPU so no pytorch
I got torch to run in a Cirruslabs Tart instance.
Re: How fast is a macOS VM, and how small could it be?
#27>Starting with 4 virtual cores and 8 GB vRAM, where the VM ran perfectly briskly with around 5 GB of memory used, I stepped down to 3 cores and 6 GB, to discover that memory usage fell to 3.9 GB and everything worked well. With just 2 cores and 4 GB of memory only 3.1 GB of that was used, and the VM continued to handle those lightweight tasks normally. Good reminder that there's a certain amount of memory tied up wit…
I'd bet for the null hypothesis: the memory behaviour changes would hold if the core count was kept constant and only the VM's memory size was adjusted.
Re: How fast is a macOS VM, and how small could it be?
#28>Starting with 4 virtual cores and 8 GB vRAM, where the VM ran perfectly briskly with around 5 GB of memory used, I stepped down to 3 cores and 6 GB, to discover that memory usage fell to 3.9 GB and everything worked well. With just 2 cores and 4 GB of memory only 3.1 GB of that was used, and the VM continued to handle those lightweight tasks normally. Good reminder that there's a certain amount of memory tied up wit…
I'd bet for the null hypothesis: the memory behaviour changes would hold if the core count was kept constant and only the VM's memory size was adjusted.
Agreed. This is the OS adapting to available memory.
Similarly if you started with 4GB and there was 900MB available for user apps, I expect you could launch apps that consume 1500MB just fine; the OS is leaving enough to launch anything, and making use of unused memory for cache/etc.
Re: How fast is a macOS VM, and how small could it be?
#29>Starting with 4 virtual cores and 8 GB vRAM, where the VM ran perfectly briskly with around 5 GB of memory used, I stepped down to 3 cores and 6 GB, to discover that memory usage fell to 3.9 GB and everything worked well. With just 2 cores and 4 GB of memory only 3.1 GB of that was used, and the VM continued to handle those lightweight tasks normally. Good reminder that there's a certain amount of memory tied up wit…
There is some overhead per-core, you're right, but imo this reduction in usage is likely from how the kernel allocates available memory, which is being reduced as well. The kernel will keep read caches around longer with more memory, it'll prefer to compress memory instead of swap to disk if it has more, it'll purge/cleanup reclaimable memory less often with more memory, etc. It even scales its internal buffer sizes and vnode tables depending on total memory.
All good things imo, it dynamically makes the most of what is available, at the expense of making it harder to see a true baseline of hard min requirement to operate.
Fun things to check, `vm_stat`
$ vm_stat Mach Virtual Memory Statistics: (page size of 4096 bytes)
Pages free: 230295.
Pages active: 1206857.
Pages inactive: 1206361.
Pages speculative: 31863.
Pages throttled: 0.
Pages wired down: 470093.
Pages purgeable: 18894.
"Translation faults": 21635255.
Pages copy-on-write: 1590349.
Pages zero filled: 11093310.
Pages reactivated: 15580.
Pages purged: 50928.
File-backed pages: 689378.
Anonymous pages: 1755703.
Pages stored in compressor: 0.
Pages occupied by compressor: 0.
Decompressions: 0.
Compressions: 0.
Pageins: 832529.
Pageouts: 225.
Swapins: 0.
Swapouts: 0.
edit: no code fence markdown support or am I doing something wrong?
Re: How fast is a macOS VM, and how small could it be?
#30I was hoping to see the bare macOS with all the applications removed as much as possible, no graphical user interface, just the bare minimum to boot, login as a user, and write hello world dot txt with a text editor. Or maybe some command line apps? Or is it no longer macOS at that point?
"I'd just like to interject for a moment. What you're referring to as macOS, is in fact, macOS/Darwin, or as I've recently taken to calling it, macOS plus Darwin." "What you're referring to as Darwin, is in fact, Darwin/XNU." "What you're referring to as XNU, is in fact, BSD/Mach." I seem to remember it being possible to run macOS-less Darwin several years ago, not sure if that's still possible or if Apple has modifi…
> several years ago
2024, maybe? needs some renewed interest perhaps: