Windows Mobile 10 without aarch64 support?

[Cruncher04]

It just came to my attention, that even in the latest version of Visual Studio, there is no support for aarch64. When thinking about it, there is also no way to submit aarch64 apps to the app-store.
Conclusion would be, that Windows Mobile 10 (and all apps in the store) will be 32 bit even on Lumia 950, even though they contain 64 bit processors. Likewise, Lumia 950 phones will be much slower than Android phones with the same Qualcomm SoC.

Is Microsoft stupid or do i miss something?

 

[npoe]

I haven't seen data about the difference in performance for 32 bits apps vs 64 bits app in ARM. I remember some Qualcomm head engineer saying that it was really about marketing and not about performance.

 

[Cruncher04]

I haven't seen data about the difference in performance for 32 bits apps vs 64 bits app in ARM. I remember some Qualcomm head engineer saying that it was really about marketing and not about performance.

That was the statement of a Qualcomm engineer, when only Apple had 64 bit
Cortex-A57 is about 20-25% faster with 64 bit code, which is significant. The aarch64 ISA is much more optimized and among other things has double the amount of registers (increase from 16 to 32).

 

[jpal12]

The main difference between 64-bit and 32-bit arm is the new arm version. The 64-bit part is mostly just marketing.

 

[Cruncher04]

The main difference between 64-bit and 32-bit arm is the new arm version. The 64-bit part is mostly just marketing.

Therefore i was referring to AArch64 and not just 64 bit. Programs compiled for AArch64 show a significant speed-up compared to when compiled for AArch32/ARMv7 on the _SAME_ CPU (Cortex A57, Cortex A72)
My Issue is, that Windows itself and all apps are compiled for AArch32/ARMv7 and not for AArch64, which makes the CPU work in compatibility mode and by doing so throwing lots of the performance out of the Window (in particular compared to Android and iOS, which both fully support Aarch64).
This just means, that while having the same SoC as Android Smartphones, the performance will be quite a bit worse.

Or to make it more clear, Windows phones will be one generation behind Android phones using the same SoC performance wise.

 

[npoe]

I was kind of expecting 32 bits when they got 3 GB of RAM for the Lumia 950 but I didn't know the specific impact that 64 bits or 32 bits would have. I kind of wonder if they are going to change the OS once Qualcomm has their proprietary architecture in the market.

 

[Cruncher04]

I kind of wonder if they are going to change the OS once Qualcomm has their proprietary architecture in the market.

Not sure, why they would decide to align introduction of 64 bit support with Qualcomm's proprietary architecture. I mean Snapdragon 820 with its proprietary architecture will be AArch64 compliant as well as any other phone SoC for the next years. Even low and mid-rage phones introducing AArch64 with Cortex A53.
What irritates me even more is, that there is no sign of AArch64 support in Visual Studio 2015. I mean this would be a prerequisite for everything else.

It did already bother me that Microsoft introduces an high-end phone at the end of Snapdragon 810's life cycle. And then there is not even a chance to use this SoC as it was supposed to be?

 

[npoe]

That bothers me too but since I'm using a Lumia 920 the 950 XL will be an awesome upgrade. I just waited to much time to change my cellphone this time. Hopefully they wont take that much time for the 2016 flagships.

Sadly with the way that Microsoft usually works I don't hold a lot of hope for them ot release a new 64 bit version but I still want to believe that it'll be here "soon". I wish to not be disappointed.

 

[AfroPhysics]

The applications will probably show as AnyCPU not aarch64. Any platform specific optimizations will be handled by the CLR and not be specifically compiled to that and only that. Updating and extending compiler support in the CLR and framework for CPU based optimizations can be done later, which is a benefit of managed code.

 

[Ivan05il]

"just marketing" is not something MS can afford to ignore. Android phones and Apple are fighting who has more cores, more bits, more RAM. Yes, some of it are gimmicks or not to be used to the full potential, but that's not that important in the big picture. Dragging reason into this won't sell the phones. MS needs to show that Windows Mobile isn't just an afterthought, but that they care to give their customers the best.

 

