AMD Zambezi news, info, fans !

[2good4you]

OBR must be some very skilled guy to judge out Bulldozer performance with his testing of ES samples, especially when he does test cache speeds and don't realize that those numbers are pretty throttled... a little notice is too compare it to Phenom II cachespeeds and also remember that Bulldozer is a cachehungry architecture in many situations, and also ALOT of more powerful cacheprefetchers.

[duron]

i was thinking about BD when i left the airport in the Philippines on the 18th

[FlanK3r]

lol, for interesting, BD thread in Czech is very impressive in reaction, maybe most discussed thread in CZ forums all times...
bulldozern.jpg

[hiepgia]

maybe some BIOS problem???

Nope. 8150p At DDR3-1866 Stock setting, Cinebench 11.5: 5.95 when OC to 4.8 Ghz/ 2.2 Ghz NB it goes to 7.8.

So...?

[TESKATLIPOKA]

FlanK3r Even if you say so, half of It is still comparison between Thuban and SB or SB glorification so Its not really impressive but rather a thread with too much unrelated stuff.

[TESKATLIPOKA]

hiepgia

Nope. 8150p At DDR3-1866 Stock setting, Cinebench 11.5: 5.95 when OC to 4.8 Ghz/ 2.2 Ghz NB it goes to 7.8.

So...?

And? What does it have in common with flanker's question about cache speed being possibly a bios problem. RAM doesn't affect cache.

[hiepgia]

I can't answer this! Ask AMD!

[TESKATLIPOKA]

hiepgia

I can't answer this! Ask AMD!

Why should I ask AMD when you were the one who quoted flanker yet gave negative answer(nope) with some unrelated stuff as proof.

P.S. Even if I asked AMD won't say anything.

[FlanK3r]

hiepgia: do u onyl found OBR results? Because u talk about this...?!

in table


because, this must not be right as retails results...

[TESKATLIPOKA]

FlanK3r didn't you want to link to Aida64 results instead?

[hiepgia]

hiepgia: do u onyl found OBR results? Because u talk about this...?!

in table


because, this must not be right as retails results...

Nope. you will see performance shortly! You have choice belive it or not!

[Opteron146]

And check out the L1 write. If those caches were where they should the performance would be much better.

That is totally ok, BD's L1 is write through, i.e. writes to the L1 go directly to the L2, thus the L1 and L2 write performance should be more or less the same.
However, I wonder what is happening with the L2 read performance, for some strange reason it seems to depend on uncore clock:

2.0GHz: 11.9 GB/s
2.2GHz: 35.8 GB/s
2.4GHz: 12.5 GB/s
2.6GHz: 36.8 GB/s

That's a big difference ...

[-Boris-]

That is totally ok, BD's L1 is write through, i.e. writes to the L1 go directly to the L2, thus the L1 and L2 write performance should be more or less the same.
However, I wonder what is happening with the L2 read performance, for some strange reason it seems to depend on uncore clock:

2.0GHz: 11.9 GB/s
2.2GHz: 35.8 GB/s
2.4GHz: 12.5 GB/s
2.6GHz: 36.8 GB/s

That's a big difference ...

Looks like a bug. And I guess the will be some interesting results if you starts playing with the core frequency as well. Could it be problems with the sync?

And the whole write through idea looks like crap to me. What is the advantage? I think I can see some drawbacks.

[-Boris-]

That is totally ok, BD's L1 is write through, i.e. writes to the L1 go directly to the L2, thus the L1 and L2 write performance should be more or less the same.
However, I wonder what is happening with the L2 read performance, for some strange reason it seems to depend on uncore clock:

2.0GHz: 11.9 GB/s
2.2GHz: 35.8 GB/s
2.4GHz: 12.5 GB/s
2.6GHz: 36.8 GB/s

That's a big difference ...

Looks like a bug. And I guess there will be some interesting results if you starts playing with the core frequency as well. Could it be problems with the sync?

And the whole write through idea looks like crap to me. What is the advantage? I think I can see some drawbacks.

[Opteron146]

And the whole write through idea looks like crap to me. What is the advantage? I think I can see some drawbacks.

Mainly clock speed due to a less complex design. Maybe also some power constraints, they only use parity check, no ECC, for the L1 that saves some transistors, too.

[FlanK3r]

Nope. you will see performance shortly! You have choice belive it or not!

