Ryzen: Strictly technical

[KompuKare]

The cache values are very confusing.

8-core Ryzen:

L1 cache: 768 KB
L2 cache: 4.0 MB
L3 cache: 16.0 MB

Hm, Broadwell-E Sixteen Core with a bit of photo editing?
Something like this perhaps:
http://ark.intel.com/products/91768
L1 = 1MB (64KBx16)
L2 = 4MB (16x256KB)
L3 = 40MB
Seems a big coincidence.

 

[Atari2600]

The cache values are very confusing.

8-core Ryzen:

L1 cache: 768 KB
L2 cache: 4.0 MB
L3 cache: 16.0 MB

Indeed. Now does it reflect a fake image or does it reflect windows not properly reading the cache sizes? But that wouldn't explain the 1MB L1.

I suppose a possible explanation would be that Ryzen isn't a fully enabled Zeppelin.

Currently its...

L1: 96 KB/core
L2: 512 KB/core
L3: 8MB/4cores (2MB/core)

So scaling by 16 gives (approx):
L1: 1.5 MB
L2: 8 MB
L3: 32 MB

Which doesn't make sense --- so I'd have to assume the screen grab is a fake.

 

[Atari2600]

Hm, Broadwell-E Sixteen Core with a bit of photo editing?
Something like this perhaps:
http://ark.intel.com/products/91768
L1 = 1MB (64KBx16)
L2 = 4MB (16x256KB)
L3 = 40MB
Seems a big coincidence.

Good catch. That's what it is. Fake.

 

[PhonakV30]

I checked cpu-world's Database and found all Intel's CPUs with 40Mb L3 cache and 4M L2 cache but all are 512Kb L1 cache.Highest clock for Xeon is E5-2698A v3.

 

[KompuKare]

I checked cpu-world's Database and found all Intel's CPUs with 40Mb L3 cache and 4M L2 cache but all are 512Kb L1 cache.Highest clock for Xeon is E5-2698A v3.

I didn't find it on ark.intel.com so I looked up the Wiki on Broadwell-E which said 64KB per core (when why I wrote 16 x 64KB = 1024KB).
https://en.wikipedia.org/wiki/Broadwell_(microarchitecture)
Obviously those Xeons don't run anywhere close to 4GHz but that could have been faked?

 

[beginner99]

Good catch. That's what it is. Fake.

And going by fotoforensics which I actually don't full understand but it looks clearly fake:

Look at the Text for example of CPU Name: Completely different (ELA) than other parts.
Also the image has a metadata creation date in November 2016 and a last modified on march 22 2017.

 

[looncraz]

And going by fotoforensics which I actually don't full understand but it looks clearly fake:

Look at the Text for example of CPU Name: Completely different (ELA) than other parts.
Also the image has a metadata creation date in November 2016 and a last modified on march 22 2017.

Yep, someone put a lot of work into it... I'm guessing they modified much of the test just to hide the usage of a different font.

 

[PhonakV30]

I didn't find it on ark.intel.com so I looked up the Wiki on Broadwell-E which said 64KB per core (when why I wrote 16 x 64KB = 1024KB).
https://en.wikipedia.org/wiki/Broadwell_(microarchitecture)
Obviously those Xeons don't run anywhere close to 4GHz but that could have been faked?

by using search in CPU-world First
1) Set Manuf = Intel then Click "show Data"
2) Set Family = Xeon then again Click "show Data"
3) L2 = 4M , L3= 40960 then show data

https://ibb.co/hSuVov

 

[coercitiv]

And going by fotoforensics which I actually don't full understand but it looks clearly fake:

Look at the Text for example of CPU Name: Completely different (ELA) than other parts.
Also the image has a metadata creation date in November 2016 and a last modified on march 22 2017.

The person who faked that SS made two obvious mistakes.
1) Used JPEG compression for the resulting file. This allows for the kind of detection used by fotoforensics.
2) Used Photoshop or other similar image editor to edit text in the image using the image editor text renderer. This introduces a different kind of flaw, that can be easily seen with the naked eye once zoomed in.

Notice the colored pixels around most of the text? That text is rendered using subpixel rendering, a tehnique used throughout the OS to increase the apparent resolution of the font at the expense of a small but otherwise indistinguishable quality loss. Normally all the text is rendered this way, including this one.

Notice the text with no colored pixels around it? That text is rendered using an image editor which only uses classic anti-aliasing.

Here's what can be done with a bit more care, although most of this stuff is not worth the effort.

 

[PhonakV30]

The person who faked that SS made two obvious mistakes.
1) Used JPEG compression for the resulting file. This allows for the kind of detection used by fotoforensics.
2) Used Photoshop or other similar image editor to edit text in the image. This introduces a different kind of flaw, that can be easily seen with the naked eye once zoomed in.

Notice the colored pixels around most of the text? That text is rendered using subpixel rendering, a tehnique used throughout the OS to increase the apparent resolution of the font at the expense of a small but otherwise indistinguishable quality loss. Normally all the text is rendered this way, including this one.

