Cache and Memory Performance

I mentioned earlier that cache latencies are higher in order to accommodate the larger caches (8MB L2 + 8MB L3) as well as the high frequency design. We turned to our old friend cachemem to measure these latencies in clocks:

Cache/Memory Latency Comparison
  L1 L2 L3 Main Memory
AMD FX-8150 (3.6GHz) 4 21 65 195
AMD Phenom II X4 975 BE (3.6GHz) 3 15 59 182
AMD Phenom II X6 1100T (3.3GHz) 3 14 55 157
Intel Core i5 2500K (3.3GHz) 4 11 25 148

Cache latencies are up significantly across the board, which is to be expected given the increase in pipeline depth as well as cache size. But is Bulldozer able to overcome the increase through higher clocks? To find out we have to convert latency in clocks to latency in nanoseconds:

Memory Latency

We disable turbo in order to get predictable clock speeds, which lets us accurately calculate memory latency in ns. The FX-8150 at 3.6GHz has a longer trip down memory lane than its predecessor, also at 3.6GHz. The higher latency caches play a role in this as they are necessary to help drive AMD's frequency up. What happens if we turn turbo on and peg the FX-8150 at 3.9GHz? Memory latency goes down. Bulldozer still isn't able to get to main memory as quickly as Sandy Bridge, but thanks to Turbo Core it's able to do so better than the outgoing Phenom II.

L3 Cache Latency

L3 access latency is effectively a wash compared to the Phenom II thanks to the higher clock speeds enabled by Turbo Core. Latencies haven't really improved though, and Bulldozer has a long way to go before it reaches Sandy Bridge access latencies.

The Impact of Bulldozer's Pipeline Windows 7 Application Performance
Comments Locked

430 Comments

