Discussion: AMD Ryzen

[scuzzycard]

Well, I plan to solve for IPC at the clocks the processors were ran at tomorrow morning. Should remove the frequency scaling issues from the results, and give an idea where IPC actually is.

Do you need Haswell results? This is my 5820K underclocked to 1.4GHz https://browser.geekbench.com/v4/cpu/233841

 

[gamerk316]

EDIT

I'm an idiot; see below

 

[gamerk316]

Well, I plan to solve for IPC at the clocks the processors were ran at tomorrow morning. Should remove the frequency scaling issues from the results, and give an idea where IPC actually is.

Do you need Haswell results? This is my 5820K underclocked to 1.4GHz https://browser.geekbench.com/v4/cpu/233841

Right after I did the math too; I'll get to them in a bit (busy at work now). Just need to throw them in my spreadsheet.

 

[Reynod]

In Intels defense, their Engineers thought they could take Netburst to 10 GHz plus. They (badly) underestimated how much processor leakage was going to kill them. No one would have cared if AMD had 1.5x the IPC if Intel ended up with 5x the clockspeed advantage.

The P4 ALU was double pumped

The pipeline was so long ... 20 ...

The existing process nodes ... transistor design ... low power states ... toooo much heat.

 

[gamerk316]

And I'm an idiot; using Number of Cores in single threaded benchmarks. Was trying to figure out why the Haswell results were giving me 1000 IPC :/

So, let's try this again:

For the pcper result set that compares Zen and Ivy Bridge, I get a 12.55% difference in IPC between Zen and Ivy Bridge, with the advantage going to Ivy Bridge.

When comparing to scuzzycard's Haswell, I get a 55.38% IPC difference, which seems excessive given the IB numbers. In fact, I'm getting a 43.58% IPC difference between the Ivy and Haswell numbers provided by scuzzycard. Note this could be due to one or two specific benchmarks; Memory Bandwidth takes a HUGE jump for example.

So I did the results a SECOND time, removing AES and the Memory Benchmarks from the results, so I can focus just on raw computing power. So according to those numbers:

Ivy V Zen: 24% IPC difference in favor of Ivy
Haswell V Zen: 45.45% IPC difference in favor of Haswell
Ivy V Haswell: 22.05% IPC difference in favor of Haswell

More reasonable. Take Scuzzycards results for what you will (non-identical configs), but the Ivy V Zen results are showing a 24% IPC deficit, which is relatively close to what you'd expect if Zen had a 40% IPC bump over SR.

 

[-Fran-]

Isn't the 5820K a Haswell-E?

Also, I read somewhere geekbench is not a good measurement for general purpose, since it relies in L1 cache too much. I would imagine it's a very repetitive test with a few instruction type and value set, so it hardly measures general purpose performance.

I'm saying this to put the numbers in context: what we might be seeing here is not "performance" of the CPU as a whole, but maybe just an aspect of it.

In any case, thanks for the numbers gamerk.

Cheers!

 

[scuzzycard]

And I'm an idiot; using Number of Cores in single threaded benchmarks. Was trying to figure out why the Haswell results were giving me 1000 IPC :/

So, let's try this again:

For the pcper result set that compares Zen and Ivy Bridge, I get a 12.55% difference in IPC between Zen and Ivy Bridge, with the advantage going to Ivy Bridge.

When comparing to scuzzycard's Haswell, I get a 55.38% IPC difference, which seems excessive given the IB numbers. In fact, I'm getting a 43.58% IPC difference between the Ivy and Haswell numbers provided by scuzzycard. Note this could be due to one or two specific benchmarks; Memory Bandwidth takes a HUGE jump for example.

So I did the results a SECOND time, removing AES and the Memory Benchmarks from the results, so I can focus just on raw computing power. So according to those numbers:

Ivy V Zen: 24% IPC difference in favor of Ivy
Haswell V Zen: 45.45% IPC difference in favor of Haswell
Ivy V Haswell: 22.05% IPC difference in favor of Haswell

More reasonable. Take Scuzzycards results for what you will (non-identical configs), but the Ivy V Zen results are showing a 24% IPC deficit, which is relatively close to what you'd expect if Zen had a 40% IPC bump over SR.

These are my results at 4.6 - as you can see, the scaling from 1.4 to 4.6 is not linear at all, although it was interesting to see what a 1400MHz CPU did with quad-channel 2666MHz DDR4. It's only about 80% as fast clock for clock compared to the 1.4GHz results.

