AMD Ryzen (Summit Ridge) Benchmarks Thread (use new thread)

[krumme]

Unless AMD never had a genuine intention or the real ability to ship any Zeppelins (regardless of the segment) in 2016, then they've had the final silicon available for months now. A newer die revision might technically exists even if AMD had a genuine intention to release them in 2016, however there is so far exactly zero indication about that. All of the three Zeppelin's we've seen so far have been ZP-A0 revision: The one displayed by Lisa Su at Computex, and both of the two SKUs benchmarked with AotS. "Michael Yuan Feng" who benchmarked and leakaged the AotS results appears to be a Chinese or Taiwanese person. Given the timing of these leaks, most likely this person either works for a system manufacturer (e.g. HP) or a OEM. In either case there is no need for AMD to send early prototypes (i.e non-qualification samples) to anyone outside the company for several reasons:

- To contain the leaks (impossible once the parts have entered China or Taiwan)
- Zeppelin is not required in order to design and validate the AM4 motherboards, initially. At least two of the biggest motherboard manufacturers used Bristol Ridge AM4 parts for the purpose. Same way the initial work on AM3+ was performed with AMD K10 chips. FM2 platforms were an exception and TN-A0 silicon was handed out, since there was no compatible CPUs / APUs which could be used until the final silicon arrived
- If newer than A0 silicon revision existed, why would AMD hand out superceded revision to a partner for qualification? By the time the leak occured the "newer revision" (whatever it would be, non A0) must have existed for ~ three months (to meet the requirement of launch capability in 2016).

Only AMD knows the truth, however I believe that they might have ended up to the same conclusion as I have: A newer die revision might not yield significant improvements in any of the critical areas and there are larger gains to be had from the process maturation itself. If that's the case then the obvious solution would be sit back and wait (postpone the launch and hope for the best). Based on the characteristics of Zeppelin and the issues AMD has had with all of their past designs (CPUs since K7 and GCN GPUs), I would expect that the first thing to limit the Fmax of the design itself would be the L2 caches. If that's the case then a newer die revision wouldn't make much of a difference, since there is no way you can change the latency of the caches with a simple respin. Despite the cache latency on Zeppelin can be considered as aggressive, I still believe Zeppelin will at least initially be limited by the manufacturing process and not by the design itself. If that's the case and there is a clear trend for the process improving to be seen, then postponing the launch would be the only right thing to do.

The serious profit is on server side - just look at Intel dcg profit. The critical part bar none is the basic efficiency as it also defines/or shaped by base freq on the server parts. Besides ipc base freq of the 24c 150w and 32c 180w is most critical. As profit on selling those parts is derived from TCO difference to Intel solutions even small changes in efficiency can have a profound impact on the pricing. Its primarily about cost of maintanance, space, power & cooling. If efficiency is not very compettitive / very close, the product is simply not getting sold. At all. Because its then simply more TCO than the competing solution.
As opposed to eg mobile og desktop where less compettitive product is sold all the time.

 

[The Stilt]

Perhaps AMD wants to see Intel's Kabylake release before it releases Zen? I give Dr. Su credit for holding fast on her timelines.

There seems to be a fair amount of pentup "demand" for Zen so it should sell well when released.

AMD needs a solid release that tightens the gap with Intel. The difference can come in price.

Not likely, since the only thing they can do about is to lower their prices. The same applies on any non-EOL Intel product released after Ivy Bridge of course.

 

[The Stilt]

Ok, based on Zauba Zeppelin is currently in it's third minor revision (ZP-A0c) and that's the one AMD is currently shipping to the partners.
Exactly the same parts which were benched in the AotS leak.

 

[blublub]

Ok, based on Zauba Zeppelin is currently in it's third minor revision (ZP-A0c) and that's the one AMD is currently shipping to the partners.
Exactly the same parts which were benched in the AotS leak.

How on earth are they going to get that released in 2016, that would be an A0 or A1 release then as There seems to be only time for one more fab cycle before production has to start.

Or did production if chips get faster?

 

[mohit9206]

Zen to be as fast as Haswell i5.Even if Zen is 20% cheaper than Kaby Lake i5,it still loses in performance per $. So why the hype?
Also i'll remember this quote when Zen reviews start hitting later this year.

This is the first time in a very long time that we engineers have been given the total freedom to build a processor from scratch and do the best we can do. It is a multi-year project with a really large team. It's like a marathon effort with some sprints in the middle. The team is working very hard, but they can see the finish line. I guarantee that it will deliver a huge improvement in performance and power consumption over the previous generation. ”
— Suzanne Plummer, Zen team leader, on September 19th, 2015

 

