ARM Launches Cortex-A5 Processor, To Take On Atom 176
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."
Summary is misleading (Score:5, Informative)
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... (Score:2, Informative)
Re:Good news for future iphone (Score:2, Informative)
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
Different L2 memory interface makes the difference (Score:2, Informative)
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.
More info at Arstechnica (Score:5, Informative)
http://arstechnica.com/gadgets/news/2009/10/arm-fills-out-cpu-lineup-with-cortex-a5.ars [arstechnica.com]
http://www.brightsideofnews.com/news/2009/10/21/arm-announces-cortex-a5-for-the-next-15-billion-cellphones-and-mids.aspx [brightsideofnews.com]
Re:Good news for future iphone (Score:3, Informative)
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).
Re:Good news for future iphone (Score:5, Informative)
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.
Re:Press Release (Score:5, Informative)
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.
Re:More advanced identity? (Score:3, Informative)
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.
Re:Press Release (Score:2, Informative)
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 [intomobile.com].
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.
Re:First the Beatles; Now the ARM? (Score:0, Informative)
I'm going to keep this civil.
Ubuntu runs rather like treacle on netbooks too.
Short story: It used to but not anymore.
Long story: Ubuntu 9.10 unlike its predecessors uses a newer more optimized kernel, new intel graphics drivers that have solved all of the performance issues of the previous effort, a new compiler that is pushing out significantly more processor efficient code, and it now defaults to the much faster modern ext4 file system. All of this adds up to significantly snappier performance on Atom based netbooks than both its predecessor or alternative OS's like Windows 7. So, please keep your old outdated FUD to yourself.
And basically I wouldn't use it even if it run quickly because it doesn't run the applications I want to use.
Two points for this one. First, between Wine, Crossover and VirtualBox, the old "it doesn't run my apps" is getting really tired. I'm getting into my 30's so I'm not as much of a gamer anymore but, occasionally I do fire up a golden oldie. Ever seen the level load times of FarCry on a Windows box using the NTFS file system? Cut that in half running it in Wine on a modern file system like Ext4. And when new stuff like an enemy jumps out, on Windows there a very small stutter, on Linux, no stutter. When you shoot and kill an enemy in Windows and they fall, they stutter again, not so on Linux. All of this is on the 2.8GHz C2D with a 9800GT video card. Same deal in Half-Life 2, Morrowind, FEAR, so on and so forth. They all run better in Linux than they do natively on Windows. Obviously, this doesn't apply on the netbook as it doesn't have the graphics card to play much more than Quake 2. But, that runs great in Ubuntu also, so there you have that. Oh, and Office 2003 runs faster in Crossover than it does natively. About the only downside I see to using Wine is the lack of support from the publishers. Hopefully that can be worked out in the future. In the meantime, I'll just suffer without it and console myself with the much greater performance and the portability. Portability, I say? Oh yeah, copy the Wine directory to another Linux machine and every program installed in it Just Works(TM). Try copying Program Files to another box and see what you get with most applications. Hint, it doesn't Just Work(TM). For the very few and steadily dwindling apps that don't play nice with Wine, there is another alternative. I find that a VM is the perfect place for Windows as it keeps malware like WGA from misbehaving and doing things like spontaneously rebooting my entire computer. Also, note that with Ubuntu 9.10, WinXP runs just fine in a VM when I really need it for oh, the two programs that don't have native Linux clients yet. As a matter of fact, if I were running Windows on the bare metal, I'd still run all of the auxiliary apps in a vm for many reasons. Ease of portability being one. When you reinstall Windows on a new box, you have to dig out all of your application CD's, driver CD's etc. and spend many hours getting back to where you started on your old machine. With Linux, I just pull the drive out of the old machine and plug it into the new machine. It starts right up on the new hardware as if nothing happened. Only a VM gives Windows this capability. My second point on your ridiculous FUD is that the coin has two sides. There are several Linux programs that I use very often that have no counterparts on Windows. To use the equivalent of your sentiment, I'll just say "So, there!"
Still, I guess I'm not an elite hacker like you.
Still more ancient fud. Every new user that isn't habitually entrenched in the backwards "Windows way" take to Ubuntu like a fish in water. No elite hacker skills required. You want to talk about elite hacker skills? Try removing much of the more nefarious malware that Windows boxes tend to be subject to. That takes some serious work.