I use this CPU in a motherboard, does not officialy supporting top FX series. Also, my ram is running on low mhz. Only 1700. Cinebench and render software's are preferring high ram settings.
That's always been one of my biggest tech "what-ifs" of the last few years. In general the L3 cache gave the Phenom II a ~10% advantage over a similarly clocked Athlon II. Llano was effectively neck and and neck with a similarly clocked Phenom II, or again about 10% ahead of the Athlon II. Now that could entirely be chalked up to the move from a 4x512kB L2 to a 4x1MB arrangement and it might have lessened the gains from an L3. Regardless, I still would love to have seen what an 8 core variant with the iGPU cut and a decent sized L3 slapped on. Considering how often the FX line failed to provide a meaningful boost in multi-threaded performance over Thuban, an additional pair of cores and some minor architectural tweaks might have been enough to negate any need for Bulldozer. Considering how nicely the GF 32nm SHP process matured, we might have seen this chips breaking 4Ghz too.
The Stilt's testing suggested that L3 is overrated in importance on Piledriver because it's slow. So, since it seems to be able to equal or beat Phenom in a lot of areas — once clocks are raised to compensate for its design choice to rely on clocks, I wonder how much L3 would matter for Phenom. Maybe it would matter more. However, if Piledriver's L3 had been faster then maybe it would have helped it more as well. Having two extra cores plus more L3 may have been enough, though, to make Bulldozer/Piledriver unnecessary. I don't know. This is all guesswork. It's clear, though, that AMD left Phenom behind for a reason.
I would back off the MHz and see what kind of score you can get. Are you using BCLK to overclock? Can you use just multiplier? Can you set the FSB to 2400? From what I recall of my testing, I don't think RAM speed, in MHz, is actually all that important for Cinebench R15 and Piledriver. I did, though, see a big boost from bumping up CPU NB voltage once when testing at 4.6. That's probably because I was using such aggressive RAM timings and the CPU NB just needed more power to handle it. I don't think the 2133 9-11-10-30-1T is necessarily that much of an improvement over something like 1800 or 1900 which is what I was originally running.
superstition said:
Despite the lacking nature of the equation it certainly shows us one thing...superstition said:
As I suggested in other posts, try to keep NB multiplier to a non prime number (12, 15 or 16) and keep core multiplier under double that. Then rise BCLK. I would suggest NB 2400, core 4800 (best because the multipliers are exact multiple) and then rise bclk... Try to reach 5200 and then try with bclk=100 and NB=2600 and core=5200 to see if there is differences with prime multiplier. If the core doesn't reach 5200 in the first try, lower bclk under 100MHz in the second try with 26x ad 52x multiplier to match the clock of first try...
I use 4 ram modules, which makes some impact on performance in negative way. My NB is running at 2544 mhz. My weakness is 9-10-9-1T @1700 mhz on ram. Tested it. Also the bios is not optimized well. I got the beta from Gigabyte, which allows me to run this CPU. No throttling etc. . Everything is to max performance.
Debian 9, Blender 2.78a, MSM8974AB (HTC One M8)
custom compiled (gcc 6.1.1): 12 minutes 41 seconds
Debian 8, Blender 2.72 32-bit, MSM8992 (Snapdragon 808, Nextbit Robin)
repository binary: 9 minutes 54 seconds
Debian 8, Blender 2.78 64-bit, MSM8992 (Snapdragon 808, Nextbit Robin)
custom compiled (gcc 6.2.1): 5 minutes 43 seconds
Debian 9, Blender 2.78a, Core i5 6200U
official binary: 2 minutes 3 seconds
custom compiled (gcc 6.2.1): 2 minutes 1 second
Debian 9, Blender 2.78a, FX-8350
official binary: 1 minutes 8 seconds
custom compiled (gcc 6.2.1): 1 minute 3 seconds
Windows 10, Blender 2.78a, Core i5 6200U
official binary: 3 minutes 26 seconds
Stilt AVX2 MSVC: 2 minutes 25 seconds
Stilt SIMD: 2 minutes 19 secondsI just did a very quick test with 100 sample and FX 8350@4.8 and lot of background programs. 00:46:13
8-9 sec faster
Not at all. GCC produces decently fast code. Also added some ARM chips in my previous post.
We've had data in this forum for several years showing gcc about equivalent to icc. Intel's MKL, however, seems to be top notch and faster than the open source equivalents.
Even though I have little doubt the icc vectorizer is better than the gcc one, a 7x speedup likely means you hit a performance bug in gcc, or an area where some specific icc optimization enables vectorization. Tycho nbody package shows that gcc is competitive with icc when the proper AoS vs SoA layout is used. Given that icc broke libquantum in part due to AoS -> SoA tricks, it makes sense this can applied to other software like Tycho nbody.
Facebook
Twitter