ARM Attacks Intel's Netbook Stranglehold

Barence writes "British chip designer ARM is launching an outright attack on Intel with the launch of a 2GHz processor aimed at everything from netbooks to servers. ARM claims the 40nm Cortex A9 MPCore processor represents a shift in strategy for the company, which has until now concentrated on low-power processors for mobile devices. In the consumer market, ARM is pitching the Cortex A9 directly against Intel's Atom, claiming the processor offers five times the power while drawing comparable amounts of energy. 'It's head and shoulders above anything Intel can deliver today,' ARM VP of marketing Eric Schom claims. However, it has one major hurdle to overcome: it doesn't support Windows. 'We've had conversations with Microsoft and you can imagine what they entail,' says Schom."

Comments

Re:Goody

[Andy Dodd]

Yeah. With a few exceptions, about the only variation between most netbooks out there in terms of required drivers are the following:
1) WiFi chipset
2) Card reader chipset (newer ones all seem to be USB mass storage, older ones tended to be a bit less standardized)
3) Bluetooth chipset (Bluetooth chipsets are basically standardized - While I know nonstandard ones exist, Bluetooth adapters that aren't a USB device compliant with a particular USB class are extremely rare.)

This is because the Intel Atom platform is EXTREMELY standardized. With a few rare exceptions, if you use an N-series Atom processor, it'll be paired with one of two variants of the Intel 945G chipset with GMA950 graphics.

Atom Z-series are a different story - they are all paired with a particular chipset with "GMA500" graphics, which unlike most Intel chipsets has basically nonexistent Linux support. So never buy an Atom Z-series based machine if you want to run Linux, they are nearly always paired with unsupported graphics.

Re:No windows support?

[TheRaven64]

Clock for clock, the Cortex A8 is a bit faster than the Atom on most workloads (in about 10% of the power envelope). The A8, however, typically ships at about half the clock speed of an Atom (they go up to 1GHz, but 600MHz is the most common speed). The A9 is slightly faster than the A8 clock-for-clock, but goes to twice the clock speed and scales to four cores, so it's not a stretch to imagine that it's more than five times the speed of a single-core Atom. I've not seen any figures for the A9's power consumption yet though...

It's worth noting that ARM doesn't make chips, they are an IP-only company. ARM licenses designs to other companies who combine their cores with other stuff and ship them. One of the more high-profile Cortex A9 licensees is nVidia, who are using it in their Tegra line. Other existing ARM licensees, like Qualcomm, TI, Samsung and Freescale have already signed up for the A9 as well.

It's also worth noting that the A9 isn't really news. The designs have been available from ARM for a while now. I don't know of any shipping chips including A9 cores yet (being mass-produced, anyway; there are a few being sampled), but TI announced the OMAP4 series a little while ago which is based around the A9 and looks like a very nice chip for handheld machines.

Re:Porting code to a new architecture

[TheRaven64]

It is either a complete rewrite, a simple recompile, or something in the middle depending on how different the architectures are. In terms of programmer-visible features (ignoring things only visible to compiler and OS writers), ARM and x86 are very similar; same word size, almost identical alignment constraints, same byte order. If you wrote your program in a high-level language, it is just a recompile. If you used any assembly language, then you will need to rewrite it. If you used a language somewhere in the middle, like C, then it will probably be a straight recompile. This is unlike porting, for example, from x86 to SPARC64, where you suddenly have very strict alignment, opposite byte order, and different

Of course, this is assuming the operating system interfaces are the same. If you're on something like OpenBSD, for example, then the OS does a good job of isolating the userspace code from having to know anything about the underlying architecture. Linux, on contrast, exposes a lot of architecture-specific details to programmers (and that's ignoring the fact that embedded Linux often ships with a non-GNU libc, which lacks a lot of features). Wince is about the worse at this, where every single device implements some subset of the Win32 APIs and so you end up having to do some tweaking for every device.

Re:A compelling Linux on ARM netbook will worry MS

[IGnatius T Foobar]

Linux already made MS drop their price, allwing cheap windows netbooks because of linux. It's not out of the question that a really compelling ARM netbook would scare them into ARM support.

And Microsoft would still lose. The only thing Windows really has going for it is the existing library of PC software. That's the network effect that keeps Windows out front, otherwise the market would have dumped Windows ages ago. Windows on ARM runs existing Windows x86 software about as well as Linux does: not at all.

In fact, ARM netbooks running Windows might actually be at a disadvantage relative to Linux. People would see the Windows logo on the box and take it home, assuming that they could run PC-Windows software. When that software fails to load, the netbook gets returned to the store.

Netbooks running Linux on an ARM processor with insanely long battery life and a true dedicated mobile operating system may be what it takes to get people to realize that netbooks were not intended to be merely smaller laptops.

Re:No windows support?

[TheRaven64]

