W10 Mobile x86 .exe Emulator

[Cruncher04]

Purely from a technical perspective, emulating x86 on ARM is still a somewhat senseless proposition. If all we want to do is run Win32 x86 desktop software on phablet sized devices, there are simply much better ways to achieve that functionality, like using a real x86 Core M CPU.

You are looking at this from a complete wrong point of view. The proposition that "all we want is run32 x86 apps" is inherently flawed.
With Windows for ARM you are getting devices which are significantly more powerful than Intel devices in the same power envelope (e.g. Atoms). we are looking at a gap of CPU performance of close to factor 2 and GPU performance of close to factor 3.
So what you are getting is a device with significantly better performance (assuming equal power and form factor), which also happens to run x86 Win32 Apps (albeit with a performance hit of course).
The purpose of these device in mid term is to run native ARM Win32 apps. x86 emulation only serves as enabling technology and is not the sole purpose of these devices.

 

[Rosebank]

https://www.youtube.com/watch?v=qXRWDjeRrBY

 

[a5cent]

You are looking at this from a complete wrong point of view. The proposition that "all we want is run32 x86 apps" is inherently flawed.

When has anyone stated that "all we want to run are x86 apps"? I definitely didn't say that. I don't think anybody else did either. That's certainly not my point of view.

Your argument is focused exclusively on matters of performance. That's the same point of view that I had when I jumped into this thread. However, I'm now convinced that view was too narrow and I think you're making the same mistake.

The purpose of these device in mid term is to run native ARM Win32 apps. x86 emulation only serves as enabling technology and is not the sole purpose of these devices.

ISA emulation is, at best, a workaround to fix a problem for which there is no better solution at the time. The idea that ISA emulation could ever be the sole purpose of a device is ridiculous. We agree on the rest though.

With Windows for ARM you are getting devices which are significantly more powerful than Intel devices in the same power envelope (e.g. Atoms). we are looking at a gap of CPU performance of close to factor 2 and GPU performance of close to factor 3.

It appears that you're not just mentioning Intel's Atom chip as an example, but basing your entire comparison to Qualcomm's Snapdragon chips on them. That is a mistake. Intel's Atom chips aren't even really a thing anymore. Intel has designed their last Atom. There won't be any more. Why? Because Intel's Core M series is taking over that spot.

Qualcomm aims for a TDP between 2.5W and 3W for phones and 5W for tablets. All their high-end SoCs are around the 3W mark, including the SD820. I think it's safe to assume the SD835 will also come in around there.

Intel's Core M series chips are officially rated for a TDP of 4.5W. However, OEMs have a lot of influence over their power management features, which is why the same Core M chip can be found in many devices with widely varying performance characteristics and with TDP ratings between 3W and 6W! The lower end of that is most certainly comparable to a high-end Qualcomm SoC! Since we're discussing a phablet sized device rather than a normal phone, thermals are a non-issue! In terms of TDP both chips are comparable.

In terms of performance they are also comparable. Some things Intel does better. Some things ARM does better. But overall they are comparable. However, where Core M has an indisputable and clear advantage over Snapdragon is when it comes to running x86 software, as ISA emulation incurs a serious performance/efficiency/battery-life hit. Interestingly enough, all of MS' W10 on ARM demos (rendering a static 3D scene, Photoshop filter, etc) were all GPU bound rather than CPU bound. Close to GPU demo territory. For me, that's not going to cause the same "feverish euphoria" as it did for many others here. I'm no farther than "reserved skepticism".

Anyway, that's why I don't buy your technical arguments. Your points are valid in the context of Atom chips, but incorrect for the chips I'd expect to actually be used in such a device. Judging only performance, the Core M chips are the far better choice. They will run anything from the store just as well as a high-end Snapdragon, but they will run the x86 based desktop software far faster. That raises the question why MS would choose a Snapdragon chip and accept its inferior x86 performance. Based solely on performance it's a poor solution and make no sense, which is what I've been saying all along.

