TR Forums

I intentionally avoided the word "Bulldozer" in the title
http://www.phoronix.com/scan.php?page=a ... inux&num=1
Seems like somebody with one hell of a system decided to submit some results to OpenBenchmarking.org. 32 Bulldozer cores still can't beat a 32 core X7550 system with HT, though to be fair, that's 16 really fat cores going up against 32 cores with SMT.

u and your silly comments
are you aware a Xeon X7550 costs 3000$?

Irrelevant, considering you don't know the pricing of said Interlagos SKU. Any other interesting facts you would like to share with us? How much does a z10 cost?

yes, totally irrelevant, Oh noez bulldozer is slower than NASA's 3.5 Million dollar super computer, bulldozer must sucks!1!111
let's totally gloss over how it beat all the sandy bridge chips though that is not a fair comparison either, price matters
we will just have to wait and see

they don't sell them in malaysia but this is exactly how much a z10 costs

...obviously you have nothing intelligent to contribute.

Let's go on the C-Ray results since hyperthreading doesn't make a big difference on C-Ray:
http://hardforum.com/showpost.php?p=103 ... ostcount=6

32 core, 16 module 2S Interlagos at 1.8GHz versus 32 physical cores, 64 virtual of 2.0GHz 4S Nehalem-EX... which is about 48% faster. 32 physical cores of Nehalem-EX with a 200MHz advantage beat 16 Bulldozer modules by a factor of 48%, so we still have linear scaling. Not surprising for an application that doesn't benefit much from HT and is compute bound. One Bulldozer module is therefore comparable to a dual core Nehalem, perhaps with a slight IPC disadvantage.

that's cool, but what's the size difference between a bulldozer module, and a nehalem dual core?

Huh?

One of the early dual Interlagos results from the 32 cores running at 1.8GHz indicates that its C-Ray time is a mere 25 seconds. C-Ray happens to be one of our favorite multi-threaded ray-tracing benchmarks. What does this compare to? Well, running an easy OpenBenchmarking.org comparison shows just how fast AMD's Bulldozer is looking to be. While there are other software/hardware differences in play too, the 32-core 1.80GHz Bulldozer system's 25 seconds compared to the Intel Core i5 2500K (quad-core + Hyper Threading; 3.3GHz + 3.7GHz Intel Turbo Boost) at 61 seconds

emphasis mine

yah, actually 32 cores, vs 4, and it's only twice as fast? wtf is that?!

The 2500K is running almost twice as fast as the Bulldozer, so let's pretend it has the same output as 8 cores of 2500K clocked at 1.65-1.8GHz. JF-AMD fell over himself saying that for anything below AVX 256bit FP precision, 1 Bulldozer module effectively acts like 2 cores because it doesn't have to work its two FP units in tandem, each 128bits wide. Thus according to his post, which is recorded somewhere on the TR forums, Bulldozer should perform like 32 cores because a ray tracer does not need 256bits of precision.

Unfortunately for JF-AMD, I don't see what he's talking about here:
http://realworldtech.com/page.cfm?Artic ... 81333&p=10

Here's a 16 module (this probably means a 2 socket system with 2x4 module Interlagos chips on an MCM per socket) 1.8GHz Bulldozer acting like a 16 core rig, putting out 2.44 times amount of FP horsepower of 8 1.65GHz SB (approximation good enough for our purposes I think). Twice the core count, but a further ~40% speedup??? We also have 32 physical 2.00GHz Nehalem EXs pulling 13 seconds compared to 8x1.65GHz Sandy Bridge at 61s. 13.47s vs 61.65s, slightly over 4x speedup, refer to clock frequencies for an explanation.

32x NEX 13.47s
16x BD ~26.00s
8x SB 61.65s

