3 ms·
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
by 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 agoFor 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 agoThe 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 agoThis 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 agoI 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 agoThe 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 agoWhat 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 agoThe 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.