Sharing Ryzen 1700 vs i7-6700 result [Archive]

cojj

10th March 2017, 10:21

I7 rig - all stock setting
R7 rig - o.c'd to 3.7ghz + running at 1.24v (under-volted) + 24c idle/70c after 2days of non-stop 100% usage, cheap evo 212 air cooled) + $650nzd ~= $450usd for cpu+mobo

Encoded 720p and 1080p video with veryslow preset + 19.9 crf.

x265 [info]: HEVC encoder version 2.3+17-6e348252e902
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
x265 [info]: Main 10 profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 3 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 3 inter / 3 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut / bias: 23 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 5 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-19.9 / 0.60
x265 [info]: VBV/HRD buffer / max-rate / init : 12000 / 12000 / 0.900
x265 [info]: tools: rect amp limit-modes rd=6 psy-rd=2.00 rdoq=2 psy-rdoq=1.00
x265 [info]: tools: rskip signhide tmvp b-intra strong-intra-smoothing deblock
x265 [info]: tools: sao

1080p:
i7: encoded 2208 frames in 2345.17s (0.94 fps), 3186.52 kb/s, Avg QP:22.74
r7: encoded 2208 frames in 1479.63s (1.49 fps), 3186.52 kb/s, Avg QP:22.74

720p:
i7: encoded 2208 frames in 1209.50s (1.83 fps), 1404.07 kb/s, Avg QP:22.15
r7: encoded 2208 frames in 859.33s (2.57 fps), 1404.45 kb/s, Avg QP:22.15

Attached are screenshots of cpu usage when encoding 1080.

ChaosKing

10th March 2017, 10:39

Could you also add a second ryzen test with smt disabled? It should be a bit faster.

Atak_Snajpera

10th March 2017, 10:55

With this you will have 100% cpu utilisation
http://forum.pclab.pl/topic/1184884-x265-FHD-Benchmark/

CruNcher

10th March 2017, 12:07

Interesting seeing that most reviews compare vs i7-7700

though Intels 6 core mainstream answer is already ready for departure if rumors are correct and that should obviously reach those values and go slightly above even @ 6C/12T, but yeah for Mainstream still insane 3 FPS even 4 or 5 would be unusable for AVG users :D

but still nice how close AMD gets now pretty unoptimized :)

cant wait the results with Ataks suggestion utilizing the threads more efficient on both and how that looks then under both 100% utilization target :)

i guess you'll endup fully utilized somewhere at the I7-6600K result in that Benchmark database

cojj

10th March 2017, 20:47

As requested - from this result seems like ryzen is ~10% slower than Haswell-e/ ~22% faster than Sandy Brdge, clock to clock/core to core/thread to thread . I was getting near full utilization (occasional small dips)

Interesting seeing that most reviews compare vs i7-7700
Maybe it's because they are in the same price range. As for me, I only have mutiple i7-6700 and a r7-1700 xD

Atak_Snajpera

10th March 2017, 21:54

Run also this http://forum.pclab.pl/topic/1105978-FlopsCPU-klasyczny-benchmark-z-1992-roku-w-nowej-oprawie/ on this overclocked Ryzen.

cojj

10th March 2017, 22:09

Run also this http://forum.pclab.pl/topic/1105978-FlopsCPU-klasyczny-benchmark-z-1992-roku-w-nowej-oprawie/ on this overclocked Ryzen.

Here you go. Please evaluate these numbers and share your conclusion :)

CruNcher

10th March 2017, 23:30

The new Intel 6 Core Mainstream (6C/12T) gonna smoke it, now Intel just has to set the price right ;)

But nothing really has changed Intel is still 1 Generation ahead and smokes AMDs Core architecture with less core count and same 14 nm target ;)

But yeah if AMD would never made it we would never have seen Intel adapting prices to it but surely the 6C/12T will still be a small overall amount more expensive when it hits soon.

Thus why Raven Ridge will be so interesting Intels GPU is still not on the same level overall to compete on the level like AMDs CPU now competes with it :)

The Time was overall not enough for Intel to advance it even if they made very huge steps on the GPU side as well, sponsored mainly by their shrinking time to market advantage that slowly vanishes thx to AMDs corporation with Samsungs Semiconductor part.

microchip8

10th March 2017, 23:38

The new Intel 6 Core Mainstream (6C/12T) gonna smoke it, now Intel just has to set the price right ;)

Got something to back that up?

CruNcher

10th March 2017, 23:58

Wait and see ;)

You could also look at those benchmarks and understand that Intel is in that Workload more advanced with it's instruction currently and that they just hold the price high till now ;)