Notice the text with no colored pixels around it? That text is rendered using an image editor which only uses classic anti-aliasing.

 

[lolfail9001]

My 2600k reliably showed 19ns with DDR3-2133 CL9 memory in most memory latency tests.

You sure it was not software you tested it with tripping up? Because checking AIDA results over internets, it sits around that 40ns region for 2600ks. In better cases.

The person who faked that SS made two obvious mistakes.

Three, you forgot caches.

 

[coercitiv]

Three, you forgot caches.

I was only talking from an image quality point of view.

 

[CatMerc]

Can't confirm but


Infinity Fabric can have a bandwidth up to 100GB/S


Wow

That would mean DF running at double memory clock would it not?
3200MT/s memory, AKA 1600MHz, would be 51.2GB/s right now. I don't see 6400MT/s memory coming anytime soon, so we have to be talking higher data fabric speeds.

 

[tamz_msc]

Regarding that fake SS, the Arial-type font of the utilization numbers is a dead giveaway.

 

[sm625]

I cant believe someone would fake a task manager screen shot. To what end? I have a SS of my task manager saying my CPU is running at 6.45GHz, and it isnt fake.

 

[IEC]

I cant believe someone would fake a task manager screen shot. To what end? I have a SS of my task manager saying my CPU is running at 6.45GHz, and it isnt fake.

It'd be easier to hook into the process and change some numbers to make it appear legit, anyways.

 

[looncraz]

You sure it was not software you tested it with tripping up? Because checking AIDA results over internets, it sits around that 40ns region for 2600ks. In better cases.

AIDA always showed about 40ns, but Sandra, PCMark, and a couple other benchmarks reliably show ~19ns. I suspect the ~40ns number in AIDA is round-trip and the ~19ns elsewhere is one-way.

Those other benchmarks also show Ryzen as having 60~70ns latencies instead of 80~100ns latencies.