Here's a better explanation. Kanter's analysis of BD says that although you can still refer to "cores", two cores share one FP unit. The FP unit is treated like a black box shared between two cores, and at some point within the FP unit, there is no distinction between macro-ops from core 1 or core 2. The cores actually handle the dispatching of FP ops to the FP unit. Therefore it makes sense that a "32 core" BD will perform like 16 "normal cores" in FP tasks. This explains why AMD is marketing "modules", not "cores". So in order to compete floating point wise with a dual core SB, you need two BD modules. Integer wise I would expect an individual BD core to not be as strong as a K10 core, because it's narrower than K10, but these cores share dispatch logic and always come in pairs, so in total a module should provide more integer throughput.

Perhaps one day, in accordance with Fusion, the FP unit will be switched out for a shader array with the rest of the chip none the wiser.

EDIT:
http://www.xbitlabs.com/news/cpu/displa ... ealed.html
Apply the "core" dividing logic, and what you see here is the replacement for the Phenom II X2, X3 and X4.

I'm not sure why people are having issues with you sharing links and information concerning Bulldozer CSC, but I want you to know that I appreciate your posts!

Reading your explanations have largely reinforced what I've already read and learned elsewhere, but it's been a long time since I've dug into this particular architecture.

One thing to add- with respect to raw FPU throughput, it was my understanding that K8 and beyond have had a higher FPU IPC than Intel P6 (all of the Cores), and much higher than Netburst, all along. Intel didn't catch up in Float capability until developers began using SSE2 for everything possible as was required to cope with Netburst's aweful raw FPU throughput. Because of this trend, when Intel supercharged the SSE2 unit in the Pentium M as part of the process of designing the Core 2, they were able to leapfrog AMD's K8 style design in real Float capability.

Therefore, it makes perfect sense to me for AMD to essentially cut raw FPU IPC in half, as Float intensive tasks will be handled either by SSE-type instructions or as GPGPU shaders.

Thanks!

They're not really cutting raw FPU IPC in half, though. The scheduling logic for the FPU is actually much more robust than for each individual core inside BD because each core depends on it for FP ops. Whereas before a "core" meant a cluster of integer and FP execution units, in BD think of a core as a cluster of integer execution units, whereas the floating point units are blackboxed, made more "external" than the rest of the core in order to facilitate migration to a GPU shader array and you'll get the idea.

But the long and short of it is "bulldozer isn't much faster than STARs". Not as fast as Sandy bridge.

sweatshopking wrote:

But the long and short of it is "bulldozer isn't much faster than STARs". Not as fast as Sandy bridge.

Very funny. Stars is nowhere near Sandy Bridge. We see Bulldozer here matching the IPC of SB/Nehalem EX on a FP intensive benchmark, and I get this stupid quotation saying it's "still not much faster than Stars".

Single threaded wise, it's probably not as fast as Sandy Bridge. But I think it was kinda obvious that AMD wasn't aiming for that. If you had read the analysis on realworldtech.com, Kanter himself said that it wouldn't be faster than SB anyway...

Crayon Shin Chan wrote:

sweatshopking wrote:

But the long and short of it is "bulldozer isn't much faster than STARs". Not as fast as Sandy bridge.

Very funny. Stars is nowhere near Sandy Bridge. We see Bulldozer here matching the IPC of SB/Nehalem EX on a FP intensive benchmark, and I get this stupid quotation saying it's "still not much faster than Stars".

Single threaded wise, it's probably not as fast as Sandy Bridge. But I think it was kinda obvious that AMD wasn't aiming for that. If you had read the analysis on realworldtech.com, Kanter himself said that it wouldn't be faster than SB anyway...

I read what kanter said, but tbh i was quite confused by your post. I'm not super good with the intricacies of cpu builds, one of the hazards of being a high school kid with no post secondary. I'll go read the numbers again, as it seems i misread them. So, you're impressed with it then?

It looks like it will excel where I want it to: Multi-threaded applications, which is what I need for rendering, encoding

sweatshopking wrote:

But the long and short of it is "bulldozer isn't much faster than STARs". Not as fast as Sandy bridge.

Interlagos 32 core 1.8 GHz
i5 2500 K 4 core 3.3-3.7 GHz

Let's try to resolve the differences:

