back to article Windows on ARM: It's nearly here (again)

It's a milestone in Windows history: the first benchmarks for a new generation of ARM-powered Windows hardware have been sighted in the wild. Geekbench has recorded an instance of a box running Windows 10 on the "Qualcomm CLS" platform. This entry describes an octocore processor, running 8GB of memory, and cites a Qualcomm …

The questions is why?

You have the following choices.

Run something like a cheap Chromebook running efficiently on native ARM,

a wintel machine running native x86 apps relatively efficiently

or a arm box running windows native on a x86 emulator slowly

The last one seems to be the worst of both worlds

23
5
Silver badge

It's not that bad for ancient exes where all it is is a GUI with fields and an event loop and does some magic calculation or talk to a database when you hit 'Go'. Somewhat grandly called enterprise software.

20
0
Silver badge

Option 3. Long battery life running thinks at an OK speed.

Not everyone wants fastest.

24
0

Screen power ....

Since 50-70% of the device power goes to the screen then why would anyone bother having the most efficient SOC at any cost?

And there's no evidence that an ARM SOC is any more efficient than an X86 SOC doing the same work. If there was then the world would be full of ARM servers.

4
17
Bronze badge

Option 3. Long battery life running thinks at an OK speed.

Well, that's fine, but Intel have come on leaps and bounds on power consumption these past few years (spurred / scared on, I expect by ARM). Surely a small, native implementation of x86 (looking at you, Atom) could be created more efficiently than ARM running an emulator (albeit on in hardware).

Or course, my understanding it that the current x86/x64 chips decode the instructions into smaller chunks, and that the native silicon actually runs a simplified instruction set. I could well be wrong on that (CPU design is not my thing), but that would suggest to me that even Xeons are running "emulated" x86.

And yes, that was a fair few brackets I used there - not even sorry. :P

10
2
Anonymous Coward

I would have a Chromebook (one that runs android like the R11) over pretty much anything else, even a windows PC.

Security foremost and only Chromebook offers that.

7
12
Def
Silver badge

...current x86/x64 chips decode the instructions into smaller chunks, and that the native silicon actually runs a simplified instruction set...

Yes, they essentially do. You wouldn't believe the things modern Intel processors go through to support the x86 instruction set.

13
0
Anonymous Coward

"Security foremost and only Chromebook offers that."

LOL, you must have missed all the numerous previous vulnerabilities patched in Chrome OS! Take a look at the CVE database...

7
7
Silver badge

@hammarbtyp: "The questions is why?"

The reason is that the Achilles heel of Windows when it comes to portability is that the only reason people buy Windows is to run proprietary x86 applications. Microsoft can port Windows, MS Office, MS SQL Server, Dot Net, and various other bits of software that they own to ARM, but each customer will always a handful of third party applications that haven't been ported and that they don't want to do without. Being able to run those poorly is better than not being able to run them at all.

It's a chicken and egg problem Third party developers won't support Windows on ARM until there's a market for it, but customers won't create a market for it until there's enough third party software to run on it.

There's work in porting software, since you have to fix the application bugs which have been there all along but haven't surfaced on x86 but will show up on ARM. Then you have to worry about performance tuning on a different architecture. Plus you have to set up the development, testing, and QA servers to support the new architecture and add it to your release pipeline. And you have to do all this while waiting for years for a significant market to materialise.

Linux distros have supported multiple architectures for years because they have the source code for the applications they distribute and can simply recompile them in most cases. Since portability has been a core feature of most "unix" style operating systems from the early days, most of these applications have had the porting bugs wrung out of them years ago. Debian has official support for AMD64, i386, ARM, MIPS, PPC, and S390x (IBM mainframe). They have unofficial support for others as well, including SPARC.

Microsoft is starting without any of these advantages. Their Itanic port died some years ago and the few third party software developers who bought into that will be shy of repeating that experience until they see a real market running Windows.

22
0
Silver badge

> or a arm box running windows native on a x86 emulator slowly

Note that the ARM x86 emulator will only run 32bit x86 and not AMDx86-64.

