Microsoft Windows 10 on ARM

[Nothingness]

And this time it looks like they acknowledged that legacy matters by embedding an x86 simulator

http://news.microsoft.com/2016/12/07/microsoft-empowers-new-development-opportunities-in-mixed-reality-gaming-and-cellular-pcs

To deliver on customers’ growing need to create on the go, Microsoft announced that Windows 10 is coming to ARM architecture through a partnership with Qualcomm. For the first time, customers will be able to experience the Windows they know with the apps, peripherals and enterprise capabilities they require, on a truly mobile, power-efficient, always-connected cellular PC.

Hardware partners will be able to build a range of new Qualcomm Snapdragon-powered Windows 10 PCs that run x86 Win32 and universal Windows apps, including Adobe Photoshop, Microsoft Office and popular Windows games.

These new devices are expected to be in market as early as next year.

 

[VirtualLarry]

So, this is "real" Windows 1o, on ARM? Not Windows RT, not Windows Phone? Interesting. When is Windows Phone getting canned?

 

[cbn]

So, this is "real" Windows 1o, on ARM?

Yep.

From the Anandtech News Post:

http://www.anandtech.com/show/10889/microsoft-and-qualcomm-bring-windows-10-to-snapdragon-processors

n any case, Windows 10’s ability to scale and adapt to essentially any hardware platform is a remarkable feat of engineering, and it’s what makes today’s joint announcement with Qualcomm possible. The first devices with Snapdragon SoCs running the full Windows 10 experience should be available in the second half of 2017.

The major change with today's announcement over Windows RT and UWP is that x86 apps will be able to run on Qualcomm's ARM-based SoCs, along with support for all of the peripherals that are already supported with Windows 10. This alone is a huge change from Windows RT, which would only work with a small subset of peripherals.

 

[Nothingness]

BTW I guess this basically kills the idea of an Intel-based smartphone from MS.

 

[coercitiv]

As you can see, this trailer runs really smoothly

No, I can definitely see stutter in the first two scenes

It's great they finally made it happen, although it's typical MS behavior: years later.

PS: I'm also curious why Edge was preloaded in the demo, and why they demoed Photoshop 32bit instead of 64bit. One could argue a scenario with multiple apps shows multi tasking performance, but then again the PS demo was in a clean environment, with no other app loaded.

As you can see, this trailer runs really smoothly

No necessarily, but definitely makes that phone/desktop hybrid waaaaay more interesting.

 

[cbn]

With core scaling in modern games improving:

http://gamegpu.com/action-/-fps-/-tps/watch-dogs-2-test-gpu

I wonder when we end up seeing consumer mATX boards with multi-core ARM CPUs on them?

Remember the following one (Opteron A1100 development board) from AMD?

http://www.tomsitpro.com/articles/amd-opteron-seattle-arm-soc,1-2105.html

Maybe 3 to 4 years? (Once the ARM platform achieves enough standardization)

EDIT: I am being too optimistic on the timing considering what progress have seen thus far from ARM.

 

[NTMBK]

I suspect this is a precursor to seeing Windows Server on ARM. x86 compatibility layer would be a big help, as it makes it much easier to transition your proprietary software over one piece at a time.

 

[Qwertilot]

PS: I'm also curious why Edge was preloaded in the demo, and why they demoed Photoshop 32bit instead of 64bit..

32 bit because that's all they're going to be emulating (for the moment?!).

I imagine that most of the software that has got updated to 64bit is being updated anyway so is in modern languages/tools etc and would be pretty trivial to port to work natively.

 

[hojnikb]

i wonder what performance penalty is there for arm->x86 emulation

 

[SpaceBeer]

Nowdays, when facebook app requires 2GB of RAM on windows phone, it can't be worse to emulate x86 and open x86 browser to make a post or see some photos

 

[Nothingness]

i wonder what performance penalty is there for arm->x86 emulation

I guess you meant emulating x86 on ARM?

Some numbers on Linux: https://eltechs.com/performance-of-exagear-desktop/

My take is that about half as fast as native already is good.

 

[coercitiv]

32 bit because that's all they're going to be emulating (for the moment?!).

I imagine that most of the software that has got updated to 64bit is being updated anyway so is in modern languages/tools etc and would be pretty trivial to port to work natively.

Yeah, got to read through Anandtech + Ars technica articles, and considering the legal implications of x86 emulation, Anandtech's take on on the matter makes sense.

So it may very well be that it's easier to avoid any potential legal issues by sticking with 32-bit code, though that's supposition on our part. In any case it will be interesting to see what instructions Microsoft's emulator supports, and whether newer instructions and instruction set extensions (e.g SSE2) are supported in some fashion.

 

