ARM Announces 64-Bit Cortex-A50 Architecture

MojoKid writes "ARM debuted its new 64-bit microarchitecture today and announced the upcoming launch of a new set of Cortex processors, due in 2014. The two new chip architectures, dubbed the Cortex-A53 and Cortex-A57, are the most advanced CPUs the British company has ever built, and are integral to AMD's plans to drive dense server applications beginning in 2014. The new ARMv8 architecture adds 64-bit memory addressing, increases the number of general purpose registers to 30, and increases the size of the vector registers for NEON/SIMD operations. The Cortex-A57 and A-53 are both aimed at the mobile market. Partners that've already signed on to build ARMv8-based hardware include Samsung, AMD, Broadcom, Calxeda, and STMicro." The 64-bit ARM ISA is pretty interesting: it's more of wholesale overhaul than a set of additions to the 32-bit ISA.

Comments

Relaunch

[Anonymous Coward]

The 64-bit ARMv8 became available over 12 months ago and no one is making any yet.

Re:Relaunch

[Anonymous Coward]

The 64-bit ARMv8 became available over 12 months ago and no one is making any yet.

That was the instruction set. These are the chip designs.

Re:Relaunch

[TheRaven64]

The first drafts of the ARMv8 architecture became available to a few ARM partners about 4-5 years ago. They've since been working closely with these partners to produce their chips before releasing their own design. The aim was to have third-party silicon ready to ship before anyone started shipping ARM-designed parts to encourage more competition.

ARM intentionally delayed releasing their own designs to give the first-mover advantage to the partners that design their own cores. In the first half of next year, there should be three almost totally independent[1] implementations of the ARMv8 architecture, with the Cortex A50 appearing later in the year. This is part of ARM's plan to be more directly competitive with the likes of Intel. Intel is a couple of magnitudes bigger than ARM, and can afford to have half a dozen teams designing chips for different market segments, including some that never make it to production because that market segment didn't exist by the time the chip was ready. ARM basically has one design, plus a seriously cut-down variant. By encouraging other implementations, they get to have chips designed for everything from ultra-low-power embedded systems (e.g. the Cortex-M0, which ARM licenses for about one cent per chip), through smartphone and tablet processors up to server chips. ARM will produce designs for some of these, and their design is quite modular, so it's relatively easy for SoC makers with the slightly more expensive licenses to tweak it a bit more to fit their use case, and companies like nVidia, TSMC and AMD will fill in the gaps.

The fact that ARM is now releasing their own designs for licensing means that their partners are very close to releasing shipping silicon. We've seen a few pre-production chips from a couple of vendors, but it's nice to see that they're about to hit the market.

[1] ARM engineers consulted on the designs, so there may be some common elements.

Re:Relaunch

[TheRaven64]

It helps if you read what I wrote, rather than pasting random bits out of context. ARM Cortex-A50 chips are likely to appear in 2014 (maybe earlier, but probably not much earlier). ARM partners such as TSMC, nVidia, and Qualcomm, who have been developing their own ARMv8 implementations for the last 3 or so years are due to release production silicon in the first half of next years - they're shipping samples to their partners now.

Re:AMD?

[Anonymous Coward]

I work at a tech company, and almost everyone I know there owns an APU based machine - generally for HTPC uses, or so they say. Yes, it is true that the fastest chips are made by Intel, but when you look at the cost of typical (not high end) machine, AMD is hard to beat, especially when the graphics in and APU will work fine for you.

This is why we need AMD

[elashish14]

Competition drives innovation.

Who knows if this will be successful or not, but a world with AMD is a world with one more innovator bringing fresh, new ideas to the table and trying things that the members of a smaller oligopoly wouldn't.

Re:This is why we need AMD

[game kid]

A world with AMD is also one that uses ARM as a DRM bludgeon. I'm not sure we need that sort of competition.

Re:This is why we need AMD

[jkflying]

Dunno, considering the budget they are working with I'd say getting performance even in the same ballpark as Intel is pretty impressive, especially once you factor in that they are a full process node behind at the fabs. Their multi-threaded top-end speed is the same or faster than Intel, it's only in IPC that they are still behind. Their performance/$ is tied or better.