However, Snapdragon does start to make sense when we look past the performance related arguments. I think price and mobile features are the most likely reasons MS chose Snapdragon. Having to emulate x86 was just an unfortunate consequence of chasing those benefits. At least that's my assessment for the time being.

 

[Cruncher04]

Where has anyone stated that "all we want to run ins x86 apps"? I definitely didn't say that. I don't think anybody else did either. I have no idea why you'd think that represents my point of view.

It was the premise from which you implied that there are better ways. My argument was, that your premise was wrong.

In terms of performance they are also comparable. Some things Intel does better. Some things ARM does better. But overall they are comparable.

They are not even close to comparable. In the same power envelope Intel is so far behind, it is not even funny. Thing is ARM is not even trying yet to compete in the performance segment outside of Apple A10.
There is not a single Core-M chip available i would buy for a tablet. These things have to be put into hibernation in order to hold the battery for more than a day. ARM chips you can leave in stand-by for days. Likewise if you limit Core-M to low TDP, voltage is reduced and frequency is severely throttled such there is not much left of the supposed performance advantage. There are few Core-M tablets that throttle below 1GHz under load and that is with a TDP of around 5W.

The writing is on the wall, once ARM releases a wider architecture similar to A10 (a phone chip mind you) Core M will not stand a chance, similar to how the 3 wide Atom don't stand a chance against a 2-wide Cortex A73. It is somewhat unfortunate that A10 is only available for Apple devices but they give a good outlook of what is possible.

They will run anything from the store just as well as an ARM chip, but they will run the x86 desktop software far better. That calls into question why MS went with an emulated solution on ARM at all?

Because Microsoft has to. Assuming for a moment my technical arguments are sound - they cannot forever support an outdated and inefficient architecture exclusively without risking to become irrelevant.
As i said, emulation is just an enabling technology. ARM devices are not supposed to run x86 apps better than an x86 architecture. However these devices are supposed to run native ARM Win32 apps better with respect to perf/watt than x86 machines.

 

[Joe920]

Assuming for a moment my technical arguments are sound

That's what I'm doing, so I'm liking your post. Gotta say, I'm pretty happy with my SP4 m3, but if I could get similar performance and longer battery life with an ARM equivalent, I'd be in.

My most heavily used apps on that device are UWP apps, which I assume one could "compile for ARM". Mind you, I have no clue what I'm saying. Anyway, very curious what 2017 will bring.. on the tech front!

 

[a5cent]

As i said, emulation is just an enabling technology. ARM devices are not supposed to run x86 apps better than an x86 architecture. However these devices are supposed to run native ARM Win32 apps better with respect to perf/watt than x86 machines.

This we can put aside. We agree that the goal must be to offer the same program compiled for ARM and x86. Any scenario where emulating x86 remains the norm on ARM devices would utterly destroy any supposed advantage ARM may have. As you said, emulation is an enabling technology (I prefer the term "stop-gap measure"). Nothing more.

Where has anyone stated that "all we want to run ins x86 apps"? I definitely didn't say that. I don't think anybody else did either. I have no idea why you'd think that represents my point of view.

It was the premise from which you implied that there are better ways. My argument was, that your premise was wrong.

It was never the premise. Please stop putting words in my mouth.

here is not a single Core-M chip available i would buy for a tablet. These things have to be put into hibernation in order to hold the battery for more than a day. ARM chips you can leave in stand-by for days. Likewise if you limit Core-M to low TDP, voltage is reduced and frequency is severely throttled such there is not much left of the supposed performance advantage.

Nowhere did I say that Core-M has a general performance advantage. Again, please stop putting words in my mouth. I said Core-M and high-end Snapdragon are comparable in terms of performance. Comparable means "more or less the same". Not that one has an advantage. The only exception is when it comes to running x86 software, where an ARM device must shoulder the emulation overhead. In that specific scenario, and only then, does Core-M have an across-the-board advantage (battery-life, perf/watt, raw performance, etc... everything).

Furthermore, your information is outdated. Just like ARMs and Atoms, the latest Core-M chips all include connected standby capabilities (the normal Intel Core chips too). Windows recently gained support for this with something MS calls "Modern Standby". A tablet built with the latest Core-M CPU can also be left in standby for days. No difference!