[Redentor]

This article says something of interesting and new: http://www.bitsandchips.it/52-english-news/7803-redstone-3-will-run-x86-application-on-arm-but-how

 

[SPBHM]

so it will be just like windows on "x86" hardware? download a .exe file and run it (even if slowly)? or is it locked somehow, limited to specific win32 programs or specific features?

if compatibility is good and speed not completely terrible it should be quite nice for cheaper computers, you should still be mostly running native programs anyway.

 

[VirtualLarry]

if compatibility is good and speed not completely terrible it should be quite nice for cheaper computers, you should still be mostly running native programs anyway.

I expect to see $30 ARM-based "TV boxes" running Windows 10 now. Even cheaper than the Atom TV boxes. Btw, this might just foretell the "death of Atom".

 

[Phynaz]

Further details at Ars

http://arstechnica.com/information-...odern-pc-with-vr-project-evo-and-arm-support/

 

[William Gaatjes]

Well, AMD has been developing ARM SOC as well (Opteron A1100). Microsoft might find it interesting to use again.
Because of lack of resources AMD committed to ZEN for obvious x86 reasons and hold back on ARM soc development.
AMD already designed the gpu for the consoles a few times, this may be another step to a possible future where Microsoft has an hardware/software ecosystem.
With funding from a client like Microsoft, AMD could revive their efforts in designing an ARM SOC.
Replacing jaguar cores with multiple high performance ARM cores in the future. It could be, who knows. If it will happen i do not know, but it sure appears like a possible strategy to me.

 

[dark zero]

I suspect this is a precursor to seeing Windows Server on ARM. x86 compatibility layer would be a big help, as it makes it much easier to transition your proprietary software over one piece at a time.

Remember that I said that posts before?
Well... that's it...

And also AMD has K12 to compete Qualcomm, but only in server side. The only few things we know is that they will clock high on their processor speed.

BTW... we saw Qualcomm on this... so, what is the next? Mediatek or Huawei? Mediatek could create a pure Quad Core A73 processor to compete to SD 820 AND AMD Stoney Ridge on the same time.

I expect to see $30 ARM-based "TV boxes" running Windows 10 now. Even cheaper than the Atom TV boxes. Btw, this might just foretell the "death of Atom".

Agreed. Atom is totally screwed up now... the timing is badly done and Intel didn't saw that comming.

i wonder what performance penalty is there for arm->x86 emulation

Supposedly is like 50%
However Qualcomm managed to reduce that big time. Maybe they should concentrate on prepare a processor with L3 cache in order to reduce that disadvantage even more.

 

[cbn]

Well, AMD has been developing ARM SOC as well (Opteron A1100). Microsoft might find it interesting to use again.
Because of lack of resources AMD committed to ZEN for obvious x86 reasons and hold back on ARM soc development.
AMD already designed the gpu for the consoles a few times, this may be another step to a possible future where Microsoft has an hardware/software ecosystem.
With funding from a client like Microsoft, AMD could revive their efforts in designing an ARM SOC.
Replacing jaguar cores with multiple high performance ARM cores in the future. It could be, who knows. If it will happen i do not know, but it sure appears like a possible strategy to me.

It could be that the PC becomes the console in the future.

https://www.engadget.com/2016/08/17/microsoft-aaron-greenberg-qa-project-scorpio-vr/

"The future of Xbox looks a lot like PC gaming." That's what Engadget editor Nathan Ingraham wrote after speaking with Phil Spencer earlier this year. Spencer spoke about wanting to see a steady stream of hardware innovation rather than seven-year gaps between consoles, citing the smartphone market as inspiration. Greenberg went one step further. In his opinion, this is the last console generation. "We think the future is without console generations," he said, explaining that Project Scorpio was a "big bet" that gamers will embrace that notion.

In fact, Microsoft is already Merging Windows 10 with Xbox One to some degree already (example below):


http://www.xbox.com/en-US/windows-10

Now when you own an Xbox Play Anywhere digital title, it’s yours to play on both Xbox One and Windows 10 PC at no additional cost. Play a game and pick up where you left off on another Xbox One or PC, bringing all your saves, game add-ons, and achievements with you. Anywhere is a great place to play.

 

[cbn]

I expect to see $30 ARM-based "TV boxes" running Windows 10 now. Even cheaper than the Atom TV boxes. Btw, this might just foretell the "death of Atom".

