Official AMD Ryzen Benchmarks, Reviews, Prices, and Discussion

[coercitiv]

This Ryzen Power Consumption Graph is quite informative, but the truth is Ryzen is YET to be torture tested. This is very curious to me. That P95 result is a farce.

Yup, hopefully the new wave of reviews for the R5 SKUs will also address this problem, reviewers have had time to compare results and test way more thoroughly since launch.

 

[lehtv]

This Ryzen Power Consumption Graph is quite informative, but the truth is Ryzen is YET to be torture tested. This is very curious to me.

That P95 result is a farce.

https://bbs.io-tech.fi/threads/amd-ryzen-7-1700.23308/page-2#post-710631
Translation:

It seems Prime95 isn't yet "optimized" for Ryzen, so I would expect it to produce a higher load in the future. Perhaps @The Stilt can shed light on this(?)

Custom settings: Minimum FFT Size: 128, Maximum FFT Size: 128, Run FFTs in place, version 28.10 produces maximum load. Other settings (mainly SmallFFT) only occasionally.

The "Ryzen optimized" 29.10 version works even worse (in terms of power consumption) than the older 28.10 on stock settings...

In other words, Tom's Hardware was using Prime95 settings (SmallFFT) that don't generate maximum load. So yes, indeed the P95 result is a farce

 

[Atari2600]

It's obvious I was addressing your claim that Ryzen is a "furnace". But it's also obvious that you belong on ignore lists.

Yep. Your right.

Too much trolling and now he's on my ignore list.

Probably should have went straight onto the ignore list before I even read any of his posts due to that username alone....

 

[Carfax83]

H.264 is by far the most widespread codec in use today. It will remain so in the next couple of years, especially if the applications where h.265 really shines, ie. 4K, are restricted to particular CPUs and GPUs with FFHs.

How many recording devices can directly output in h.265? I know of a few Samsung cameras, but it exited the semi-pro/enthusiast camera market.

H.264 processing power is still relevant.

I agree with everything you say here, but that still doesn't mean I was wrong in what I said. H.264 doesn't utilize modern CPUs effectively as it's very old, and it's still on the way out and will be completely replaced by either H.265/266 or AV1 in the near future. 4K and HDR are already here, and in just another year they will be much more prevalent than they are today, and consumers will be demanding content.

As for performance, it keeps improving. Remember that H.264 has had a decade of optimization behind it, both software and hardware. H.265 is inherently designed for much more massively parallel processing and SIMD, and it is improving at a rapid pace. In the end, the optimal result will probably be to use a massively parallel processor like the GPU or an ASICs for the areas of encoding that can be easily parallelized, whilst using the CPU for the rest.

From what I've read, hardware accelerated encoding still provides inferior results in terms of image quality and file size compared to software.

 

[Carfax83]

About bandwidth Ryzen's soon upcoming 12/16c x399 processors will have double of the memory bandwidth by having four memory channels like Intel. How this plays with their CCX communication is yet to be seen, but probably you can at least have more memory and keep the higher memory clocks.

It's not just main memory bandwidth, but cache bandwidth as well. Haswell and up L1 cache has 64/32 bytes load/store per cycle, whilst Zen to my knowledge does 2*16 byte loads per cycle and one 16 byte store:

Zen:

Haswell, Broadwell and Skylake:

 

[french toast]

If you cant find a valid way to torture ryzen, that has to be good right?

 

[raghu78]

Nice to see the Ryzen optimizations to Oxide Games' Nitrous engine and the resulting improvements to performance in AoTS. 16-20% in CPU focussed benchmarks and upto 30% in GPU focussed benchmarks

https://www.computerbase.de/2017-03...ashes-of-the-singularity-escalation-1920-1080

https://www.pcper.com/reviews/Processors/Ashes-Singularity-Gets-Ryzen-Performance-Update

http://www.legitreviews.com/amd-ryzen-performance-update-released-ashes-singularity_193137

