Kaveri Steamroller vs BulldozerPiledriver

[inf64]

First of all everyone should relax .

The cosmology results are genuine. BUT they come from pre-production sample and they should be disregarded as we have no clue what kind of clocks or level of bios support that system had.

That amdfx blog is known by sensational information not grounded in reality but in this case the author didn't just make it up, the result is indeed there. But as I have said it should definitely be disregarded. Note that AMD also stated that FP performance should not regress with Kaveri (on the contrary- for source check AT article on SR).

As Exophase said, the wide int exec. capability is situated in that very FP co-processor unit and is basically used a lot when running all those workloads AMD lists in the footnotes for the supposed 30% more ops/cycle improvement versus BD/PD. This means anything that runs SSE code in a nutshell(footnote <2>). SSE is executed in FP unit.

 

[Abwx]

The fact that the results make no sense and come from a dubious source is what makes me think it is fake. I'd love to see AMD make an excellent comeback, but getting excited over nonsense doesn't help anyone.

It was and is dubbed nonsense because Galego posted
it his site not because of thorough examination of the
numbers eventual relevance , as pointed by Inf64 the
numbers seems genuine even if not totaly accurate
in respect of a final silicon.

 

[NTMBK]

It was and is dubbed nonsense because Galego posted
it his site not because of thorough examination of the
numbers eventual relevance , as pointed by Inf64 the
numbers seems genuine even if not totaly accurate
in respect of a final silicon.

They show a regression in FP, which makes no sense, and they show no improvement between BD and PD, which makes no sense. Either the numbers are faked or it's a nonsense benchmark.

 

[inf64]

You are wrong here NTMBK . BOINC benchmark was one of the rare ones that showed very little difference between BD and PD. PD is indeed (just) a bit faster in integer part but also, according to BOINC, slower at the same time in fp part. We know PD just flat out outperforms BD in common workloads by a healthy margin (between 7 %and 17%, averaging out at ~11% according to hardware.fr).

 

[Exophase]

They show a regression in FP, which makes no sense, and they show no improvement between BD and PD, which makes no sense. Either the numbers are faked or it's a nonsense benchmark.

Why would fake numbers from an AMD fanboy have the FP regression then?

We do know what the benchmark is and we know it's not a remotely representative one.

 

[NTMBK]

You are wrong here NTMBK . BOINC benchmark was one of the rare ones that showed very little difference between BD and PD. PD is indeed (just) a bit faster in integer part but also, according to BOINC, slower at the same time in fp part. We know PD just flat out outperforms BD in common workloads by a healthy margin (between 7 %and 27%, averaging out at ~11% according to hardware.fr).

So it's a nonsense benchmark, which was my second option.

 

[Insert_Nickname]

Of all of these unsubstantiated benchmarks, what I think is most important is the supposed 15.0 GB/s memory bandwidth. If this is really double the 6800K, then it is going to be pretty fast. I wish I knew how much of that increase comes from the RAM speed vs controller optimizations.

I don't know where you got those numbers from, but I have a 6800K/2133MHz doing 21.3GB/s Read and 10.8GB/s write...

If AMD has a memory controller that can do twice that, I can see some serious performance improvements are in store. But that is not going to happen, the theoretical maximum for dual 2133 is only 34.1GB/s, but if they can break 30GB/s I'm impressed.

 

[sm625]

I got that 15GB/s from here:

It's "GP memory bandwidth", whatever that means. Maybe part of the benchmark involves copying memory from RAM to GPU RAM, which theoretically would be reduced to 0nS for a system with unified memory. Maybe that is why it says 15GB/s for kaveri and only 10GB/s for the top intel.

 

[Insert_Nickname]

I got that 15GB/s from here:

It's "GP memory bandwidth", whatever that means. Maybe part of the benchmark involves copying memory from RAM to GPU RAM, which theoretically would be reduced to 0nS for a system with unified memory. Maybe that is why it says 15GB/s for kaveri and only 10GB/s for the top intel.

That could explain things. I'd really like to see some memory benches from Sandra/Aida64. Just so I have something known I can compare them to. I'm not familiar with that program being used. If someone can point it out, I'd be happy to run some tests...

 

[Fjodor2001]

I got that 15GB/s from here:

It's "GP memory bandwidth", whatever that means. Maybe part of the benchmark involves copying memory from RAM to GPU RAM, which theoretically would be reduced to 0nS for a system with unified memory. Maybe that is why it says 15GB/s for kaveri and only 10GB/s for the top intel.

Hmm... you mean the operation is reduced to a NOP more or less? Or perhaps only updating some MMU tables for a large block of data. Then I think we'd see much higher bandwidth than that.

 

[Enigmoid]

Yup. "Simulated benchmarks". Not sure why anyone takes this joke of a blog seriously, it feels like it's written by Galego.

lol

Of all of these unsubstantiated benchmarks, what I think is most important is the supposed 15.0 GB/s memory bandwidth. If this is really double the 6800K, then it is going to be pretty fast. I wish I knew how much of that increase comes from the RAM speed vs controller optimizations.

The a10-6800k gets almost exactly 15 GB/sec.

I got that 15GB/s from here:

It's "GP memory bandwidth", whatever that means. Maybe part of the benchmark involves copying memory from RAM to GPU RAM, which theoretically would be reduced to 0nS for a system with unified memory. Maybe that is why it says 15GB/s for kaveri and only 10GB/s for the top intel.