View All Comments

  • vectorm12 - Wednesday, October 12, 2011 - link

    As both AMD and Intel now use dedicated hardware for AES I feel simply testing AES performance isn't enough. A benchmark of the AES+Twofish+Serpent or atleast AES+Serpent would serve as a more telling benchmark at this point. Don't get me wrong I love that you guys even run a benchmark related to Encryption but it needs to be updated.

    About BD I'm also extremely bummed out that it didn't turn out better than this. Ofc there might be room for improvements with patches/cpu-driver for windows7 etc but considering the TDP, transistor-count and everything else this is a huge loss for AMD.

    I'm still interested in seeing how the Opteron versions will perform in specific tasks as the architecture itself seems really interesting. Someone obviously spent a lot of time thinking this design through and I'd like to believe there's at least one particular workload where BD can actually flex it's muscles for real.
  • fri2219 - Wednesday, October 12, 2011 - link

    Since Bulldozer wasn't created with 3D shooters in mind, it would have been nice to see some financial/engineering/scientific benchmarks instead. Anandtech used to differentiate itself from the kiddie sites by providing that sort of analysis. I guess things change, like my RSS subscription to Anandtech articles will.

    That said, the power consumption numbers pretty much say everything I need to know about the CPU series- the constraint on almost all HPC is power, not SPECint or peak flops.
  • chillmelt - Wednesday, October 12, 2011 - link

    Unfortunately a huge majority of the enthusiast market are gamers. If you truly want productivity benchmarks then wait for server chips. FX CPUs aren't marketed as such, but does perform like one.

    With that said, the FX lineup is a decent multi-threading powerhouse, and not flop in that respect.

    Read tomshardware's review for more benchmarks.
  • Malih - Wednesday, October 12, 2011 - link

    well, i guess there'll be follow up posts.

    "My sample actually arrived less than 12 hours ago, so expect a follow up with performance analysis later this week."
  • lagrande - Wednesday, October 12, 2011 - link

    I'm not AMD fan boy, but the reason AMD gave is pretty reasonable. Thread locality is an important factor in bulldozer architecture, primarily because the memory latency on the cache level is pretty high. If the OS can't schedule the thread properly to the correct core, then there will be a lot of inter-core data movement and probably problem like false sharing can be more apparent.
  • GatorLord - Wednesday, October 12, 2011 - link

    While on one hand as a PC user and builder...and really wanting to build a BD based mindblower, I'm a little disappointed...OK, more than a little...by these results. On the other hand, as an MBA and investor in AMD, I see the big picture and have to reluctantly agree...and hopefully profit.

    If you have constrained and finite capabilities in both design and manufacture (GloFo needs its butt kicked), you maximize along a marginal ROI track and right now that would be server chips to support the growing and lucrative cloud, data warehouse, HPC, and corporate servers and the growing fusion space integrating modest x86 with robust video on low wattage single chips, you end up with exactly what we have here. BD (a server chip rebranded) and Llano with plans to improve both with descendents.

    In highway terms it would be akin to building semis and commuter cars. This is the high performance forum and while the Ferrari Enzos are cool and badass, it's hard to fault AMD for the approach. After all, when you're on the road today, you'll see a bunch of semis and commuter cars...its economics. Performance sells magazines, utility sells products.

    BD must be a killer server beast because Cray (you know Cray, right?) just got a $97M contract from Oak Ridge NL about a month or so after taking possession of the first box of BD based server chips. I think Cray knows a thing or two about making computers haul butt.

    Now we'll see if any of that translates into the client space...
  • MossySF - Wednesday, October 12, 2011 - link

    I'll agree with this. We have a ton of servers -- both Intel and AMD. More integer cores are better. FPU? Games? 3D? Media encoding? Who cares. Hyper-threading does nothing when you peg all cores with VMs running at full blast. For example, we have 1 configuration where we run 4 VMs on a Phenom II x4 3ghz and it performs roughly the same as our 4-core i7 2.8ghz. If we add a 5th VM, both slow down equally showing that there are simply no free resources in the CPU pipeline for hyper-threading to steal.

    So where the bulldozer platform is extra good is for cheap / disposable / uniform VM hosts running Linux. Instead of 1 mega expensive quad xeon costing $100K, you have 10 x 1U Bulldozers that can handle 8VMs each at full utilization without speed degradation for $10K. In addition, you'd probably run something like Centos (or RHEL) the default packages are not compiled with Intels uber compiler so many of the +25% you see in benchmarks here don't exist at all in the Linux world.

    The most disappointing part though (which I mentioned previously) is the lack of speed improvement for the chipset. The first bottleneck for adding more VMs is CPU core but the 2nd is disk bandwidth. If you have disk intensive VMs, you need a separate hard drive for each VM to avoid HD seek latency killing performance. But putting 8 HDs in a 1U is impossible so you need 2U/4U servers taking up too much rackspace.

    The answer of course is a fast SSD ... 500MB/s with 0 latency can be split off to separate VMs with a linear degradation versus exponential for HDs. But the SB950 chipset at 2GB/s bidirectional can only handle 2 fast SSDs. So 1000 MB/s divided by 8 VMs reading at full blast is 125 MB/s per VM -- which is regular SATA3 HD speed. Double that to 4 GB/s and you can put easily put 4 x 2.5" SATA3 SSDs in a 1U delivering 250 MB/s to each VM. Now we're back to at least 2nd generation SSD performance.

    (Note, all the Intel chipsets also max out at 2GB/s bidirectional and stuffing a super expensive raid controller in a 1U is not cost effective.)
  • GatorLord - Wednesday, October 12, 2011 - link

    Great analysis...I'm not a server guy and can hardly keep up with the average 15 year old on desktop jargon and theory, but it seems that the bigger cache would mitigate the roundtrips to disk in the conditions you describe. I guess that's why they left that fat L3 cache on the die...assuming Interlagos and Zambezi are really closer than cousins...more like siblings.

    Great financial case...that I get. I heard a joke the other day that went something like "Whenever they say it's not about the money, it's about the money". It's always about the money... :)
  • Macabre215 - Wednesday, October 12, 2011 - link

    This is reminiscent of the Phenom I launch without the TLB bug. You have a chip that barely outperforms its predecessor and at times performs a little worse. AMD might be able to make a Phenom II like product out of Bulldozer but I I think it's too late. They needed to start out well out of the gate with this one.

    Right now I'm on a Phenom II and will be upgrading to Sandy Bridge soon. I'm done with AMD on the desktop front; a platform which is probably a dead one in the next ten to twenty years anyway. AMD should just stick to the server market and mobile platforms for CPUs as that's where they have a dog in the hunt.

    BTW, this is a disgrace to the FX name.
  • Iketh - Wednesday, October 12, 2011 - link

    I understand why AMD execs resigned in the past 2 years... can you imagine what it musta looked like then? "Nah, we've actually gotten slower per thread, and will need 4ghz+ to compete now..."

Log in

Don't have an account? Sign up now