AMD needs to improve its developer relations and focus on popular game engines and game studios. The Bethesda AMD partnership is a good one. But AMD need more of such partnerships like they have Oxide Games or Bethesda. I think the big catch needs to be AMD with Epic as the Unreal engine is very popular and probably the most licensed PC/console game engine. AMD also have to push for more AAA titles under Gaming Evolved where Nvidia leads with their Gameworks program.

 

[tamz_msc]

It's not just main memory bandwidth, but cache bandwidth as well. Haswell and up L1 cache has 64/32 bytes load/store per cycle, whilst Zen to my knowledge does 2*16 byte loads per cycle and one 16 byte store:

Zen:

Haswell, Broadwell and Skylake:

AIDA64 measures exactly half the L1 bandwidth of the 6900K on the Ryzen 8-core, which is expected. However, the L2 and L3 bandwidth as measured properly by the newest version is vastly superior on Ryzen.

Most of the latency issues seem to stem from the inter-CCX penalty more than anything else.

 

[Abwx]

In other words, Tom's Hardware was using Prime95 settings (SmallFFT) that don't generate maximum load. So yes, indeed the P95 result is a farce

Smaller FFTs induce higher power comsumption because more operands and instructions can be low level cached, FI Hardware.fr use 256K FFTs and this is enough to get Intel s CPU up to their stock TDPs, if they use 128K FFTs then TDP is exceeded by 30% according to their own measurements...

Anyway i find ironic that the smaller FFT "argument" is used in complete reversal of the truth, all that is ultimately displayed by this site is their sheer incompetence...

 

[VDA-RTR]

Blog AMD
https://community.amd.com/community/gaming/blog/2017/03/30/amd-ryzen-community-update-2

 

[Malogeek]

Blog AMD
https://community.amd.com/community/gaming/blog/2017/03/30/amd-ryzen-community-update-2

BIOSes based on this new code will have four important improvements for you

1. We have reduced DRAM latency by approximately 6ns. This can result in higher performance for latency-sensitive applications.
2. We resolved a condition where an unusual FMA3 code sequence could cause a system hang.
3. We resolved the “overclock sleep bug” where an incorrect CPU frequency could be reported after resuming from S3 sleep.
4. AMD Ryzen™ Master no longer requires the High-Precision Event Timer (HPET).

 

[Glo.]

 

[Despoiler]

BIOSes based on this new code will have four important improvements for you

1. We have reduced DRAM latency by approximately 6ns. This can result in higher performance for latency-sensitive applications.
2. We resolved a condition where an unusual FMA3 code sequence could cause a system hang.
3. We resolved the “overclock sleep bug” where an incorrect CPU frequency could be reported after resuming from S3 sleep.
4. AMD Ryzen™ Master no longer requires the High-Precision Event Timer (HPET).

I need this in my life!

 

[krumme]

BIOSes based on this new code will have four important improvements for you

1. We have reduced DRAM latency by approximately 6ns. This can result in higher performance for latency-sensitive applications.
2. We resolved a condition where an unusual FMA3 code sequence could cause a system hang.
3. We resolved the “overclock sleep bug” where an incorrect CPU frequency could be reported after resuming from S3 sleep.
4. AMD Ryzen Master no longer requires the High-Precision Event Timer (HPET).

Yeaa great news already. 6ns better dram latency yes thank you. And next

"We will continue to update you on future AGESA releases when they’re complete, and we’re already working hard to bring you a May release that focuses on overclocked DDR4 memory."

 

[Atari2600]

Blog AMD
https://community.amd.com/community/gaming/blog/2017/03/30/amd-ryzen-community-update-2

Excellent. 6ns of DRAM latency reduction and a promise of further work on higher rated DDR4.

 

[IEC]

Excellent. 6ns of DRAM latency reduction and a promise of further work on higher rated DDR4.

More to come...

I'm not in a position to say, but latency reduction is not the only way we can improve performance with future updates. I'm sure there's more to come, so stay tuned…

 

[Zucker2k]

Smaller FFTs induce higher power comsumption because more operands and instructions can be low level cached, FI Hardware.fr use 256K FFTs and this is enough to get Intel s CPU up to their stock TDPs, if they use 128K FFTs then TDP is exceeded by 30% according to their own measurements...