https://browser.geekbench.com/v4/cpu/224843

 

[ComputerSecurityGuy]

Something is a bit fishy then, because Haswell is maybe 10-11% faster than Ivy Bridge in terms of IPC. This benchmark claims double that. Doesn't seem incredibly reliable.
http://www.anandtech.com/show/9483/intel-skylake-review-6700k-6600k-ddr4-ddr3-ipc-6th-generation/9

 

[scuzzycard]

Something is a bit fishy then, because Haswell is maybe 10-11% faster than Ivy Bridge in terms of IPC. This benchmark claims double that. Doesn't seem incredibly reliable.
http://www.anandtech.com/show/9483/intel-skylake-review-6700k-6600k-ddr4-ddr3-ipc-6th-generation/9

Where did the 1.4GHz Ivy numbers come from? I know mine are right, though I'm sure I've put more time into fine tuning my memory and such than most. My machine tends to benchmark around 5% faster than other machines with the same hardware.

 

[gamerk316]

Something is a bit fishy then, because Haswell is maybe 10-11% faster than Ivy Bridge in terms of IPC. This benchmark claims double that. Doesn't seem incredibly reliable.
http://www.anandtech.com/show/9483/intel-skylake-review-6700k-6600k-ddr4-ddr3-ipc-6th-generation/9

Benchmarks do tend to show better average gains; take the AES results as an example: AMD has dedicated HW for AES, hence why it wins that specific benchmark. So 20% Ivy to Haswell is "reasonable", though a bit high. Also remember that the IB and HW setups aren't identical, since they come from different users, so it's not a real apples to apples.

My big concern here is my result set matches pcper, even with their clockspeed scaling. Disregarding AES and Memory, I came up with 24% IPC deficit, while PCPER came up with 20.34%, which is close enough where you have two points saying "Zen is 20% slower clock for clock".

Now, Multithreaded might be a more interesting case, given Zen *should* get more benefit out of SMT. I'll check that next to see if that holds up. My suspicion going in blind is that Zen should beat Ivy in multithreaded IPC.

 

[juanrga]

http://www.pcper.com/news/Processors/Leaked-Geekbench-Results-AMD-Zen-Performance-Extrapolated?destination=node/66172#comment-308881

Specifically:

AES numbers make sense, given AMD has dedicated resources on the CPU die. For all other tasks, you see performance 10-30% slower then IB at the same clocks.

