*** AMD "Zen" thread (inc AM4/APU discussion) ***

[cheesyboy]

The CU can't push its calculations through a 128Bit pipe as well as it can a 256Bit pipe, an actual bottleneck.
Its only cinebench that operates in this way and it does to give you a single threaded performance option. But its flawed as even cinema 4D its self does not operate in this way. Its fully threaded.

But in single core bench, you're saying it's got one 128bit pipe for one core - but in multi-core it will have one 256bit pipe for 2 cores - is that any different? And why is it resulting in worse performance for the multi-core bench?

 

[joeyjojo]

The difference in the scaling is still 20% for the AMD.
Although the i5 scaling is out by 4%. It's possible his RAM etc was better set up for his single run.

And it being 70% out isn't a massive difference from the 67% that I'd already shown. You're trying to make a point that isn't there, and far too much focus is being put on buzzwords.

Forget about scaling, just look at the results I took from that thread. Multi-threaded, the two systems (at the same clocks) get scores within 2%. They have the same theoretical max FP processing power so we shouldn't be too surprised.

But single-threaded suddenly there's a 70% gap. Why?

 

[Martini1991]

Forget about scaling, just look at the results I took from that thread. Multi-threaded, the two systems (at the same clocks) get scores within 2%. They have the same theoretical max FP processing power so we shouldn't be too surprised.

But single-threaded suddenly there's a 70% gap. Why?

Sorry what? You're comparing a 4 core and an 8 core, the reason the 4 core's performing nigh on anywhere near that 8 core is because the single threaded performance is that high in stark contrast? Surely that's the answer

Your question seems so ridiculously flawed? The only reason it's seemingly occurred is the focus on buzzwords.

 

[cheesyboy]

Forget about scaling, just look at the results I took from that thread. Multi-threaded, the two systems (at the same clocks) get scores within 2%. They have the same theoretical max FP processing power so we shouldn't be too surprised.

But single-threaded suddenly there's a 70% gap. Why?

Because you're using one wide Intel core and one half of an AMD module. The AMD just doesn't have the per-core grunt.

8 FP-bottlenecked AMD cores match 4 Haswell cores. One non-FP-bottlenecked AMD core is worth less than the Haswell

 

[Martini1991]

Joey.
Do it another way.

The FX83 in Cinebench single thread is only using 12.5% of the cores as per the Multi-threaded benchmark.

12.5% of 755 is ~95. But, because (As I said) the penalty is only in effect when both cores in the module are used, the actual single threaded performance isn't that low, it's actually 114.

What's the difference in percentage between 95 and 114? That magic 20% again (Notice it cropping up a lot?)

Then the Intel is using 25% of the cores it was, 25% of 742 is 185 (A bit off from Pasty's results, but I think he was more optimised for his Single threaded run)

 

[joeyjojo]

Sorry what? You're comparing a 4 core and an 8 core, the reason the 4 core's performing nigh on anywhere near that 8 core is because the single threaded performance is that high in stark contrast? Surely that's the answer

Your question seems so ridiculously flawed? The only reason it's seemingly occurred is the focus on buzzwords.

Are you feeling OK? You know very well it doesn't make sense to call a 4 module Piledriver an 8-core, unless you're specifically talking about integer workloads.

I'm comparing two CPUs with the exact same theoretical peak FP performance, one does it with 4 conventional cores, one does it with 4 modules.

Flat out they have the same theoretical max, and post similar scores. "Single-threaded", one canes the other.

We could just say the single-threaded test isn't a good way of comparing CPUs from different architectures, which is fine, except when we start using it as an example of "IPC differences". (Remember how this started???)

Doing so might suggest Intel were 70% ahead in the IPC game, but we'd be drawing totally the wrong conclusion, because the benchmark is borked.

 

[Martini1991]

Agh, so you're only going to look at this in a flawed manner......
Working on buzzwords and semantics is why people end up being wrong.
Software doesn't care for the semantics, you can't deem something to be flawed because it doesn't care for semantics.

And again, IPC is a very broad term. You couldn't just bang an IPC claim on from Cinebench, because it's an FPU heavy task which the FX's lose their load with. That was very much my point. But calling the benchmark as borked is lolworthy. It highlights an architectural flaw.

 

[joeyjojo]

Right I'm with you, so you're saying with no "module-sharing" (let's call it) overhead you'd expect to see 8*114 = 912, but you end up with 755, so the overhead is about 17%. That's plausible (but wasteful!!!).

 

[Martini1991]

I'm just calling a rock a rock, not a rough pebble.

 

[Martini1991]

Right I'm with you, so you're saying with no "module-sharing" (let's call it) overhead you'd expect to see 8*114 = 912, but you end up with 755, so the overhead is about 17%. That's plausible (but wasteful!!!).

AMD's own slides said this is exactly what would happen with their module approach.

There was always going to be a scaling hit from 2 threads on a module.

 

[Tonester0011]

This is why I listen to martini. He knows his ****
Humbug being a know it all? Does a bear **** in the woods?

 

[humbug]

AMD's own slides said this is exactly what would happen with their module approach.

There was always going to be a scaling hit from 2 threads on a module.

Yes. Because its prone to bottlenecks due it being made up of 2 smaller threads the use of one instead of both would not scale the CP's throughput.

You need to study AMD's modular design, how it functions and why.

 

[Martini1991]

Yes. Because its prone to bottlenecks due it being made up of 2 smaller threads the use of one instead of both would not scale the CP's throughput.

You need to study AMD's modular design, how it functions and why.

Hasn't seemed to help you at all.

 

[humbug]

Hasn't seemed to help you at all.

You have made it passionately clear that you disagree with me and yet cannot fault my reasoning successfully.

I don't think its anything that I say which you disagree with, you just disagree with me, your irrational reactions to me in this and many other threads also speak volumes in that, is it that you just hate being wrong from time to time ?

 

[Martini1991]

Just sounds like more twisting to me Humbug.

 

[humbug]

Your reasoning is easily and constantly rebuked, you then just change the goal posts and do whatever.

The only one who is irrational is you.

You hilariously bring up stuff about me "hating to be wrong" when really, you're just talking about yourself.

Correcting you is not changing any goal posts.

Tell you what, do you even know the reasons fot the modular design, explain it.

 

[Martini1991]

I'm done.
I don't need you to prove you've read more than me about AMD's Module design, I don't care, it doesn't change the fact that for as much theory as you pretend to know about, you're wrong like 9/10 times, and I don't think I've ever seen you correct someone, it's the other way around.

 

[humbug]

Lol. Do some studies before throwing your weight around next time.

In prical terms it saves space, functionality it enable the two CU's and thier indervidual FPU's to join up to make one big CU and thread, in that you can have one big CU + FPU doing the bard work with 6 remaining doing multiple little jobs, or 2 + 4 ecte....

 

[BluD]

Awe, i was hoping this was leading to an arm wrestle.

 

[humbug]

Awe, i was hoping this was leading to an arm wrestle.

Lol