Some years ago Microsoft announced that there would be "no more 32bit versions of Windows". Of course they still do have 32bit versions, but many software companies switched entirely to 64bit only. Now, are they able and willing to revert to 32bit versions just to run on slow ARM emulation ?

9
0
Silver badge
Windows

Re: LOL

"...vulnerabilities patched in Chrome OS!"

There's the operative word, right there.

2
9
Anonymous Coward

a wintel machine running native x86 apps relatively efficiently

or a arm box running windows native on a x86 emulator slowly

Most low-end Windows PCs use Atom / Celeron / Pentium / AMD A-series CPUs, and their performance is similar to the Qualcomm ARM emulating x86. For example, my 2+ year old N2840 netbook is slower at both single and multicore Geekbench according to http://cpuboss.com/cpu/Intel-Celeron-N2840

So it looks like the low-end x86 market is under threat. I would include games consoles in that.

5
0
Anonymous Coward

Why?

Moore's law. Today it's a tad underpowered. Give it a couple of years and it will be exceptionally adequate.

Intel is big and lumbering so can't afford to make cheap low margin processors, so the choice is going to be between cheap but adequate or expensive and overpowered.

4
0
Anonymous Coward

No, I understand how Chromebook works and how it's architecture fundamentally changes how an OS works for the better. Fully signed read-only runtime that can't be modified, and can only be updated by a matching bootloader cert means no room for dodgy stuff to slip in.

2
3
Anonymous Coward

Re: LOL

"There's the operative word, right there"

But the problem is that the utterly vast number of them for such a cut down OS suggests that an attacker with resources could easily find more...

4
0
Anonymous Coward

"Fully signed read-only runtime that can't be modified, and can only be updated by a matching bootloader cert means no room for dodgy stuff to slip in."

So just like secure boot on Windows you mean?

6
2

Re: LOL

>>...vulnerabilities patched in Chrome OS!"

>There's the operative word, right there.

I'll venture to say that the operative word is "vulnerabilities".

5
0
Silver badge

except

Security foremost and privacy who gives a sh1t eh? Must be a millennial. Biggest problem with ChromeOS is having to always browse in Guest mode to even have a chance at privacy and even then have to make sure to disable all those helpful services Google enables by default in the browser to data mine you.

9
1
Silver badge

Somewhat grandly called enterprise software.

An x86 probably VisualBasic GUI running on an x86 emulator running on ARM, simulating an IBM3270 terminal session talking to a mainframe. over an ethernet connection pretending to be RS232

6
0
Bronze badge

Instruction set doesn’t really matter

You’re absolutely right. Intel hasn’t run x86 or x64 natively for years. Instead, they have an internal instruction set decoder/recompiler implemented mostly as ASIC and partially as microcode to make it so x86 and x64 is little more that a means of delivering a program. In fact, it’s similar to .NET CIL or Java IL. It’s actually much closer to LLVM IL.

There are some real benefits to this, first is that the recompiler can identify instructions that can be executed out of order as there are no register or cache read/write dependencies. Alternatively, it can automatically run instructions on parallel on separate parts of one or more ALUs which lack dependencies. As such, more advanced cores can process the same code in less clock cycles assuming there is no contentions.

Microsoft has spent 15 years moving most non-performance critical code away from x86 or anything else and over to .NET. They also have implemented the concept of fat-binaries like Apple did with PPC, ARM and x86/x64. In addition, they have been making LLVM and CLang part of Visual Studio. Windows probably has a dozen technologies that allow platform agnostic code to run on Windows now.

Emulating x86 is nice, but is really only necessary for older and unmaintained software. Most modern programs can carry across platforms with little more than a recompile and for power conscious devices GPU intensive code will be the same and CPU intensive code is frowned upon. So, you wouldn’t want to run x264 for example on a low power device ... and certainly not emulated. You’d favor either a video encoder core or a GPU encoder.