64-bit is a buzzword rather than a useful feature for most people. People with 64-bit SPARC or PowerPC machines generally run very little 64-bit software, because doubling the word size doubles the cache usage for no benefit (especially on SPARCv9, where integers registers are all 64-bit even when running 32-bit code). It's only important on x86 because 64-bit also means twice as many general-purpose registers, SSE required (no x87 ugliness) and a few other improvements. If someone defined an ILP32 profile for x86-64, where pointers were 32-bits but the chip ran in 64-bit mode then pretty much all code would be faster than the standard LP64 profile. On non-x86 architectures, 64-bit support is only important when you need more than 4GB of address space and are willing to pay a speed penalty for it.

32-bit only becomes a limitation on NetBooks when you start to get applications that can't fit comfortable in less than 4GB of RAM. This is not likely to be a problem for a few years. NetBooks may start getting more than 4GB of RAM in the next couple of years, but that doesn't require major changes, as long as the OS can address it and map it into processes' 32-bit address spaces (we still aren't getting many machine shipping with more RAM than a Pentium Pro with PAE can address).

Re:A compelling Linux on ARM netbook will worry MS

[TheRaven64]

Note that watching YouTube is actually not a relevant benchmark for the ARM core. On most existing ARM SoCs, video decoding is offloaded to the DSP, ISP, or GPU and most of the A8 versions can decode 720p H.264 without any problems (and without touching the ARM core). SoC manufacturers like Freescale have partnered with Adobe to ship custom versions of Flash that take advantage of the extra hardware on the chip for exactly this. This means that an ARM chip will generally do a lot better, in terms of power usage, than Atom when watching YouTube because it's using dedicated hardware for the video decoding, while the Atom is doing it on the CPU.

Re:No windows support?

[TheRaven64]

Look through the Slashdot archives for the article containing benchmarks - I am too lazy to dig it out. It is a gross mistake to regard ARM as a RISC architecture. It is in the sense that the instruction set is orthogonal, but it is incredibly dense (much denser than x86). Almost every instruction can be predicated on one of the condition codes, which eliminates the need for a lot of branching (and, therefore, reduces the overhead from superscalar designs) and every instruction gets free use of a barrel shift on the result. Added to that, most ARM chips from the last decade support one or more of the Thumb instruction sets, which are 16-bit versions of the ARM instruction set, and most ABIs let you switch between these on a per-function basis, so you can compile functions that don't touch more than 64KB of RAM into thumb code and get even better cache usage.

You'd also be surprised at SIMD performance. The Cortex A8 and A9 support both Neon and VFP vector instruction sets. They are not so fast for double-precision vector floating point workloads, but on single-precision and integer SIMD loads they do reasonably well. For very FPU-intensive workloads you are generally better off using the DSP that comes with most ARM SoCs.

Re:What does it support?

[the_womble]

linux has held pretty steadily at sub-1%

Steve Ballmer says otherwise

Re:no windows?

[TheRaven64]

There is nothing special about the ARM ISA that makes it require less power.

Yes there is. The ARM instruction set is simpler to decode than x86, which means that the (fixed) power cost of the instruction decoder is higher on x86 chips (you can't turn off the decoder as you can, say, the FPU or an adder while not in use because it's always in use unless the whole CPU is in power-saving mode). The Core 2 has to do a lot of clever stuff with the x86 instruction set because it doesn't match up at all well to a modern microarchitecture; not only does it split complex instructions into smaller operations, it also has to combine sequences of micro-ops into things that can be executed. Atom doesn't do any of these things, so it is a lot slower (per clock) in an effort to save power. ARM also gets to cheat a lot with things like Thumb code. This is a simpler, 16-bit ISA, which achieves very good cache density at the cost of some flexibility. You can switch ISA on a call with ARM chips, so you can have some routines in Thumb code and some in the full instruction set. Unlike the compression that Intel gets from a variable-length instruction set, this helps power saving because you can turn off the thumb decoder when it's not in use (and turn off the other instruction decoders when in thumb mode).

And that's ignoring things like the predicate instruction and barrel shifter that make ARM code denser and more cache-friendly than x86 code (which has the same advantage over something like SPARC). This means that ARM chips can get away with smaller instruction caches, which saves power.

If you want a more detailed explanation, Jon Stokes does a good job of explaining the advantages ARM has over x86 in his analysis of the Atom.

Re:NO WINDOWS ARM APPS SO -- SO WHAT?

[hattig]

There are 75,000 apps for ARM iPhone OS X.
There are 10,000+ apps for ARM Android OS.
There are loads of apps for ARM Maemo.
There are loads of apps for ARM Symbian.
There are loads of apps for ARM Windows CE and derivatives.
There are loads of apps for ARM Linux and derivatives.

Re:The best thing about it

[Corson]

No problem, Ubuntu for ARM will be out soon (it's already available for specific platforms).

I don't think you know anything about Linux portab

[anti-NAT]

ility. It runs on more architectures than OpenBSD, and you're saying it's far less portable, and that the architectual differences are exposed? Way back in 2000 I ran (Debian) Linux on a Sun Ultra 5, and it just worked. The only issue I had was nmap, and that was likely due to a missing htonX() calls. OpenBSD wouldn't have magically put those instructions in the nmap code if they didn't exist either.

I've written networking kernel code for Linux, and never encountered any CPU specific requirements - it's all abstracted behind function calls.