7 ms·

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 a

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...

wvenable 10y ago
Given the entire OS would still be native, it might not be too bad for certain classes of applications. You would expect games to perform terribly but standard corporate desktop applications would probably perform pretty well. Many of our critical corporate applications were designed a decade ago -- so you just have to emulate the average desktop performance from those days.
- Havoc 10y ago
  >standard corporate desktop applications would probably perform pretty well. 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???
  - youdounderstand 10y ago
    Undoubtedly due to blocking the UI thread on I/O.
    - darrylb42 10y ago
      and the slow database backend
    - i336_ 10y ago
      Or an overabundance of I/O. 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.
      - nine_k 10y ago
        Acceptance testing? Load testing? No, never heard of those :-/
    - wfunction 10y ago
      The problem is there shouldn't be much so I/O for loading programs in the first place, but .NET loves loading an exabyte from the disk whenever any program runs.
  - Maarten88 10y ago
    > yet its bloody slow. HOW??? 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...
    - Clubber 10y ago
      Swap out some brand names and that's almost exactly what I'm building right now. Micro services! Let's make everything like that now! I miss WinForms.
- huxley 10y ago
  Given that Apple pulled it off twice with the Mac 68K emulator (for the Motorola 680x0 to PowerPC transition) and on OS X with Rosetta (for the PowerPC to x86 transition), it's certainly possible and ARM processors have come a long way.
  - greglindahl 10y ago
    Note that in both cases the new processor was faster than the old one. Not so much for x86 on ARM.
    - freehunter 10y ago
      Back then, "faster" really meant faster. These days, there's far less of a gap between processor generations for a consumer use-case. Running Firefox on Windows 10 to check Gmail and Facebook and occasional Word usage probably wouldn't feel much slower if you're on an Apple A10 processor vs a Skylake core i5. We long ago reached the point where an iPad processor was fast enough for consumer usage, and I knew plenty of college students who were happy with their Surface (non-pro, ARM-based). 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.
      - gsnedders 10y ago
        And there's plenty of people whose primary devices are phones and tablets nowadays.
  - kalleboo 10y ago
    It could be difficult for Microsoft, but since Apple have their own line of ARM processors, could Apple theoretically add a couple strategic instructions to their CPUs to help speed up the emulation?
frozenport 10y ago
It can work very well, there is an x86 emulator that is able to play many early 2000s strategy games on Android https://play.google.com/store/apps/details?id=com.eltechs.es&hl=en https://play.google.com/store/apps/details?id=com.eltechs.es...
comex 10y ago
If your experience of ARM emulation of x86 is qemu, especially the full-system variant, you're getting something much slower than emulation needs to be: - 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.
- TheCoreh 10y ago
  Doesn't ARM have very different memory consistency guarantees than x86 across cores, requiring memory barriers? I figured that would be one of the trickiest parts of emulating x86 on ARM
Raticide 10y ago
Apple emulated PowerPC on x86 when they initially switched to Intel CPUs, and it wasn't too bad really.
- city41 10y ago
  They did the same for 68k programs when they first went to PowerPC. And there's mild rumor building of them switching to ARM as well. 4 processor architectures across the Mac's history is pretty impressive.

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...

wvenable 10y ago

Given the entire OS would still be native, it might not be too bad for certain classes of applications. You would expect games to perform terribly but standard corporate desktop applications would probably perform pretty well. Many of our critical corporate applications were designed a decade ago -- so you just have to emulate the average desktop performance from those days.

Havoc 10y ago
>standard corporate desktop applications would probably perform pretty well. 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???
- youdounderstand 10y ago
  Undoubtedly due to blocking the UI thread on I/O.
  - darrylb42 10y ago
    and the slow database backend
  - i336_ 10y ago
    Or an overabundance of I/O. 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.
    - nine_k 10y ago
      Acceptance testing? Load testing? No, never heard of those :-/
  - wfunction 10y ago
    The problem is there shouldn't be much so I/O for loading programs in the first place, but .NET loves loading an exabyte from the disk whenever any program runs.
- Maarten88 10y ago
  > yet its bloody slow. HOW??? 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...
  - Clubber 10y ago
    Swap out some brand names and that's almost exactly what I'm building right now. Micro services! Let's make everything like that now! I miss WinForms.
huxley 10y ago
Given that Apple pulled it off twice with the Mac 68K emulator (for the Motorola 680x0 to PowerPC transition) and on OS X with Rosetta (for the PowerPC to x86 transition), it's certainly possible and ARM processors have come a long way.
- greglindahl 10y ago
  Note that in both cases the new processor was faster than the old one. Not so much for x86 on ARM.
  - freehunter 10y ago
    Back then, "faster" really meant faster. These days, there's far less of a gap between processor generations for a consumer use-case. Running Firefox on Windows 10 to check Gmail and Facebook and occasional Word usage probably wouldn't feel much slower if you're on an Apple A10 processor vs a Skylake core i5. We long ago reached the point where an iPad processor was fast enough for consumer usage, and I knew plenty of college students who were happy with their Surface (non-pro, ARM-based). 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.
    - gsnedders 10y ago
      And there's plenty of people whose primary devices are phones and tablets nowadays.
- kalleboo 10y ago
  It could be difficult for Microsoft, but since Apple have their own line of ARM processors, could Apple theoretically add a couple strategic instructions to their CPUs to help speed up the emulation?

frozenport 10y ago

It can work very well, there is an x86 emulator that is able to play many early 2000s strategy games on Android https://play.google.com/store/apps/details?id=com.eltechs.es&hl=en https://play.google.com/store/apps/details?id=com.eltechs.es...

comex 10y ago

If your experience of ARM emulation of x86 is qemu, especially the full-system variant, you're getting something much slower than emulation needs to be: - 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.

TheCoreh 10y ago
Doesn't ARM have very different memory consistency guarantees than x86 across cores, requiring memory barriers? I figured that would be one of the trickiest parts of emulating x86 on ARM

Raticide 10y ago

Apple emulated PowerPC on x86 when they initially switched to Intel CPUs, and it wasn't too bad really.

city41 10y ago
They did the same for 68k programs when they first went to PowerPC. And there's mild rumor building of them switching to ARM as well. 4 processor architectures across the Mac's history is pretty impressive.