Cat (Bulldozer) out of the bag! Review here!

teletran8 said:
But can it run Quake 3?
Click to expand...

Yes... 8 instances, at 10fps per core... Will that be fast enough...;)

Another preliminary (read FAKE) bench, and I quote:

Green bar is FX8120
This is without right drivers and BIOS.
Could be completely different after AMD releases additional drivers.
There was also a slight TeamView overhead.

22kH7.png
 
mzs_biteme said:
Yes... 8 instances, at 10fps per core... Will that be fast enough...;)

Another preliminary (read FAKE) bench, and I quote:

Green bar is FX8120
This is without right drivers and BIOS.
Could be completely different after AMD releases additional drivers.
There was also a slight TeamView overhead.
Click to expand...

Ouch.
 
AntiSocialMunky said:
Its not even performing badly. The graphs are horrid. Most of the numbers are quite close.
Click to expand...

this this this, I have a sandy bridge chip and won't be buying this. However these results aren't bad if you look at the numbers. There might be some issue with the cinebench but otherwise not bad at all, especially if they price it right.
 
mrbigshot said:
lmao!
Click to expand...

I can't even look at it for 2 seconds, you must be superman!!

butterfliesrpretty said:
this this this, I have a sandy bridge chip and won't be buying this. However these results aren't bad if you look at the numbers. There might be some issue with the cinebench but otherwise not bad at all, especially if they price it right.
Click to expand...

Yet a 1055T goes for 149.99 atm I believe.
 
LoL another idiot reviewer who can't make good cpu test in games.
Just by looking at 1100T so near to 2600K it should be obvious they tested places where GPU was limiting factor.
 
Some of those games are only a few fps difference ... I don't see how that's all bad. Consider these bulldozer chips will be cheaper , its not bad at all.
 
W.Feather said:
My impression of an intel fanboys impression of an AMD fanboy:


seriously, did you look at the graphs? The scaling is all over the place to show bigger gaps between performance rather than the hard numbers
Click to expand...

Yeah, buying the best processor for the money makes me a fanboy. :rolleyes: Enjoy your 8 Athlon 64 cores.
 
AMD_Gamer said:
Exactly what Intel would want.
Click to expand...

It is interesting, of course I'll read the official reviews when they come out. Honestly I could care less what intel wants, I kinda doubt though there is a grand conspiracy(could be wrong). I am not in the market for cpu, my phenom x4 perform adequately for everything I need.
 
mzs_biteme said:
22kH7.png
Click to expand...