Assuming for a moment my technical arguments are sound - they cannot forever support an outdated and inefficient architecture exclusively without risking to become irrelevant.

You do realize that ARM was around back in the 1980's, right? Both ISAs are ancient.

It sounds as if you think ARM is an objectively superior, almost magical ISA compared to x86. It's not. Intel and ARM just approach the problem from different angles. An IC can be designed to perform as well as possible (most of what Intel does), or it can be designed to be as power efficient as possible (most of what ARM does). Both requirements are mutually exclusive. Between those two extremes, a company can take the approach to maximize perf/watt, in which case neither best performance or lowest power consumption is top priority, but best bang for your power. Designs built on that last approach is where both company's products are slowly converging and becoming ever more comparable.

To be honest, ARM's original designs actually suck at this point. ARM's technology is now only competitive when put into the hands of companies like Qualcomm or Apple. It's not really about the ISA at all, but rather about the specific CPU designs built around those ISAs by Intel, Qualcomm, Apple and Samsung.

They are not even close to comparable. In the same power envelope Intel is so far behind, it is not even funny.

Really? We seem to both agree that Apple has (IMHO by far) the best ARM implementation around. So lets compare Apple's ARM A9X, to Intels x86 Core M 6Y30, as both have a similar TDP rating and both are produced on a 14nm process node:


source

The A9X and the somewhat older m3-6Y30 go back and forth. Where Core-M is better, it's significantly better, but the A9X also pulls out a few wins. If we don't want to give the win to Intel, I'd say the results are roughly comparable. As far as I'm concerned, that's the end of your argument. The idea that the x86 ISA is outdated and inefficient is ridiculous. The designs used to implement x86 and ARM compatible CPUs have undergone radical changes over time and have been kept up to date and modern. They all employ similar concepts. Only the ISA is different which barely matters anymore.

I suspect that going forward, Apple and Intel will continually wrestle over performance leadership, continually switching first and second spots based on whomever was the latest to release a product to market.

I'll say it just one more time and them I'm out:

If the goal is to also run x86 software, there is, purely from a performance perspective, simply no reason to accept emulation on ARM. We're far better off using a Core M chip. Using the newest iterations of both chips, battery life will be similar and performance will be very comparable, except when running x86 software, where Core M will do much better. If we start to judge other metrics beside pure performance, particularly price, then the ARM alternatives start to make a lot more sense. From what I've been reading, all OEMs are coming to that conclusion. Intel seems to be pricing Core M out of the market.

 

[Joe920]

I'll say it just one more time and them I'm out

Five minutes later:

 

[Cruncher04]

You do realize that ARM was around back in the 1980's, right? Both ISAs are ancient.

You do realize that ARMv8 was a complete revamp of the ISA? Gone are the v7 CPU modes, instead layered exception levels were introduced. Gone are ancient concepts like locked swap instructions (Intel still have them today). Gone are the banked GP registers....the only banked registers you have with AArch64 are SP and SPSR and LR.
Compare this to x64, which is just an extension to x86, with the same old paradigms. The page table descriptors where extended over the time with several orthogonal concepts like MTRRs, because in the original design there were just enough space for all the required protection mechanism a modern CPU requires today.
And then there are more advanced concept that help with multicore efficiency like the MOESI protocol...Intel still use MESI. Then we have a modern weakly ordered memory model...Intel still bets on sequential consistency for most memory accesses, which hinders performance and efficiency. Moving CPU state from and to GP register happens via stack operations on x86, while you do a direct move on ARM.
I could go on the whole day...
If anything it is surprising how far they come with such ancient concepts...but they are hitting the wall much sooner than ARM.

ARM's technology is now only competitive when put into the hands of companies like Qualcomm or Apple. It's not really about the ISA at all, but rather about the specific CPU designs built around those ISAs by Intel, Qualcomm, Apple and Samsung

The most advanced 2-wide ooo CPU we have today is Cortex A-73 a genuine ARM design. Apple A9x is 5 wide...of course its faster single threaded. Take the 3 wide Atom as comparison...that is what you get if you have to carry the x86 legacy.

