AMD Announces First ARM Processor

MojoKid writes "AMD's Andrew Feldman announced today that the company is preparing to sample its new eight-core ARM SoC (codename: Seattle). Feldman gave a keynote presentation at the fifth annual Open Compute Summit. The Open Compute Project (OCP) is Facebook's effort to decentralize and unpack the datacenter, breaking the replication of resources and low volume, high-margin parts that have traditionally been Intel's bread-and-butter. AMD is claiming that the eight ARM cores offer 2-4x the compute performance of the Opteron X1250 — which isn't terribly surprising, considering that the X1250 is a four-core chip based on the Jaguar CPU, with a relatively low clock speed of 1.1 — 1.9GHz. We still don't know the target clock speeds for the Seattle cores, but the embedded roadmaps AMD has released show the ARM embedded part actually targeting a higher level of CPU performance (and a higher TDP) than the Jaguar core itself."

Comments

Despite it's name

[dbIII]

Jaguar is for tablets and seems to be designed for price point and not speed. That's why they are comparing it with the ARM stuff and not using an Opteron 6386 as a comparison.

Re:Despite it's name

[hairyfeet]

Which is why I don't get this chip. After all they have the Jaguar for ULV applications, Opteron for when you need more horsepower, what good are these ARM units?

And I'm sorry ARM fans but as we keep seeing ARM just doesn't scale, you bump up the IPC and you blow the power budget, which is why I've been saying for awhile that days of "ARM Mania" will be quickly coming to an end. Folks want their handhelds to perform like an HTPC in their pocket and that means high instructions per second which ARM can't do without blowing through the power. This is why Nvidia is up to 5 cores, Samsung to 6, because ARM just doesn't scale. Its gonna be easier for AMD and Intel to cut X86 down with jaguar and Atom than it is to get ARM to scale.

So I just don't get what the market for this is exactly. Most server code is X86 anyway, be it wintel or Linux, so you are talking about some serious expense porting it over and with jaguar on the low end and Opteron on the high? Well i just don't see a huge market for ARM servers, am I missing something?

Re:Despite it's name

[MrEricSir]

Jaguar is for tablets and seems to be designed for price point and not speed. That's why they are comparing it with the ARM stuff and not using an Opteron 6386 as a comparison.

The question is whether Jaguar itself is really 64-bit, or if it's just the graphics processor that's 64-bit and the rest is 32-bit.

Re:Despite it's name

[Billly Gates]

Microsoft supports Windows, IIS, SQL Server, and Exchange on ARM. Linux and its FOSS supports ARM as well. I believe RHES has an openJDK for java apps to run on ARM servers too.

Besides a few niche apps I really do not see the application compatibility problem.

It is not like these are used to run win32 desktop apps.

Re:Despite it's name

[LordLimecat]

Its not x86 today, which kind of makes me think you have no idea what youre talking about.

opting for a horrible stack based approach.

Im not one to argue architectural advantages, but id point out that both of the top two cpu manufacturers chose the same instruction set. Noone else has been able to catch the pair of them in about a decade.

Re:Despite it's name

[gmhowell]

Where you even came up with an idea like that is beyond me.

Obviously. BTW, isn't tonight a school night, kid?

Re:Despite it's name

[gbjbaanb]

its unfortunate, but sometimes the best way to drive a screw into a piece of wood is just to keep smashing at it with bigger and bigger hammers.

I guess this approach is what Intel and AMD have been doing with x86.

Re:Despite it's name

[fuzzyfuzzyfungus]

Write once, debug in some places, abandon all hope elsewhere...

Re:Despite it's name

[evilviper]

Your criticisms are probably quite apt for a 286 process. Some might be relevant to 686 processors too... But they make no sense in a world that has switched to x86-64.

The proprietary processor wars are over. Alpha and Vax are dead. PA-RISC is dead. MIPS has been relegated to the low-end. SPARC is slowly drowning. And even Itanium's days are severely numbered. Only POWER has kept pace, in fits and starts, and for all the loud press, ARM is only biting at x86's ankles.

    x86 has been shown able to not just keep pace but outclass every other architecture. Complain about CISC all you want, but the instruction complexity made it easy to keep bolting on more instructions... From MMX to SSE3 and everything in-between. The complaints about idiosyncracies are quite important to the 5 x86 ASM programmers out there, and compilier writers, and nobody else.

I wouldn't mind a future where MIPS CPUs overtake x64, but any debate about the future of processors ended when AMD skillfully managed the 64-bit transition, and they and Intel killed off all the competition. With CPU prices falling to a pittance, and no heavy computational loads found for the average person, there's no benefit to be had, even in the wildest imagination, of switching the PC world to a different architecture, painful transition or no.

Re:Despite it's name

[fuzzyfuzzyfungus]

I have no love for Android; but there is one major difference between Intel's latest and assorted ARM:

Has Intel managed to cram some impressive x86 punch into ever lower power envelopes? Yes, yes indeed. Are they the only game in town, period, if you want reasonably speedy x86s at low power? Yes, unfortunately so. And, to the degree that the threat from iPads and the like doesn't keep them in check, prices reflect that.

ARM, by contrast, lacks some punch and a lot of legacy software; but approximately a zillion vendors using undistinguished foundry processes can achieve decent results at low power. Prices reflect this.

