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."
No, it's not... (Score:4, Interesting)
The Cortex-A5 is a slight improvement over the MPCore/Arm11/Arm9. That's nice for those who need it, but it's miles away from the speed of a Cortex-A9, which is really what's going to be needed to battle Atom.
And since the A9 has announced by ARM quite some time ago, this posting should have been written then not now.
In reality, it's not clear which niche the A5 is going to occupy. It's probably going to be useful in lower end smartphones only, since current higher end models are already using the faster A8.
Good news for future iphone (Score:4, Interesting)
Looks like the Cortex-A5 has 50% more performance while using 1/3rd the power of the current generation ARM11 found in the iPhone. As a game developer this makes me hopeful that we'll see cellphones as a gaming platform without sacrificing useful battery life.
Being late to the game is what is killing these... (Score:3, Interesting)
Re:Love to have one (Score:4, Interesting)
MIPS rather than ARM, but these things [amazon.com] are cheap and look pretty useful.
EMTEC Gdium Liberty 1000
Re:Summary is misleading (Score:4, Interesting)
I agree - the summary is bad.
But it's worth noting that according to previous articles, Intel "envisioned" Atoms one day making it into high end phones. This latest move from Arm will prevent that, solidifying their lead.
Re:Love to have one (Score:3, Interesting)
Why would you buy that when you can get a 10" Dell mini which runs every x86 app in existence through Windows, Ubuntu Preinstalled or Hackintosh?
For almost the same price it has:
Twice as much RAM.
Twice as fast of a processor.
Exponentially more software available.
Twice as much battery life.
And weighs exactly the same amount.
Re:MS (Score:1, Interesting)
So it took Autodesk years and years to make a 64 bit version of Autocad, because Microsoft forgot to make a Visual studio that could compile a 64 bit program? or Autodesk didn't have the money to upgrade there Visual Studio?
With open source software it indeed depends on the availability of a compiler, but with closed source software it seems preferable to slap new version numbers onto prehistoric piles of 32-bit code.
A5 is for people like me (Score:4, Interesting)
As a developer for products based on ARM9 and ARM11 SoCs the A5 is targeted squarely at me. I'm not sure why it's of any interest to slashdot. But it does appear to be a cheaper ARM11 (to the point of making the ARM9 obsolete) but with some of the features of the A8.
While smartphones are all sexy and exciting, the staple for cell phone manufacturers are the simple ordinary phones. If they can cram more features into the same cheap phone it usually means they can sell more of them. Think of it as competing in the free phone market. Where the styling and brand and features are the only way to differentiate yourself rather than price. The customer is just going to pick 1-4 of the plan bundled phones.
Re:No, it's not... (Score:5, Interesting)
Size is a big deal and right now, Cortex-A8 on 65nm is rather large for smart phones. they pack some decent power for netbooks so I'm not sure what the delay is on that front. Cortex-A9 on netbooks would be very nice but I think they are just sampling now so it won't happen til next year( 2010 ).
ARM is a thorn in both Microsoft and Intel's sides and there is probably massive amounts of pressure on OEMs and manufacturers to stay away from it. Atleast on the netbook side. Remember, the head of the Thai Manufacturers Association said they fear Microsoft when talking about Linux on netbooks. ARM is an enabler for Linux so it too is a threat to Microsoft. But I sure hope the market gets to make the choice some how, some way.
LoB
Re:First the Beatles; Now the ARM? (Score:3, Interesting)
I hope ARM beats x86 merely because x86 is an ancient technology that has a pile of limitations preventing the industry from moving forward as fast as it otherwise might. Previous attempts to move away from x86 failed due to the absence of software to run on the new machines. It's all fine and dandy if Microsoft write NT for the Dec Alpha and Itanium, but if there are no apps, it's pointless.
Actually there is a way for this to work. Microsoft ports Windows to Arm. Most of the time the processor is in kernel mode so that makes a difference. Now running user mode code through an emulator which is basically a big switch statement will not deliver a decent performance level. Microsoft could port their Office applications to ARM.
ARM have actually quite some experience of running non native instruction sets - Jazelle is mode where the ARM runs 80% of Java byte code natively. Basically there is an extra pipeline stage that decodes Java byte code into native ARM instructions.
Now surprisingly this doesn't give particularly good performance
http://weblogs.java.net/blog/mlam/archive/2007/02/when_is_softwar_1.html [java.net]
It's actually better to JIT the code. ARM have actually have a second generation produce that uses a mixture of Ahead or Time compilation to native code for the Java platform, DBX aka Jazelle for rarely used code and JIT for the hotspots that are executed frequently. In practice I'm told that you could get by with purely AOT for the platform and JIT for the rest, except that application startup will seem sluggish.
x86 Java VMs have to do this because there is no equivalent of Jazelle DBX there. Now ARM could do something similar for netbooks. Still that is not without problems. Notebook processors, whether x86 or ARM are optimized for power consumption, not performance. Notebooks are also very short of memory - you basically can't afford to keep both the native ARM code and the original x86 code in memory. Actually there isn't much disk space either.
So it's far from clear whether an ARM that can perform as fast as an Atom on native code - i.e. a faster processor that the fastest Cortex A9 - would be able to run x86 code as fast as an Atom. Given that the performance of an Atom running x86 code is pretty awful, that makes me wonder if you could sell them even if the battery life is much better. Even that is doubtful actually - Atom is pretty power efficient but current Atom chipsets are not. It's likely that Intel will fix that problem if Arm based notebooks start to become popular though. They'll cut the price of Atoms too. At that point ARM doesn't really have any advantage over x86.
Of course I say x86 but most x86 chips will be running x86-64 code by then. ARM doesn't have a 64 bit extension either.
Re:First the Beatles; Now the ARM? (Score:5, Interesting)
Acorn Computers tried in the 80's and 90's. The ARM processors were faster than their x86 rivals, and OS was years ahead of the likes of Windows and Mac OS. As you say, some monopolistic software company would never allow ARM to take off. Lucky ARM is now the most common architecture on the market.
It's sad x86 is still here, the platform should have been done away with years ago.
Re:Love to have one (Score:4, Interesting)
http://www.alwaysinnovating.com/touchbook/ [alwaysinnovating.com]
http://promos.asus.com/US/1000HE/ASUS/index.html [asus.com]
Two netbooks with long battery lives.
There are smaller devices available, which might be nice for lugging around - but keep in mind that the screen and Wifi are still big power draws, so the bigger the batteries the better.
Re:MS (Score:5, Interesting)
I've said this before. Aside from games, very little legacy software is CPU-bound. A modern emulator can get somewhere between 50-80% of the host native speed on emulated software, and not all of the code that is running will be emulated. Take a look at a typical Windows application. Most spend at least 50% of their CPU time in system library code. A half-decent emulator will just pass these calls to the native versions of the libraries, so for half of the CPU time you are running native code. A lot of recent Windows applications use some .NET code. This will be JIT compiled to ARM, so it's also native. The remaining code will be emulated, but the number of programs for which this will be too slow is very small.
Oh, and most people do not have a stack of x86 Windows software. They have one or two Windows programs that they depend on (or, at least, would not abandon without a lot of persuasion). You can bet that an ARM version of Windows would be accompanied by an ARM version of Office, and if MS really wanted to push it then they'd give a free download of the ARM binaries to people who owned the x86 version.
In terms of C programming environment, x86 and ARM are very similar. C does a terrible job at abstracting the differences between SPARC64 and x86 (for example), but it does a lot better at abstracting the differences between ARM and x86. Most software, unless it uses inline assembly or SSE / MMX intrinsics, is a straight recompile. The SSE and MMX intrinsics can be implemented in terms of NEON or slower scalar operations, so the code will compile, even if it doesn't get the same performance.
Re:MS (Score:3, Interesting)
Apple did not kill the PPC market. IBM did at least the desktop market, one day they decided to give up the PPC desktop processors without telling Apple. Apple did not have a choice, there were new desktop and notebook processors in the pipeline, while IBM busily was working on their high end server processors and was designing console processors for Sony and Microsoft with their old cores.
premature evaluation (Score:3, Interesting)
I'm shocked at this claim. Back in the day, Byte Magazine used to dissect processor architectures in a way you rarely see any more, apart from anything written by Jon Stokes over at Ars. Realworldtech picked up the torch, and I followed it for a while; smart guys, but you need a large Kool-Aid division factor to hang there.
This problem of "true innovation" has dogged the computer industry since the introduction of Hype 1.0.
Kurweil's law is "no technology before its time". Why is it that the premature ejaculator so often gets the lion's share of the credit? You can't deny the innovation at Xerox. The Xerox Dorado from 1979, which I once used for an hour, is reputed to have contained 3000 discrete ECL chips and have a BOM cost pushing up into six figures. Retail price might have been in the $200k range if, say, all the moon rocks recovered by NASA had been made of solid gold, and the engineers were suitably rewarded. I was told my my friend, a coop student there at the time, that the rumour on estimated street price to sell the Dorado was "probably $250k". I thought that was high at the time, but I knew less then about cost multiples.
Ray Kurzweil on how technology will transform us [ted.com]
When you run a giant fab, you need to consider your volume targets in choosing processor design goals. What made the Alpha kick ass was the incorporation of some ultra-expensive metalization. That's how you get fast 64-bit adder in early 1990s process technology: an entire layer devoted to fast carry propagation. Lacking OOO, you need short, deterministic instruction latencies above all else, unobtainium be damned. Works for NASA, Boeing, and Ferrari. This fabrication approach was a total non-starter for Intel volume production.
IIRC--and this is becoming dim--the Alpha was a four-issue core with a uniform instruction width and precious little OOO logic. What is it that Nahalem is reputed to have copied here? It's been known for 15 years now that x86 integer performance was able to directly compete with RISC designs given a large design team devoted to working around the instruction set wonkiness. Most of the problems with x86 were toll bridges, rather than permanent road blocks. On the floating point side, the blighted x86 stack architecture cost you a factor of two. But floating point defined the low-volume workstation market, where sports cars like the Alpha found fleeting glory. I actually think the Itanium better represented Intel's desire to take Alpha to the next level.
Apart from that, over the longer time frame, reality imposes convergent evolution. To my knowledge, Intel never once publicly stated that AMD's on-die memory controller was the wrong path to take. Intel usually said "not yet, we can do it cheaper for another spin without going there, and besides, our marketing department ate some bad mushrooms for a couple of years there, so our roadmap is a bit jumbled right now." Does AMD get credit for innovating on-die memory controllers or for facing up to despe