So lets compare Apple's ARM A9X, to Intels x86 Core M 6Y30, as both have a similar TDP rating and both are produced on a 14nm process

You must be kidding. That is not even compiled with the same compiler. Safe to say x86 is using Intel Compiler (aka Spec compiler). In addition that does not even tell the whole story, as Core M throttles down-to 1GHz under load in a 4,5TDP implementation, which can not be observed for A9X. You need to understand that TDP is just the upper limit. It does not mean, that that both Core M and A9X using the same power when running a certain workload or corollary that they have the same performance when both approach the 4.5 TDP limit under heavy load.

You have to look either ISO-power and observe the performance or ISO-workload and look at the duration given a certain akku capacity.

Example from notebookcheck.de:

Surface Pro 4 M-6Y30: 38Wh Akku: runtime idle (lowest brightness): 791min , runtime wlan browsing 150 cd/m?: 488min.
Apple iPad Pro 12 A9X: 38Wh Akku: runtime idle (lowest brighness): 1933min, runtime wlan browsing 150 cd/m?: 695min.

That is in a completely different league. Safe to say it will take Intel another few generations of core M to get such numbers while we already have Apple A10.

 

[a5cent]

Take the 3 wide Atom as comparison...that is what you get if you have to carry the x86 legacy.

No. I will not compare an Atom to anything. It's no longer relevant. It's EOL for a reason.

You must be kidding. That is not even compiled with the same compiler. Safe to say x86 is using Intel Compiler (aka Spec compiler). In addition that does not even tell the whole story, as Core M throttles down-to 1GHz under load in a 4,5TDP implementation, which can not be observed for A9X.

I don't know what your beef is with the compiler. Of course ARM and Intel code will not be generated using the same compiler. It can't be. Your assumption that the Core M was not tested under realistic conditions because it wasn't yet throttling is also incorrect. It was specifically stated in the test that both CPUs throttled down when they reached their max TDP. All CPUs do. That's physics, and even ARM CPUs must abide by those laws.

The Core M throttled down, so did the A9X, then performance was measured under full load at a similar power draw. That was the whole point. The test comes from Anandtech. One of the most technically competent sites on the internet. A gazillion other tech sites quoted their findings and believe them to be accurate. I think you're reaching. I'm inclined to take their numbers and their word over yours.

Joel Hruska from ExtremeTech, also an unusually competent writer, also shares my position:

One — and it’s the one I generally tend to favor — is that physics and process are the primary barriers to faster performance these days. Both Apple and ARM have made huge performance strides in the last five years, but those improvements have required higher TDPs, more sophisticated power management, and better software support. This view argues that Apple and ARM have made such huge advances because they’ve been adopting techniques and technologies that companies like Intel and AMD started using a long time ago.

If you hold this view, than ARM and x86 performance will inevitably approach each other, assuming equal tool and compiler support, but will be hard-pressed to systemically beat the other by large margins

Now I really hope I am out.

 

[appsmartvn]

Also the ranges being spoken about for the NEW device is 6, 10, and 14 inch display format. phuc kich The 6 inch device commonly known as a phone or Phablet might have a new Label completely?

 

[Cruncher04]

I don't know what your beef is with the compiler. Of course ARM and Intel code will not be generated using the same compiler. It can't be.

Of course it can. Anandtech could have used gcc for both. It is well known that the Intel compiler generates optimized AVX code for certain SPEC benches, where LLVM/ARM compiler does not generate NEON code. It is also surprising that the Intel compiler does generate particularly good code for SPEC but outside of this it is just average (e.g. if your compiling your own code).

Joel Hruska from ExtremeTech, also an unusually competent writer, also shares my position

Look, they are journalists not engineers. They typically have a very limited knowledge. I doubt they have any clue about how any of my points from above as example the usage of MESI vs MOESI impact performance and power.
In this sense Anandtech might be the one-eyed among the blinds.
Point in case compiling and running SPEC is one thing, but understanding where performance differences coming from and drawing the right conclusions is another.

 

