Microsoft Brings x64 Emulation to Windows on Arm PCs

[Alan Wynn]

In what way?

Simply by not providing a compelling case for supporting Windows on Arm. Microsoft has ported Windows to many other architectures, none were ever compelling and so never got developers to port to them. All had some ability to run some set of existing Windows apps either through emulation (or in a one or two cases as I recall, translation).

Dotnet apps are very easy to port and universal apps would already work. MS have all kinds of developer support it’s the lack of developer desire that’s the issue.

They lack the most important form of developer support, a reason to care about the platform. Lacking that, it seem pretty clear as to why so few developers have ported their applications.

As a dev why would you have thought Arm would work this time until Apple made the move?

How does Apple, with under 7% worldwide desktop market share adopting its own Apple Silicon make Windows on Arm more compelling? Did the Arm-based Surface systems suddenly get faster or get extended battery life? Until someone makes an Arm-based Windows system that is compelling, Apple’s actions will not really matter.

It’s easy for Apple to move as the ecosystem is smaller and they can force a change.

No. It is easier for Apple to transition platforms because they are willing to commit to a change. People on here point to the fact that one can still run MS-DOS games on Windows as a great thing (it has some benefits), but it is that lack of willingness on Microsoft’s part to really commit to these changes that makes them take so long to get adopted.

MS have their hands tied as they live in a broader world of devices and partners as well as huge legacy support.

You mistake cause and effect. Microsoft has chosen to have its past be its priority, not its future. More niche products will port when they are forced to do so. Continuing to cater to them just enables this bad behavior and holds their platform back. Let us be clear here, Microsoft is not captive to its OEMs, its OEMs have to do what Microsoft wants.

Personally I’m amazed MS put in the effort and kept putting in the effort for 8 years with very little reward. For Apple it’s almost guaranteed success, although a minor gamble if they end up MacOS only

Apple’s success will be due to how compelling Apple Silicon is. I have no idea what was driving Microsoft’s desire to port other than seeing Apple’s success with its own chips and misunderstanding that as a general advantage of Arm over x86_64.

 

[cgsnipinva]

The problem with Windows on ARM is stated in the article. Most apps are 32 bit x86 based app so they need emulation. If MS wants to be successful in this arena - they need to find a way to push their third party software portfolio to 64 bit native ARM as well as their own software.

 

[Alan Wynn]

The problem with Windows on ARM is stated in the article. Most apps are 32 bit x86 based app so they need emulation. If MS wants to be successful in this arena - they need to find a way to push their third party software portfolio to 64 bit native ARM as well as their own software.

Their problem is that they lack a clear definition of success. Is their goal with Windows on Arm to have that be their future platform or just one of two? Is their interest in trying to become a serious contender in the Windows hardware space? Are they just hedging their bets? Without clear answers to these questions, it is impossible to understand what they need to do to be successful.

 

[spinedoc77]

x86 and x64 emulation performance is excellent under Windows ARM. Did you even bother to check the numbers? Most benchmarks run between 50% and 70% of native performance - which is probably as good as it gets for a dynamic translation solution.
Also x64 code is easier to emulate than x86 code, so it comes with no surprise that x64 emulation is faster - as initial tests show. Main reason is, that x86 code contains significantly more memory references compared to x64 code - which is sub-optimal when running on ARM.

50-70% of native performance, depending on which end of that spectrum a particular app falls I don't know if I'd call that excellent. But really my gripe isn't with performance, it's with battery life. I'll admit it's been a couple of months since I've read reviews, but most were saying there was no meaningful battery life improvement using a x86 app emulated and in many cases battery life was actually worse than using an Intel proc. (PS note that your "as good as it gets" is still not what Apple gets with Rosetta 2, from what I understand it's much higher in most (not all) test results: Rosetta2: x86-64 Translation Performance - The 2020 Mac Mini Unleashed: Putting Apple Silicon M1 To The Test (anandtech.com)