[Cruncher04]

The applications will probably show as AnyCPU not aarch64. Any platform specific optimizations will be handled by the CLR and not be specifically compiled to that and only that. Updating and extending compiler support in the CLR and framework for CPU based optimizations can be done later, which is a benefit of managed code.

Few statements:
1) Updating runtime translation within CLR has as prerequisite that Windows 10 Mobile is compiled itself for 64 bit in the first place.
2) Not all apps are managed code, there are lots a native applications and Windows 10 Mobile itself, which are compiled native.
3) It can be argued that native apps need the performance most, because that is one of the reasons they are compiled native in the first place. In fact most if not all high quality games are all C/C++. Runtime critical algorithms in photo and video apps including apps like VLC are all C/C++.

 

[mortici]

That's because ARM based chips are not what MS is going after... x86 SoC chips is where they are going. There is not reason to invest in a new arch type for dev, when you can just using existing amd64/x86. You know so you can run win32 apps on your phone with continuum....

MS isn't looking to keep the branch of ARM and x86, they want to get rid of ARM and position themselves with x86, thus completing the whole picture. Universal apps help this along because you have support for the old 32bit ARM chips, focusing on the new aarch64 is a wasted effort when x86 SoC chips can and should outperform them in performance and battery... that all depends on Intel at this point I suspect...

This is all speculation and personal opinion.

 

[a5cent]

The answer is unfortunately "no". Visual Studio doesn't (yet?) include compilers that target ARMv8.

On the other hand, we've been through this in the PC space before, and at no point did an updated ISA alone ever result in general performance gains >= 20%. While such gains (and more) were measurable under very specific circumstances (video encoding with QuickSync is one example), they were never general gains. For the average word/mail/office user, which requires little more than bread & butter integer performance, those ISA additions came and went largely unnoticed. That's how most of this will play out for smartphones too. That's why I'm highly sceptical that >=20% is a realistic percentage, at least not when measured under circumstances that mimic real life smartphone usage (not synthetic benchmarks).

I've searched, but so far I haven't found anyone that benchmarked the ARMv7 and ARMv8 variants of a single app on the A57. Comparisons are always drawn to older A53 or A15 CPUs which is completely useless for this purpose. Can you help out?

Don't get me wrong. I'm not excusing MS here. In contrast to the whole 64bit debate which is a complete joke, supporting ARMv8 is important and IMHO should already be part of Visual Studio. It is a big deal, I'm just sceptical it's the kind of deal-breaker big deal that a general performance improvement of >=20% would represent.

Sources (other than Qualcomm marketing material) very much appreciated...

@mortici
I disagree with your take on ARM. Just look at how MS is evolving Visual Studio into a cross platform development environment for Android and iOS which also has direct support for cross platform development tools like Unity and Xamarin. Even MS' own UWP bridges (Astoria / Islandwood) depend on the availability of ARM compilers. As long as MS intends to play in the smartphone space, they can't afford to ignore ARM compiler technology. It's not going away or being phased out.

 

[Cruncher04]

Regarding aarch32 vs aarch64 on Cortex A57 there are some slides from ARM:

In addition you can look-up Geekbench scores from Galaxy Note 4 (Cortex A57 32 bit) and Galaxy S6 (Cortex A57 64 bit)

On the architecture side, the aarch64 ISA offers (among others) the following advantages:
- 31 instead of 14 GP registers available
- barriers with release and acquire semantics
- integer divide
- NEON/VFP embedded into ISA instead of using co-pro interface with separate status flags
- 64-bit AAPCS enables more efficient procedure calls (e.g. 8 parameter/return + 8 scratch)
- conditional select instead of only conditional move

focusing on the new aarch64 is a wasted effort when x86 SoC chips can and should outperform them in performance and battery... that all depends on Intel at this point I suspect...

Latest ARM designs outperforming Airmont(Atom) by a very healthy margin up to the point where with Apple A9/A9x even Skylake is challenged. Atoms are moving fast to mid range/low end as we speak. If Microsoft making their bets on x86 only, they will be left behind quickly.

 

