On Thu, Jul 31, 2014 at 07:37:05PM +0200, Peter Zijlstra wrote: > On Thu, Jul 31, 2014 at 06:39:05PM +0200, Jirka Hladky wrote: > > I'm doing 3 iterations (3 runs) to get some statistics. To speed up the test > > significantly please do the run with 20 warehouses only > > (or in general with #warehouses == number of nodes * number of PHYSICAL > > cores) > > Yeah, went and did that for my 4 node machine, its got a ton more cores, but I > matches the warehouses to it: > > -a43455a1d57 tip/master > > 979996.47 1144715.44 > 876146 1098499.07 > 1058974.18 1019499.38 > 1055951.59 1139405.22 > 970504.01 1099659.09 > > 988314.45 1100355.64 (avg) > 75059.546179565 50085.7473975167(stdev) > > So for 5 runs, tip/master (which includes the offending patch) wins hands > down. > > Each run is 2 minutes.
Because Rik asked for a43455a1d57^1 numbers: 546423.08 546558.63 545990.01 546015.98 some a43455a1d57 numbers: 538652.93 544333.57 542684.77 same setup and everything. So clearly the patches after that made 'some' difference indeed, seeing how tip/master is almost twice that. So the reason I didn't so a43455a1d57^1 vs a43455a1d57 is because we already fingered a commit, after that what you test is the revert of that commit, because revert is what you typically end up doing if a commit is fail. But on the state of tip/master, taking that commit out is a net negative for everything I've tested.
pgpQ2fcgd0Qwu.pgp
Description: PGP signature