And on my HD 4000 laptop I get 17.5 GB/sec with 1600 mhz Cas 11 RAM in that test.

 

[Soulkeeper]

"GP" likely just means general purpose if I had to guess

 

[Ajay]

It is, isn't it. Wasn't that galego's blog that he kept pimping here before he was politely asked to vacate the premises?

Oh, I wondered what happened to him, not that I missed him or anything. Thanks.

 

[Ajay]

http://wccftech.com/amd-kaveri-stea...oint-results-show-viable-competition-haswell/

Yikes! Looks like the rough improvement between these is only around 20% (from the FP score). So that mean means the pre-production sample has a clock of only ~ 2 GHz D:

Unless the IPC jump is much more than we are expecting, Kaveri will need to hit at least 3.5 GHz just to match Richland in ST CPU performance. At 3 GHz or below, Kaveri is going to be a joke, kind of like BD was, in terms of ST CPU performance. This is very sad news if these screen shots are true.

Maybe, as some have suggested, there is now high performance node for 28nm? I think many of us expected the clocks to drop, but not this much - even if Kaveri comes out @ 2.5 GHz with a 20% IPC bump, it will be so out classed that it will become and instant loss leader.

I hope it's not true, really.

 

[inf64]

I don't know what you are thinking by looking at that image.
Kaveri in question is 1.8GhzBase/2.3GhzTurbo mobile ES chip...

 

[Ajay]

I don't know what you are thinking by looking at that image.
Kaveri in question is 1.8GhzBase/2.3GhzTurbo mobile ES chip...

OK, which one, the first or the second? The basic FP score went up by 20% between the two - the is most likely a small, very linear FP test and would be indicative of a 20% increase in clocks (not affected by drivers, just FP instruction loop). I would expect an early ES chip to be clocked at 1.8 GHz. I wouldn't expect a 'Near Production Sample' to be clocked @ 2 GHz.

Now maybe it's completely bogus, in this case, that would be a very good thing.

 

[inf64]

Well for start the chip is completely different. 1st one has 2M at the beginning of the model string and second one has 1M (different stepping, one is early ES other is pre-prod. ES).
2nd, both are obviously having identical base/boost clocks. Whether one had its boost deactivated and other has it activated is unknown.

This score is basically useless as we know nothing about the ES chip that ran it. So basing your opinion about how SR is going to rock or suck is futile.

 

[Abwx]

I would expect an early ES chip to be clocked at 1.8 GHz. I wouldn't expect a 'Near Production Sample' to be clocked @ 2 GHz.

Now maybe it's completely bogus, in this case, that would be a very good thing.

1304 stand for mobile 35W higher perfs part.

 

[Ajay]

So all we get out of this thread is that AMD has Kaveri up and running. Got it.
Man, you'd think I'd learn and just avoid baseless rumor threads...

 

[nenforcer]

So all we get out of this thread is that AMD has Kaveri up and running. Got it.
Man, you'd think I'd learn and just avoid baseless rumor threads...

Yeah, I'm also more interested in benchmarks run on Windows 8.1 which is suppose to have much better performance for APU based designs with a shared GPU / CPU memory space.

Those are probably only a month away, however.

 

[Abwx]

........

http://translate.google.fr/translat...pu-gcn-2-0-con-512-stream-processor&sandbox=1

 

[frozentundra123456]

........

http://translate.google.fr/translat...pu-gcn-2-0-con-512-stream-processor&sandbox=1

If correct that means they need a 25% increase in ipc just to maintain the same CPU performance, since clockspeed is down that much. Igp performance could be good if they can solve the bandwidth problem.

They seem to be biasing performance toward the igp. Time will tell if that is the correct strategy. It could work in mobile, but for desktop, I am not so sure. Still would seem easier just to add a discrete card.

 

[mrmt]

If correct that means they need a 25% increase in ipc just to maintain the same CPU performance, since clockspeed is down that much. Igp performance could be good if they can solve the bandwidth problem

This will be project denver in red. Big iGPU, weak CPU attached.

 

[inf64]

What kind of a BS article was that (the Italian translated). Where did they got those CPU clocks? AMD said that they will "maintain" high frequency engine and this is not what that website is saying. Basically the previously touted "high clock" tuned design done on 28nm bulk process would end up on the (frequency) level of 45nm short pipe K10 which is nonsense.
So adding a decoder, optimizing FP unit for better perf./watt and doing a design on smaller node makes you lose 25-30% frequency? Lmao. So how can this thing outperform 4.1-4.4Ghz Turboed PD core by ~15-20% in common workloads? It would need to have 50-60% higher IPC in order to perform 15-20% better than ~4.2Ghz PD (meaning it would perform like 4.8Ghz PD while running at ~3Ghz). This is complete nonsense.

I love "news" like that

 

[Enigmoid]

They seem to be biasing performance toward the igp. Time will tell if that is the correct strategy. It could work in mobile, but for desktop, I am not so sure. Still would seem easier just to add a discrete card.

In mobile the CPU is already so weak, it bottlenecks a 7970m to 660m levels. In mobile they need a stronger CPU more than anything. You can see in AT GX60 review (with the a10-4600m and the a10-5750m) how much performance went up in CPU bound games like SC2 with richland vs trinity on the igp alone.