How would this actually work? Wouldn't it be painfully slow? Even ARM emulation on x86 seems to be pushing it, and I feel like the reverse should be 10x worse at best...
- Anything floating point or SIMD is generally done with a big mass of C helper functions rather than fully inline, and it's always unrolled rather than translated into native SIMD. You can blame qemu's choice to use an architecture neutral IR, but even with that design it could be a lot smarter than it is. In any case, a JIT designed for a specific guest/native architecture combo should be able to produce much more efficient instruction sequences.
- In system mode, qemu has to emulate page tables, which it does by translating every load/store to call a stub that maps the given virtual address to a "physical" one before loading. This is quite slow. User-mode qemu (where qemu is a host-arch Linux process pretending to be a single target-arch Linux process) is faster because it doesn't need to perform any translation itself (the host page tables provided by the native kernel do the job). Here too qemu could be improved - it's possible to use host page tables for full system emulation, though in some cases at the expense of hardware accuracy - but AFAIK Microsoft's emulator is user-mode, so this too isn't an issue.
- Those are only the big issues; I think there are a lot of small cases where there's room to do better than qemu, either in general or by optimizing for a specific architecture pair.
Also, I'm not sure how much this matters, but translating x86->ARM64 has some small builtin advantages over other pairs due to the nature of the ISAs. x86 has few general-purpose registers, while ARM64 has 32, so you can map each x86 register to an ARM register throughout the emulation; going the other way around you need to be constantly shuffling registers to and from memory. And a small one: ret on x86 requires the use of the stack pointer and memory, while ARM64 ret just takes an arbitrary register argument. (In both cases, the visible semantics are the same as a regular indirect jump, but the instructions are optimized to quickly return to the corresponding call instruction using a shadow stack in hardware.) All indirect jumps, including returns, have some emulation overhead because you need to translate the host code address to a native one; it's a bit easier when the host instructions are more flexible.
Many of our critical corporate applications were designed a decade ago -- so you just have to emulate the average desktop performance from those days.
Don't say such evil things.
Spend half my days being frustrated by corporate software. .net software that runs on a modern i7 ultrabook with SSD. Doesn't do anything wild (mostly buttons & menus)...yet its bloody slow. HOW???
A friend showed me the industry-standard database app used to manage most Internet-connected second-hand bookshops (I think).
Its development decisions went something like:
"Hey, let's be sooooo awesome and update the search results live, as you type! Wow, without even a one-second delay this is SO REALTIME - like we're in 2187"
(later)
"Do we need to index the database? ...eh, nah. I don't think our custom database solution even supports indexing. Kay."
In my friend's case the store he's at has tens of thousands of books.
Cue perpetual SSD replacements by all the shops using this software
My approach to using it (when my friend and I were discussing it while I visited) was to hit Win+R to obtain a text box, type my search string, then ^C/ESC/^V it over. The database app would lock up for about 1.2 seconds per keypress.
The button calls into a recently developed micro-service, that calls into a previous-generation SOAP webservice, that sends a message to the enterprise service bus, that then goes to netweaver middleware, that calls into the SAP R/3 backend that has been there since 1992 but was recently upgraded to use an even more expensive database.
Of course, the button has to wait for the response of all this, and blocks the UI while waiting...
I miss WinForms.
For you and I, we want the fastest machines possible, and right now it's x86. For everyone else, I doubt they've even given it a thought, and I don't think they'd notice.
https://play.google.com/store/apps/details?id=com.eltechs.es...