I get that some users use ARM apps on their mobile devices and a Windows/ARM device can be enticing to them (although personally I don't think even the battery gains in ARM only use is that spectacular, what are we talking maybe 20%?), but that's not the way I use my mobile device/tablet. This is where Rosetta 2 shines as from what I understand there is no hit to battery life, so running x86/x84 will have similar battery life as a native ARM app.

Anecdotally there are a few posts from those who have tried the x64 emulation and from what I understand it's very bad, but of course it's only at the developer stage and not ready for prime time use. I read just this morning: My experience with x64 emulation on the Pro X : Surface (reddit.com) I will repeat this is only anecdotal and not necessarily representative of what most are experiencing, but I have seen several posts such as this one in various different forums.

Just to put things into perspective I AM a Microsoft fan boy, I buy every surface pro every single year, I use and highly prefer Windows, etc.

 

[PickUrPoison]

In what way? Dotnet apps are very easy to port and universal apps would already work. MS have all kinds of developer support it’s the lack of developer desire that’s the issue. As a dev why would you have thought Arm would work this time until Apple made the move? It’s easy for Apple to move as the ecosystem is smaller and they can force a change. MS have their hands tied as they live in a broader world of devices and partners as well as huge legacy support. Personally I’m amazed MS put in the effort and kept putting in the effort for 8 years with very little reward. For Apple it’s almost guaranteed success, although a minor gamble if they end up MacOS only

I never thought Windows on ARM would work 🤷‍♂️ But now that there’s decent hardware, at least there’s a chance.

Apparently ms’s ARM strategy the last 8 years was waiting for a magical ARM chip and machines using it to drop from the sky. Now that that’s finally happened, I guess we’ll see how interested they are in supporting it. I assume they’ll go all in.

 

[Maximara]

MS makes almost no money on the Macs to begin with...and has not for several decades. First, Apple only has, at best, year after year for 30+ years, 7% of the Personal Computer space. That's such a tiny segment of the Personal Computer market. Think about it: if one piece of the market supplies 93%+ of your potential customers and the other segment of your market supplies 7%, who are you going to write your apps for?

Second, out of the few million Apple Macs that are sold each year (10-20 million source: https://www.statista.com/statistics/276308/global-apple-mac-sales-since-fiscal-year-2002/ ) , only a minority purchase MS Office. A miniscule share want to run Windows on a Mac. So to say that this "would actually be quite a money making opportunity for MS" is nonsense and most likely not worth Microsoft's time other than to promote that MS now supports ARM in some capacity to make some folks happy. "But what about all the iPads and iOS devices that are ARM?!" folks will say. My reply is that practically nobody on a touch screen iOS device is using MS Office. So again, this is not going to make much money for Microsoft.

You forgot about the mobile market which dwarfs the Personal Computer market. In fact, Exiting x86: Why Apple and Microsoft are embracing the Arm-based PC, which I cited a while ago shows the x86 hit its peak in 2011 and has been in a decline (abet a slow one) ever since.

As the graph shows the future is ARM and not x86

Microsoft is going to concentrate on where the sales and profits live: non-Apple world.

Which is ARM and Microsoft needs a large penetration in the market to refine it ARM OS and that market is Apple. Yes odds are it will be virtualization but they need something so their x86 emulator doesn't continue to blow goats from a cannon.

Dell shipped 260 MILLION machines in 2019...Lenovo shipped 60+ million. Then factor in Toshiba and all the other Wintel players. Again, I'm sure MS will happily accept some revenue from Mac Arm folks, but it's tiny peanuts compared to the Wintel vendors out there.

The problem and the one the Windows world likes to ignore is those machines are so loaded with ad/spamwere that Windows runs a lot slower. The fact of the matter PCs are only a third of Dell's sales and Lenovo’s Yoga 5G is the first ARM-powered Windows laptop with 5G is their latest trip into ARM.

Another problem is there is really no way to know how much of that is replacement rather than new sales.

 

[Maximara]

Yeah, still not worried about this. If nothing else, I think Windows still has a worse reputation than MacOS once you get outside of MacRumors troll country. People would run the comparisons and over time and the pattern would become clear. There's an amusing amount paranoia around Apple, so there may be some people who think the reason Windows is slow is because Apple is withholding access to key functionality, but I think the difference will be seen between the OSs and libraries, not the underlying hardware.

To be fair to Microsoft/Windows much of problem is that margins of most (if not all Intel) PC hardware is so thin that they have to load up the hard drive with so much adware (and background processes) that the OS performance and stability takes a serious hit.

 

[PickUrPoison]

MS makes almost no money on the Macs to begin with...and has not for several decades. First, Apple only has, at best, year after year for 30+ years, 7% of the Personal Computer space. That's such a tiny segment of the Personal Computer market. Think about it: if one piece of the market supplies 93%+ of your potential customers and the other segment of your market supplies 7%, who are you going to write your apps for?

Second, out of the few million Apple Macs that are sold each year (10-20 million source: https://www.statista.com/statistics/276308/global-apple-mac-sales-since-fiscal-year-2002/ ) , only a minority purchase MS Office. A miniscule share want to run Windows on a Mac. So to say that this "would actually be quite a money making opportunity for MS" is nonsense and most likely not worth Microsoft's time other than to promote that MS now supports ARM in some capacity to make some folks happy. "But what about all the iPads and iOS devices that are ARM?!" folks will say. My reply is that practically nobody on a touch screen iOS device is using MS Office. So again, this is not going to make much money for Microsoft.

Microsoft is going to concentrate on where the sales and profits live: non-Apple world. Dell shipped 260 MILLION machines in 2019...Lenovo shipped 60+ million. Then factor in Toshiba and all the other Wintel players. Again, I'm sure MS will happily accept some revenue from Mac Arm folks, but it's tiny peanuts compared to the Wintel vendors out there.

Dell definitely didn’t ship 260 million PCs last year. They’re not a huge player, but they did sell about twice as many units as Apple, maybe 40-45 million units.

Will ARM eventually outsell x86-64 as a Windows platform? Who knows 🤷‍♂️

 

[PickUrPoison]

To be fair to Microsoft/Windows much of problem is that margins of most (if not all Intel) PC hardware is so thin that they have to load up the hard drive with so much adware (and background processes) that the OS performance and stability takes a serious hit.

Adware? Sounds like an OS problem to me.

 

[AndyMacAndMic]

Adware? Sounds like an OS problem to me.

Nope that is not an OS problem. Adware are extra programs added by the OEM (Dell, HP etc.). This has nothing to do with the OS.

 

[Gerdi]

Here was your original quote:

You made an absolute statement which is clearly wrong. It is not just wrong for the case of the Microsoft’s hardware, it is wrong for much of what is considered standard drivers: USB HIL, basic graphics, basic audio, CD/DVD/SATA drivers, and many more. There are certainly specialized drivers, but most drivers an average system needs are provided by Microsoft.

That you are able to come up with an example of a driver that one would need to get from a third party does not change that there are many drivers provided by Microsoft.

You still do not grasp the fact that even if Microsoft is considered the OEM, the specific drivers are provided by Qualcomm. So my Nvidia example is not just a random example but the general rule for non-generic drivers.

The generic drivers you are describing above apparently work on M1.
I had the impression you were aiming for a HW accelerated driver for the M1 GPU and video acceleration features - which again Microsoft never writes nor do the maintenance.

The question being discussed is if Microsoft intends to do it or if they will work with a virtualization company to do it.

The Virtualization company does not need the help of Microsoft, as the DirectX12 interfaces are clearly specified. They just have to do the work including code maintenance - as would do any HW company which aims to provide Windows support.
I am not ruling out, that Microsoft will offer support when Parallels (or whoever) running into issues. Microsoft just won't take responsibility for such development efforts.

Interestingly Microsoft is currently working on HW accelerated OpenGL and Wayland compositor for WSL2. In this case Microsoft provides the Virtualization solution (e.g. WSL2) and therefore also develops the display driver for the Linux guest.

 

[Gerdi]

50-70% of native performance, depending on which end of that spectrum a particular app falls I don't know if I'd call that excellent.

There is no faster dynamic translator i am aware of - and there are certain limits which you cannot get past when doing dynamic translations.

But really my gripe isn't with performance, it's with battery life. I'll admit it's been a couple of months since I've read reviews, but most were saying there was no meaningful battery life improvement using a x86 app emulated and in many cases battery life was actually worse than using an Intel proc.

Such conclusions typically happens if the wrong reference is taken - for instance when you compare with a device with significantly larger battery or lower resolution screen. But yes there is a certain hit when emulating stuff compared to native, simply because you are running more instructions for the same work under emulation. Naturally there is similar hit for Rosetta - its not like M1 is consuming less energy when doing more...

(PS note that your "as good as it gets" is still not what Apple gets with Rosetta 2, from what I understand it's much higher in most (not all) test results: Rosetta2: x86-64 Translation Performance - The 2020 Mac Mini Unleashed: Putting Apple Silicon M1 To The Test (anandtech.com)

Rosetta translates in many cases statically (aka ahead-of-time)- so this is always faster. In some cases also Rosetta has to fall-back to dynamic translation (aka JIT) - as for instance when running Javascript benchmarks. And indeed, turns out for Javascript Rosetta tends to land in the 50% performance range from what i have seen.
I can only repeat myself, getting up to 70% of native performance for a JIT engine exceptionally good - i believe technically there is not much room for improvement - given how dynamic translation works.

Anecdotally there are a few posts from those who have tried the x64 emulation and from what I understand it's very bad, but of course it's only at the developer stage and not ready for prime time use. I read just this morning: My experience with x64 emulation on the Pro X : Surface (reddit.com) I will repeat this is only anecdotal and not necessarily representative of what most are experiencing, but I have seen several posts such as this one in various different forums.

You might want to read more impressions from here. Sure not everything works, but what works seems to work good. Also as expected x64 seems to be faster than x86 emulation.

 

[spinedoc77]

There is no faster dynamic translator i am aware of - and there are certain limits which you cannot get past when doing dynamic translations.

You are saying the current x86 implementation Microsoft uses is as fast as Rosetta 2?

Such conclusions typically happens if the wrong reference is taken - for instance when you compare with a device with significantly larger battery or lower resolution screen. But yes there is a certain hit when emulating stuff compared to native, simply because you are running more instructions for the same work under emulation. Naturally there is similar hit for Rosetta - its not like M1 is consuming less energy when doing more...

For reference the battery in the SP-x is 38whr, the battery in the SP7 is 43.2whr, so about 13% difference give or take. Most reviews I've read such as Windows Central note the SP-X has about a 20% advantage in battery life IF USING ARM APPS, with benchmarking being about 8 hours versus 10 hours, in that same review battery life fell to about 7 hours when using emulated x86 apps which is WORSE than the SP7, but allowing that 13% difference in battery size means they are close to equal. Just to put things into further perspective the SP6 has a 45.0whr battery but typically is shown in benchmarks to get at least 20%-30% better battery life than the SP7. So the SP-X running x86 emulated apps gets worse battery life than an Intel device with a 2 generation old chip. This is where I see so many losing sight of what the main goal of ARM really is, battery life. From what I understand the M1 Macbooks are getting about 50% more battery life when using Rosetta 2, now that IS significant, when using ARM the gap widens even more significantly (with at least Apple claiming double, 10 hours vs 20 hours!). If the Surface Pro-X ran x86 at a crappy 50% power BUT got 50% more battery life, I think that would be significant, but Apple has them beat on BOTH factors.

Rosetta translates in many cases statically (aka ahead-of-time)- so this is always faster. In some cases also Rosetta has to fall-back to dynamic translation (aka JIT) - as for instance when running Javascript benchmarks. And indeed, turns out for Javascript Rosetta tends to land in the 50% performance range from what i have seen.
I can only repeat myself, getting up to 70% of native performance for a JIT engine exceptionally good - i believe technically there is not much room for improvement - given how dynamic translation works.

So the devil is in the details, I suppose it depends on which programs Rosetta has to fall back to JIT with. Is this that common? I haven't seen much mention of it in benchmarks/reviews so I have to assume it's not that common, but is an interesting point to explore. I put up benchmarks showing clearly superior translation, I'd be curious if you had any benchmarks showing the opposite for JIT and what major programs/platforms out there use JIT where it will be a real world issue. And again, you didn't say "up to 70%", you said "50-70%" which is a pretty huge difference depending on where on that spectrum a programs performance lands. But even if we make believe 70% is the number it again brings us back to my main point, battery life.

You might want to read more impressions from here. Sure not everything works, but what works seems to work good. Also as expected x64 seems to be faster than x86 emulation.

?? I read through that and it looks like a disaster, BUT this is pre-release developer so of course it should have tons of issues. It's too early to tell either way, personally I think Microsoft will eventually work it out but I doubt it will have significantly more battery life than x86. But again, it's too early to tell.

I'd also like to note that most of this stuff is technically above me and I can only opine as a lowly consumer. If I'm sacrificing compatibility, stability, performance, etc then you better give me something in return, and personally that something should be battery life. I'm a diehard Microsoft fan, but even I would not touch the Pro-X with a 10 foot pole in its current iteration. I can see the benefit of it to someone who uses ARM only, but that's not my use case scenario. I also think that just looking at hardware alone is myopic, you also have to look at development support. Microsoft has been trying their hand at ARM for what at least 8 years now? My biggest hope is that developers porting their apps to ARM for use on MacOS will be able to easily port this to Windows ARM as well, but that won't mean much if the hardware doesn't follow.

 

[Alan Wynn]

You still do not grasp the fact that even if Microsoft is considered the OEM, the specific drivers are provided by Qualcomm. So my Nvidia example is not just a random example but the general rule for non-generic drivers.

Discussing with you is like trying to grab mercury. You begin my making an absolute statement (in this case: “Microsoft never provides drivers”), then whenever people provide counter examples, you respond with the equivalent of “those do not count“ (“Microsoft is considered the OEM”, I was talking “about HW accelerated drivers”, etc.), and follow that by saying that sometimes even the drivers provided by Microsoft are written by other people.

None of these change the facts. Your blanket, absolute statement was false and all the qualifications you try to add just demonstrate it.

Interestingly Microsoft is currently working on HW accelerated OpenGL and Wayland compositor for WSL2. In this case Microsoft provides the Virtualization solution (e.g. WSL2) and therefore also develops the display driver for the Linux guest.

Again, this just demonstrates what I was saying above, and further supports my general point. Microsoft will put together a release of Arm Windows for macOS if they feel it benefits them.

 

[Gerdi]

For reference the battery in the SP-x is 38whr, the battery in the SP7 is 43.2whr, so about 13% difference give or take. Most reviews I've read such as Windows Central note the SP-X has about a 20% advantage in battery life IF USING ARM APPS, with benchmarking being about 8 hours versus 10 hours, in that same review battery life fell to about 7 hours when using emulated x86 apps which is WORSE than the SP7, but allowing that 13% difference in battery size means they are close to equal. Just to put things into further perspective the SP6 has a 45.0whr battery but typically is shown in benchmarks to get at least 20%-30% better battery life than the SP7. So the SP-X running x86 emulated apps gets worse battery life than an Intel device with a 2 generation old chip. This is where I see so many losing sight of what the main goal of ARM really is, battery life. From what I understand the M1 Macbooks are getting about 50% more battery life when using Rosetta 2, now that IS significant, when using ARM the gap widens even more significantly (with at least Apple claiming double, 10 hours vs 20 hours!). If the Surface Pro-X ran x86 at a crappy 50% power BUT got 50% more battery life, I think that would be significant, but Apple has them beat on BOTH factors.

Nothing much wrong with your calculation. However your conclusion is wrong. Main feature of ARM is better efficiency. Efficiency goes into both directions either more performance at same power or less power at same performance or anything in between.
Have you seen the awful performance of the SoC Intel designed to compete with SQ1 in the Surface Pro X? It is called Lakefield and you can get it in the Tablet from Samsung.
Thing is with say a Surface Pro X you typically run mostly ARM64 apps - otherwise it would be the wrong device for you. So even if your application mix contains the occasional x86/x64 app, the battery life stays comfortably ahead of a Surface Pro 6. (I do own both devices) - thats all while being thinner and having a bigger screen.

Regarding M1 vs SQ1 - are you honestly comparing a brand new 5nm designed SoC vs. a 2 years old SoC produced at 7nm? And then you conclude that is due to emulation being bad in Windows ARM? Remember this is precisely the point where we started the discussion.

So the devil is in the details, I suppose it depends on which programs Rosetta has to fall back to JIT with. Is this that common? I haven't seen much mention of it in benchmarks/reviews so I have to assume it's not that common, but is an interesting point to explore. I put up benchmarks showing clearly superior translation, I'd be curious if you had any benchmarks showing the opposite for JIT and what major programs/platforms out there use JIT where it will be a real world issue. And again, you didn't say "up to 70%", you said "50-70%" which is a pretty huge difference depending on where on that spectrum a programs performance lands. But even if we make believe 70% is the number it again brings us back to my main point, battery life.

JIT has to be used, when the application itself produces code and runtime. This is the case for all applications based on .Net, Mono, Java, Javascript (e.g. most code running in the context of Web-browser session), Electron etc.

?? I read through that and it looks like a disaster, BUT this is pre-release developer so of course it should have tons of issues. It's too early to tell either way, personally I think Microsoft will eventually work it out but I doubt it will have significantly more battery life than x86. But again, it's too early to tell.

Interesting, that perception can be so different. All of the x64 apps i would have liked to run now suddenly running - with exception of World of Warcraft. Thing is that the number of native ARM64 Windows app grow every day.

My biggest hope is that developers porting their apps to ARM for use on MacOS will be able to easily port this to Windows ARM as well, but that won't mean much if the hardware doesn't follow.

Purely looking at the technical side, there is not much synergy. I believe the biggest impact of Mac ARM on Windows ARM is raising awareness among the SW developers.

 

[Alan Wynn]

There is no faster dynamic translator i am aware of - and there are certain limits which you cannot get past when doing dynamic translations.

You love to artificially limit your comparisons. Either Microsoft’s approach is faster or the same speed as Rosetta 2 or it is not. End users do not care about the technical definitions or choices that were made, they care about comparable results. If dynamic translators are slower than the technology used in Rosetta 2, then they made the wrong choice. If they are not, then no need to qualify it.

Rosetta translates in many cases statically (aka ahead-of-time)- so this is always faster.

Again, if this statement is true, then it seems that Microsoft made the wrong choice. Users care about results.

In some cases also Rosetta has to fall-back to dynamic translation (aka JIT) - as for instance when running Javascript benchmarks.

Why would Javascript benchmarks have to be run as x86_64 code and not done using a native Javascript interpreter? Also, even if the interpreter was not native, why would it not be pre-transcoded?

And indeed, turns out for Javascript Rosetta tends to land in the 50% performance range from what i have seen.

Please provide a citation.

 

[Alan Wynn]

JIT has to be used, when the application itself produces code and runtime. This is the case for all applications based on .Net, Mono, Java, Javascript (e.g. most code running in the context of Web-browser session), Electron etc.

This makes no sense. One either pre-translates the interpreter or runs the code on a native interpreter. Neither Java nor Javascript is x86 or x86_64 code.

 

[Gerdi]

Discussing with you is like trying to grab mercury. You begin my making an absolute statement (in this case: “Microsoft never provides drivers”), then whenever people provide counter examples, you respond with the equivalent of “those do not count“ (“Microsoft is considered the OEM”, I was talking “about HW accelerated drivers”, etc.), and follow that by saying that sometimes even the drivers provided by Microsoft are written by other people.

I never claimed that your examples do not count. I did refine my statement, that it was to be read in the context of non generic drivers - because the generic drivers are totally irrelevant in the context of the discussion - because they are already available and have no impact on the question what drivers are required for a better experience on the M1 Macs running Windows.

Thing is i had hoped you are able to put some statements into the proper context - namely the question of required Windows driver for M1 Macs. Apparently you are unable to do so.

So i give you back, that the discussion with you has largely been an unpleasant experience.

None of these change the facts. Your blanket, absolute statement was false and all the qualifications you try to add just demonstrate it.

This comes from you, who made an absurdly wrong statement about porting, while you meant packaging?

 

[spinedoc77]

Nothing much wrong with your calculation. However your conclusion is wrong. Main feature of ARM is better efficiency. Efficiency goes into both directions either more performance at same power or less power at same performance or anything in between.
Have you seen the awful performance of the SoC Intel designed to compete with SQ1 in the Surface Pro X? It is called Lakefield and you can get it in the Tablet from Samsung.
Thing is with say a Surface Pro X you typically run mostly ARM64 apps - otherwise it would be the wrong device for you. So even if your application mix contains the occasional x86/x64 app, the battery life stays comfortably ahead of a Surface Pro 6. (I do own both devices) - thats all while being thinner and having a bigger screen.

Regarding M1 vs SQ1 - are you honestly comparing a brand new 5nm designed SoC vs. a 2 years old SoC produced at 7nm? And then you conclude that is due to emulation being bad in Windows ARM? Remember this is precisely the point where we started the discussion.

No my conclusion is correct, Microsoft's iteration of Windows on ARM, specifically in my example of the Pro-X and the SQ1 chip, does not have any significant battery gains and in x86 emulation can even be said to have worse battery. This is in contrast to the M1 chip which has significant battery gains in BOTH x86 and native ARM. It gets even worse if you use the term efficiency; if running a x86 app in emulation costs 30-50% power and uses the same or more battery I think it's a pretty safe bet to say that it's not very efficient.

Who said you typically run ARM64 apps on the Pro-X? Obviously there is a reason Microsoft gave it the ability to emulate x86 and eventually x64, because that's a humungous part of their market and what their users use. I do agree that there are consumers who use only ARM apps and welcome having a little bit of extra battery life, but I'd also opine that many consumers picked the Pro-X over the SP7 because of the smaller bezels, instant on, keyboard with pen slot, LTE, etc. If Microsoft has released the SP7 with all those features, and the battery life of the SP6 the Pro-X would have tanked, if it hasn't already.

Regarding M1 vs SQ1, yep I'm definitely making the comparison. In fact I'll double down and make the comparison between the M1 and the SQ2 which was released what a couple of months ago? That had only very very marginal gains against the SQ1.

JIT has to be used, when the application itself produces code and runtime. This is the case for all applications based on .Net, Mono, Java, Javascript (e.g. most code running in the context of Web-browser session), Electron etc.



Interesting, that perception can be so different. All of the x64 apps i would have liked to run now suddenly running - with exception of World of Warcraft. Thing is that the number of native ARM64 Windows app grow every day.



Purely looking at the technical side, there is not much synergy. I believe the biggest impact of Mac ARM on Windows ARM is raising awareness among the SW developers.

Well I'll let others who are more technically inclined discuss that point, but based on others responses it doesn't seem to be holding up too well. I don't see native ARM64 apps growing exponentially, well unless we count on all the devs that are climbing over each other to develop for the M1. I'm hoping that does translate to the Windows side. But we all know what horrible support devs have given to Microsoft over the past 8+ years, but deservedly so as Microsoft has dropped the ARM ball so many times.

With all that said I'm really not sure what point you are trying to uphold. My point is simply that the M1 is a much better solution from both a power AND a battery standpoint when combined, and if you like termed as "efficiency". On the flip side Microsoft's implementation suffers from poor efficiency.

 

[Maximara]

Nope that is not an OS problem. Adware are extra programs added by the OEM (Dell, HP etc.). This has nothing to do with the OS.

Right. The margines are so thin in the PC hardware market that the OEM need those adware programs to actually make a profit. The problem is all that crap slows down the OS and not all of it is well written or conflicts with something deep in the OS and suddenly you are in the Bluescreen of death.

 

[windowsblowsass]

Apple has been clear that they will not support any other native OS, so Bootcamp will not be an option. Virtualization will be, if they decide to offer it, but that is Microsoft’s choice.

Apples only statement on the matter was that the technology is there and running windows on an M1 mac was entirely up to Microsoft.

 

[Alan Wynn]

Apples only statement on the matter was that the technology is there and running windows on an M1 mac was entirely up to Microsoft.

No, Apple also said that Bootcamp would not be supported (and that they would not support any other native OS on the hardware).

 

[AndyMacAndMic]

No, Apple also said that Bootcamp would not be supported (and that they would not support any other native OS on the hardware).

I read something completely different from this article:

https://www.zdnet.com/article/top-a...-m1-macs-is-a-choice-microsoft-needs-to-make/

It seems that, as other posters already said: 'It is up to Microsoft'.
Where can I find your statement that Bootcamp will not be supported (and that they would not support any other native OS on the hardware)?

 

[Alan Wynn]

I read something completely different from this article:

https://www.zdnet.com/article/top-a...-m1-macs-is-a-choice-microsoft-needs-to-make/

It seems that, as other posters already said: 'It is up to Microsoft'.
Where can I find your statement that Bootcamp will not be supported (and that they would not support any other native OS on the hardware)?

Here is the quote:

“We’re not direct booting an alternate operating system,” says Craig Federighi, Apple’s senior vice president of software engineering. “Purely virtualization is the route. These hypervisors can be very efficient, so the need to direct boot shouldn’t really be the concern.”

Pretty unambiguous, but of course, things could always change.

 

[AndyMacAndMic]

Here is the quote:

Pretty unambiguous, but of course, things could always change.

Well, It seems Apple is giving mixed signals then. The link I posted was pretty unambiguous and your link too. Both put together they seem pretty ambiguous to me