7 ms·

It's really a shame how AMD's per-thread performance has been lagging Intel. Maybe it's just their postition as an also-ran in a basically monopolized market (d

It's really a shame how AMD's per-thread performance has been lagging Intel. Maybe it's just their postition as an also-ran in a basically monopolized market (desktop CPU manufacture), but I've always seen them as ahead of the curve. They were optimizing per-cycle performance with Athlon while Intel was still pushing higher clocks. They moved to 64-bit while Intel was still pushing higher clocks. Now that Intel has turned their attention more fully to optimizing their per-clock performance (and pulled ahead by a full generation in fab technology), AMD hasn't really had a leg to stand on. Price and low-power are OK, but ARM is already strong in those areas, and ARM servers are becoming more likely by the year. AMD needs something more transformative than massively-parallel chips and high frequencies. I know it's a long shot, but could they try to go the way Intel did with Itanium, and invent a new architecture/instruction set specifically designed for server workloads? People have broadly expressed interest in ARM, but the support isn't there right now. If AMD had a new RISC architecture with awesome support and incentives for developers to target it, they might be able to steal share from x64 and ARM chips.

wtallis 14y ago
AMD has already announced that they'll be selling ARM chips under the Opteron brand. They're going to be used in SeaMicro servers.
- alanctgardner2 14y ago
  I have heard about this, but AMD really needs to throw their weight behind getting important software stacks onto ARM. If they can't convince big players to ship ARM builds of software, they're not going to get the kind of market share they need.
  - SwellJoe 14y ago
    Linux already runs on ARM, and there are multiple distros that support it. Most of the web runs on Linux, Apache, MySQL, and PHP/Python/Ruby/Perl, all of which run fine on ARM. I'd say that's a sizable server market that would already be happy on an ARM server. I would be. We run nothing on our servers that doesn't already compile on ARM. Then again, we've just switched to an entirely virtualized infrastructure running under KVM a few months ago, and ARM doesn't really have much in the way of hypervisor support. So, I guess there is some part of the software stack that ARM won't work for.
    - wtallis 14y ago
      There's KVM paravirtualization support for ARM, and the Cortex-A15 supports hardware virtualization (and probably all the 64-bit ARM processors will, too).
    - alanctgardner2 14y ago
      It's fine for people who administer their whole stack themselves, but companies like Red Hat don't seem to be on board yet (their website only mentions embedded applications as far as I can see). Compiling open source software against a platform is the easy part; most places don't want to deploy their own build of Apache. Intel has also spent considerable resources contributing patches and optimizing compilers for their platform. If AMD wants to move large clients off x64, they can't just say 'Well, look, Perl compiles'. They need consulting shops onboard, they need large, well-tested repositories of Linux packages.
      - SwellJoe 14y ago
        Debian, Ubuntu, and several other distros have ARM builds. It's not a matter of saying, "Oh, you can compile it yourself." It's just a matter of saying, "Use one of these extremely popular distributions." Fedora is available for ARM, which means RHEL and CentOS almost certainly aren't far behind. There's also a port of RHEL to ARM called Red Sleeve, which means most of the hard work of a port has already been done. Given that the potential cost savings are pretty big in a large data center, I suspect we'll start seeing deployments pretty soon, and the pressure on Red Hat to provide ARM will grow. I'm not really arguing with you, per se. There are plenty of people who won't make the jump until Red Hat does. But, there are plenty of people who take their cues from other providers.
      - TillE 14y ago
        Gentoo has always been aggressively multiplatform. I know there are other distros which run on ARM as well, but I don't know how clean their solutions are. Anyway, hardware availability is an important prerequisite. Sure everything mobile uses ARM, so the Linux kernel is in good shape. But once there's cheap server hardware available, more work will be done on the distros.
