> because merely decompressing the packages is very slow
Is this because the guest code is making syscalls that context-switch, and that imposes a lot of interpretation overhead; or is it mostly because the emulator's disk driver maps calls to write to disk X directly to host IO against the file representing disk X, such that O(N) emulated IOPS translate to O(N) host IOPS?
If it's the latter, then this sounds like it'd be the same problem that Docker.app dealt with on macOS: some guest apps do IO in a single-threaded + serially-dependent (write, then read back, then write back, then read back...) manner, and so they degrade basically quadratically when there's any kind of IO-syscall latency. (You can see a similar effect if you run e.g. `apt-get install` within an NFS-mounted chroot.)
Alternately, if the emulator's disk driver mmap(2)s a host file to serve as the emulated disk—then large-batch streaming writes from the guest would become large piles of dirty pages in need of flushing; and large-batch streaming reads would become large piles of page faults. And because the guest workload is opaque to the hypervisor, it wouldn't be able to use madvise(2) or the like to tell the iPadOS kernel how to predict/coalesce these.
If either of these is the problem with UTM SE's emulated-block-device IO perf, I'd be curious how much better emulation of IO-intensive operations would perform if they reimplemented the block-device driver as a userland large-block-size page file — i.e. what an RDBMS calls a buffer pool.
(AFAIK this is already a best-practice for hypervisors that work with expected-high-latency disks. If you tell VMWare ESXi/vSphere to use an iSCSI storage adapter, then that storage adapter is going to do client-side in-memory caching of the iSCSI target at some larger-than-one-disk-sector granularity.)
2. and this page in turn is apparently of an unusual "commentary on a link" CMS type — where it seems that clicking the little arrow wingding beside the title — or clicking the thumbnail (which is a thumbnail of the page the comment is "about") — takes you to the page that the comment is "about";
> After initially rejecting it, Apple has approved the first PC emulator for iOS
> UTM SE can ‘run classic software and old-school games’ for Windows, Mac OS 9, and Linux on your iPhone.
---
This is admittedly confusing and indirect — but that's mostly due to this website's publishing system's weird reading-UX choices, not so much due to the author's editorial choices. (Unless this publishing system is created by the author, in which case...)
A few UX recommendations to the site's designer:
1. fix the rendering for your "Link" resources! Facebook and Twitter have forced the rest of the web into expecting that this kind of resource will be rendered as what they call a "link preview" — using the OpenGraph metadata (og:title and og:description) of the target page. As such, only rendering the page's scraped <title> might produce bad results, as nobody's expecting you to do that, and so hasn't optimized their pages' out-of-context comprehensibility for that. They've optimized for people rendering og:title + og:description — so if you want your own "link previews" to be comprehensible, then that's what you've gotta do too.
2. You probably want to give "supplementary" Posts like this one, some CMS metadata that points to a previous Post or Link as the "prerequisite reading." If a Post has prerequisite reading, then your CMS should render the Post's full unfolded body view with an embedded summary of the previous resource at the beginning. (Where in this case, what I'd expect is a blockquote of the Link resource — in turn including the link preview!)
That's exactly what I did, which confused me a lot:
* See an article about something called "UTM SE"
* See a linkified "UTM SE" in the first paragraph, thinking it would take me to a homepage or GitHub project or something
* But instead it takes me to another article on the same site that talks about JIT and apt-get update and how Apple disallows that. Not very helpful
* Further down on the first page is a link to "the 'real' UTM", but guess what, it also goes to some other article on the same blog that doesn't explain anything
I realize that most of this has been fixed now, but seriously, to me that just looked like some sort of SEO by using dozens of intra-site links, or something.
Is this because the guest code is making syscalls that context-switch, and that imposes a lot of interpretation overhead; or is it mostly because the emulator's disk driver maps calls to write to disk X directly to host IO against the file representing disk X, such that O(N) emulated IOPS translate to O(N) host IOPS?
If it's the latter, then this sounds like it'd be the same problem that Docker.app dealt with on macOS: some guest apps do IO in a single-threaded + serially-dependent (write, then read back, then write back, then read back...) manner, and so they degrade basically quadratically when there's any kind of IO-syscall latency. (You can see a similar effect if you run e.g. `apt-get install` within an NFS-mounted chroot.)
Alternately, if the emulator's disk driver mmap(2)s a host file to serve as the emulated disk—then large-batch streaming writes from the guest would become large piles of dirty pages in need of flushing; and large-batch streaming reads would become large piles of page faults. And because the guest workload is opaque to the hypervisor, it wouldn't be able to use madvise(2) or the like to tell the iPadOS kernel how to predict/coalesce these.
If either of these is the problem with UTM SE's emulated-block-device IO perf, I'd be curious how much better emulation of IO-intensive operations would perform if they reimplemented the block-device driver as a userland large-block-size page file — i.e. what an RDBMS calls a buffer pool.
(AFAIK this is already a best-practice for hypervisors that work with expected-high-latency disks. If you tell VMWare ESXi/vSphere to use an iSCSI storage adapter, then that storage adapter is going to do client-side in-memory caching of the iSCSI target at some larger-than-one-disk-sector granularity.)