So long as ARM remains a looming threat, Intel will price their parts such that they (by virtue of Intel's unquestioned technical prowess) are very, very, compelling. If ARM shows any signs of weakness, it'll be back to the early Pentium M days, when Intel pretended that the 'Pentium 4 Mobile' was good enough, and that a Pentium M deserved a massive price premium. Not fun, at all.

Re:Despite it's name

[DrXym]

Most server code? Most server code is Java, Python, PHP or some other abstraction running over the hardware. Providing the runtime exists to support the abstraction it is largely irrelevant what architecture is powering it. I expect that operations that are already using Linux or some other Unix variant are well positioned to jump over. Windows based operations, not so much though Microsoft are in the cloud computing space too and this might motivate them to support ARM.

Why companies might do choose ARM really depends not on whether it is faster than Intel CPUs, but whether it is fast enough for the task at hand, and better in other regards such as power consumption, cooling, rack space etc. Google, Facebook, Amazon et al run enormous data centers running custom boot images and have teams capable of producing images for different architectures. This would seem to be the market that AMD is targeting.

Re:Despite it's name

[Alioth]

ARM scales fine (in another way). Sophie Wilson (one of the ARM's original developers) indeed said that ARM wouldn't be any better today than x86 in terms of power per unit of computing done. However, an advantage ARM has for parallelizable workloads is you can get more ARM cores onto a given area of silicon. Just the part of an x86 that figures out how long the next instruction is is the size of an entire ARM core, so if you want lots of cores this will count for something (for example, the Spinnaker research project at Manchester University uses absurd numbers of ARM cores).

Re:ARM processing

[ne0n]

I believe you've read it wrong. Basically, AMD actually traveled back in time to develop the first ARM processor.

x86 IS efficient

[Crass Spektakel]

Actually x86 IS efficient for for something completely different. The architecture itself is totally unimportant as deep inside it is yet another micro code translator and doesn't differ significantly from PPC or Sparc nowadays.

x86 short instructions allow for highly efficient memory usage and for a much, much, much higher Ops per Cycle. This is just that big of a deal that ARM has created a short command version of ARM opcodes just to close in. But then this instruction set is totally incompatible and also totally ignored.

Short instructions do not matter on slow architectures like todays ARM world. These just want to safe power and therefore it fits in well that ARM also is a heavy user of slow in-order-execution.

A nice example, increasing a 64 bit register in x86 takes ONE byte and recent x86 CPUs can run this operation on different register up to 100 times PER CYCLE, all commands to be loaded in THREE to EIGHT Cycles from memory to cache. On the other hand, the same operation on ARM takes 12 bytes for a single increment operation, to load some dozend of these operations would take THOUSANDS of clock cycles.

And now you know why high end x86 is 20-50 times faster than ARM.

Re:x86 IS efficient

[luminousone11]

1 byte?, you have no idea what you are talking about. AMD64 has a prefix byte before first op code byte, so in 64bit mode no instruction is smaller then 2bytes, Also 64bit arm is a new instruction set, and it does not in any way resemble 32bit arm. The fact is 64bit ARM, looks much more CISC'y then 32bit ARM, providing access to multiple address modes for load instructions, integrating the SIMD instructions rather then using costly co-processor extensions, having lightly variable length instructions, dedicated stack register and access instructions, And in a huge break from prior arm instruction sets they drop the conditional execution instructions from the instruction set. And it manages to increase the register count from 16 to 32 to boot as well. ARM has a bright future, It is not forced to waste huge swaths of transistors on decoding stupidly scatter brained instruction encodings built from 40 years of stacking shit on top of shit.

Re:x86 IS efficient

[TheRaven64]

Actually x86 IS efficient for for something completely different. The architecture itself is totally unimportant as deep inside it is yet another micro code translator and doesn't differ significantly from PPC or Sparc nowadays.

This is true, unless you care about power. The decoder in an x86 pipeline is more accurately termed a parser. The complexity of the x86 instruction set adds 1-3 pipeline stages relative to a simpler encoding. This is logic that has to be powered all of the time (except in Xeons, where they cache decoded micro-ops for tight loops and can power gate the decoder, reducing their pipeline to something more like a RISC processor, but only when running very small loops).

x86 short instructions allow for highly efficient memory usage and for a much, much, much higher Ops per Cycle.

It is more efficient than ARM. My tests with Thumb-2 found that IA32 and Thumb-2 code were about the same density, plus or minus 10%, with neither a clear winner. However, the Thumb-2 decoder is really trivial, whereas the IA32 decoder is horribly complex.

This is just that big of a deal that ARM has created a short command version of ARM opcodes just to close in. But then this instruction set is totally incompatible and also totally ignored.

Thumb-2 is now the default for any ARMv7 (Cortex-A8 and newer) compiler, because it always generates denser code than ARM mode and has no disadvantages. Everything else in your post is also wrong, but others have already added corrections to you there.

Re:ARM processing

[Chrisq]

I believe you've read it wrong. Basically, AMD actually traveled back in time to develop the first ARM processor.

No - its making a food processor for cannibals. The design brief was that you should be able to process a whole arm.

Re:Pretty low bar...

[gtall]

And the point is that this is about servers, it doesn't matter if there are more ARM chips selling....you wouldn't compare a smart phone SoC with a server chip.

I've heard arguments on both sides about server stats for ARM vs. Intel servers. Personally, I hope Intel gets kicked in the teeth, but I have yet to see a knock down argument that ARM has what it takes to beat them. There will probably be applications for both were each excels.

Making comparisons now is also somewhat pointless. What's more important are the trajectories of both architectures, and Intel could also try to pull another Itanic, only be successful this time. At that point, attempting to plot trajectories now is pointless because a new Intel architecture is an entirely different trajectory.

Re:Pretty low bar...

[fisted]

ARM chips are currently outselling x86 ships

That doesn't surprise me at all. It might be interesting to have an ARM-powered x86 ship though.