Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AMD's Bulldozer server benchmarks are here, and they're a catastrophe

arstechnica.com

Post reply on HN
Print view View original

11–20 of 29 posts

Re: AMD's Bulldozer server benchmarks are here, and they're a catastrophe

#11

Post by onenine »

DarkShikari wrote: post #10
onenine wrote: post #9

This article is impressively bad. While the 8-module chip does share a few things (mainly a vector processing unit, that becomes two when doing the 128-bit SSE operations) they really can run 16 threads on 16 ALUs. But, they'll have sse contention if they schedule more than 8 256-bit vector operations (sadly intel won't bring this instruction set to market for a bit). Bulldozer is pretty cool, but sadly the tech pres…

While the 8-module chip does share a few things (mainly a vector processing unit And more importantly, the decode and dispatch unit, which only run every other clock for a given core -- thus limiting any given core to a theoretical maximum of a mere 2 IPC, and in practice a lot more than that since the dispatch unit has limitations of its own, nevermind branch mispredictions and such.

I'm not sure what it would look like in the video [d]ecoder world, but I don't think that would matter since most the time you'd want to use the 256-bit vector instructions (in practice this would hardly be a high priority until they're nearly ubiquitous...). For use cases where you are addressing large memory regions this hardly seems like that big of a deal. There are times when you can schedule tons of calculations without leaving L1 but for some odd reason people are finding 500GB+ of RAM useful.

Re: AMD's Bulldozer server benchmarks are here, and they're a catastrophe

#12

Post by DrPizza »

onenine wrote: post #9

This article is impressively bad. While the 8-module chip does share a few things (mainly a vector processing unit, that becomes two when doing the 128-bit SSE operations) they really can run 16 threads on 16 ALUs. But, they'll have sse contention if they schedule more than 8 256-bit vector operations (sadly intel won't bring this instruction set to market for a bit). Bulldozer is pretty cool, but sadly the tech pres…

> This article is impressively bad.

Cheers!

> While the 8-module chip does share a few things (mainly a vector processing unit, that becomes two when doing the 128-bit SSE operations)

A few things? No, it shares a lot of things. The entire floating point and SIMD unit. The entire front-end. The branch predictor is, I believe, a weird hybrid of shared and non-shared. The I-cache, and the L2 cache, also both shared.

The front-end is particularly troublesome. The entire decoder can either service one thread or the other. If both threads need instructions, the best it can do is round robin between them. This averages to allow just two instructions per cycle: less decode bandwidth than K10.

Likewise the integer units: there are fewer ALUs and AGUs per thread than in K10. Likewise the floating point unit. There's lots of sharing, and even the private, non-shared parts are resource-starved.

> But, they'll have sse contention if they schedule more than 8 256-bit vector operations (sadly intel won't bring this instruction set to market for a bit).

SSE contention will occur if a thread can issue more than two SSE operations per cycle, or one AVX operation per cycle.

> Bulldozer is pretty cool, but sadly the tech press decides to shit on the underdog in a market that multiple companies have successfully sued the monopolist for anti-competitive behavior. :(

I don't care about "the underdog" or which is "cool" or which multi-billion dollar corporation you might prefer. I care about which works better. It ain't Bulldozer.

Re: AMD's Bulldozer server benchmarks are here, and they're a catastrophe

#13

Post by DrPizza »

DarkShikari wrote: post #10
onenine wrote: post #9

This article is impressively bad. While the 8-module chip does share a few things (mainly a vector processing unit, that becomes two when doing the 128-bit SSE operations) they really can run 16 threads on 16 ALUs. But, they'll have sse contention if they schedule more than 8 256-bit vector operations (sadly intel won't bring this instruction set to market for a bit). Bulldozer is pretty cool, but sadly the tech pres…

While the 8-module chip does share a few things (mainly a vector processing unit And more importantly, the decode and dispatch unit, which only run every other clock for a given core -- thus limiting any given core to a theoretical maximum of a mere 2 IPC, and in practice a lot more than that since the dispatch unit has limitations of its own, nevermind branch mispredictions and such.

My understanding is that it can give every cycle to a given thread just as long as the other thread doesn't need it to decode anything (if it's idle or whatever). i.e. it can give one thread 4 ops/cycle sustained, given the right workload. But for your purposes, that's probably not any improvement.

Re: AMD's Bulldozer server benchmarks are here, and they're a catastrophe

#14

Post by bad_user »

zdw wrote: post #3

AMD's problem is that they can't compete either in the low power high performance (the 45w and under laptop chips), or high power high performance markets (like the high end Xeons). So they build massively parallel chips, and try new stuff like the Bulldozer platform, which creates a bunch of trade offs. It's very similar in concept to the Sun/Oracle Sparc T-series, with lots of great performing integer cores, and (a…

They did the same thing back in the days of AMD K6 ... fast integer ops, poor floating point. Then AMD Athlon came, built on the same foundation and Intel never knew what hit them.

Don't dismiss Bulldozer just yet. AMD has this uncanny ability to make short term compromises that benefit them in the long term.

Re: AMD's Bulldozer server benchmarks are here, and they're a catastrophe

#15

Post by apu »

DrPizza wrote: post #12
onenine wrote: post #9

This article is impressively bad. While the 8-module chip does share a few things (mainly a vector processing unit, that becomes two when doing the 128-bit SSE operations) they really can run 16 threads on 16 ALUs. But, they'll have sse contention if they schedule more than 8 256-bit vector operations (sadly intel won't bring this instruction set to market for a bit). Bulldozer is pretty cool, but sadly the tech pres…