I just now realized this might be a difference between read and write latency. I already know that Ryzen has a write coalescing buffer which will increase latency for writes (which really isn't such a big deal).

Great, more code to write... I'm gonna put that on my list and just keep working on getting http://zen.looncraz.net/ live (I have yet to generate even half the charts, but I have all but 8C/8T numbers).

 

[looncraz]

So, I just ran my Handbrake test (a full DVD rip of Masterminds, 1200kbps MKV, AC3 PassThru). On Sandy Bridge the choice of reading the disc from a mechanical hard drive wasn't an issue - the CPU was consistently maxed. It slowed Ryzen down some in stage 1 (but that is a short stage, anyway).

i7-2600k @ 4.5GHz, DDR3-2133 19-19-19-? 2T
Time: 13:41
Power: 282W (full system, including monitors)

Ryzen 1700X @ 3.925GHz, DDR4-2667 16-16-16-38 1T
Time: 7:41
Power: 241W (Full system, including monitors)

Yeah... that's insane. ~40W less and 6 minutes faster. I would have probably shaved 30 seconds by reading from a DVD instead of from a mechanical hard drive... but I didn't run it that way on the 2600k.

 

[imported_jjj]

So, I just ran my Handbrake test (a full DVD rip of Masterminds, 1200kbps MKV, AC3 PassThru). On Sandy Bridge the choice of reading the disc from a mechanical hard drive wasn't an issue - the CPU was consistently maxed. It slowed Ryzen down some in stage 1 (but that is a short stage, anyway).

i7-2600k @ 4.5GHz, DDR3-2133 19-19-19-? 2T
Time: 13:41
Power: 282W (full system, including monitors)

Ryzen 1700X @ 3.925GHz, DDR4-2667 16-16-16-38 1T
Time: 7:41
Power: 241W (Full system, including monitors)

Yeah... that's insane. ~40W less and 6 minutes faster. I would have probably shaved 30 seconds by reading from a DVD instead of from a mechanical hard drive... but I didn't run it that way on the 2600k.

Figured that we need a new metric, MT IPC.
With substantial differences in SMT yield and platforms with many cores, ST IPC is of little importance on these platforms but MT IPC is relevant.
One can test SMT yield but doing it by running a MT task on a single core with 2 threads would make it easier for folks to understand the metric. Ofc as an alternative one can do MT results per number of cores to compute MT IPC.

 

[looncraz]

Figured that we need a new metric, MT IPC.
With substantial differences in SMT yield and platforms with many cores, ST IPC is of little importance on these platforms but MT IPC is relevant.
One can test SMT yield but doing it by running a MT task on a single core with 2 threads would make it easier for folks to understand the metric. Ofc as an alternative one can do MT results per number of cores to compute MT IPC.

I already have done some of those tests 1C/2T

SMT scaling is pretty insane (~40%). I've also found very little in the way of an SMT penalty (sometimes 3% or so of a loss with SMT enabled and a single thread locked to a single core without the SMT logical core being parked)... but it's a pretty tricky thing to reliably quantify... it's basically inside the noise floor.

Update:

I've found a few examples where the SMT penalty is rather large, going through the numbers in their final form... but I've not found this play out in real application... just two synthetic benchmarks.

3.925GHs, DDR4-2667 16-16-16-38 1T

AIDA64 PhotoWorxx:
SMT ON: 21,567
SMT OFF: 24,805
Penalty: 13%

AIDA64 VP8 (6700k scores 7,521 @ 4Ghz, so both results here are awesome)
SMT ON : 7,748
SMT OFF: 9,336
Penalty: 17%

Cinebench R10 Single Threaded
SMT ON: 4,774
SMT OFF: 4,923
Penalty: 3%

Cinebench R11.5 Single Threaded
SMT ON: 1.55
SMT OFF: 1.62
Penalty: 4%

Cinebench R15 Single Threaded
SMT ON: 150
SMT OFF: 160
Penalty: 6%

Most example, of course, show no change at all with or without SMT enabled.

 

[looncraz]

Ashes of the Singularity patch gives Ryzen as much as 30% more performance!!

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

 

[tamz_msc]

I already have done some of those tests 1C/2T

SMT scaling is pretty insane (~40%). I've also found very little in the way of an SMT penalty (sometimes 3% or so of a loss with SMT enabled and a single thread locked to a single core without the SMT logical core being parked)... but it's a pretty tricky thing to reliably quantify... it's basically inside the noise floor.

Update:

I've found a few examples where the SMT penalty is rather large, going through the numbers in their final form... but I've not found this play out in real application... just two synthetic benchmarks.

3.925GHs, DDR4-2667 16-16-16-38 1T

AIDA64 PhotoWorxx:
SMT ON: 21,567
SMT OFF: 24,805
Penalty: 13%

AIDA64 VP8 (6700k scores 7,521 @ 4Ghz, so both results here are awesome)
SMT ON : 7,748
SMT OFF: 9,336
Penalty: 17%

Cinebench R10 Single Threaded
SMT ON: 4,774
SMT OFF: 4,923
Penalty: 3%

Cinebench R11.5 Single Threaded
SMT ON: 1.55
SMT OFF: 1.62
Penalty: 4%

Cinebench R15 Single Threaded
SMT ON: 150
SMT OFF: 160
Penalty: 6%

Most example, of course, show no change at all with or without SMT enabled.

PhotoWorxx uses AVX2 - so does it mean that the SMT penalty is more pronounced in such types of workloads?
The real mystery is the VP8 benchmark - given what it tests, the performance hit that SMT causes is weird.

 

[looncraz]

PhotoWorxx uses AVX2 - so does it mean that the SMT penalty is more pronounced in such types of workloads?
The real mystery is the VP8 benchmark - given what it tests, the performance hit that SMT causes is weird.

Yeah, but VP8 almost always scales with frequency more than anything else. The 4Ghz quad-core 6700k beats the 3.6GHz six-core 6850k - 7521 to 6932... which is fully explainable with the frequency difference.

It's pretty strange considering the test nearly maxes out every core (16 threads at 85~90%)... but that might be explainable if the VP8 test itself is actually single threaded and it has locking overhead that slows down the Julia output, meaning performance is being restricted by locking contention... less threads = less contention = higher score.

RE: AVX, that actually makes sense -the uop, retire, and store queues are statically shared but rarely used for one work load as much as they can be with SIMD. AVX, in particular, could be like issuing twice as many uops for the same task as normal, making the penalty come to light in a very clear manner.

 

[ndtech]

I already have done some of those tests 1C/2T

Please test Ryzen at 2.4 GHz with two cores in GeekBench 4.
So we can estimate Ryzen IPC relative to Apple A10 and Cortex-A73.
You can find details about these tests in another thread:
http://www.portvapes.co.uk/?id=Latest-exam-1Z0-876-Dumps&exid=threads/x86-and-arm-benchmark.2501859/

 

[imported_jjj]

I
Update:

I've found a few examples where the SMT penalty is rather large, going through the numbers in their final form... but I've not found this play out in real application... just two synthetic benchmarks.

3.925GHs, DDR4-2667 16-16-16-38 1T

AIDA64 PhotoWorxx:
SMT ON: 21,567
SMT OFF: 24,805
Penalty: 13%

AIDA64 VP8 (6700k scores 7,521 @ 4Ghz, so both results here are awesome)
SMT ON : 7,748
SMT OFF: 9,336
Penalty: 17%

Cinebench R10 Single Threaded
SMT ON: 4,774
SMT OFF: 4,923
Penalty: 3%

Cinebench R11.5 Single Threaded
SMT ON: 1.55
SMT OFF: 1.62
Penalty: 4%

Cinebench R15 Single Threaded
SMT ON: 150
SMT OFF: 160
Penalty: 6%

Most example, of course, show no change at all with or without SMT enabled.

Is that with the latest AIDA64? And if it is , have results changed in any of the tests, aside from L3$.