www. O S N E W S .com
News Features Interviews
BlogContact Editorials
.
HP, Asus announce first Windows 10 ARM PCs
By Thom Holwerda on 2017-12-05 20:19:56

HP and Asus have announced the first Windows 10 PCs running on ARM - Snapdragon 835 - and they're boasting about instant-on, 22 hour battery life, and gigabit LTE. These machines run full Windows 10 - so not some crippled Windows RT nonsense - and support 32bit x86 applications. Microsoft hasn't unveiled a whole lot just yet about their x86-on-ARM emulation, but Ars did compile some information:

The emulator runs in a just-in-time basis, converting blocks of x86 code to equivalent blocks of ARM code. This conversion is cached both in memory (so each given part of a program only has to be translated once per run) and on disk (so subsequent uses of the program should be faster, as they can skip the translation). Moreover, system libraries - the various DLLs that applications load to make use of operating system feature - are all native ARM code, including the libraries loaded by x86 programs. Calling them "Compiled Hybrid Portable Executables" (or "chippie" for short), these libraries are ARM native code, compiled in such a way as to let them respond to x86 function calls.

While processor-intensive applications are liable to suffer a significant performance hit from this emulation - Photoshop will work in the emulator, but it won't be very fast - applications that spend a substantial amount of time waiting around for the user - such as Word - should perform with adequate performance. As one might expect, this emulation isn't available in the kernel, so x86 device drivers won't work on these systems. It's also exclusively 32-bit; software that's available only in a 64-bit x86 version won't be compatible.

I'm very curious about the eventual performance figures for this emulation, since the idea of running my garbage Win32 translation management software on a fast, energy-efficient laptop and external monitor seem quite appealing to me.

 Email a friend - Printer friendly - Related stories
.
Post a new comment
Read Comments: 1-10 -- 11-20 -- 21-30 -- 31-40 -- 41-50 -- 51-59
.
Not the first time, if I understand it right
By gus3 on 2017-12-06 17:56:39
Saving the translated instructions along with the original text (albeit in a separate section) is nothing new, right? Wasn't this the philosophy of the AS/400, with its Technology-Independent Machine Interface?
Permalink - Score: 3
.
RE: This is awesome
By CaptainN- on 2017-12-06 18:05:59
That'd be nice, but this is still a crippled version of Windows - unable to run 64-bit x86 code.
Permalink - Score: 1
.
RE[2]: Garbage in, garbage out.
By Brendan on 2017-12-06 18:14:56
Hi,

> In practice I've benchmarked QEMU's software emulation to be about 15-20% as fast as on bare metal. Hardware VT acceleration was able to achieve 100% in the same test. In theory poorly optimized code on x86 could end up being faster if the emulator has a sufficiently powerful code optimizer. We may get there with advanced AI techniques, but it's not possible now.

Qemu's software emulation mostly stitches together snippets (functions created by a C compiler); which is great for portability but very bad for performance. A JIT designed for performance (e.g. something that converts machine code directly, which is able to map most "guest registers" to "host registers") can achieve about 90% of native speed.

I'd expect Microsoft's JIT is designed for performance, which means that the performance of Qemu is a bad/misleading indicator of the performance you'd expect from Microsoft's JIT.

More specifically; I'd expect that the performance of these ARM systems will be bad (compared to modern 80x86) because the performance of the ARM CPU itself is bad, even when running native ARM code with no JIT at all.

- Brendan
Permalink - Score: 3
.
RE[5]: Is it crippled?
By viton on 2017-12-06 18:19:39
can't think of a reason why a 64bit ARM processor would not handle the memory requirements of 64bit x86 processes.

Isolation. You need to keep JIT cache and dynamic recompiler structures inaccessible for emulated code.
Memory protection of JIT cache? Too slow, IMHO.

which ought to be compatible as long as the barriers are correct

x86 do not need barriers because of it's memory model. Lockless code carelessly written for x86 and not tested on ARM, can fail.
Permalink - Score: 4
.
RE[2]: Just like Apple's Rosetta
By Alfman on 2017-12-06 18:26:47
tidux,

> That's my concern as well. If these come with unlocked bootloaders, I'll absolutely buy one and put Linux on it.


darknexus,

> It did indeed do a good job, but the performance impact was definitely obvious even so. I'm curious to get my hands on one of these, though I don't really like Windows 10 enough to want to buy one.

Haha, ironically I'm not sure there's that much demand for ARM among typical windows users. But there is a pent up demand for ARM computers on the linux side though. I'd be ready to buy one and load up a linux distro on there. Outside of embedded devices x86 has dominated computers for my entire life, I'd like to see some variety already... Just please don't cripple secure boot to remove my choice of software!
Permalink - Score: 1
.
RE[6]: Is it crippled?
By Alfman on 2017-12-06 18:33:33
viton,

> can't think of a reason why a 64bit ARM processor would not handle the memory requirements of 64bit x86 processes.

Isolation. You need to keep JIT cache and dynamic recompiler structures inaccessible for emulated code.
Memory protection of JIT cache? Too slow, IMHO.