As for JIT and AOT dynamic recompilers, I can literally write a book on the topic, but there is absolutely no reason why two architectures as similar as x86 and ARM shouldn’t be able to run each other’s code at near native speed. In fact, it may be possible to make the code run faster if targeting the specific local platform. Also consider that we have run ARM binaries emulated on x86 for a long time, the performance is very respectable. I believe Microsoft is more focused on accuracy and limitation of patent infringement. Once they get it working, it is entirely possible that running x86 on x86 may be faster than running native because JITs are amazing technology in that they can do things like intelligently pipeline execution branches and realign execution order for the host processor.

Nice comment though :)

1
1
Bronze badge

Sorry... I vomited in my mouth as choking

On what planet is Chromebook secure?

A) runs Linux as a core

B) has very little security research targeting it, so most vulnerabilities are unknown.

C) Runs on fairly generic hardware produced by vendors who don’t customize to the local security hardware.

D) has a fairly small business user base and hasn’t properly been tossed to the wild as a hacker target.

I can go on... but that comment was as good as Blackberry claiming that 11 million lines of untested code for a total rewrite with an entirely new OS Core was secure.

3
3
Bronze badge

Re: LOL

“Known” is the key word.

0
1
Trollface

If there wasn't then the world would be full of Intel smartphones

There, fixed it.

1
1

It's because the emulation is part of Windows on Windows.

Back in the NT 3.x days they supported Win32 code via the Win32 API in the kernel and Win16 code via WOW. On x86 the code was both the Win32 code and the Win16 code in WOW could be run natively by setting the processor up in the right mode and WOW was mostly a thunking layer. On Risc platforms - PowerPC, Mips, Alpha - WOW had a x86 emulator which they licensed from Insignia called SoftPC. So back then if you had a Win32 app it needed to be compiled natively, which of course was unlikely for the Risc platforms.

It's the same now, though I believe the x86 emulator is in house. So 64 bit apps must be native and call 64 bit APIs. 32 bit apps go through WOW. On an x64 chip that's a thunking layer. On a Risc platform they use an emulator. Though from what they're saying they're going to JIT code in their in house x86 on ARM emulator.

Back in the NT 3.x days Dec actually did produce a clever emulator called FX!32 which emulated initially but later JITted the most frequently emulated Win32 x86 code ended up native Alpha. There is/was actually a hook in the Windows loader to allow this - it calls out if it is asked to load a Win32 PE file compiled for the wrong architecture. FX!32 used that to do it's 'emulate and profile first, then JIT the performance critical parts' magic.

However for Microsoft have decided to stick with the 'put the emulator only in the WOW path' for some reason and not do a FX!32 equivalent which would run x64 binaries on ARM64.

The performance they're reporting isn't very good compared to code running natively on a Snapdragon 835 aka MSM8998. The Geekbench 3 score is about half what it should be

http://browser.geekbench.com/geekbench3/search?dir=desc&q=MSM8998&sort=score

0
0
Anonymous Coward

Nope, not like secure boot at all. You don't appear to understand the huge difference between a hash (Windows) and a hash-tree (ChromeOS). Also the term Read-Only appears to be an alien concept too.

Literally on ChromeOS, you can't change a single byte on the entire OS without it failing a boot check, or runtime check.

2
2

turns out "native" code is portable

Its amazing how portable 20 year old C code is. Compared to languages that claim a common runtime as a goal like Java and .Net.

I just wrote a lot of new C code on a fairly new framework and to my surprise it compiled and ran with minimal tweaks on ARM (on an rpi).

2
1
Bronze badge

Re: Sorry... I vomited in my mouth as choking

Given that the entire internet thing on Linux, I'm not sure whether you're trolling.

the fact that Google pay huge bug bounties to people who uncover security bugs gives a clue how serious they are about security. They also have dedicated zero-day security researchers.

There's a huge base of users, e.g. educational establishments in the USA, who have fleets of these.

0
0
Anonymous Coward

"Nope, not like secure boot at all."

No, that is just like Secure Boot + Device Guard.

0
0

Why can’t Windows run ARM natively, and all none MS software run in an emulator?

Most legacy software was written to run on much slower hardware than what was written today, so the perform hit shouldn’t be that big a deal...

—-

