9 ms·

Intel Atom versus ARM Cortex-A9

27 points by gvb 17y ago

pieter 17y ago
Even more notable is that the Intel-based netbook is running at 1.6-GHz clock frequency the dual-core Cortex-A9 development is running at 500-MHz. 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.
- illumen 17y ago
  For two reasons. A lower ghz means it uses less power. The second reason is that there is room for improvement, since this is a development board. It is said another 500mhz or so from released versions, and it's unlikely the atom will double its ghz any time soon. 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.
  - sketerpot 17y ago
    The figures I always hear say that the Cortex-A9 will scale up to 2 GHz if you go for the least power-efficient settings, and that somewhere around 1 GHz would probably be more typical of real use. 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.
- gvb 17y ago
  This is the core of the power vs. speed trade-off. Since the ARM is getting roughly the same amount of work done at 1/3 the gross clock frequency, it has a substantial advantage in producing a lower power implementation. 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.
  - tedunangst 17y ago
    I liked your post, but you didn't explain at all why a legacy x86 ISA has anything at all to do with either static or dynamic power.
    - timthorn 17y ago
      The x86 ISA has significant complexity to it. The essence of the problem is that the logic required to decode x86 instructions (originally designed to be featureful for assembly programmers' convenience) is large, compared to that required for the ARM ISA which was designed to be decoded in an efficient manner. 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).
      - tedunangst 17y ago
        What percentage of an Atom is devoted to decode? Atom is around 45 million transistors. The PPro which also decoded to mini-RISC had 5 million. Somehow I don't think the Atom is really burning that much space/power on decode. 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?
        sketerpot 17y ago
        The Cortex-A9 executes more instructions per clock because it can decode more than one instruction at a time (2 to 4, usually 4) and execute them out of order to get more instruction-level parallelism. Atom can decode a maximum of two instructions at a time, and executes them in order. 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.
notauser 17y ago
FTA> "As form factors shrink power efficiency and battery life will increasingly drive market success." 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/2009/04/03/windows-on-netbook-pcs-a-year-in-review.aspx http://windowsteamblog.com/blogs/windowsexperience/archive/2... and http://www.osnews.com/story/22587 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.
- gvb 17y ago
  You do need to be a little careful looking at netbook market share and size statistics because Microsoft decided they could not cede that market to linux. As a result, they have distorted the market by licensing WinXP (and now Win7?) at an attractive price point and added laptop/netbook size and speed criteria to discourage low end netbooks.
  - rbanffy 17y ago
    "As a result, they have distorted the market by licensing WinXP (and now Win7?) at an attractive price point and added laptop/netbook size and speed criteria to discourage low end netbooks." Thank you, Microsoft, for helping advance computer technology... I don't have to repeat this: http://news.ycombinator.com/item?id=1033708 http://news.ycombinator.com/item?id=1033708
protomyth 17y ago
I am curious, given the amount of memory that we can put in smaller and smaller devices, is there a clear 64-bit migration for the ARM like the Atoms already have? It seems we will be exceeding 4GB of RAM in devices in the the not to distant future.
- rbanffy 17y ago
  I don't know, but if we stick to running open-source Unix-like software, it should be trivial to switch architectures when needed. Most software I use already has actively maintained ports to 64-bit architectures since the mid 90's. 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.
  - timthorn 17y ago
    I believe the question is more to do with the hardware options. Going to 64-bit will require a great deal more silicon area with a consequent increase in power consumption, which tends to go against the ARM philosophy (indeed, the later ARM instruction sets have gone more in the direction of 16bit).
    - rbanffy 17y ago
      There is no real need to migrate to 64-bit unless you need to cleanly address more than 4 GB of memory. The case for the x86 migration to 64-bits was not so much the extra memory space, but the extra registers. ARM always had plenty of them. 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.
      - timthorn 17y ago
tedunangst 17y ago
The video is designed to convince you that the ARM system is just as fast as the Atom system. But they don't present evidence to support this. They only demonstrate that the ARM is sufficient to do basic web browsing. I want to see a demo playing something that actually taxes the CPU, e.g. Quake2. Then we'll see what's better. 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?
- wmf 17y ago
  They only demonstrate that the ARM is sufficient to do basic web browsing. That is impressive, considering that the ARM Cortex A8 was not sufficient. They have gone from "not good enough" to "good enough".

27 points by gvb 17y ago

Even more notable is that the Intel-based netbook is running at 1.6-GHz clock frequency the dual-core Cortex-A9 development is running at 500-MHz. 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.

illumen 17y ago
For two reasons. A lower ghz means it uses less power. The second reason is that there is room for improvement, since this is a development board. It is said another 500mhz or so from released versions, and it's unlikely the atom will double its ghz any time soon. 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.
- sketerpot 17y ago
  The figures I always hear say that the Cortex-A9 will scale up to 2 GHz if you go for the least power-efficient settings, and that somewhere around 1 GHz would probably be more typical of real use. 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.
gvb 17y ago
This is the core of the power vs. speed trade-off. Since the ARM is getting roughly the same amount of work done at 1/3 the gross clock frequency, it has a substantial advantage in producing a lower power implementation. 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.
- tedunangst 17y ago
  I liked your post, but you didn't explain at all why a legacy x86 ISA has anything at all to do with either static or dynamic power.
  - timthorn 17y ago
    The x86 ISA has significant complexity to it. The essence of the problem is that the logic required to decode x86 instructions (originally designed to be featureful for assembly programmers' convenience) is large, compared to that required for the ARM ISA which was designed to be decoded in an efficient manner. 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).
    - tedunangst 17y ago
      What percentage of an Atom is devoted to decode? Atom is around 45 million transistors. The PPro which also decoded to mini-RISC had 5 million. Somehow I don't think the Atom is really burning that much space/power on decode. 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?
      - sketerpot 17y ago
        The Cortex-A9 executes more instructions per clock because it can decode more than one instruction at a time (2 to 4, usually 4) and execute them out of order to get more instruction-level parallelism. Atom can decode a maximum of two instructions at a time, and executes them in order. 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.

notauser 17y ago

FTA> "As form factors shrink power efficiency and battery life will increasingly drive market success." 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/2009/04/03/windows-on-netbook-pcs-a-year-in-review.aspx http://windowsteamblog.com/blogs/windowsexperience/archive/2... and http://www.osnews.com/story/22587 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.

gvb 17y ago
You do need to be a little careful looking at netbook market share and size statistics because Microsoft decided they could not cede that market to linux. As a result, they have distorted the market by licensing WinXP (and now Win7?) at an attractive price point and added laptop/netbook size and speed criteria to discourage low end netbooks.
- rbanffy 17y ago
  "As a result, they have distorted the market by licensing WinXP (and now Win7?) at an attractive price point and added laptop/netbook size and speed criteria to discourage low end netbooks." Thank you, Microsoft, for helping advance computer technology... I don't have to repeat this: http://news.ycombinator.com/item?id=1033708 http://news.ycombinator.com/item?id=1033708

protomyth 17y ago

I am curious, given the amount of memory that we can put in smaller and smaller devices, is there a clear 64-bit migration for the ARM like the Atoms already have? It seems we will be exceeding 4GB of RAM in devices in the the not to distant future.

rbanffy 17y ago
I don't know, but if we stick to running open-source Unix-like software, it should be trivial to switch architectures when needed. Most software I use already has actively maintained ports to 64-bit architectures since the mid 90's. 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.
- timthorn 17y ago
  I believe the question is more to do with the hardware options. Going to 64-bit will require a great deal more silicon area with a consequent increase in power consumption, which tends to go against the ARM philosophy (indeed, the later ARM instruction sets have gone more in the direction of 16bit).
  - rbanffy 17y ago
    There is no real need to migrate to 64-bit unless you need to cleanly address more than 4 GB of memory. The case for the x86 migration to 64-bits was not so much the extra memory space, but the extra registers. ARM always had plenty of them. 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.
    - timthorn 17y ago

tedunangst 17y ago

The video is designed to convince you that the ARM system is just as fast as the Atom system. But they don't present evidence to support this. They only demonstrate that the ARM is sufficient to do basic web browsing. I want to see a demo playing something that actually taxes the CPU, e.g. Quake2. Then we'll see what's better. 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?

wmf 17y ago
They only demonstrate that the ARM is sufficient to do basic web browsing. That is impressive, considering that the ARM Cortex A8 was not sufficient. They have gone from "not good enough" to "good enough".