I believe MovieMan, as credible source....He saw final stepings/retail in action and u can find some indications on XSnews from him...But otherwice, this coolaler result can be truth with his BIOS, boards and revision of BD...(but not must be the same or simillary as after launch date!)

[-Boris-]

Mainly clock speed due to a less complex design. Maybe also some power constraints, they only use parity check, no ECC, for the L1 that saves some transistors, too.

Is that worth the loss of IPC? IPC usually is a better route than frequency from a power perspective. And frequency gains seems to be small no matter what nowadays so the possibly higher frequencies doesn't seem to make a big impact on the end performance.

[flyck]

Is that worth the loss of IPC? IPC usually is a better route than frequency from a power perspective. And frequency gains seems to be small no matter what nowadays so the possibly higher frequencies doesn't seem to make a big impact on the end performance.

IPC is just as bad as frequency from a power perspective. ipc cannot be scaled up without huge power drawbacks. Both ipc/frequency should have a good relation to have proper performance. If the difference is to big you can expect bad performance. None of those extremes are at work for SB, BD, K8, nehalem, CoreDuo.

Also the write through concept isn't really an issue because the stores should be stored in a buffer and are written out more bandwidth driven (bundled if possible) to have less latency impact. (Whether or not it turns out that way needs to be seen).

it will have an impact if the l2 cache is extremely slow as results above indicate. However Aida64 also reported that Brazos has 0MB/s write on Brazos... so if te tested version doesn't support it properly strange result are common.

[Opteron146]

Is that worth the loss of IPC? IPC usually is a better route than frequency from a power perspective. And frequency gains seems to be small no matter what nowadays so the possibly higher frequencies doesn't seem to make a big impact on the end performance.

That's traditional, old thinking, it was true until the leakage went through the roof. For IPC you need lots of transistors, hence the fat cores of e.g. intels current architecture, but leakage will be worse and worse with every shrink. Thus the new idea is to cut as much transistors when it does not hurt that much. It's like with a car engine, you can easily construct an 8 cylinder engine with ~500 hp, but if you around 800 hp and up it gets tricky and you have to use lots of time & money to find and build some really complicated tricks. In short: the return of investments gets less and less.
So in future it is easier to build smaller cores. Bulldozer is just the first generation. I expect some IPC improvments in later versions again, but they won't cost too much transistors ;-)

[-Boris-]

That's traditional, old thinking, it was true until the leakage went through the roof. For IPC you need lots of transistors, hence the fat cores of e.g. intels current architecture, but leakage will be worse and worse with every shrink. Thus the new idea is to cut as much transistors when it does not hurt that much. It's like with a car engine, you can easily construct an 8 cylinder engine with ~500 hp, but if you around 800 hp and up it gets tricky and you have to use lots of time & money to find and build some really complicated tricks. In short: the return of investments gets less and less.
So in future it is easier to build smaller cores. Bulldozer is just the first generation. I expect some IPC improvments in later versions again, but they won't cost too much transistors ;-)

That's exactly how I look at high frequencies. Leakage grown lineary with transistors but exponentially with frequency, and exponentially with voltage.

[Dresdenboy]

That's exactly how I look at high frequencies. Leakage grown lineary with transistors but exponentially with frequency, and exponentially with voltage.

Sure, you could use more power consuming logic or drive the single transistors faster to reach higher clockspeeds. But you could just use less logic, thus less transistors, which need to switch during a clock phase. So you get higher clocks w/o increasing power consumption, maybe even lowering it. This is what's AMD's way of going to lower FO4 delays (per pipelinestage).

[Manicdan]

That's exactly how I look at high frequencies. Leakage grown lineary with transistors but exponentially with frequency, and exponentially with voltage.

i dont think leakage is exponential with clock speed, ive done the tests with thuban and it seemed power draw was near linear with clock speed, but exponential with voltage. but you need volts for higher clocks so they practically go hand in hand.

[Buckeye]

As some of you know OBR was banned here sometime ago. We do not allow reposting of material from banned members.

Take this as a warning, anymore posting of OBR screens or links pointing to his materal will/may result in a vacation.

[stangracin3]

As some of you know OBR was banned here sometime ago. We do not allow reposting of material from banned members.

Take this as a warning, anymore posting of OBR screens or links pointing to his materal will/may result in a vacation.

you are going to have to start acting on this because it has been said so many times in this thread before.

[Buckeye]

you are going to have to start acting on this because it has been said so many times in this thread before.

Thats why I made the post