Anyway i find ironic that the smaller FFT "argument" is used in complete reversal of the truth, all that is ultimately displayed by this site is their sheer incompetence...

You again? A few months ago, you were backing bjt2 on some impossible power/clock mispredictions. It's a bit audacious of you to call The Stilt's (and so far confirmed) findings that Prime 95 load on Ryzen is borked, 'incompetent.' Where is your own work on the subject? Post it, I would love to read it.

 

[HutchinsonJC]

H.264 doesn't utilize modern CPUs effectively as it's very old, and it's still on the way out and will be completely replaced by either H.265/266 or AV1 in the near future.

What are you talking about? I don't think you follow the development of h264 encoders as well as you think you do. x264 already has been utilizing avx2 and x264's ability to use more threads has been improved some few times in the last couple or few years.

x264 is one of, if not the most, worked on video encoder and it's staying power is pretty immense. 265 has a long way to go to improve on everything x264 already has BEEN doing. There's not a lot of advantage in even using 265, yet, and 265 is SLOW.

I can pull from the change log just 3 days ago on x264 tweaks involving AVX2 specifically. I can also scroll through the change log and look at tweaks involving AVX2 that go back to Feb of 2014. And I didn't even try hard to find these changes. Edit: And there were a whole bunch of entries between these two dates involving AVX2.

Maybe your favorite encoding programs are just slow to use the newest releases of x264.

Edit some more: detection of AVX2 support was added to x264 back in 2012. That doesn't really mean it could do anything amazing with a CPU's AVX2 capability at that time, but it tells you they were eye balling AVX2 to take advantage of since at least then, and if I remember right from doom9 forums at that time frame (2012), developers of x264 were working close with engineers at Intel.

Feb 2012 x264 change log:
"TBM, AVX2, FMA3, BMI1, and BMI2 CPU detection support
TBM and BMI1 are supported by Trinity/Piledriver.
The others (and BMI1) will probably appear in Intel's upcoming Haswell.
Also update x86inc with AVX2 stuff"

 

[lolfail9001]

You again? A few months ago, you were backing bjt2 on some impossible power/clock mispredictions. It's a bit audacious of you to call The Stilt's (and so far confirmed) findings that Prime 95 load on Ryzen is borked, 'incompetent.' Where is your own work on the subject? Post it, I would love to read it.

Oh, he jumped into technical thread confusing forest for trees, you could look it up there. But that's OT.

Anyways, what i found curious is that apparently even Oxide started to treat AotS as nothing but a benchmark, considering that those improvements did not translate into the very real game of AotS at all (inb4 mentions of memory and drivers): http://www.pcgameshardware.de/Ryzen...ecials/AMD-AotS-Patch-Test-Benchmark-1224503/

EDIT: Oh, and btw, nice to see they shaved off a fairly solid bit of latency. Only question is whether it applies to all configs or just the best case that may or may not be relevant to people using fast memory.

 

[Abwx]

You again? A few months ago, you were backing bjt2 on some impossible power/clock mispredictions. It's a bit audacious of you to call The Stilt's (and so far confirmed) findings that Prime 95 load on Ryzen is borked, 'incompetent.' Where is your own work on the subject? Post it, I would love to read it.

Where and when did i made irrelevant predictions..?..

I was spot on for both IPC and Power comsumption, as for frequency i was certainly more on point than most people here with some going as far as "predicting" 2.8-3.0GHz base frequencies...

As for Prime 95 and Ryzen it s just that the latter s FPU is very efficient, that the most plausible explanation, FI Hardware.fr use the same FFTs for all CPUs :

http://www.hardware.fr/articles/939-3/overclocking-pratique.html

http://www.hardware.fr/articles/946-4/overclocking-consommation.html

Pour la charge nous optons pour Prime95 25.8 64 bits avec une taille de FFT fixe à 256K, qui nous permet à la fois de mesurer la consommation dans un cas de stress très important (la consommation est 30% supérieure à celle obtenue avec un logiciel plus classique) et de valider le couple fréquence/tension.