ck2 14y ago
I just hope AMD doesn't go away or Intel pricing is going to go through the roof (again). If you can settle for "only" 2ghz, you can get a 16-core AMD 6366HE for $600 ($38 a core) Bring on the price wars.
- miahi 14y ago
  6366HE has a base frequency of 1.8GHz, with 2.3/3.1 turbo. For the same money you can get a six core Intel E5-2630 (2.3/2.8GHz). The benchmarks [1] say the Vishera (desktop Piledriver) has about 50% of the Intel performance per core at the same frequency, so unfortunately the 6-core Intel is roughly equivalent to the 16-core AMD. [1] http://wccftech.com/amd-vishera-fx8350-x86-piledriver-pitted-fx8150-cpu-benchmarks/ http://wccftech.com/amd-vishera-fx8350-x86-piledriver-pitted...
  - ck2 14y ago
    The 8350 and 8150 are 8-core, not 16-core, is that throwing off the math?
  - velodrome 14y ago
    Doesn't AMD have advantage for cloud/VM workloads? They have more (but slower) cores...
    - eropple 14y ago
      The answer is, of course, "it depends." Heavily threaded floating-point workloads, for example, will see a ton of contention and performance degradation on the 6200-series Piledrivers because there's one floating-point unit for every processing core. The 6100 series doesn't have this limitation, but IIRC they still have some perf wonkiness on some loads. There are also power concerns with the AMD stuff, which matters a lot more in data centers/"cloud" environments than it necessarily does in a desktop.
    - miahi 14y ago
      All the cores fight for the same memory bandwidth. VMs do many context switches and cache invalidations.
glhaynes 14y ago
As someone who has little idea about chip design: is there that much room for benefit purely from instruction set? i.e. if someone were to design the Optimum Instruction Set [and perhaps it'd have to be optimum in only some types of workloads at the expense of others?] and start building chips with it, how much advantage would they really have over, say, x64? Maybe a good question to go alongside this: if two teams of equal capability with equal access to fabs, patents, etc were to both start completely fresh, one team making the best x64 chip they could and one team making the best ARM chip they could, how much difference would there be in speed and power-consumption between the end products?
- alanctgardner2 14y ago
  The thing is, CISC vs. RISC seems to be an ideological debate more than anything else. The only reason I suggested designing a RISC CPU is because a) ARM has made RISC for servers sexy again, and b) Intel already tried a CISC chip with Itanium, and another would scare vendors pretty badly. The big difficulty I see is designing an instruction set, architecture and compiler which can show serious performance gains for workloads that matter. Making it easy for developers to come over from x64 while juicing the performance per clock would be a big win. P.S. I'm not a CPU expert by any means. My understanding is that x86_64 has a big legacy overhead from implementing backwards compatibility with x86, and a goal of Itanium was to reduce the amount of the die dedicated to backwards compatibility. If anyone wants to correct me, feel free.
  - haberman 14y ago
    I don't think Itanium was CISC, they call it "EPIC" (explicitly parallel instruction computing: http://en.wikipedia.org/wiki/Explicitly_parallel_instruction_computing http://en.wikipedia.org/wiki/Explicitly_parallel_instruction...). The basic idea of this was to move logic about what could be parallelized from the CPU to the compiler, but this turned out not to work so well. In Donald Knuth's words, "The Itanium approach...was supposed to be so terrific—until it turned out that the wished-for compilers were basically impossible to write."
- ComputerGuru 14y ago
anonymfus 14y ago
>It's really a shame how AMD's per-thread performance has been lagging Intel. Are you sure that you don't mix it with single-thread performance or per-core performance?
- astrodust 14y ago
  It's based on "thread" meaning "execution channel" which is usually core or, in the case of Hyper-Thread, a portion of a core.
sp332 14y ago
AMD just released an 8-core, 4.0 GHz processor that keeps up somewhat better on single-threaded tasks (while matching or beating a Core i7 on multithreading!), for only $200. http://www.anandtech.com/show/6396/the-vishera-review-amd-fx8350-fx8320-fx6300-and-fx4300-tested/7 http://www.anandtech.com/show/6396/the-vishera-review-amd-fx... "Through frequency and core level improvements, AMD was able to deliver a bit more than the 10 - 15% performance increased [it] promised... Thankfully, Vishera does close the gap by a decent amount and if AMD extends those gains it is on an intercept course with Intel. The bad news is, that intercept wouldn't be in 2013... Steamroller [will be] far more focused on increasing IPC, however without a new process node it'll be difficult to demonstrate another gain in frequency like we see today with Vishera. I suspect the real chance for AMD to approach parity in many of these workloads will be with its 20nm architecture, perhaps based on Excavator in 2014."
- bunderbunder 14y ago
  Sadly, though, the previous page in that same review shows that the power consumption gap remains wide. With desktop PCs continuing to lose popularity, and small form factors being popular with the desktops that are selling, that's going to be a much bigger problem for AMD going forward than their single-thread performance is.
  - deleted 14y ago
    [deleted]