I don't follow, specifically what makes you assert that the recompiler must be worse with 64bit code than 32bit code?


> which ought to be compatible as long as the barriers are correct

x86 do not need barriers because of it's memory model. Lockless code carelessly written for x86 and not tested on ARM, can fail.


Not exactly, x86 guaranties the order of operations, but developers must use barriers even on x86, otherwise the compiler would not be able to generate proper SMP code.

Edit: Some x86 developers may neglect this, but technically it opens up race conditions even on x86. It wouldn't surprise me one bit if alot of multithreaded x86 code has these kinds of race conditions in it today.

Edited 2017-12-06 18:41 UTC
Permalink - Score: 2
.
RE[3]: Garbage in, garbage out.
By Alfman on 2017-12-06 19:09:42
Brendan,

> Qemu's software emulation mostly stitches together snippets (functions created by a C compiler); which is great for portability but very bad for performance. A JIT designed for performance (e.g. something that converts machine code directly, which is able to map most "guest registers" to "host registers") can achieve about 90% of native speed.

I'd expect Microsoft's JIT is designed for performance, which means that the performance of Qemu is a bad/misleading indicator of the performance you'd expect from Microsoft's JIT.


I don't use qemu as an example because of it's performance, but rather because of it's cross-architecture support. Do you know of other cross-architecture emulators with 90% speed efficiency? I'd like to read about it if you've got a source.


> More specifically; I'd expect that the performance of these ARM systems will be bad (compared to modern 80x86) because the performance of the ARM CPU itself is bad, even when running native ARM code with no JIT at all.

Well sure, they don't match the performance of high end x86 PCs, but these laptops are meant to compete with intel's atom and celeron processors being used in consumer laptops today. I'm definitely curious how these new ARM laptops will do in benchmarks running both x68 and native code. Hopefully Thom will post an article about it :)
Permalink - Score: 3
.
RE[3]: Just like Apple's Rosetta
By darknexus on 2017-12-06 20:07:29
Yeah, while the demand for Linux computers isn't really that high in the consumer space, demand for Windows on ARM is likely even less prevalent. It's cool from a technological standpoint, but I can just see the holiday shopper:
Shopper: Hey, this is cool. Does it really get a full day on battery like my iPad can?
Sales: Sure does.
Shopper: And it'll run Word and Outlook and all that? It will really let me edit my pictures?
Sales: Sure will.
*** Shopper, at home: Damn, this thing is slow. I can't get anything done. My phone runs faster than this! I'm returning this stupid thing.

They might actually sell more of these if they sell them unlocked, since the likely market for these is going to end up being enthusiasts at least for the time being. Of course, I doubt Microsoft is going to approach this logically. I'm betting they'll try the Windows RT approach again, and will probably doom the idea as a result. In fact, the cynic in me sees a way they could use the poor performance as a way of removing the ability to side-load applications altogether, and claim they were right all along to limit Windows RT the way they did.
Permalink - Score: 0
.
RE[3]: Comment by smashIt
By CaptainN- on 2017-12-06 20:37:46
It isn't enough though to simply cache the translation - the quality of the translation matters, and that's going to be challenging to get right in any high performing way.

As a matter of interesting history - back when Apple banned Flash from iOS, Adobe create a Flash bytecode to ARM compiler using LLVM. The whole pipeline is - Actionscript 3.0 (which is really Ecmascript/JavaScript 4) -> ABC (Flash's version of webassembly) -> LLVM -> Native code. (After Flash is killed off in 2020, AIR, which is just Flash packaged up as apps will live on - take that Steve Jobs!)

It does produce very fast code (mostly due to the strength of LLVM), but it's still not as fast as even modern JavaScript engines like V8, Nitro or SpiderMonkey, which are incredibly fast these days (almost C++ fast). Part of that is the programming model - dynamic languages like AS/JS require a lot of safety checks and translation at runtime, and to do AOT the way LLVM must do with ABC, it has to bake all that into the runtime. This carries a lot of overhead. The modern JS engines are able to optimize a lot of that out at runtime, using dozens of really neat tricks.

Edited 2017-12-06 20:39 UTC
Permalink - Score: 0
.
RE[2]: Is it crippled?
By dionicio on 2017-12-06 20:56:09
Once Inside this market segment, MS will be able to see what LEGACY We are trying to bring into mobile. What's worth recompiling, rewriting for ARM...
Permalink - Score: 2

Read Comments 1-10 -- 11-20 -- 21-30 -- 31-40 -- 41-50 -- 51-59

Post a new comment
Username

Password

Title

Your comment

If you do not have an account, please use a desktop browser to create one.
LEAVE SPACES around URLs to autoparse. No more than 8,000 characters are allowed. The only HTML/UBB tags allowed are bold & italics.
Submission of a comment on OSNews implies that you have acknowledged and fully agreed with THESE TERMS.
.
News Features Interviews
BlogContact Editorials
.
WAP site - RSS feed
© OSNews LLC 1997-2007. All Rights Reserved.
The readers' comments are owned and a responsibility of whoever posted them.
Prefer the desktop version of OSNews?