[Joe920]

The writing is on the wall, once ARM releases a wider architecture similar to A10 (a phone chip mind you) Core M will not stand a chance, similar to how the 3 wide Atom don't stand a chance against a 2-wide Cortex A73.

So the good news to me seems to be that we are on track for getting very efficient yet powerful Windows tablets and phablets (although MS keeps finding creative ways of turning my 950XL into a mini toaster), that can also run legacy software, but not as efficiently. We don't yet know how efficiently, and for now they will not be all that powerful until a new ARM architecture release (ETA?).

How about storage speed? I see that the latest iPhones have read speeds in the range 700MBps-900MBps, so I guess that's good enough for most. Any intrinsic differences there depending on available chipsets? Given the tone of this thread I suspect the answer will be 'that's storage controllers, that's got nothing to do with the CPU architecture, you fool!!'.

 

[a5cent]

Of course it can. Anandtech could have used gcc for both. It is well known that the Intel compiler generates optimized AVX code for certain SPEC benches, where LLVM/ARM compiler does not generate NEON code. It is also surprising that the Intel compiler does generate particularly good code for SPEC but outside of this it is just average (e.g. if your compiling your own code).

Okay. Even gcc will (or at least should if configured correctly) do slightly different things for different CPU architectures, so no set of results will ever be 100% fairly comparable. You appear to think that the differences between spec2006 for ARM and x86 might be so large that the test is basically worthless. While possible, it would require the people doing the test to be somewhat incompetent. I can't prove or disprove either scenario. But are you sure this is even a thing? I couldn't find anything suggesting that spec2006 was compiled with Intel's compiler for Core M and LLVM for A9X. It seems far more probable that the same compiler was used for both. Do you have a link?

Either way, ignoring complete incompetence for a minute, I don't think it's realistic to assume that using another compiler would change the results so drastically, that Core M would go from being slightly ahead or comparable to ARM, to being laughably behind. I'm pretty sure you don't think that either. Are changes possible? Sure. Could it lead to such a large swing? Since it's from Anandtech and been looked at by half the internet without objection, I'd say that's highly unlikely.

Look, they are journalists not engineers. They typically have a very limited knowledge. I doubt they have any clue about how any of my points from above as example the usage of MESI vs MOESI impact performance and power. In this sense Anandtech might be the one-eyed among the blinds.

For 99.9% of the people working at tech websites, I'd agree with you. However, every Anandtech contributor I've ever looked up was in fact an engineer. Not a journalist. Ian Cutress, the senior CPU/mainboard guy at Anandtech has a STEM background and a PhD. I can't recall what he worked on, but I do remember it being related to computer simulation of physical phenomenon. He's a journalist "only" in his role as a contributor to Anandtech. That's the exact opposite of most tech journalists, who have a journalism major, but little more technical understanding than the average Joe (usually just enough to make the average Joe think they are experts).

At least one of the guys who worked on this test was also an engineer. Discrediting their work should require a bit more than a hunch. If it were most any other tech website I'd agree with you, but then I wouldn't have quoted the test either.

Without a bit more to back up your suspicion, I think it's very safe to assume the results are not wildly off.

If anything should be invalidated, it should be judgements of the affects of two CPUs on battery life, where one device runs iOS (a mobile OS designed specifically to be energy efficient) and the other runs full Windows (a big fat OS where the original designers never intended it to run without a power cord). IMHO the compiler differences are pretty much irrelevant compared to that. ;-)

 

[a5cent]

Given the tone of this thread I suspect the answer will be 'that's storage controllers, that's got nothing to do with the CPU architecture, you fool!!'.

YOU FOOL! There, now everyone's being treated the same and fairly. Just give me a few days to come up with an explanation for the accusation. ;-)

I know things can get a bit heated. I don't mind that sort of thing, but it's not for everyone. As long as people are technically competent and can explain their views, like Cruncher, then they can throw whatever they want my way. That's fine.

