Qualcomm and Microsoft showcased some Snapdragon 835 based Windows 10 “Mobile PCs” at Computex 2017 last June, and while the press was allowed film the demo, the device could only be operated by a Qualcomm employee.
But both companies and their partners have made progress, and at the Snapdragon Technology Summit, Qualcomm announced “Always Connected PCs” which will run Windows 10, be always on and always connected at Gigabit LTE speeds, and support all-day battery life while keeping thin and fanless designs. all while incorporating Windows 10. HP and ASUS unveiled their very own “Always Connected PCs”, respectively Envy X2 and Novago TP370. What I used to call laptop or in this case 2-in-1 hybrid (laptop) is now apparently called “Always Connected PC”, but in any case let’s have a closer look at both devices.
HP Envy x2 (2017)
- SoC – Qualcomm Snapdragon 835 Mobile Processor @ 2.6GHz with Adreno 540 GPU @ 710MHz
- System memory – Up to 8GB RAM
- Storage – Up to 256GB UFS 2.0 storage, micro SD card reader
- Display – 12.3″ WUXGA+ (1920 x 1280) touch display
- Audio – 1x combo audio jack; dual speaker; microphone array with Cortana voice-recognition support
- Backlit Keyboard and touchpad
- WiFi – 802.11a/b/g/n, 802.11ac
- Qualcomm Snapdragon X16 modem (Gigabit LTE with DL: 1Gbps, UL: 150Mbps; 4×4 MIMO); 1x SIM card reader
- Camera – 13MP rear camera and 5MP front camera
- USB – 1x USB-C port
- Misc – Volume buttons
- Battery – Good for up to 20 hours of local video playback, over 700 hours of connected standby
- Dimensions – 6.9 mm thick
- Weight – 1.21 kg
The device will run Windows 10 S, but with option to upgrade to Windows 10 Pro (fee may apply). HP Digital Pen will also be included. The product page has some more information, including a “buy” button to get notified of the launch. Does it really last one full day? According to Qualcomm yes, as the company explains how you could spend a full day using the device on a charge.
ASUS Novago TP370
- SoC – Qualcomm Snapdragon 835 Mobile Processor @ 2.6GHz with Adreno 540 GPU @ 710MHz
- System memory – 4GB / 6GB / 8GB 1866MHz LPDDR4x (soldered)
- Storage – 64GB / 128GB / 256GB UFS 2.0 storage, micro SD card slot up to 256 GB
- Display – 13.3” LED-backlit Full HD (1920x 1080) display
- Video Output – HDMI
- Audio – 1x audio jack; dual speaker; smart amplifier; microphone array with Cortana voice-recognition support
- Backlit keyboard and PTP touchpad
- WiFi – 802.11a/b/g/n, 802.11ac (2×2 MIMO)
- Qualcomm Snapdragon X16 modem (Gigabit LTE with DL: 1Gbps, UL: 150Mbps; 4×4 MIMO); 1x Combo Nano SIM (tray with needle)
- Camera – 1280×720 HD camera
- USB – 2x USB 3.1 Gen 1 Type-A ports
- Sensors – Fingerprint sensor
- Battery – 52 Wh lithium-polymer battery good for up to 22 hours battery life, over 30 days of modern standby
- Dimensions – 31.6 x 22.1 x 1.49 cm
- Weight – 1.39 kg
2-in-1 laptop always connected PC will run Windows 10 S by default, but a recommended free upgrade to Windows 10 Pro will be offered. More details may be found on the product page. Windows 10 S only allows the installation of apps in Windows Store, and Microsoft own Edge browser (no Firefox, no Chrome), so most people will likely upgrade to Windows 10 Pro, especially if it is free, and this is probably a condition imposed by Microsoft.
ASUS NovaGo is expected to be available early next year, while the HP Envy x2 is planned for Spring 2018. I could not find pricing on the official page, but Liliputing reports an “entry-level model with 4GB of RAM and 64GB of storage should sell for about $599, while an 8GB/256GB model will run $799”.
You’ll find various hands-on video for the Envy x2 (2017) model online, including the one from Engadget embedded below.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
30 Replies to “Meet the First Windows 10 Arm “Always Connected PCs” – HP Envy x2 (2017) and ASUS NovaGo TP370”
I actually thought the Snapdragon laptops would be more affordable! 600 dollars base unit??
Will Armbian support it?
It should be priced similarly with Chromebooks.
Waaaay too expensive! I’ll pass.
As people said these are way too expensive. You can get some good Chinese Intel Apollo Lake powered laptops for much less. Through in a USB modem and you have pretty much the same thing. OK so maybe battery life is better with these ones but still … Too much money
This post misses one of the interesting “features” in this “Windows on Arm”: the ability to run almost all the Windows x86 (32bits) software out there.
This is important because apart from the Windows OS and kernel, there is almost zero windows native arm apps ready to run on it.
The emulator it’s basically a port to ARM of the wonderful 1996’s FX!32, but without the performance, because back then Alpha hardware was significantly faster than x86, while now ARM running native code is significantly slower than current model x86, so under emulation this Arm laptop’s will be far behind.
The extra overhead of the emulation won’t help battery life either, and will increase memory usage. Again not problems Alpha systems really had to content with.
ARM laptops running Linux would do 99% of what x86 laptops running Linux do, while providing improved power efficiently, ARM laptops running windows will be significantly worse than x86 laptops.
People will buy ARM laptops on the promise of long battery life and compatibility with windows software, but will find the software runs slowly and the battery life tanks if you actually try to do anything…
Word will spread, and there’s a chance ARM laptops will be seen as a shit product, unless M$ has a bold strategy behind all this…
This is a whole other device… This is a top class ARM chip with much more performance and power consumption than Apollo Lake. The fact that the build quality seems much superior for the $600, I can’t see why anyone is complaining. With native ARM software, this looks to be faster than any Core M on the market (Core Ms throttle with anything else than light, single-threaded, CPU-only loads).
Cheaper ARM laptops with a lot crappier drivers should soon follow.
Only thing I find disappointing in the HP is the single USB-C port.
Always connected… Unless currently downloading or applying an update.
If it’s at Core M levels of performance then yes, this is indeed something else. That’s a big if though and we’ll see how much native ARM software there will be.
Is Office available as native ARM ? Because if not even MS software is native ARM then it will take some time for sure.
I think software vendors are more ready to recompile their software now because of all the changes in the move from the old days of 32 bit Windows XP and 2000, to 64 bit Windows 10 etc, with new versions of dotnet/C# and Windows Metro/Modern etc.
I suspect though that just as the old Win RT tablets and laptops were tightly locked down, these will be too. So unless they put on an equivalent Linux runtime stuff that x86 Windows 10 has for running Linux, only an Arm version, then you’ll be entirely locked into Windows. In other words like a Microsoft version of a Chromebook, only it’ll be Windows + Office 365 instead.
They are still 2 in 1s, the Always Connected part is due to the LTE support built in and the high battery life
Funny comments as usual. If you (or the others speculating about ‘low performance’) are able to click on the link in 1st sentence of 1st paragraph then in the comments section you get a link where you can learn how smart/fast Microsoft’s binary translation attempt is (of course it’s not a boring emulation).
The only problem with these devices above are a) they run Windows (who wants this?) and b) they’re always connected so these things just like smartphones are utilities of mass surveillance (your device being fully owned by the LTE chipset connected to whoever out there controls the telco provider)
AMD just announced their “Always Connected PCs” solution with Qualcomm’s LTE modem. I would pick those than these all day…
To which Intel/AMD x86 processors (multicore-versions?) can the Snapdr. 835 be compared to?
I can’t comment on emulation, but since this is shipping with system libraries compiled for ARM, performance of system library calls shouldn’t be too bad.
Also, as a former MFC and current Windows Store App developer, unless you are using large amounts of external libraries, most heavy lifting is done by system libraries: encode/decode, imaging(WIC), drawing(DirectX, DirectWrite), networking, etc.
But again, I’d feel lot more confident if they actually release some numbers!
Universal Windows Platform (UWP) apps are running ‘native’ anyway (since also compiled for ARM64) and everything else (especially why performance won’t suck and why ‘some numbers’ won’t tell anything) has been explained long time ago:
https://channel9.msdn.com/Events/Build/2017/P4171 (when only interested in the x86 ’emulation’ that is none then skip first 6 mins).
Despite insistence of some “experts” here, performance and battery will hit a penalty when running x86 software, yes.
As I explained in my previous comment, the emulation is nothing more than a port of the great FX!32 (https://en.wikipedia.org/wiki/FX!32) code to Arm.
Quoting: “FX!32 achieved speeds for Win32 x86 applications that ran 40-50% as fast as native x86 code, with a 70% speed projected as likely with improved optimization”
At that time, late 90’s, this performance loss sometimes was not even noticeable, because the DEC Alpha workstations where so much fast compared to Intel those days, that they absorb the delta.
(everyone that has had the opportunity to play with DIGITAL hardware back then, will know what I mean)
But, now you can not say the same, because currently top Arm is slower than top Intel processors, so the overhead of the emulator will be noticeable, of course.
On the other hand, of course the Windows kernel and userland (system library’s, dll’s) are all Arm native, so no problems there, and it is estimated that a large chunk of software out there can be easily recompiled to run natively., it just needs some traction.
What this post fails to explain and explore is that this laptops are not for general consumption, but rather focused on specific cases, where is more important to be able to run x86 software coupled with more efficient hardware, than performance.
(hey, just noticed that I’m just typing this on a “old” DEC keyboard built at 1989, and it still feels like new!)
You can already compare numbers if you prefer irrelevant and more or less horribly stupid ‘passive benchmarking’ attempts. Here Geekbench 3 numbers made with Win 10 x86 on Snapdragon 835. And here Geekbench numbers running an Android natively on the same SoC: https://browser.geekbench.com/geekbench3/search?utf8=✓&q=MSM8998
Given that this can be considered already worst case possible (since not using system libraries but using own code for performance relevant stuff) the results are pretty impressive especially for the background that real software will let almost all performance relevant stuff natively and not as x86 code. But while we know that Microsoft is not using an inefficient CPU emulation but dynamic binary translation we would need to know how often Geekbench was already running before (since with subsequent runs further optimizations might start to kick in). As usual: passive benchmarking more or less only produces numbers without meaning, applies especially to those more popular benchmarks out there.
Already curious how people interpret these useless numbers now 🙂
Those geekbench scores are just a curiosity. For the majority of the usecases of those notebooks, native code will be executed, at least in the performance-critical paths. Why? Because the usecases of these machines center around a couple of high-profile products (office, et al) and web, either of which will be native, or ‘as native as they run on x86-64’ anyway.
And this not even on the CPU cores but inside more efficient engines (GPU, VPU and whatever special stuff is added). Looking at Geekbench numbers makes only some sense when checking individual results since then the benchmark starts to tell at least something. Eg. comparing the numbers for the OnePlus A5000 which ‘performs’ somewhat different depending on using a Geekbench version compiled for ARMv7 or ARMv8 (though they talk about 32-bit and 64-bit instead):
So the Android Geekbench 3 version obviously has been built with different compiler switches not making use of ARMv8 crypto extensions even if available when choosing the ‘wrong’ Geekbench binary. And the Windows version uses Microsoft system libraries that end up with AES-NI acceleration on Intel and ARMv8 crypto stuff on ARM. Therefore depending on the CPU your Windows apps are running on you can switch between NSA and GCHQ crypto backdoors. Nice! 🙂
In a perfect world yes, but often no. Some of our products rely on external precompiled libraries only in x86/64. Since Windows ARM devices were non-existent for quite some time, it wasn’t worth the hassle of compiling for ARM platform.
TL;DR: there are many UWP apps that doesn’t support ARM natively.
From way I see it it’s way above Atom and slightly lower than core M 5Y10c. Very impressive indeed given that it’s using an emulation.
As you might have noticed, over the last few years CPU frequency is very hard to know before you buy a device, and GPU, coprocessors and various other devices are shown as what makes a CPU’s value. Why ? Just because most of today’s applications are offloaded to the system and such components. In the end the only applications which will suffer from emulation are those showing a high %user ratio. Ie if you run a compiler it *will* be measurably slower than a native version. If you run a game, a video player, a spreadsheet or any such thing, you won’t notice because most of the CPU cycles are spent either in the idle loop, or in the system.
So that will have limited to no impact for most applications. And every time it has no impact, battery life will not be affected either.
Today. But in case this is an issue (no one knowns now) then this can change easily if I understood the UWP/store concept. The developer ticks the ‘ARM’ checkbox, might need to adjust some library code and an update will ‘fix’ it. Whether providing a fully native app will show better performance and/or longer battery life or not is subject of real benchmarking later (not that insanely stupid Geekbench BS so many people love to look at).
While I’ve almost zero experiences with Windows on Desktop/Mobile at least on macOS where we went through this a decade ago (PowerPC code being handled by Transitive’s dynamic binary translation then running on x86/x64) it was a smooth experience with users not able to notice that they ran code for the wrong CPU on their devices. And over the years software updates all the time improved battery life and performance (Apple even used this in their marketing telling people this year’s MacBook Air would show one hour longer battery life while in reality it was the same hardware as the year before but this time running newest macOS which made use of Intel’s QuickSync now handing video decoding over to the CPU’s video engine).
I would expect similar things happening here too (for example Microsoft improving process scheduling to cope better with the big.LITTLE architecture and further moving stuff away from the CPU cores). At least Microsoft has internal knowledge in this area even with performance criticial code paths (their 2nd generation Xbox was PowerPC based and had to deal with the successor’s x86 games)
Well, I consider Geekbench numbers BS, especially the ‘Multi-Core’ score. Why? Since Geekbench only tests CPU cores and this in a way that is not that representative for what’s happening in reality. Desktop/mobile systems need as much stuff as possible offloaded to special engines (GPU, VPU, crypto, whatever) and then single-threaded performance is important and more or less also IO (easy to check: replace your SSD with a HDD and throw your PC out of the Window within minutes).
When looking at Single-Core Geekbench Integer scores an Android phone with Snapdragon 835 clocked at 1900MHz scores 2300 while a Core M 5Y10c at 1000 MHz scores 2000. Since we know that the Snapdragon 835 used in these Windows devices is slightly modified and able to clock up to 2600 MHz the single thread performance is already a lot better than on Core M devices when running native code on the CPU cores (and more or less on par when runnning translated binaries). And the SoC has four of these Kryo280/Cortex-A73 cores so there’s plenty of processing power.
And then there’s IO performance. Both devices above utilize UFS 2.0 storage so this is not boring and slow eMMC but comparable to entry level consumer SSDs which helps a lot with snappiness and battery life (minimize storage access and send both storage and controllers to low-power states more often).
To me the whole thing looks pretty well but unfortunately I’m neither interested in running Windows nor ‘always connected’ devices. I’m already curious how certain companies will deal with this ‘threat’ in the future…
One nice advantage: At least we’ll start seeing laptops available with top of the line snapdragon SoCs available to the general public. Perhaps even some motherboards/SBCs in the future.
Now, even better, but only possible in a parallel universe, would be if Microsoft did the same with an Apple ARM SoC, since those are still ahead of the curve.
This is a complete crap. It’s hilarious to need this powerful ARM SoC to run emulated Windows because M$ is such an idiotic company.
It’s like the world upside down, isn’t supposed to create software for the hardware and not the opposite? here we depict a hardware crying and wanting to use the software so mad so it gets adapted to it, a complete retard thing imho.
I can’t believe Qualcomm is one of the strongest companies regarding ARM if they’re doing such things…
Some previewers were able to get more hands time on and pry some benchmarks here https://www.ultrabookreview.com/19015-asus-novago-impressions/. Mostly Intel Atom level performance and sometimes worse. Under native Edge browser, not that snappy or fast. Some hiccups (crashes) also.
Windows on ARM has a large amount of native ARM code in recompiled libraries and the core OS, so a significant amount of the code execution will be at native speeds. Only the application specific sections of code would need to be translated.