Bloax

11th March 2017, 00:53

Could you also add a second ryzen test with smt disabled? It should be a bit faster.

Disabling SMT only helps in limited threading scenarios (e.g. games), not things like video encoding which utilize all available threads.

burfadel

11th March 2017, 01:02

The new Intel 6 Core Mainstream (6C/12T) gonna smoke it, now Intel just has to set the price right ;)

It's gonna smoke? So it will have thermal issues? :sly:

Got something to back that up?

The 6-core Coffee Lake CPU, which is a modified Kaby Lake, is expected to be released in February 2018. Its release roughly coincides with the second generation Zen, known as Zen+. Sure, you can compare the performance of 6-core Coffee Lake to Zen, but you might as well compare Zen to Haswell and not Skylake.

Also keep in mind we might not have seen exactly how well Ryzen performs yet, seeing as there's the scheduler bug, a performance processor driver on the way (allegedly), bios optimisations, as well as optimisations for specific titles.

cojj

11th March 2017, 01:28

Run also this http://forum.pclab.pl/topic/1105978-FlopsCPU-klasyczny-benchmark-z-1992-roku-w-nowej-oprawie/ on this overclocked Ryzen.

Here you go. Would appriciate if you could sharing your evaluation on these results.

microchip8

11th March 2017, 01:32

It's gonna smoke? So it will have thermal issues? :sly:

The 6-core Coffee Lake CPU, which is a modified Kaby Lake, is expected to be released in February 2018. Its release roughly coincides with the second generation Zen, known as Zen+. Sure, you can compare the performance of 6-core Coffee Lake to Zen, but you might as well compare Zen to Haswell and not Skylake.

Also keep in mind we might not have seen exactly how well Ryzen performs yet, seeing as there's the scheduler bug, a performance processor driver on the way (allegedly), bios optimisations, as well as optimisations for specific titles.

How much of an improvement will Coffee Lake be over Kaby Lake? If it's the same (read: virtually nothing) as Skylake -> Kaby Lake, then I doubt it will gone "smoke" anything

cojj

11th March 2017, 01:57

Hello everyone. Let's stay on topic and try not to sepculate the future - maybe we can do that on another thread.

To help with the discussion => Currrently (2017-03-11), with above results, is r7-1700 the best processor to get for pure x265 encoding machine? I think its pretty decent perf/$?

Run also this http://forum.pclab.pl/topic/1105978-FlopsCPU-klasyczny-benchmark-z-1992-roku-w-nowej-oprawie/ on this overclocked Ryzen.

I uploaded the result but doom9 forum says it will post it after a moderator reviews it. In the meantime, a txt version of the result is as follows:

test/single/muti/ratio
x86/52.1M/593M/11.4
x87/3.34G/28.3G/8.5
SSE2/8.87G/87.2G/9.8
AVX/11.1G/111G/10.0
AVX2/18.0G/153G/8.5

@Atak_Snajpera => I would appriciate your evaluation of these results as I find your knowledge very insightful.

Bloax

11th March 2017, 04:19

The r7-1700 is the best processor in terms of price/high-performance to get for video encoding at the moment if you manually overclock it to 3.7-3.9 Ghz, yes.

hajj_3

11th March 2017, 09:26

But nothing really has changed Intel is still 1 Generation ahead and smokes AMDs Core architecture with less core count and same 14 nm target ;)

Intel's 14nm FF+ is WAY better than the 14nm that AMD is using, it is more like 12nm in comparison. Therefore intel has a power and temperature advantage over AMD. If AMD has the same process they could increase clock speeds to make their chips more competitive in games.

Intel's motherboards for their 6, 8 and 10 core processors are far more expensive than amd's boards. Intel still hasn't reduced the prices for their chips yet either so i can't see intel's 6 core being a best seller due to the cost.

p.s i hope someone can compare 2400mhz ram vs 3200mhz ram using ryzen and kaby lake with x264 and x265 so that we can see what effect it has performance on intel and amd as previous amd architectures gave significant performance increases with faster memory, much more so than intel.

Atak_Snajpera

11th March 2017, 12:01

test/single/muti/ratio
x86/52.1M/593M/11.4
x87/3.34G/28.3G/8.5
SSE2/8.87G/87.2G/9.8
AVX/11.1G/111G/10.0
AVX2/18.0G/153G/8.5

@Atak_Snajpera => I would appriciate your evaluation of these results as I find your knowledge very insightful.
Can you post screenshot as well? Upload images to http://imgsafe.org/ or https://cubeupload.com/

