Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #4182

Re: AMD Bulldozer released... and it sucks

Show all headers | View raw

On 10/12/2011 8:59 PM, Dan wrote:
> So, AMD Bulldozer has finally been released after years of delays, and
> quite frankly based on all the reviews (and the fact that the top of
> the line model has an MSRP of $245) it isn't very good.
>
> http://www.anandtech.com/show/4955/the-bulldozer-review-amd-fx8150-tested
> http://www.planet3dnow.de/vbulletin/showthread.php?t=399114
> http://www.lostcircuits.com/mambo//index.php?option=com_content&task=view&id=102&Itemid=1
> http://www.hardocp.com/article/2011/10/11/amd_bulldozer_fx8150_desktop_performance_review
> http://www.techspot.com/review/452-amd-bulldozer-fx-cpus/page13.html
> http://hothardware.com/Reviews/AMD-FX8150-8Core-Processor-Review-Bulldozer-Has-Landed/
> http://vr-zone.com/articles/amd-fx-8150-cpu-overclocking-review-a-bulldozer-for-gamers-/13694.html
>
> The question is, of course, why? I have a few theories:
>
> 1. The cache hierarchy is not good
>
> Each module has a 64KB 2-way set associative I-cache, two 16KB 4-way
> set-associative write-through D-caches, and 2MB L2. 16KB L1 is a
> significant step below the previous 64KB L1D caches in K10. Not only
> that, but the L2 cache has a horrible 21-27 cycle access latency. I'm
> very interested as to what set of applications this hierarchy is
> optimized for, since it's very different than anything else on the
> market. Given the current state of BD performance, could it be that
> their simulations that led to their cache hierarchy design were
> inaccurate?
>
> 2. Switching from full custom to automatic synthesis caused them to
> miss clock frequency goals
>
> Current rumors state that AMD switched from their usual full custom
> chip design to a more SoC-like design process (which apparently caused
> a mass exodus of ex-DEC engineers) . Doing so costed them 20% in power/
> perf/area. I was under the impression though that the latest shrinks
> of K10 were also synthesized instead of full custom, but what do I
> know. The BD die shots don't really look like the chip was fully
> synthesized (unlike Bobcat, which is obviously fully synthesized), so
> I dunno.
>
> 3. The Global Foundries 32nm process sucks
>
> This still doesn't explain why a 2 billion transistor architecture is
> worse than the Sandy Bridge 1 billion transistor architecture.
>
> Any comments? I know Andy Glew used to work on it, and now that
> Bulldozer is finally out, would you be able to comment about it?

I worked at AMD 2002-2004.  I do not know how or in what ways what I 
worked on back then relates to Bulldozer.  I highly suspect that if what 
I worked on back then *is* substantially related to Bulldozer, that you 
have your answer: if a design that is 7+ years old is only just now 
being introduced, well, that's an awfully long time.

"Now that Bulldozer is finally out, would you be able to comment about 
it?" -- No.  It doesn't work that way.

===

What I do know is that Bulldozer's so-called "multi-core" design 
resembles the "multi-cluster multi-threading" (MCMT) ideas that I came 
up with at UWisc, in reaction to Willamette style multithreading. 
Willamettte had two threads shaing a tiny L0 data cache - 8K in what 
shipped, 16K in later versions, smaller in some proposals.

IMHO having two threads share a 4K or 8K cache for a prolonged period of 
time is stupid. So the basic idea behind my multicluster multithreading 
is to duplicate the cache, so that each thread has a private cache. 
Share the next level out.  Now, you can't just duplicate or split the 
cache without paying a penalty.  So you duplicate the closely coupled 
ALUs, and then possibly move out to the scheduler and renamer - 
basically putting the critical loop inside the duplicated "cluster". 
(Note that you don't necessarily need to dupliccate the scheduler, since 
it isn't inside the most critical loop; but duplicating the scheduler is 
attractive because a fast scheduler grows more difficult with size.)

So, that's the basic idea of my flavor of multicluster multithreading: 
duplicate the innermost cache, plus whatever is neecessary for the 
critical loop.

PRO: two threads are not sharing a really tiny cache

CON: when you are only using a single thread, you can't use the extra 
space in the other L0$.

I mean, one of the main justifications for multithreading, as opposed to 
multiple single threaded cores, is that you can build a larger machine 
that sometimes can be used by a single thread.  Multiclustering's hard 
partitioning makes that more difficult - you can only get the extra 
benefit for a single threaded workload in the shared L2 data cache and 
shared instruction cache.  (And in other shared structures, such as the 
shared L2 scheduler I have written about.)

===

I'll stop here.

Mentioning only briefly that one of the big reasons I proposed 
multicluster multithreading was to support SpMT, speculative 
multithreading.  AMD does not have SpMT, AFAIK.

While I think MCMT is one of the best ways to support a multithreaded 
workload with a small L0 or L1 cache, I don't know that I would have 
built it for a non-SpMT machine.

The "speed demon" motivation for MCMT, threading with a very small L0 or 
L1 cache, went away with the right hand turn away from Wmt or K9-style 
high frequency design. When a chip like Sandybridge can build a 32K L1 
cache without impacting frequency too much - indeed, when design trends 
want you to build a lower clock frequency, to improve yields and power - 
it is not clear that MCMT has an advantage over SMT with a shared L1 cache.
     I.e. I think MCMT is clearly justified with a 4K or 8K L0 cache. 
But probably not justified with a 32K L1 cache.  16K?  I am sure that 
AMD must have simulated it.

Back to comp.arch | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

AMD Bulldozer released... and it sucks Dan <dzhang1@gmail.com> - 2011-10-12 20:59 -0700
  Re: AMD Bulldozer released... and it sucks "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-10-12 23:49 -0700
    Re: AMD Bulldozer released... and it sucks "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-10-14 10:45 -0700
  Re: AMD Bulldozer released... and it sucks Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-10-13 09:06 +0200
  Re: AMD Bulldozer released... and it sucks MitchAlsup <MitchAlsup@aol.com> - 2011-10-13 10:54 -0700
  Re: AMD Bulldozer released... and it sucks "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-10-13 11:05 -0700

csiph-web