I guess the point is Microsoft needs to recompile/rewrite everything they sell for ARM before anyone is going to take this seriously. Likely what would happen is a mixed environment of x86 (autocad etc.) + ARM (MS software only) which sounds like a pain in the ass to support.

7
0
Def
Silver badge

Windows and Universal Apps will be running natively.

It's only legacy applications that'll be sandboxed into thinking they're running on x86.

In a way, I imagine this is not much different to shoehorning 32-bit apps into 64-bit Windows.

11
0

And only the user parts of the code will be emulated.

Any Kernel calls will call the native ARM code in the OS.

So I guess it depends what your app is doing as to how fast it will run....

6
0

Alpha, MIPS, PA RISC, and PowerPC

Don't recall an NT port to PA-RISC, at least not one that was publicly announced. OTOH there were Itanic releases of XP and Server 2003/2008.

6
0

Re: Alpha, MIPS, PA RISC, and PowerPC

No, but on the topic of x86 emulation, the DEC Alpha machines had an x86 emulator in their boot ROM. It was needed to execute the x86 code in the boot ROM of the graphics card.

5
0
Anonymous Coward

When Microsoft attempted to run Windows natively on ARM, in the shape of Windows RT, the world stayed away. There was too much technical debt, aka legacy cruft, to make a clean port. Something, somewhere wouldn't run.

Something, somewhere? More like everything, everywhere. Apart from the set of Microsoft's own apps that they ported and the small amount of worthwhile stuff from the spectacularly successful Windows Store, the vast majority of existing Windows applications were incompatible with RT. Even if you were talking about apps being recompiled for Arm, RT only supported Windows Store apps from third party developers. So even if your "legacy" desktop application would have recompiled cleanly, it still wouldn't run on RT.

6
3
Silver badge

VC did support Win32 on ARM if you changed a few settings first and Surface RT did run ARM exes if unlocked. link

4
0
Silver badge
Windows

Smart

Good move by MSFT as it pulls the rug out from under lazy churnalists who scuppered RT and WIndow 10 Mobile by spewing FUD about the 'app gap'.

Now MSFT can move on from Intel and still run the Win32 apps where the coder's been dead for years.

3
13
Silver badge

Re: Smart

What are you on about? Nobody was interested in RT because they thought they could run Desktop apps and nobody was interested in Windows 10 Mobile because there were hardly any apps of any kind.

12
1
Silver badge

Re: Smart

Thank you for proving my point.

3
5

About as fast as an Atom

To put it in perspective that puts it about level with an Intel Atom x5-Z8550

http://browser.geekbench.com/geekbench3/8255581

I.e. you're not going to get a good experience running Photoshop on it as in Microsoft's demo

https://www.youtube.com/watch?v=gQ5bmRjBDeg

Even worse consider SIMD. Intel pointedly reminded everyone that recent SSE instructions are still patented here

https://newsroom.intel.com/editorials/x86-approaching-40-still-going-strong/

Now it's fair to assume that Photoshop uses a lot of recent SSE which could be translated to ARM SIMD. However the Intel blog posts is essentially threatening the OEMs with a lawsuit if this is enabled. The best way to avoid that is to disable SSE to ARM SIMD translations but that has a significant performance impact. I.e. not only would you be running Photoshop on a processor equivalent to an Atom, it's won't implement any SIMD instructions. And there's the question of how many Win32 x86 applications actually require SSE since it has been around for long and is actually a pretty well designed SIMD instruction set.

It's shame really. I'd love to see a Win32 phone based on Atom or Snapdragon chips that let you run Win32 applications. In fact that's what I thought they'd do with Windows Phone and/or WIndows RT. Unfortunately they decided to disable non Microsoft WIn32 ARM executables to try to get people to use Metro apps from the store. Now Windows Phone is dead could they try WIn32 Phone? On an Atom I reckon that might be viable. Most of the Android apps I use have a Win32 version. Chrome and Opera do. Pleco, my favourite Chinese dictionary actually run well on Windows Mobile before it run on Android and iOS. Problem is killing off Win32 WIndows Mobile applications on Windows Phone has alienated a lot of ISVs. Even if Microsoft launched Win32 Phone now, it's not clear if they'd bother to support it given how dominant Android and iOS are.