Updated Flops table
http://i.imgsafe.org/41ba1e2822.png

for comparison KabyLake@5.1GHz
http://fs5.directupload.net/images/170211/doyk2oew.jpg

NikosD

11th March 2017, 18:18

R7 rig - o.c'd to 3.7ghz + running at 1.24v (under-volted) + 24c idle/70c after 2days of non-stop 100% usage, cheap evo 212 air cooled) + $650nzd ~= $450usd for cpu+mobo

Hey,

Is it possible to run both apps and post your results - FlopsCPU (single core) and x265 benchmark (GUI) - but by disabling from your BIOS:

a) Precision Turbo
b) SMT ("hyper-threading")
c) XFR

also disable 6 cores (if possible) in order to have only 2 active and make sure your CPU runs at 3.0GHz and stays there.

So, you will end up to a RyZen 2C/2T@3.0GHz in order to directly compare it with Sandy and Haswell.

Here is my updated post:
https://forum.doom9.org/showthread.php?p=1800292#post1800292

It would be extremely useful if you keep the log files (txt) created by FlopsCPU, in order to further analyze the FPU of RyZen and upload them too as a zip file.

ShogoXT

12th March 2017, 06:32

Did this in a hurry. OCed to 3.6ghz, but didnt reformat yet, so its not optimal. Cant disable cores, made sure power is on high performance mode. Dont have my noctua yet, so will have to OC more later.
http://i.imgur.com/TpqPXcr.jpg
http://i.imgur.com/HNdZO5z.jpg
http://i.imgur.com/EZlIW5K.jpg

NikosD

12th March 2017, 06:43

There is a huge fluctuation in your results regarding to multicore performance of FlopsCPU, which is a secure indicator that precision turbo and XFR were having a party.

In order to compare small differences you have to at least disable those two, if disabling cores is impossible, in order to keep your clock stable during tests.

ShogoXT

12th March 2017, 07:23

Actually I had ran that with discord open after streaming on youtube with Ryzen, playing World of Warcraft. The FPU program actually froze a couple times getting those results. If I ever get around to reformatting it should clear up. Pretty sure XFR and Turbo disable automatically when overclocking. At least one of those does. XFR only increases by 50mhz.

NikosD

12th March 2017, 07:38

test/single/muti/ratio
x86/52.1M/593M/11.4
x87/3.34G/28.3G/8.5
SSE2/8.87G/87.2G/9.8
AVX/11.1G/111G/10.0
AVX2/18.0G/153G/8.5

There is an issue here.

It seems that optimized Intel FP SIMD SSE2/AVX/AVX2-FMA3 code has a weird behavior running on AMD RyZen.

The logical steps for RyZen's SIMD HW according to Intel's hardware and compiler optimizations should be:

Ryzen SSE2 about 2.3x faster than x87

Ryzen AVX about 2x faster than SSE2

Ryzen AVX2-FMA3 about unknown times faster than AVX

We now get:

RyZen SSE2 about 2.7x faster than x87 (close , a little faster)

RyZen AVX about 25% faster than SSE2 (extremely slow)

RyZen AVX2-FMA3 about 62% faster than AVX (too fast)

RyZen's SSE2 performance is beyond Intel's 2.27-2.35x jump over scalar x87, it's around 2.65x, but they are close.

The first step could mean not so optimized scalar code x87 for RyZen, slower x87 performance of RyZen or faster SSE2 implementation of RyZen vs Intel.

But the next steps are very difficult to explain.

From SSE2 to AVX, Intel gains ~100% performance, RyZen gains 25%

This is completely unexplained, even more than low DX12 performance in gaming.

RyZen seems to gain 100% over SSE2, using AVX2-FMA3 and 62% over AVX.

Completely unpredictable behavior, possibly due to Intel compiler optimizations regarding to RyZen's HW SIMD implementation.

I don't know if there is any difference running that test using Win 7.

It shouldn't for Single Core results.

The above results explain the very low performance running AVX single precision in Tom's hardware scientific tests here:
http://www.tomshardware.com/reviews/amd-ryzen-7-1800x-cpu,4951-10.html

RyZen when running Intel optimized FP SIMD code, gains a lot leveraging AVX2-FMA3 code compared to SSE2 and AVX and looses a lot leveraging AVX code compared to Intel.

NikosD

12th March 2017, 11:32

OK...

I might have an explanation of that almost 1/2 performance of Ryzen compared to Intel for AVX1 (FP32/FP64) which can be seen as only 25% gain over SSE2 code for Ryzen.

