Re: New ASM cores speed test bug
SideWinder <sidewinder-9Aww8k/80nUxHbG02/[email protected]>
| Newsgroups | gmane.comp.distributed-net.rc5 |
|---|---|
| Message-ID | <[email protected]> |
On 8.5.2009 11:45, Dead J. Dona wrote: > [May 05 11:58:55 UTC] OGR-NG benchmark summary : > Default core : #4 (cj-asm-sse-p4) > Fastest core : #2 (rt-asm-mmx) > [May 05 11:58:55 UTC] Core #2 is significantly faster than the default core. > Please file a bug report along with the output of > -cpuinfo. > [May 08 08:31:19 UTC] OGR-NG benchmark summary : > Default core : #4 (cj-asm-sse-p4) > Fastest core : #3 (cj-asm-sse2) > [May 08 08:31:19 UTC] Core #3 is significantly faster than the default core. > Please file a bug report along with the output of > -cpuinfo. > [May 08 08:35:01 UTC] OGR-NG benchmark summary : > Default core : #4 (cj-asm-sse-p4) > Fastest core : #2 (rt-asm-mmx) > [May 08 08:35:01 UTC] Core #2 is marginally faster than the default core. > Testing variability might lead to pick one or the > other. You have such high variance between the results (both relative and absolute), that I wouldn't call this a bug yet. Basically, you need to run the test without other load in the machine, let's say 4 times and then average the results after removing the lowest node per sec count from each core. The cores of interest should be cj-asm-sse-p4, which is theoretically the best optimizes one, then cj-asm-sse2 and rt-asm-mmx. It is entirely possible that two cruncher cores are so close between each other in performance when running in certain processor physical core steppings, that it really doesn't matter which one is picked. However, determining this requires more reliable benchmark results. -- >------->- SideWinder -<-------< PGP key ID: 0x77CCE3D6 ___Computer Science: solving today's problems tomorrow. _______________________________________________ rc5 mailing list rc5-Ra3b/QYEcJ3d140v2zMXi0fjHoOT/h/[email protected] http://lists.distributed.net/mailman/listinfo/rc5
PGP.sig
(application/pgp-signature, 195 B) - not displayed