Francesc Alted wrote: > A Wednesday 09 September 2009 20:17:20 Dag Sverre Seljebotn escrigué: > > > Ruben Salvador wrote: > > > > Your results are what I expected...but. This code is called from my > main > > > > program, and what I have in there (output array already created for > both > > > > cases) is: > > > > > > > > print "lambd", lambd > > > > print "np.shape(a)", np.shape(a) > > > > print "np.shape(r)", np.shape(r) > > > > print "np.shape(offspr)", np.shape(offspr) > > > > t = clock() > > > > for i in range(lambd): > > > > offspr[i] = r[i] + a[i] > > > > t1 = clock() - t > > > > print "For loop time ==> %.8f seconds" % t1 > > > > t2 = clock() > > > > offspr = r + a[:,None] > > > > t3 = clock() - t2 > > > > print "Pythonic time ==> %.8f seconds" % t3 > > > > > > > > The results I obtain are: > > > > > > > > lambd 80000 > > > > np.shape(a) (80000,) > > > > np.shape(r) (80000, 26) > > > > np.shape(offspr) (80000, 26) > > > > For loop time ==> 0.34528804 seconds > > > > Pythonic time ==> 0.35956192 seconds > > > > > > > > Maybe I'm not measuring properly, so, how should I do it? > > > > > > Like Luca said, you are not including the creation time of offspr in the > > > for-loop version. A fairer comparison would be > > > > > > offspr[...] = r + a[:, None] > > > > > > Even fairer (one less temporary copy): > > > > > > offspr[...] = r > > > offspr += a[:, None] > > > > > > Of course, see how the trend is for larger N as well. > > > > > > Also your timings are a bit crude (though this depends on how many times > > > you ran your script to check :-)). To get better measurements, use the > > > timeit module, or (easier) IPython and the %timeit command. > > Oh well, the art of benchmarking :) > > The timeit module allows you normally get less jitter in timings because > it loops on doing the same operation repeatedly and get a mean. However, > this has the drawback of filling your cache with the datasets (or part > of them) so, in the end, your measurements with timeit does not take > into account the time to transmit the data in main memory into the CPU > caches, and that may be not what you want to measure.
Do you see any issues with this approach: Add a flag timeit to provide two modes: a) Do an initial run which is always not included in timings (in fact, as it gets "min" and not "mean", I think this is the current behaviour) b) Do something else between every run which should clear out the cache (like, just do another big dummy calculation). (Also a guard in timeit against CPU frequency scaling errors would be great :-) Like simply outputting a warning if frequency scaling is detected). -- Dag Sverre _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