Remember pcsrefurbished.com (source of low cost internet)? I wonder if those guys start selling some kind low cost ARM Windows device (small box or tablet/laptop) as an option to the $75 franklin wireless Mifi (wireless hot spot).

That would be interesting considering the Snapdragon 820 already has LTE built in.

Refurbished PC (with WIndows 10) + $75 franklin wireless Mifi vs. New ARM Windows 10 machine with LTE built in?

http://www.windowscentral.com/how-turn-your-windows-10-pc-wireless-hotspot

 

[VirtualLarry]

Interesting thoughts, @cbn .

What will this announcement do for the Rasberry Pi 3? Could that turn it into a viable Desktop client machine? It's some sort of ARMv8 64-bit quad-core SoC, with HDMI, Wifi, and 1GB RAM.

http://www.newegg.com/Product/Product.aspx?Item=9SIA5YB4AM9292&cm_re=pi_3-_-13-300-007-_-Product

This combo could be quite potent for the "developing world",

 

[cbn]

Interesting thoughts, @cbn .

What will this announcement do for the Rasberry Pi 3? Could that turn it into a viable Desktop client machine? It's some sort of ARMv8 64-bit quad-core SoC, with HDMI, Wifi, and 1GB RAM.

http://www.newegg.com/Product/Product.aspx?Item=9SIA5YB4AM9292&cm_re=pi_3-_-13-300-007-_-Product

This combo could be quite potent for the "developing world",

That one has quad core Cortex A53, just like Amlogic S905 (A SoC found in very low cost TV boxes).

Yeah, it will be interesting to see how fast and how far this spreads beyond Qualcomm? (And how important standardizing ARM as a platform will be for this purpose)

 

[cbn]

Geekbench 4 results....

(the Q6600 doesn't have AES)

Q6600 (LGA 775 C2Q):
https://browser.primatelabs.com/v4/cpu/1273759
(ST 1497, MT 4125)

Snapdragon 820 @ 1.59 Ghz (as MSM 8996):
https://browser.primatelabs.com/v4/cpu/1284320
(ST 1681, MT 3974)

Snapdragon 820 @ 2.19 Ghz (as MSM 8996):
https://browser.primatelabs.com/v4/cpu/1283841
(ST 1822, MT 4096)

J3455 (Goldmont atom quad core):
https://browser.primatelabs.com/v4/cpu/1279939
(ST 1495, MT 4068)

 

[Exophase]

I guess you meant emulating x86 on ARM?

Some numbers on Linux: https://eltechs.com/performance-of-exagear-desktop/

My take is that about half as fast as native already is good.

I think you've seen my comments on exagear before, but I don't think these are very representative benchmarks.

50% native for a wide set of real world software would be a fair bit ahead of what we've seen with Houdini on Android going in the opposite direction, but it could be plausible. Will be especially interested to see how well it does with SSE. SSSE3 or so maps a lot better to NEON than the other way around, in my experience.

I wonder if we'll be seeing better ARM dev support than is available right now on Windows Phone. eg, proper desktop support for normal non-MS developers, open executable formats.. if GCC could target it that'd be especially good. It's a big burden trying to port ARM assembly code (and to a lesser extent some GCC stuff in general) that targeted GAS, to MSVC. There's also some big open questions about compatibility on Windows Phone, for example MS says that ARM mode isn't supported (Thumb-2 only), although in testing it seems to work OK.

 

[Nothingness]

I think you've seen my comments on exagear before, but I don't think these are very representative benchmarks.

Agreed, that's why I took care of stating I think 50% of native already is good. I still think giving a data point is interesting

50% native for a wide set of real world software would be a fair bit ahead of what we've seen with Houdini on Android going in the opposite direction, but it could be plausible. Will be especially interested to see how well it does with SSE. SSSE3 or so maps a lot better to NEON than the other way around, in my experience.

There are also many fine points in the ISA that makes simulation either slow or inaccurate (e.g. FP NaN).

I wonder if we'll be seeing better ARM dev support than is available right now on Windows Phone. eg, proper desktop support for normal non-MS developers, open executable formats.. if GCC could target it that'd be especially good. It's a big burden trying to port ARM assembly code (and to a lesser extent some GCC stuff in general) that targeted GAS, to MSVC. There's also some big open questions about compatibility on Windows Phone, for example MS says that ARM mode isn't supported (Thumb-2 only), although in testing it seems to work OK.

Wouldn't you have to explicitly change symbols resolution in the linker to prevent interworking from properly functioning? IIRC symbols get their lower bit set to 1 for T2 code while ARM functions have it set to 0. It's been a long time since I did any 32-bit ARM dev