bitteralmond 14y ago
Hear hear! AMD's always been pushing the limits, Intel cleaning up afterwards and making more stable chips based on AMD's innovations.

wtallis 14y ago

AMD has already announced that they'll be selling ARM chips under the Opteron brand. They're going to be used in SeaMicro servers.

alanctgardner2 14y ago
I have heard about this, but AMD really needs to throw their weight behind getting important software stacks onto ARM. If they can't convince big players to ship ARM builds of software, they're not going to get the kind of market share they need.
- SwellJoe 14y ago
  Linux already runs on ARM, and there are multiple distros that support it. Most of the web runs on Linux, Apache, MySQL, and PHP/Python/Ruby/Perl, all of which run fine on ARM. I'd say that's a sizable server market that would already be happy on an ARM server. I would be. We run nothing on our servers that doesn't already compile on ARM. Then again, we've just switched to an entirely virtualized infrastructure running under KVM a few months ago, and ARM doesn't really have much in the way of hypervisor support. So, I guess there is some part of the software stack that ARM won't work for.
  - wtallis 14y ago
    There's KVM paravirtualization support for ARM, and the Cortex-A15 supports hardware virtualization (and probably all the 64-bit ARM processors will, too).
  - alanctgardner2 14y ago
    It's fine for people who administer their whole stack themselves, but companies like Red Hat don't seem to be on board yet (their website only mentions embedded applications as far as I can see). Compiling open source software against a platform is the easy part; most places don't want to deploy their own build of Apache. Intel has also spent considerable resources contributing patches and optimizing compilers for their platform. If AMD wants to move large clients off x64, they can't just say 'Well, look, Perl compiles'. They need consulting shops onboard, they need large, well-tested repositories of Linux packages.
    - SwellJoe 14y ago
      Debian, Ubuntu, and several other distros have ARM builds. It's not a matter of saying, "Oh, you can compile it yourself." It's just a matter of saying, "Use one of these extremely popular distributions." Fedora is available for ARM, which means RHEL and CentOS almost certainly aren't far behind. There's also a port of RHEL to ARM called Red Sleeve, which means most of the hard work of a port has already been done. Given that the potential cost savings are pretty big in a large data center, I suspect we'll start seeing deployments pretty soon, and the pressure on Red Hat to provide ARM will grow. I'm not really arguing with you, per se. There are plenty of people who won't make the jump until Red Hat does. But, there are plenty of people who take their cues from other providers.
    - TillE 14y ago
      Gentoo has always been aggressively multiplatform. I know there are other distros which run on ARM as well, but I don't know how clean their solutions are. Anyway, hardware availability is an important prerequisite. Sure everything mobile uses ARM, so the Linux kernel is in good shape. But once there's cheap server hardware available, more work will be done on the distros.

ck2 14y ago

I just hope AMD doesn't go away or Intel pricing is going to go through the roof (again). If you can settle for "only" 2ghz, you can get a 16-core AMD 6366HE for $600 ($38 a core) Bring on the price wars.

miahi 14y ago
6366HE has a base frequency of 1.8GHz, with 2.3/3.1 turbo. For the same money you can get a six core Intel E5-2630 (2.3/2.8GHz). The benchmarks [1] say the Vishera (desktop Piledriver) has about 50% of the Intel performance per core at the same frequency, so unfortunately the 6-core Intel is roughly equivalent to the 16-core AMD. [1] http://wccftech.com/amd-vishera-fx8350-x86-piledriver-pitted-fx8150-cpu-benchmarks/ http://wccftech.com/amd-vishera-fx8350-x86-piledriver-pitted...
- ck2 14y ago
  The 8350 and 8150 are 8-core, not 16-core, is that throwing off the math?