[The Stilt]

Zen to be as fast as Haswell i5.Even if Zen is 20% cheaper than Kaby Lake i5,it still loses in performance per $. So why the hype?
Also i'll remember this quote when Zen reviews start hitting later this year.

I'd say "...and do the best we can do." is the key part here.

 

[Phynaz]

"An early engineering sample" of a product, which was supposed to launch in retail within ~ three months? "A primitive motherboard", which happens to be the exactly same as the one for a product already launched (on paper, Bristol Ridge AM4)?

It's possible the leaks are old devices. Although myslef I wouldn't expect devices that old to be in partners hands. I would assume that partner platform validation devices would be essentially shipping product. Any major change would require re-validation.

Edit:
Nevermind, you said all this much better than I did!

 

[Zstream]

Don't know about you, but a 16 threaded SB/Haswell level IPC is just right up my alley! I'd love to see how this thing performs in Hyper-V and VMware, along with AVX2 crunching.

 

[The Stilt]

along with AVX2 crunching.

You may forget AVX2 crunching on Zen.

 

[Sinnfrei]

Exactly the same parts which were benched in the AotS leak.

2D2801A2M88E4 - This is the SR from the Ashes Benchmark
2D2801A2M88EA - This is the SR from Zauba

Shouldn't that be the Microarchitecture and core revision?

 

[The Stilt]

2D2801A2M88E4 - This is the SR from the Ashes Benchmark
2D2801A2M88EA - This is the SR from Zauba

Shouldn't that be the Microarchitecture and core revision?

I don't have the definitions for Zeppelin, however in the past that has been the die revision. In the shipping manifest it clearly says A0C (and A0) for both of them so I would guess that is typo (4 and A can be confused quite easily). Also in the past the roadmap code (2801 in this case) has changed when the stepping changes.

 

[Erenhardt]

Or just a fail on someones part. 4 looks almost like A if your sight is not good, or the writing not clear.

 

[ogbbv]

Do anyone of you know why they have so complex numbers? is it the "identity" of the chip or do it say something about were and when its made etc?
Sorry for stupid question but just got curious when the stilt mentioned 2801 is a roadmap code.

 

[The Stilt]

Do anyone of you know why they have so complex numbers? is it the "identity" of the chip or do it say something about were and when its made etc?
Sorry for stupid question but just got curious when the stilt mentioned 2801 is a roadmap code.

There is no hidden information in the ES SKU. The roadmap code is the only additional information, as the retail SKUs don't include the clock frequency (just the model number). 2801 roadmap code means that the base frequency is 2.8GHz.There can be a completely different part with 2802 roadmap code, however both of them would have 2.8GHz base frequency.

 

[Zstream]

You may forget AVX2 crunching on Zen.

Oh, why is that?

 

[The Stilt]

Oh, why is that?

Pretty inefficient, at least compared to >= Haswell.
Even Excavator can do AVX2 but it only slows the application down.

 

[PhonakV30]

AMD APU with Haswell IPC is EPIC! until Intel releases something like APU.

So AMD APU with 4 Zen Core ( running at 4GHz ) should be really good value.

 

[NostaSeronx]

@The Stilt - XOP & AVX2 perform about the same on Bristol Ridge. Both are faster than SSE4.1/AVX binaries. AVX2 in Visual Studio and DirectX has depreciated XOP.

SSE4.1; 0.52 seconds
AVX; 0.54 seconds
XOP; 0.46 seconds
AVX2; 0.48 seconds

Do to the ± error rate;
SSE4.1/AVX are range 1 thus perform exactly the same.
XOP/AVX2 are range 0 thus perform exactly the same.

SSE tends to be preferred if you take the error rate into the measure. Most AVX code paths tend to favor Intel which the error rate might have exposed. It should be ignored as AVX/AVX2 generic becomes the new norm. AMD and VIA both support AVX2 with their modern mainstream/essential products.

 

[itsmydamnation]

Pretty inefficient, at least compared to >= Haswell.
Even Excavator can do AVX2 but it only slows the application down.

You are confusing a multitude of different components here from a mobile optimized CON module(seems to have odd FP pipeline utilization issues vs piledriver) and then applying it to the part of Zen that isn't even remotely similar between CON and Zen.

