TR Forums

mikewinddale wrote:

Thanks for the Ryzen results. But I'm a little bit confused. I thought the Ryzen 5 1600 had a base clock of 3.2 GHz and a turbo of 3.6 GHz. (See AMD's product description: https://www.amd.com/en/products/cpu/amd-ryzen-5-1600).

Can you please clarify? Is this an under-clock and an over-clock? Or did AMD change the specs at some point?

OP did a standard test, with all processors @ 2.4GHZ. He did the same, underclocking the Ryzen to match the others frequency for comparison's sake

Alright so I tried my laptop, but thanks to Speedstep it's difficult to get an exact cpu speed.

From looking at the cpu max clock I believe it looks like

9.406 at 3.8
9.828 at 3.7
10.281 at 3.6

Xeon 1505mv6 ddr4 2400 ecc @ 17,17,17,39,2t (it's a mobile Kaby Lake)

mikewinddale wrote:

Can you please clarify? Is this an under-clock and an over-clock? Or did AMD change the specs at some point?

I underclocked it to 2.4 and normally have it overclocked to 3.75.

You wanted bulldozer? Well I have a piledriver.
https://en.wikipedia.org/wiki/List_of_A ... 82013.29_2







This is completely default stock. I'll recheck the bios to see if I can fix the speed.

I love how that P3 is almost as fast as a P4 clocked nearly a GHz higher.
Have an old Athlon 800MHz I can dust off and test if anyone's interested.

Found a bios option to turn off "CPB" with that off it seemed to cap the CPU at 2125MHz.

While running CPUz and SuperPi, @ 2125 it took ~44 seconds.
turning CPB back on...
And running CPUz and SuperPi, @ 2825 it took ~31.5 seconds.

MileageMayVary wrote:

Found a bios option to turn off "CPB" with that off it seemed to cap the CPU at 2125MHz.

While running CPUz and SuperPi, @ 2125 it took ~44 seconds.
turning CPB back on...
And running CPUz and SuperPi, @ 2825 it took ~31.5 seconds.

Thanks for the Piledriver results! So it looks like these are actually slower than K8 at x87, clock-for-clock. I had a hunch that the shared FPU would hurt Bulldozer in this type of benchmark; just didn't think it would be that bad.

setaG_lliB wrote:

I overclocked my Phenom II x6 1090T to just over 4GHz.
Phenom II (Thuban) at 4070MHz - 16GB CL9-9-9-24 1760MHz dual channel DDR3 - 512KB L2+6MB L3: 15.063s

Which is still slower than Haswell at 2.4GHz with a single channel of cheap (CL11 DDR3-1600) memory.
It's nice to see that Ryzen is a good bit faster than Ph2 at SuperPi. Though I don't have one to confirm, I'm thoroughly convinced that a Bulldozer-derived chip would end up being well behind Ph2 at this particular benchmark.

I'd like to know what you did to achieve that overclock. I'm running an 1100T and would be interested.

Mr Bill wrote:

setaG_lliB wrote:

I overclocked my Phenom II x6 1090T to just over 4GHz.
Phenom II (Thuban) at 4070MHz - 16GB CL9-9-9-24 1760MHz dual channel DDR3 - 512KB L2+6MB L3: 15.063s

Which is still slower than Haswell at 2.4GHz with a single channel of cheap (CL11 DDR3-1600) memory.
It's nice to see that Ryzen is a good bit faster than Ph2 at SuperPi. Though I don't have one to confirm, I'm thoroughly convinced that a Bulldozer-derived chip would end up being well behind Ph2 at this particular benchmark.

I'd like to know what you did to achieve that overclock. I'm running an 1100T and would be interested.

I boosted the base clock to 220MHz and set the multi at 18.5x. I had to increase the voltage to just under 1.5v. 4070MHz was the most I could do with this CPU, and not all Phenom IIs will be able to do 4GHz. Even under a big Noctua NH-D14, the CPU was hitting 82C under Prime95.

I think it was alluded to earlier, but all the PI benchmarks are probably very to latency as much as FPU efficiencies. I think you drew the wrong conclusion from the K7 to K8 jump; the IMC vs NB probably contributed to most of that speedup. Otherwise the execution latencies at the instruction level are not too dissimilar between the two. I usually use Agner's x86 instruction latency tables if I'm handcoding some assembly. I don't know what is the x87 instruction mix for SuperPi though.
http://www.agner.org/optimize/instruction_tables.pdf

I know this doesn't really contribute much, but as a related bit of history/trivia re: x87

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Comment #109 is pretty humorous (it's actually taped on my wall out of frustration with floating point some days).

CampinCarl wrote:

I know this doesn't really contribute much, but as a related bit of history/trivia re: x87

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Comment #109 is pretty humorous (it's actually taped on my wall out of frustration with floating point some days).

I thought this was quite well known behavior of the x87 unit. Well stepping out of the 80s and closer to the new millennium, I could have sworn there were discussion about this as well when 3DNow/SSE math functions were created back when those instructions first made their appearances.
(Speaking of which, the 8087 and 80287 were not completely IEEE-754 compliant; the first x87 chip to be compliant would have been the 80387 which was then backported to the 80287 and sold as the 80287XL; some of which ended up being paired with 80386s)

Yeah, anyone who has done a significant amount of floating point programming on x87 is probably aware of the "long double" internal data type issue.

More generally (and this doesn't apply to just x87), it is a very bad idea to use tests for exact equality of floating point values. Unless the values were calculated via an identical code path, roundoff errors can cause values which should be identical (in a mathematical sense) to differ slightly in the least significant bits. For example, if you've assigned x = 1.0 / 3.0, then later compare the value of x * 6.0 for equality with 2.0, it may (and in fact probably WILL) compare NOT equal.

I ran it on my Intel DX2-66 for kicks. 2 hours, 1 minute.
I used Win 3.1, I wonder if that makes a difference, being 16 bit?
Edit: never mind, forgot I had Win32s on it.

seeker010 wrote:

I think it was alluded to earlier, but all the PI benchmarks are probably very to latency as much as FPU efficiencies. I think you drew the wrong conclusion from the K7 to K8 jump; the IMC vs NB probably contributed to most of that speedup. Otherwise the execution latencies at the instruction level are not too dissimilar between the two. I usually use Agner's x86 instruction latency tables if I'm handcoding some assembly. I don't know what is the x87 instruction mix for SuperPi though.
http://www.agner.org/optimize/instruction_tables.pdf

If K8's IMC is what provided most of the boost in SuperPi, then Core 2's excellent Pi performance becomes even more interesting. It does extremely well with an old fashioned FSB. Moving the memory controller on-chip didn't give Intel much of a boost in this benchmark. Haswell is 4 generations ahead of Wolfdale.

AMD E350 (Bobcat) 1.6GHz

Average for 5 runs: 49 seconds.

MileageMayVary wrote:

AMD E350 (Bobcat) 1.6GHz

Average for 5 runs: 49 seconds.

Yikes, less than 50% slower than Piledriver. I finally had to give up my E-350 netbook because of no new video drivers, of all things. :/

The Snapdragon 835 found in most flagship phones this year is also at 2.4(5)GHz so I thought I'd run the Android version of SuperPi. It's probably not as well optimized as it could be but just an interesting datapoint I thought.

4.665 seconds to 1M
27.615 seconds to 4M

just brew it! wrote:

Yeah, anyone who has done a significant amount of floating point programming on x87 is probably aware of the "long double" internal data type issue.

More generally (and this doesn't apply to just x87), it is a very bad idea to use tests for exact equality of floating point values. Unless the values were calculated via an identical code path, roundoff errors can cause values which should be identical (in a mathematical sense) to differ slightly in the least significant bits. For example, if you've assigned x = 1.0 / 3.0, then later compare the value of x * 6.0 for equality with 2.0, it may (and in fact probably WILL) compare NOT equal.

Here's a whole web page devoted to different techniques for comparing potentially inexact floating point values: https://randomascii.wordpress.com/2012/ ... 2-edition/

setaG_lliB wrote:

seeker010 wrote:

I think it was alluded to earlier, but all the PI benchmarks are probably very to latency as much as FPU efficiencies. I think you drew the wrong conclusion from the K7 to K8 jump; the IMC vs NB probably contributed to most of that speedup. Otherwise the execution latencies at the instruction level are not too dissimilar between the two. I usually use Agner's x86 instruction latency tables if I'm handcoding some assembly. I don't know what is the x87 instruction mix for SuperPi though.
http://www.agner.org/optimize/instruction_tables.pdf

If K8's IMC is what provided most of the boost in SuperPi, then Core 2's excellent Pi performance becomes even more interesting. It does extremely well with an old fashioned FSB. Moving the memory controller on-chip didn't give Intel much of a boost in this benchmark. Haswell is 4 generations ahead of Wolfdale.

In the talk I think Pat Gelsinger made at around the time Core 2 launched called "Into the Core" (should still be able to find it on the net), someone asked him about when Intel was going to bring the memory controller onboard, and he wasn't sure when. His answer as to why at the time he didn't give a yes was something like "because we have really great caches".

So my guess is that cache performance (and large L2 caches, the 45nm Core 2 had 6MB) masked not having an integrated memory controller.