Bench results updated.
Another performance regression (4.0-5319 and newer) [FIXED!?]
|
02-05-2015, 12:00 PM
@mimimi: Now that the regression is fixed, could you do a rebased PR #1952 test build? It would be interesting to see the bench results.
02-05-2015, 12:27 PM
I dont think these performance regression are actual regression but more on your pc being finicky and any extra load on your cpu affects performance. Thats how it was when i had an old Phenom IIx4 deneb until i upgraded to an ivy bridge i3. I mean nobody can reproduce it, even i tried and still no difference. The same goes for all of your previous topics claiming these regressions. Also you just tested one game which is a bad test sample. You need to test several different games that require different settings like ef2ram, efb2tex, single core etc, you get the picture.
(02-05-2015, 12:27 PM)pinchy Wrote: I dont think these performance regression are actual regression but more on your pc being finicky and any extra load on your cpu affects performance. Thats how it was when i had an old Phenom IIx4 deneb until i upgraded to an ivy bridge i3. I mean nobody can reproduce it, even i tried and still no difference. I did several tests with different titles and settings, and I tried everything, including an OS reinstall and swapping the CPU and GPU with a different model (!) The regression affected everything, not just one test. nsmb was used this time, because it's easy to benchmark and 100% reproducible. A stupid bug is a stupid bug. 02-05-2015, 01:28 PM
Umm, your regression was imaginary if that's the build that fixed it. Just saying; a hotkey merge isn't going to fix a performance regression.
(02-05-2015, 01:28 PM)JMC47 Wrote: Umm, your regression was imaginary if that's the build that fixed it. Just saying; a hotkey merge isn't going to fix a performance regression. No, it's not imaginary. It's real and always reproducible. One possible cause for this regression is very high CPU usage by WxWidgets during runtime, which was caused by a stupid typo error in the Anaglyph shaders commit. The Hotkey commit simply cleaned up / fixed some lines in the Wx files and that squashed the CPU-munching bug in the process. Anyone can browse the diffs and compare the changes to the files @ GitHub. 02-05-2015, 05:06 PM
I believe you, when you say you can reproduce your issues again and again, and you pinpoint those regressions to specific builds. But you are alone with those issues, none of the devs or main contributors can reproduce them.
Maybe there's something wrong with your computer. Do you know about the TLB bug? If you don't, it's likely that it dramatically affects you, the one way or the other. If your cpu has the TLB bug, you get either issues, or the L3 cache is disabled, and the performance is tanked. Or your cpu does not have the TLB bug, but your BIOS and/or Windows still disables the L3 cache, which kills the performance.
No, there's no TLB bug with these CPUs (that bug was fixed a long time ago in hardware) and the L3$ works fine.
To be sure it's not a L3 or TLB issue, I borrowed a crappy, but newer native dual-core Regor without L3$ for a couple of days for testing, just to see if that was the case. I experienced the exact same issue even with that CPU. And that L3$ helps a lot with performance, the Regor needs 4.0~4.1 GHz to perform like a 3.5 GHz Deneb. On the GPU side, I was also testing the R9 270(X) for a couple of days and then returned it, as you can see from my other posts.
Have you tried render to main window checked? This has given me like a 50% speed boost on DX11.
(02-07-2015, 03:16 AM)Slickman Wrote: Have you tried render to main window checked? This has given me like a 50% speed boost on DX11. 'Render to Main' disables Exclusve Fullscreen, which is a known CPU hog. That's why you're getting a massive speed boost. Always use Borderless FS for best performance. |
« Next Oldest | Next Newest »
|
Users browsing this thread: 1 Guest(s)