The FPU design is completely different, Zen has lower latency pipes and it connects differently ( only to one set of load/store pipelines).
Also remember AVX2 != 256bit, AVX2 is a set of mainly INT SIMD instructions that align to equivalent AVX FP SIMD instructions, both of these can be either 128bit or 256 bit. What will likely be the bottleneck is the 128/256bit load store vs >haswell but that doesn't mean Zen core = 50% of haswell core. For one intel downclocks for 256bit workloads ( there is no free lunch) and atleast in spec fp load/store is around 45-55% of operations so while a 128bit load store will create bottlenecks it wont be all the time. In the worest case it will be 50% but in the best case probably something like 70% (per clock). But at this stage for right now in enterprise/cloud/personal computing you will find far more SSEx.x then AVX/FMA and the FPU seems to target that traditional workload.(we can thank intel for that on multiple fronts (atom+cel/Pentium)

With the rumors of 48core Zen+ cpu's for 7nm i wouldn't expect 256bit ops then either as that would be a ~300% increase in throughput the cache fabric would need to provide.

 

[jpiniero]

Well, there is AVX-512 that Skylake Server and Cannonlake support, it's not just AVX2. You probably will have to downclock to use it but it would surely be quite a bit faster than AVX2. That could be a problem for sure if Zen really doesn't have full speed AVX2.

 

[Zstream]

Pretty inefficient, at least compared to >= Haswell.
Even Excavator can do AVX2 but it only slows the application down.

Hmm, that sucks.

 

[superstition]

For one intel downclocks for 256bit workloads ( there is no free lunch)

Maybe AVX should be spun off into a separate processor. I remember when CPUs were used to do all the work of a GPU. Of course, they have absorbed the FPU and MMU chips...

 

[itsmydamnation]

Well, there is AVX-512 that Skylake Server and Cannonlake support, it's not just AVX2. You probably will have to downclock to use it but it would surely be quite a bit faster than AVX2. That could be a problem for sure if Zen really doesn't have full speed AVX2.

So a few things here:
1. Software support, AVX 512 is going to be way more fragmented then AVX is, how long before anyone cares?

2. Load store bandwdith, unless they double L/S (one of the most expensive parts of a core for both power and size) to be 4 times that of Zen then unless you can keep your work in registers 512bit avx is in the same place Zen is for 256bit.

3. What do you mean by "full speed". >Haswell FP pipes are all FMA and have longer latency then Zen so if the data is in registers even with back to back execution on Zen 256bits will execute quicker, Intel has 2 main pipes for FP that are 256bit, Zen has 4 pipes (effectively 2add, 2mul) that are 128bit. The execution time isn't an issue (speed), throughput in 256bit ops per clock will be a fair bit lower for Zen then >haswell because of load/store bandwidth, but are you going to buy an 8-10 intel chip anytime soon? I know im not dropping the $2500 a i7-6950 costs in OZ. The 8 core @ $1600 is far more reasonable

Its worth remembering TAM, how much TAM increase does intel get by adding large amounts of IPC, how much TAM does intel get by displacing exsisting FPGA/ASIC/DSP/etc by deploying new instructions/features into Core. What Intel does isn't necessarily the best thing for general computing, its the best thing for Intel to make money*. AMD has such a low Server TAM at the moment that all they need to do is general computing well to see a massive increase in TAM.

* I have no problem with this

 

[TurtleCrusher]

People are making snap judgments from a benchmark that is wholly unreliable and not particularly static in terms of predictable performance.

If someone actually had this on their hands, they'd benchmark a well known bench and not this. If they really have the ES on hand and used this bench, they really had to cherry pick pretty hard to put it in a negative light.

 

[TurtleCrusher]

- Core i7-4770 4C/8T 3.4-3.9 GHz (2013 Haswell)
Average: 66.0 FPS
Normal batch: 74.5 FPS
Medium batch: 69.5 FPS
Heavy batch: 56.6 FPS

- Core i7-6700K 4C/8T - 4.0 GHz (2015 Skylake)
Average: 107.3 FPS
Normal batch: 125.7 FPS
Medium batch: 113.8 FPS
Heavy batch: 89.2 FPS

This tells you everything you really need to know. Assuming the 4770k is locked at 3.4Ghz, it still supposedly is 38% faster per clock. If the 4770k is at 3.9Ghz, it is 59% faster per clock. We know neither of these to be the case. The bench is unreliable and not speculation based off of these supposed numbers are no better than a rumor.