That's actually pretty good, and it's not even the 8150 (it's the 8120, which is clocked quite a bit lower).

People may complain that it loses to Thuban but all those Thuban's are overclocked and also they tend to do really well in multithreaded benchmarks like this one. From other benchmarks I've seen BD does much better than Thuban in single threaded apps, where AMD was getting spanked up until now.
 
it's funny, i don't see the AMD fanboys bitching about this graph.

WHOAAAA. Look at that huge gap. look how slow the 2600k is !! It's slower by 200 frames/sec !!#!&^%*%&$^

2011-10-09_175322.png
 
dr.kevin said:
it's funny, i don't see the AMD fanboys bitching about this graph.

WHOAAAA. Look at that huge gap. look how slow the 2600k is !!

2011-10-09_175322.png
Click to expand...

DH's graphs are retarded, no matter which chip is winning. Graphs are supposed to make it easier to tell a relative difference between two performance numbers, DonanimHaber's graphs do nothing of sorts. They are pointless. Like that graph, it spans a whole 3 FPS, lol!

Freaking amateurs. C'mon NDA get lifted already so we can see some pro benches.
 
Is this a legit review? Well to be honest I didn't really think it would beat the 2600K.
 
I think AMD has shot themselves in the foot from a marketing perspective because they advertise it as an 8 core processor. In reality the 8150 is more like a 4 core processor with multi-threading like the i7-2600k. Thus, if you look at all of the leaked benches which have surfaced in the last few days and look at is as a 4 core processor with 8 threads, the results are very good indeed. Looking at it in this light the new Bulldozer is faster than a true 6 core Phenom X6 and relatively close to Intel's I7 2600k.

Still, AMD is marketing it as an 8 core when it really isn't and thus the results from an 8 core perspective are horrific.
 
looncraz@XS

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!
Click to expand...
http://comments.gmane.org/gmane.linux.kernel/1170214
http://www.spinics.net/lists/linux-tip-commits/msg13140.html
 
I'll be happy if BD can get a 10% improvement via software (OS patches) but in that linux kernel patch discussion (good read) the AMD engineer estimates the improvement to be around 3%.
Avi Kivity [Red Hat Linux]: Out of curiosity, what's the performance impact if the workaround is not enabled?
Borislav Petkov [AMD]: Up to 3% for a CPU-intensive style benchmark, and it can vary highly in a microbenchmark depending on workload and compiler.
Click to expand...
 
larkin said:
I'll be happy if BD can get a 10% improvement via software (OS patches) but in that linux kernel patch discussion (good read) the AMD engineer estimates the improvement to be around 3%.
Click to expand...

I understood the 3% as the performance penalty you pay when you install the patch. Not all code causes the aliasing issue, but by installing the patch you'll affect the whole stack. Affected code will run at normal speed.

The issue doesn't seem to be very small according to Linus :

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.
Click to expand...
 
dr.kevin said:
it's funny, i don't see the AMD fanboys bitching about this graph.

WHOAAAA. Look at that huge gap. look how slow the 2600k is !! It's slower by 200 frames/sec !!#!&^%*%&$^

2011-10-09_175322.png
Click to expand...

Funny, you are the only one bitching about it.
 
Michaelius said:
LoL another idiot reviewer who can't make good cpu test in games.
Just by looking at 1100T so near to 2600K it should be obvious they tested places where GPU was limiting factor.
Click to expand...

Is this in reference to the excel sheet? If so, take a look, its a x264 rendering test for 1080p .... GPU doesnt make a difference.....if in reference to the DH info, then take a look at the axis..


Valshistixol said:
Yeah, buying the best processor for the money makes me a fanboy. :rolleyes: Enjoy your 8 Athlon 64 cores.
Click to expand...

yet we dont know what the best for the money is, my only point was the graphs are skewed to make the data look what DH wants it to
 
Can we just finally stop using the term "fanboy" you bunch of newbs.:D
 
I love the gaming graphs. The FX is like 200 fps and the i7 is 204 fps but the FX graph is half the size.
 
They'll probably be so many more BD speed comparison tests and graphs to come it isn't even funny.

I want to see in real consumer experiences is where it's at IMO.
 
savantu said:
I understood the 3% as the performance penalty you pay when you install the patch. Not all code causes the aliasing issue, but by installing the patch you'll affect the whole stack. Affected code will run at normal speed.

The issue doesn't seem to be very small according to Linus :
Click to expand...

When he says its a small disaster he implies the proposed fix is a small disaster, because it could affect older software. If you keep on reading you will notice that they (the AMD guy and Linus) come to an agreement on how to better implement the fix.

On Wed, Jul 27, 2011 at 11:57:45AM -0400, Avi Kivity wrote:
> Out of curiosity, what's the performance impact if the workaround is
> not enabled?

Borislav Petkov (AMD) wrote:

Up to 3% for a CPU-intensive style benchmark, and it can vary highly in
a microbenchmark depending on workload and compiler.
Click to expand...

Up to 3% performance impact without a fix, in many cases the impact could be nothing.
 
Last edited:
I love that a 5.94 bar is 1.5" tall, and the MUCH BETTER INTEL 5.98 is 6" tall. lol. Start the graphs at 0.
 
You must log in or register to reply here.
Back
Top