@Cruncher04
In my view you're right about most things. I think you've just not yet seen the very latest changes Intel made to the Core M series. I also think you're overestimating the difference that an ISA can make. What really matters is the design of the silicon behind the ISA, and there aren't many differences left in that area between ARM and x86. Anyway, two months ago I would have taken the same position as you.

 

[Grant Taylor3]

Its a really funny/odd/intriguing bit of information Joe920, its exciting yet it seems highly unlikely, its controversial yet a lovely idea (if it worked), its all pipe dream or is it?? I do think these modern phones can give more than they currently do, Because I mentioned an 8 core phone with 3GB Ram in my OP I was by no means comparing that to an 8 core x86 chip, That assumption seems to have been made for me and is ridiculous it was not what I wrote, i would never in a million years compare an 8 core phone cpu with an 8 core x86 cpu (i own 2 i7 and 2 i5 Lenovo's), however i have compared modern phone cpu power with single core x86 cpu's, Very interesting.

It is not a pipe dream I had this sort of thing running on a DEC ALPHA PC over 20 years ago and things have moved on since then.



Of course it will not be as fast as native x86 code running on a Desktop Core i7 but it could be good enough for a large percentage.



Think Windows XP mode but cross architecture.



Also think Bluetooth enabled with cortana and you would not even need to take it out of your pocket to answer a call.



Get to work and connect to a dock and you have your PC with full Domain join Enterprise Windows 10.



Stick a Windows 10 Mobile style front end on for phone form factor devices.

The stuff I was using took the native x86 binary code and translated them on the fly.

Look up FX!32 for more information.

 

[Grant Taylor3]

The interesting thing now is does the new ARM CPU have the guts to perform this and not feel slow.





Back in the day the ALPHA processors were vastly more powerful than the i80486 at the time.





Now what Intel processor does this ARM chip have to perform like to be useable?

 

[a5cent]

Look up FX!32 for more information.

From what I've read, FX32 ran the x86 program in an emulator and then, using information collected at runtime, generated a native Alpha binary. We don't really have enough information to know how MS' solution works, so it's hard to compare.

Anyway, according to Wikipedia, that translated and native Alpha binary ran at about half the speed of a native x86 application. Using the same techniques, that factor would stay about the same. Using the same techniques, we'd still reach 50% of native performance, but those 50% now would just represent a lot more computing power than it did back then. On the other hand, software is also much much heavier than it was back then.

To me, 50% of native performance seems believable (assuming emulation is hardware supported). Whether that's good enough depends on what we want to do of course.

 

[Grant Taylor3]

The software maybe heavier but with the multi core and SSD speed there should not be an issue.

If it could run as fast as a Core 2 Duo then that would be acceptable for occasional use. Again think of it like Windows XP mode as a bridge to new applications in a newer version.

 

[Rosebank]

This is what I had in mind, get it (emulation)established and up and running then with development it can only get better not worse. I have an old core2 duo, T9300 from 6 years ago, its still running fast and very hard pushed to tell the difference between it and my much more powerful laptops with daily use, my son now uses the T9300, it seems an 820 cpu can run windows and photo shop under emulation, leaps ahead of what I had in mind but a welcome surprise, itching to find out the processes used by MS that allow this to work well.

 

[a5cent]

The software maybe heavier but with the multi core and SSD speed there should not be an issue.

If it could run as fast as a Core 2 Duo then that would be acceptable for occasional use.

like I said, whether it's acceptable (for occasional use or otherwise) depends on what that use is. If I just occasionally want to demonstrate XFlow, it won't be acceptable.

I can just barely remember MS Word from 20 years ago. I wouldn't swear it, but it didn't seem any slower to me then than it does now. It certainly couldn't do as much. It didn't look as pretty. But it already did everything 99% of people use Word for today. Today it's just bloated to hundreds of megabytes in size with layer upon layer of software. Back then it clocked in at under 1MB. Most advances in performance don't seem to benefit the consumer using everyday software (mail, office, chat, etc). Those gains just make up for the latest technology that makes software development cheaper at the cost of performance. I wouldn't underestimate that what we're emulating today are big fat software whales, whereas back then what you were emulating were tiny and very efficient hummingbirds in comparison.