AMD FX-8150 Bulldozer finally tested

**Kuroimaho** · 10-10-2011, 04:26 AM

The Brain rejects negative thoughts, this might explain what's going on in this thread.

**Pantsu** · 10-10-2011, 05:06 AM

Originally Posted by Kuroimaho

The Brain rejects negative thoughts, this might explain what's going on in this thread.

It's a natural shock reaction, first you try to deny it. Then you start trying to "fix" it, until you finally accept it and move on to Intel.

**SoF** · 10-10-2011, 05:44 AM

when we were playing BD a week ago we were looking at each other like "omg this is it?" - 6500+ and the scores were still as ugly as dinos in his summer-suit -.-
Everybody went back to Sandy and GT systems like half an hour later

**liberato87** · 10-10-2011, 05:57 AM

@ Monstru
does HPET was enabled or not in bios?

Originally Posted by chew*

There are many bios options that can effect the outcome of benches.

HPET is 1 for example, it stops the cpu from throttling back in mulithreaded apps.

Running pi on a cluster, versus a core ( 2 threads ) versus being able to disable a single cluster in a core ( which 99% boards/bios's do not have implemented so resources are not shared ) can all influence the results in single threaded.

Knowing all this tells you one thing for sure, you can make it look worse or make it look better all depending on your knowledge of the chip and or your intentions.

As far as PI it's an antiquated bench and has not been AMD's strong point for quite some time.

Granted some results shown tend to lead to the fact that 1m times are bad but looking at the bigger picture we also know that in many cases you can validate 1000mhz higher in many cases with BD, which would point to the fact that you can run 1m at alot faster speeds than current AMD tech.

Things that make you go hmm like what kind of times will we see at 8 gig or even comparing BD to deneb/thuban when same cooling is used.

**AKM** · 10-10-2011, 05:59 AM

Originally Posted by Kuroimaho

The Brain rejects negative thoughts, this might explain what's going on in this thread.

"And despite how sophisticated these neural networks are, it is illuminating to see how the brain sometimes comes up with wrong and overly optimistic answers despite the evidence."

LOL reading this thread makes this painfully obvious.

**Gener_AL (UK)** · 10-10-2011, 06:08 AM

8150.jpg

mm just spotted this. There are also tests against the 2500k.

**Mad Pistol** · 10-10-2011, 06:19 AM

Originally Posted by Gener_AL (UK)

8150.jpg

mm just spotted this. There are also tests against the 2500k.

If this is true, there is a tangible performance increase going to BD from an x6.

**matose** · 10-10-2011, 06:20 AM

Originally Posted by liberato87

@ Monstru
does HPET was enabled or not in bios?

It's me that made the review, so I will take the liberty in responding. I will also respond to some questions from earlier!

BIOS was 9905 which was significantly better in both OC and performance than the old ones. All settings in BIOS were left on default, the only thing I modified was the memory frequency / timings / voltage and turned off all the things I don't use (LAN, USB 3.0, etc).
CPU is the final retail version, revision B2 and the Turbo Core worked without any problem: 1.4GHz when IDLE, 3.6 - 3.9GHz when all cores were used and 4.2GHz in single-threaded applications

Have a nice day,
matose

**Manicdan** · 10-10-2011, 06:23 AM

Originally Posted by Gener_AL (UK)

8150.jpg

mm just spotted this. There are also tests against the 2500k.

this might have already been pointed out for a week now, or there could have been newer 8150 results uploaded to their database

**Manicdan** · 10-10-2011, 06:29 AM

Originally Posted by matose

1.4GHz when IDLE

Have a nice day,
matose

are there multiplyers as low as 4 for 800mhz, or is 7 the lowest?

**Manicdan** · 10-10-2011, 06:29 AM

double post

**haylui** · 10-10-2011, 06:30 AM

Originally Posted by Gener_AL (UK)

8150.jpg

mm just spotted this. There are also tests against the 2500k.

could we see the source of this ?

**liberato87** · 10-10-2011, 06:31 AM

edit

**flyck** · 10-10-2011, 06:33 AM

Originally Posted by Mad Pistol

If this is true, there is a tangible performance increase going to BD from an x6.

Well if they could gain 80% in integer compared to thuban... that would be contradicting every bench that was leaked since that woul make a new BD core immensly more efficient. So this score from the BD seems to be an overclocked model (if we assume the numbers popping up in previews to be correct).

The smallest difference is in fpu load, the biggest in integers.

**liberato87** · 10-10-2011, 06:35 AM

Originally Posted by matose

It's me that made the review, so I will take the liberty in responding. I will also respond to some questions from earlier!

BIOS was 9905 which was significantly better in both OC and performance than the old ones. All settings in BIOS were left on default, the only thing I modified was the memory frequency / timings / voltage and turned off all the things I don't use (LAN, USB 3.0, etc).
CPU is the final retail version, revision B2 and the Turbo Core worked without any problem: 1.4GHz when IDLE, 3.6 - 3.9GHz when all cores were used and 4.2GHz in single-threaded applications

Have a nice day,
matose

thank you for reply.
I thought Monstru did the review

I red the "HPET thing" long time before, so I was curious to see if it matters or not.

I can ask you why you left northbridge clock at default (I saw that in the spi picture)?
I red of someone raised nb to 3200...
I can ask you if you will post a complete review when nda expires?

**Gener_AL (UK)** · 10-10-2011, 06:39 AM

Originally Posted by haylui

could we see the source of this ?

http://semiaccurate.com/forums/showp...&postcount=539

Just happened to come across this earlier, a few more benchies to look at there

**Opteron146** · 10-10-2011, 06:55 AM

Originally Posted by looncraz

Actually, we already have such an issue known for Bulldozer, and NO bench-marked system has the patch installed!

The shared L1 cache is causing cross invalidations across threads so that the prefetch data is incorrect in too many cases and data must be fetched again. The fix is a "simple" memory alignment and (possible)tagging system in the kernel of Windows/Linux.

I reviewed the code for the Linux patch and was astonished by just how little I know of the Linux kernel... lol! In any event, it could easily cost 10% in terms of single threaded performance, possibly more than double that in multi-threaded loads on the same module due to the increased contention and randomness of accesses.

Not sure if ordained reviewers have been given access to the MS patch, but I'd imagine (and hope) so! Last I saw, the Linux kernel patch was still being worked on by AMD (publicly) and Linus was showing some distaste for the method used to address the issue. One comment questioned the performance cost but had received no replies... but you don't go re-working kernel memory mapping for anything less than 5-10%... just not worth it!

Hi,

are you sure about the numbers? I remember following the discussion on the message board, I think they talked about ~3% performance impact, much more for "micro" benchmarks. So you say now that it is more 10-20%?

**saint19** · 10-10-2011, 07:05 AM

Are this results all true? I was waiting more from BD and AMD with all the long wait that we did for this CPUs. Hope see something different to this results.

**wez** · 10-10-2011, 07:09 AM

Originally Posted by liberato87

I red the "HPET thing" long time before, so I was curious to see if it matters or not.

If I understood chew correctly, modifying HPET will allow it to run 4.2ghz on all cores. Not exactly suitable for most reviews, But no doubt interesting for us

Hope more boards will implement that feature, as long as they can handle the load without going *poff*

(I think AMD confirmed on facebook or something that nda lift on the 12th?)

**hokiealumnus** · 10-10-2011, 07:14 AM

Originally Posted by SKYMTL

The reactions of some people really get me laughing.

People wanted to see results posted so Lab501 did that. Unfortunately, some of us are bound by NDA so we can't comment on the accuracy of said numbers but....

Since they weren't anywhere near what some people expected, small details are picked and prodded until we get the "impossible", "BS!" and "biased" words thrown around for heaven knows what reason.

So if these numbers are accurate, will those same people post again saying "we were wrong!"? Methinks not. They'll go sulk in a corner for 5 minutes, find another thread to pick apart and then ultimately go buy an Intel processor. On the flip side of that coin, if the numbers are inaccurate or wrong, Lab501 has pretty much burned every possible bridge with a major manufacturer and will be the butt end of communal jokes until Theo or Charlie screw up again.

So which one will it be? Man, the next few days will be interesting to say the least.....

As I'm also bound by NDA, I just wanted to say - QFT. Well said SKYMTL.

**xXSebaSXx** · 10-10-2011, 07:25 AM

Regardless of how BD performs vs SB; I will guarantee you one thing... FX-8150 will become one of the most popular chips at HWBot faster than you can type "Rev 4 Sucks". If for one reason only; it will be because of its high OC ceiling. I foresee the 7GHz+ and even the 8GHz+ clubs gaining a load of new members in the future weeks/months.

**Syn.** · 10-10-2011, 08:03 AM

Originally Posted by xXSebaSXx

Regardless of how BD performs vs SB; I will guarantee you one thing... FX-8150 will become one of the most popular chips at HWBot faster than you can type "Rev 4 Sucks". If for one reason only; it will be because of its high OC ceiling. I foresee the 7GHz+ and even the 8GHz+ clubs gaining a load of new members in the future weeks/months.

I will buy FX8 simply because it is better then my current CPU. As far as performance numbers unlike most people in this thread i am not expecting anything. I am awaiting the reviews with no expectations, just curiosity.

**tiborrr** · 10-10-2011, 08:06 AM

Who cares about performance, I want jiggahertzs!

**Kobaltrock** · 10-10-2011, 08:07 AM

Originally Posted by looncraz

Actually, we already have such an issue known for Bulldozer, and NO bench-marked system has the patch installed!

The shared L1 cache is causing cross invalidations across threads so that the prefetch data is incorrect in too many cases and data must be fetched again. The fix is a "simple" memory alignment and (possible)tagging system in the kernel of Windows/Linux.
!

Here is the patch in question:
http://thread.gmane.org/gmane.linux..../focus=1171713

From: Borislav Petkov <bp <at> amd64.org>
Subject: [PATCH] x86, AMD: Correct F15h IC aliasing issue
Newsgroups: gmane.linux.kernel
Date: 2011-07-22 13:15:47 GMT (11 weeks, 3 days, 2 hours and 46 minutes ago)

From: Borislav Petkov <borislav.petkov <at> amd.com>

This patch provides performance tuning for the "Bulldozer" CPU. With its
shared instruction cache there is a chance of generating an excessive
number of cache cross-invalidates when running specific workloads on the
cores of a compute module.

This excessive amount of cross-invalidations can be observed if cache
lines backed by shared physical memory alias in bits [14:12] of their
virtual addresses, as those bits are used for the index generation.

This patch addresses the issue by zeroing out the slice [14:12] of
the file mapping's virtual address at generation time, thus forcing
those bits the same for all mappings of a single shared library across
processes and, in doing so, avoids instruction cache aliases.

It also adds the kernel command line option
"unalias_va_addr=(32|64|off)" with which virtual address unaliasing
can be enabled for 32-bit or 64-bit x86 individually, or be completely
disabled.

This change leaves virtual region address allocation on other families
and/or vendors unaffected.

and Linus' response http://article.gmane.org/gmane.linux.kernel/1170744

From: Linus Torvalds <torvalds <at> linux-foundation.org>
Subject: Re: [PATCH] x86, AMD: Correct F15h IC aliasing issue
Newsgroups: gmane.linux.kernel
Date: 2011-07-24 16:04:27 GMT (11 weeks, 23 hours and 59 minutes ago)
Argh. This is a small disaster, you know that, right? Suddenly we have
user-visible allocation changes depending on which CPU you are running
on. I just hope that the address-space randomization has caught all
the code that depended on specific layouts.

And even with ASLR, I wouldn't be surprised if there are binaries out
there that "know" that they get dense virtual memory when they do
back-to-back allocations, even when they don't pass in the address
explicitly.

How much testing has AMD done with this change and various legacy
Linux distros? The 32-bit case in particular makes me nervous, that's
where I'd expect a higher likelihood of binaries that depend on the
layout.

You guys do realize that we had to disable ASLR on many machines?

So at a MINIMUM, I would say that this is acceptable only when the
process doing the allocation hasn't got ASLR disabled.
...
Anyway, I seriously think that this patch is completely unacceptable
in this form, and is quite possibly going to break real applications.
Maybe most of the applications that had problems with ASLR only had
trouble with anonymous memory, and the fact that you only do this for
file mappings might mean that it's ok. But I'd be really worried.
Changing address space layout is not a small decision.