[mortici]

The answer is unfortunately "no". Visual Studio doesn't (yet?) include compilers that target ARMv8.

On the other hand, we've been through this in the PC space before, and at no point did an updated ISA alone ever result in general performance gains >= 20%. While such gains (and more) were measurable under very specific circumstances (video encoding with QuickSync is one example), they were never general gains. For the average word/mail/office user, which requires little more than bread & butter integer performance, those ISA additions came and went largely unnoticed. That's how most of this will play out for smartphones too. That's why I'm highly sceptical that >=20% is a realistic percentage, at least not when measured under circumstances that mimic real life smartphone usage (not synthetic benchmarks).

I've searched, but so far I haven't found anyone that benchmarked the ARMv7 and ARMv8 variants of a single app on the A57. Comparisons are always drawn to older A53 or A15 CPUs which is completely useless for this purpose. Can you help out?

Don't get me wrong. I'm not excusing MS here. In contrast to the whole 64bit debate which is a complete joke, supporting ARMv8 is important and IMHO should already be part of Visual Studio. It is a big deal, I'm just sceptical it's the kind of deal-breaker big deal that a general performance improvement of >=20% would represent.

Sources (other than Qualcomm marketing material) very much appreciated...

@mortici
I disagree with your take on ARM. Just look at how MS is evolving Visual Studio into a cross platform development environment for Android and iOS which also has direct support for cross platform development tools like Unity and Xamarin. Even MS' own UWP bridges (Astoria / Islandwood) depend on the availability of ARM compilers. As long as MS intends to play in the smartphone space, they can't afford to ignore ARM compiler technology. It's not going away or being phased out.

I agree with you, my take on the bridges is the fact that they are absolutely needed if you wish to bridge the gaps between architecture and software. There has to be a means for the apps to be developed for legacy and future devices from a single point. Hence the bridges were created to allow cross platform universal development. Point being that if you are developing an ARM variant, especially in Visual Studio, you can simply do an x86 variant at the same time. ARM was/is necessary due to power and form factor restrictions, with new SoC x86 chips on the way that compete equally if not better in this realm the need might be reduced if not eliminated.

Only time will tell, but this whole thing hangs on the developer adoption. There is incentive now, because those who only developed Win32 apps, can now cross into the mobile space and vice versa, with the tools the MS I providing. Hence why I speculate that MS is looking into the future of better than ARM, x86 SoC chips and officially being able to say Windows on any size device. Addtionally this helps devs too, because you are developing for one architecture type, not ARMv7,ARMv8,64/32, SPARC, etc. just x86/amd64 like its been done in the past.

The question is then whether x86 is the best architecture for all computing...

Again this is all speculation and opinion, but the prospect of a phone sized x86 device with the power of say a Core i5 Skylake chip (core M maybe?) that can be docked and scales up to a full desktop/tablet OS (depending on peripherials) would be short of amazing. My PC travels with me, in my pocket.

The goal here is to bring the legacy stuff along with this is the hard part. You need the devs that only cerated apps for ARM to convert to universal apps and now target more than just a cellphone but ALL types of devices, granted should their app actually have value on said devices, but either way you could also set them up to only run on mobile screens and no scaling for desktop or tablet mode.

Basically re-code, how you code

 

[mortici]

Latest ARM designs outperforming Airmont(Atom) by a very healthy margin up to the point where with Apple A9/A9x even Skylake is challenged. Atoms are moving fast to mid range/low end as we speak. If Microsoft making their bets on x86 only, they will be left behind quickly.

You are correct, that's currently though. The atom chips have been around in 64bit flavor since 2012/2013 but due to power religated to tablets. The new x7 lines coming up win the 14u chip dies are a different animal based on cherry trail. Sadly they will need separate LTE chips as opposed to the x3... Either way they claim to outperform the Qualcomm chips by up to 50%, the question is at what cost to the battery.

