Message boards :
Number crunching :
Performance drop on new CPU
Message board moderation
Author | Message |
---|---|
Cavalary Send message Joined: 15 Jul 99 Posts: 104 Credit: 7,507,548 RAC: 38 |
Just recently got a new computer, has a Pentium G3440 CPU and was initially doing the regular 183k GFLOPs tasks is quite exactly 2h effective CPU time, with benchmarks showing some 3300-3400 floating point and some 8600-8700 integer. Now, after about a week, the time started increasing (though lately I'm getting usually longer ones, just 2-3 of the 183k ones in this batch of 100, but the estimate for them is around 2:07 now, and those 190-196k ones are going to some 2:30-2:40). Benchmarks around 3350 / 8500, but I turned on the benchmark debug flag and I see this: 5/9/2015 10:56:16 AM | | [benchmark] CPU 0: fp 3291457628.207532 int 8553922672.918948 intloops 149584000.000000 inttime 9.952864 5/9/2015 10:56:16 AM | | [benchmark] CPU 1: fp 3400724558.976434 int 0.000000 intloops 0.000000 inttime 0.000000 Since I never turned that flag on before, is that normal, no int ops on 2nd core, or is there a problem? And why the drop anyway? |
Brent Norman Send message Joined: 1 Dec 99 Posts: 2786 Credit: 685,657,289 RAC: 835 |
I would say that it is possible your CPU is running too hot and backing of a bit to cool down. |
Claggy Send message Joined: 5 Jul 99 Posts: 4654 Credit: 47,537,079 RAC: 4 |
Don't think there's any problem with your benchmark: 09/05/2015 10:11:26 | | [benchmark] Starting floating-point benchmark 09/05/2015 10:11:36 | | [benchmark] Ended floating-point benchmark 09/05/2015 10:11:41 | | [benchmark] Starting integer benchmark 09/05/2015 10:11:51 | | [benchmark] Ended integer benchmark 09/05/2015 10:11:54 | | [benchmark] Ended benchmark 09/05/2015 10:11:55 | | [benchmark] CPU 0 has finished 09/05/2015 10:11:55 | | [benchmark] CPU 1 has finished 09/05/2015 10:11:55 | | [benchmark] CPU 2 has finished 09/05/2015 10:11:55 | | [benchmark] CPU 3 has finished 09/05/2015 10:11:55 | | [benchmark] 4 out of 4 CPUs done 09/05/2015 10:11:55 | | [benchmark] CPU 0: fp 3105570154.610810 int 9105408180.420843 intloops 150992000.000000 inttime 9.438060 09/05/2015 10:11:55 | | [benchmark] CPU 1: fp 3075241060.718381 int 0.000000 intloops 0.000000 inttime 0.000000 09/05/2015 10:11:55 | | [benchmark] CPU 2: fp 3077312298.339559 int 0.000000 intloops 0.000000 inttime 0.000000 09/05/2015 10:11:55 | | [benchmark] CPU 3: fp 3169438734.897026 int 0.000000 intloops 0.000000 inttime 0.000000 09/05/2015 10:11:55 | | Benchmark results: 09/05/2015 10:11:55 | | Number of CPUs: 4 09/05/2015 10:11:55 | | 3107 floating point MIPS (Whetstone) per CPU 09/05/2015 10:11:55 | | 9105 integer MIPS (Dhrystone) per CPU 09/05/2015 10:11:57 | | Resuming computation Claggy |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14654 Credit: 200,643,578 RAC: 874 |
Author: David Anderson <davea@ssl.berkeley.edu> This may relate to the problems with precision timing counters under Windows, that Jason was mentioning in another thread. Edit - might well be related to message 1675126 and https://support.microsoft.com/en-us/kb/895980: Multi core or multiprocessor systems may encounter Time Stamp Counter (TSC) drift when the time between different cores is not synchronized. |
Cavalary Send message Joined: 15 Jul 99 Posts: 104 Credit: 7,507,548 RAC: 38 |
It's running very cool actually. CPU reported temps 48-51C, motherboard 34-37C. Old computer tended to try to hold 67C core temp at a normal room temperature, and the only times I saw it under 60 were the first 30 or so seconds after boot or when the window was open for a while in the middle of winter. This last reply though, can't say I understand what it means... However, after noticing a steady significant difference between core 0 and 1 (~3300 vs. ~3400 fp steady), and core 1 typically running up to 3C cooler too, I set boinc.exe affinity on core 1 and reran benchmarks and got the expected results again steady (actually ~3400 / ~8600). Seems as if Windows swapped core references or something so as of yesterday, since it benchmarks int on a single core, BOINC ended up doing it on the slightly slower one? But that still doesn't explain the clear and sudden difference in WU time. Up till yesterday morning I got those WUs like I was saying in almost exactly 2h effective time, and the estimate was around 2:01. By last night, estimate for them was 2:05. Now it's 2:07, and I had 184k WUs done in around 2:10 and 196k ones in over 2:40 already. |
Brent Norman Send message Joined: 1 Dec 99 Posts: 2786 Credit: 685,657,289 RAC: 835 |
Estimated times are just that, estimates. With a new computer the program doesn't know what your average time is. It takes a week or two for the program to figure out what the average is. Look are the run times in your profile and see what they are actually running. |
Cavalary Send message Joined: 15 Jul 99 Posts: 104 Credit: 7,507,548 RAC: 38 |
That's what I was looking at, and estimates for those were pretty darn accurate, like I was saying. Ah well, will keep tracking. |
jason_gee Send message Joined: 24 Nov 06 Posts: 7489 Credit: 91,093,184 RAC: 0 |
That's what I was looking at, and estimates for those were pretty darn accurate, like I was saying. Ah well, will keep tracking. heh, I think with respect to boinc estimates, the quote "Even a stopped clock gives the right time twice a day" fits "Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions. |
Josef W. Segur Send message Joined: 30 Oct 99 Posts: 4504 Credit: 1,414,761 RAC: 0 |
...no int ops on 2nd core, or is there a problem?... Yes, that's normal. Because there were problems running the Dhrystone test on multiple cores with some XEON chips, only the first core is tested. Joe |
©2024 University of California
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.