If true (And that's a BIG if), Zen likely doesn't even match Sandy Bridge IPC levels.

EDIT

I want to make this very clear, if these results are accurate, Zen won't even beat Sandy Bridge head to head. This would be significantly below even my worst-case estimations for Zen's performance.

There's a side of me that says the results are so bad, they can't possibly be real. Then again, I said the same thing in regards to Bulldozer when the first real numbers started to leak.

According to AMD, Zen has 40% higher IPC than Excavator. I took CB15 score for Excavator-based Athlon and got Zen IPC behind Sandy Bridge

http://www.tomshardware.co.uk/forum/id-2986517/discussion-amd-zen.html#18067773

Said that, the PCPer approach is incorrect, because Geekbench doesn't scale linearly.

 

[juanrga]

Geekbench doesn't scale linearly with frequency, thus the Zen results extrapolated to 3.6GHz are invalid. This can be observed comparing single thread score for Haswell at different clocks

Intel Haswell @1.6GHz: 1804 pts / 1.6 GHz -> 1127 pts / GHz
Intel Haswell @3.6GHz: 3075 pts / 3.6 GHz -> 854 pts / GHz

Linear scaling [(1804/1.6GHz)*3.6GHz] would give a wrong value 4059 for the Haswell chip at 3.6GHz. Linear scaling is giving fictitious IPC advantage to the low-clocked chips. PCPer can do two things:

(A)
Apply an approx correction factor to linear scaling: e.g. 3075/4059 ~0.76 to all Zen scores they got for 3.6GHz.

(B)
Repeat the comparison using instead an Intel Xeon chip clocked similarly to Zen

https://browser.primatelabs.com/v4/cpu/117877

http://ark.intel.com/products/83349/Intel-Xeon-Processor-E5-2603-v3-15M-Cache-1_60-GHz

This is a 6-core Haswell Xeon clocked so low as 1.6GHz without Turbo and without Hypertreading.

 

[gamerk316]

Well then, that was horrible.

In Multithreaded, disregarding AES and Memory Benchmarks:

Zen V Ivy: 73.85%
Zen V Haswell: 79.44%
Ivy V Haswell: 6.55%

I'm triple checking my math, but I'm fairly confident based on the Ivy V Haswell results, which is the IPC difference I'd expect. Farther, given the Ivy/Haswell results make sense, this implies that scaling is relatively consistent, otherwise there'd be a HUGE gap between a 48 core Ivy and a 12 core Haswell.

I'm honestly not sure what to make of this; the single thread results make sense across the board, and the multithread between Haswell and Ivy also seem spot on. The Zen multithreaded results look outright HORRIBLE.

 

[gamerk316]

One final time, using these two result sets only:

Haswell:
https://browser.primatelabs.com/v4/cpu/117877

Zen:
http://browser.primatelabs.com/v4/cpu/105227

The numbers are horrid:

Single threaded: 48.22%

Multithreaded: 114.17%

Something is SERIOUSLY wrong here; there's no way Zens multithreading can possible be this bad. Either Geekbench running into some sort of bottleneck with the Zen architecture when using Zen, the OS isn't properly handling Miltithreading for Zen, or something is seriously wrong inside Zens HW.

EDIT

Whats happening here is that Zen has significant more cores, but a lower overall score in the majority of the tests. So when I do the math, Zen's numbers look horrid. Can anyone confirm these results actually SCALE across a 64-core cluster?

Here's an example:

Haswell Multithreaded AES: 19314 = IPC * Clock * Cores
19314 = 1.6 * 12 * IPC
IPC = 1005.94

Zen Multithreaded AES: 18235 = IPC * Clock * Cores
18235 = 1.44 * 64 * IPC
IPC = 197.86

IPC deficit: 134.25%

Kind of highlights my "software scaling" argument in a nutshell. I don't think I can confidently compare multithreaded results across significantly differing core counts here, given scaling and core loading could very well be an issue.

 

[scuzzycard]

Something is wrong. Have a look at these 48-core Haswell-EP Xeon results (4x12 core)
http://browser.primatelabs.com/v4/cpu/42743
Single Core: 2957
Multi Core: 62615
Multi/Single: 21.75X

Zen 48 core:
Single Core:1141
Multi Core: 15620
Multi/Single: 13.69X

Shouldn't there be a bigger difference between Single and Multi Core if this is indeed a 48 core CPU? It there any chance it's 24C/48T and Geekbench detected the core count incorrectly?

Now here's a 24-Core Xeon setup:

http://browser.primatelabs.com/v4/cpu/111832
Single Core: 3292
Multi Core: 46191
Multi/Single: 14.03

Kinda makes you think - The ratio of Multi core:Single core is the same as a 24-core Intel setup.

 

[juanrga]

Well then, that was horrible.

In Multithreaded, disregarding AES and Memory Benchmarks:

Zen V Ivy: 73.85%
Zen V Haswell: 79.44%
Ivy V Haswell: 6.55%

I'm triple checking my math, but I'm fairly confident based on the Ivy V Haswell results, which is the IPC difference I'd expect. Farther, given the Ivy/Haswell results make sense, this implies that scaling is relatively consistent, otherwise there'd be a HUGE gap between a 48 core Ivy and a 12 core Haswell.

I'm honestly not sure what to make of this; the single thread results make sense across the board, and the multithread between Haswell and Ivy also seem spot on. The Zen multithreaded results look outright HORRIBLE.

Multi treading requires lots of bandwidth, specially when you have 64 cores (128 threads) to feed with tons of data. No one here remember the AoS benchmark leak where Zen was behind Haswell by a large amount?

http://www.guru3d.com/news-story/amd-zen-engineering-sample-aos-further-analysis.html

My interpretation then was that the gap was a result of this game being very heavy in memory bandwidth.

 

[-Fran-]

There's also the scaling itself of the CPU and how Geekbench treats the exposed threads. Another important detail we're forgetting, which could also explain a couple of things, the BIOS microcode used for the tests might still be lacking adjustments. It was a board for an ES, so it is bound to run in diagnose or debug mode most of the time.

There are just too many unknowns in the numbers being put forward to even consider them as remotely valid.

Now, this is not a bad exercise at all. I really find interesting the things you guys are noting in your numbers. Unfortunately, I find more "unknowns" than "knowns" in them.

Cheers!

EDIT: Typo.

 

[scuzzycard]

I don't think these leaked scores are indicative of anything either. They actually show IPC that's extremely close what AMD already has in the FX series if you extrapolate from FX-8350 scores, which is just absurd. Even though my personal belief has always been that Zen would be too little, too late, I'm *sure* it will be *far* better than these leaked Geekbench scores indicate.

 

[juanrga]

Something is wrong. Have a look at these 48-core Haswell-EP Xeon results (4x12 core)
http://browser.primatelabs.com/v4/cpu/42743
Single Core: 2957
Multi Core: 62615
Multi/Single: 21.75X

Zen 48 core:
Single Core:1141
Multi Core: 15620
Multi/Single: 13.69X

Shouldn't there be a bigger difference between Single and Multi Core if this is indeed a 48 core CPU? It there any chance it's 24C/48T and Geekbench detected the core count incorrectly?

Now here's a 24-Core Xeon setup:

http://browser.primatelabs.com/v4/cpu/111832
Single Core: 3292
Multi Core: 46191
Multi/Single: 14.03

Kinda makes you think - The ratio of Multi core:Single core is the same as a 24-core Intel setup.

The Zen benchmark is for 64 cores, not 48. Moreover, performance doesn't scale linearly with number of cores.

 

[juanrga]

I don't think these leaked scores are indicative of anything either. They actually show IPC that's extremely close what AMD already has in the FX series if you extrapolate from FX-8350 scores, which is just absurd.

Why would be absurd? IPC gains aren't constant across the benchmarks. 40% higher IPC than Excavator on average is compatible with Zen being only 10% faster in some benchmark.

 

[scuzzycard]

Wow, I'm really going blind with age. Either way, I was comparing the core count scaling with the Intel processor test results I listed - it's either MUCH worse than Intel's, or that core count was erroneously reported. The fact that the AMD is supposedly a 64-core just reinforces my point more.

 

[ComputerSecurityGuy]

Perhaps we are actually seeing a 32 core chip with SMT, or a dual 16 core with SMT. I have no idea how anything would view AMD SMT. I'm not a huge expert, but just a thought.

 

[juanrga]

Wow, I'm really going blind with age. Either way, I was comparing the core count scaling with the Intel processor test results I listed - it's either MUCH worse than Intel's, or that core count was erroneously reported. The fact that the AMD is supposedly a 64-core just reinforces my point more.

But I already said something like this was going to happen when I predicted 8-core dies and up-to quad-die SoC for Zen about two years ago. A quad-die design has higher latencies and power consumption than a monolithic die design. A 16-core CPU made with two 8-core dies glued together is not going to produce the same throughput than a 16-core CPU made with one 16-core die.

 

[juanrga]

Perhaps we are actually seeing a 32 core chip with SMT, or a dual 16 core with SMT. I have no idea how anything would view AMD SMT. I'm not a huge expert, but just a thought.

"L3 65536 KB x 8" says us this is a 64-core configuration with 32-cores per socket.

 

[juanrga]

One final time, using these two result sets only:

Haswell:
https://browser.primatelabs.com/v4/cpu/117877

Zen:
http://browser.primatelabs.com/v4/cpu/105227

The numbers are horrid:

Single threaded: 48.22%

Multithreaded: 114.17%

Something is SERIOUSLY wrong here; there's no way Zens multithreading can possible be this bad. Either Geekbench running into some sort of bottleneck with the Zen architecture when using Zen, the OS isn't properly handling Miltithreading for Zen, or something is seriously wrong inside Zens HW.

EDIT

Whats happening here is that Zen has significant more cores, but a lower overall score in the majority of the tests. So when I do the math, Zen's numbers look horrid. Can anyone confirm these results actually SCALE across a 64-core cluster?

Here's an example:

Haswell Multithreaded AES: 19314 = IPC * Clock * Cores
19314 = 1.6 * 12 * IPC
IPC = 1005.94

Zen Multithreaded AES: 18235 = IPC * Clock * Cores
18235 = 1.44 * 64 * IPC
IPC = 197.86

IPC deficit: 134.25%

Kind of highlights my "software scaling" argument in a nutshell. I don't think I can confidently compare multithreaded results across significantly differing core counts here, given scaling and core loading could very well be an issue.

Performance doesn't scale linearly with number of cores. When you compare a 64 core system against a 12 core system , you are artificially increasing the IPC gap of the lower-core system, in this case the Haswell Xeon.

If you want to obtain IPCs use the single thread score for both chips.

Intel HSW @1.6GHz: 1804 pts / 1.6 GHz -> 1127 pts / GHz
AMD Zen @1.44GHz: 1141 pts / 1.44 GHz -> 792 pts / GHz

IPC gap 42%.