Re:This is why we need AMD

[Anonymous Coward]

So you're posting this from a Itanium box, right?
Wait, so you got a 64 bit x86 CPU... what was that ISA called again?

Re:ARM builds chips?

[NatasRevol]

Architectures.

It's the last word in the title.

Re:Yay Cortex A-15!

[Pulzar]

Well, ARM designs the IPs that will go into those products... and they are ready to start selling the IP. It takes a couple of years to build SOCs around them, and then to build the devices.

ARM is selling their product now, their customers will announce their products when they are ready. You can't expect them to keep quiet about what they're trying to sell until it's in an actual phone.

A better article at anandtech.com

[IYagami]

Anandtech has a better article:

http://www.anandtech.com/show/6420/arms-cortex-a57-and-cortex-a53-the-first-64bit-armv8-cpu-cores

According to them, ARM Cortex A57 core is a tweaked ARM Cortex A15 core with 64 bit support. And ARM Cortex A53 core is a tweaked ARM Cortex A7 core with 64 bit support. It is possible to mix A57 and A53 cores in the same die to improve efficiency.

What I would like to see is this kind of approach in the x86 world. Imagine having an AMD processor with two fast cores (Piledriver's successor, Steamroller) for heavy processing and two lower cores for longer battery life (Bobcat's successor Jaguar).

Or Intel with their future Haswell and Silvermont architectures...

Re:A better article at anandtech.com

[romiz]

The problem is the static leakage of transistors. It increases as the node width decreases, and for a given node you have two choices to generate a transistor: either high-speed and high-leakage, or low-speed and low-leakage. Even with DVFS enabled, you will have better power results if you use the CPU with the slow transistors than the one with the fast transistors. Hence the switching between two types of cores with different optimizations but executing the same code.

No ARM servers

[Billly Gates]

Lets hope this can keep AMD afloat.

A fortune 500 datacenter can easily cost up to 1 million a year in electricity! I/O, not CPU performance is the bottleneck in most servers so the slower ARM wont make that much a deal. Also a kick ass GPU can improve SuperComputing a lot more than a tweaked out Xeon if AMD can pull it off with a decent graphics for scientific workloads.

Re:No ARM servers

[serviscope_minor]

A fortune 500 datacenter can easily cost up to 1 million a year in electricity!

Yes but...

Datacentres operate with an overhead of between 1.1 and 2 for cooling (i.e. cooling requires between 10% and 100% of the electricity used for compute).

If you're buying $1e6 of electricity per year then you get quite decent rates.

At those price points, the performance per watt, density and bang for buck go head to head.

A quad socket Opteron system gives pretty much the best bang per buck, and some of the highest density per U of any system. You can go better if you get really exotic, like supercomputer level exotic, but even things like those 1024 atoms in 10U get less brute floating point performance per U.

AMD can't match the performance per Watt of the Intel systems. They're quite a way off. But, the AMD systems are waaaaay cheaper. And it's roughly at the point where the lifetime cost of power+cooling is of the same order as the cost of a quad socket 1U machine with a good amount of RAM in it.

It's at the point where performance/$ including all factors is dependent very much on the task at hand. There is no clear winner, and AMD is significantly ahead of intel in some areas.

In order for the ARM machines to be competitive, they can't be super-expensive. If they cost twice the $ per performance then no power savings will be enough. If they're similar, then why go for the ARMs? A quad socket x86 box will provide the same lifetime performance/$ and with much greater flexibility (higher per-thread performance, and larger system image).

Unsurprisingly, it's cheaper and more power efficient to use a large number of single socket machines if you can. The single socket CPUs are cheaper and lower power because they don't need a bunch of fast and expensive hyper transport or quickpath links.

But to get away from commodity motherboards and tons of hackery you get into the realm of eye-wateringly expensive blade servers which struggle to match the density of the 1U quad socket machines, are vastly more expensive and have only moderate power improvements. Oh, and tie you into a single vendor really well to boot.

Re:What a clusterf**k.

[TheLink]

AMD wants them for dense servers. The CPUs are aimed at the mobile market. Wearable servers FTW!

