Intel Atom versus ARM Cortex-A9
eetimes.com
eetimes.com
I have several mid-to-late-90's RISC workstations (I restore and collect them) that have 64-bit processors and OSs in them. 64-bit computing is news only to the x86 world.
With about 1.5 gigs on my Atom-based netbook, it hardly hits the swap partition unless I am running Windows on a VM session.
More to the point, moving ARM to 64-bits is relatively simple - and the ARM cores are so small even if you had twice the silicon area for that (a worse than worst-case-scenario) you would end up with a core that is still a fraction the size of a tiny x86. A Cortex core occupies less than 2 square millimeters.
With cache.
Cortex is the branding for the ARM implementations of the ARM v7 Architecture. A brand was chosen for the first time because historically, even numbered ARM cores don't sell well (ARM8, anyone? ARM10?), so the next core after the ARM11 would have had to skip to ARM13. But 13 is unlucky. So that's ARM15 then... In addition, it would be very easy for the ARM v7 architecture to be confusd with the ARM7TDMI implementation of the ARM v4 architecture.
The grand plan was to bring out new cores in V7 targetting three distinct market segments - Applications, Realtime and Microcontrollers (see what they did there?!), with very different performance points and feature sets. Thus, the Cortex M3 has a die size of 0.86mm2 on a 180nm process, but that's a weedy core. The A8 has a die size of a bit under 4mm2 on a 65nm (albeit speed optimised) process, without the ETM included.
So, I'm not quite sure what core you are talking about - but it is also the case that the Atom die does contain a significant number of perhiperals and busses.
A 64-bit ARM won't have a problem beating an x64 processor in terms of MIPS/Watt, I'm fairly sure.
Edit - I should have explained that the number following the A/R/M is meant to indicate performance and not be a version number. The A5 and A9 both came out after the A8, for example - the ARM market isn't about increasing performance with every design, but ensuring a good fit for a design envelope.
http://www.arm.com/products/CPUs/ARM_Cortex-R4F.html
Whatever that is. I am no ARM expert.
Edit: I think this one would be better. The R is for real-time applications
http://www.arm.com/products/CPUs/ARMCortex-A9_MPCore.html
This other one (http://www.arm.com/products/CPUs/ARM_Cortex-A8.html) is about 4 mm2.
I hope it does work out like that, because cheap Linux-only hardware will only help Linux adoption! However I still think this is incorrect. You can already get a netbook with more than one useful day's battery life, which means you can always plug it in overnight. There are people who need more but that's a fairly small niche.
x86 compatibility is a much bigger deal. The percentage of netbooks sold with Linux has dropped from 100% to somewhere between 33% and 4% (sources: http://windowsteamblog.com/blogs/windowsexperience/archive/2... and http://www.osnews.com/story/22587 ).
That's still not a bad number, especially if it's closer to 33%, but it does put ARM in the position of at best trying to win a market within a market.
On top of that there's a question of how much further form factors are really going to shrink. Keyboards can only get so small, and we are already seeing a trend towards _bigger_ net books - not smaller.
Finally, they are comparing against the old single processor atoms, not the new dual core atoms that are already available.
That still leaves ARM with a potential advantage in the tablet market, where there is a lot less space for batteries and the software stack is better concealed. But the fate of the tablet market is still in doubt.
Plan9 has cross platform debugging, let alone compiling (which is extremely trivial "conf=ARM9 mk")
debugging :
import remote /proc /proc
echo stop > /proc/$apid/ctl # if you want it stopped
acid $apid # the debugger
Can it run the vx32 sandbox version http://swtch.com/9vx/ Or even just the userland tools as Unix programs http://swtch.com/plan9port/
hmm, odd those URIs aren't responding, which is unusual, give it a while
I prefer VirtualBox, but running Plan9 inside a VM takes all the fun out of it.
But come on, which way do you want to have it. Castigating because of lack of certain apps.
BTW if Django is pure Python then it should run just fine, we have native Python.
Emacs, hmm blegh. FF and OO well ok, no native. That's why I have multiple comps.
Also: if there is a non-trivial market for ARM netbooks, Microsoft will produce Windows for it (they probably already do, internally). They are highly sensitive to business risk.
And then, ARM-based Windows notebooks will not run x86-based Windows software.
Microsoft has Windows CE for ARM (and others), but it sucks really bad and is bears little relationship to desktop Windows apart from its name (and suckyness, but that is only my opinion).
Yeah, loss of platform is the real problem. Windows isn't that great; its software is. Same for intel. Hence the "wintel platform".
However, we have this new "web" platform, which might not be good enough, or have enough products, or be fast enough - but it is improving all the time. Perhaps, call it the web+arm = "warm" platform (though the ARM isn't part of the platform; any web will do).
BTW: if windows is written in a high level language (C), it just requires that the compiler targets a different processor. Of course, any tweaks written specifically for x86 (esp inline assembly) would have to be dealt with, and perhaps performance wouldn't be adequate with a simple retargeting - ARM would also need tweaks (again, esp inline assembly).
You know... We have had this new open-source platform that created lots of programs that can run on anything. I use Firefox on Windows PCs (it's not my fault - company policy), on Linux PCs, on a PPC Mac (and an IBM) and under Solaris on a SPARC box. It works well (apart from Flash support) on all of them.
BTW, all these boxes have GNU command-line tools and a decent set of compilers and interpreters (I run Cygwin on Windows). With the exception of Windows and Mac, which impose their looks on users, I would be unable to tell what I am running under the GUI from a screenshot (not really - the AIX box runs CDE).
I highly doubt that a company with $20 billion dollars in the bank would have a problem porting to ARM even if it didn't already have extensive experience on that platform (WinCE).
MS could easily have their OS and Office ported over and released in the amount of time it would take ARM to make any serious dent in the x86 market.
Heck, ARMH only has a 4 billion market cap, MS could easily buy the whole company in cash, at that point they'd certainly have the expertise. I'd say it's highly likely they could maintain a port.
Realistically, ARM would probably pay MS and send over their top engineers if MS expressed interest in porting Win7 to ARM. NVidia would probably get in on the action too to avoid the x86 licensing problems they are facing against an AMD & Intel that aren't suing each other into oblivion anymore. At least until the next time they decide to sue each other into oblivion.
Office is another story and would need work, although if MS ever carry through on their original plans to convert all their apps to .NET compatibility should come for free.
Thank you, Microsoft, for helping advance computer technology...
I don't have to repeat this: http://news.ycombinator.com/item?id=1033708
How is selling their software at an attractive price to the market classed as distortion?
"Microsoft charges local OEMs $32 for XP Home on netbooks, compared to around $65 for XP Home on desktops. Large OEMs are believed to pay much less." http://www.crn.com/software/212902058
Charging differing prices for different market segments is a reasonable business practice, and it could be argued that Linux is the OS that is distorting the market, seeing that there's no licensing fee at all involved. :)
If you are talking about the latter then no, it's probably not dumping. If you are looking at the former I bet it's not so clear cut. WinXP development and all of the associated cost (such as the loss-making products like IE that help keep WinXP in it's market position) would have been pretty expensive - and the expenditure is still going on today thanks to things like security support and IE upgrades.
Because it stifles competition?
Besides that, this arguments ignores the other part: the one in that Microsoft restricts what kinds of netbooks can be built by modulating license price for the machines.
James Hamilton is looking toward ARM and makes "the argument that the right measures of server efficiency was work done per dollar and work done per joule. Purchasing servers on single dimensional metrics like performance or power or even cost alone, makes no sense at all."
http://perspectives.mvdirona.com/2009/01/15/TheCaseForLowCos...
http://perspectives.mvdirona.com/2009/09/07/LinuxApacheOnARM...
"James is a Vice President and Distinguished Engineer on the Amazon Web Services team where he is focused on infrastructure efficiency, reliability, and scaling."
If it's all about "just fast enough to view the BBC", then what prevents Intel from scaling the Atom back to 500MHz?
PS: What is the graphic "accelerator" in the intel system?
That is impressive, considering that the ARM Cortex A8 was not sufficient. They have gone from "not good enough" to "good enough".
I don't get why people keep saying this. One is x86-based, the other is ARM-based. Why should you be able to compare cpu frequency? Is it notable that a Core 2 processor performs better at 3.2GHz than a P4? And that's even in the same general CPU architecture.
Intel has been very clever (read "spends a lot of money") in their process to make it run faster at a given power level, but their legacy architecture is a major millstone around their low power aspirations.
There are two aspects of power consumption in digital electronics:
1) Static power (leakage)
2) Dynamic power (cost of switching state)
The static power is what the part consumes while sitting idle. As a gross generalization, optimizing for execution speed typically hurts static power (you end up with more leakage to facilitate faster switching speeds). Note that smaller geometries help speed, but hurt leakage. Semi manufactures, including Intel, fight this by being more clever with their process, doing things like SOI (IBM/Freescale, also AMD?) and high-K insulation (the latest "hotness", if you pardon my pun).
Dynamic power is the cost of switching transistors on and off, of toggling interconnects high and low. This is largely a capacitive charge/discharge effect. Every time you switch a transistor gate or drive a transmission line, you have to push charge onto or drain charge off of the gate or line. It costs power to do this. It costs more power to do this faster.
CPU speed can also have "knock-on" effects throughout the system. Faster CPUs (typically) have or need faster memories and other peripherals. If the memories are slow, for instance, the CPU spends a lot of its time waiting for cache lines to be filled or emptied. Intel helps this by having larger caches, but caches cost power too - bigger caches have more leakage (1) and faster caches cost more for dynamic power (2).
Intel is working hard to make a low power x86 architecture and succeeding to some extent, but they have to do a lot of brute forcing to overcome their legacy CPU architecture.
Like martial arts, your strength (x86 ISA and their legacy of emphasizing raw clock rate) can become your weakness if your opponent can figure out how to use it against you.
That further logic certainly increases static power in terms of the extra area used, and also increases the dynamic power as more translation is required to get from an x86 instruction to the hardware control signals (I believe that the central part of the Atom effectively runs a different ISA translated from the x86 ISA via microcode).
You and gvb seem to imply that an ARM (RISC) chip which does less work per instruction somehow does more work per clock. I find that surprising. Otherwise, what is meant by the "emphasize raw clock rate" comment?
The Atom also uses precious pipeline stages on decoding the x86 instruction set -- all of it. There are a lot of instructions there, and all but the most common require the processor to read sequences of several micro-instructions from a ROM.
Now, the Atom tries to compensate for this with Hyperthreading: they share the decode unit among two threads (hypothetically) and have those threads share the execution units on the chip. This gives Atom a boost in performance per watt if you can find two processes that need to run at the same time. For single-threaded workloads, Cortex-A9 looks like it will continue to trounce Atom pretty severely, and for multi-threaded workloads, it's not expensive to put down some more A9 cores. It's not like they have to decode x86 instructions or anything, so they can be pretty darn small.
At the same time, the RISC instruction sets were friendlier to compilers, with large register counts. RISC architectures were also ruthlessly optimized for the compute intensive tasks of the day.
So re: static/dynamic power decoding RISC instructions is going to fundamentally involve less dynamic power.
No gfx accelerator on the arm board either. So it should get faster than this yet again.
So this shows fairly good promise to it being a good architecture.
It looks like the obvious fit for the Apple Tablet, by the way. It's fast enough to compete head-on with Intel chips while taking it easy on the batteries. Apple bought PA Semi, and has made custom ARM-based chips before. This would be a competitive advantage that other companies would have trouble duplicating, and for that reason alone I think Apple would go for it.