Edit : For Ryzen they got more power comsumption under an X264 loading than with Prime 95 while all Intel and previous AMD CPUs exhibit the opposite behaviour, wich point to said FPU efficency.

 

[formulav8]

considering that those improvements did not translate into the very real game of AotS at all

You don't consider an 11% increase @ 720p and 13% @ 1080p in actual game performance as not translating into very real world improvement's from a first patch?

BTW, I doubt many were thinking real world, unique use scenerios would see a 20%+ increase like the factory bench loop.

 

[lolfail9001]

You don't consider an 11% increase @ 720p and 13% @ 1080p in actual game performance as not translating into very real world improvement's from a first patch?

When put like that it indeed sounds good, but then you look at minimum fps... And cry, if you have any remembrance of what 18 fps looks like.

Though my biggest quip with it is that it completely contradicts the game's very own "CPU" benchmark, (let alone GPU one) casting doubt on usability of AotS benchmark even for AotS measurements.

 

[lolfail9001]

Edit : For Ryzen they got more power comsumption under an X264 loading than with Prime 95 while all Intel and previous AMD CPUs exhibit the opposite behaviour, wich point to said FPU efficency.

It is much simpler than that: Prime95 for whatever reason uses K10 code path (without any AVX/FMA to speak of) or so it seems to me:

Spoiler

 

[DrMrLordX]

It does not stop 4Ghz+ Ryzen from being a furnace akin to 4.3-4.4Ghz 6900k. 3.3-3.5Ghz Ryzen? Oh yeah, it is efficient. 4Ghz? Not a chance.

My power measurements do not show an 1800x @ 4.0 GHz to be a furnace at all. Running an AVX workload with 1.35v vcore and Level 3 LLC (Prime95) showed a package power of 125W. Upping LLC to level 1 (which raised vcore to ~1.4v during heavy load) running an AVX workload showed a package power of 145W.

y-cruncher showed similar power draw results.

It is much simpler than that: Prime95 for whatever reason uses K10 code path (without any AVX/FMA to speak of) or so it seems to me:

Was that the latest Prime95?

 

[sushukka]

It's not just main memory bandwidth, but cache bandwidth as well. Haswell and up L1 cache has 64/32 bytes load/store per cycle, whilst Zen to my knowledge does 2*16 byte loads per cycle and one 16 byte store:

Zen:

Haswell, Broadwell and Skylake:

True, but as tamz_msc mentioned new version of AIDA shows different results. Also double sized L2 comparing Intel gives AMD some advantage. However, the biggest drawback with Zen is its CCX specific L3 cache as only 8MB can be used per CCX. If one core would need the whole cache, it would be forced to use Infinity Fabric for reaching the whole L3, which is fast, but way slower than the normal Lx cache requests. I assume that somewhere here is also the reason why we haven't seen 4+2 or 4+0 CCX combinations yet eg. 1500X have four cores (could fit to one CCX) but 16MB L3. Still wondering why the 4c variants with 8MB L3 are not using only one CCX, but maybe it has something to do with the Infinity Fabric, yields...only AMD knows.

Caches are one of the most important processor design areas. It's always some kind of compromise to fit enough caches and still have room for all the other logic. It's like the most expensive memory there are. Areas where you need to have consistent throughput and serve lots of different type of loads, you need to buff the caches up eg. in the IBM's z series machines there can be maximum of ~4GB processor caches alone in one barebone. Games tend to be cache sensitive so maybe here is the actual reason why Intel have had slight advantage in game benchmarks with its more traditional design. Having good results by speeding up the CCX interconnection with OCing your memory bus seems to underline this aspect.

It will be interesting to see if the upcoming x390/x399 will accelerate the Infinity Fabric, are there any changes to the cache structure and what those extra memory channels (rumors: x390: 4, x399: 16(!)) bring up. Either way AMD's Infinity Fabric, which is basically kind of an improved HyperTransport variation, will be in center of their new products. As it can scale all the way to 512GB/sec it will be used in Ryzen and also Vega products soon...and that brings up lots of interesting viewpoints how AMD's GPUs/APUs/CPUs will be connected in the future and what kind of synergy advantages there could be...