161–170 of 290 posts
Can someone explain how they are achieving high execution speed? I would have expected the speeds (or at least the start-up times, if we have dynamic recompilation) for x86 on ARM to be outright abysmal.
There's a reason their demo apps were pre-installed. The initial recompilation is cached so that running it the second time will be much quicker than the first.
For any Microsoft insiders with knowledge about this, a few questions: 1. In the talk they claim that they get "near native" speed from the translation. Can we have some real number of what can be expected? What about warm up time? 2. Is the x86 translation layer only available in user space, or can x86 drivers be loaded for hardware that doesn't have arm drivers yet (or the manufacturer doesn't care about making the…
I remember when Apple supported PPC emulation of applications when they made the switch to Intel x86 for a major OS release cycle. I was impressed that the speed there was, in fact, near native enough that the transition was essentially completely seamless. Although this is somewhat of the reverse in architectures, going from CISCy to RISCy. The only thing that concerns em about recent Microsoft developments is that…
I put "successfully" in quotes because MacOS in that era was notoriously crashy-buggy.
They are doing this because they want the benefits of great ARM battery life. But they are emulating x86 on ARM. So they believe that emulated x86 on ARM will have a better battery life than native x86. The only way I think this could be possible is if they measure battery life of an idle device. Maybe someone can disabuse me of this belief.
I hope they drop this on the surface 2. It would save it from being a paper weight.
Was the SurfaceRT an ARM device? I have one collecting dust, would be nice if it got an update
Earlier quoted context omitted.
Yes. The RT devices ran ARM, which was one of the reasons for the locked down software policy (nothing else would run anyway).
Except that you were also denied much of the existing API and can only install software if you have a developer key from MS. I use my RT device for media playback in the car, but the windows-RT version of VLC hasn't been updated in years, and is somewhat buggy.
Emulation should be a last resort. They should ship an SDK with all the proper import libs and a cl.exe etc. that can target proper Win32 on ARM.
Microsoft appears to have apps that are native to ARM, but the real value of the Windows ecosystem is all the Win32 apps that have been built over the last 2 decades. The emulation layer addresses that so that "it just works" with old apps. I assume they will be releasing a build configuration for native ARM software deployment on Windows.
Odd thought: the existence of an ARM Windows, makes it much simpler for Apple to ship ARM PCs. The macOS development stack has been re-tooled to output LLVM bitcode within its "fat" binaries for a good while now. It'd be very simple for Apple to throw the switch on a compile farm ala the one Google has for Android APKs, and suddenly have ARM downloads for everything on the Mac App Store (without requiring any re-subm…
This idea keeps popping up. LLVM bitcode is way too architecture specific to allow that to happen. Chris Lattner has stated it himself.
Yes, you could do the same thing with a plain x86-ISA binary, but such a binary might have sections that are very hard to transpile efficiently/effectively—because e.g. they exist as the result of compiling hand-optimized x86 ASM source modules. Targeting bitcode constrains the inputs a bit more, such that the input to the transpiler won't be using extremely-microarchitecture-specific instructions.
And yes, the results wouldn't be 100% efficient. But it would be efficient enough—like Rosetta—to serve as an effective stop-gap to allow ecosystem consumers to continue to consume their purchased apps on new devices, until ecosystem developers upload explicitly re-optimized apps. (And it would—like Rosetta—at least let apps from "dead" development studios run, rather than killing them off entirely.)
Earlier quoted context omitted.
I'd be very interested in a Windows 10 phone if it has automatic updates that do not depend on the carrier, to avoid the Android situation where only certain phones get updates on a timely basis.
This was the case for the Win7/8 Nokia phones, so the signs are good. (Although I'm in the UK, where the carriers are less abusive)