First, bench-core normalization factor: 25/61 = 0.41 * 32 Interlagos cores = 13.12 Interlagos cores at 1.8 = 4 SB cores at approx 3.5
Hertz normalization factor: 1.8/3.5 (let's estimate) = 0.51 * 13.12 = 6.7 Interlagos cores = 4 SB cores at the same hertz
Core normalization factor: 32 * 0.41 = 13.12 * 0.51 = 6.74/4 = 1.68 Interlagos cores = 1.0 SB cores at the same hertz

That's a seriously whacked way of looking at it, but it is a way. Hopefully it's extremely flawed because an Interlagos core ain't looking so hot.

It doesn't matter anyway if SB9xx SATA isn't competitive

The Bulldozer core doesn't look so hot, the same way that the virtual CPU of a Core i7 doesn't look so hot in some benchmarks. But for entirely different reasons.

The virtual CPU of a Core i7 (that is, the Hyperthreaded instance) sometimes does absolutely nothing. That's because it shares execution hardware with the physical instance, i.e. it waits for one thread to stall, then the CPU will switch to the thread held by the virtual CPU.

On Bulldozer, it won't stall, simply because there's no virtual instance. There actually is actual hardware behind each thread, it's just that compared to Stars, AMD decided to slim it down a bit, so now it has 2 ALUs per core instead of 3. But in the end, you get 4 ALUs, because you can't buy a BD core, you can only buy a module, which has two cores. Like buying a Pentium 4, you buy a CPU, which has two virtual CPUs. Thus, throughput should overall be higher, even if per-core output is lower.

For normal usage I wouldn't dare draw a conclusion from the data available now. I think it's imperative that when TR publishes its CPU review of Bulldozer, they emphasize that the module is meant to replace a traditional core, and the "core" inside a BD is a dispatch unit with some ALUs behind it, outsourcing FP instructions to a shared, externalized, blackboxed FPU. Too many people think that a BD core has to outperform a SB core, how on earth can it do that when it's got less execution units than Stars? Why is this even necessary when you cannot buy a core from AMD, only modules? This is exactly why AMD coined the term "modules"'.

EDIT: On further thought, the last paragraph is the job of the marketing team at AMD. What the hell are they doing? Look at IBM: Synergistic Processing Elements, Power Processor Element. Look at Intel: Hyperthreading, Pentium, and god knows what they have these days. The least they could do at AMD to reduce disappointment when people realize that BD core aren't traditional cores is call them "thread paths", or "Hydra", or is that already taken? Nobody uses Hydravision anymore anyway. Instead they take the one thing that hasn't been split into two and call it "Flex FP", when FPU would suffice perfectly. I think this is maybe why AMD hasn't had such a great market share...

flip-mode wrote:

1.68 Interlagos cores = 1.0 SB cores at the same hertz

That's a seriously whacked way of looking at it, but it is a way. Hopefully it's extremely flawed because an Interlagos core ain't looking so hot.

That would actually be OK: it would mean that a desktop Bulldozer (8 cores / 4 modules) is about 20% faster than a similarly clocked Sandy Bridge in tasks that do not benefit from hyperthreading. It would be the first time since Conroe that AMD was competitive on anything except price close to the high-end (the 990X is still going to crush these, but the number of people willing to pay $1K+ is small).

Crayon Shin Chan wrote:

EDIT: On further thought, the last paragraph is the job of the marketing team at AMD. What the hell are they doing? Look at IBM: Synergistic Processing Elements, Power Processor Element. Look at Intel: Hyperthreading, Pentium, and god knows what they have these days. The least they could do at AMD to reduce disappointment when people realize that BD core aren't traditional cores is call them "thread paths", or "Hydra", or is that already taken? Nobody uses Hydravision anymore anyway. Instead they take the one thing that hasn't been split into two and call it "Flex FP", when FPU would suffice perfectly. I think this is maybe why AMD hasn't had such a great market share...

I agree, and i have a theory about this.

Back when Kanter's article first came out, I went around and around in my head trying to decide what to make of the core/module thing that AMD was doing. I finally decided that they were characterizing it badly. I think it would be much better if they had just called a module a "core" despite the fact it can consume two separate instruction streams simultaneously -- that fact could be marketed as "just like Hyperthreading but better"... trademark it as "UltraThreading™" or something. This would put them on a much stronger footing when compared to competing Intel chips, since they'd have more equivalent execution resources. AMD would actually have an advantage in some cases, because their version of hyperthreading has real resources behind it (and would be available on every model, unlike Intel's "when we feel like you've paid enough to deserve it" approach).

But -- and here's my theory -- BD is clearly a "server-first" chip (no on-die graphics, for example), and I suspect AMD decided they needed to market it that way. For server customers, parallel integer loads matter a lot: if you're hosting web traffic or running a big DBMS or any number of other common server tasks, that shared FP unit is pretty meaningless; it's the number of integer cores you can keep fed that matters, so those two real integer cores per module are meaningful. And those server customers have been a big deal for AMD ever since the first Opteron: what margins AMD sees, it sees mostly from servers. Server CPUs have kept the company alive; everything else is just the leftovers that the server CPUs have made possible.

So BD is a server chip, and server customers care about getting as many integer cores as possible, so AMD characterized Bulldozer in a way that made it look as good as possible to those customers. Unfortunately, that's going to lead to some awkward comparisons everywhere else. Of course we haven't even seen those comparisons yet; these results aren't really indicative of very much when it comes to desktops (I imagine there will be 1.8GHz desktop BD chips, but presumably they'll be towards the bottom of the range -- though who knows how long it will take from them to get sufficient yields at the top of the clock spectrum.) The unfortunate thing is that server customers are savvy enough to understand what's going on no matter what AMD calls it, and they're going to go by benchmarks (on their loads) anyway; the only place the marketing characterization might've made a difference was in the overheated fanboy CPUWarz! and they probably chose exactly wrong for that.

I have to say, that makes a lot of sense UberGerbil.

Actually each bulldozer core has more execution resources than a stars core.

Modules are not going to be marketed, modules are only a way to talk about the logical grouping of cores around shared resource.

As for performance, there will obviously be workloads where having more integer cores and more throughput will be an advantage. We will not be "everything to everyone" and people should do their best to pick the product that meets their needs. This whole idea that intel and amd have to have everything squared off against one another is not realistic.

Bulldozer will do just fine in the market. If being the fastest single threaded CPU is so important, then how can people explain how that $1000 I7 holds ~.01% market share. What does the other 99.99% of the market know that those buyers don't?

There is a great thread here on this forum about price performance, and I find that to be one of the most realistic ways to review processors to date.

well, it's interesting to note that modules won't be marketed. How will you guys do it? branding a module as a core?

When the system boots up, it will see cores, not modules. The OS will see cores, not modules. The applications will see cores, not modules. Why would we introduce modules into the discussion and confuse customers. Modules are logical groupings and mostly relevant to designers.

JF, remember back when you said on a post in this forum that as long as 128bit FP math was required, the Flex FP unit would effectively act like two floating point units matching the two cores in the module, which would act as one when higher precision was required, e.g. AVX. How does that tie in?

Also, are Phenom II units going to come out on AM3+ as well?

David Kanter just posted an excellent analysis and commentary on this.
Executive summary: it's impossible to draw any firm conclusions from these "results."

Crayon Shin Chan wrote:

JF, remember back when you said on a post in this forum that as long as 128bit FP math was required, the Flex FP unit would effectively act like two floating point units matching the two cores in the module, which would act as one when higher precision was required, e.g. AVX. How does that tie in?

Also, are Phenom II units going to come out on AM3+ as well?

Yes, let's compare a 16-core BD to an 8-core SB.

256-bit AVX:
8 256-bit AVX units for Intel
8 256-bit AVX units for AMD

128-bit legacy:
8 128-bit FP units for Intel
16 128-bit FP units for AMD

Now, let's take a step further and look at 128-bit AVX:

8 128-bit AVX units for Intel
16 128-bit AVX units for AMD

Yet the above system performed like a 16 core system instead of a 32 core system. What happened there? Simply not running enough threads?