I haven't added these results because they are without turbo. If you had half a brain you probably could figure that out, but apparently I need to spell it out for you.
(01-27-2014, 09:56 AM)delroth Wrote: [ -> ]If you had half a brain you probably could figure that out, but apparently I need to spell it out for you.
I've been on the internet long enough to learn this:
Never. Assume. Anything.
I in fact did come to a probable conclusion that no turbo was the issue, but it was never stated what the issue actually was, so I instead asked why. If I made an assumption and that assumption was wrong then it could have very easily led to accusatory language from either of us which then could have led to flaming, trolling, etc.
Nintendo Maniac 64 Wrote:NaturalViolence, you might want to change that document to not require permission just to view it as read-only.
Done. Sorry about that. I've never used google docs for public documents before.
Since turbo boost has come up as a topic of discussion I should point out that I notice some anomalies with the IPC figures of certain AMD cpus. And I think I know why. They are all cpus with turbocore. Turbocore works by dithering between two clock rates very rapidly (nanoseconds) and its effect on clock rate is undetectable at software level. For example an FX-8350 at stock will read 4.0GHz in CPUZ while its actual average clock rate over a period of time is somewhere between 4.0-4.3GHz. This throws off the clock rate measurement and therefore the IPC measurements (sometimes by more than 10% for certain models). The only real way around this would be to have all AMD users turn off turbocore in their UEFI before running the benchmark. But that would be too much work and we would have no way to make sure that they actual did it to avoid accidentally adding invalid results. Plus it would invalidate all of the current results which many users are unlikely to redo. So I guess we'll just have to live with the inaccuracy of these measurements. In most cases the turbocore clock rate in dolphin will likely be closer to the maximum value than the minimum value in the range since dolphin only uses 2 cores. So we could get a more accurate clock rate measurement by averaging the min and max together and weighting the max more strongly, say 3 to 1. This would likely be closer to the real clock rate than the reported value in the vast majority of cases. Luckily turboboost doesn't have this problem since it's detectable by software. Although it would still be slightly more accurate to have it off.
(01-27-2014, 09:07 AM)NaturalViolence Wrote: [ -> ]Since I haven't gotten a response from delroth I went ahead and did it myself to see what the numbers would be: https://docs.google.com/file/d/0B9V1dG6cTJDnVWVDaDhiaGdQYlU/edit
Interestingly the IPC figures match the ratios observed in the WW benchmark perfectly. And I mean perfectly. Nehalem, sandy bridge, and ivy bridge (assuming quad core) differ by only 5%. Haswell is 30% higher than ivy bridge. Pretty much all architectures take a 5-10% loss when they have a smaller or absent L2/L3. Piledriver with L3 is equalvalent to penryn. Nehalem is around 15% higher than both. Without the L3 cache piledriver is equivalent to K10. Bulldozer is slower than that. Followed by K8 and finally jaguar.
Haswell seems to be getting IPC gains with higher clock (10% to be exact) and i am getting the feeling that cache memory speed of haswell is probably the reason for it's higher than usual ipc gains compared to previous cpu gens. Dolphin probably favors fast cpu cache memory.
Why would you say that? If that were the case why would it have such a drastic advantage over piledriver?
Link_to_the_past Wrote:Haswell seems to be getting IPC gains with higher clock (10% to be exact)
I notice this too. And it's not only haswell. Pretty much every microarchitecture seems to display this behavior when it should logically be the reverse.
I think you guys could need a benchmark from a 1st gen Macbook Pro Retina? I might do it today, depends on if I have time.
(01-27-2014, 04:14 PM)NaturalViolence Wrote: [ -> ]Why would you say that? If that were the case why would it have such a drastic advantage over piledriver?
Link_to_the_past Wrote:Haswell seems to be getting IPC gains with higher clock (10% to be exact)
I notice this too. And it's not only haswell. Pretty much every microarchitecture seems to display this behavior when it should logically be the reverse.
Ivy bridge between 3.8 and 4,6 ghz has pretty much the same ipc on the bench, haswell chips on the other hand differ and it is a known fact that haswell lets you overclock your cache. People overclocking their haswells have also overclocked their cache to varying degrees.
CPU: i7 2600k @4.7GHz (HT disabled)
OS: Windows 7
Time: 00:09:27
Screenshot: I forgot
CPU: i7 2600k @4.7GHz
OS: Windows 7
Time: 00:09:33
Screenshot: I forgot
CPU: i7 2600k @4.6GHz (HT disabled)
OS: Windows 7
Time: 00:09:35
Screenshot: http://i.imgur.com/K23jQlg.png
CPU: i7 2600k @4.6GHz
OS: Windows 7
Time: 00:09:46
Screenshot: I forgot
CPU: i7 2600k @4.5GHz (HT disabled)
OS: Windows 7
Time: 00:09:50
Screenshot: I forgot
CPU: 17 2600k @ 4.5GHz
OS: Windows 7
Time: 00:09:58
Screenshot: I forgot
- - - -
EDIT: More benchmarks emerging including stock clocks
CPU: i7 2600k @3.8GHz (HT disabled)
OS: Windows 7
Time: 00:11:35
Screenshot: http://i.imgur.com/GilLBQT.png
CPU: i7 2600k @3.8GHz
OS: Windows 7
Time: 00:11:43
Screenshot: http://i.imgur.com/pNseuOQ.png
CPU: i7 2600k @3.4GHz (TB enabled, HT disabled)
OS: Windows 7
Time: 00:11:38
Screenshot: http://i.imgur.com/VuT6AVl.png
CPU: i7 2600k @3.4GHz (TB enabled) - BAD RUN?
OS: Windows 7
Time: 00:11:58
Screenshot: http://i.imgur.com/HUZRQEJ.png