> This article is impressively bad. Cheers! > While the 8-module chip does share a few things (mainly a vector processing unit, that becomes two when doing the 128-bit SSE operations) A few things? No, it shares a lot of things. The entire floating point and SIMD unit. The entire front-end. The branch predictor is, I believe, a weird hybrid of shared and non-shared. The I-cache, and the L2 cache, also both shared. Th…

Are you the author?

Re: AMD's Bulldozer server benchmarks are here, and they're a catastrophe

#16

Post by DrPizza »

apu wrote: post #15
DrPizza wrote: post #12

Earlier quoted context omitted.

> This article is impressively bad. Cheers! > While the 8-module chip does share a few things (mainly a vector processing unit, that becomes two when doing the 128-bit SSE operations) A few things? No, it shares a lot of things. The entire floating point and SIMD unit. The entire front-end. The branch predictor is, I believe, a weird hybrid of shared and non-shared. The I-cache, and the L2 cache, also both shared. Th…

Are you the author?

Yes.

Re: AMD's Bulldozer server benchmarks are here, and they're a catastrophe

#18

Post by DarkShikari »

onenine wrote: post #11
DarkShikari wrote: post #10

Earlier quoted context omitted.

While the 8-module chip does share a few things (mainly a vector processing unit And more importantly, the decode and dispatch unit, which only run every other clock for a given core -- thus limiting any given core to a theoretical maximum of a mere 2 IPC, and in practice a lot more than that since the dispatch unit has limitations of its own, nevermind branch mispredictions and such.

I'm not sure what it would look like in the video [d]ecoder world, but I don't think that would matter since most the time you'd want to use the 256-bit vector instructions (in practice this would hardly be a high priority until they're nearly ubiquitous...). For use cases where you are addressing large memory regions this hardly seems like that big of a deal. There are times when you can schedule tons of calculation…

since most the time you'd want to use the 256-bit vector instructions

There are no 256-bit integer vector instructions on x86, and AVX is slower than SSE on Bulldozer.

Re: AMD's Bulldozer server benchmarks are here, and they're a catastrophe

#19

Post by DarkShikari »

DrPizza wrote: post #13
DarkShikari wrote: post #10

Earlier quoted context omitted.

While the 8-module chip does share a few things (mainly a vector processing unit And more importantly, the decode and dispatch unit, which only run every other clock for a given core -- thus limiting any given core to a theoretical maximum of a mere 2 IPC, and in practice a lot more than that since the dispatch unit has limitations of its own, nevermind branch mispredictions and such.

My understanding is that it can give every cycle to a given thread just as long as the other thread doesn't need it to decode anything (if it's idle or whatever). i.e. it can give one thread 4 ops/cycle sustained, given the right workload. But for your purposes, that's probably not any improvement.

i.e. it can give one thread 4 ops/cycle sustained, given the right workload.

Dispatch can only do 2 loads per cycle, and 1 store per cycle. Any more, and it stops on that instruction and dispatches nothing more for that cycle. On plenty of workloads, especially typical compiler output for C code, this is not going to nearly reach the 4 ops/cycle maximum, even on a single thread.

Re: AMD's Bulldozer server benchmarks are here, and they're a catastrophe

#20

Post by dman »

DrPizza wrote: post #12
onenine wrote: post #9

This article is impressively bad. While the 8-module chip does share a few things (mainly a vector processing unit, that becomes two when doing the 128-bit SSE operations) they really can run 16 threads on 16 ALUs. But, they'll have sse contention if they schedule more than 8 256-bit vector operations (sadly intel won't bring this instruction set to market for a bit). Bulldozer is pretty cool, but sadly the tech pres…

> This article is impressively bad. Cheers! > While the 8-module chip does share a few things (mainly a vector processing unit, that becomes two when doing the 128-bit SSE operations) A few things? No, it shares a lot of things. The entire floating point and SIMD unit. The entire front-end. The branch predictor is, I believe, a weird hybrid of shared and non-shared. The I-cache, and the L2 cache, also both shared. Th…

Benchmarks at http://www.phoronix.com/scan.php?page=article&item=amd_f... appear to paint a picture of a much more balanced performance profile for bulldozer chips. It does well in threaded applications and where code is recompiled for it.

I cringed a bit when I saw this on arstechnica - the linkbaitey headline, the image of a burning bulldozer, the lack of any benchmarks that you ran yourself and the fact that data is presented in a lopsided fashion. Here are a few examples -

a) If you look at the actual prices for the Xeon system and the AMD system you can see that the price of the system is entirely dominated by the cost of the SSD drive. Of the ~1.5 Million in before discount price nearly 1.2 Million is for the SSD in the AMD system. While in the Xeon system 485k of the roughly 740k price is the SSD. Penalising AMD for that seems unfair. Also it remains unclear what the SSD in the AMD at double the cost of the Xeon SSD does for performance. b) In the SPEC JBB2005 section where the bulldozer 6200 scores 1.25 million bops, the 6100 gets 0.981 million, and the Xeon has 0.975 million you explain away the high performance saying that this exists only because of a higher number of cores. c) For the SAP section - "the 6200 scores 31,720 SAPS, the 6100 scores 24,020, and the Xeon gets 28,480. The 6200 system, with 33 percent more processors than the 6100 system, gets 32 percent more performance." Heres a test that clearly contradicts your Bulldozer is absymal narrative. d) In the end you write - "AMD is boasting that Opteron 6200 is the "first and only" 16-core x86 processor on the market. Not only is this not really true (equating threads and cores is playing fast and loose with the truth), it just doesn't matter. " - except in the SPEC JBB2005 test where you yourself said that "But these results are still cause for some concern. The 6200 part has 33 percent more cores than the 6100 part, as well as a minor clock speed advantage. Its performance in this CPU-stressing benchmark is only 27 percent greater than that of the 6100. " e) Next time please run some benchmarks of your own.

Post reply on HN