We'll be doing our virtual telepathy and telekinesis using SOAP, Java, XMPP, etc. Maybe they should add hardware acceleration for base64 encode/decode and XML compression/decompression ;).

ARM64 is a mess

[AaronW]

ARM 64's ISA is radically different than ARM32. All of the things that make Arm "ARM" are gone, such as conditional execution, having the program counter as general purpose register and more. Not only that, the binary encoding is totally different. The binary encoding for ARM64 is a total confusing mess compared to ARM32. I wouldn't say that ARM64 was a well designed ISA.

Other processors made much cleaner transitions between 32 and 64-bit such as MIPS, Power/Power PC and Sparc. Even i386 and x86-64 are much closer than ARM32 vs ARM64.

-Aaron

Re:ARM64 is a mess

[tlhIngan]

ARM 64's ISA is radically different than ARM32. All of the things that make Arm "ARM" are gone, such as conditional execution, having the program counter as general purpose register and more. Not only that, the binary encoding is totally different. The binary encoding for ARM64 is a total confusing mess compared to ARM32. I wouldn't say that ARM64 was a well designed ISA.

The binary encodings are a mess, yes, due mostly to the urge to adapt and produce some consistency with the AArch32 instructions. The ARM ABI has seriously evolved and the encoding possibilities are quite... nasty now if you look at ARMv7.

Thankfully, the assembler takes care of that for us.

Conditional execution is nice, but it really interferes with modern architectures. The ARMv8 core is a fully speculative, out-of-order with register renaming implementation. Conditional execution breaks this as the processor has to track more state since any combinations of instructions in the stream could have any combination of conditional execution.

Ditto the PC - it was nice to be able to jump by simply writing to the PC, but man does it complicate internal design if any instruction can arbitrarily move the PC to any register value. In the end, the few uses of conditional execution and the ability to move anything to the PC without using a branch or return style instruction was probably so limited, there was no point.

Oh, and there are 31 registers - X0 through X30. The 32nd register is special depending on the instruction - for ADD and SUB, "X31" means the stack pointer. For most other instructions, it means the zero register (reads as zero), something borrowed from MIPS, and allowing interesting register-only instruction forms to be used when the immediate value is zero. It does result in oddball uses though, like
      SUB SP, 0, X0 ; Set SP.
to play with the stack pointer.

If you're a system level programmer, AArch64 is MUCH nicer (no more damned coprocessors). I know, I've done a fair bit of it.

Re:ARM64 is a mess

[romiz]

Conditional instructions are also available in the AArch64 assembler. But instead of the condition affecting whether the instruction is executed or not as in AArch32, it affects its behaviour. For example, you have the following Aarch64 instruction that can do what cmov does.

CSEL Wd, Wn, Wm, cond ;Wd = if cond then Wn else Wm.

It's more efficient that the AArch32 case, where you have to use two instructions to achieve the same result (MOVcond followed by MOVcondbar)

Re:ARM64 is a mess

[TheRaven64]

All of the things that make Arm "ARM" are gone, such as conditional execution, having the program counter as general purpose register and more

The advantage of conditional instructions is that you can eliminate branches. The conditional instructions are always executed, but they're only retired if the predicates held. ARMv8 still has predicated select instructions, so you can implement exactly the same functionality, just do an unconditional instruction and then select the result based on the condition. The only case when this doesn't work is for loads and stores, and having predicated loads and stores massively complicates pipeline stage interactions anyway, so isn't such a clear win (you get better code density and fewer branches, but at the cost of a much more complex pipeline).

