You may have heard about Windows RT vs Windows 8. They’re, like, almost the same, but also really different? It’s confusing. Well, here’s the difference:
Windows 8 can only run on x86/x64 processors. Windows RT can only run on ARM processors.
Cool. But why does x86/x64 vs ARM matter? Why does each processor require different versions of Windows? Let’s drill down.
x86/x64 processors: They’re fast and powerful, but they require a lot of electricity. So, they’re used in desktop computers that can plug into the wall. All versions of Windows run on x86/x64.
ARM processors: They’re weak but low-power processors for smartphones and other devices that aren’t plugged into the wall. Mobile iOS and Android operating systems run on ARM.
The two processor architectures are mutually exclusive: a program that’s built for x86/x64 can’t run on ARM under any circumstances, and vice versa.
Since the 90s, these architectures have existed in parallel worlds: ARM for phones and small PDAs, x86/x64 for desktops and big laptops. But in the past few years, the market’s gotten all hot and bothered for tablets that are bigger and more powerful than phones, but simpler than laptops — like the iPad or Kindle. Tablets have to be small and light, which means tiny batteries, which means ARM processors. But tablets have USB ports, full web browsers, and word processing and photo editing apps, which means ARM-based portables have become direct challengers to x86/x64-based desktops.
Windows has always been a desktop-only operating system, so it’s only been available for x86/x64 processors. But Microsoft sees everyone moving to tablets, and it doesn’t want to lose all its future revenue, so it entered the mobile arena with Windows RT and the Surface. [update 2016: Windows RT sorta failed and the Surface is becoming a brand for x86/x64 processor powered laptops, with the Surface Pro and Surfacebook]
x86/x64 processor manufacturers are potentially the most harmed by the rise of tablets. But there’s an easy way for them to stay relevant — make an x86/x64 processor that’s low-power enough to place in tablets. Intel’s doing that with the Atom processors, which give up processing power, x64 support, and high-speed computing features like SSE in return for super-reduced power consumption.
BUT. GET THIS. Atom processors still can consume 2x the electricity of an ARM processor, even at the same processor count/clock speed. What?
Well, it’s because of an inherent difference between the processors. See, “ARM” stands for “Advanced RISC Machine”. RISC stands for ‘Reduced Instruction Set Computing’, and, befitting an acronym that’s part of your entire brand name, it’s what makes ARM so low-power.
You may remember that the instruction set refers to the set of commands that the processor can execute. Well, most code only requires a few instructions — read/write memory, do arithmetic, jump, boolean logic, not much more. ARM processors only offer these basic instructions. Thus, a reduced instruction set.
x86/x64 processors are CISC, or ‘Complex Instruction Set Computing’. Although almost all code can be represented by the basic instructions in RISC, certain patterns of instructions are common — for instance, “write this byte to memory then look at the immediately following byte”. CISC processors offer combo-instructions (previous example being STOSB) that handle these common instruction patterns super-efficiently. However, support for these combo-instructions requires extra hardware — and that hardware costs electricity.
That difference in hardware is why ARM processors use less power than x86/x64 processors at the same clock speed. Mind you, it also means that some programs run faster in x86/x64 processors than they do in ARM processors with the same specs — an algorithm that takes 3 cycles on an ARM processor can take 1 cycle on an x86/x64 processor if it’s been wrapped into a CISC combo-instruction. It’s also why programs built for x86/x64 can’t run in ARM — once you compile a program for x86/x64, it’s hardcoded to use these combo-instructions, and there’s no translation to ARM from there.
So what do the specs of two similar-release-date processors look like? Let’s compare the ARM AM3359 and the x86 Atom Z650.
|ARM AM3359||Atom Z650|
|INTRODUCED IN||Q3 2011||Q2 2011|
The Atom Z650 is definitely more powerful, with a 67% clock speed increase — but it consumes over 400% the electricity. That said, it theoretically could run a program over 4X faster than the ARM AM3359, if that program uses a ton of CISC instructions.
All the same, I’d eat my whole Beanie Baby collection if a real-world program can get more than a 2x speed increase. And that’s a lot of Beanie Babies.
Thanks for this. Best explanation I’ve found on this.
Yes, I’d second that. Thanks for the very good explanation.
Thanks! Simple and neat!
have to disagree here. actually having a “reduced” _instruction set_ doesnt necessarily mean that _instructions_ themselves have to be simple. thats especially true when comparing 32-bit arm and original x86 (im not talking x64 and extensions now these arent yet in the atom anyway). arm instructions arent destructive, have predication and free shift, they dont necessarily update the flags, load/stores have autoincrements built in (also means you can have as many stacks as you like), block transfer with more regs available is more handy than lods/movs/stos. i can say from my own old-time experience that hand-optimised arm code easily wins over hand-optimised x86 code most of the time in amount of work done per instruction count. now the sorry state of most widely used arm compilers is other story…
Thanks, I got it now!
4x power consumption for 2x speed? sounds cheep at the price. normally to acheave something like that you need a major process shrink.
so far i have not seen many programs developed for arm that can match both performance and features that a x86/x64 native program.
in the computing world theirs always a price.. you gain X you loose Y.
Awesome – great explanation – so much so that i’m leaving a comment to say how good it was!
Nice one dude 🙂
Very nice explanation. Thank You 😀
…superb explanation. Pls do become n a teacher or lecture..
Technically x86 simply refers to a family of processors and the instruction set they all use. It doesn’t actually say anything specific about data sizes. The term x86 started out as a 16-bit instruction set for 16-bit processors (the 8086 and 8088 processors), then was extended to a 32-bit instruction set for 32-bit processors (80386 and 80486), and now has been extended to a 64-bit instruction set for 64-bit processors. It used to be written as 80×86 to reflect the changing value in the middle of the chip model numbers, but somewhere along the line the 80 in the front was dropped, leaving just x86. More about….x86/x64