The Intel compiler probably expects only 2 execution units for AVX, because Intel's HW has only 2.

So, it gives 1x256bit FADD AVX instruction to 1x128bit FADD AVX instead of 2x128bit FADD AVX that Ryzen has, because it thinks there is only 1 FADD inside.

So instead of splitting the 256bit instruction to 2x128bit registers in order to work simultaneously, now the 128bit register has to process two times the same 256bit instruction.

The same of course goes for FMUL, but I think the compiler can give two FMULs at the same time due to Intel's HW capability, so that's why we don't have exactly half performance but a little lesser.

That would explain the performance loss and I think is feasible for Intel to change/patch that behavior of its compiler or for AMD to do that automatically maybe with a microcode update (?).

I'm not sure about that.

These are wild guesses of course, for that huge surprise of AVX1 FP32/FP64 performance.

Atak_Snajpera

12th March 2017, 13:33

I always thought that AMD cpus are smart enough to automatically split 1x256 instruction into 2x128 bit. It looks like since AMD FX nothing has been changed in this matter so I wouldn't wait for some magic microcode update.

Sagittaire

12th March 2017, 20:32

well I think that x265fhd benchmark can't work really good with Rysen because x265fhd use multiple instance and Rysen have specific limitation in L3 cache.

Moreover, 5 instance for x265 in same time is not reallistic situation: nobody make encoding like that, and particulary with x265.

@cojj

use simply "--pme" command to optimize thread charge for rysen in 720p and 1080p

If you want really compare speed at CPU charge 100% for Rysen vs Intel, use simply 4K source with --pme command.

NikosD

12th March 2017, 20:40

We have results from two users only, which are very contradicting because although they have small differences in clock, the performance difference is big.

The users are not professional reviewers or IT professionals and we don't know the exact conditions of systems tested.

x265 FHD benchmark scales better than any other I have seen, but maybe we need 4K samples for better scaling.

Atak_Snajpera

12th March 2017, 20:42

NikosD

12th March 2017, 20:47

RyZen is not Sandy+.

Its IPC starts from just little lower than Sandy and goes up to Kabylake for some workloads.

RyZen R7 is the best 8C/16T cpu you can buy nowadays and will stay that way for a long time.

Sagittaire

12th March 2017, 20:52

Well I've already told you that for 16T cpu you must use atleast two instances of x265. Your magic commands won't change anything. I've tested mutiple switches and always 2 instances were overall faster. I think you are expecting too much from AMD's 8 core "SandyBridge+" cpu. ALU is only ~13% faster than in K10 architecture from 2010.

anyway your x264fhd test don't produce coherent result, it's like that ... ;-)

in cojj test you have:

1080p:
i7: encoded 2208 frames in 2345.17s (0.94 fps), 3186.52 kb/s, Avg QP:22.74 with CPU at 100%
r7: encoded 2208 frames in 1479.63s (1.49 fps), 3186.52 kb/s, Avg QP:22.74 with CPU at 50%

Atak_Snajpera

12th March 2017, 20:57

Sagittaire

12th March 2017, 20:59

Results do not lie. x86 is between sandybridge and ivybridge. AVX+FMA is a disaster. Only SSE2 looks good but still not near SkyLake. AMD once again fight with Intel using old method called "MoAr CoRes!".

it's true, Result do not lie ... ;-)

http://www.hardware.fr/getgraphimg.php?id=446&n=10

and in serious test you have R7 1800X on par with i7-6900K.

Atak_Snajpera

12th March 2017, 21:04

it's true, Result do not lie ... ;-)

http://www.hardware.fr/getgraphimg.php?id=446&n=10

and in serious test you have R7 1800X on par with i7-6900K.

Show cpu usage in those tests and then we will talk. I guarantee that x265 wasn't saturating 10c/20t in 100%. Average usage in 1080p for 16T is around 75%.

NikosD

12th March 2017, 21:05

We have already said too many times, that FP SSE2, AVX and FMA3 have nothing to do with x265 application.

Only integer performance matters here and it's about x64, SSEx and AVX2 integer.

x64 is faster on RyZen, you can't see that from FlopsCPU but from the latencies and thoughput of instructions.

The same is true for SSEx.
RyZen is at least as fast as Kabylake.

The only performance drop is when using integer AVX2, but as you said it has double cores so...

RyZen is faster than the fastest 4C/8T from Intel using x265.

Sagittaire

12th March 2017, 21:08

Show cpu usage in those tests and then we will talk. I guarantee that x265 wasn't saturating 10c/20t in 100%. Average usage in 1080p for 16T is around 75%.