I suspect the ship has sailed. Everyone has moved on to Android and iOS and another phone OS isn't really viable.

6
0
Anonymous Coward

Re: About as fast as an Atom

Photoshop is a relatively high-end use case. If you're spending £50 a month on a CC subscription you're probably not bothered about splashing out for a high-end i5 or i7, and you're probably not the target market for this.

I expect this is aimed squarely at the high volume "back room terminal which runs Office + Edge + Web apps" type workload, and if it's Microsoft apps then it's all going to get recompiled to real native code anyway (and browser includes the JIT for scripting, so nicely platform agnostic). For a lot of use cases a low-cost all-in-one or Mac mini-like form-factor would make a huge amount of sense.

8
0
Silver badge

Re: About as fast as an Atom

> However the Intel blog posts is essentially threatening the OEMs with a lawsuit if this is enabled

The difference here is that Microsoft definitely want this to happen. They want to compete with tablets and Chromebooks but RT lacks traction and Intel can't hit that day spot on price/speed/power.

Microsoft have a big enough stick to force them to negotiate a license with OEMs to use those instructions.

2
0
Silver badge

If you can remember the '90s, you weren't really there, man.

6
0
Silver badge
Coat

What are you raving on about?

5
0
Anonymous Coward

"If you can remember the '90s, you weren't really there, man."

That was back when things could only get better.

3
0
Silver badge

Utterly, utterly pointless

"Hooray now I can run a subset of Windows software at a fraction of the speed of an x86 computer!"

Said nobody ever.

5
2
Bronze badge

These won't be running a BIOS! Come on, El Reg, you should know BIOSes are long dead.

Anyway, I have a horrible suspicion these will have locked down UEFI firmware and locked bootloaders, and thus will only boot a signed Windows kernel, so can only be made to run Windows son-of-RT or whatever Microsoft will call it, and also only run signed apps from the Windows store.

Thereby basically achieving what Apple have done with the iOS (iPad/Phone/Pod) and trying to do with the Mac.

1
1
Anonymous Coward

"Anyway, I have a horrible suspicion these will have locked down UEFI firmware and locked bootloaders"

I don't think it likely. Firstly most of these wont be made by Microsoft so it will be an OEM decision. Secondly near zero people would install an non MS OS and if it's Intel hardware both manufacturers and users would probably want the option of installing other Windows OSs too.

And whilst we know Windows 10 has historically had far fewer holes in boot loaders, etc. than Android / Linux, etc. to compromise such a system, someone normally always finds a way if there is a demand!

0
0
Anonymous Coward

Native code good, x86 emulation bad

On servers anyway, because non-x86 gave a degree of Windows virus protection.

Probably not so true now as I guess malware written in higher level languages, browser apps etc.

Still, non-x86 for servers seems like a smart idea to me.

0
6
Anonymous Coward

Re: Native code good, x86 emulation bad

"On servers anyway, because non-x86 gave a degree of Windows virus protection"

Viruses on Windows server have never been a significant issue as 99% of Windows virus attacks require user interaction. There have been a few notable worms but then Linux has also had a few of those. Now that Windows Server is a minimal feature install and is firewalled and locked down by default and also has no GUI by default it has a reasonably good security profile.

If I was to choose an OS based only on security then it would probably be Open BSD, but that's not usually the only consideration.

When used as an Internet facing Web server, Windows is actually circa 4 times less likely to be hacked / defaced than an OSS stack on Linux when allowing for market share of servers. To be fair on Linux, a fair proportion of such exploits are due to the stack rather than the OS, but still...

According to Netcraft ~ 50% of Internet websites now run IIS on Windows so if there was a significant security issue I think we would have seen it by now!

5
2
Silver badge
Trollface

Re: Native code good, x86 emulation bad

might as well do everything in javascript.

no, wait...

1
0

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Forums

Biting the hand that feeds IT © 1998–2017