- velodrome 14y ago
  Doesn't AMD have advantage for cloud/VM workloads? They have more (but slower) cores...
  - eropple 14y ago
    The answer is, of course, "it depends." Heavily threaded floating-point workloads, for example, will see a ton of contention and performance degradation on the 6200-series Piledrivers because there's one floating-point unit for every processing core. The 6100 series doesn't have this limitation, but IIRC they still have some perf wonkiness on some loads. There are also power concerns with the AMD stuff, which matters a lot more in data centers/"cloud" environments than it necessarily does in a desktop.
  - miahi 14y ago
    All the cores fight for the same memory bandwidth. VMs do many context switches and cache invalidations.

glhaynes 14y ago

As someone who has little idea about chip design: is there that much room for benefit purely from instruction set? i.e. if someone were to design the Optimum Instruction Set [and perhaps it'd have to be optimum in only some types of workloads at the expense of others?] and start building chips with it, how much advantage would they really have over, say, x64? Maybe a good question to go alongside this: if two teams of equal capability with equal access to fabs, patents, etc were to both start completely fresh, one team making the best x64 chip they could and one team making the best ARM chip they could, how much difference would there be in speed and power-consumption between the end products?

alanctgardner2 14y ago
The thing is, CISC vs. RISC seems to be an ideological debate more than anything else. The only reason I suggested designing a RISC CPU is because a) ARM has made RISC for servers sexy again, and b) Intel already tried a CISC chip with Itanium, and another would scare vendors pretty badly. The big difficulty I see is designing an instruction set, architecture and compiler which can show serious performance gains for workloads that matter. Making it easy for developers to come over from x64 while juicing the performance per clock would be a big win. P.S. I'm not a CPU expert by any means. My understanding is that x86_64 has a big legacy overhead from implementing backwards compatibility with x86, and a goal of Itanium was to reduce the amount of the die dedicated to backwards compatibility. If anyone wants to correct me, feel free.
- haberman 14y ago
  I don't think Itanium was CISC, they call it "EPIC" (explicitly parallel instruction computing: http://en.wikipedia.org/wiki/Explicitly_parallel_instruction_computing http://en.wikipedia.org/wiki/Explicitly_parallel_instruction...). The basic idea of this was to move logic about what could be parallelized from the CPU to the compiler, but this turned out not to work so well. In Donald Knuth's words, "The Itanium approach...was supposed to be so terrific—until it turned out that the wished-for compilers were basically impossible to write."
ComputerGuru 14y ago

anonymfus 14y ago

>It's really a shame how AMD's per-thread performance has been lagging Intel. Are you sure that you don't mix it with single-thread performance or per-core performance?

astrodust 14y ago
It's based on "thread" meaning "execution channel" which is usually core or, in the case of Hyper-Thread, a portion of a core.

sp332 14y ago

AMD just released an 8-core, 4.0 GHz processor that keeps up somewhat better on single-threaded tasks (while matching or beating a Core i7 on multithreading!), for only $200. http://www.anandtech.com/show/6396/the-vishera-review-amd-fx8350-fx8320-fx6300-and-fx4300-tested/7 http://www.anandtech.com/show/6396/the-vishera-review-amd-fx... "Through frequency and core level improvements, AMD was able to deliver a bit more than the 10 - 15% performance increased [it] promised... Thankfully, Vishera does close the gap by a decent amount and if AMD extends those gains it is on an intercept course with Intel. The bad news is, that intercept wouldn't be in 2013... Steamroller [will be] far more focused on increasing IPC, however without a new process node it'll be difficult to demonstrate another gain in frequency like we see today with Vishera. I suspect the real chance for AMD to approach parity in many of these workloads will be with its 20nm architecture, perhaps based on Excavator in 2014."

bunderbunder 14y ago
Sadly, though, the previous page in that same review shows that the power consumption gap remains wide. With desktop PCs continuing to lose popularity, and small form factors being popular with the desktops that are selling, that's going to be a much bigger problem for AMD going forward than their single-thread performance is.
- deleted 14y ago
  [deleted]

bitteralmond 14y ago

Hear hear! AMD's always been pushing the limits, Intel cleaning up afterwards and making more stable chips based on AMD's innovations.