They also have the same set of conditional branches as ARMv7, but because the PC is not a GPR branch prediction becomes a lot easier. With ARMv7, any instruction can potentially be a branch and you need to know that the destination operand is the pc before you know whether it's a branch. This is great for software. You can do indirect branches with a load instruction, for example. Load with the pc as the target is insanely powerful and fun when writing ARM assembly, but it's a massive pain for branch prediction. This didn't matter on ARM6, because there was no branch predictor (and the pipeline was sufficiently short that it didn't matter), but it's a big problem on a Cortex A8 or newer. Now, the branch predictor only needs to get involved if the instruction has one of a small set of opcodes. This simplifies the interface between the decode unit and the branch predictor a lot. For example, it's easy to differentiate branches with a fixed offset from ones with a register target (which may go through completely different branch prediction mechanisms), just by the opcode. With ARMv7, an add with the pc as the destination takes two operands, a register and a flexible second operand, which may be a register, a register with the value shifted, or an immediate. If both registers are zero, then this is a fixed-destination branch. If one register is the pc, then it's a relative branch. Because pretty much any ARMv7 instruction can be a branch, the branch predictor interface to the decoder has two big disadvantages: it's very complex (not good for power) and it often doesn't get some of the information that it needs until a cycle later than one working just on branch and jump encodings would.

Load and store multiple are gone as well, but they're replaced with load and store pair. These give slightly lower instruction density, but they have the advantage that they complete in a more predictable amount of time, once again simplifying the pipeline, which reduces power consumption and increases the upper bound on clock frequency (which is related to the complexity of each pipeline stage).

They've also done quite a neat trick with the stack pointer. Register 0 is, like most RISC architectures, always 0, but when used as the base address for a load or store, this becomes the stack pointer with ARMv8, so they effectively get stack-relative addressing without having to introduce any extra opcodes (e.g. push and pop on x86) or make the stack a GPR.

ARMv8 also adds a very rich set of memory barriers, which map very cleanly to the C[++]11 memory ordering model. This is a big win when it comes to reducing bus traffic for cache coherency. This is a big win for power efficiency for multithreaded code, because it means that it's easy to do the exact minimum of synchronisation that the algorithm requires.

As an assembly programmer, I much prefer ARMv7, but as a compiler writer ARMv8 is a clear win. I spend a lot more time writing compilers than I spend writing assembly (and most people spend a lot more time using compilers than writing assembly). All of the things that they've removed are things that are hard to generate from a compiler (and hard to implement efficiently in silicon) and all of the things that they've added are useful for compilers. It's the first architecture I've seen where it looks like the architecture people actually talked to the compiler people before designing it.

Re:AMD?

[gentryx]

Citation needed.

Re:AMD?

[bemymonkey]

"Yes, it is true that the fastest chips are made by Intel, but when you look at the cost of typical (not high end) machine, AMD is hard to beat, especially when the graphics in and APU will work fine for you."

Interesting... care to give an example? In most cases, I feel I can spec out an Intel based machine for the same price (also using the IGP) that is fast enough for HTPC use and runs cooler and quieter while using half the power... unless you actually need the extra GPU power or the additional cores AMD likes to throw in at the same price point, what's the point in going with AMD? A Sandy Bridge Celeron/Pentium is more efficient and provides enough processing power for any HTPC I've seen.

I'd actually like to start buying AMD again in order to give them some support, but Intel's where the efficiency bang-for-the-buck is at right now... this may be different for those of you who don't pay your own power bill *cough*mom's_basement*cough* :p

Re:Pfff, 64bit ARM. Crusoe was 256bit x86

[Anonymous Coward]

The problem for Transmeta was that no manufacturers understood, or could market a low power laptop or tablet. According to popular magazines at the time, the sort with large intel ad budgets, it was 40% slower than Pentium 4 and therefore a complete and utterly miserable failure that you should avoid like the plague.

The fact that it drew only 3 watts at max load was somehow glossed over.

Re:Yay Cortex A-15!

[Hal_Porter]

Smartphones with >4GB are not that far off. There are a couple of 2GB phones already.

So it's likely that Android will have 64 bit kernel and 32 bit userland before long.

Though you can probably kludge it with something like PAE - i.e. a 32 bit kernel with >32bits of address space.

Re:Yay Cortex A-15!

[dkf]

Concur. ARM is fucked, it's funny people don't see that. They will move back to basically providing only ultra low cost and ultra low power chips. They will see their high end aspirations kicked to the ground, and will be pushed lower and lower in the tablet and mobile phone market over the next 2 years.