CPU charge with R7 is comparable to i7-6900K. You have the same limitation here (8C/16T).

Anyway it's simple to saturate thread for 8C/16T: use simply 4K source with --pme command. It's in x265 documentation.

Atak_Snajpera

12th March 2017, 21:11

Anyway it's simple to saturate thread for 8C/16T: use simply 4K source with --pme command. It's in x265 documentation.
Too synthetic test for me. Most people work with 1080p sources (Blu-ray discs and so on). Trust me.

RyZen is faster than the fastest 4C/8T from Intel using x265.
Let's be honest difference is not huge.

Sagittaire

12th March 2017, 21:12

Too synthetic test for me. Most people work with 1080p sources (Blu-ray discs and so on). Trust me.

seriousely, multiple instance for x265 is by far more synthetic test ... :rolleyes:

and HEVC codec is the official codec for UHD BluDisk ... not H264.

HEVC is particulary designed for UHD encoding.

NikosD

12th March 2017, 21:19

x265 is an extremely optimized AVX2 integer application.

Haswell using x265 optimized for AVX2 is 70% faster than Sandy at the same clock.

So, it's like a miracle that RyZen is faster on x265 than Kabylake which has faster clocks and full AVX2 integer implementation.

@Atak

Is it possible to upgrade your benchmark to 4K HEVC encoding ?

Atak_Snajpera

12th March 2017, 21:20

seriousely, multiple instance for x265 is by far more synthetic test ...
No it is not. I constantly run two instances on my Xeon using Distributed Encoding.

and HEVC codec is the official codec for UHD BluDisk ... not H264.
See torrent sites and tell me how many 4k rips you have there.

HEVC is particulary designed for UHD encoding.
And so what. Most people use x265 for 1080p blu-ray rips. Maybe you should tell them to stop using x265 in this case?

So, it's like a miracle that RyZen is faster on x265 than Kabylake which has faster clocks and full AVX2 integer implementation.
I can reverse your sentence. It is miracle that despite 8 threads and FMAC256 (more heat) SkyLAke/KAbyLake can overclock to ~5GHz and still compete with double cores.

Sagittaire

12th March 2017, 21:27

Is it possible to upgrade your benchmark to 4K HEVC encoding ?

I have benchmark in preparation with x264 (1080p) and x265 (2160p) encoding.

If you use --pme mode with 1080p source (with higher preset than medium) you have 75% CPU charge with 8C/16T.

Unfortunaly --pmode is not usefull because you desactivate reflist option (usefull for speed in x265).

I can reverse your sentence. It is miracle that despite 8 threads and FMAC256 (more heat) SkyLAke/KAbyLake can overclock to ~5GHz and still compete with double cores.

no, simply because R7 CPU charge is not at 100% but more at 50% with 8C/16T for 1080p source and default x265 setting.

and you have same theoric IPC for CPU 4C/8T at 5.0 Ghz than 8C/16T at 2.5 Ghz (for same achitectural CPU)

CruNcher

12th March 2017, 21:31

clocks are dead threading workload efficiency is the future of chip and core design.

Atak_Snajpera

12th March 2017, 21:32

no, simply because R7 CPU charge is not at 100% but more at 50% with 8C/16T for 1080p source and default x265 setting.
Not in my benchmark...

Sagittaire

12th March 2017, 21:36

Not in my benchmark...

your benchmark don't produce usuable result ... it's like that ... :search:

Atak_Snajpera

12th March 2017, 21:36

clocks are dead threading workload efficiency is the future of chip and core design.

Less cores + more IPC + Higher clocks is always better than
MoAr CoReS + less IPC + Lower clocks

https://i.stack.imgur.com/HTTmC.png

Sagittaire

12th March 2017, 21:41

Less cores + more IPC + Higher clocks is always better than
MoAr CoReS + less IPC + Lower clocks

https://i.stack.imgur.com/HTTmC.png

seem don't work for GPU ... or calculator station.

or even with x264:

http://www.hardware.fr/getgraphimg.php?id=446&n=9

Atak_Snajpera

12th March 2017, 21:42

your benchmark don't produce usuable result ... it's like that ... :search:

Oh really?
RyZen 1700@3.7GHz = 25.5 fps
5960X@4.4GHz = 33.9 fps

If we could overclock RyZen to 4.4GHz we would get
4.4/3.7*25.5=30.3 fps

33.9/30.3=1.12

Haswell architecture in x265 encoding is 12% more efficient than Zen. According to flops results (ALU) haswell is 14% faster than Zen. Pretty accurate don't you think?