Intel is in a position to shake things up at this point. If they can pack a better punch than the ARM chips at equal or better yet, better battery life, while providing the ability to run a "desktop" OS then things will get interesting in my opinion..

Again speculation and opinion on my part, but I think the next two years will be interesting.

 

[Cruncher04]

The new x7 lines coming up win the 14u chip dies are a different animal based on cherry trail. Sadly they will need separate LTE chips as opposed to the x3... Either way they claim to outperform the Qualcomm chips by up to 50%, the question is at what cost to the battery.

Sorry to burst your bubble but i was talking about the Airmont u-architecture, which you find in Cherrytrail Atom x7. Look up some performance comparisons on the web. Take for example Atom X7 Z8700 you'll find in the Surface 3 and then compare to Cortex A57 you'll find in Galaxy S6. And if you want some more fun, compare with Apple A9 in iPhone 6S. We are talking 50%-100% faster within a phone power envelope vs. tablet.

 

[Cruncher04]

double post

 

[a5cent]

@Cruncher

I just really wish there was something better to go by than Qualcomm's marketing material, using the most synthetic of benchmarks no less, Geekbench. I saw that chart too, but I'm calling BS on the integer performance test under ARMv8 (I suspect ARMv8 NEON "shenanigans" that almost never translate into real world improvements).

Remove that and the differences are negligible.


The Note 4 uses a S805 which is not based on the A57, so comparing that to the Galaxy S6 in order to gauge the impact of ARMv8 wouldn't result in a valid comparison either.

I've never seen just recompilation targeting an updated ISA alone lead to general improvements in the >=20% range. Even today, we're still running a lot of 32bit PC software compiled for vanilla x86 because it's not had a notable impact.

Sure, that could be different here, but until there is something comparing how each ISA handles real world computational loads, I'll remain doubtful it's that important. To a degree also because I just can't see MS outright ignoring ARMv8, as they currently are, if there truly was that much to gain from it.

I'll keep looking for benchmarks that are less synthetic, but until we've got more reliable tests proving otherwise, I think it's safer to assume this capability is not a critical omission. And yes, I will keep looking...

 

[Cruncher04]

I just really wish there was something better to go by than Qualcomm's marketing material, using the most synthetic of benchmarks no less, Geekbench. I saw that chart too, but I'm calling BS on the integer performance test under ARMv8 (I suspect ARMv8 NEON "shenanigans" that almost never translate into real world improvements).

The slides i linked are from ARM not from Qualcomm. The main message of the slide is, that Cortex A57 is 45% faster than A15 and not so much the fact, that you will not gain the speed-up with 32 bit code (which is rather a restriction and not something you would brag about).
Geekbench3 is not compiled for NEON (nor SSE/AVX for that matter). The nice thing about synthetic benchmarks is, that they are not reliant on the OS or other libraries. Side effects from updated OS/libraries are therefore removed.
In addition there is a Cortex A57 version of the Note 4 (version N910C with Exynos 5433). Note 4 was never updated to 64 bit Android. So there you have a comparison right at hand.

I've never seen just recompilation targeting an updated ISA alone lead to general improvements in the >=20% range. Even today, we're still running a lot of 32bit PC software compiled for vanilla x86 because it's not had a notable impact.

Most of the improvements of the ARM v8 ISA directly aim at performance gains. Take the register set as example. You just don't increase your register set from 16 to 32 if you would not expect significant gains from that. Its not just the gates of the registers and multiplexer you would waste, but you are loosing 3 bits of instruction encoding space, which is very precious when you want to stay at fixed length 32 bit instructions. Its not only large functions, which gain from increased register set but also small leaf functions in the call graph, because they now have 8 scratch registers available.

To a degree also because I just can't see MS outright ignoring ARMv8, as they currently are, if there truly was that much to gain from it.

This concern was precisely why i was opening this thread. Could be as example that they have so much pressure finishing Windows Mobile, that there was just no room for anything on top, like moving the whole toolchain and OS to 64 bit ARM despite the known gains.