ARM's core business is processor cores — CPU layouts to laymen — that other companies can take and add their own extra bits to before manufacturing. It's called System-on-Chip (SOC) and it's an area where Intel doesn't have much of a grasp precisely because it involves giving your design to other companies, letting them modify it by adding stuff, and then manufacture it themselves (or through a third-party). Now, it's hardly surprising that the high-end SOC guys want a larger addressing mode; the forces which pushed desktops also push mobile devices and the like.

What amuses me is the push to e.g. servers. Gee, can I get a server with 1000 cores that's slower in almost every operation than a 16 core Xeon server? Oh, and can you make it useless for virtualizing servers or doing anything but light load trivially parallelizable tasks?

I know a few scientists with tasks to do that are embarrassingly parallel and with far more data than you can shake a whole bushel of sticks at. Being able to stuff even more cores into a rack (where power and cooling are usually the main constraints) is going to be of great interest to them. Whether it will beat out GPUs is the real question though. I expect it will for some workloads (ones with more complex conditional processing in the individual units of processing) but not others. And Intel remains the fastest situations where raw single-threaded power is required, which frankly is a lot of code.

Supercomputing doesn't operate under the same constraints that desktop or normal server computing does. Supercomputer makers try to pack as much computing power in as small a space as possible (because delays effectively due to the speed of light are quite a significant problem otherwise). All too often, the main challenge with a supercomputer is stopping it from cooking itself and setting fire to the building...

Re:Yay Cortex A-15!

[Hal_Porter]

I think ARM is very safe in mobile devices. It's low power consumption most ARM chipsets have video acceleration, so it can still play HD video. It's licensable too, which is handy for SoCs. Also the cores are tiny.

Moving to Atom would give phones more CPU power but I'm not convinced there is much need for it. I've got an Samsung Galaxy S2 and it's not like there is anything I do that is CPU bound. Smartphones have poor battery life already though, and a move to x86 is going to make that worse.

Now Intel are talking about licensing Atom, but I think they face an uphill battle. ARM's mix of low thermal power/low CPU power compared to x86 and small licensable cores aimed at TSMC is basically ideal for people like Samsung, Qualcomm and so on. In fact Qualcomm have spent a lot of money developing their own microarchitecture for ARM - the Snapdragon and Krait cores. If they moved to x86 they would not be able to do that. NVidia are obviously graphics focussed. So it's hard to see the ARM SoC vendors switching to Intel.

Of course Intel is safe in servers and laptops because there you do need x86 compatibility and more horsepower even at the cost of a higher power consumption.

Re:Yay Cortex A-15!

[dkf]

I will take the opposing view, which I call "reality". Intel is a full process level ahead and 14nm is coming in a little over a year. They are dominant in manufacturing, that helps a _lot_. Remind me what the A6X was manufactured at? Oh, yeah - 32nm. Maybe late next year we'll see 20nm ARM chips...maybe.

Your ignorance is fascinating. Intel are the biggest single manufacturer, yes, but ARM sells to nearly every other manufacturer. It's a different business model. Let's emphasize that for you: ARM are fab-less; they don't manufacture themselves. A consequence of this is that the process scales for ARM are usually a lot larger, and that's because the non-Intel manufacturers are a generation or two behind. (Intel spends a lot on staying ahead on that front.) But that's OK; the other manufacturers are usually using those ARM cores to produce SOC, that is, a CPU plus extra bits for a specific application (such as hardware for doing 4G mobile comms or video stream processing). Specialist hardware beats a general CPU in the application for which that specialist hardware was designed, which shouldn't be a surprise (it's been true for as far back as I can think).

I'll bet that ARM will only really start worrying about Intel at the point when Intel start trying to sell high-performance CPU cores for SOC use together with the right to use Intel's own fabs to make the resulting parts. Or if Intel start helping other companies to tech up to an equivalent level so as to be able to make parts at the same scale as Intel. Also known as a cold day in hell; that's totally alien to Intel's business model. (Heck, if Intel were to help other fabs to be able to make 14nm parts, I'd bet that ARM would happily produce a 14nm core to use with that process...)

Oh, and for the mobile phone market, there's Atom.

Are Intel licensing that to other manufacturers for SOC use? No? Then it's not a real player; cutting the component count at the overall device level is more important than speed to phone makers, as it's cheaper for them like that.

Re:Time to learn..

[TheRaven64]

Itanium was just a recompile. The problem was that the resulting code was then typically very slow, because Itanium is a complete bitch as a compiler target. In contrast, ARMv8 is a beautiful architecture to target. To give you some idea of how easy it is, the ARMv8 back end for LLVM was written entirely by one guy in under a year and already performs well (although there's still room for optimisation). LLVM, GCC and ICC all still suck at producing good code for Itanium, and they have had hundreds of man years of effort thrown at them.

Re:Yay Cortex A-15!

[hattig]

I agree that ARM is safe in mobile and tablets. That doesn't mean that Intel won't get a slice of the market, but I don't think that Intel will ever have the flexibility and price advantages of ARM.

Moving to Atom would give phones more CPU power

That's debatable as well, because Intel only offers a single-core, hyperthreaded Atom at 1.3GHz (with some turbo features), that only performs well in Javascript benchmarks. Quad-core A9s and dual-core A15s are more than competitive, and definitely include far better graphics these days - something that people will make use of (games, UI, etc).

ARM have a product for everyone to license. This also adds 64-bits to the mix, in time for 8GB phones and tablets in 2014/2015.

x86 compatibility in servers - only if your running Windows Server. I haven't seen Microsoft crowing about server sales for quite some time, Linux is really the leader here. And Linux runs on ARM. Java runs on ARM. Perhaps it is only a matter of time... Power consumption is already an issue in data centres...

Re:Patent move?

[TheRaven64]

First, don't conflate the ABI and the ISA. The ABI, the Application Binary Interface, describes things like calling conventions, the sizes of fundamental types, the layout of C++ classes, vtables, RTTI, and so on. It is usually defined on a per-platform (OS-architecture pair) basis. This changes quite infrequently because changing it would break all existing binaries.

The ISA, Instruction Set Architecture, defines the set of operations that a CPU can execute and their encodings. These change quite frequently, but usually in a backwards-compatible way. For example, the latest AMD or Intel chips can still run early versions of MS DOS (although the BIOS and other hardware may be incompatible). ARM maintains backwards compatibility for userspace (unprivileged mode) code. You could run applications written for the ARM2 on a modern Cortex A15 if you had any. ARM does not, however, maintain compatibility for privileged mode operations between architectures. This means that kernels needed porting from ARMv5 to ARMv6, a little bit of porting from ARMv6 to ARMv7 and a fair bit more from ARMv7 to ARMv8. This means that they can fundamentally change the low-level parts of the system (for example, how it does virtual memory) but without breaking application compatibility. You may need a new kernel for the new CPU, but all of the rest of your code will keep working.

Backwards compatible changes happen very frequently. For example, Intel adds new SSE instructions with every CPU generation, ARM added NEON and so on. This is because each new generation adds more transistors, and you may as well use them for something. Once you've identified a set of operations that are commonly used, it's generally a good use of spare silicon to add hardware for them. This is increasingly common now because of the dark silicon problem: as transistor densities increase, you have a smaller proportion of the die area that can actually be used at a time if you want to keep within your heat dissipation limits. This means that it's increasingly sensible to add more obscure hardware (e.g. ARMv8 adds AES instructions) because it's a big power saving when it is used and it's not costing anything when it isn't (you couldn't use the transistors for anything that needs to be constantly powered, or your CPU would catch fire).

Re:Yay Cortex A-15!

[TheRaven64]

What would "IP" mean anyway, with the fact that it is utterly impossible to ever control every single human being and computer you sent a copy to

We're talking about CPU designs. If you copy it illegally, then you have to spend a billion or so dollars on a fab. Or spend a few million to buy some time on someone else's (and hope that they don't check with ARM that you're actually a licensee). Enforcing copyright is pretty much impossible on mass-market goods, but when you're talking about something that has a target market of maybe 100 companies (if you're wildly optimistic) then it's not exactly hard to keep track of them.

And buying the ARM license doesn't just get you their core design. It also gets you access to their simulator and their (immense) verification suite, so that you can check if any of the modifications that you made broke compatibility with anything. And, most importantly, it gets you time with ARM engineers. If someone from Qualcomm or TI has a question about any aspect of the ARM architecture, they can get the engineer who designed that part on the phone almost immediately and they can probably get him put on a plane and sent over to them for a week quite quickly if they want more time. ARM doesn't just license their designs, they also license their expertise. ARM engineers spent a lot of time working with nVidia on their upcoming ARMv8 core, for example.

Re:Yay Cortex A-15!

[Hal_Porter]

It's interesting I'm typing this on a netbook. That's got an Atom N570 a 1.6Ghz dual core, in order hyperthreaded CPU. My phone has dual core Cortex A9s which are 1.2Ghz out of order and single issue.

If you'd have said five years ago that Arm would go out of order and Intel would go in order, I'd have thought it was absurd. Then again you're comparing the (then) slowest Atom with the (then) fastest Arm.

According to this

http://www.7-cpu.com/

An Atom N270 at 1.6Ghz with two threads gets a score of 1000 MIPS Compressing and 1500 MIPS Decompressing.

An Exynos 4210 at 1.2Ghz with 4 threads gets 1380 MIPS Compressing and 2130 MIPS Decompressing.

Unfortunately there's no result for an N570 but judging by the other results doubling up the number of cores should make it a bit faster than the Exynos 4210. Still it's probably quite close. Which is remarkable actually - the Exynos uses slow mobile SDRAM and the Atom uses DDR2.

Re:Yay Cortex A-15!

[Anonymous Coward]

Its a hell of a lot easier for Intel, who already has insane levels of IPC, to scale down and have low power chips than it is for ARM to scale up and not blow their power budgets

[Citation required]

Intel have insane levels of IPC because they use insane amounts of power. IPC and power are correlated, yeah? It takes power to run all those parallel circuits that can look ahead in the instruction stream and provide high IPC. The laws of physics work the same way for Intel as they do for ARM. So, why is it easier to scale down than scale up? ARM's major advantage is they don't have to spend power decoding the x86 instruction set. Unless Intel are proposing a new ISA, which they're not, they are always going to have lower feasible performance per Watt. Basic physics. And performance per Watt is what matters on mobile, not IPC. The funny thing is, this is beginning to matter in the server space too. So far from Intel significantly eating into ARM's mobile market, ARM are going to start eating into Intel's server market. For desktops, IPC is way more important than performance per Watt, so Intel are safe for the foreseeable future.

As for "dark silicon", that's Intel main trick for reducing power consumption, so it's a funny argument to make against ARM.

Re:Yay Cortex A-15!

[RaceProUK]

ARM is fucked

Of course they are. Their immense popularity in mobile phones and tablets, and their presence in both the DS and 3DS is such a sign of failure. Attracting enough attention fro Microsoft to port Windows to ARM is also a sign of massive failure.

Have I broken your sarcasm detector yet?

Re:Yay Cortex A-15!

[marcosdumay]

and for a bit more $ and Watts you can get a much faster x86/x64 chip.

Or, in ither words, for some less batery life, you can get a computer that performs faster (notice that price doesn't even enter the equation). That may seem like a deal for you, but it is not for lots and lots of people.

The netbooks and servers market is already owned by Intel, ARM can't lose it (they can only gain market share there). Weight and batery life are two of the most important features of a tablet (only comparable to screen size/definition, and OS), it is a tough market for hungry chips.

Most people that claim that ARM is dead arguee that Intel will outinvest them, and consequently get the best portable chip once they start trying. That can't be proven false. But your argument doesn't hold any water.

Re:Yay Cortex A-15!

[TheRaven64]

That depends. If you market it as an ARM core without passing their compatibility test suite, then they'd be very unhappy. Similarly, if you violated any of their patents. But read the rest of my post: the point is that the number of potential customers is small. We actually have an ARMv7 implementation that runs in an FPGA that ARM knows about. They're quite happy with it, because it gives our students experience working with their architecture. There's a fairly widely distributed design from Edinburgh that is very ARM-like, but omits some of the harder bits, and again ARM is fine with it because it uses a different name.

Re:ARM builds chips?

[rwise2112]

Architectures.

It's the last word in the title.

So I'm suposed to read the whole title now!